request for review for a non FUSSP proposal

[Claudio Telmon]

Dear Sirs,
I've developed a proposal for an extension to the SMTP protocol that
should provide to address owners the ability to express consent to
delivery of messages in their mailboxes. While it is not the Ultimate
Solution to the Spam Problem, and strictly speaking it is not even an
antispam solution, it could help reducing spam. I already discussed my
proposal with some researchers, which judged it positively, but which
didn't have a very specific competence.
I think that my proposal could be of some interest for the ASRG
community, and I'm looking for comments and advise.

The paper is in html and pdf at
http://www.telmon.org/consent/smtp-consent-1.1.html
and
http://www.telmon.org/consent/smtp-consent-1.1.pdf

The paper is quite long, as I tried to anticipate most of the
implementation and deployment issues, but the idea is quite simple and
not really new, since it is very similar to "ham passwords". If you just
want to see what it's all about, you could just read the "Introduction"
and "General overview of the framework" sections, and maybe the
"Deployment of the framework" section at the end of the document.

Thanks in advance for any comments or suggestions you can provide me.

Sincerely,

- Claudio Telmon

--

Claudio Telmon
claudio@...
http://www.telmon.org


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Claudio,
I've skimmed part of your paper, and I think your framework has a
problem in the transition to consent-enabled mailboxes: When users
switch their mailboxes to consent-enabled, they lose the ability to
receive any message from consent-unaware senders, including friends,
business contacts, mailing lists, banks and similar notification
services, reminders, cell phones, etcetera. Most of them will end up
having a second mailbox which is not consent-enabled, or functionally
similar arrangement, resulting in two streams of messages. They'll
have to watch both streams and will find wanted and unwanted messages
in each one. (Well, the consent-enabled stream will have to wait for
spammers to become aware of the X-Consent-request header to get much
unwanted stuff.) Since any other action will be performed as usual,
there will be no visible advantage resulting from the framework. That
state of affairs will never be an incentive for widespread adoption,
and, on the other hand, without widespread adoption the framework will
always require that disappointing stream doubling.

-------- Original Message --------
Subject: [Asrg] request for review for a non FUSSP proposal
Date: Sun, 21 Jun 2009 11:25:37 +0200
From: Claudio Telmon <claudio@...>
Reply-To: Anti-Spam Research Group - IRTF <asrg@...>
To: asrg@...

Dear Sirs,
I've developed a proposal for an extension to the SMTP protocol that
should provide to address owners the ability to express consent to
delivery of messages in their mailboxes. While it is not the Ultimate
Solution to the Spam Problem, and strictly speaking it is not even an
antispam solution, it could help reducing spam. I already discussed my
proposal with some researchers, which judged it positively, but which
didn't have a very specific competence.
I think that my proposal could be of some interest for the ASRG
community, and I'm looking for comments and advise.

The paper is in html and pdf at
http://www.telmon.org/consent/smtp-consent-1.1.html
and
http://www.telmon.org/consent/smtp-consent-1.1.pdf

The paper is quite long, as I tried to anticipate most of the
implementation and deployment issues, but the idea is quite simple and
not really new, since it is very similar to "ham passwords". If you just
want to see what it's all about, you could just read the "Introduction"
and "General overview of the framework" sections, and maybe the
"Deployment of the framework" section at the end of the document.

Thanks in advance for any comments or suggestions you can provide me.

Sincerely,

- Claudio Telmon

--

Claudio Telmon
claudio@...
http://www.telmon.org
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Alessandro Vesely wrote:
> Claudio,
> I've skimmed part of your paper, and I think your framework has a
> problem in the transition to consent-enabled mailboxes: When users
> switch their mailboxes to consent-enabled, they lose the ability to
> receive any message from consent-unaware senders, including friends,
> business contacts, mailing lists, banks and similar notification
> services, reminders, cell phones, etcetera.

You're absolutely right, of course. This is the most critical deployment
issue, and I have tried to consider some strategies in the "deployment"
section. Nobody could actually "switch" to consent-enabled mailboxes: a
gradual, albeit less effective transition path is required.

> Most of them will end up
> having a second mailbox which is not consent-enabled, or functionally
> similar arrangement, resulting in two streams of messages. They'll have
> to watch both streams and will find wanted and unwanted messages in each
> one.

A couple of thing could help. First, at the beginning the framework
could be implemented by the receiver's MUA, instead of the receiver's
MTA. This could produce backscatter, so it wouldn't be suited for wide
deployment, but this way, people willing to adopt it were not bound to
the choices of their ISPs. This way users wouldn't need two separate
addresses: messages carrying proper tokens would be whitelisted, while
others would receive a worse spam score. Also, messages for addresses
associated to token in the address book, but not carrying a proper
token, would be marked as forgery and treated as such. However, some
people could actually prefer to have two different email addresses, even
if then forwarding all messages to the non-consent-enabled mailbox. This
helps in adopting the framework, but doesn't help much in finding it useful.

In the beginning, the advantage could be more for senders that for
receivers. A bank offering this option to its customers could protect
its communications from phishing: messages without consent token, and
with an address from the bank, could be highlighted by the MUA as
probable phishing attempt. The main point here is that the
presence/absence of tokens should be easily understood by most people,
while mail authentication failures are usually not, and message
authentication is hard for many reasons. People worried about forgeries
could be told by the bank to adopt the framework (this wouldn't replace
other security measures and proper behaviour, it would however add
another layer of protection).

Some services could be offered, e.g. protected mailboxes for children;
relatives and friends would need to adopt the framework in order to
communicate with them. These mailboxes would actually only accept
messages with proper tokens. In this respect, having plugins available
for most common MUAs would be critical. Friends and relatives willing to
communicate with them could just be told to "install the plugin and put
this string in this field", and then forget the whole thing. But again,
all this may make sense if there is enough interest in this form of
control on communications, which is probably not the case just for UBE.

> (Well, the consent-enabled stream will have to wait for spammers to
> become aware of the X-Consent-request header to get much unwanted
> stuff.)

The hope is that messages conforming to the consent request format and
semantic should be much easier to deal with by using other antispam
tools and controls. However, this is my guess, you know better than me.

> Since any other action will be performed as usual, there will be
> no visible advantage resulting from the framework. That state of affairs
> will never be an incentive for widespread adoption, and, on the other
> hand, without widespread adoption the framework will always require that
> disappointing stream doubling.

Well, this stream doubling is something many already do, keeping one
address for close friends and business partners, not disclosing it in
order to avoid spam and other messages. But again you're right, the
framework would need reach a critical mass in some time, or it would be
abandoned even by early adopters.

Regards,

- Claudio

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Paul Russell-6]

On 6/22/2009 17:12, Claudio Telmon wrote:
> Well, this stream doubling is something many already do, keeping one
> address for close friends and business partners, not disclosing it in
> order to avoid spam and other messages. But again you're right, the
> framework would need reach a critical mass in some time, or it would be
> abandoned even by early adopters.

Back in the day when most spammers obtained addresses by harvesting them from
web pages, you could, for the most part, keep a mailbox spam-free by disclosing
your email address only to those from whom you wanted to receive email.  The sun
set on that scene long ago.  Spammers generate potential recipient addresses
based on common names and naming schemes, or harvest them from address books and
private mail archives on compromised systems.  Security by obscurity seldom
works for very long.

--
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Steve Atkins]

On Jun 22, 2009, at 2:30 PM, Paul Russell wrote:

> On 6/22/2009 17:12, Claudio Telmon wrote:
>> Well, this stream doubling is something many already do, keeping one
>> address for close friends and business partners, not disclosing it in
>> order to avoid spam and other messages. But again you're right, the
>> framework would need reach a critical mass in some time, or it  
>> would be
>> abandoned even by early adopters.
>
> Back in the day when most spammers obtained addresses by harvesting  
> them from
> web pages, you could, for the most part, keep a mailbox spam-free by  
> disclosing
> your email address only to those from whom you wanted to receive  
> email.  The sun
> set on that scene long ago.  Spammers generate potential recipient  
> addresses
> based on common names and naming schemes, or harvest them from  
> address books and
> private mail archives on compromised systems.  Security by obscurity  
> seldom
> works for very long.

Also any actual usage of an email address leads to it being in a mailbox
on a Windows machine. That, in turn, leads to it being sprayed all over
the internet by viruses, and hence harvested by spammers.

I have lots of uniquely created addresses that were provably not guessed
that get a lot of spam via that route.

Cheers,
   Steve

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Paul Russell wrote:

> On 6/22/2009 17:12, Claudio Telmon wrote:
>> Well, this stream doubling is something many already do, keeping one
>> address for close friends and business partners, not disclosing it in
>> order to avoid spam and other messages. But again you're right, the
>> framework would need reach a critical mass in some time, or it would be
>> abandoned even by early adopters.
>
> Back in the day when most spammers obtained addresses by harvesting them from
> web pages, you could, for the most part, keep a mailbox spam-free by disclosing
> your email address only to those from whom you wanted to receive email.  The sun
> set on that scene long ago.  Spammers generate potential recipient addresses
> based on common names and naming schemes, or harvest them from address books and
> private mail archives on compromised systems.  Security by obscurity seldom
> works for very long.
>

In this respect, the framework should be effective, since spammers would
also need to generate the consent token, which they can't. When
harvesting email addresses (and tokens) from compromised systems, the
framework provides a way to detect who was compromised and to invalidate
the token.

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote:
> In this respect, the framework should be effective, since spammers would
> also need to generate the consent token, which they can't.

Why not?  They can run any code they want on any compromised system,
therefore they can generate the consent token the same way the former
owner of that system could.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Mon, Jun 22, 2009 at 02:37:16PM -0700, Steve Atkins wrote:
> Also any actual usage of an email address leads to it being in a mailbox
> on a Windows machine. That, in turn, leads to it being sprayed all over
> the internet by viruses, and hence harvested by spammers.
>
> I have lots of uniquely created addresses that were provably not guessed
> that get a lot of spam via that route.

Precisely correct, and worth emphasizing.  I've gone so far as to
deliberately embed non-guessable addresses in the headers of single
messages sent to single recipients -- and have subsequently received spam
at some of them.  And of course addresses used repeatedly with multiple
recipients tend to attract spam much quicker, since such usage increases
the probability that the addresss will show up on a compromised system.

It's no longer possible to keep any email address that's actually
used out of the hands of spammers, at least not for long.  (I often
find it ironic how many people using obfuscated domain registration,
putatively to keep addresses away from spammers, are running Windows on
their desktops or laptops, and thus are either (a) already compromised or
(b) going to be compromised.)

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Rich Kulawiec wrote:
> On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote:
>> In this respect, the framework should be effective, since spammers would
>> also need to generate the consent token, which they can't.
>
> Why not?  They can run any code they want on any compromised system,
> therefore they can generate the consent token the same way the former
> owner of that system could.

The owner of the compromised system can only generate tokens then
accepted by his address's MTA, the same can the spammer that compromised
the system.
The attacker can collect the tokens provided to the system owner in
order to communicate with other people. It will then be able to send
spam to the owner's correspondents. These, in turn, can see that spam
arrives with the tokens they provided to the system owner, inform the
system owner about this fact and invalidate the tokens. Once the system
security is "restored", the spammer is left with useless tokens.
Collected consent-protected addresses are useless without valid tokens.

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

On Tue, 2009-06-23 at 00:14 +0200, Claudio Telmon wrote:
> These, in turn, can see that spam
> arrives with the tokens they provided to the system owner, inform the
> system owner about this fact and invalidate the tokens. Once the
> system
> security is "restored", the spammer is left with useless tokens.
> Collected consent-protected addresses are useless without valid
> tokens.

All of which puts the burden once again -- or 'still' -- on the backs of
the innocent victims. This doesn't solve anything.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Lyndon Nerenberg wrote:

> All of which puts the burden once again -- or 'still' -- on the backs of
> the innocent victims. This doesn't solve anything.

I'm probably missing your point. I'm corresponding with person A. I give
him a token he can use to send me messages. He is careless, and has his
system compromised, so a spammer can take that token and use it for
sending me spam. I would feel more a victim of A than a victim of the
spammer. This framework takes the problem at the level of a relationship
between me and somebody who doesn't handle the relationship with proper
care. The system compromise is an accident that is known to happen to
careless people. By using this framework, I can give another opportunity
to A, by informing him of the problem, reprimand him, talk about this
with our friends, invalidate the token and send him another one, or I
can just close the (email) relationship. The same if the token is
directly provided by A to other undesired correspondents. These are
things I cannot do if I just look at spam messages. Also, I can restore
a situation where the information in the hands of the spammer is
useless, and at almost no cost, so I wouldn't say that it doesn't solve
anything.

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

Claudio,

An alternative for tokens would be to offer message links.  Rather  
than sending messages, a reference to a message is exchanged instead.  
The link format associated with the message should allow recipients a  
means to know who issued the message.  This would eliminate a need to  
track delivery status.  Unless the recipient follows the link, the  
message would not be considered delivered.  Receiving MTAs could offer  
a menu to allow recipients a means to automatically fetch messages  
from specific links as a method to save time when online, especially  
when dealing with slow uplinks.  This mode of operation might be  
globally used to ensure compatibility with existing MUAs or domains  
that don't support this mode of exchange.  Importantly, this method  
would not represent a major change in how email is currently handled,  
however authentication would become inherent with the transfer.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Rich Kulawiec wrote:

> On Mon, Jun 22, 2009 at 02:37:16PM -0700, Steve Atkins wrote:
>> Also any actual usage of an email address leads to it being in a mailbox
>> on a Windows machine. That, in turn, leads to it being sprayed all over
>> the internet by viruses, and hence harvested by spammers.
>>
>> I have lots of uniquely created addresses that were provably not guessed
>> that get a lot of spam via that route.
>
> Precisely correct, and worth emphasizing.  I've gone so far as to
> deliberately embed non-guessable addresses in the headers of single
> messages sent to single recipients -- and have subsequently received spam
> at some of them.  And of course addresses used repeatedly with multiple
> recipients tend to attract spam much quicker, since such usage increases
> the probability that the addresses will show up on a compromised system.

And are you sure their machines were actually infected? I
experienced spam after sending to organizations that should be
secured, e.g. nic.es. As I wrote a few minutes ago, I recognized the
connection by timely receiving spam in the relevant foreign
language. My guess is that spammers have also other means to sniff
mail traffic.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Douglas Otis wrote:

> Claudio,
>
> An alternative for tokens would be to offer message links.  Rather than
> sending messages, a reference to a message is exchanged instead.  The
> link format associated with the message should allow recipients a means
> to know who issued the message.  This would eliminate a need to track
> delivery status.  Unless the recipient follows the link, the message
> would not be considered delivered.  Receiving MTAs could offer a menu to
> allow recipients a means to automatically fetch messages from specific
> links as a method to save time when online, especially when dealing with
> slow uplinks.  This mode of operation might be globally used to ensure
> compatibility with existing MUAs or domains that don't support this mode
> of exchange.  Importantly, this method would not represent a major
> change in how email is currently handled, however authentication would
> become inherent with the transfer.

This seems to mix Internet mail 2000 with the consent framework. You
suggest to put the token in the link, so that the receiver's
notification agent can perform the same selection as the receiver's MTA
in my proposal. While this would be possible, goals are different and
implementations seem to be independent. It should work, from a technical
perspective. However, Internet mail 2000 already has its own deployment
issues, so mixing the two things seems to increase the deployment
difficulties, which are already high.


--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Tue, Jun 23, 2009 at 12:14:30AM +0200, Claudio Telmon wrote:
> The attacker can collect the tokens provided to the system owner in
> order to communicate with other people. It will then be able to send
> spam to the owner's correspondents. These, in turn, can see that spam
> arrives with the tokens they provided to the system owner, inform the
> system owner about this fact and invalidate the tokens.

This is unworkable for multiple reasons, not the least of which of scale:
as of a few years ago, there were at least a hundred million compromised
systems, and the number today is certainly much higher.  There's no
good way to inform the former owners of those systems, there's no reason
to believe that they'll see the notification (especially if automated,
since the new owners of those systems can prevent them from seeing it),
there's no way to stop those systems from emitting bogus notifications,
the recipients' systems may themselves be compromised, etc.  Not to
mention it's a LOT of work for everyone to keep track of all these tokens.

Any proposal (not just anti-spam) which depends on the presumption that
end-user systems are secure or securable is dead-on-arrival *until*
the zombie problem is solved, and there is at the moment nothing at all
happening to indicate that problem is even being seriously addressed,
let alone "solved".

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Rich Kulawiec wrote:

> This is unworkable for multiple reasons, not the least of which of scale:
> as of a few years ago, there were at least a hundred million compromised
> systems, and the number today is certainly much higher.  There's no
> good way to inform the former owners of those systems, there's no reason
> to believe that they'll see the notification (especially if automated,
> since the new owners of those systems can prevent them from seeing it),
> there's no way to stop those systems from emitting bogus notifications,
> the recipients' systems may themselves be compromised, etc.  Not to
> mention it's a LOT of work for everyone to keep track of all these tokens.

While what you say is true in general, I think you missed a critical
part of the consent framework I'm proposing. A consent-enabled address
will only accept messages from senders that received a valid token for
that address though some channel (usually, not email). That is, each
sender will only have tokens for consent-enabled addresses he received a
token for, which is comparable to the number of addresses he has in his
address book. If the sender's system is compromised, the
attacker/spammer will only collect tokens for these addresses. The
spammer can send spam to any non-consent-enabled address, but this is
outside the scope of the framework. The spammer can however send
messages only to the consent-enabled addresses he has tokens for, which
are the people in the address book of the compromised system. These are
the (few) people the system owner is in direct contact with, which will
detect which token is used in the spam they receive and therefore whose
system was compromised. The owner of this system will be informed,
possibly not via email, and the tokens will be invalidated anyway. The
other millions of compromised hosts are not relevant in this scenario:
even if the spammer distributes the tokens to these hosts, or sells the
address and the token in a list, all this becomes useless once the token
is invalidated, which should happen almost immediately after a couple of
spam messages.
At this point, those receiving the spam can decide if they want to issue
a new token for the (once) compromised sender, provided that its host
has been cleaned. If they keep receiving spam with the new token, they
surely will revoke this token too, and will be put in front of the
problem of their relationship with somebody that is not able to keep its
system clean. With respect to consent-enabled addresses, it would turn
the problem of informing the owners of millions of compromised systems,
into a "local" problem of relationships inside small groups of people.


--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 22 June 2009 16:31:04 -0600 Lyndon Nerenberg <lyndon@...> wrote:

> On Tue, 2009-06-23 at 00:14 +0200, Claudio Telmon wrote:
>> These, in turn, can see that spam
>> arrives with the tokens they provided to the system owner, inform the
>> system owner about this fact and invalidate the tokens. Once the
>> system
>> security is "restored", the spammer is left with useless tokens.
>> Collected consent-protected addresses are useless without valid
>> tokens.
>
> All of which puts the burden once again -- or 'still' -- on the backs of
> the innocent victims. This doesn't solve anything.
>

That's the wrong test. The test should not be "does this mechanism place a
burden on the innocent?". All new mechanisms do that.

Instead, you should ask whether the mechanism places a disproportionate
burden on the innocent. The burden should be at least somewhat less than
the burden currently imposed by spammers. That's a much easier test to pass
if you include the burden on sys-admins. However, the burden placed on end
users should not be a cognitive burden - most won't cope.


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

Ian Eiloart wrote:

> However, the burden placed
> on end users should not be a cognitive burden - most won't cope.

If I understand what you mean, then IMHO this framework should pass this
cognitive test, since the availability of tokens to correspondents (and
spammers) should be easy to understand... well, much easier than
failures of digital signatures, DSN, and locks on web pages, anyway...

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Seth Breidbart]

Claudio Telmon <claudio@...> wrote:

> While what you say is true in general, I think you missed a critical
> part of the consent framework I'm proposing. A consent-enabled
> address will only accept messages from senders that received a valid
> token for that address though some channel (usually, not
> email). That is, each sender will only have tokens for
> consent-enabled addresses he received a token for, which is
> comparable to the number of addresses he has in his address book. If
> the sender's system is compromised, the attacker/spammer will only
> collect tokens for these addresses.

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.

Seth
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Claudio Telmon]

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
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg