Loading ...
Sorry, an error occurred while loading the content.

Re: Disabling SMTP Auth per user

Expand Messages
  • List
    ... Indeed, we are actually writing a policy service now to deal with rate limits and blacklisting/whitelisting SASL. One thing I noticed in the documentation
    Message 1 of 7 , Oct 2, 2013
    • 0 Attachment
      On 10/2/13 10:32 AM, Viktor Dukhovni wrote:
      On Wed, Oct 02, 2013 at 10:17:16AM -0500, List wrote:
      
      
      We are currently using dovecot for smtp auth, and due to an increase
      in spammers abusing smtp auth we setup dovecot to return an invalid
      login for user's that have been set to "disabled" in our
      provisioning system.  This seemed to work for a while (preventing
      spammers that are using auth), but we are finding that a number of
      spammers are somehow keeping their smtp connection open after we
      have "disabled" smtp auth and continuing to send messages even
      though the authentication should be failing.  We are not sure why
      this is the behavior or even what we should be looking for to
      determine how they are circumventing the authentication.
      
      The full story is in your logs.  Find a message sent by a disabled
      user after the account was disabled.  Find the associated stmpd(8)
      connect and disconnect log entries.  If a single connection continues
      to generate messages long after the account is disabled, then indeed
      your description is correct.
      
      Regardless of whether you've disabled an account or not,  you should
      probably use a policy service that limits the message rate from a
      a given SASL user account (returning a 421 error code when the rate
      is exceeded).  The policy service can also check whether the account
      has been disabled.  This check will not be cached (unlike the SASL
      login status of the SMTP connection).
      
      
      Indeed, we are actually writing a policy service now to deal with rate limits and blacklisting/whitelisting SASL.  One thing I noticed in the documentation regarding smtpd_recipient_restrictions (under " Dangerous use of smtpd_recipient_restrictions") is that recipient restrictions can result in too permissive access.  I wonder if moving the check_client_access and permit_sasl_authenticated below reject_unauth_destination would help?

      smtpd_recipient_restrictions =
                 #### Permit networks defined in /etc/postfix/mynetworks
                 permit_mynetworks
                 reject_unauth_destination
                 #### POP/IMAP before SMTP
                 check_client_access mysql:/etc/postfix/authb4smtp.cf
                 check_client_access cidr:/etc/postfix/access
                 #### Permit SASL authenticated
                 permit_sasl_authenticated

      Also I understand that smtp_client_restrictions is the first to be evaluated, would it make sense to move the permit_sasl_authenticated into this access restriction or not so much?

       
    • Viktor Dukhovni
      ... Don t. ... Too late, their outbound mail has already been rejected. ... No. Take time to understand how Postfix restrictions work. With Postfix 2.10 or
      Message 2 of 7 , Oct 2, 2013
      • 0 Attachment
        On Wed, Oct 02, 2013 at 10:46:12AM -0500, List wrote:

        > One thing I noticed
        > in the documentation regarding smtpd_recipient_restrictions (under "
        > Dangerous use of smtpd_recipient_restrictions") is that recipient
        > restrictions can result in too permissive access. I wonder if
        > moving the check_client_access and permit_sasl_authenticated below
        > reject_unauth_destination would help?

        Don't.

        >
        > smtpd_recipient_restrictions =
        > #### Permit networks defined in /etc/postfix/mynetworks
        > permit_mynetworks
        > reject_unauth_destination
        > #### POP/IMAP before SMTP
        > check_client_access mysql:/etc/postfix/authb4smtp.cf
        > check_client_access cidr:/etc/postfix/access
        > #### Permit SASL authenticated
        > permit_sasl_authenticated

        Too late, their outbound mail has already been rejected.

        > Also I understand that smtp_client_restrictions is the first to be
        > evaluated, would it make sense to move the permit_sasl_authenticated
        > into this access restriction or not so much?

        No. Take time to understand how Postfix restrictions work.

        With Postfix 2.10 or later you can use "smtpd_relay_restrictions"
        to avoid being an open relay, and do anti-spam control in the
        various other restriction classes. Some duplication of permissive
        controls is then inevitable, but you're no longer at risk of becoming
        an open relay due to ordering problems.

        --
        Viktor.
      • Manuel Bieling
        ... Moving check_client_access below reject_unauth_destination prevents you from wildcards in check_client_access which can make you an open relay. Just
        Message 3 of 7 , Oct 2, 2013
        • 0 Attachment
          On 10/02/2013 05:46 PM, List wrote:
          > I wonder if moving the
          > check_client_access and permit_sasl_authenticated below
          > reject_unauth_destination would help?

          Moving 'check_client_access' below 'reject_unauth_destination'
          prevents you from wildcards in 'check_client_access' which can make you
          an open relay. Just best practice and not a must.

          > smtpd_recipient_restrictions =
          > #### Permit networks defined in /etc/postfix/mynetworks
          > permit_mynetworks
          > reject_unauth_destination
          > #### POP/IMAP before SMTP
          > check_client_access mysql:/etc/postfix/authb4smtp.cf
          > check_client_access cidr:/etc/postfix/access
          > #### Permit SASL authenticated
          > permit_sasl_authenticated

          I'm wondering what 'permit_sasl_authenticated' effects? If you have
          already rejected unauth destination. Keep in mind "Restrictions are
          applied in the order as specified; the first restriction that matches wins".

          > Also I understand that smtp_client_restrictions is the first to be
          > evaluated, would it make sense to move the permit_sasl_authenticated
          > into this access restriction or not so much?

          Do you mean 'smtpd_client_restrictions'?

          Since 'reject_unauth_destination' is not allowed in
          'smtpd_client_restrictions' you will need 'permit_sasl_authenticated' in
          'smtpd_recipient_restrictions' too.

          In general 'smtpd_client_restrictions' is not want you want. You don't
          want client side authentication. You want authentication for sending
          mails, I think.

          Finally authenticated users via 'permit_sasl_authenticated' can avoid
          'spam checking', 'policy, gray listing' as early as it is checked. But
          that is only relevant for 'smtpd_relay_restrictions'

          http://www.postfix.org/SMTPD_ACCESS_README.html


          Manuel Bieling
        • Viktor Dukhovni
          ... No, it simply breaks POP before SMTP. So the original order is correct. However, now that we see that the OP is using POP before SMTP, it is quite likely
          Message 4 of 7 , Oct 2, 2013
          • 0 Attachment
            On Wed, Oct 02, 2013 at 07:08:48PM +0200, Manuel Bieling wrote:

            > >I wonder if moving the
            > >check_client_access and permit_sasl_authenticated below
            > >reject_unauth_destination would help?
            >
            > Moving 'check_client_access' below 'reject_unauth_destination'
            > prevents you from wildcards in 'check_client_access' which can make
            > you an open relay. Just best practice and not a must.

            No, it simply breaks POP before SMTP. So the original order is
            correct.

            However, now that we see that the OP is using POP before SMTP, it
            is quite likely the POP before SMTP cache, rather than SMTP auth
            that is at issue with the spammers in question. Once SASL is up
            and running, it is wise to stop supporting the POP before SMTP
            crutch.

            --
            Viktor.
          • Manuel Bieling
            ... Aha I see, interesting relict Manuel Bieling
            Message 5 of 7 , Oct 2, 2013
            • 0 Attachment
              On 10/02/2013 07:12 PM, Viktor Dukhovni wrote:
              > However, now that we see that the OP is using POP before SMTP

              Aha I see, interesting relict


              Manuel Bieling
            Your message has been successfully submitted and would be delivered to recipients shortly.