Missing Link

I doubt, therefore I might be.

by John on Nov.03, 2006, under Uncategorized

SPAM  There is one particular type of email that everybody, everywhere, hates.  There is also a meat product that everbody, everywhere, hates.  Not-so-coincidentally, they share the same name.  SPAM.  Just like spam email is the bane of computer (email) users worldwide,  spam the meat is the bane of any sane individual who has standards about which foods they will eat.

For a while, I was able to get by just using a content filter and spamassassin to handle spam email on my mail servers.  Lately, though,  more and more spam messages have been flitting through the filters, and spamassassin has, while not choked, at least shown a sign of increased workload.    I figured now would be as good a time as any to lock the server down farther.

After a bit of research into possible anti-spam methods,  I noticed a neat feature that sendmail has that allows a server administrator to delay sending the smtp greeting.  Since the greeting is mandated by RFC’s, specifically that clients must wait for the greeting before sending data,  you can set it to not immediately send the greeting.    Why would you want to do this?  It’s quite simple, really, when you think about it.  Spammers want to send enormous amounts of email in as short a period of time as possible.   Most of the software they use to send them thus try to connect and immediately start sending data.   The server, knowing it hasn’t sent it’s greeting yet, now knows that this isn’t a legitimate server, and rejects the traffic automatically.   Postfix can mimic this behavior, though it’s a little trickier with postfix to do.   You’d need to set up settings like:

#smtpd_delay_reject = no
#smtpd_client_restrictions =
#   permit_mynetworks
#   sleep 2
#   reject_unauth_pipelining
There is another method, however, which I thought is potentially more interesting.  It’s called greylisting.   Greylisting is also taking advantage of the fact that most spamming software does not conform to standards and RFC’s.  In this approach,  the mail server, upon receiving an email,  looks at it to see if it has seen the IP address of the sending machine, the envelope sender address, and envelope recipient address together before.  If it hasn’t seen traffic that matches all three before it will send a temporary reject notice back to the sending server telling them to re-send in a few minutes (usually around 5 for the default , but user configurable).  When the servers re-send the mail, it is accepted and any further emails matching those criterea are accepted as well.   Just like with the SMTP greeting delay approach,  spammers generally won’t try to resend, as it just takes up more of their time.   Those that do re-send are likely to already have been picked up and added to RBL-XBL black lists and can be filtered easily by the rest of your spam filtering and scanning engines.

Neither of these solutions should be used as a replacement for other spam fighting techniques, but rather should be used to augment them.

Greylisting can be a double edged sword, though.  More information about greylisting can be found on wikipedia.  You should read that before trying to implement this.  Not that anybody who reads my weblog really cares about any of this stuff :-)

So, having set this stuff up, I can say it does reduce spam significantly.  There are other measures that will help secure against spam and virus laden emails even farther, but that’s beyond the scope of what I had to say.

Enjoy a spam free life :-)

:

6 Comments for this entry

Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!