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".
