No Spam Here!

 

Let face it, there just isnít an antispam product that will fix the mess that the original email (SMTP) protocol allows. So from my experiences in having to fix broken applications I decided to fix/bandaid things on my own. With the onset of my younger children now gaining interest and wishing to send and receive email there seemed an inevitable possibility that this garbage would end up in their inbox one day.

 

History:

Iíve been quite comfortable with Sendmail for sometime now, but lets face it, maintaining an access list thatís well over 7000 spammers long is more trouble than its worth. There are many secondary services that can provide a blacklisting, whitelisting and the like, but even they have trouble keeping up with the rapidly changing IP addresses and scams out there. With kids now in the loop, its simply to risky to chance.

 

Cutting them off at the border:

Again, sendmail can be really useful. I donít particularly care for the products that simply store a suspected email in some hidden folder because for 1, Iím paying for my internet service, and the spammers are using it for free to send their garbage data. And 2, I really do want those idiots to know their not getting a message through on my dime. Access lists are great for this because you can tailor a response with colorful phrases letting them know such. But thereís just too many idiots signing up to spam to be able to keep up with it.

 

The war continues:

Its been a cat and mouse game, I get some spam, report it then blacklist the IP/ISP/Network. As of November 2006, I was getting upwards of 3000+ spam emails in a weeks time, coming from any number of random IP addresses. I setup a dummy email account, and just using that would blacklist IP addresses which quickly added about 1000 entries to my access list in a weeks time. After looking at logging from sendmail, I could see that even if the item was blacklisted it would continue to attempt to send.

 

 

Know your goals:

I had to step back and look at what it was I expected from email, and where I expected it to be from. For work, its mailing lists and collegeís emails, for home its friends and family. Since the list of spam items was probably about 80% of my log files, I figured itís a better bet to take the lesser of the two (the valid email senders/IP addresses) and work with those. I searched high and low on the web for some way of getting sendmail to only accept from certain items while denying everything else. To date Iíve not found such, but Iím sure thereís a way to do such, I just donít have the time to recode sendmail to do this in the meantime.

 

My goal:

Allow only trusted traffic, but let the untrusted traffic know Iím not letting it in.

On the off chance that someone somewhere is trying to email me, I needed to give them a sign that the bounces are because of this, not because my domain isnít existent or Iím dead. Initially I setup a firewall that only allowed certain hosts and ranges of networks in to talk to my sendmail server, while the other request simply fell on the floor. After 4 hours, I quickly realized that some of the 70+ drops might be something I missed as a trusted item, or what if someone changed thier ISP? So, I setup another sendmail server that would respond to any email attempt but wonít accept any emails at all. All of these emails will get rejected with a nice 550 error, and the error message has a referral to a webpage with details on how to get access.

 

Technical:

 

So in short, when a trusted IP address hits my firewall it gets sent to the main email server for x.y.z domains. When an untrusted IP hits my firewall it gets routed to the bounce server for a 550 error. This does a couple of things, firstly I can still gauge how many spam emails are attempting to be sent, and 2 I can see whom the emails are going to. In parallel to this I still have an access list on the main server so I can protect from obvious spam/spoofs that might be sent from the trusted networks. In that case I can follow up with the ISP and explain to them that their customer (a friend/co-worker etc.) is using their service and if this doesnít get acted upon Iíll have no choice but to block their traffic and get their customer to find another provider.




The answer to spam?

Not really, more of a anti-spam campaign till someone :) comes up with a new protocol for electronic messages. I suspect this will be a good solution for small providers, maybe medium too, but large providers would more than likely find that the administrative overhead would be too much. I suppose one "could" do some sort of key exchange between email servers to do trusted email, but thats getting well ahead of the objectives of this piliot. Stay tuned, more to come...


Joe Blanchard