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(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg