[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: greylisting anyone?
Concerning most (all?) of these numerous and diverse spam/virus
prevention/detection/cleaning methods, I think the general solution
would be to teach ZMailer about Milter. I've hear tell of 'libmilter',
but Im not sure if it is targeted at MTA developers, or just
milter-plugin developers. So, if not the full blown implementation, then
at least do the equivalent of the content-policy hook just before the
On Thu, 2004-02-26 at 10:48, James MacKinnon wrote:
> 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:
> ZObk13425r DATA
> 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
> ZObk13425r QUIT
> 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)
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to email@example.com