[ale] the _REAL_REASON_ for the admin change

[JK]

For some reason, Mike, your message prompted me to wonder if
anyone is doing steganography in spam.  Seems to me if you
wanted a surreptitious communication channel, especially one
intended for broadcast to a large audience, then hiding bits
of messages inside the continuous torrent of spam as it passed
through your email server would be an interesting way to
accomplish that.

Hmm, I suppose botnet control messages could be carried in
spam payloads, as well.  It'd be kind of surprising if
that wasn't the case already.

-- JK

Michael H. Warfield wrote:
> On Wed, 2008-02-20 at 00:16 -0500, Jim Popovitch wrote:
>> 2008/2/20 Jim Kinney <jim.kinney at gmail.com>:
>>> Clearly, spamassassin needs some tuning on the new server.
> 
>> spamassassin should be at least the 3rd level protection, after
>> ClamAV.  First line should be DNSBLs at the MTA.
> 
> 	First line should be greet_pause to knock off the botnets.
> 
>> Add these to sendmail.mc and recompile it:
> 
>> FEATURE(`enhdnsbl', `dnsbl-1.uceprotect.net', `Rejected by DNSBL')dnl
>> FEATURE(`enhdnsbl', `dnsbl-2.uceprotect.net', `Rejected by DNSBL')dnl
>> FEATURE(`enhdnsbl', `zen.spamhaus.org', `Rejected by DNSBL')dnl
>> FEATURE(`enhdnsbl', `dnsbl.sorbs.net', `Rejected by DNSBL')dnl
> 
> FEATURE(`greet_pause',10000)dnl 10 seconds
> 
> 	Then add something like this to "access" for anything you do NOT want to delay:
> 
> GreetPause:localhost            0
> 
> 	Anything not listed in access will get a default greet_pause of 10
> seconds.  What this means is that sendmail waits for 10 seconds before
> sending its banner.  If the client attempts to send any data (say
> botnet) sendmail closes the connection right then and there.
> 
> 	Pause time is in mSec and 0 means no delay.
> 
> 	I've seen this reduce spam load by 80% or more, depending on how much
> spam is being relayed to you through legitimate E-Mail servers.  In the
> case of a front end to a mailing list, I would expect much higher
> effectiveness, since you don't have many lists feeding to the list.  The
> majority of the spam I see is now being relayed to mailing lists to
> which I'm subscribed and, consequently, can not stop this way.  If your
> E-Mail is handled by another MX server (not the case here with the list)
> then it has to be done on the MX server.  It obviously has to be running
> on the machine that the botnets are contacting.

-- 
"What can be asserted without evidence can also be
dismissed without evidence." -- Christopher Hitchens