Attempting to whitelist sender domain with DUNNO result

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Attempting to whitelist sender domain with DUNNO result

deoren
I suppose it was out of ignorance, but I've used 'OK' in the past to
accept mail from specific domains that are blacklisted by Spamhaus or
have partial DNS records.

Recently I came across several threads here that noted how this was a
bad idea. Looking over the Postfix documentation I seemed to find
confirmation of that. As a result, I've attempted to start using 'DUNNO'
for whitelisting sender domains instead of 'OK'. I don't appear to be
having any luck though, so I wanted to reach out and get confirmation
that the DUNNO action applies to what I'm trying to do.

I have all intentional spam control checks applied within the
smtpd_recipient_restrictions section of the conf file.

Here are some of the checks applied:

smtpd_recipient_restrictions =
     permit_mynetworks,
     permit_sasl_authenticated,
     check_recipient_access
proxy:mysql:/etc/postfix/mysql-recipient_access.cf,
     check_sender_access proxy:mysql:/etc/postfix/mysql-sender_access.cf,
     check_client_access proxy:mysql:/etc/postfix/mysql-client_access.cf,
     ...
     reject_rbl_client zen.spamhaus.org,
     reject_rbl_client b.barracudacentral.org,


 From the log message (which seems to indicate working FCrDNS):

connect from vmta-b-80.listrak.com[66.216.179.80]

and then later:

NOQUEUE: reject: RCPT from vmta-b-80.listrak.com[66.216.179.80]: 554
5.7.1 Service unavailable; Client host [66.216.179.80] blocked using
zen.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL340844; 
from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<vmta-b-80.listrak.com>

I'm attempting to match on the planttherapy.com portion of the 'FROM'
value by using 'planttherapy.com' as my left-hand value. I've used the
'OK' right-hand value as a response in the past for domains I've wished
to whitelist with the check_sender_access directive. Those entries still
work well, though as I've mentioned earlier I now question whether I
should be using 'OK' for whitelisting.


Thanks for reading this and any advice that you have.



References I consulted:

* http://www.postfix.org/access.5.html

*
http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access

*
http://postfix.1071664.n5.nabble.com/check-client-access-won-t-check-hostname-td86126.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

Bill Cole-3
On 29 Jul 2017, at 0:13, deoren wrote:

> I suppose it was out of ignorance, but I've used 'OK' in the past to
> accept mail from specific domains that are blacklisted by Spamhaus or
> have partial DNS records.
>
> Recently I came across several threads here that noted how this was a
> bad idea. Looking over the Postfix documentation I seemed to find
> confirmation of that.

That's not strictly correct. It is more precise to do domain-wide
whitelisting in a milter or policy daemon that can authenticate the
sender and/or client host in some fashion but if you're not set up for
that and can accept the risk of trivial address forgery, whitelisting in
Postfix works.

> As a result, I've attempted to start using 'DUNNO' for whitelisting
> sender domains instead of 'OK'. I don't appear to be having any luck
> though, so I wanted to reach out and get confirmation that the DUNNO
> action applies to what I'm trying to do.

It does not. As documented, "DUNNO" only terminates whatever matching is
being done within the current map. It does not bypass matching in
additional maps for the same restriction (e.g. check_sender_access) or
in later restrictions (e.g. reject_rbl_client) within the same
restriction list, or in any restriction list that is applied after the
current one.

The only way to exempt a sender address from blockage by a DNSBL (i.e.
based on client IP) is to map the address to 'OK' (or its synonym
'permit') before the reject_rbl_client directive that you want to not
apply, within the same restriction list.

[...]

> I'm attempting to match on the planttherapy.com portion of the 'FROM'
> value by using 'planttherapy.com' as my left-hand value. I've used the
> 'OK' right-hand value as a response in the past for domains I've
> wished to whitelist with the check_sender_access directive. Those
> entries still work well, though as I've mentioned earlier I now
> question whether I should be using 'OK' for whitelisting.

Using 'OK' in check_sender_access for white;listing isn't wrong, it's
just imperfect and can be risky. It is trivial to forge the SMTP sender
address, so absent additional measures applied AFTER
smtpd_recipient_restrictions (such as replicating the reject_rbl_client
rules in smtpd_relay_restrictions) your 'OK' whitelisting makes you an
open relay for anyone forging the exempted address or domain. Even with
an anti-relay backstop, whitelisting on a domain-wide basis is usually
unnecessarily broad, opening your local mailboxes to spam with forged
senders. The best solution for this in the specific case you cite would
be a pcre or regex check_sender_access map limiting the exemption to a
sender pattern that isn't obvious, perhaps:

/^[A-Z0-9]{25}@bounce.planttherapy.com$/i   OK

N.B.: that's a *guess* about what the local-part pattern might be for
that mailing list. Check your actual senders to figure out if it is too
tight.

Another option for some cases would be IP-based whitelisting in
check_client_access, however in this case I think Spamhaus is absolutely
correct to be listing the address, as it has been a tool for
subscription-bombing. It is also a nuisance to find all the IPs of a
sketchy ESP like listrak, since they have a lot of little blocks almost
all smaller than a /24.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

Wietse Venema
In reply to this post by deoren
deoren:

> I suppose it was out of ignorance, but I've used 'OK' in the past to
> accept mail from specific domains that are blacklisted by Spamhaus or
> have partial DNS records.
>
> Recently I came across several threads here that noted how this was a
> bad idea. Looking over the Postfix documentation I seemed to find
> confirmation of that. As a result, I've attempted to start using 'DUNNO'
> for whitelisting sender domains instead of 'OK'. I don't appear to be
> having any luck though, so I wanted to reach out and get confirmation
> that the DUNNO action applies to what I'm trying to do.
>
> I have all intentional spam control checks applied within the
> smtpd_recipient_restrictions section of the conf file.
>
> Here are some of the checks applied:
>
> smtpd_recipient_restrictions =
>      permit_mynetworks,
>      permit_sasl_authenticated,

Here, insert: reject_unauth_destination, then it is safe to use "OK"
in your check_xxx_access tables below.

        Wietse

>      check_recipient_access
> proxy:mysql:/etc/postfix/mysql-recipient_access.cf,
>      check_sender_access proxy:mysql:/etc/postfix/mysql-sender_access.cf,
>      check_client_access proxy:mysql:/etc/postfix/mysql-client_access.cf,
>      ...
>      reject_rbl_client zen.spamhaus.org,
>      reject_rbl_client b.barracudacentral.org,


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

deoren
On 7/29/17 5:45 PM, Wietse Venema wrote:

> deoren:
>> I suppose it was out of ignorance, but I've used 'OK' in the past to
>> accept mail from specific domains that are blacklisted by Spamhaus or
>> have partial DNS records.
>>
>> Recently I came across several threads here that noted how this was a
>> bad idea. Looking over the Postfix documentation I seemed to find
>> confirmation of that. As a result, I've attempted to start using 'DUNNO'
>> for whitelisting sender domains instead of 'OK'. I don't appear to be
>> having any luck though, so I wanted to reach out and get confirmation
>> that the DUNNO action applies to what I'm trying to do.
>>
>> I have all intentional spam control checks applied within the
>> smtpd_recipient_restrictions section of the conf file.
>>
>> Here are some of the checks applied:
>>
>> smtpd_recipient_restrictions =
>>       permit_mynetworks,
>>       permit_sasl_authenticated,
>
> Here, insert: reject_unauth_destination, then it is safe to use "OK"
> in your check_xxx_access tables below.
>
> Wietse
>
>>       check_recipient_access
>> proxy:mysql:/etc/postfix/mysql-recipient_access.cf,
>>       check_sender_access proxy:mysql:/etc/postfix/mysql-sender_access.cf,
>>       check_client_access proxy:mysql:/etc/postfix/mysql-client_access.cf,
>>       ...
>>       reject_rbl_client zen.spamhaus.org,
>>       reject_rbl_client b.barracudacentral.org,

Thank you!

If I have the following, does that free up using
smtpd_recipient_restrictions for just spam/blacklist/whitelist rules?

smtpd_relay_restrictions =
     permit_mynetworks,
     permit_sasl_authenticated,
     reject_unauth_destination,


Thank you for your help.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

deoren
In reply to this post by Bill Cole-3
On 7/29/17 4:31 PM, Bill Cole wrote:

> On 29 Jul 2017, at 0:13, deoren wrote:
>
>> I suppose it was out of ignorance, but I've used 'OK' in the past to
>> accept mail from specific domains that are blacklisted by Spamhaus or
>> have partial DNS records.
>>
>> Recently I came across several threads here that noted how this was a
>> bad idea. Looking over the Postfix documentation I seemed to find
>> confirmation of that.
>
> That's not strictly correct. It is more precise to do domain-wide
> whitelisting in a milter or policy daemon that can authenticate the
> sender and/or client host in some fashion but if you're not set up for
> that and can accept the risk of trivial address forgery, whitelisting in
> Postfix works.

Thanks for the tip. It's been on my todo list for some time, but I'm
making do for now. I hope to carve out some time to implement such a
tool in the future.

>
>> As a result, I've attempted to start using 'DUNNO' for whitelisting
>> sender domains instead of 'OK'. I don't appear to be having any luck
>> though, so I wanted to reach out and get confirmation that the DUNNO
>> action applies to what I'm trying to do.
>
> It does not. As documented, "DUNNO" only terminates whatever matching is
> being done within the current map. It does not bypass matching in
> additional maps for the same restriction (e.g. check_sender_access) or
> in later restrictions (e.g. reject_rbl_client) within the same
> restriction list, or in any restriction list that is applied after the
> current one.

Ah, that makes sense. I was really struggling to understand how DUNNO
works. Thank you for spelling it out to me.

> The only way to exempt a sender address from blockage by a DNSBL (i.e.
> based on client IP) is to map the address to 'OK' (or its synonym
> 'permit') before the reject_rbl_client directive that you want to not
> apply, within the same restriction list.

That's what I've done in the past, but coming across other threads
recommending the use of DUNNO instead of OK confused me. Evidently I
missed the context of those recommendations, which gave me the
impression that DUNNO terminated execution within the same restriction
list. Again, many thanks for spelling that out.


>> I'm attempting to match on the planttherapy.com portion of the 'FROM'
>> value by using 'planttherapy.com' as my left-hand value. I've used the
>> 'OK' right-hand value as a response in the past for domains I've
>> wished to whitelist with the check_sender_access directive. Those
>> entries still work well, though as I've mentioned earlier I now
>> question whether I should be using 'OK' for whitelisting.
>
> Using 'OK' in check_sender_access for white;listing isn't wrong, it's
> just imperfect and can be risky. It is trivial to forge the SMTP sender
> address, so absent additional measures applied AFTER
> smtpd_recipient_restrictions (such as replicating the reject_rbl_client
> rules in smtpd_relay_restrictions) your 'OK' whitelisting makes you an
> open relay for anyone forging the exempted address or domain.

So if I return 'OK' within smtpd_recipient_restrictions, will these
rules within smtpd_relay_restrictions be sufficient to prevent granting
them relay access? I was under the impression that it was?

smtpd_relay_restrictions =
     permit_mynetworks,
     permit_sasl_authenticated,
     reject_unauth_destination,


Even with
> an anti-relay backstop, whitelisting on a domain-wide basis is usually
> unnecessarily broad, opening your local mailboxes to spam with forged
> senders.

I usually try to match the specific sending address where possible,
unless I see that they're auto-generated, which I presume is an intent
to track specific use of the email, etc.

The best solution for this in the specific case you cite would

> be a pcre or regex check_sender_access map limiting the exemption to a
> sender pattern that isn't obvious, perhaps:
>
> /^[A-Z0-9]{25}@bounce.planttherapy.com$/i   OK
>
> N.B.: that's a *guess* about what the local-part pattern might be for
> that mailing list. Check your actual senders to figure out if it is too
> tight.
>
> Another option for some cases would be IP-based whitelisting in
> check_client_access, however in this case I think Spamhaus is absolutely
> correct to be listing the address, as it has been a tool for
> subscription-bombing. It is also a nuisance to find all the IPs of a
> sketchy ESP like listrak, since they have a lot of little blocks almost
> all smaller than a /24.

Good tips, thank you.

I think in a few cases I have whitelisted IPs in the past, but rarely.
I'm fortunate that I'm mostly doing this as a personal/learning setup,
so I've been able to apply what I feel are aggressive checks while
falling back to whitelisting specific sites that send mail that we're
interested in.

So far so good, aside from various points of ignorance like the one you
helped clear up for me. I still have much to learn.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

Wietse Venema
In reply to this post by deoren
deoren:
> If I have the following, does that free up using
> smtpd_recipient_restrictions for just spam/blacklist/whitelist rules?
>
> smtpd_relay_restrictions =
>      permit_mynetworks,
>      permit_sasl_authenticated,
>      reject_unauth_destination,
>
> Thank you for your help.

That would make 'OK' safe in smtpd_recipient_restrictions.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

deoren
On 7/30/17 7:12 AM, Wietse Venema wrote:

> deoren:
>> If I have the following, does that free up using
>> smtpd_recipient_restrictions for just spam/blacklist/whitelist rules?
>>
>> smtpd_relay_restrictions =
>>       permit_mynetworks,
>>       permit_sasl_authenticated,
>>       reject_unauth_destination,
>>
>> Thank you for your help.
>
> That would make 'OK' safe in smtpd_recipient_restrictions.
>
> Wietse
>

Thank you for confirming! I appreciate your help.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

Bill Cole-3
In reply to this post by deoren
On 29 Jul 2017, at 23:30, deoren wrote:

> On 7/29/17 4:31 PM, Bill Cole wrote:
[...]

>> Using 'OK' in check_sender_access for white;listing isn't wrong, it's
>> just imperfect and can be risky. It is trivial to forge the SMTP
>> sender address, so absent additional measures applied AFTER
>> smtpd_recipient_restrictions (such as replicating the
>> reject_rbl_client rules in smtpd_relay_restrictions) your 'OK'
>> whitelisting makes you an open relay for anyone forging the exempted
>> address or domain.
>
> So if I return 'OK' within smtpd_recipient_restrictions, will these
> rules within smtpd_relay_restrictions be sufficient to prevent
> granting them relay access? I was under the impression that it was?
>
> smtpd_relay_restrictions =
>     permit_mynetworks,
>     permit_sasl_authenticated,
>     reject_unauth_destination,

Yes. As always, Dr. Venema knows more than anyone about Postfix and his
recommendation was much more concise and complete than mine:
reject_unauth_destination before any access map used as a whitelist
prevents the whitelisting from opening a relay hole.

[...]
> So far so good, aside from various points of ignorance like the one
> you helped clear up for me. I still have much to learn.

True for us all, aside from those who actually write the code.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

Noel Jones-2
In reply to this post by deoren
On 7/30/2017 9:18 AM, deoren wrote:

> On 7/30/17 7:12 AM, Wietse Venema wrote:
>> deoren:
>>> If I have the following, does that free up using
>>> smtpd_recipient_restrictions for just spam/blacklist/whitelist
>>> rules?
>>>
>>> smtpd_relay_restrictions =
>>>       permit_mynetworks,
>>>       permit_sasl_authenticated,
>>>       reject_unauth_destination,
>>>
>>> Thank you for your help.
>>
>> That would make 'OK' safe in smtpd_recipient_restrictions.
>>
>>     Wietse
>>
>
> Thank you for confirming! I appreciate your help.


I prefer to use permit_auth_destination rather than OK for
whitelisting.  Using permit_auth_destination is an always safe
"deliver here" action that doesn't depend on other rules to prevent
unintentional open relay.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

deoren
On 7/30/17 4:15 PM, Noel Jones wrote:

> On 7/30/2017 9:18 AM, deoren wrote:
>> On 7/30/17 7:12 AM, Wietse Venema wrote:
>>> deoren:
>>>> If I have the following, does that free up using
>>>> smtpd_recipient_restrictions for just spam/blacklist/whitelist
>>>> rules?
>>>>
>>>> smtpd_relay_restrictions =
>>>>        permit_mynetworks,
>>>>        permit_sasl_authenticated,
>>>>        reject_unauth_destination,
>>>>
>>>> Thank you for your help.
>>>
>>> That would make 'OK' safe in smtpd_recipient_restrictions.
>>>
>>>      Wietse
>>>
>>
>> Thank you for confirming! I appreciate your help.
>
>
> I prefer to use permit_auth_destination rather than OK for
> whitelisting.  Using permit_auth_destination is an always safe
> "deliver here" action that doesn't depend on other rules to prevent
> unintentional open relay.

Wow, I completely missed that access tables allow the use of
restrictions as an action. Thanks for sharing!

Refs (for anyone stumbling across this thread in the future):

http://www.postfix.org/postconf.5.html#permit_auth_destination
http://www.postfix.org/postconf.5.html#check_sender_access
http://www.postfix.org/access.5.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Attempting to whitelist sender domain with DUNNO result

deoren
In reply to this post by Bill Cole-3
On 7/30/17 1:23 PM, Bill Cole wrote:

> On 29 Jul 2017, at 23:30, deoren wrote:
>
>> On 7/29/17 4:31 PM, Bill Cole wrote:
> [...]
>>> Using 'OK' in check_sender_access for white;listing isn't wrong, it's
>>> just imperfect and can be risky. It is trivial to forge the SMTP
>>> sender address, so absent additional measures applied AFTER
>>> smtpd_recipient_restrictions (such as replicating the
>>> reject_rbl_client rules in smtpd_relay_restrictions) your 'OK'
>>> whitelisting makes you an open relay for anyone forging the exempted
>>> address or domain.
>>
>> So if I return 'OK' within smtpd_recipient_restrictions, will these
>> rules within smtpd_relay_restrictions be sufficient to prevent
>> granting them relay access? I was under the impression that it was?
>>
>> smtpd_relay_restrictions =
>>     permit_mynetworks,
>>     permit_sasl_authenticated,
>>     reject_unauth_destination,
>
> Yes. As always, Dr. Venema knows more than anyone about Postfix and his
> recommendation was much more concise and complete than mine:
> reject_unauth_destination before any access map used as a whitelist
> prevents the whitelisting from opening a relay hole.
>
> [...]
>> So far so good, aside from various points of ignorance like the one
>> you helped clear up for me. I still have much to learn.
>
> True for us all, aside from those who actually write the code.

Thanks again for your help. Your explanation really helped me understand
the details. Sometimes hearing the same thing said a different way
finally makes everything you've heard/read "click".
Loading...