A new anti-spam precaution after our local spam incident

September 30, 2012

When we had out local spam incident, I of course immediately started thinking about mail configuration changes we'd want to make to lessen the impact of another such incident. One of them was to arrange it so that another IP address was used when sending out user email that did not come from a local address.

Our mail submission machine (which handles almost all outgoing email) is one of our most important mail machines to keep off blocklists and to maintain with a good reputation, because it's the machine that local human-written email goes out through. This email is the most important email to get through. It's kind of a pain if (say) forwarded email or user-run mailing lists can't get delivered; it's a crisis if professors and staff can't email other universities, GMail, or whatever.

As it happens, all of the spam email sent in the incident had non-local (and forged) origin addresses. The obvious thing to do would be to fix our webmail systems so they don't allow that any more and you have to send with your authenticated local user address (or it just forces that address all the time). I briefly thought about trying to do that and then realized that this would actually make our problem worse. It's not as if this would block the phish spammers from spamming; instead it would just force them to send their spam with one of our email addresses as the origin address. If my goal was to keep our reputation as nice as possible, this would be a step backwards.

The cheap hack is then to use this marker that the spammers have given us to segregate their outgoing email so that it comes out from a different IP address. Then if (or when) there's another spam run due to a compromised local account, it's highly likely that there will be little or no drop in the reputation of our IP address for normal outgoing email. Some of our users routinely send email with non-local addresses and they'd still be affected, but that's a lot better than everyone's email being hit.

(My impression is that forging origin addresses is the common spammer behavior when they exploit compromised systems like ours and that they do it whenever possible. This may change over time.)

PS: this is real concern, not a theoretical worry. A number of systems temporarily blacklisted our outgoing mail machine in the immediate aftermath of the spam run, and did it for long enough that some of our users ran into the blocks with real mail they were sending.


Comments on this page:

From 89.100.144.161 at 2012-10-01 14:54:44:

The forged sender addresses you saw matched every experience we had with this too. Our solution was to vary outbound IP's as you're now doing...although slightly differently than what you're discussing. We had a set of outbound IP's that we could use and after a compromise we'd change the IP being used for primary outbound delivery. This meant that we weren't relying on the reputation of a single IP (for better or worse) and had a quick recovery option.

As we also allowed authenticated senders to relay as any address they chose, we made sure to include the authenticated user info in the headers too so that isolating the compromised account was simple.

-Ben

Written on 30 September 2012.
« A recent spam oddity that I've been mulling over
Some notes on getting durations in DTrace »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 30 23:05:00 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.