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
