So, after finally getting Postini deployed and enabled for all accounts, the Postini stats report that just over 50% of incoming mail is being tossed out as “blatant spam,” with over 25% of the remaining mail being quarantined as “potential spam.”  This is with Postini on the default lowest aggressiveness setting.  So, assuming the worst case (“all incoming mail is spam”, which is almost true), our users are already receiving less than 37.5% as much spam as they used to.  Once we’re satisfied that things are working fine, I’ll bump up the aggressiveness.

Anyways, I noticed that my FirstClass inbox was still being bombarded by spam messages (a few per hour), most of them obviously spam.  Why weren’t these being blocked by Postini?

Checking the headers on these spam messages, I noticed that they weren’t being routed through the Postini servers.  This means that the spammers are ignoring the MX records for our domain and delivering mail directly to the FirstClass server.  They must have cached the old MX record and kept using it after we switched it to point to a Postini server, because what spammer wants to send mail through Postini if they have the choice?  Anyway, yuck.

Turns out that this is not an unknown problem.  I find it pretty interesting, though.  I didn’t know that spammers did this since I had never bumped into this situation before; just another pretty smart thing that the spammers are doing to get around your efforts to stop them.

Anyway, the solution in this case is to set the mail server (the FirstClass server in this case) or a firewall in between your mail server and the Internet to only accept connections from where it should be coming from.  Seems simple enough?  We are actually routing the mail through Google Apps, so the answer was to only allow connections from addresses that Google’s SPF record says that mail should be coming from.

209.85.128.0/17
216.239.32.0/19
64.233.160.0/19
66.249.80.0/20
72.14.192.0/18
66.102.0.0/20
74.125.0.0/16
64.18.0.0/20
207.126.144.0/20
173.194.0.0/16

Anyway, I set these filters in our firewall and, presto, no spam messages all weekend.

First of all, I’ve never liked to install the Microsoft Office plug-in or Outlook e-mail scanner plug-in that comes with AVG. In my experience, this has led to it wanting me to quit Outlook whenever it wants to install an update (or reboot the machine after the update is complete), which is a bother, and I don’t think it’s a very big risk to leave those components out. So, on my system with only the “basic” e-mail scanner installed, it is only able to scan mail sent through SMTP.

I recently switched to Thunderbird and I have one of my accounts set up to send through SMTP, which means AVG is able to intercept the connection and scan the mail. Even though I do not have AVG set to “certify mail,” it still makes some modifications to the message. Perhaps the most obvious is a message that it adds to the headers of the message…

Received: from 127.0.0.1 (AVG SMTP 8.0.169 [270.6.15/1649]); Wed, 03 Sep 2008 15:30:57 -0500

Of course, it makes sense for it to put this there, because it is actually intercepting the TCP connection used to send the mail and then relaying the mail to the server you specified in your e-mail client. Adding these relay messages to an e-mail will not make it fail validation as they are not covered by the digital signature.

However, oddly, AVG makes some other modifications to the message, as we see in this diff between the mail sitting in my Thunderbird “sent” folder and the mail that showed up in the recipient’s inbox:

I know that AVG caused this because I duplicated the behavior several times, and it stopped right after I disabled AVG’s mail scanner.

There are a number of other small changes like this. These modifications are to the body of the e-mail message, which is covered by the digital signature. The result is, the recipient cannot verify the authenticity of the message, as it appears to have been modified since it was sent (duly so).

Why were these modifications made to the message? Are they just strange errors, or is AVG actually trying to make the style information in the message more consistent for some reason? Whatever the case, your anti-virus software should not be modifying mail that you send, especially without informing you that it is doing so, whatever the modifications may be.

So, here we have a plus for digital signatures and a minus for AVG. I don’t seem to be able to communicate this to AVG support because I am using the free version. If any of you have a paid AVG anti-virus product, maybe you could pass the word along?

Anyway, I now am running AVG without any mail scanning at all. (I hope that common sense in dealing with attachments can keep me safe. )