Don't blame greylisting for this behavior.
Queue-and-retry was an option but it is mandatory since RFC-2821.
The very obsolete RFC-821 stated that "clients should retry". In the old RFC-2119 it was explained that "should" means recommended. The actual RFC-2821 states clearly that: - "the SMTP client retains responsibility for delivery of the message" - "the SMTP client is encouraged to try again" - "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender."
You'd rather blame the lazy programmers who don't cares about RFCs and other standards !
Daniele
Tonnerre Lombard wrote:
The problem is that your users go to web sites and subscribe their mail addresses to newsletters generated by PHP programmers. As expected, a lot of these try to deliver the mail directly to the destination host from the PHP script using some Pear SMTP crap module, rather than local sendmail. A typical dialog looks about like this:
Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) In: HELO gmail.com Out: 250 planck.ngas.ch In: MAIL FROM: blubber@gurgel.org Out: 250 2.1.0 Ok In: RCPT TO: kreisch@ngas.ch Out: 450 4.7.0 You are greylisted for 300 seconds In: DATA Out: 554 Error: No valid recipients In: From blubber@gurgel.org Out: 221 2.0.0 error: I can break rules, too. goodbye.
Not very problematic for the mail server but of course the PHP script does _not_ attempt redelivery. And your users go to gmail, because there they get the mail. Not sure that's desirable for you.
That's the problem I am seeing with Greylisting, and I have discovered that methods like rejecting SPAM after DATA can be way more effective if the SPAM filter databases are sufficiently trained and the RBLs well chosen.
Tonnerre
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog