Re: [mailop] "One-Click" List-Unsubscribe URIs

[Shawn K. Hall]

> You demonstrated the need for a flag day when you stated that 
> the ESPs need to give the ISPs "a hint" that things are 
> changing. Expecting every ESP to contact every ISP is ridiculous. 

No, what he said was that ESPs *could* give a hint. All RFCs and IETF
recommendations are just that - recommendations. Nobody is under any
undue influence to change the way they do things or to implement a new
feature. The only side effect is that eventually you will be outmoded by
those who do implement the new features and capabilities described in
newer recommendations.

An RFC 822 email server is perfectly able to send and receive mail
today. It will work whether or not SSL, TLS, SPF, DKIM, DMARC or
whatever the new post-facto implementations may offer. It will not have
all the same features, and some operators may *choose* to deny mail from
the server for neglecting to implement any one or all of the above, but
the recommendation stands on it's own to be implemented or ignored by
whoever opts in to using it.

That someone is pushing for more effective MUA hints for list management
isn't a bad thing, it's just got to get a lot of traction before it's
useful.

-S


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Laura Atkins]

> On Jun 10, 2016, at 12:56 PM, Bill Cole 
>  wrote:
> 
> On 10 Jun 2016, at 11:23, Laura Atkins wrote:
> 
>> In this case, having read the documents and followed the public discussions, 
>> there’s no real clear benefit. There is also a lot of expense. So that’s a 
>> problem. The benefits need to be better articulated by the people who want 
>> to make the change.
> 
> Yes, indeed: this unicorn's horn is inadequately polished.
> 
> More directly: I don't think any "One Click Unsubscribe" can be a net benefit 
> for the parties who would need to do the most work to implement and deploy 
> it. As someone whose job security is improved by the proliferation of arcane 
> external/interop email failure modes, I'm not saying that out of 
> self-interest.

The unicorn has already left the barn. Two major webmail providers are using 
the List-Unsubscribe header to place unsubscribe links in the message display 
window along with headers like To:, From:, Reply-To: and Date:

So the work has already been done to decide that having a header that shows an 
unsubscribe process is a net benefit. Most ESPs use the List-Unsubscribe 
header. Two major ISPs take that header and use it to automate unsubscribes 
mediated by the MUA. Clearly, at least some of the parties involved have 
decided its a net benefit. But the implementation isn’t standardized and there 
is some unexpected behavior happening. Thus, coming up with a clearer spec 
about what is intended is a good idea. 

But I think the work was inadequately scoped. These issues that we’re 
discussing here are obvious. Addressing them is vital both to foster 
interoperability and to drive adoption. 

>> Also in this case, there is a significant chance that the proposal will 
>> result in sub-optimal or harmful results. It is a fact that there are 
>> appliances and filters out there that follow every link in an email. 
>> Implementing a protocol where a link being followed means a user is 
>> unsubscribed immediately will result in people being unsubscribed. I 
>> understand this proposal makes whatever is automatically clicking the link 
>> append a magic token to the URL, in an effort to stop this. I think that 
>> makes the proposal overly complex and fragile.
> 
> Exactly. If a well-intentioned, prudent, and wise organization implements a 
> protocol into being an opaque "Just Do What I Want" button in a way that 
> behaves as the protocol envisions, there will be malicious, reckless, and/or 
> stupid entities deploying implementations that behave badly and/or facilitate 
> malicious use within days.

That’s what’s currently happening and was the issue this document was supposed 
to address. 

The problem is this document inadequately addresses the current issues. 
Further, it introduces new failure modes creating even more chaos.

> The result is that by hiding a complex protocol behind the face of a 
> "one-click" unsubscribe button, you create a whole new collection of subtle 
> and obscure ways that various implementations can quietly and rarely operate 
> incorrectly. Unsubs that should not occur WILL. Unsubs that should occur WILL 
> NOT. Users will expect their personal and workplace mail systems to give them 
> identical experiences of the new protocol, which mostly WILL NOT happen.

Again, this is already happening. I agree the current proposal will lead to 
more opportunities for screw up. But not doing anything is a less than adequate 
resolution. 

There does need to be clarification on how best to show an unsubscribe through 
the MUA. The current solution has problems, but consumers like it, so it’s 
presence is something we need to deal with. I’d just like to see a better 
solution. 

laura

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Bill Cole]

On 10 Jun 2016, at 11:23, Laura Atkins wrote:

In this case, having read the documents and followed the public 
discussions, there’s no real clear benefit. There is also a lot of 
expense. So that’s a problem. The benefits need to be better 
articulated by the people who want to make the change.


Yes, indeed: this unicorn's horn is inadequately polished.

More directly: I don't think any "One Click Unsubscribe" can be a net 
benefit for the parties who would need to do the most work to implement 
and deploy it. As someone whose job security is improved by the 
proliferation of arcane external/interop email failure modes, I'm not 
saying that out of self-interest.


Also in this case, there is a significant chance that the proposal 
will result in sub-optimal or harmful results. It is a fact that there 
are appliances and filters out there that follow every link in an 
email. Implementing a protocol where a link being followed means a 
user is unsubscribed immediately will result in people being 
unsubscribed. I understand this proposal makes whatever is 
automatically clicking the link append a magic token to the URL, in an 
effort to stop this. I think that makes the proposal overly complex 
and fragile.


Exactly. If a well-intentioned, prudent, and wise organization 
implements a protocol into being an opaque "Just Do What I Want" button 
in a way that behaves as the protocol envisions, there will be 
malicious, reckless, and/or stupid entities deploying implementations 
that behave badly and/or facilitate malicious use within days.


The result is that by hiding a complex protocol behind the face of a 
"one-click" unsubscribe button, you create a whole new collection of 
subtle and obscure ways that various implementations can quietly and 
rarely operate incorrectly. Unsubs that should not occur WILL. Unsubs 
that should occur WILL NOT. Users will expect their personal and 
workplace mail systems to give them identical experiences of the new 
protocol, which mostly WILL NOT happen.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 2:18 PM, Laura Atkins 
wrote:

> You demonstrated the need for a flag day when you stated that the ESPs
> need to give the ISPs “a hint” that things are changing. Expecting every
> ESP to contact every ISP is ridiculous.
>

I don't have to contact anyone. I just add the hint. If they use it, great
if not who cares -- everything continues to work as it does today. 100%
backward compatible.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Bill Cole]

On 9 Jun 2016, at 12:11, John Levine wrote:


The http specs are
quite clear that GET is not supposed to change the state on the web
server.  For that you use POST or PUT.


Not wrong...

Unfortunately, that horse died of old age a decade ago, 5 counties away 
from the former location of the barn that it escaped from, which is now 
the crumbling parking lot of a shopping mall obviated by Amazon. It's 
difficult to convince many "web developers" these days even that a 'GET' 
should at least be idempotent.


The key practical advantage of your model over the generally bad idea of 
"one-click" unsub links is that it is more resistant to casually 
careless or ignorant user error. That does not change the fact that the 
*general* idea of putting tokens in email headers that can be 
robotically used by anything/anyone with access to the unmodified 
message in transit or post-delivery to change account state (even a 
trivial 'account' like a list subscription) is intrinsically flawed. 
Mail travels too often across unencrypted links and headers aren't 
encrypted even when bodies are. This makes mail is an attractive target 
in transit and at rest, so even without any a priori motivation to unsub 
random people from random lists, the ability of a miscreant to do so 
recklessly by accident is created by "one-click" unsub links of any 
sort. A protocol like yours for combining headers thwarts that, but it 
still leaves the problem of easing the way for automating intentional 
random mischief.


There very much needs NOT to be a universal automatable standard 
mechanism that would allow every MUA author to put an "Unsubscribe" 
button on every compliant message that would not bother  users with 
handling a flock of different second-steps for different lists. I'm not 
saying unsub should ever be made objectively difficult but it SHOULD be 
a minor nuisance on the level of having a browser (or at least a 
"webview") window open and require the user to do something simple like 
acknowledging that they want to unsub an address that they either have 
to enter or confirm in munged form; e.g. Sears recently revived an 
ancient address I gave them ~20 years ago in association with a credit 
card that hasn't existed for a decade, and the unsub link (in a 7pt 
light-gray-on-white paragraph of a HTML-only message...) took me to a 
page that was much more considerate than their desperation spam. It had 
just a big, readably-formatted question (the *-munging may have been 
slightly less complete):


   Do you really want us to remove the address
   "b***-s***@s*c**.***" from our mailing list?

With "Yes" and "No" buttons: almost perfect. No password, not even a 
captcha, no need to remember precisely which address you gave to whom in 
the 90's or do header forensics to figure it out, and no risk of senders 
leaking limited-exposure addresses to harvesters. Maybe it would be nice 
to have had some options like: this list, all of a sender's lists, or 
all of the ESP's lists now and/or for all time (yes, seriously.) I also 
like some of the pages that ask why one is unsubscribing but on the 
other hand: simplicity has value.


Anyhow, my point is that unsubscribing from a list of any flavor should 
require a simple second conscious act to filter out acts of simplistic 
automation (of any motivation) or of human error. There should be 
heterogeneity in that second step so that it's never worthwhile for 
anyone to automate it into an opaque single click. The principle is the 
same one behind a "Trash" mailbox or the \Deleted flag in IMAP or 2-step 
file deletion in a GUI (i.e. "Trash" or "Recycle Bin" or "Are you sure?" 
dialogs.) The caveats are the same as well: people get annoyed by third 
steps and burdensome second steps.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Laura Atkins]

> On Jun 10, 2016, at 10:56 AM, Vick Khera  wrote:
> 
> 
> On Fri, Jun 10, 2016 at 12:17 PM, Laura Atkins  > wrote:
>> The beauty of the proposal is that you can with some cooperation of the mail 
>> user agent convert the two-click unsub into a one-click.
> 
> And the failure of this proposal is that it requires the MUA to change 
> current behavior without a clear benefit to doing so. It also means there can 
> be no partial adoption or roll out. ESPs and ISPs need to coordinate on a 
> flag day for the new changes. All of this makes it a hard sell for a lot of 
> people. 
> 
> I'm not following why there has to be a flag day for the change. I as the ESP 
> give you the ISP a hint to make something work "better" for the end user. If 
> you don't act on the hint, the unsubscribe is still possible and works just 
> fine with a second click. If I don't give you a hint, then the same happens. 
> If you do follow my hint, then the user has an optimized experience of 
> one-click unsubscribe. The other benefit is that scanners will not cause the 
> unsubscribe.


You demonstrated the need for a flag day when you stated that the ESPs need to 
give the ISPs “a hint” that things are changing. Expecting every ESP to contact 
every ISP is ridiculous. 

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 12:17 PM, Laura Atkins 
wrote:

> The beauty of the proposal is that you can with some cooperation of the
> mail user agent convert the two-click unsub into a one-click.
>
>
> And the failure of this proposal is that it requires the MUA to change
> current behavior without a clear benefit to doing so. It also means there
> can be no partial adoption or roll out. ESPs and ISPs need to coordinate on
> a flag day for the new changes. All of this makes it a hard sell for a lot
> of people.
>

I'm not following why there has to be a flag day for the change. I as the
ESP give you the ISP a hint to make something work "better" for the end
user. If you don't act on the hint, the unsubscribe is still possible and
works just fine with a second click. If I don't give you a hint, then the
same happens. If you do follow my hint, then the user has an optimized
experience of one-click unsubscribe. The other benefit is that scanners
will not cause the unsubscribe.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[John Levine]

>I also am not 100% in agreement that "GET" for HTTP means no altering of
>state. I think that's a recent convention coming over from REST based APIs.

See section 12.2 of RFC 1945, published over 20 years ago:

12.2  Safe Methods

   The writers of client software should be aware that the software
   represents the user in their interactions over the Internet, and
   should be careful to allow the user to be aware of any actions they
   may take which may have an unexpected significance to themselves or
   others.

   In particular, the convention has been established that the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, in a
   special way, so that the user is made aware of the fact that a
   possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Laura Atkins]

> On Jun 10, 2016, at 9:07 AM, Vick Khera  wrote:
> 
> 
> On Fri, Jun 10, 2016 at 11:23 AM, Laura Atkins  > wrote:
> Also in this case, there is a significant chance that the proposal will 
> result in sub-optimal or harmful results. It is a fact that there are 
> appliances and filters out there that follow every link in an email. 
> Implementing a protocol where a link being followed means a user is 
> unsubscribed immediately will result in people being unsubscribed. I 
> understand this proposal makes whatever is automatically clicking the link 
> append a magic token to the URL, in an effort to stop this. I think that 
> makes the proposal overly complex and fragile.
> 
> 
> I kind of like Tobias' proposal (not just because we've thrown back a lot of 
> beers...)
> 
> The way I interpret it is that naive and current filters will just follow the 
> URL as-is. The anchor will just be mostly ignored by the landing page, where 
> you would normally then have to click a "confirm" button on that page. If, 
> however, your ISP (or mail user agent) detects this magick one-click anchor 
> and rewrites it for the user to click with the params appended, then it 
> becomes converted into a one-click unsubscribe by the landing page. The key 
> is that the automated scanning stuff will (and should) not do any rewriting. 
> If some filter scanner decides to do the rewrite then all bets are off, and 
> they should be punched in the face :)

There are a lot of things filtering scanners do that deserve a punch in the 
face. (Like, for instance, following COI links and then listing the sender on a 
blacklist when they’re done.)

But having the anchor added by the MUA / ISP is fragile. It also means that 
code needs to be rewritten on both ends - the ESP and the ISP. There are other 
ways to do this. People here have suggested them.  

> The beauty of the proposal is that you can with some cooperation of the mail 
> user agent convert the two-click unsub into a one-click.

And the failure of this proposal is that it requires the MUA to change current 
behavior without a clear benefit to doing so. It also means there can be no 
partial adoption or roll out. ESPs and ISPs need to coordinate on a flag day 
for the new changes. All of this makes it a hard sell for a lot of people. 

> I also am not 100% in agreement that "GET" for HTTP means no altering of 
> state. I think that's a recent convention coming over from REST based APIs.


That’s something for the more technical audience to argue, I’m not the person 
to do it. But from my reading of the RFCs GET is absolutely the wrong verb to 
use. 

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 11:23 AM, Laura Atkins 
wrote:

> Also in this case, there is a significant chance that the proposal will
> result in sub-optimal or harmful results. It is a fact that there are
> appliances and filters out there that follow every link in an email.
> Implementing a protocol where a link being followed means a user is
> unsubscribed immediately will result in people being unsubscribed. I
> understand this proposal makes whatever is automatically clicking the link
> append a magic token to the URL, in an effort to stop this. I think that
> makes the proposal overly complex and fragile.
>
>
I kind of like Tobias' proposal (not just because we've thrown back a lot
of beers...)

The way I interpret it is that naive and current filters will just follow
the URL as-is. The anchor will just be mostly ignored by the landing page,
where you would normally then have to click a "confirm" button on that
page. If, however, your ISP (or mail user agent) detects this magick
one-click anchor and rewrites it for the user to click with the params
appended, then it becomes converted into a one-click unsubscribe by the
landing page. The key is that the automated scanning stuff will (and
should) not do any rewriting. If some filter scanner decides to do the
rewrite then all bets are off, and they should be punched in the face :)

The beauty of the proposal is that you can with some cooperation of the
mail user agent convert the two-click unsub into a one-click.

I also am not 100% in agreement that "GET" for HTTP means no altering of
state. I think that's a recent convention coming over from REST based APIs.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Laura Atkins]

> On Jun 10, 2016, at 4:10 AM, tobias.herk...@optivo.de wrote:
> 
>> I think it is an insufficient solution that potentially allows a
>> security device developer or service to build one click URLs just as
>> easily as the ISP could. So it's got two things that I don't like.
>> 1- You're requiring the ISP to identify and include a token in the URL
>> - I don't think they should have to build something.
>> 2- What's being built is just as easily added in by any security
>> device who decides they know better than the subscriber and want to
>> cause that unsubscribe.
>> 
>> Cheers,
>> Al Iverson
> 
> With these arguments you can shoot down everything, SPF, DKIM, DMARC...
> I'm not even trying to solve intended malicious behavior because it is
> much more complex and I don't want to pick up a fight right now, I'm
> simply not in the position to do that. The ORT session requirement or
> question never wanted to solve this completely different issue at all.

But when implementing a solution, whatever solution that may be, MUST look at 
the full issue. This includes looking at interoperation with current protocols 
and interoperation with current practices. It also includes looking at how the 
solution could be broken in ways that result in a sub-optimal or harmful 
result. 

The current proposal requires multiple parties (ISPs and ESPs using the 
List-Unsubscribe header) to change what they’re doing now. New proposals that 
require change are not unheard of, but if people and companies are going to 
invest resources into changing current behavior there needs to be a very clear 
benefit. 

In this case, having read the documents and followed the public discussions, 
there’s no real clear benefit. There is also a lot of expense. So that’s a 
problem. The benefits need to be better articulated by the people who want to 
make the change. 

Also in this case, there is a significant chance that the proposal will result 
in sub-optimal or harmful results. It is a fact that there are appliances and 
filters out there that follow every link in an email. Implementing a protocol 
where a link being followed means a user is unsubscribed immediately will 
result in people being unsubscribed. I understand this proposal makes whatever 
is automatically clicking the link append a magic token to the URL, in an 
effort to stop this. I think that makes the proposal overly complex and 
fragile. 

As well, I often use the “list-unsubscribe” header to unsubscribe from certain 
emails. Why? Because I know that in many / most cases this header is handled by 
the MTA or the ESP. It is not a “normal” unsubscribe. So if I have had problems 
with an unsubscribe being respected, I try that. (I’ve also been known to send 
mail back to the bounce address in truly egregious situations). Having to 
append a token would break this functionality for me, and people like me, who 
use the List-Unsubscribe header. 

Overall, I don’t think the proposal, as written, addresses the underlying issue 
and introduces a number of opportunities for failure or sub-optimal results. 

I do believe there needs to be a way to mechanically handle unsubscribes, that 
can be used by automated systems and individuals. I don’t think the current 
proposal encompasses that goal. It is fragile and it is complex. What’s more, 
it silently (to the end user) changes current behavior. This is a recipe for a 
failed protocol. 

> Every other solution that came up in this discussion, run down to
> possible pathes:
> 
> 1# much more complex idea, that tries to solve a lot more than the
> initial question asked for…

The initial question was, IMO, overly simplistic. It didn’t encompass the full 
scope of what was needed. When that happens, creating something that does 
address the full scope is often a better answer than just looking at the narrow 
and simplistic case. 

> 2# leaving the situation like it is right now without changing anything

Making a change to s protocol that leaves it more fragile and more complex and 
more prone to undesired behavior is better than not changing it. 

I know how frustrating it can be to try and shepherd some of these issues 
through a group. One of my projects took 4 years and multiple restarts as we 
figured out we’d missed something in the initial question and had to go back 
and rescope and reassess. 

There is a need for automated unsubscribe process. The proposal, as it stands 
currently, is not a good change. I do not think it will have a good chance of 
being adopted. It would be easier to get it adopted if the issues brought up 
here were assessed and addressed. Wearing people down to get them to stop 
objecting leads to problems in a protocol that become obvious in a few years 
but no one wants to fix because it was so hard to get a consensus in the first 
place. 

Let’s try and get a viable solution done, rather than sticking bubble gum in 
the hole and hoping no one notices the leaks. 

laura 

-- 
Having an Email Crisis?  800 82

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Kurt Andersen (b)]

On Fri, Jun 10, 2016 at 7:10 AM,  wrote:

> The ORT session requirement or
> question never wanted to solve this completely different issue at all.
>
> Every other solution that came up in this discussion, run down to
> possible pathes:
>
> 1# much more complex idea, that tries to solve a lot more than the
> initial question asked for...
>
> 2# leaving the situation like it is right now without changing anything
>

These statements are complete non sequiturs in the discussion. M3AAWG Open
Roundtable topics are (almost by definition) poorly formed, nascent ideas
that need to be refined and discussed into something useful. How they are
originally stated is unimportant.

Changes to specs (as this is) need to pass the much higher bar of 1) doing
something useful, and 2) doing it in a reasonable way.

I'm in complete agreement with John's suggestions that POST needs to be the
operative verb and that the additional parameters should be specified in a
related header field.

--Kurt
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[tobias.herkula]

On Thu, 9 Jun 2016 13:02:05 -0400
Al Iverson  wrote:

> On Thu, Jun 9, 2016 at 12:24 PM,   wrote:
> > On Thu, 9 Jun 2016 11:53:16 -0400
> > Al Iverson  wrote:
> >
> >> This also brings us back to the issue of what happens when security
> >> devices or services click the link, instead of the subscriber. In
> >> this scenario, it sounds like it would cause an unsubscribe that
> >> was not actually requested by the recipient. I think that is
> >> suboptimal.
> >
> > No it doesn't, the solution described in the document especially
> > solves this issue.
> 
> I think it is an insufficient solution that potentially allows a
> security device developer or service to build one click URLs just as
> easily as the ISP could. So it's got two things that I don't like.
> 1- You're requiring the ISP to identify and include a token in the URL
> - I don't think they should have to build something.
> 2- What's being built is just as easily added in by any security
> device who decides they know better than the subscriber and want to
> cause that unsubscribe.
> 
> Cheers,
> Al Iverson

With these arguments you can shoot down everything, SPF, DKIM, DMARC...
I'm not even trying to solve intended malicious behavior because it is
much more complex and I don't want to pick up a fight right now, I'm
simply not in the position to do that. The ORT session requirement or
question never wanted to solve this completely different issue at all.

Every other solution that came up in this discussion, run down to
possible pathes:

1# much more complex idea, that tries to solve a lot more than the
initial question asked for...

2# leaving the situation like it is right now without changing anything


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Steve Atkins]

> On Jun 9, 2016, at 11:07 AM, John Levine  wrote:
> 
>>> List-Unsubcribe: 
>>> List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023
> 
>> If there is a requirement from MUA developers for an https-based 
>> non-interactive unsubscribe - and
>> researching whether that's the case and what their actual requirements are 
>> would be the first step - then I'm
>> sure the IETF would be open to a standard to include that metadata in an 
>> email, outside the RFC 2369 set of
>> headers.
> 
> When you click the spam button in gmail, it often asks whether you
> want to unsubscribe as well as mark it as spam.  That seems like
> a pretty strong use case for this.

But also an argument that the existing List-Unsubscribe system - which is what 
Gmail use for that - is good enough for that use case.

Something better defined would be better, but List-Unsubscribe using mailto: 
URLs is working fine for non-interactive unsubscription today.

> 
>> A new RFC, or an extension of RFC 2369 to add a new List-Something header 
>> would make the whole idea cleaner
>> and more robust than imposing structure on the existing List-Unsubscribe 
>> process, and wouldn't have much
>> significant impact on rollout (as it doesn't change significantly the amount 
>> of new code needing to be
>> deployed at both ends of the protocol to support it).
> 
> That was my thought.

Yup. If this were done properly - as a well-designed protocol rather than a 
gross hack - it'd be a useful thing to work on.

> 
>> [2] I like the idea of an MUA with a "meh" button that asks list senders to 
>> send less meh mail, or
>> unsubscribe me if they can't manage that.
> 
> I doubt there are enough mailers that would interpret that reasoanbly
> to be worthwhile.  The ESPs I know don't think they send any meh mail.

User preference modeling and targeting is huge in other areas. It's what Amazon 
and Netflix are based on, for instance. I suspect that smart email marketers 
would jump at the idea (and the smart ones tend to be successful and 
influential). Whether the MUA developers would care is a whole other thing.

Cheers,
  Steve
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[John Levine]

>> List-Unsubcribe: 
>> List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023

>If there is a requirement from MUA developers for an https-based 
>non-interactive unsubscribe - and
>researching whether that's the case and what their actual requirements are 
>would be the first step - then I'm
>sure the IETF would be open to a standard to include that metadata in an 
>email, outside the RFC 2369 set of
>headers.

When you click the spam button in gmail, it often asks whether you
want to unsubscribe as well as mark it as spam.  That seems like
a pretty strong use case for this.

>A new RFC, or an extension of RFC 2369 to add a new List-Something header 
>would make the whole idea cleaner
>and more robust than imposing structure on the existing List-Unsubscribe 
>process, and wouldn't have much
>significant impact on rollout (as it doesn't change significantly the amount 
>of new code needing to be
>deployed at both ends of the protocol to support it).

That was my thought.

>[2] I like the idea of an MUA with a "meh" button that asks list senders to 
>send less meh mail, or
>unsubscribe me if they can't manage that.

I doubt there are enough mailers that would interpret that reasoanbly
to be worthwhile.  The ESPs I know don't think they send any meh mail.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Shawn K. Hall]

+1. This was what I was thinking when I read it, too.

-S
 

> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of 
> John Levine
> Sent: Thursday, June 09, 2016 09:11
> To: mailop@mailop.org
> Cc: tobias.herk...@optivo.de
> Subject: Re: [mailop] "One-Click" List-Unsubscribe URIs
> 
> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkul
> a-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: <https://www.spammersr.us/unsub/2908duskejs>
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Al Iverson]

On Thu, Jun 9, 2016 at 12:24 PM,   wrote:
> On Thu, 9 Jun 2016 11:53:16 -0400
> Al Iverson  wrote:
>
>> This also brings us back to the issue of what happens when security
>> devices or services click the link, instead of the subscriber. In this
>> scenario, it sounds like it would cause an unsubscribe that was not
>> actually requested by the recipient. I think that is suboptimal.
>
> No it doesn't, the solution described in the document especially solves
> this issue.

I think it is an insufficient solution that potentially allows a
security device developer or service to build one click URLs just as
easily as the ISP could. So it's got two things that I don't like.
1- You're requiring the ISP to identify and include a token in the URL
- I don't think they should have to build something.
2- What's being built is just as easily added in by any security
device who decides they know better than the subscriber and want to
cause that unsubscribe.

Cheers,
Al Iverson



--
Al Iverson
www.aliverson.com
(312)725-0130

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Steve Atkins]

> On Jun 9, 2016, at 9:11 AM, John Levine  wrote:
> 
>> It's a public document and I welcome requests with updates...
>> https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
> List-Unsubcribe: 
> List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.

+1.

(recycling my comments from the last time this was suggested, in a different 
forum)

List-Unsubscribe: is poorly defined (at least for http links) yet widely 
supported. mailto: links are for non-interactive use, http: links are (almost 
always) for interactive use. Any attempt to change that risks causing problems 
with a deployed base - it's not a versioned nor extensible protocol. Extending 
the behaviour with hidden magic doesn't seem like a clean solution to the 
problem, even if the magic "shouldn't" cause any problems with existing code[1].

If there is a requirement from MUA developers for an https-based 
non-interactive unsubscribe - and researching whether that's the case and what 
their actual requirements are would be the first step - then I'm sure the IETF 
would be open to a standard to include that metadata in an email, outside the 
RFC 2369 set of headers.

A new RFC, or an extension of RFC 2369 to add a new List-Something header would 
make the whole idea cleaner and more robust than imposing structure on the 
existing List-Unsubscribe process, and wouldn't have much significant impact on 
rollout (as it doesn't change significantly the amount of new code needing to 
be deployed at both ends of the protocol to support it).

That also opens up the option of implementing what MUA developers and list 
operators can agree on as a useful protocol rather than a single feature wedged 
into an existing one. As I'm not a list operator or an MUA developer I don't 
have particular things I'd want there, but I can imagine "send me no more mail 
like this / remove me from this list", "send me no more mail at all / suppress 
me from all lists" and maybe even "send me less mail like this"[2] as some 
possibilities.

Cheers,
 Steve

[1] Assuming that ad-hoc clients will strip off URL fragments or that servers 
will ignore them if they don't is reasonable in a spec sense, but may be 
optimistic when it comes to deployed code.

[2] I like the idea of an MUA with a "meh" button that asks list senders to 
send less meh mail, or unsubscribe me if they can't manage that.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[tobias.herkula]

On 9 Jun 2016 16:11:17 -
"John Levine"  wrote:

> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: 
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

I'm not a friend of "new" Headers and I can't really see why this
document will change any meaning of the standard, RFC2369 already
states:

"Each field typically contains a URL (usually mailto [RFC2368])
locating the relevant information or performing the command directly."

and

"The List-Unsubscribe field describes the command (preferably using
mail) to directly unsubscribe the user (removing them from the list)."

So it doesn't change any meaning of the standard, I'm aware of the fact
that there are entities out in the net that handle this differently but
the standard is pretty clear.

The document describes how to signal this functionality to make sure
the receiver knows that this link can be used as a "oneclick" and it
also hinders "dump" clients who simple GET every link to trigger the
action.

I'm sure we should argue about the GET vs. POST thing as this is for
sure very difficult to solve, if we stick by RFC you are totally right,
POST, PUT or even DELETE are the right verbs to use. I would rule out
PUT and DELETE because not every lib implements it. On the other side,
every tracking link in commercial mails changes STATE and they are
never requested by POST...


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[tobias.herkula]

On Thu, 9 Jun 2016 11:53:16 -0400
Al Iverson  wrote:

> This also brings us back to the issue of what happens when security
> devices or services click the link, instead of the subscriber. In this
> scenario, it sounds like it would cause an unsubscribe that was not
> actually requested by the recipient. I think that is suboptimal.
> 
> Regards,
> Al Iverson
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

No it doesn't, the solution described in the document especially solves
this issue.


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[John Levine]

>It's a public document and I welcome requests with updates...
>https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt

Hmmn.  One the one hand, I'm definitely in favor of making it as easy
as possible for people to make the mail go away.

On the other hand, this particular proposal is a horrible misuse of
both http GET and of the list-unsubscribe header.  The http specs are
quite clear that GET is not supposed to change the state on the web
server.  For that you use POST or PUT.  It is also a bad idea to try
to redefine the List-Unsubscribe header which has meant the same thing
for 18 years.

Fortunately, this is not hard to fix.  Let's invent a new header,
list-unsubscribe-post, which one can use in conjunction with
list-unsubscribe, e.g.

 List-Unsubcribe: 
 List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023

This says to do a POST to the URL in the list-unsubscribe, with the
fields in the list-unsubscribe-post as the data to the POST.  MUAs
that don't understand the new field can still do a GET to the URL
which will do whatever it does, probably show you a page with a
confirmation button that does a POST.

This should be easy to implement, since I've never seen an http
library that could do GET that can't also do POST, and this avoids
both the semantic problem of GET, and the unintended unsubs by
filterware that poke all the URLs just to see what will happen.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Al Iverson]

This also brings us back to the issue of what happens when security
devices or services click the link, instead of the subscriber. In this
scenario, it sounds like it would cause an unsubscribe that was not
actually requested by the recipient. I think that is suboptimal.

Regards,
Al Iverson

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[tobias.herkula]

On Thu, 09 Jun 2016 14:30:29 +0200
Dave Warren  wrote:

> On 2016-06-09 12:23, David Hofstee wrote:
> > Same here, auto-unsubscribe presumed. The https is a nice addition 
> > that I will pass along. I hope that all implementations can handle 
> > https. Did people verify?
> >
> > I treat it nearly as strict as a feedbackloop. All streams (of my 
> > customer X) to the recipient will cease permanently. I cannot
> > expect Gmail (or others) to differentiate between specific
> > permissions that my customer uses and filter accordingly.
> 
> As a user, I like the idea of a HTTPS page that shows all lists to
> which I was subscribed, clearly indicates that I have been removed
> from all, but also has a one-more-click to resubscribe to specific
> lists if I desire.
> 
> A bit more complex, and I think the user expectation is that you'll
> be completely unsubscribed from all marketing drivel with one click,
> but in cases where there are clearly differentiated lists, it's nice
> to expose that to the user and give them a chance to reconsider.
> 

The view here is a little bit different, I don't really care what
happens in the body of the mails my customers send out, as long as they
don't violate our content policy or the law. So Links to preference
pages and all this stuff is fine there.

The document is more suited for functionality where the function should
be integrated into the MUA, like Googles "Easy Unsubscribe", in these
cases I would expect, that the platform provider doesn't want to show
external content and still needs a way to find out if the unsubscribe
worked.

#1 You could simply state as a platform provider that you expect that
   those links are "one-click" and give a penalty to senders who don't
   comply...

#2 You could use this pattern and be sure that the links are "one-click"

The second approach, in my opinion, is the easier way to implement this
feature, if you already settled on the idea to give your users a
unsubscribe button in your MUA.

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Dave Warren]

On 2016-06-09 12:23, David Hofstee wrote:
Same here, auto-unsubscribe presumed. The https is a nice addition 
that I will pass along. I hope that all implementations can handle 
https. Did people verify?


I treat it nearly as strict as a feedbackloop. All streams (of my 
customer X) to the recipient will cease permanently. I cannot expect 
Gmail (or others) to differentiate between specific permissions that 
my customer uses and filter accordingly.


As a user, I like the idea of a HTTPS page that shows all lists to which 
I was subscribed, clearly indicates that I have been removed from all, 
but also has a one-more-click to resubscribe to specific lists if I desire.


A bit more complex, and I think the user expectation is that you'll be 
completely unsubscribed from all marketing drivel with one click, but in 
cases where there are clearly differentiated lists, it's nice to expose 
that to the user and give them a chance to reconsider.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[David Hofstee]

Same here, auto-unsubscribe presumed. The https is a nice addition that I will 
pass along. I hope that all implementations can handle https. Did people 
verify? 

I treat it nearly as strict as a feedbackloop. All streams (of my customer X) 
to the recipient will cease permanently. I cannot expect Gmail (or others) to 
differentiate between specific permissions that my customer uses and filter 
accordingly. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 


Van: "Gil Bahat via mailop"  
Aan: "tobias herkula"  
Cc: mailop@mailop.org 
Verzonden: Donderdag 9 juni 2016 11:40:56 
Onderwerp: Re: [mailop] "One-Click" List-Unsubscribe URIs 

FWIW I understood that the policy of large recipients is to already 'demand' 
and 'assume' that the URLs in List-Unsubscribe behave as 1-clicks and that 
mailto: links can also be triggered from backend systems. That was the 
requirement that I passed to our R&D. I'd be happy if anyone from a large 
recipient can comment on that - not sure what would happen if it didn't indeed 
function like this, or if there are separate streams and this shuts off only a 
specific stream or what happens if the users regrets unsubscribing and 
re-activates it. 
Regards, 

Gil Bahat, 
Director of Online Operations, 
Magisto Ltd. 

On Thu, Jun 9, 2016 at 12:32 PM, < tobias.herk...@optivo.de > wrote: 


Hi List, 

I'm working on a document about a topic that came out of an open 
roundtable discussion at M³AAWG, it is more or less a way for mail 
senders to signal that a URI in the List-Unsubscribe Header has 
"One-Click" functionality and therefore can be triggered by backend 
systems to provide MUA users a better way to unsubscribe from bulk 
commercial mail that is reputable enough. 

We as an ESP implemented it for our customers so if you are curious 
about it, there is a chance that you already getting traffic with this 
feature enabled. 

I'm writing here because I'm looking for more input about it and if it 
interesting enough for ISPs or MUA provider. 

It's a public document and I welcome requests with updates... 
https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt 

For people on the road a copy of the document is attached to this 
mail... 


Kind regards, 

/ Tobias Herkula 

-- 
optivo GmbH 
Head of Deliverability & Abuse Management 
Wallstraße 16 
10179 Berlin 
Germany 

Tel: +49(0)30-768078-129 
Fax: +49(0)30-768078-499 

Email: mailto: t.herk...@optivo.com 
Website: http://www.optivo.com 
Linkedin: http://www.linkedin.com/in/tobiasherkula 

Commercial register: HRB 88738 District Court Berlin-Charlottenburg 
Executive board: Dr. Rainer Brosch, Thomas Diezmann 
Vat reg. no.: DE813696618 

optivo A company of Deutsche Post DHL Group 

___ 
mailop mailing list 
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 






___ 
mailop mailing list 
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Gil Bahat via mailop]

FWIW I understood that the policy of large recipients is to already
'demand' and 'assume' that the URLs in List-Unsubscribe behave as 1-clicks
and that mailto: links can also be triggered from backend systems. That was
the requirement that I passed to our R&D. I'd be happy if anyone from a
large recipient can comment on that - not sure what would happen if it
didn't indeed function like this, or if there are separate streams and this
shuts off only a specific stream or what happens if the users regrets
unsubscribing and re-activates it.

Regards,

Gil Bahat,
Director of Online Operations,
Magisto Ltd.

On Thu, Jun 9, 2016 at 12:32 PM,  wrote:

> Hi List,
>
> I'm working on a document about a topic that came out of an open
> roundtable discussion at M³AAWG, it is more or less a way for mail
> senders to signal that a URI in the List-Unsubscribe Header has
> "One-Click" functionality and therefore can be triggered by backend
> systems to provide MUA users a better way to unsubscribe from bulk
> commercial mail that is reputable enough.
>
> We as an ESP implemented it for our customers so if you are curious
> about it, there is a chance that you already getting traffic with this
> feature enabled.
>
> I'm writing here because I'm looking for more input about it and if it
> interesting enough for ISPs or MUA provider.
>
> It's a public document and I welcome requests with updates...
> https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
>
> For people on the road a copy of the document is attached to this
> mail...
>
>
> Kind regards,
>
> / Tobias Herkula
>
> --
> optivo GmbH
> Head of Deliverability & Abuse Management
> Wallstraße 16
> 10179 Berlin
> Germany
>
> Tel: +49(0)30-768078-129
> Fax: +49(0)30-768078-499
>
> Email:mailto:t.herk...@optivo.com
> Website:  http://www.optivo.com
> Linkedin: http://www.linkedin.com/in/tobiasherkula
>
> Commercial register: HRB 88738 District Court Berlin-Charlottenburg
> Executive board: Dr. Rainer Brosch, Thomas Diezmann
> Vat reg. no.: DE813696618
>
> optivo A company of Deutsche Post DHL Group
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] "One-Click" List-Unsubscribe URIs

[tobias.herkula]

Hi List,

I'm working on a document about a topic that came out of an open
roundtable discussion at M³AAWG, it is more or less a way for mail
senders to signal that a URI in the List-Unsubscribe Header has
"One-Click" functionality and therefore can be triggered by backend
systems to provide MUA users a better way to unsubscribe from bulk
commercial mail that is reputable enough.

We as an ESP implemented it for our customers so if you are curious
about it, there is a chance that you already getting traffic with this
feature enabled.

I'm writing here because I'm looking for more input about it and if it
interesting enough for ISPs or MUA provider.

It's a public document and I welcome requests with updates...
https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt

For people on the road a copy of the document is attached to this
mail...


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group
INFORMATIONAL Tobias Herkula
draft-herkula-oneclick.txt   optivo GmbH
   June 2016


   Signaling "One-Click" functionality for HTTPS URIs in email headers

Status of this Memo

   This document is not an Internet Standards Track specification; it is
   for informational purposes and requests discussion and suggestions
   for improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) Tobias Herkula (2016).  All rights reserved.

Abstract

   This document describes a simplified method for signaling "One-Click"
   functionality for HTTPS URIs as they appear in email headers.  The
   need for this arises out of the fact, that third-party entities
   involved in the processing of emails sometimes unintendedly trigger
   actions that are subject to the user and shall not be triggered
   automatically without an user's intent.

1.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   a.  "One-Click":  In the context of this document, describes an HTTPS
   URI that directly triggers a change in a system that shall only
   be applied if the request to that HTTPS URI is done with an
   user's intent.

   b.  "Organizational Domain":  Is to be interpreted as described in
   [RFC7489#section-3]

   c.  "Domain Alignment":  In the context of this document, means that
   two domains share the same organizational domain.

   d.  "signal-constant": fixed string "=One-Click"

2.  Introduction

   An email header can contain HTTPS URIs for extended functionality,
   for example List-Headers [RFC2369].  In case of the List-Unsubscribe
   Header the HTTPS URI is mandated to unsubscribe the recipient of the
   email directly from the list.  This requirement is often not
   implemented because anti-spam solutions request all found external
   resources, this is considered unintended malicious behavior. In
   consequence senders implement landing pages asking to confirm the
   unsubscribe request.  This specification tries to solve one part of
   this, as it proposes a pattern to detect "One-Click" functionality.
   It defines a specific format for the fragment part of a HTTPS URI and
   a specific transformation for the receiver. A request to the
   transformed HTTPS URI from somebody who adheres to this specification
   can be distinguished from other requests and therefore handled
   independently.

3.  High-Level Goals

   o  Allow email senders to signal "One-Click" functionality for
  specific HTTPS URIs used in email headers.

   o  Allow MUA owners to implement independent user interface features
  for a better user experience.

   o  Allow MUA users to trigger intended actions in a familiar
  environment.

4.  Out of Scope

   This proposal does not solve problems associated with intended
   malicious behavior by users or robots.

5.  Implementation

5.1  Sender

   A sending entity which is responsible for the content of an email,
   that wishes to add an actionable HTTPS URI in the header of an email,
   shall add the name of the Header followed by signal-constant, as the
   URI fragment. The sending entity also needs to provide the infrastructure
   to handle GET and or POST requests to this URI in an appropriate volume.

   The "One-Click" action triggered by such URIs must complete in an appropriate
   timeframe and