Le 03/03/2012 18:11, /dev/rob0 a écrit : > On Sat, Mar 03, 2012 at 12:14:41PM +0200, Nikolaos Milas wrote: >>[snip] >> >> You mean that an error entry in the maps might be such that it >> would allow - under certain circumstances - an undesired "ACCEPT" >> which would bypass reject_unauth_destination (due to the resulting >> stop in the evaluation of the rest of the statements in the >> smtpd_recipient_restrictions directive)?
yes. you write this in your map: joedomain.example REJECT we get too much spam from you then years later, a new admin comes in and wants to accept mail from friend@joedomain.example. he then adds friend@joedomain.example OK (instead of the correct friend@joedomain.example DUNNO ) with the OK there, friend is given a free ticket... This is just an example. things may get worst. The impact of errors is not proprortional to the number of lines ;-p > [snip] > > Sometimes it is easier to offload a few restrictions to another > stage. There is no clear-cut, always right (nor always wrong) way. > Since some (many?) years, my rule of thumb has been: - anti-spam measures go after reject_unauth_destination under smtpd_recipient_retsrictions. - use other restrictions for "special" controls that are not really spam oriented, such as "this address is local-only", "that address is write-only and shouldn't get mail" etc. > Just be aware of who you are allowing to relay and why. Best > practice: use a separate submission service and ONLY allow relay > through that, not on port 25 at all. fully agreed. divide and conquer!
