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

reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Expand Messages
  • Simon Brereton
    Hi I was evaluating my smptd_recipient_restrictions last week and decided that it made no sense to have reject_sender_login_mismatch after
    Message 1 of 14 , Oct 31, 2011
      Hi

      I was evaluating my smptd_recipient_restrictions last week and decided that it made no sense to have reject_sender_login_mismatch after permit_sasl_authenticated. So I changed it. At the time I was reviewing the documentation I wasn't able to figure out the difference between reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch.

      Since then I have a few items in the logs like:

      Oct 30 17:59:40 mail postfix/smtpd[21281]: connect from cpc17cable-connection.cableprovider.com[12.34.56.78]
      Oct 30 17:59:40 mail postfix/smtpd[21281]: setting up TLS connection from cpc17cable-connection.cableprovider.com[12.34.56.78]
      Oct 30 17:59:40 mail postfix/smtpd[21281]: Anonymous TLS connection established from cpc17cable-connection.cableprovider.com[12.34.56.78]: TLSv1 with cipher AES128-SHA (128/128 bits)
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
      Oct 30 18:09:43 mail postfix/smtpd[21281]: timeout after RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]
      Oct 30 18:09:43 mail postfix/smtpd[21281]: disconnect from cpc17cable-connection.cableprovider.com[12.34.56.78]

      Googling led me to this thread:
      http://comments.gmane.org/gmane.mail.postfix.user/210413

      But I don't understand how myuser@... is not owned by myuser@...

      What is the purpose of reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch and should it come before or after permit_sasl_auth?



      mail:~# postconf -n | grep smtpd_recipient_restrictions
      smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_sender_login_mismatch, permit_sasl_authenticated, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_sender_access hash:/etc/postfix/backscatter check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, check_policy_service unix:private/policy-spf, check_policy_service inet:127.0.0.1:10031, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client blackholes.mail-abuse.org, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, permit

      Postfix is 2.7.1 installed via apt-get on Debian.

      Thanks.

      Simon
    • Noel Jones
      ... Did you see this? http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch With the authenticated version, the sender address is
      Message 2 of 14 , Oct 31, 2011
        On 10/31/2011 12:31 PM, Simon Brereton wrote:
        > Hi
        >
        > I was evaluating my smptd_recipient_restrictions last week and decided that it made no sense to have reject_sender_login_mismatch after permit_sasl_authenticated. So I changed it. At the time I was reviewing the documentation I wasn't able to figure out the difference between reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch.

        Did you see this?
        http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch

        With the "authenticated" version, the sender address is only checked
        if the user has authenticated. This allows unauthenticated mail to
        use a protected sender address, which may be needed for
        notification/invitation services etc. that "spoof" the sender
        address for incoming mail.

        >
        > Since then I have a few items in the logs like:
        >
        > Oct 30 17:59:40 mail postfix/smtpd[21281]: connect from cpc17cable-connection.cableprovider.com[12.34.56.78]
        > Oct 30 17:59:40 mail postfix/smtpd[21281]: setting up TLS connection from cpc17cable-connection.cableprovider.com[12.34.56.78]
        > Oct 30 17:59:40 mail postfix/smtpd[21281]: Anonymous TLS connection established from cpc17cable-connection.cableprovider.com[12.34.56.78]: TLSv1 with cipher AES128-SHA (128/128 bits)
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
        > Oct 30 18:09:43 mail postfix/smtpd[21281]: timeout after RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]
        > Oct 30 18:09:43 mail postfix/smtpd[21281]: disconnect from cpc17cable-connection.cableprovider.com[12.34.56.78]
        >
        > Googling led me to this thread:
        > http://comments.gmane.org/gmane.mail.postfix.user/210413
        >
        > But I don't understand how myuser@... is not owned by myuser@...

        Apparently this user didn't authenticate.
        You define who owns what address in smtpd_sender_login_maps. There
        are no "automatic" mappings.

        > mail:~# postconf -n | grep smtpd_recipient_restrictions
        > smtpd_recipient_restrictions =
        > reject_non_fqdn_sender,
        > reject_non_fqdn_recipient,
        > reject_sender_login_mismatch,
        > permit_sasl_authenticated,

        This should be followed by "permit_mynetworks,
        reject_unauth_destination," followed by your other UCE checks.

        > check_helo_access hash:/etc/postfix/helo_checks,
        > check_sender_access hash:/etc/postfix/ip_whitelist,

        check_sender_access is to check the sender email address, and will
        never match an IP. You must use check_client_access to whitelist by IP.

        > check_recipient_access hash:/etc/postfix/laxdomains,
        > reject_unknown_sender_domain,
        > reject_unknown_recipient_domain,
        > reject_invalid_helo_hostname,
        > reject_non_fqdn_helo_hostname,
        > reject_unknown_helo_hostname,
        > check_sender_access hash:/etc/postfix/backscatter
        > check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
        > permit_mynetworks,
        > reject_unauth_destination,

        This is dangerously late for reject_unauth_destination. You should
        move it above any check_*_access maps.

        > reject_unlisted_recipient,
        > check_policy_service unix:private/policy-spf,
        > check_policy_service inet:127.0.0.1:10031,
        > reject_rbl_client bl.spamcop.net,
        > reject_rbl_client zen.spamhaus.org,
        > reject_rbl_client cbl.abuseat.org,

        cbl is included in zen, so this is a duplicate.

        > reject_rbl_client blackholes.mail-abuse.org,

        Do you pay for a subscription to mail-abuse.org? Otherwise this
        won't work.

        > reject_rbl_client tw.countries.nerd.dk,
        > reject_rbl_client kr.countries.nerd.dk,
        > reject_rbl_client cn.countries.nerd.dk,
        > reject_rbl_client relays.mail-abuse.org,

        Do you pay for a subscription to mail-abuse.org? Otherwise this
        won't work.

        > warn_if_reject, reject_unknown_client,
        > warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org,
        > warn_if_reject, reject_rbl_client dnsbl.sorbs.net,
        > warn_if_reject, reject_rbl_client dnsbl.njabl.org,
        > warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net,
        > permit





        -- Noel Jones
      • Simon Brereton
        ... Thanks again Noel. That helps my understanding. Cheers Simon
        Message 3 of 14 , Oct 31, 2011
          On 31 October 2011 15:16, Noel Jones <njones@...> wrote:
          > On 10/31/2011 12:31 PM, Simon Brereton wrote:
          >> Hi
          >>
          >> I was evaluating my smptd_recipient_restrictions last week and decided that it made no sense to have reject_sender_login_mismatch after permit_sasl_authenticated.  So I changed it.  At the time I was reviewing the documentation I wasn't able to figure out the difference between reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch.
          >
          > Did you see this?
          > http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch
          >
          > With the "authenticated" version, the sender address is only checked
          > if the user has authenticated.  This allows unauthenticated mail to
          > use a protected sender address, which may be needed for
          > notification/invitation services etc. that "spoof" the sender
          > address for incoming mail.
          >
          >>
          >> Since then I have a few items in the logs like:
          >>
          >> Oct 30 17:59:40 mail postfix/smtpd[21281]: connect from cpc17cable-connection.cableprovider.com[12.34.56.78]
          >> Oct 30 17:59:40 mail postfix/smtpd[21281]: setting up TLS connection from cpc17cable-connection.cableprovider.com[12.34.56.78]
          >> Oct 30 17:59:40 mail postfix/smtpd[21281]: Anonymous TLS connection established from cpc17cable-connection.cableprovider.com[12.34.56.78]: TLSv1 with cipher AES128-SHA (128/128 bits)
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 <myuser@...>: Sender address rejected: not owned by user myuser@...; from=<myuser@...> to=<recipient@...> proto=ESMTP helo=<jemima>
          >> Oct 30 18:09:43 mail postfix/smtpd[21281]: timeout after RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]
          >> Oct 30 18:09:43 mail postfix/smtpd[21281]: disconnect from cpc17cable-connection.cableprovider.com[12.34.56.78]
          >>
          >> Googling led me to this thread:
          >> http://comments.gmane.org/gmane.mail.postfix.user/210413
          >>
          >> But I don't understand how myuser@... is not owned by myuser@...
          >
          > Apparently this user didn't authenticate.
          > You define who owns what address in smtpd_sender_login_maps.  There
          > are no "automatic" mappings.

          Thanks again Noel. That helps my understanding.

          Cheers

          Simon
        • Simon Brereton
          ... Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes? ... Nice catch - thanks. ... This is what I was told - but it s always cbl
          Message 4 of 14 , Nov 1, 2011
            On 31 October 2011 15:16, Noel Jones <njones@...> wrote:
            > On 10/31/2011 12:31 PM, Simon Brereton wrote:
            >> Googling led me to this thread:
            >> http://comments.gmane.org/gmane.mail.postfix.user/210413
            >>
            >> But I don't understand how myuser@... is not owned by myuser@...
            >
            > Apparently this user didn't authenticate.
            > You define who owns what address in smtpd_sender_login_maps.  There
            > are no "automatic" mappings.

            Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes?

            >> mail:~# postconf -n | grep smtpd_recipient_restrictions
            >> smtpd_recipient_restrictions =
            >> reject_non_fqdn_sender,
            >> reject_non_fqdn_recipient,
            >> reject_sender_login_mismatch,
            >> permit_sasl_authenticated,
            >
            > This should be followed by "permit_mynetworks,
            > reject_unauth_destination," followed by your other UCE checks.
            > check_sender_access is to check the sender email address, and will
            > never match an IP.  You must use check_client_access to whitelist by IP.

            Nice catch - thanks.

            >> reject_unlisted_recipient,
            >> check_policy_service unix:private/policy-spf,
            >> check_policy_service inet:127.0.0.1:10031,
            >> reject_rbl_client bl.spamcop.net,
            >> reject_rbl_client zen.spamhaus.org,
            >> reject_rbl_client cbl.abuseat.org,
            >
            > cbl is included in zen, so this is a duplicate.

            This is what I was told - but it's always cbl that does the blocking
            in the logs. I seldom get a result for zen.

            >> reject_rbl_client blackholes.mail-abuse.org,
            >
            > Do you pay for a subscription to mail-abuse.org?  Otherwise this
            > won't work.

            I haven't looked at these in a while - removed.

            >> warn_if_reject, reject_unknown_client,
            >> warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org,
            >> warn_if_reject, reject_rbl_client dnsbl.sorbs.net,
            >> warn_if_reject, reject_rbl_client dnsbl.njabl.org,
            >> warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net,
            >> permit

            It's still not clear to me if I need each warn_if_reject, or if I can
            just use one. I.e.

            warn_if_reject,
            reject_unknown_client,
            reject_rbl_client tw.countries.nerd.dk,
            reject_rbl_client kr.countries.nerd.dk,
            reject_rbl_client cn.countries.nerd.dk,
            reject_rhsbl_client dsn.rfc-ignorant.org,
            reject_rbl_client dnsbl.sorbs.net,
            reject_rbl_client dnsbl.njabl.org,
            reject_rbl_client dul.dnsbl.sorbs.net,
            permit


            >> check_recipient_access hash:/etc/postfix/laxdomains,
            >> reject_unknown_sender_domain,
            >> reject_unknown_recipient_domain,
            >> reject_invalid_helo_hostname,
            >> reject_non_fqdn_helo_hostname,
            >> reject_unknown_helo_hostname,
            >> check_sender_access hash:/etc/postfix/backscatter
            >> check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
            >> permit_mynetworks,
            >> reject_unauth_destination,
            >
            > This is dangerously late for reject_unauth_destination. You should
            > move it above any check_*_access maps.

            This is problem with adding things over time. And sometimes I get
            really confused - to whit.


            ## SPAM STUFF and REJECT CODES ##
            smtpd_recipient_restrictions =
            reject_non_fqdn_sender,
            reject_non_fqdn_recipient,
            permit_sasl_authenticated,
            check_helo_access hash:/etc/postfix/helo_checks,
            permit_mynetworks,
            reject_unauth_destination,
            reject_unlisted_recipient,
            check_recipient_access hash:/etc/postfix/laxdomains, (this is
            one domain I host that doesn't want the checking done below)
            check_client_access hash:/etc/postfix/ip_whitelist,
            reject_invalid_helo_hostname,
            reject_non_fqdn_helo_hostname,
            reject_unknown_helo_hostname,
            reject_unknown_sender_domain,
            reject_unknown_recipient_domain,

            Jim Seymour has these two ABOVE permit_mynetworks - which I can see
            for the sender_domain, but if the recipient_domain was above
            permit_mynetworks, then wouldn't postfix reject everything that wasn't
            in $mydestination? So, should it be above or below? And surely if it
            should be above, then so should the helo_hostname checks, no?

            check_sender_access hash:/etc/postfix/backscatter
            check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
            check_policy_service unix:private/policy-spf,
            check_policy_service inet:127.0.0.1:10031,
            reject_rbl_client bl.spamcop.net,
            reject_rbl_client zen.spamhaus.org,
            reject_rbl_client cbl.abuseat.org,
            warn_if_reject,
            reject_unknown_client,
            warn_if_reject,
            reject_rbl_client tw.countries.nerd.dk,
            warn_if_reject,
            reject_rbl_client kr.countries.nerd.dk,
            warn_if_reject,
            reject_rbl_client cn.countries.nerd.dk,
            warn_if_reject,
            reject_rhsbl_client dsn.rfc-ignorant.org,
            warn_if_reject,
            reject_rbl_client dnsbl.sorbs.net,
            warn_if_reject,
            reject_rbl_client dnsbl.njabl.org,
            warn_if_reject,
            reject_rbl_client dul.dnsbl.sorbs.net,
            permit
          • Noel Jones
            ... Right. You must define the user sender address mapping. ... Maybe spamhaus cut you (or your ISP if you use their DNS) off for exceeding their query
            Message 5 of 14 , Nov 1, 2011
              On 11/1/2011 1:31 PM, Simon Brereton wrote:
              > On 31 October 2011 15:16, Noel Jones <njones@...> wrote:
              >> On 10/31/2011 12:31 PM, Simon Brereton wrote:
              >>> Googling led me to this thread:
              >>> http://comments.gmane.org/gmane.mail.postfix.user/210413
              >>>
              >>> But I don't understand how myuser@... is not owned by myuser@...
              >>
              >> Apparently this user didn't authenticate.
              >> You define who owns what address in smtpd_sender_login_maps. There
              >> are no "automatic" mappings.
              >
              > Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes?

              Right. You must define the user <-> sender address mapping.


              >>> reject_unlisted_recipient,
              >>> check_policy_service unix:private/policy-spf,
              >>> check_policy_service inet:127.0.0.1:10031,
              >>> reject_rbl_client bl.spamcop.net,
              >>> reject_rbl_client zen.spamhaus.org,
              >>> reject_rbl_client cbl.abuseat.org,
              >>
              >> cbl is included in zen, so this is a duplicate.
              >
              > This is what I was told - but it's always cbl that does the blocking
              > in the logs. I seldom get a result for zen.

              Maybe spamhaus cut you (or your ISP if you use their DNS) off for
              exceeding their query limits.


              > It's still not clear to me if I need each warn_if_reject, or if I can
              > just use one. I.e.
              >
              > warn_if_reject,
              > reject_unknown_client,
              > reject_rbl_client tw.countries.nerd.dk,


              you need to use warn_if_reject in front of each restriction you want
              turned into a warning.


              > reject_rbl_client dul.dnsbl.sorbs.net,
              > permit

              and for completeness, I'll note the final permit is unnecessary, but
              doesn't really hurt anything.


              > ## SPAM STUFF and REJECT CODES ##
              > smtpd_recipient_restrictions =
              > reject_non_fqdn_sender,
              > reject_non_fqdn_recipient,
              > permit_sasl_authenticated,
              > check_helo_access hash:/etc/postfix/helo_checks,
              > permit_mynetworks,
              > reject_unauth_destination,
              > reject_unlisted_recipient,
              > check_recipient_access hash:/etc/postfix/laxdomains, (this is
              > one domain I host that doesn't want the checking done below)
              > check_client_access hash:/etc/postfix/ip_whitelist,
              > reject_invalid_helo_hostname,
              > reject_non_fqdn_helo_hostname,
              > reject_unknown_helo_hostname,
              > reject_unknown_sender_domain,
              > reject_unknown_recipient_domain,
              >
              > Jim Seymour has these two ABOVE permit_mynetworks - which I can see
              > for the sender_domain, but if the recipient_domain was above
              > permit_mynetworks, then wouldn't postfix reject everything that wasn't
              > in $mydestination? So, should it be above or below? And surely if it
              > should be above, then so should the helo_hostname checks, no?

              The checks "above" permit_mynetworks and permit_sasl_authenticated
              are checks you want applied to your networks and authenticated
              users. Generally it's better to put those checks in
              smtpd_sender_restrictions.



              -- Noel Jones
            • Simon Brereton
              ... Gah. There s like 5 people on this list I force myself to obey and you re one of them... But I thought the recommended best practice was to have it all
              Message 6 of 14 , Nov 2, 2011
                On 1 November 2011 18:53, Noel Jones <njones@...> wrote:
                > On 11/1/2011 1:31 PM, Simon Brereton wrote:
                >> On 31 October 2011 15:16, Noel Jones <njones@...> wrote:
                >>> On 10/31/2011 12:31 PM, Simon Brereton wrote:
                >>>> Googling led me to this thread:
                >>>> http://comments.gmane.org/gmane.mail.postfix.user/210413
                >>>>
                >>>> But I don't understand how myuser@... is not owned by myuser@...
                >>>
                >>> Apparently this user didn't authenticate.
                >>> You define who owns what address in smtpd_sender_login_maps.  There
                >>> are no "automatic" mappings.
                >>
                >> Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes?
                >
                > Right.  You must define the user <-> sender address mapping.

                >> ## SPAM STUFF and REJECT CODES ##
                >> smtpd_recipient_restrictions =
                >>         reject_non_fqdn_sender,
                >>         reject_non_fqdn_recipient,
                >>         permit_sasl_authenticated,
                >>         check_helo_access hash:/etc/postfix/helo_checks,
                >>     permit_mynetworks,
                >>         reject_unauth_destination,
                >>         reject_unlisted_recipient,
                >>         check_recipient_access hash:/etc/postfix/laxdomains,  (this is
                >> one domain I host that doesn't want the checking done below)
                >>         check_client_access hash:/etc/postfix/ip_whitelist,
                >>         reject_invalid_helo_hostname,
                >>         reject_non_fqdn_helo_hostname,
                >>         reject_unknown_helo_hostname,
                >>         reject_unknown_sender_domain,
                >>         reject_unknown_recipient_domain,
                >>
                >> Jim Seymour has these two ABOVE permit_mynetworks - which I can see
                >> for the sender_domain, but if the recipient_domain was above
                >> permit_mynetworks, then wouldn't postfix reject everything that wasn't
                >> in $mydestination?  So, should it be above or below?  And surely if it
                >> should be above, then so should the helo_hostname checks, no?
                >
                > The checks "above" permit_mynetworks and permit_sasl_authenticated
                > are checks you want applied to your networks and authenticated
                > users.  Generally it's better to put those checks in
                > smtpd_sender_restrictions.

                Gah. There's like 5 people on this list I force myself to obey and
                you're one of them... But I thought the recommended best practice was
                to have it all in smtpd_recipient_restrictions.. :(

                So if I take them out of there, and add in:

                smtpd_sender_restrictions = reject_unknown_sender_domain,
                reject_unknown_recipient_domain, permit

                it won't break anything? Won't make me an open relay and won't make a
                backscatterer?

                Simon
              • James Seymour
                On Tue, 1 Nov 2011 14:31:14 -0400 Simon Brereton wrote: [snip] ... [snip] ... [snip] I don t know to which two you refer, but I
                Message 7 of 14 , Nov 2, 2011
                  On Tue, 1 Nov 2011 14:31:14 -0400
                  Simon Brereton <simon.brereton@...> wrote:

                  [snip]
                  >
                  > ## SPAM STUFF and REJECT CODES ##
                  > smtpd_recipient_restrictions =
                  > reject_non_fqdn_sender,
                  > reject_non_fqdn_recipient,
                  > permit_sasl_authenticated,
                  > check_helo_access hash:/etc/postfix/helo_checks,
                  > permit_mynetworks,
                  [snip]
                  >
                  > Jim Seymour has these two ABOVE permit_mynetworks -
                  [snip]

                  I don't know to which two you refer, but I have what I have above
                  permit_mynetworks because I want them to apply to even my own local
                  users.

                  Regards,
                  Jim
                  --
                  Note: My mail server employs *very* aggressive anti-spam
                  filtering. If you reply to this email and your email is
                  rejected, please accept my apologies and let me know via my
                  web form at <http://jimsun.LinxNet.com/contact/scform.php>.
                • Simon Brereton
                  ... Yes, that was my understanding when I followed your original instructions. But Rob and Noel were telling me that I had too much stuff before
                  Message 8 of 14 , Nov 2, 2011
                    On 2 November 2011 15:53, James Seymour <jseymour@...> wrote:
                    > On Tue, 1 Nov 2011 14:31:14 -0400
                    > Simon Brereton <simon.brereton@...> wrote:
                    >
                    > [snip]
                    >>
                    >> ## SPAM STUFF and REJECT CODES ##
                    >> smtpd_recipient_restrictions =
                    >>         reject_non_fqdn_sender,
                    >>         reject_non_fqdn_recipient,
                    >>         permit_sasl_authenticated,
                    >>         check_helo_access hash:/etc/postfix/helo_checks,
                    >>     permit_mynetworks,
                    > [snip]
                    >>
                    >> Jim Seymour has these two ABOVE permit_mynetworks -
                    > [snip]
                    >
                    > I don't know to which two you refer, but I have what I have above
                    > permit_mynetworks because I want them to apply to even my own local
                    > users.

                    Yes, that was my understanding when I followed your original
                    instructions. But Rob and Noel were telling me that I had too much
                    stuff before reject_unauth_destination..

                    I was referring to these two:

                    reject_unknown_sender_domain,
                    reject_unknown_recipient_domain,

                    I guess this is a little off-topic now, but I can see why
                    reject_unknown_sender_domain before permit_mynetworks would be
                    sensible - it's stops my users trying to mail with a
                    randomgibberish.tld but if I put reject_unknown_recipient_domain there
                    postconf.5 says it will

                    Reject the request when Postfix is not final destination for the
                    recipient domain, and the RCPT TO domain has no DNS A or MX record, or
                    when it has a malformed MX record such as a record with a zero-length
                    MX hostname (Postfix version 2.3 and later).

                    Unless that's meant to say it will Reject the request when Postfix is
                    not final destination for the recipient domain, OR the RCPT TO domain
                    has no DNS A or MX record, or when it has a malformed MX

                    Simon
                  • James Seymour
                    On Wed, 2 Nov 2011 16:12:07 -0400 Simon Brereton wrote: [snip] ... No, it means just what it says it means. If the local
                    Message 9 of 14 , Nov 2, 2011
                      On Wed, 2 Nov 2011 16:12:07 -0400
                      Simon Brereton <simon.brereton@...> wrote:

                      [snip]
                      > ... but if I put reject_unknown_recipient_domain there
                      > postconf.5 says it will
                      >
                      > Reject the request when Postfix is not final destination for the
                      > recipient domain, and the RCPT TO domain has no DNS A or MX record, or
                      > when it has a malformed MX record such as a record with a zero-length
                      > MX hostname (Postfix version 2.3 and later).
                      >
                      > Unless that's meant to say it will Reject the request when Postfix is
                      > not final destination for the recipient domain, OR the RCPT TO domain
                      > has no DNS A or MX record, or when it has a malformed MX

                      No, it means just what it says it means. If the local Postfix instance
                      is the final destination it will accept it. Or if a destination for
                      the RCPT domain can be determined it will accept it. If the local
                      Postfix instance is not the final destination or it cannot determine
                      what is, it will be rejected.

                      Regards,
                      Jim
                      --
                      Note: My mail server employs *very* aggressive anti-spam
                      filtering. If you reply to this email and your email is
                      rejected, please accept my apologies and let me know via my
                      web form at <http://jimsun.LinxNet.com/contact/scform.php>.
                    • Simon Brereton
                      ... Well, I think my postulation was closer to your explanation, but either way it s clear now. I ll restore them above mynetworks. Thank-you. Simon
                      Message 10 of 14 , Nov 2, 2011
                        On 2 November 2011 16:26, James Seymour <jseymour@...> wrote:
                        > On Wed, 2 Nov 2011 16:12:07 -0400
                        > Simon Brereton <simon.brereton@...> wrote:
                        >
                        > [snip]
                        >> ... but if I put reject_unknown_recipient_domain there
                        >> postconf.5 says it will
                        >>
                        >> Reject the request when Postfix is not final destination for the
                        >> recipient domain, and the RCPT TO domain has no DNS A or MX record, or
                        >> when it has a malformed MX record such as a record with a zero-length
                        >> MX hostname (Postfix version 2.3 and later).
                        >>
                        >> Unless that's meant to say it will Reject the request when Postfix is
                        >> not final destination for the recipient domain,  OR the RCPT TO domain
                        >> has no DNS A or MX record, or when it has a malformed MX
                        >
                        > No, it means just what it says it means.  If the local Postfix instance
                        > is the final destination it will accept it.  Or if a destination for
                        > the RCPT domain can be determined it will accept it.  If the local
                        > Postfix instance is not the final destination or it cannot determine
                        > what is, it will be rejected.

                        Well, I think my postulation was closer to your explanation, but
                        either way it's clear now. I'll restore them above mynetworks.

                        Thank-you.

                        Simon
                      • Wietse Venema
                        ... The manpage text says, and really means to say, (A AND (B OR C)). This is equivalent to ((A AND B) OR (A AND C)). Your postulation is (A OR B OR C) which
                        Message 11 of 14 , Nov 2, 2011
                          Simon Brereton:
                          > On 2 November 2011 16:26, James Seymour <jseymour@...> wrote:
                          > > On Wed, 2 Nov 2011 16:12:07 -0400
                          > > Simon Brereton <simon.brereton@...> wrote:
                          > >
                          > > [snip]
                          > >> ... but if I put reject_unknown_recipient_domain there
                          > >> postconf.5 says it will
                          > >>
                          > >> Reject the request when Postfix is not final destination for the
                          > >> recipient domain, and the RCPT TO domain has no DNS A or MX record, or
                          > >> when it has a malformed MX record such as a record with a zero-length
                          > >> MX hostname (Postfix version 2.3 and later).
                          > >>
                          > >> Unless that's meant to say it will Reject the request when Postfix is
                          > >> not final destination for the recipient domain, ?OR the RCPT TO domain
                          > >> has no DNS A or MX record, or when it has a malformed MX
                          > >
                          > > No, it means just what it says it means. ?If the local Postfix instance
                          > > is the final destination it will accept it. ?Or if a destination for
                          > > the RCPT domain can be determined it will accept it. ?If the local
                          > > Postfix instance is not the final destination or it cannot determine
                          > > what is, it will be rejected.
                          >
                          > Well, I think my postulation was closer to your explanation, but
                          > either way it's clear now. I'll restore them above mynetworks.

                          The manpage text says, and really means to say, (A AND (B OR C)).
                          This is equivalent to ((A AND B) OR (A AND C)).

                          Your postulation is (A OR B OR C) which equals (A OR (B OR C)).
                          Note the difference with what the manpage says.

                          Wietse
                        • Noel Jones
                          ... That s a guideline, not a best practices -- big difference. If you want to apply some restriction to ALL connections -- both your own senders and outside
                          Message 12 of 14 , Nov 2, 2011
                            On 11/2/2011 2:33 PM, Simon Brereton wrote:

                            >> The checks "above" permit_mynetworks and permit_sasl_authenticated
                            >> are checks you want applied to your networks and authenticated
                            >> users. Generally it's better to put those checks in
                            >> smtpd_sender_restrictions.
                            >
                            > But I thought the recommended best practice was
                            > to have it all in smtpd_recipient_restrictions.. :(

                            That's a guideline, not a best practices -- big difference.
                            If you want to apply some restriction to ALL connections -- both
                            your own senders and outside mail -- it makes sense to put it in a
                            different section.

                            And mostly applies to access tables (check_*_access) since those
                            must be handled carefully.

                            >
                            > So if I take them out of there, and add in:
                            >
                            > smtpd_sender_restrictions = reject_unknown_sender_domain,
                            > reject_unknown_recipient_domain, permit
                            >
                            > it won't break anything? Won't make me an open relay and won't make a
                            > backscatterer?

                            again, the final "permit" is unnecessary.

                            Should be fine, and it certainly won't make you an open relay.



                            -- Noel Jones
                          • Simon Brereton
                            ... Finally, I get it (thanks Wietse and Jim).. I was confusing the binary (in most cases) action of check_*_access with the REJECT access of reject_* So,
                            Message 13 of 14 , Nov 3, 2011
                              On 2 November 2011 18:23, Noel Jones <njones@...> wrote:
                              > On 11/2/2011 2:33 PM, Simon Brereton wrote:
                              >
                              >>> The checks "above" permit_mynetworks and permit_sasl_authenticated
                              >>> are checks you want applied to your networks and authenticated
                              >>> users.  Generally it's better to put those checks in
                              >>> smtpd_sender_restrictions.
                              >>
                              >> But I thought the recommended best practice was
                              >> to have it all in smtpd_recipient_restrictions..  :(
                              >
                              > That's a guideline, not a best practices -- big difference.
                              > If you want to apply some restriction to ALL connections -- both
                              > your own senders and outside mail -- it makes sense to put it in a
                              > different section.
                              >
                              > And mostly applies to access tables (check_*_access) since those
                              > must be handled carefully.

                              Finally, I get it (thanks Wietse and Jim).. I was confusing the
                              binary (in most cases) action of check_*_access with the REJECT access
                              of reject_*

                              So, these should be fine anywhere be fine anywhere before
                              reject_unauth_destination...

                              reject_invalid_helo_hostname,
                              reject_non_fqdn_helo_hostname,
                              reject_unknown_helo_hostname,
                              reject_unknown_sender_domain,
                              reject_unknown_recipient_domain,

                              If I put them above mynetworks it applies to my networks too, but
                              doesn't make me an open relay. And I put them above permit_sasl_auth
                              then it applies to all connections (but the HELO ones would likely
                              knock out any road-warriers (but they should be using the submission
                              port anyway, right)?

                              Thanks again for your patience and guidance.

                              Simon
                            • Noel Jones
                              ... Yes to all the above, but note it s generally considered bad form to reject your own users (either mynetworks or authenticated) for any but the most
                              Message 14 of 14 , Nov 3, 2011
                                On 11/3/2011 9:28 AM, Simon Brereton wrote:

                                > So, these should be fine anywhere be fine anywhere before
                                > reject_unauth_destination...
                                >
                                > reject_invalid_helo_hostname,
                                > reject_non_fqdn_helo_hostname,
                                > reject_unknown_helo_hostname,
                                > reject_unknown_sender_domain,
                                > reject_unknown_recipient_domain,
                                >
                                > If I put them above mynetworks it applies to my networks too, but
                                > doesn't make me an open relay. And I put them above permit_sasl_auth
                                > then it applies to all connections

                                Yes to all the above, but note it's generally considered bad form to
                                reject your own users (either mynetworks or authenticated) for any
                                but the most egregious errors. Of course, you get to define what's
                                egregious for you. Many mail clients present the user a "confusing"
                                error when mail is rejected, triggering a support call, and it's
                                unfriendly to make your own users jump through the same
                                RFC-compliance hoops as a random possibly-hostile MTA.


                                > (but the HELO ones would likely
                                > knock out any road-warriers (but they should be using the submission
                                > port anyway, right)?

                                It doesn't make much sense for your system to present your users
                                different behavior based on the port they connect to.

                                I think putting additional restrictions on port 25 user submission
                                just makes it harder for the end user without any benefit.


                                -- Noel Jones
                              Your message has been successfully submitted and would be delivered to recipients shortly.