On 2/23/2018 3:25 PM, Grant Taylor via mailop wrote:
On 02/23/2018 12:28 PM, David Carriger wrote:
Can you tell if the URL accesses are GETs or POSTs?
Do you action on your one-click-unsubscribe based on GETs? - I thought
one-click-unsubscribe was purposefully supposed to require POSTs to
avoid inadvertent activation by things like link scanners.
Office 365 Outlook on the Web does show the user a button to
unsubscribe. I think it's triggered by the existence of a
List-Unsubscribe header, but I'm not certain. Every time I have clicked
on the button, they give a message indicating that it's not safe to
process the request (possibly due to an internal reputation model) and
recommend the user instead mark the message as spam (causing the sender
to be added to Blocked Senders)
The dilemma is that users are (or should be) afraid to click unsubscribe
links due to security concerns. They don't want their browser loading
the payload behind the URL. Furthermore, legitimate email senders have
been increasingly aggressive at sending unsolicited mailings. This
leads to a VERY high level of frustration among users.
I support the idea of a server-side facilitated unsubscribe process. It
seems that using the List-Unsubscribe-Post header as the indicator for
the server to know that they can POST unsubscribe requests on behalf of
the user is ideal.
But, what if not enough email senders adopt List-Unsubscribe-Post or
accept some other FBL mechanism for server facilitated unsubscribes?
Then, I guess, why not POST (or GET) the unsubscribe link anyway? If
the user indicated a desire for a facilitated unsubscribe, why not try?
Jesse @ UW-Madison
(I'm kind of sad to see wisc.edu isn't on the list because I know that
our users would love to see this happen.)
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
