On Thu, Nov 13, 2008 at 09:31:05PM -0500, Barry Shein wrote:
> First, there's no way for the web interface to know if the unsubscription
> request was successful -- presuming that it's submitted via the address
> specified in the RFC 2369 headers.
Is that important? Any unsubscription confirmation email should go
back to the subscriber.
Well, I'm not sure if it's important or not. But I'm concerned about
how this process will work from the user's point of view.
Some lists allow unsubscription without confirmation, and in a case
like that, a button-generated unsubscription request should work without
any further involvement of the user.
But some lists require confirmation, and in that case, the user will
need to wait for a second message, understand that it's a request for
confirmation and reply to it -- which can't be done with the button.
(That is, presuming the code behind the button is set up to process
RFC 2369 headers and not to attempt to parse the myriad formats of
unsubscription confirmation messages.)
(BTW, I think requiring confirmation is a good idea, so I'm not arguing
against that.)
> But second, and this is the much larger problem: widespread adoption of
> this will almost instantly lead to its mass exploitation by spammers.
How? Maybe I lack imagination, but why is this any more of a problem
than spammers just sending unsub etc requests now?
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.)
Or they'll cause the RFC 2369 "unsubscribe" header to point to
a "subscribe" link. Or they'll point it to unrelated third parties.
And so on.
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.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg