Quoting Kee Hinckley <nazgul(_at_)somewhere(_dot_)com>:
At 10:17 AM -0700 8/7/03, Scott Nelson wrote:
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".
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg