Stan Hoeppner a écrit :
> mouss put forth on 12/5/2009 7:50 AM:
>
>> you need to read the docs :)
>
> Isn't that always the case here. :)
>
>> an OK in an smtpd_foo_restrictions skips further checks in _that_
>> restriction. so an OK in smtpd_client_restrictions skips further checks
>> and goes to smtpd_helo_restrictions.
>
> Aha! Thanks mouss. I was under the assumption that "first match wins"
> means exactly that. I thought _all_ other checks were skipped after an OK.
>
>> for mail to be accepted, it needs to get an OK in _each_ restriction. by
>> default, all but smtpd_recipient_restrictions return OK, but since you
>> edited yours...
>
> So, "first match wins" only applies within a restriction class. Missed
> that in the docs during previous reads.
>
postfix access allow implementing "AND" friends "linearly", which is
nice. it gives you the ability to say:
- if their head is square, reject. else continue
- if they have 3 hands, reject. else continue.
- if they have 3 eyes, reject. else continue.
...
so at each step/stage, you get rid of a group of offenders.
This is far better than having to deal with complex logic. NOT, OR and
AND are much more complex to deal with in general.
>> This is why I suggested (in my previous post) that you put all your
>> checks under smtpd_recipient_restrictions. Among other things, this
>> avoids the need to duplicate whitelisting actions.
>
> Sanity checking and ease of troubleshooting is precisely why I'd kept
> them separated for years, so each check type was in its respective class
> heading. I guess given the things I'm doing with my static lists, it
> makes no sense to continue my current method, given it makes the
> troubleshooting _more_ difficult...
>
I prefer to use a "linear sequence". it's easier to manage, and it's
also easier to test ("why this wasn't blocked" and "why was this
blocked"). It can even be scripted (I yet to publish the script...).
