[Greylist-users] exim implementation
mjd at digitaleveryware.com
Tue Jun 24 17:20:32 PDT 2003
> 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.
More information about the Greylist-users