On 9 Jun 2016 16:11:17 -0000 "John Levine" <jo...@taugh.com> 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: <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 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
