Apologies for spam - we will blacklist that account right away

Gustin Johnson gustin at echostar.ca
Mon Dec 31 13:15:30 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am not against grey-listing but one should think carefully when
deploying it.  I have threaded some of my comments below, I have also
deleted some of the previous message.

Harish Pillay wrote:
<snip>
> Actually, intuitively, it seems to be putting a lot of stress to the
> servers.  But
> 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
> later.  Genuine
> email servers that implement the SMTP protocol WILL retry (and generally
> do so for upto 5 days).

The problem is that me as the receiver has to keep track of all the grey
listed attempts.  This load grows exponentially with the size of the
user base.  One user account can cause hundreds of delayed messages per
day, the SMTP traffic is not the cause of the load, but all the data
that has to be maintained and routinely checked that is associated with
each message.

<snip>
>> 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.

Nope, it causes a significantly larger load on the receiver, and not the
sender.  The sender only has to queue the message to be resent, the
receiver has to keep track of it all, for every user it serves.  This
database can grow quite large and cause some significant I/O overhead on
a busy mail system.

<snip>

> 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.

I don't know of anyone who does not have multiple methods of fighting
spam and virus emails.  This is usually a good idea.

>> 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 apologize as well for my OT post.

>> 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).

20 thousand person user base?  I would not dream of serving 100 users
with that hardware (the RAM is the scary part for me).  To be fair I/we
use encryption (SSL/TLS) by default, not to mention the virus scanning
and various RBLs and filters that each message goes through.  Also our
greylist approach uses Mysql to store the sender/user/ip/timestamp info,
so this is perhaps not an apples to apples comparison.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHeN1iwRXgH3rKGfMRAqonAJ9QtqiHAwVnSpKOGBeobajH/1FpZgCgj4sU
VhYQEVg9BS8oZfbu+CUUbjw=
=Qmfs
-----END PGP SIGNATURE-----




More information about the community mailing list