Wandering Thoughts archives

2008-03-26

Why authenticated email won't stop phish spam

Every so often, people proposes some form of authenticated email as a way of stopping phish spam; digital signatures, SPF, DomainKeys, you name it it's probably been put forward. Unfortunately, all of these are tackling the wrong problem and thus none of them can work even in theory (much less in practice).

The core problem of dealing with phish email is not that you need to be able to positively identify messages from your bank, which is what the various forms of authenticated email give you, it's that software needs to be able to block message that claim to be from your bank but aren't. Or, more exactly, it needs to be able to spot email that is trying to convince you that it was sent by your bank when it wasn't.

The usual retort is that once people can positively identify messages from their bank, they'll stop being fooled by all the other messages. But we already know that this sort of positive assertion doesn't work; if it did, phishing wouldn't be a problem because people wouldn't enter their bank credentials into anything except their bank's SSL certified website. Manifestly, they do.

(One of the reasons it doesn't work is that people are much worse at noticing the absence of something than they are at noticing the presence of something.)

WhySignedEmailWontStopPhishing written at 23:47:25; Add Comment

2008-03-04

How we deal with the spam forwarding problem

We have a spam forwarding problem. Specifically, we forward spam, although not through choice; it's a political mandate not to impose filtering on people, and some of the people who don't filter forward their email elsewhere, and predictable things ensue.

We're dealing with this in three ways:

  • we use a different source IP address when forwarding spam-tagged email, splitting good email traffic away from the spam so we avoid contaminating the former with the latter.

    This is especially important for places where a bunch of users may be forwarding their email, like Yahoo and Hotmail; this way we avoid having a user that forwards a lot of spam cause problems for other users who mostly forward non-spam.

  • in order to eliminate as much backscatter as possible, we outright discard bounces of spam-tagged email. This is definitely not RFC compliant but is the lesser evil in a situation with no really good way out.

    (It also keeps our delivery queues small, since otherwise they would fill up with all of the bad addresses that spammers use.)

  • just in case, bounces go out from yet another source IP address, used only for bounces, so if we get blocked for being a backscatter source it will affect as little mail as possible.

Our spam-forwarding source IP address has already shown up on a few email reputation systems, although I believe not in any of the public DNSbls. This doesn't bother me, because I can hardly blame anyone who blacklists it; it is pretty much a spam source.

(Since I don't believe in tempting fate, it has an innocuous host name.)

DealingWithSpamForwarding written at 23:25:13; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.