SPF and SRS and friends
One of the really promising new anti-spam technogies which is really starting to gain some ground on the net (lots of people are actually using it now) is SPF. It works by having ISPs create DNS entries which list what servers are allowed to send email using their domain name. Since most spammers forge their headers, this makes it really easy to block spam that claims to be from an ISP that has those entries set up.
One of the minor problems with this is it completely breaks the existing notion of a “mail forwarding mailbox.” A little known fact is that we don’t have an in-house mail system at the Mozilla Foundation yet for people to pick up email from (there isn’t really a need for one yet). When you see someone with an @mozilla.org email address, that mail is redirected somewhere else (usually to that person’s home ISP or their own server) after it gets to mozilla.org. With traditional mail forwarding, the mozilla.org mail server would take that email with the @mozilla.org recipient on it, and just change the recipient address to the final destination address and send it on its way, without touching the sender address.
Now enter the age of SPF. The person sending this hypothetical email from @somedomain.com is using an ISP that has one of those SPF records set up. One of the ISPs that several Mozilla Foundation employees use, just started blocking mail if the SPF records don’t match. They receive the email and it says it’s from @somedomain.com. They look up the SPF record for somedomain.com, and get the list of authorized servers to use that domain. But guess what? It didn’t come from that server, it came from rheet.mozilla.org. Bounce.
They have a solution for that, but the solution is causing yet more trouble for us, and I could use some ideas. Read on…
Enter SRS. SRS attempted to solve this problem by having the ISP doing the forwarding (in this case, mozilla.org) rewrite the envelope sender on the email as it passes through the server, so that it indicates that it came from us, and not from the person who sent the message (note that it changes the sender on the envelope, not the one on the From: line at the top of the email). The original sender’s email address is encoded along with a hash that we can verify later if we need to. Now when the recipient’s ISP gets the mail, it actually says it came from mozilla.org, and our SPF record says it can, so the mail is accepted. The only problem is if the mail bounces, it goes back to us, not the original sender. This is where that hash comes in that got added to the sender address. If we just blanket forwarded the bounce notice back to the original sender, it would be easy for spammers to treat us like an open relay and address a “bounce notice” to an address made to look like it forwarded through us. This is what the hash is for in the address we mangled. Now we verify this hash, and if it checks out as something we forwarded, then we go ahead and send it on to the original sender. If it doesn’t, it’s bogus, and we junk the email. The neat part about this is, the SRS config file for Sendmail sets up the mail server to include this hash on ALL outgoing mail, not just forwarded mail. And when we receive bounce notices, if it doesn’t have a hash on it at all, it was obviously forged, so you reject them and kill off all the bounce notices for forged mail the spammers sent claiming to be from you. This is almost perfect, right? Wrong.
New problem. Our user with the @mozilla.org email address also sends his mail with an @mozilla.org return address on it from his home ISP. Since it never passed through our servers, there’s no hash in the return address, so if it bounces, the bounce notice is going to look like a forgery when we get it, and will be discarded.
Does anyone have an answer for this situation? Given the type of setup we have, we can probably live with continuing to deal with all the forged bounce notices just like we always have. If someone knows how to fix SRS so it won’t reject unsigned bounce notices (but won’t forward unsigned bounces to forwarded messages), I’d like to hear from you. Or is a better answer to give all these folks SMTP AUTH passwords and force them to use our mail server for outgoing mail?