Subject: [Asrg] SMTP level unsubscribe

From: Scott Nelson <[email-masked]>
Date: Thu, 07 Aug 2003 10:17:37 -0700

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 <[email-masked]>

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

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 7 Aug 2003 19:36:53 -0400

>the single word "unsubscribe".

Because it contains no token which proves that you actually received 
any of the messages you are unsubscribing from, it's susceptible to 
abuse (unsubscribing people against their will).  Also I doubt that 
most commercial mailers would go for it because it has very limited 
granularity.  You might fire off such a message in response to some 
mail from a idiot who bought a CD and unwittingly remove yourself 
from the lists of several of your favorite software vendors--because 
they all happened to use the same bulk mail provider.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: Andrew Akehurst <[email-masked]>
Date: Fri, 08 Aug 2003 13:57:23 +0100 (BST)

> they all happened to use the same bulk mail provider.

I'm not quite sure what your objection is. Do you mean that this
is possible because the server MTA's policy may not reflect the true
consent of the end recipient? If the site administrator set a blanket
policy for their entire MTA then I agree this would be a problem.

However it could be much more granular than that. By the time the
RCPT command has been received, the MTA knows:

 - the IP address of the previous system (the sender or a relay)
 - the detail in the HELO or EHLO command
 - the address in the MAIL FROM command
 - the address in the RCPT TO command

Not all of this information may be useful, but the pair consisting
of [sender, recipient] could be used to provide very granular
unsubscribe behaviour, as long as the server MTA's actions do in
fact accurately reflect the consent of the end-recipient.

Perhaps I missed something? If you'd like to provide a more
detailed counter-example, please do.

However in all of this there is the assumption that the MTA somehow
"knows" what the recipient wants, which raises again the question
as to how (by what protocol) a recipient could communicate their
consent to an MTA. This fits in with section 2.5.1 of the consent
framework document:

  http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html

It would be interesting to see some more debate in that area.

There is also the issue of which MTA would be responsible for 
doing this. For the simple situation where the recipient uses their
ISP's POP/IMAP servers to receive their mail, it might be relatively
easy to send consent details to that ISP's server MTA. To try and
communicate such data into other MTAs closer to the network core
would be much more difficult due to the sheer volume of data.

Regards

Andrew

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 8 Aug 2003 10:41:11 -0400

At 1:57 PM +0100 8/8/03, Andrew Akehurst wrote:
>...

Braindeadness on my part.  For some reason I thought it was something 
sent to the bulkmailer, as opposed to a reply to an incoming message. 
Ignore my message.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: david nicol <[email-masked]>
Date: 12 Aug 2003 18:20:44 -0500

I'm worried that sharing the intersection of suggestions
with aspects of the system I've been working on is off
topic but here goes.

> would be much more difficult due to the sheer volume of data.

I see no advantage in adding a command from a different layer to
SMTP.  Variable envelope return paths work perfectly well for the
purpose Scott Nelson suggested.  Andrew Akehurst suggests that
a receiving MTA could be hacked to refuse selected messages.  This
is similar to a suggestion made on a talk-radio show last week,
the show was on spam, Missouri might be rolling out a law against
return address forging.  A caller suggested adding a "bounce" button
to their MUA in addition to the "delete" button.

The pay2send MTA, which I am and havebeen working on, will use rules
to allow wanted messages in, and block all else.

You can set something up with sendmail milter, too , I think.

-- 
David Nicol / If at first you don't succeed, use a bigger hammer. 
                                        http://gallaghersmash.com

---

From: Andrew Akehurst <[email-masked]>
Date: Wed, 13 Aug 2003 15:01:12 +0100 (BST)

> a receiving MTA could be hacked to refuse selected messages. 

That was certainly one of the things I had in mind when I wrote
the above. The main point I was making was that it would be
utterly impractical for me (or any other e-mail user) to 
communicate my personal consent policy to every single MTA on the
planet (even assuming all MTAs supported consent policy 
enforcement, which is itself a massive assumption).

However I do still think that action at the network edge could
have a big impact on the problem as a whole and I agree with the
point you highlighted about hacking.

> This

In order for the MTA to be able to do this, the end user must
be able to communicate policy decisions to it, so that the MTA
knows which messages are "unwanted".

If there were a standard for expressing and communicating such
policies, it would allow any MUA to communicate policy with any
compliant MTA. Then far more people would have the benefit of
using such a system.

I'm willing to volunteer to help draft such a standard, in line
with Section 2.6 of the Consent Framework. Who wants to help?

Andrew

---

From: Andrew Akehurst <[email-masked]>
Date: Thu, 14 Aug 2003 09:55:04 +0100 (BST)

Quoting david nicol <[email-masked]>:
> 
> I believe that any solution that required the whole world
> to play along for the solution to work is fundamentally flawed.

That seems quite reasonable.
 
> I think that the 400 and 500 error codes are sufficient,
> and there is no need to broadcast your reception preferences.

Broadcasting preferences involves a lot of synchronisation effort and a lot of 
data, I doubt many people would advocate that. However transmitting a consent 
policy to one or two systems such as the MTA(s) of your ISP might make some 
difference as it could help to enforce the policy further "upstream" from the 
receiver. It's a possibility.

> The pay2send.com system currently uses a form on a web page for
> describing the list of what messages to accept.
> 
> Please take a moment to test it?  

I've signed up for the system and I'll decide what I think.

Andrew