New standards are needed to fix reply-by-email
There is a growing (and welcome) trend of web services tightly integrating email into their application workflows. One of the most useful (and frequent) types of integration is reply-by-email. Services like GitHub, Disqus and Facebook all support this.
To get reply-by-email working, services set the From header to a special address that goes back to the service in question. Here's what the From header looks like for messages from GitHub, Disqus and Facebook, respectively:
John Doe <[email protected]> Disqus <[email protected]> Reply to Comment <[email protected]>
In every case, the ... is actually a long, presumably unique, identification string.
This works well in general, but presents a couple of subtle user-experience problems. The most notable problems we've found:
Many clients (like Gmail) will automatically add addresses you contact to your address book. They'll be included in the autocomplete hints when you're composing new messages.
When searching for messages from John Doe using his email address (say [email protected]) you won't see any of the messages from him that came via GitHub.
The autocomplete problem isn't as much of a sticking point for Disqus and Facebook style headers, since they don't use the sender's name. For GitHub-style headers it's a big problem: when I start typing "John Doe" the autocomplete will include the GitHub reply address. That said, GitHub-style headers are nice as they provide more information/context about who is responsible for the message you're receiving.
To solve these problems, there should be a header that services can use to indicate that they are doing this type of From-header munging. When a client sees that header it can avoid adding the From address to the autocomplete index and, for the purposes of search, can index the message using a different address that the service optionally provides.
Let's say the header chosen is X-Indexable-From. For a service to indicate that a message's From address shouldn't be added to contacts/auto-complete, it just sets:
X-Indexable-From: false
If it's compatible with a service's privacy policy, it can also specify the address of the person who is actually responsible for the notification being received. That way, the proper name/address can be added to the receiver's contacts and search index:
X-Indexable-From: [email protected]
or
X-Indexable-From: John Doe <[email protected]>
In any of these examples, the From header stays the same as above - it's just ignored by clients for the purposes of autocomplete & search indexing.
Since we're proposing this, it may come as no surprise that we're running into similar issues at Fiesta with our implementation of Reply-Thru. We thought we'd publish this post and see if others have thoughts on this or can point out anything we're overlooking. Consider it a very informal RFC. Is anybody else interested in pushing something like this forward as an open standard? Alternatively, is there an existing solution to this problem?
Edit: We've already heard from a couple of people who run services that have the same issue and are looking for solutions. The best thing you can do to help is to spread the word about this problem and the proposed solution. It doesn't really become viable until we get the attention of at least one big email client, so I'm not proposing that people start adding this header to outbound emails yet. Or at least not until there is consensus built around syntax, header name, etc.
