Thoughts on fixing email forwarding

This article proposes a new internet mail feature. I haven’t worked on any details of design or implementation yet, but I wanted to publish my motivation and initial thoughts.

The problem

After hanging around the Internet for the better part of three decades I have more email addresses than I can remember. None of us want to have loads of mailboxes to check. Back in the day we could forward one mailbox to another, and that was all the implementation needed to simplify matters.

Sadly email forwarding is now a victim in the battle against spam, phishing, and email-borne malware.

It’s fallen on three fronts. The first is that forwarding makes you an inadvertent forwarder of unwanted messages, which hurts your server reputation with the big providers, Gmail & Outlook.com in particular. Secondly, the Sender Policy Framework (SPF), which improved our ability to verify email sources but conflicts with email forwarding, since forwarding changes the source IP, meaning even legitimate mail is likely to be scored negatively in spam filters.

The final (and most recent) nail in forwarding’s coffin is Domain-based Message Authentication, Reporting and Conformance (DMARC), which can turn SPF failures into a brick wall of rejection.

The anti-solution: SRS

One of the solutions for SPF/DMARC issues is the Sender Rewrite Scheme (SRS). SRS is a specific class of address rewrite called a variable envelope return path (VERP) and rewrites the outbound sender to make SPF policies pass, with a cryptographic proof for bounce verification.

This solves your SPF & DMARC delivery failure problems. But there are many downsides, the most glaring of which is that you’re still a potential spam forwarder, which remember lowers your reputation rather than the spammy origin. Your forwarding server is also now responsible for queueing and delivery, and for rewriting and forwarding any bounce messages.

To sum up, it’s a spammer’s dream. SRS is a source of problems; I don’t use it.

What’s the alternative to forwarding, then?

The first is to give up and use an aggregating MUA. This has been my preferred mode lately, just using a regular email client that aggregates inbox views across multiple mailboxes.

The second is to use more sophisticated methods to synchronise your email. It’s the equivalent of automatically dragging-and-dropping your messages from one mailbox to another. I’ve done this; it’s inefficient, brittle, scales poorly, hard to configure. There’s a cut-down version of this idea in Gmail, which can pull from external POP3 mailboxes.

The third might be to steal HTTP’s rerouting model.

A new response code for mail rerouting

Some email services call their forwarding “redirection”, but it isn’t really, it’s forwarding as described above, with the intermediary taking responsibility for queuing & delivery & bouncing & the reputational risk et cetera. But to avoid confusion I’ll avoid the term.

HTTP has a rerouting mechanism, in which the client is told to go somewhere else next for their request. The response codes vary in subtle shades of meaning, but the most common are 301 Moved Permanently and 302 Found. Many RESTful apps also issue 303 See Other when there’s a GET to perform in response to a POST. Either way, the new URL is given in the Location header field and the client is expected to try there next.

The important point is that responsibility for placing the revised request is still with the originating client, but the destination remains under the control of the first responder. If SMTP had a similar mechanism, then we’d be able to redirect/rewrite email without falling afoul of the failure modes described above.

Curiously, there almost is such a response code. The SMTP standard, even as far back as RFC 821, included response code 551 to specify an alternative recipient. However the response is poorly constructed and is, as far as my skimpy research goes, never implemented. I surmised from the form of the response that it was originally intended for human, not programmatic consumption. Subsequent RFCs have tried to revise this, to indicate that well-formed rewritten addresses should be a valid reply to act upon programmatically. The semantics of doing so aren’t clearly stated, however, and no-one honours it anyway; I checked three major MTA implementations and none of them bother to act on a 551 except to bounce the message.

I think we need a new response code, perhaps even re-using some of the 30x codes from HTTP, and with well-defined semantics for SMTP in a modern context, and the backing of major MTAs and the big email providers to honour it. Yeah, that’s all.

Downsides

I haven’t considered all possible downsides yet; the most obvious is that declaring another email address makes it a potential address harvesting mechanism. I’m hoping that by thinking about the problem in advance, we might find a mechanism that makes it less likely - e.g. by verifying the sender’s SPF & DMARC policy before responding.

It’ll perhaps need a mechanism by which clients can declare their willingness to honour it; might be up to the responder whether to be a hardass or not.

Getting the big providers and popular MTAs on board sounds like teeth-pulling exercise. Neither Google nor Microsoft are famed for their openness to outside leadership.