Addressing unsubscribe link leakage when an email is forwarded

Question

Since newsletters are often forwarded (and in fact successful ones encourage it!), what's the conventional wisdom on the security of unsubscribe links?

It's common practice to provide an unsubscribe link at the bottom of every newsletter or newsletter-like email sent to consenting customers, along with a List-Unsubscribe header. Unsubscribe links should include a cryptographically-secure token indicating which subscriber to unsubscribe.

The link often unsubscribes the subscriber immediately (instead of asking confirmation, either through a dialogue or sending an email with a confirmation link), and will often provide a follow-up dialogue allowing the subscriber to unsubscribe from additional newsletters they're also subscribed to from the same website, or resubscribe if unsubscribing was an accident.

So what is the convention when it comes to unsubscribe links?

Is it just user-beware: That if the user has forwarded the email, they're accepting the risk of a recipient unsubscribing them from that and any other newsletters? Should unsubscribe events trigger a notification email? Or is there a special unforwardable element that email clients remove from emails when forwarding them?

Overall, this is a relatively trivial security vulnerability, but I am wondering if this has been considered much before and, if so, what convention dictates. (The problem is briefly referred to in this question and answer and, while I agree that the problem is trivial, I'm still interested if anyone has developed a solution.)

Answer 1

Many mailers use the mailto trick where one needs to send an email with "Unsubscribe" in the subject to unsubscribe.

Create a mailto link in your newsletter. Perhaps add a body with some text telling the user that sending this email will unsubscribe them from the newsletter.

<a href="mailto:newsletter@example.com?subject=unsubscribe">Unsubscribe</a>

When the user clicks the link, their mail client should pop up a new email with the To and Subject pre-filled and ready to send the "unsubscribe" email.

When you receive the email on your server, extract the From field to find who to unsubscribe and if the Subject is "unsubscribe", then unsubscribe them. Of course now you need to deal email forging, if that is something worth tackling.

Additional information: If you want to go the standard way, RFC 2369 explains the commands for mailing lists. (EDIT: As clarified by @AdamKatz RFC 2369 is largely obsoleted these days. Check RFC 8058 for the latest functionality of email headers).

Answer 2

I know of several defenses to this issue that are typical of subscription management systems:

• List-Unsubscribe headers are not added to inline-forwards, so those links are safe
• List-Unsubscribe-Post headers (RFC 8058) specify a single-click unsubscribe, also safe
• mailto: links are email, so it's safe as long as you respond from a subscribed address
• Reply-based unsubscribe can retain original list recipient information in certain headers
• Unsubscribe links in the body can require you to enter your subscribed email address
  (though this is not one-click and shouldn't be used for List-Unsubscribe links)

For programmatic bulk mail detection and management, I must insist on having List-Unsubscribe and List-Unsubscribe-Post headers, though I don't oppose also using additional methods. Notably, the "reply to this email" method is particularly hard to detect.

Answer 3

I don't think this problem has an ideally secure solution in lieu of changes to standards used by email services and providers.

Newsletter services like Mailchimp, which have an interest in coming up with secure solutions, use simple unsubscribe links that have the same vulnerability you cite here. Mailgun, which is my preferred service, has the same system of just creating unique links per user.

In the case of Mailchimp, they sometimes have a "confirm your email" form before you can actually unsubscribe, and they also optionally send out an "Unsubscribe successful" notification, but only the latter adds any layer of security, and it's… probably going to annoy users.

To editorialize a bit, email is a bit of a hellscape overall (one example is the lack of standardization in HTML email), and I think this problem of links in emails never quite being private is just one manifestation of that.

Why the mailto solution is imperfect: Email proxies

bhorkarg's answer is good, but it wouldn't work for all users — me included — because of the use of replaceable proxy email addresses.

I use proxy email addresses so that I only have to use one Gmail account from which to send and receive email — work, personal, project-based, or otherwise. I do this by using improvmx.com to forward emails sent to certain addresses, but there are lots of email forwarding services out there like it.

An example of how it works: I have signed up for The New York Times newsletters using nytimes.com-{UID}@{mydomain.com} (where {UID} is a random identifier and my domain is carterpape.com) so that, if I start getting spam in my mailbox aimed at that address, I know where it leaked, and I can change my email with the Times and block all emails to the old address.

But this system doesn't mean I can easily send mail from that proxy address because it's just an address I use for receiving email. If I were to click that unsubscribe link, I would be sending them an unsubscribe request from one of the five email addresses from which I actually send mail, which would not yield a successful unsubscribe.

This is certainly an edge case — probably more of an edge case than unsubscribe link leakage — but it's just an illustration of the various problems with various measures to address the security challenge, which fundamentally is a problem with email itself.

Answer 4

The simplest solution (and this is the most common implementation, in my experience) is to send another email after the unsubscribe link is followed. That email might either be "click to confirm unsubscribing" or "click if you unsubscribed by mistake (or it wasn't you) and wish to undo it".

However, this is only making a minor security vulnerability (allowing other users to unsubscribe for you) less critical as you now need to either ignore the confirmation email or undo an attempt to unsubscribe.

In order to completely eliminate this vulnerability, you can implement an "email required" strategy as described by @bhorkarg, but this might require more user clicks (and thus more time) than the "follow this URL" strategy.