Apologies for spam - we will blacklist that account right away
harish.pillay at gmail.com
Wed Dec 26 17:40:38 CET 2007
> > May I make a suggestion to whoever is running this mailing list to add
> > the greylist technique to it as well? I have had milter-greylist
> > running on
> > my main email servers for over 12 months now, and the amount of spam
> > reaching my users/mailing lists has gone down to almost zero.
> I know greylisting works and is stopping spam very effective (for now).
> However this behaviour puts high volume mailservers in a lot of stress.
> Also I am experiencing, that spammers are adapting to greylisting and
> are connecting multiple times to mailservers. Supposedly in order to
> pass greylisting.
> Thus, the administrators of these high volume mailservers have to get
> rid of several thousands incoming connections per minute from a single
> spammer (think of a botnet DDoS you) and delayed outgoing connections
> for your customers.
> You therefore have a higher deferr rate outgoing (doubling outgoing
> connections) and therefore have a bigger mailqueue, additionally you
> have more incoming connections (spam) blocking your available TCP ports
> permanently only for the cause to reject them.
Actually, intuitively, it seems to be putting a lot of stress to the
if you look at what happens, each mail whose domain is not on the whitelist,
gets an "ack" of sorts telling it to come back an unspecified time
email servers that implement the SMTP protocol WILL retry (and generally
do so for upto 5 days).
When a mail is received and is not on the whitelist AND not on a "previously
seen list", a triple gets stored on the server - the sender ID, recipient ID and
sender's IP#. That's it. That incoming SMTP get acked and closed off.
If it was a genuine SMTP server, it will retry and when it does AFTER some
timeout period (which is not known to both ends), and the receiving SMTP
server matches the triple (sender ID, recipient ID and sender IP#), then that
mail is accepted and processed. If it came back within the timeout period,
it will be rejected. It is true that some legitimate SMTP servers WILL retry
almost immediately, but that load is and behaviour is OK for it is usually
> So my advice would be to not use greylisting, as it pushes the problem
> to other parts of the internet and is effective only for a limited time
> (if anyone is using it).
It pushes the problem to the source NOT the receiver. A very large percentage
of these sources are spambots and is therefore perfectly acceptable to have
the push back.
> My thought is, that it would be much more effective to block
> subscription by sophisticated captchas (take care of XSS vulnerabilities
> ) . Also it might be effective to block subscriptions by using lists of
> compromised hosts like CBL (<http://cbl.abuseat.org>).
> Try to identify which IPs are causing trouble and do match them with
> several blacklists. The lists do not always work in the same way as it
> does for others. Sometimes also only a mix of several lists are working.
> <http://karmasphere.com/> might help you there.
milter greylist that I use on my sendmail smtp servers use RBL lists and others
in addition to greylist. So, it is not just one solution.
> If you dont have enough samples, be conservative. It is more a hassle to
> gain legitimate listmembers back, who you have been lost during
> subscription, as blocking fake accounts afterwards.
> Have an eye on your subscriptions. Too many new listmembers is certainly
> not a cause of marketing.
> I might have come a little off topic, but perhaps it helps someone.
> I am now getting back to my cookies, ice cream, cake and teas ;-)
Thanks for the comments and challenges. You are welcome to take the
suggestion and try it out. Nothing to loose I say. It has worked for me on
the server I run (which serves a 20K userbase) and the machine is a lowly
Cobalt Qube with 64MB RAM. It runs the latest sendmail and is also a
webserver (low volume sites btw).
More information about the community