Subject: 6. Proposals - SMTP Level Unsubscribe (was Re: [Asrg] SMTP level unsubscribe)

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 07 Aug 2003 14:29:10 -0400

At 01:17 PM 8/7/2003, Scott Nelson wrote:
>At 11:14 PM 8/6/03 -0600, John Fenley wrote:
>[edited]
> >
>.......
> >I believe piece by piece unsubscribe should be evaluated as one type of 
> spam
> >control method evaluated in the proposed simultaneous and long term
> >comparison of spam control systems.
> >
>There is an urban myth (possibly true) that unsubscribing makes the
>problem worse.

The most reliable source of information on this is a report by the US 
Department of Energy's CIAC back in 1997 (its obviously dated). The report 
can be found at (http://www.ciac.org/ciac/bulletins/i-005c.shtml) with the 
following quote:

"DO NOT Sending "remove" messages to a spammer.  It simply validates your 
e-mail address for future spammings."

I remember vaguely reading a while ago, that the Dept of Energy actually 
ran a study on this. However, the general consensus on the Internet seems 
that what unsubscribing from spam messages does is actually unknown.

The FTC implies that people should use the "Remove" link and report any 
site that refuses to honor it 
(http://www.ftc.gov/bcp/conline/pubs/online/inbox.htm):

"Let the FTC know if a "remove me" request is not honored. If you want to 
complain about a removal link that doesn't work or not being able to 
unsubcribe from a list, you can fill out the FTC's online complaint form at 
www.ftc.gov."

>.......
>I've always wondered whether unsubscribing would reduce the overall
>volume, or increase it but that's a separate topic.

I would suggest that someone here runs a large statistical study on what 
unsubscribes actually do or solicit this information from one of the 
anti-spam companies.

>I propose standardizing an SMTP level error code to mean "unsubscribe".
>I chose "578 5.7.8 Unsubscribe" which would be returned immediately
>after the RCPT command.  It could be thought of as a "that user
>does not consent to any further email from you" but I prefer
>the single word "unsubscribe".
>
>There's could also be a standardized DSN but that requires generating
>a message, which is always problematic, and has the possibility
>of forgeries associated.
>
>Pros:
>
>Legacy compatible.
>   Most existing mailing list software would interpret this as a
>   "no such user" and remove them from the mailing list.
>
>Well defined result.
>   Some list software retries, even on a permanent failure because
>   of vagaries in the mailing system.  But if you get a 578 at the
>   SMTP level, you can be certain that the user wants to unsubscribe.
>
>No extra messages.
>   Currently, a large percentage of messages that ask you to unsubscribe
>   are spam, and don't actually care about you unsubscribing.  Most
>   will never be heard from again in any event.
>
>
>
>Cons:
>
>Server only.
>   This could only be implemented at the server level, and it's not
>   particularly easy to implement unless you already implement a
>   server side foe's list.
>
>Facilitates Harvesting.
>   It's possible to collect some information about a mailbox,
>   because it will respond slightly differently when an agent
>   unsubscribes.
>
>
>
>Although a minor change to the protocol,
>I think this would encourage more providers to offer the option of
>selective blocking, and (when available) it makes unsubscribe a
>simple /and consistent/ operation for the end user.
>
>Scott Nelson <[email-masked]>
>
>
>_______________________________________________
>Asrg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg