Re: [Asrg] request for review for a non FUSSP proposal

[Claudio Telmon <[e-mail]>]

Seth wrote:

> What benefit does that offer over using tagged addresses (with the tag
> as the "consent token")?  I do that now, for commercial mailers; when
> an address starts getting spammed, I turn it off.  Sometimes, I give
> the company that got it a new address to use.

It's quite similar. The framework is actually quite similar to anything
that sets a different "tag" or "token" for different correspondents, and
then accepts only messages carrying those tags somewhere in the message.
I referred to "ham passwords" as an example, but in the paper I also
cite tagged addresses (I call them "address name extensions", which as I
understand it is one of the many names of this kind of mechanisms).

There are some relevant differences between how tagged addresses are
currently defined/deployed, and this proposal. I don't say that the same
results couldn't be achieved with tagged addresses, but a framework
similar to the one I've defined would be required in order to cope with
these differences.

The main problem is that tagged addresses would be disclosed every time
messages are sent in Cc to many addresses. This opens to forgery, and
most of the positive effects discussed until now in this thread were
lost. A solution would require either not to send messages in Cc:, or to
purge the messages from the tags when delivered to other recipients,
which is the main task for the framework I've described. I think that
tags/tokens in a separate header can ease this task, since addresses can
be disclosed in many places, e.g. in the body of a message.

Also, currently (but it doesn't need to be so), tags are bound to
addresses and service providers, so distributing tags or moving to
another provider would be complicated. The framework I've described
provides an explicit solution to this, since it uses an SMTP extension
that can be standardised.

Finally, the framework provides a way to deal with consent requests
(requests of contact from unknown people), that should reduce the risk
of spam and malware. Again, this could be done also with tagged addresses.

All in all, all I've described could be done with tagged addresses, but
IMO it would end up with the same framework, just with tags/tokens put
in a different, maybe less appropriate place.

-- 

Claudio Telmon
[e-mail]
http://www.telmon.org