> From: Hannah Schroeter <[EMAIL PROTECTED]> > And there's no mailout pool with shared queue involved, and if the > envelope sender address is always the same (i.e. no VERP, no SES, > no self-signed SRS, no SRS-enabled forwards, etc.).
Surprisingly few. > >problem? During the initial weeks of using spamd on my server, half of the > >complaints about undelivered email were not the fault of spamd. > > So the other half *was* the fault of spamd? Oh, you floccinaucinihilipilificatrix, you! The very paranoid among us will read the disclaimers involved in greylisting and never get round to implementing it. The braver souls will just do it and see what happens. It turns out that it is an *extremely* valuable tool - far more so than simple content filters, no matter how good they are - and it is well worth having. And I say that as someone who started off at the paranoid end of the spectrum and who implemented greylisting a lot sooner than planned solely because a new CIO had used it at his previous site and insisted we put it up. Yes, there are a few teething troubles, but they mostly get taken care of in the first month where you're monitoring everything closely anyway. There were only two systematic problems we had: 1) some sites issue an RSET, before the RSET code was in spamd. 2) People using older installations of Cisco PIX firewalls had SMTP masking enabled (visible by connecting to their server and seeing stars (*******) where text should be.) Asking them to turn off this useless and broken misfeature fixed the problem, or if they weren't willing to do that, have them mask only incoming connections, not outgoing ones. At our University we have some very demanding faculty with a low tolerance for email glitches. Despite this the greylisting not only went without complaints, it has generated more praise for the IT dept than any other measure in the last year (which is probably a bit galling to the guys working on the hard stuff ;-) ) My advice, just do it. Graham
