ietf-mxcomp
[Top] [All Lists]

Proof of Consent NON-Proposal

2004-03-17 15:29:41
following up the great success of my accreditation non-proposal that nobody
wants to make a work item, here is a second.

Again the relevance is that the existence of the concept affects the spec
that MARID may produce. In this case however the point is to reduce the
scope of the spec by eliminating a particularly problematic set of corner
cases. 

Detailed discussion should take place on ASRG.


One of the biggest headaches with any SPF/RMX like proposal is how to deal
with a forwarding relationship. I.E

Mail is send to                         
alice(_at_)alumni(_dot_)ardvark(_dot_)com
It is then forwarded to         alice(_at_)homeisp(_dot_)net

The change of the email address in mid stream is problematic because it
means that homeisp.net will be receiving the mail from the
alumni.ardvark.com forwarder and not from the place it is expected to come
from.


I believe that an forwarding relationship of this type should only occur
because the ultimate destination of the message intends to collect mail from
the additional contact address whether it be mailing list or forwarding
relationship. In other words alice should have to 'choose' to listen at that
address in the first place.

This is a consent relationship. One of the biggest net.problems to hit the
blacklists was how to deal with outright malicious complaints about mailing
list senders. At the FTC workshop Cindy Cohen described an organized
campaign to get moveon.org blacklisted. People subscribed to the list simply
so that they could report it to their ISP as spam.

The problem is that even though Alice subscribed to the list the incomming
email infrastructure does not know that this happened.

I do not like he-said-she-said problems. This one is easy to deal with,
simply attach a proof of consent to every message the forwarding
relationship generates. The proof can be generated during the original
subscription opt-in process.

All we need to do to deploy this is to update the mailing list software C/R
module and then update the spam filters.


This is similar in concept to SRS but avoids the hokey address
transformations which I think confuse the end user. Every time my wife sees
something unusual in her email she demands a 30 minute consultation and an
explanation of why it is happening. She does not accept the fact that it is
futile to expect a computer whose fundamental operations are based on
quantum mechanics to behave in a deterministic manner. 'Thats just the way
the wave function collapsed today' is not considered acceptable. So I don't
like specs that do things that might confuse end users.

                Phill

Attachment: proofofconsent.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>