At 04:30 14-11-2008, der Mouse wrote:
It's always seemed broken to me. Unless there's been a history of
unsub attacks or some such to justify it, I can't see any reason to
require confirmation for unsubs. Ideally it would be a
per-subscription option, since people as well as lists can have a
history of attracting the sort of people who'll forge unsubs.
It's better not to wait for the unsub attacks to prevent it from
happening. Sometimes we may take an action based on the information
we receive from a list. Without the confirmation, we would not be
aware that the information may no longer be available to us.
At 04:42 14-11-2008, Rich Kulawiec wrote:
Because spammers will quickly learn to attach RFC 2369 headers to
their messages, and will use "unsubscription" requests for anything
but that -- for example, they'll use this to confirm that addresses
are valid and that traffic to them is being read. (I'm thinking back
here to the days of Return-Receipt.)
They already do.
The bottom line is that nothing spammer-generated in a spam can be
trusted, so taking any action based on it opens the door to abuse.
Right.
At 05:18 14-11-2008, Chris Lewis wrote:
There are ways to avoid needing confirmation (or worse, passwords) that
still protect against malicious unsubscribes.
The MAAWG sender BCP talks about saying that unsubs should be a "single
action", and not require any additional information (eg: "confirmation
cycle" or password).
Each email message's unsub links should contain everything needed to do
an unsub in one action - the user doesn't need to know another password,
and then goes on to say that if malicious unsubscriptions are a concern,
that "everything" could include a magic cookie that only the recipient
of the email sees (in the link) that serves as a password for the unsubs.
Sometimes the subscriber resends the message, including full
headers. The magic cookie is then disclosed to third parties.
Regards,
-sm
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg