[Greylist-users] exim implementation

[martin dempsey]

> Just readed it. looks great. I need one info: does this local_scan thing
> takes place before the DATA has been received? if yes, this can save a
> lot of bandwidth on receiving spam.

Due to the way exim4 implements local_scan it occurs after DATA. There is no 
choice. But IMO this is a *good* thing. According to Evan, only 4% of "real" 
messages get delayed. So almost all the extra bandwidth used by reporting a 
temporary error after the DATA phase is being used by spammers and open 
relays (and the receiving host of course). But email is probably not the 
biggest thing in normal companies bandwidth budget. Even doubling email 
bandwidth, won't cause companies with normal amounts of email much grief.

But we *want* to cost the spammers bandwidth. All spammers do is spam, so 
doubling the amount of bandwidth needed to send a message really really hurts 
them - either they can only send half as many messages or they need to 
purchase more bandwidth. I'd suggest that after the DATA phase is the proper 
place for the reject. It also can allow you to do sneaky things like running 
the message through spam assassin, doing checksums to look for bulk email to 
multiple users or reporting it as spam even though it you haven't received 
it. If you reject before DATA spammers get off cheap and the only information 
you know about the message are the headers. 

Spend the bandwidth. There are millions of us but fewer spammers. It hurts 
them much more.

> I think that if I use a .deb generated from debian's source package it
> will be done automagically...

This is a little off topic, but basically yes. You can pack up your own home 
compiled exim in a .deb file put that .deb on your own (even password 
protected) webserver. Add the webserver /etc/apt/sources.list on the client 
machines and everything from there is simple and just like the package was 
official. Its easy to load it on 100's of boxes.