can't seem to white list an address

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

can't seem to white list an address

Stan Hoeppner
I'd like to keep copies of all the spam coming into the address mentioned below.  I thought all that I needed was an "OK" in the access file to force acceptance of all mail to this address.  My attempt at whitelisting the address is not working.  All my anti-spam measures are still whacking spam to the address.  Suggestions?

relevant /etc/postfix/main.cf entries

smtpd_client_restrictions =
        hash:/etc/postfix/access,
        pcre:/etc/postfix/access.pcre,
        pcre:/etc/postfix/check_client_fqdn.pcre,
        reject_unknown_reverse_client_hostname

smtpd_helo_restrictions =
        reject_non_fqdn_helo_hostname,
        reject_invalid_helo_hostname,
        reject_unknown_helo_hostname

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client dnsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client psbl.surriel.com,
        reject_rbl_client ix.dnsbl.manitu.net,
        check_policy_service inet:127.0.0.1:60000


/etc/postfix/access

[hidden email]            OK


/var/log/mail.log

Sep 12 22:11:50 greer postfix/smtpd[13813]: NOQUEUE: reject: RCPT from CPE-124-189-100-27.gziz1.win.bigpond.net.au[124.189.100.27]: 554 5.7.1 Service unavailable; Client host [124.189.100.27] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=124.189.100.27; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<CPE-124-189-100-27.gziz1.win.bigpond.net.au>
Sep 12 22:15:40 greer postfix/smtpd[13815]: NOQUEUE: reject: RCPT from Tigo190-102-201-26.emtel.net.co[190.102.201.26]: 550 5.7.1 <Tigo190-102-201-26.emtel.net.co[190.102.201.26]>: Client host rejected: We do not accept mail from .co domains; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<Tigo190-102-201-26.emtel.net.co>
Sep 12 23:25:16 greer postfix/smtpd[13900]: NOQUEUE: reject: RCPT from h95-155-243-200.dynamic.se.alltele.net[95.155.243.200]: 554 5.7.1 <h95-155-243-200.dynamic.se.alltele.net[95.155.243.200]>: Client host rejected: Dynamic/DSL/Residential not allowed; from=<[hidden email]> to=<[hidden email]> proto=SMTP helo=<h95-155-243-200.dynamic.se.alltele.net>
Sep 13 00:35:24 greer postfix/smtpd[13976]: NOQUEUE: reject: RCPT from unknown[122.169.208.172]: 450 4.7.1 <ABTS-AP-Dynamic-172.208.169.122.airtelbroadband.in>: Helo command rejected: Host not found; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<ABTS-AP-Dynamic-172.208.169.122.airtelbroadband.in>

Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Noel Jones-2
On 9/15/2009 8:58 AM, Stan Hoeppner wrote:
> I'd like to keep copies of all the spam coming into the address mentioned below.  I thought all that I needed was an "OK" in the access file to force acceptance of all mail to this address.  My attempt at whitelisting the address is not working.  All my anti-spam measures are still whacking spam to the address.  Suggestions?
>
> relevant /etc/postfix/main.cf entries
>
> smtpd_client_restrictions =
>          hash:/etc/postfix/access,

This checks the access table for a client IP.  You need
   check_recipient_access hash:/etc/postfix/access

While postfix allows bare map names, it's far better to always
explicitly use check_{client,helo,sender,recipient}_access to
specify what you're checking.

>          pcre:/etc/postfix/access.pcre,
>          pcre:/etc/postfix/check_client_fqdn.pcre,
>          reject_unknown_reverse_client_hostname
>
> smtpd_helo_restrictions =

You need your check_recipient_access whitelist here too.

>          reject_non_fqdn_helo_hostname,
>          reject_invalid_helo_hostname,
>          reject_unknown_helo_hostname
>
> smtpd_recipient_restrictions =
>          permit_mynetworks,
>          reject_unauth_destination,

You need your check_recipient_access whitelist here too.

>          reject_rbl_client zen.spamhaus.org,
>          reject_rbl_client dnsbl.sorbs.net,
>          reject_rbl_client bl.spamcop.net,
>          reject_rbl_client psbl.surriel.com,
>          reject_rbl_client ix.dnsbl.manitu.net,
>          check_policy_service inet:127.0.0.1:60000
>
>

   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Stan Hoeppner
Ahhh, is this one of the reasons some folks put 'all' of their restrictions under smtpd_recipient_restrictions (only have to list things once)?

Thanks Noel.

--
Stan

Noel Jones put forth on 9/15/2009 9:27 AM:

> On 9/15/2009 8:58 AM, Stan Hoeppner wrote:
>> I'd like to keep copies of all the spam coming into the address
>> mentioned below.  I thought all that I needed was an "OK" in the
>> access file to force acceptance of all mail to this address.  My
>> attempt at whitelisting the address is not working.  All my anti-spam
>> measures are still whacking spam to the address.  Suggestions?
>>
>> relevant /etc/postfix/main.cf entries
>>
>> smtpd_client_restrictions =
>>          hash:/etc/postfix/access,
>
> This checks the access table for a client IP.  You need
>   check_recipient_access hash:/etc/postfix/access
>
> While postfix allows bare map names, it's far better to always
> explicitly use check_{client,helo,sender,recipient}_access to specify
> what you're checking.
>
>>          pcre:/etc/postfix/access.pcre,
>>          pcre:/etc/postfix/check_client_fqdn.pcre,
>>          reject_unknown_reverse_client_hostname
>>
>> smtpd_helo_restrictions =
>
> You need your check_recipient_access whitelist here too.
>
>>          reject_non_fqdn_helo_hostname,
>>          reject_invalid_helo_hostname,
>>          reject_unknown_helo_hostname
>>
>> smtpd_recipient_restrictions =
>>          permit_mynetworks,
>>          reject_unauth_destination,
>
> You need your check_recipient_access whitelist here too.
>
>>          reject_rbl_client zen.spamhaus.org,
>>          reject_rbl_client dnsbl.sorbs.net,
>>          reject_rbl_client bl.spamcop.net,
>>          reject_rbl_client psbl.surriel.com,
>>          reject_rbl_client ix.dnsbl.manitu.net,
>>          check_policy_service inet:127.0.0.1:60000
>>
>>
>
>   -- Noel Jones

Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Noel Jones-2
On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
> Ahhh, is this one of the reasons some folks put 'all' of their restrictions under smtpd_recipient_restrictions (only have to list things once)?
>

Yes, exactly.

   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

VR-9
Noel Jones wrote:
> On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
>> Ahhh, is this one of the reasons some folks put 'all' of their
>> restrictions under smtpd_recipient_restrictions (only have to list
>> things once)?
>>
>
> Yes, exactly.
>
>   -- Noel Jones


This raises a question for me...

If all the checks are listed under smtp_recipient_restrictions...
doesn't postfix still step through each smtpd_*_restrictions "class"
regardless?

E.g.

/etc/postfix/main.cf
   smtpd_recipient_restrictions =
    check_client_access hash:/etc/postfix/access_client
       #(bumps against client criteria)
    reject_non_fqdn_helo_hostname
       #(bumps against helo criteria)

and so on...

If collapsing all checks into smtp_recipient_restrictions, and to be
thorough, would you still need to do something like:

/etc/postfix/main.cf
   smtpd_recipient_restrictions =
    check_client_access hash:/etc/postfix/access
    check_helo_access hash:/etc/postfix/access
    check_recipient_access hash:/etc/postfix/access
    check_sender_access hash:/etc/postfix/access
    check_...

to address checking each portion of the smtp transaction?
Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Noel Jones-2
On 9/18/2009 10:41 AM, VR wrote:

> Noel Jones wrote:
>> On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
>>> Ahhh, is this one of the reasons some folks put 'all' of their
>>> restrictions under smtpd_recipient_restrictions (only have to list
>>> things once)?
>>>
>>
>> Yes, exactly.
>>
>> -- Noel Jones
>
>
> This raises a question for me...
>
> If all the checks are listed under smtp_recipient_restrictions...
> doesn't postfix still step through each smtpd_*_restrictions "class"
> regardless?
>
> E.g.
>
> /etc/postfix/main.cf
> smtpd_recipient_restrictions =
> check_client_access hash:/etc/postfix/access_client
> #(bumps against client criteria)
> reject_non_fqdn_helo_hostname
> #(bumps against helo criteria)
>
> and so on...
>
> If collapsing all checks into smtp_recipient_restrictions, and to be
> thorough, would you still need to do something like:
>
> /etc/postfix/main.cf
> smtpd_recipient_restrictions =
> check_client_access hash:/etc/postfix/access
> check_helo_access hash:/etc/postfix/access
> check_recipient_access hash:/etc/postfix/access
> check_sender_access hash:/etc/postfix/access
> check_...
>
> to address checking each portion of the smtp transaction?

Sort of.  It's bad practice to reuse a map for several
purposes - you should have different maps for client, helo,
sender, etc.   You should also always explicitly specify
check_{client, helo, sender, ...}_access for any table lookups.

So the end result is really the same.


   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

VR-9
Noel Jones wrote:

> On 9/18/2009 10:41 AM, VR wrote:
>> Noel Jones wrote:
>>> On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
>>>> Ahhh, is this one of the reasons some folks put 'all' of their
>>>> restrictions under smtpd_recipient_restrictions (only have to list
>>>> things once)?
>>>>
>>>
>>> Yes, exactly.
>>>
>>> -- Noel Jones
>>
>>
>> This raises a question for me...
>>
>> If all the checks are listed under smtp_recipient_restrictions...
>> doesn't postfix still step through each smtpd_*_restrictions "class"
>> regardless?
>>
>> E.g.
>>
>> /etc/postfix/main.cf
>> smtpd_recipient_restrictions =
>> check_client_access hash:/etc/postfix/access_client
>> #(bumps against client criteria)
>> reject_non_fqdn_helo_hostname
>> #(bumps against helo criteria)
>>
>> and so on...
>>
>> If collapsing all checks into smtp_recipient_restrictions, and to be
>> thorough, would you still need to do something like:
>>
>> /etc/postfix/main.cf
>> smtpd_recipient_restrictions =
>> check_client_access hash:/etc/postfix/access
>> check_helo_access hash:/etc/postfix/access
>> check_recipient_access hash:/etc/postfix/access
>> check_sender_access hash:/etc/postfix/access
>> check_...
>>
>> to address checking each portion of the smtp transaction?
>
> Sort of.  It's bad practice to reuse a map for several purposes - you
> should have different maps for client, helo, sender, etc.   You should
> also always explicitly specify check_{client, helo, sender, ...}_access
> for any table lookups.
>
> So the end result is really the same.
>
>
>   -- Noel Jones

OK, understanding reuse of a check is bad...
Say for discussion it looks more like this:

/etc/postfix/main.cf
smtpd_recipient_restrictions =
check_client_access hash:/etc/postfix/access_client
check_helo_access hash:/etc/postfix/access_helo
check_recipient_access hash:/etc/postfix/access_recipient
check_sender_access hash:/etc/postfix/access_sender
check_...

It would seem because of how the flow of processing works an entry
(white or black listed) would still need to appear in each check even
when collapsed under smtpd_recipient_restrictions?

Are there recommendations for collapsing the checks under
smtpd_recipient_restrictions to simplify whitelisting (or blacklisting)
things without reproducing entries in the check files or having to
maintain individual files?

Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Noel Jones-2
On 9/18/2009 11:25 AM, VR wrote:

> Noel Jones wrote:
>> On 9/18/2009 10:41 AM, VR wrote:
>>> Noel Jones wrote:
>>>> On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
>>>>> Ahhh, is this one of the reasons some folks put 'all' of their
>>>>> restrictions under smtpd_recipient_restrictions (only have to list
>>>>> things once)?
>>>>>
>>>>
>>>> Yes, exactly.
>>>>
>>>> -- Noel Jones
>>>
>>>
>>> This raises a question for me...
>>>
>>> If all the checks are listed under smtp_recipient_restrictions...
>>> doesn't postfix still step through each smtpd_*_restrictions "class"
>>> regardless?
>>>
>>> E.g.
>>>
>>> /etc/postfix/main.cf
>>> smtpd_recipient_restrictions =
>>> check_client_access hash:/etc/postfix/access_client
>>> #(bumps against client criteria)
>>> reject_non_fqdn_helo_hostname
>>> #(bumps against helo criteria)
>>>
>>> and so on...
>>>
>>> If collapsing all checks into smtp_recipient_restrictions, and to be
>>> thorough, would you still need to do something like:
>>>
>>> /etc/postfix/main.cf
>>> smtpd_recipient_restrictions =
>>> check_client_access hash:/etc/postfix/access
>>> check_helo_access hash:/etc/postfix/access
>>> check_recipient_access hash:/etc/postfix/access
>>> check_sender_access hash:/etc/postfix/access
>>> check_...
>>>
>>> to address checking each portion of the smtp transaction?
>>
>> Sort of. It's bad practice to reuse a map for several purposes - you
>> should have different maps for client, helo, sender, etc. You should
>> also always explicitly specify check_{client, helo, sender,
>> ...}_access for any table lookups.
>>
>> So the end result is really the same.
>>
>>
>> -- Noel Jones
>
> OK, understanding reuse of a check is bad...
> Say for discussion it looks more like this:
>
> /etc/postfix/main.cf
> smtpd_recipient_restrictions =
> check_client_access hash:/etc/postfix/access_client
> check_helo_access hash:/etc/postfix/access_helo
> check_recipient_access hash:/etc/postfix/access_recipient
> check_sender_access hash:/etc/postfix/access_sender
> check_...
>
> It would seem because of how the flow of processing works an entry
> (white or black listed) would still need to appear in each check even
> when collapsed under smtpd_recipient_restrictions?

I don't quite understand that statement.
Postfix evaluates restrictions in the order listed.  That's
pretty much all there is to it.  If all your checks are under
smtpd_recipient_restrictions, you only need to whitelist once.


>
> Are there recommendations for collapsing the checks under
> smtpd_recipient_restrictions to simplify whitelisting (or blacklisting)
> things without reproducing entries in the check files or having to
> maintain individual files?
>

When you use a map for multiple purposes you need to keep in
mind what you're doing or you'll end up with unintended
consequences.  For this reason, reusing maps for multiple
purposes is not recommended.  So the warning is really more of
a "watch your step" rather than "do not enter".
Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

VR-9
Noel Jones wrote:

> On 9/18/2009 11:25 AM, VR wrote:
>> Noel Jones wrote:
>>> On 9/18/2009 10:41 AM, VR wrote:
>>>> Noel Jones wrote:
>>>>> On 9/15/2009 11:01 AM, Stan Hoeppner wrote:
>>>>>> Ahhh, is this one of the reasons some folks put 'all' of their
>>>>>> restrictions under smtpd_recipient_restrictions (only have to list
>>>>>> things once)?
>>>>>>
>>>>>
>>>>> Yes, exactly.
>>>>>
>>>>> -- Noel Jones
>>>>
>>>>
>>>> This raises a question for me...
>>>>
>>>> If all the checks are listed under smtp_recipient_restrictions...
>>>> doesn't postfix still step through each smtpd_*_restrictions "class"
>>>> regardless?
>>>>
>>>> E.g.
>>>>
>>>> /etc/postfix/main.cf
>>>> smtpd_recipient_restrictions =
>>>> check_client_access hash:/etc/postfix/access_client
>>>> #(bumps against client criteria)
>>>> reject_non_fqdn_helo_hostname
>>>> #(bumps against helo criteria)
>>>>
>>>> and so on...
>>>>
>>>> If collapsing all checks into smtp_recipient_restrictions, and to be
>>>> thorough, would you still need to do something like:
>>>>
>>>> /etc/postfix/main.cf
>>>> smtpd_recipient_restrictions =
>>>> check_client_access hash:/etc/postfix/access
>>>> check_helo_access hash:/etc/postfix/access
>>>> check_recipient_access hash:/etc/postfix/access
>>>> check_sender_access hash:/etc/postfix/access
>>>> check_...
>>>>
>>>> to address checking each portion of the smtp transaction?
>>>
>>> Sort of. It's bad practice to reuse a map for several purposes - you
>>> should have different maps for client, helo, sender, etc. You should
>>> also always explicitly specify check_{client, helo, sender,
>>> ...}_access for any table lookups.
>>>
>>> So the end result is really the same.
>>>
>>>
>>> -- Noel Jones
>>
>> OK, understanding reuse of a check is bad...
>> Say for discussion it looks more like this:
>>
>> /etc/postfix/main.cf
>> smtpd_recipient_restrictions =
>> check_client_access hash:/etc/postfix/access_client
>> check_helo_access hash:/etc/postfix/access_helo
>> check_recipient_access hash:/etc/postfix/access_recipient
>> check_sender_access hash:/etc/postfix/access_sender
>> check_...
>>
>> It would seem because of how the flow of processing works an entry
>> (white or black listed) would still need to appear in each check even
>> when collapsed under smtpd_recipient_restrictions?
>
> I don't quite understand that statement.
> Postfix evaluates restrictions in the order listed.  That's pretty much
> all there is to it.  If all your checks are under
> smtpd_recipient_restrictions, you only need to whitelist once.
>
>

Sorry for being confusing... I was trying to convey that I do understand
postfix evaluates restrictions in the order listed under a given
smtpd_*_restriction. I'm essentially not grasping how things change when
checks are split out into their respective smtpd_*_restriction vs.
collapsed into smtpd_recipient_restrictions.

I don't grasp how

smtpd_recipient_restrictions=
check_client_access hash:/etc/postfix/access_client
check_helo_access hash:/etc/postfix/access_helo

/etc/postfix/access_client
goo.dip.ad.dre.ss ok

/etc/postfix/access_helo
good.host.com ok


can equate to less whitelisting than:


/etc/postfix/main.cf
smtpd_client_restrictions=
check_client_access hash:/etc/postfix/access_client

smtpd_helo_restrictions=
check_helo_access hash:/etc/postfix/access_helo

/etc/postfixaccess_client
goo.dip.ad.dre.ss ok

/etc/postfix/access_helo
good.host.com ok


I think the reason I might be getting hung up on this is because I'm
thinking postfix restrictions operate just like an SMTP conversation

client
ehlo/helo
mail from
rcpt to
data

which (I thought) means no matter where, for example: check_helo_access
appears, that particular check is only going to operate in the realm of
line 2 above.

Reading back through I realize my question gets fuzzy but I'm
specifically trying to understand the benefits of collapsing all checks
under smtpd_recipient_restrictions as opposed to keeping checks broken
out. To me, it seems like it's one and the same?




>>
>> Are there recommendations for collapsing the checks under
>> smtpd_recipient_restrictions to simplify whitelisting (or blacklisting)
>> things without reproducing entries in the check files or having to
>> maintain individual files?
>>
>
> When you use a map for multiple purposes you need to keep in mind what
> you're doing or you'll end up with unintended consequences.  For this
> reason, reusing maps for multiple purposes is not recommended.  So the
> warning is really more of a "watch your step" rather than "do not enter".

Reply | Threaded
Open this post in threaded view
|

Re: can't seem to white list an address

Brian Evans - Postfix List
VR wrote:

> I don't grasp how
>
> smtpd_recipient_restrictions=
> check_client_access hash:/etc/postfix/access_client
> check_helo_access hash:/etc/postfix/access_helo
>
> can equate to less whitelisting than:
>
> smtpd_client_restrictions=
> check_client_access hash:/etc/postfix/access_client
>
> smtpd_helo_restrictions=
> check_helo_access hash:/etc/postfix/access_helo
>
> I think the reason I might be getting hung up on this is because I'm
> thinking postfix restrictions operate just like an SMTP conversation
>
> client
> ehlo/helo
> mail from
> rcpt to
> data
>
> which (I thought) means no matter where, for example:
> check_helo_access appears, that particular check is only going to
> operate in the realm of line 2 above.
This is how things do work.

Restrictions inherit in descending order as noted in postconf(5) manual.
Ex: client checks can be present in helo,sender,recipient,data(...);
helo checks can be present in sender,recipient,data(...);etc.
Doing so allows more complex checks such as:

smtpd_helo_restrictions=check_client_access hash:/path/to/file

/path/to/file
127.0.0  check_helo_access hash:/path/to/file2

You must also note the value of 'smtpd_delay_reject ' which defaults to yes.
This, basically, puts all decisions of restrictions on hold until after
RCPT TO.
This also allows checks that normally are not allowed/meaningful in a
class, such as a helo check in client, to function.