[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
greylisting ( http://projects.puremagic.com/greylisting/ )
appears to be very successful and is catching on. Our main campus
sendmail MTA has implemented it with great results.
I recently decided to integrate it to our older departmental zmailer
(2.99.55) as an add-on hack to my content-policy routine and have seen a
very noticable drop in spam deliverables.
Sample smtpserver log entry showing the block:
ZObk13425w 354 Start mail input; end with <CRLF>.<CRLF>
ZObk13425# policyprogram said: -1 451 4.7.1 Temporary greylist delay
ZObk13425# Content-policy analysis ordered message rejection.
(code=-1); msg='451 4.7.1 Temporary greylist delay'
ZObk13425w 451 4.7.1 Temporary greylist delay
The idea is to keep track of unique triplets (relay_ip,mail_from,rcpt_to)
and to introduce a temporary blocking interval which expires after a given
Well behaved MTA's will resend at some fixed rate or with exponential
backoff, but a lot of simple spam engines do not, and this is where
greylisting gets them, at least for the time being.
Anyone else (Matti?) looked into it?
(in particular, it would be much more efficient to do greylisting before
the DATA/BDAT phase in my case, but I don't know the zmailer code well
enough to pick the best one)
James S. MacKinnon Office: P-139 Avadh-Bhatia Physics Lab
Team Physics Voice : (780) 492-8226 [old AC 403]
University of Alberta email : Jim.MacKinnon@Phys.UAlberta.CA
Edmonton, Canada T6G 2N5 WWW : http://www.phys.ualberta.ca/
for all that we know the universe could cease to exist at any mo
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to firstname.lastname@example.org