At 11:14 PM 8/6/03 -0600, John Fenley wrote:
[edited]
Since the 12th of July I have been tracking my spam volumes at a poisoned
account.
on the 20th I decided to start unsubscribing from the mail I received.
Since the 25th I have unsubscribed from every piece of mail that I could.
I have seen spam volumes decrease from 20-30 per day to 10-15 per day over
the course of 2 weeks.
I see this as relevant, but its impact on long term volumes is still to be
determined.
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. I did the harvest experiment, where you invent an
address and unsubscribe it from every spam you receive on anther address.
It did eventually get spam.
Another urban myth is the grandmother who complains of hundreds of
spams a day, and upon investigation, she's been subscribed to spam-L.
I think this has happened (except for the spam-L part).
There are many people who refuse to unsubscribe from "legitimate"
mailing lists that they signed up for because of the
"unsubscribing makes the problem worse" myth.
I've always wondered whether unsubscribing would reduce the overall
volume, or increase it but that's a separate topic.
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