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

2016-06-10 Thread 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 -

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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 >

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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.

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

2016-06-10 Thread 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

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

2016-06-10 Thread 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

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

2016-06-09 Thread Steve Atkins
> On Jun 9, 2016, at 11:07 AM, John Levine wrote: > >>> List-Unsubcribe: >>> List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023 > >> If there is a requirement from MUA developers for an https-based >> non-interactive

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

2016-06-09 Thread John Levine
>> List-Unsubcribe: >> List-Unsubscribe-Post: mailaddr=some...@receipient.de=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

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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 >

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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

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

2016-06-09 Thread 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? > >

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

2016-06-09 Thread 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

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

2016-06-09 Thread David Hofstee
"tobias herkula" <tobias.herk...@optivo.de> 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 U

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

2016-06-09 Thread 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 I'd be happy if anyone from a large

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

2016-06-09 Thread 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