[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 <scott@spamwolf.com>


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg