Subject: Re: [Asrg] SMTP level unsubscribe

From: Scott Nelson <[email-masked]>
Date: Wed, 13 Aug 2003 10:49:00 -0700

At 06:20 PM 8/12/03 -0500, david nicol wrote:
>
>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.
>
>
>
>On Fri, 2003-08-08 at 07:57, Andrew Akehurst wrote:
>
>> 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.
>
>
>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.
>
>

I suggested /standardizing/ the meaning of a 578 to mean unsubscribe.
I has been suggested to me off list that it should be
"578 5.7.8 No consent" and that if a mailing list gets one of these,
it should unsubscribe the user.  I agree.
The advantage to 578 over, say, 550,  is that if a mailing list
gets a 578, it can be /certain/ that it should unsubscribe the user.

Kee Hinkley had a momentary lapse of reason and suggested that someone
might generate the message accidentally.  This was why I originally 
suggested that it happen /only/ at the SMTP level.
After thinking about this I realized that in practice it often
/would/ be possible, since very few mailing lists send the 
messages themselves, preferring to relay them through sendmail.
So from the mailing list's point of view, it does get a DSN message,
and that message could be faked.

Since that is possible, I now suggest that DSN also be allowed,
and that lists that are concerned about the possibility of forged
unsubscribes should send a confirmation message with a token
embedded in a header (probably the Subject: though it could be any header), 
and check for that in the subsequent bounce.  If you get a 578 once,
you should get it again the second time.  It may be an extra email or two,
but they're small emails, and they should be handled automatically.
If the list is unwilling or unable to do that, 
then it should accept all 578s as an unsubscribe.

Allowing DSNs makes it possible for either the MUA or the MTA to do it.

That removes the need to update the MTA, or give it potentially
sensitive information, though for most people, 
the issue of updating a new MTA is moot.
When they switch MTAs they're also switching ISPs, and that
means a new email address, which isn't going to be subscribed
to any mailing lists anyway.

Scott Nelson <[email-masked]> 

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

---

From: Brad Knowles <[email-masked]>
Date: Wed, 13 Aug 2003 20:20:03 +0200

>  it should unsubscribe the user.  I agree.

	Uh, no.  We don't use 57x reply codes to SMTP commands.  See RFC 
2822, sections 4.2.2, 4.2.3, and 4.3.2.  Sections 4.2.2 and 4.2.3 
list all possible reply codes, in different sort orders.  Section 
4.3.2 provides a complete breakdown of all possible reply codes on a 
state-by-state basis.

	You can use a 5.7.8 extended mail system status code (RFC 1893), 
but that is a different matter.

>  gets a 578, it can be /certain/ that it should unsubscribe the user.

	This is a pretty big change to the SMTP protocol, and would 
require code modification to a lot of MTAs.  It would also be a huge 
violation of the "Principle of Least Astonishment" (POLA) as far as 
pretty much the entire Internet is concerned.

	Setting the particular extended mail system status code to mean 
whatever you want, is a much easier task.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)