≡ Menu

A Standard I Would Use: Auto Unsubscribe

I don’t get a lot of spam, at least not in the traditional sense of “unsolicited commercial email”. But I do get a lot of solicitations from online retailers with whom I have done business. As we all know, even a single order can trigger weekly emails. Multiply that by all places I do business with, and I end up with a lot of unwanted emails.

Certainly, the vast majority of these companies offer an unsubscribe option, with instructions clearly marked at the bottom of the email. These instructions tend to have a URL which I click and one of three things happen:

  1. Link automatically unsubscribes me
  2. Link takes me to a web page that asks for confirmation and maybe a little survey, or a list of mailings which I can opt-in or out of.
  3. Link takes me to a login page, where I need to remember my login id, navigate to a profile and perform several other steps before I can unsubscribe. I have some mailing lists that I have never been able to unsubscribe to at all. I end up defining inbox rules to delete the mailings altogether.

The idea for a standard is this: Can we encode these unsubscribe mechanisms, or at least the first two mechanisms, in a standard way in the mail message itself, so that an email client can allow the user to simply push a button and activate the unsubscribe procedure? If done right, I could even be in my inbox view and select several emails and unsubscribe to those lists all at once. Ideally no further user interaction would be required. And certainly I want to avoid the requirement to hunt through an email for the unsubscribe link.

Since emails can come in a variety of formats, from text, to HTML to RTF, it might make sense to handle this in the mail headers rather than the email body itself.

Of course, we want this to be simple and declarative and not require general-purpose scripting support, for simplicity and security reasons.

I think this would be a relatively simple standard to create. We just need some conventions for an email to declare a RESTful API for unsubscribing to a list.

Of course, maybe there is something like this already out there?

{ 8 comments… add one }
  • derek 2009/08/19, 08:11

    You misunderstand the model.

    The sender doesn't WANT you to unsubscribe. They have a vested interest in keeping the process as complicated as legally permitted. There are standards for mailing list headers (the List-* headers) one of which is about unsubscription, but at the end of the day, none of the bulk-mailers care because they don't make money off of you if you unsubscribe.

  • Luis Villa 2009/08/19, 09:10
  • Anonymous 2009/08/19, 09:29

    Pete Austin said:

    Probably the closest thing to a public standard is to reply with "unsubscribe" in the subject.

    The immediate problem with a REST API is that email is implemented via a special-purpose mail-server and not a Webserver. Bots for spam, or MTAs (Mail Transfer Agents) for legitimate bulk email. Neither of these is really equipped to run a Website. So you're probably actually talking about a standard API onto the mailer's click-through servers. I'll give this some thought.

    @derek Legitimate senders do want you to unsubscribe, because the alternatives are worse. Either you use a "report as spam" button (which damages reputation), or you blackhole the emails with a mail rule (which wastes everyone's resources).

  • Anonymous 2009/08/19, 10:08
  • Gary McGath 2009/08/19, 10:20

    The term "unsubscribe" implies that I have subscribed. If I haven't, it's spam. When spammers include an "unsubscribe" feature, it really means "This sucker has confirmed receipt of mail."

    I do, however, implement auto-boycott of spammers.

  • Rob 2009/08/19, 11:05

    I'm thinking here of lists that I arguably belong to, either because I opted in, or because I did business with the sender at some time. I'm not concerned with spam, deception and so on.

    It is more a question of how can we make it easier for users to unsubscribe in those situations. What conventions can we have to help automate a process that both parties wish to have available?

    It sounds like some attempts have already been made in this area.

  • Bart Hanssens 2009/08/19, 14:58

    Actually (somewhat) personalised newsfeeds would be a better model instead of emails.

    Just pull the news once a day from the vendor's website(s) using your favorite aggregator, and "unsubscribe" or "suspend" if you don't want to get the updates anymore…

  • André 2009/09/02, 16:05

    How did the good old Usenet implement that?

Leave a Comment