reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 [hidden email] is not owned by [hidden email]

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



Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Noel Jones-2
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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 [hidden email] is not owned by [hidden email]

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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
On 31 October 2011 15:16, Noel Jones <[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 <[hidden email]>: Sender address rejected: not owned by user [hidden email]; from=<[hidden email]> to=<[hidden email]> 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 [hidden email] is not owned by [hidden email]
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
In reply to this post by Noel Jones-2
On 31 October 2011 15:16, Noel Jones <[hidden email]> 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 [hidden email] is not owned by [hidden email]
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Noel Jones-2
On 11/1/2011 1:31 PM, Simon Brereton wrote:

> On 31 October 2011 15:16, Noel Jones <[hidden email]> 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 [hidden email] is not owned by [hidden email]
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
On 1 November 2011 18:53, Noel Jones <[hidden email]> wrote:

> On 11/1/2011 1:31 PM, Simon Brereton wrote:
>> On 31 October 2011 15:16, Noel Jones <[hidden email]> 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 [hidden email] is not owned by [hidden email]
>>>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Jim Seymour-2
In reply to this post by Simon Brereton-2
On Tue, 1 Nov 2011 14:31:14 -0400
Simon Brereton <[hidden email]> 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>.
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
On 2 November 2011 15:53, James Seymour <[hidden email]> wrote:

> On Tue, 1 Nov 2011 14:31:14 -0400
> Simon Brereton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Jim Seymour-2
On Wed, 2 Nov 2011 16:12:07 -0400
Simon Brereton <[hidden email]> 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>.
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
On 2 November 2011 16:26, James Seymour <[hidden email]> wrote:

> On Wed, 2 Nov 2011 16:12:07 -0400
> Simon Brereton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Wietse Venema
Simon Brereton:

> On 2 November 2011 16:26, James Seymour <[hidden email]> wrote:
> > On Wed, 2 Nov 2011 16:12:07 -0400
> > Simon Brereton <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Noel Jones-2
In reply to this post by Simon Brereton-2
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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Simon Brereton-2
On 2 November 2011 18:23, Noel Jones <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Noel Jones-2
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