ietf-asrg
[Top] [All Lists]

Re: [Asrg] SMTP level unsubscribe

2003-08-13 10:49:39
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 <scott(_at_)spamwolf(_dot_)com> 

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg