Salut, Marco, On Wed, 15 Oct 2008 11:01:06 +0200, Marco wrote: > we made the experience that not greylisting itself is the problem. the > problem are miss configured mailservers with wrong queue times or > servers interpreting the greylisting "temp error" code as an "error".
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: <[EMAIL PROTECTED]>
Out: 250 2.1.0 Ok
In: RCPT TO: <[EMAIL PROTECTED]>
Out: 450 4.7.0 You are greylisted for 300 seconds
In: DATA
Out: 554 Error: No valid recipients
In: From [EMAIL PROTECTED]
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
signature.asc
Description: PGP signature
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
