Subject: [dispatch] "One-Click" List-Unsubscribe URIs

From: "John R Levine" <[email-masked]>
Date: 10 Jul 2016 13:26:21 -0400

See https://datatracker.ietf.org/doc/draft-levine-herkula-oneclick/

The List-Unsubscribe header defined in RFC 2369 has been around for almost 
20 years, and is quite well supported by bulk mail senders.  Originally it 
was mostly mailto: URIs, but now it's mostly http and https.

It shouldn't surprise you to learn that some mail filtering software 
fetches all of the http and https in incoming mail, including the ones in 
list-unsubscribe, to see if it leads to something malicious.  The server 
on the other end can't tell whether a request was from a user wanting to 
unub or just the filtering software, so the landing pages now typically 
ask if you're sure and have a confirmation button you have to click.

That's fine for humans, but not so great for mail systems that want to 
integrate unsub into spam reporting.  For example, when you click the spam 
button in Gmail, if it sees a plausible list-unsubscribe, it asks whether 
you want to unsub as well as marking the message as spam.  I gather some 
other systems have long sent unsubs on spam reports without even telling 
the user (but without any complaints, either.)  In an automated system 
there's no reasonable* way to click that second button, so mail providers 
would really like an unsub that isn't interactive and isn't mailto:.

Tobias Herkula from Optivo (the e-mail part of DHL) and I came up with a 
draft that adds list-unsubscribe-post, which defines a POST operation for 
list-unsubscribe that is intended to do the job without further 
interaction.** Having talked to some people from large mail providers, 
there's a great deal of interest in this. History tells us that bulk mail 
senders will do whatever large recipient systems want them to do, so it 
would be nice to have a standard spec they can point to so it all works 
the same way.

I don't see anything contentious here. List-unsubscribe has been around 
forever and this is just a twiddle to add another flavor of it.  Comments 
and suggestions welcome from anyone who's read the draft.

R's,
John

* - I've heard of systems that try to parse the resulting page from a 
regular unsubscribe and guess which button to press, but if you've seen 
the range of landing pages, that way lies madness.

** - No doubt some overeager filter systems will do POSTs, too, but you 
can only do so much.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jul 2016 11:20:24 +1000

Rather than add new headers to the mail message, why not add a link
relation to the header fields of the HTTP resource.

<Email: List-Unsubscribe: https://example.com/unsub?foo

HTTP> HEAD /unsub?foo
Host: example.com

<HTTP 200 OK
Link: </unsub?foo>;rel=list-unsubscribe-post

HTTP> POST /unsub?foo
Host: example.com
Content-Length: 0

<HTTP 200 OK

...
Why does the POST need a content-type of application/x-www-form-urlencoded?

On 11 July 2016 at 03:26, John R Levine <[email-masked]> wrote:
> It shouldn't surprise you to learn that some mail filtering software fetches
> all of the http and https in incoming mail, including the ones in
> list-unsubscribe, to see if it leads to something malicious.  The server on
> the other end can't tell whether a request was from a user wanting to unub
> or just the filtering software, so the landing pages now typically ask if
> you're sure and have a confirmation button you have to click.
>
> other systems have long sent unsubs on spam reports without even telling the
> user (but without any complaints, either.)  In an automated system there's
> no reasonable* way to click that second button, so mail providers would
> really like an unsub that isn't interactive and isn't mailto:.
>
> would be nice to have a standard spec they can point to so it all works the
> same way.
>
> regular unsubscribe and guess which button to press, but if you've seen the
> range of landing pages, that way lies madness.
>
> ** - No doubt some overeager filter systems will do POSTs, too, but you can
> only do so much.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2016 22:17:21 -0400

> relation to the header fields of the HTTP resource.

We didn't discuss that ppossibility, but the people I've talked to about 
this didn't sound like they were very interested in multiple web 
transactions to do one-click.  Also, it's not at clear how this would pass 
through the info about who to unsubscribe without generating the link 
header on the fly, which appears to be hard in some web servers.

> Why does the POST need a content-type of application/x-www-form-urlencoded?

Because it's what everyone supports.  I suppose we could say 
multipart/form-data is an option.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jul 2016 16:06:01 +1000

On 12 July 2016 at 12:17, John R Levine <[email-masked]> wrote:
> through the info about who to unsubscribe without generating the link header
> on the fly, which appears to be hard in some web servers.

The performance thing is reasonable.  The other doesn't take much
creativity to work around.

> multipart/form-data is an option.

What information are you looking to carry?  If it doesn't matter, then
say that content is empty and the content-type can be ignored.

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 09:37:24 -0400

> say that content is empty and the content-type can be ignored.

See the examples in the draft.  It's definitely not empty.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 09:38:35 -0400

Somewhat to my surprise, I just heard from one of the giant mail providers 
that they're ready to implement this, like, tomorrow.

So if we want to have meaningful input to the design as opposed to just 
scribing what somewhat else has done (which isn't always a bad thing), 
there is some urgency here.

Regards,

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 09:56:11 +1000

> See the examples in the draft.  It's definitely not empty.

I didn't read down to the examples because I was looking for a
definition of keys and associated semantics.

Somewhat orthogonally, all the kids are doing JSON nowadays.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Jul 2016 10:12:06 +1000

Worth a side meeting in Berlin?

> On 12 Jul 2016, at 11:38 PM, John R Levine <[email-masked]> wrote:
> 
> Somewhat to my surprise, I just heard from one of the giant mail providers that they're ready to implement this, like, tomorrow.
> 
> So if we want to have meaningful input to the design as opposed to just scribing what somewhat else has done (which isn't always a bad thing), there is some urgency here.
> 
> Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 20:15:05 -0400

> Somewhat orthogonally, all the kids are doing JSON nowadays.

Not in POST arguments, they're not.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 20:18:55 -0400

> Worth a side meeting in Berlin?

I'll be talking about it AOB at appsawg/dispatch.  My co-author lives in 
Berlin and I encouraged him to come.  This draft is not a big deal, either 
could go through appsawg or even as AD sponsored.

Regards,

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 10:26:24 +1000

> Not in POST arguments, they're not.

I don't follow.  POST with a JSON body runs most of the (non-GET) web.

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 21:09:26 -0400

> I don't follow.  POST with a JSON body runs most of the (non-GET) web.

That's for stuff sent from js scripts.  For stuff sent from web forms, 
it's still tags and strings.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 07:32:37 +0200

> it's still tags and strings.

Assuming I understand the context correctly, the assumption is that the
client which
dereferences this URL has to know about this specification: i.e., if it is
presented to
a current browser or other Web engine (like an HTML news reader) will try to
dereference it with GET. So, this requires special accommodations in the
client. If
so, I'm with MT about JSON being more sensible.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2016 08:37:45 +0200

>> it's still tags and strings. ...
>
> client which dereferences this URL has to know about this specification: 
> i.e., if it is presented to a current browser or other Web engine (like 
> an HTML news reader) will try to dereference it with GET. So, this 
> requires special accommodations in the client. If so, I'm with MT about 
> JSON being more sensible.

I don't understand what problem JSON is trying to solve.  The 
list-unsubscribe-post header has a simple set of labels and values, which 
directly match what you'd get from a web form, and is parsed by the web 
server code that parses web forms.  I have never seen a mailing list 
unsubscribe form (the manual kind) that uses ajax rather than a normal 
form POST.

The goal here is not to invent something new, it's to define a shortcut 
for existing two-step forms.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 08:40:30 +0200

On Mon, Jul 18, 2016 at 8:37 AM, John R Levine <[email-masked]> wrote:

>> i.e., if it is presented to a current browser or other Web engine (like an
>> HTML news reader) will try to dereference it with GET. So, this requires
>> special accommodations in the client. If so, I'm with MT about JSON being
>> more sensible.
>>
>
> unsubscribe form (the manual kind) that uses ajax rather than a normal form
> POST.
>

Yes, but as MT says, it's the lingua franca for the client side which is
programmatic, not a form.

The goal here is not to invent something new, it's to define a shortcut for
> existing two-step forms.

1. I'm not sure I think that not requiring the existing servers to change
is a particular virtue.
2. How many existing server sides will process this POST exactly as-is?

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2016 08:48:42 +0200

> 1. I'm not sure I think that not requiring the existing servers to change

I would think it is if you expect people to implement it.  In this case, 
the alternative is that mailers will say, wow, this is silly, we're not 
going to pull in an entire json parser just for this nit so we'll do it 
the other way.  The people that need to implement the server side of this 
are bulk mail providers like Mailchimp and Experian.

> 2. How many existing server sides will process this POST exactly as-is?

Most of them.  The existing GET generally sends you to a page that says 
"are you sure" with a POST to confirm.  This is intended to land in the 
same place, so all they have to change is a little bit of the argument 
checking.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 08:51:56 +0200

On Mon, Jul 18, 2016 at 8:48 AM, John R Levine <[email-masked]> wrote:

> I would think it is if you expect people to implement it.

I'm rather more interested in whether clients will implement it.

> In this case, the alternative is that mailers will say, wow, this is
> silly, we're not going to pull in an entire json parser just for this nit
> so we'll do it the other way. The people that need to implement the server
> side of this are bulk mail providers like Mailchimp and Experian.

> same place, so all they have to change is a little bit of the argument

These statements seem to contradict each other. Without any change or not?

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2016 09:00:53 +0200

> I'm rather more interested in whether clients will implement it.

The reason I'm presenting it is that Gmail tells me they're ready to 
implement it right now.

> These statements seem to contradict each other. Without any change or not?

That's not a useful question.

The existing code processes web forms.  The changes to process a slightly 
different form POST are tiny.  The changes to process json when nothing in 
the application uses json now and the existing POST handlers all parse web 
forms are not tiny.  If you're arguing that if they have to change it at 
all they might as well change it a lot, that's not a winning argument with 
the programming managers I know.

Regards,