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

From: Claudio Telmon <[email-masked]>
Date: Sun, 21 Jun 2009 11:25:37 +0200

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
[email-masked]
http://www.telmon.org

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Jun 2009 16:54:35 +0200

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 <[email-masked]>
Reply-To: Anti-Spam Research Group - IRTF <[email-masked]>
To: [email-masked]

Dear Sirs,

Sincerely,

- Claudio Telmon

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 22 Jun 2009 23:12:15 +0200

Alessandro Vesely wrote:
> 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
> 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
[email-masked]
http://www.telmon.org

---

From: Paul Russell <[email-masked]>
Date: Mon, 22 Jun 2009 17:30:25 -0400

> 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

---

From: Steve Atkins <[email-masked]>
Date: Mon, 22 Jun 2009 14:37:16 -0700

> private mail archives on compromised systems.  Security by obscurity  

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

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 22 Jun 2009 23:45:08 +0200

> private mail archives on compromised systems.  Security by obscurity seldom

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
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 22 Jun 2009 17:52:51 -0400

On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote:
> 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

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 22 Jun 2009 17:52:54 -0400

> 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

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 00:14:30 +0200

> 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
[email-masked]
http://www.telmon.org

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 22 Jun 2009 16:31:04 -0600

On Tue, 2009-06-23 at 00:14 +0200, Claudio Telmon wrote:
> These, in turn, can see that spam

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

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 01:19:53 +0200

> 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
[email-masked]
http://www.telmon.org

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Jun 2009 18:09:11 -0700

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Jun 2009 08:22:17 +0200

Rich Kulawiec wrote:
> 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.

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 09:26:42 +0200

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
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 23 Jun 2009 06:05:42 -0400

On Tue, Jun 23, 2009 at 12:14:30AM +0200, Claudio Telmon wrote:
> 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

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 12:47:28 +0200

> 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
[email-masked]
http://www.telmon.org

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 23 Jun 2009 12:36:59 +0100

> 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/

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 13:59:48 +0200

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
[email-masked]
http://www.telmon.org

---

From: Seth <[email-masked]>
Date: Tue, 23 Jun 2009 09:39:41 -0400 (EDT)

Claudio Telmon <[email-masked]> wrote:

> 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

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 16:22:21 +0200

> 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
[email-masked]
http://www.telmon.org

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 23 Jun 2009 16:18:43 +0100

> failures of digital signatures, DSN, and locks on web pages, anyway...

It the behaviour of the user is required to change, then that's a bad 
thing. I've not read the spec, so I'm not judging this proposal. Just 
correcting the claim that you can't burden the use at all. You can, but 
ideally you want to do it in ways that the user doesn't notice. If your 
spec requires a user to find something in addition to an email address, 
then it needs to be extremely easy to do.

Still, we're already in a position where people are fearful of publishing 
email addresses, so this spec might alleviate that problem. But, it isn't 
fundamental to combatting spam.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 Jun 2009 10:38:00 -0700

On Jun 23, 2009, at 12:26 AM, Claudio Telmon wrote:
> 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.

Your strategy requires servicing a method that does not depend upon  
"pass-tokens" as a means to obtain them.  The task of collecting  
source specific tokens represents a fair amount of administrative  
effort for both senders and recipients that is likely to be  
problematic.  Not good.

Spitting the email-address onto separate headers is problematic.  In  
addition, what one MTA might understand may not apply to the subsequent.

Review how one might use <local-part>"+"<tags> :
http://css.its.psu.edu/news/emailplus.html

Then imagine this acceptance criteria is combined valid DKIM  
respondent's messages.

As yet a better alternative, to thwart wasted and undesired exchanges,  
an exchange by reference offers an inherent means to authenticate  
sources without cryptography, and avoid undesired exchanges.

-Doug

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 23 Jun 2009 16:37:53 -0400

On Tue, Jun 23, 2009 at 12:47:28PM +0200, Claudio Telmon wrote:
> that address though some channel (usually, not email).

Yeah, I get that.  But whatever that channel is, if it ultimately connects
to a network endpoint that's compromised (more and more likely every day),
or if it originates on a network endpoint that's compromised (likewise),
then whatever is communicated via that channel can't be trusted.  Moreover,
even if the information that's communicated via that channel is authentic,
any compromised endpoint can't be trusted to act on it properly.

Maybe I'm not saying this very well.  Let me try examples: Fred
doesn't know Barney, but gets a request for consent: it looks plausible,
so he grants it.  But the request *wasn't* from Barney, it was from
the malware on Barney's laptop, and now Fred not only has to deal with
the spam, he's got to revoke the consent.   Or: Wilma knows Betty,
and sends a request for consent.  Betty grants it, and things go
fine, until the night Wilma's system is compromised and sends a dozen
pieces of spam to Betty, who wakes up to it.  (Why does this happen?
Because the malware resident on Wilma's computer read the list of
people-who-have-granted-consent-to-Wilma and targeted that first.)

And so on, for all kinds of scenarios we could come up with.  Yes,
this is not a big problem for Fred or Betty, but when we multiply
them by a hundred million, it's a pretty big problem.  Which is why
this idea sounds to me like an attempt to build a layer on top of
a computing base (end-user systems) that are already compromised
in enormous numbers.

> With respect to consent-enabled addresses, it would turn

I don't think so: there is no "local".  Take for example, the members
of this mailing list: presuming that all of us use a mail client which
maintains an "address book" (and I don't) I'm certain that every one
of us has at least one entry in it that nobody else on this list has.
Most of us probably have *many* entries that nobody else on this list has.
And some of those entries are mailing lists which forward to many people.
Consider the extent of the damage that could be done if one of our
systems started spewing -- and how many spam recipients would have to
individually act in order to fully mitigate it.  (Because A and B
revoking their consent to mail from Z does not help C, D, E...)

(Which raises another scalability question: how would those of us who
have hundreds or thousands of correspondents find the time to manage
all this?  And any of us participating in any mailing list have many more
potential correspondents: anyone on any of those lists might write to us
off-list.  Same for anyone with a web site or blog or running any other
resource.   A quick check of my personally-addressed and valid inbound mail
-- that is, not including mailing lists, not including spam or phishes --
suggests that I've had over 11,500 correspondents in the past few years.
That's a lot of tokens to keep track of.  And that's just *me*.)

Moreover, "informing the owners" has already proven to be a badly-losing
strategy.  *If* the owners actually receive such communication
(telling them their system is probably compromised), they tend to
either disbelieve it, ignore it, classify it as a phish--often correct,
deny it, or act ineffectively to remedy the situation.  No anti-spam
scheme which requires effective, clueful participation by end-users has
any chance of working: if they existed (in very large numbers) then we
wouldn't have such a large spam problem because (a) their systems would
be compromised in huge numbers and (b) they would have learned by
now to never respond to any spam.

---Rsk

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 23 Jun 2009 23:26:59 +0200

Douglas Otis wrote:

> "pass-tokens" as a means to obtain them. 

Tokens can be obtained trough a "consent request" email message, which
is a normal "text only" message with some constraints, or trough some
other communication channel, including face by face meetings. Other,
more powerful or easy means to obtain token would probably mean that the
address owner would be flooded by spam hiding as consent request, or
that tokens could be surreptitiously obtained.

> The task of collecting source
> specific tokens represents a fair amount of administrative effort for
> both senders and recipients that is likely to be problematic.  Not good.
> 

This kind of evaluation is a critical one for the model the framework is
based on. I take the cell phone numbers as an example. Most of us has
hundreds of cell phone numbers, (almost) none of which has been obtained
automatically. We took the burden of collecting them, and usually, if we
need to contact somebody, and this person is willing to talk with us, we
manage to get a phone number through one of the many communication
channels that are offered to us. We also happily take the burden of
distributing by hand our cell phone number, even if we could just put it
on phone directories and have it automatically distributed, because we
understand the advantages of not distributing it. I would say, most of
us is more unhappy with the ease unknown people can contact us through
email, than with the difficulties they have contacting us through our
cell phone.

> addition, what one MTA might understand may not apply to the subsequent.

I think this is a technical problem the framework deals properly with. I
may be missing something, of course. And, it requires an extension to SMTP.

> http://css.its.psu.edu/news/emailplus.html

Yes, I wrote a detailed answer on this to Seth in a previous message.

> Then imagine this acceptance criteria is combined valid DKIM

I don't think this would solve the problem of address (that is, tag)
disclosure in messages with multiple recipients.

> sources without cryptography, and avoid undesired exchanges.

Maybe I didn't catch this one, but tokens can be exchanged between
users, so a "reference" would just be the use of the same token. But
probably I didn't understand what "exchange by reference" is, google
just gives me some cryptic pages on taxation and foreign currency :)

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: John Levine <[email-masked]>
Date: 23 Jun 2009 21:37:28 -0000

>A consent-enabled address will only accept messages from senders that
>received a valid token for that address though some channel (usually,
>not email).

It seems to me that if you want a private e-mail network, there are
plenty of ways to construct one now, e.g., use S/MIME and only accept
mail from senders whose signing keys are on your whitelist and encrypt
with your public key.  Or use per-correspondent subaddresses, as
Zoemail has been doing for over a decade.  If this were a problem that
needed to be solved, there are plenty of solutions already.

R's,
John

---

From: Claudio Telmon <[email-masked]>
Date: Wed, 24 Jun 2009 09:36:14 +0200

Rich Kulawiec wrote:

> the spam, he's got to revoke the consent. 

This is a very good example, and I'm really happy to read it, since this
is exactly the kind of problems that lets me put "non FUSSP" in the
subject. In order to answer to your example, I must take advantage of
existing antispam techniques.
A consent request is a message with some syntax limits, but it's not
just that: it is... well, a request for consent. If it looks like spam,
current antispam tools could deal with it at least as good as they do
with other messages (including DKIM, blacklist, check on the envelope,
etc., but on a simpler and smaller message). If it doesn't look like
spam, then Fred reads it: it is not spam, but now it must also be a
convincing request specifically for Fred, so that he may be willing to
believe it. Now, let's get to Fred: he receives a convincing request for
a contact, whatever "convincing" means to him. Should he take the risk
of granting a token?
Answers:
1. No. It then just doesn't accept consent requests: whoever wants to
contact him must manage to obtain a token through some other channel,
e.g. a common friend. Somebody won't be able to contact him: Fred's choice.
2. Yes. Well, if a software on Barney's laptop manages to pass all the
other antispam protections, and also passes the "Turing test" of
mimicing Barney so good to be able to  provide a request that is
convincing for Fred, what can we do about it? The fact is, it shouldn't
be that easy to get to this point, but we can't put limits on spammer
talents :).
3. Yes, but with a trick. I wrote the trick in the "Additional fields in
the MTA database" section. I don't like it, since it requires the MTA to
be able to write in the database, which increases implementation
complexity, but anyway: Barney is provided a token with a counter. When
a message is received with that token, the MTA decreases the counter.
When the counter is zero, the token is invalidated. Should Barney (or
his personal zombie) abuse of the token, he could do so for a very
limited number of messages. Should Barney actually be Fred's good fiend,
he would be provided a new token. All this can be automatically managed,
Fred would be asked by the MUA to choose if to set a counter when
answering to the consent request, and could then answer "Yes" when,
while reading Barney's messages, the MUA proposes to grant an unlimited
token.
This is at least how I conceived to deal with the problem.

> revoking their consent to mail from Z does not help C, D, E...)

I don't think that much action would be needed. If my system is
compromised, the tokens I have were compromised. My friends would
complain (the "local" blame that works), and the spammer would have a
token for the mailing list, the one I use, so it would be able to send
spam to the list. While this wouldn't avoid spam to the list and its
recipients, it wouldn't increase the risk/damage with respect to the
current situation. The list (not me) owns tokens for its subscribers,
and would forward the spam to these users with these tokens. These
tokens wouldn't be compromised, since me and my personal zombie cannot
access them. You would complain with the list owner: not with me, you
don't have a token for it and in any case I wouldn't care  (the "non
local" blame). The list owner invalidates the token me and my personal
zombie use in order to send messages to the list. End of the game. In
the meantime, since my friends threaten me not to grant me tokens any
more, I will probably clean up my system. If I don't, they will either
stop communicating with me, or accept my little problem, the same way it
usually goes with personal relationships. The mailing list will not.

> That's a lot of tokens to keep track of.  And that's just *me*.)

Dealing with the framework without an address book would be actually
impossible. With respect to numbers, I cannot answer. People and
software explicitly dealing with large lists of addresses/subscribers
would usually need to deal with an equal (well, double) number of
tokens. People like you, dealing, if I understand correctly, with a
large number of occasional correspondents, would need to do the same.
Note however that probably in these cases, most of the token exchanges
would be automated (you receive a token through a consent request, put a
token in piggyback in your first answer) and handled by the MUA, you
wouldn't even see these tokens. You would however need to collect some
through other means. I cannot make any guess on numbers, nor would I
take me or people I know as a reference on how many correspondents
people has (did anybody ever publish any statistics on this?), but it
would all turn down on how strict you are when accepting consent
requests, and how strict your correspondents are. At one end, you answer
to every contact request: this would end up with no consent protection,
no limits to communications with you, and in some cases to useless
messages (note that a consent request wouldn't be usually a useless
message, it just must be short and text). You could then disable the
consent protection on your address. At the other end, you do not accept
consent requests, and end up with a private network. The same for your
correspondents. Between these extremes, you select your correspondents,
and the same do they, and still enjoy the protection of antispam tools,
especially on consent requests.

> deny it, or act ineffectively to remedy the situation.

Do you feel that the same would be true if the communication were not an
automated communication but a communication from correspondents, not by
email, and maybe implying the (temporary) inability to communicate with
some of them? This would actually severely limit the usability of the
scheme.

>  No anti-spam

I don't know. Me, as probably each of us, I'm often asked by friends to
"reinstall" their systems because they are full of garbage. My email
address probably got collected also through their systems, but I never
considered blaming them, as I couldn't show any evidence of the fact.
Should I receive spam using their token, I could be much more aggressive
than I've been until now, and maybe others would do the same. This kind
of blame usually works with other communication channels (again, people
disseminating phone numbers), why shouldn't it work with email? People
usually don't care of ineffective blame, but don't like to be considered
stupid by their friends.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Claudio Telmon <[email-masked]>
Date: Wed, 24 Jun 2009 09:36:19 +0200

> needed to be solved, there are plenty of solutions already.

It could turn down to a private network in some cases, but in general
people would still be able to contact each other. But if you mean that
anybody should be able send messages to whoever he wants, and expect
that they are accepted unless they are collectively classified as
"spam", whatever this means (vs. being considered undesired by the
receiver), or sent by a misbehaved agent, this is not what I want. My
guess is exactly this, that a lot of people don't want it either, and
would appreciate to be able to use the current tools and protocols with
some control on correspondents. Cell phones are not a private network,
and people like to have (some of) this control.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 24 Jun 2009 10:34:14 +0200

> John Levine wrote:

...

> and people like to have (some of) this control.

There are some very big philosophic differences between "cell phones networks" and 
internet. Among them, internet is a "freedom space". And that's the main reason why spam 
is a difficult problem to solve.

You're right when you say that sometimes some people may want to use internet as a private 
network. But this is contrary to internet philosophy.

IMHO, there are little chance to see new standards allowing/enabling using internet as a 
private network. But if people want to  do it, the best way isn't to set up a new 
standard, but just creating a proprietary and closed protocol to set up his private 
network. No need to publish it, nor to create a RFC about it, just set it up with your 
friends.

A good example of consent is Donald Knuth. He has a web page explaining how to contact 
him. It's simple and efficient, and doesn't require any new standard to continue working.

   http://www-cs-faculty.stanford.edu/~knuth/email.html

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Jun 2009 10:22:37 +0100

--On 24 June 2009 10:34:14 +0200 Jose-Marcio Martins da Cruz 
<[email-masked]> wrote:

> There are some very big philosophic differences between "cell phones
> networks" and internet. Among them, internet is a "freedom space". And
> that's the main reason why spam is a difficult problem to solve.
>
> You're right when you say that sometimes some people may want to use
> internet as a private network. But this is contrary to internet
> philosophy.
>
> IMHO, there are little chance to see new standards allowing/enabling
> using internet as a private network. But if people want to  do it, the
> best way isn't to set up a new standard, but just creating a proprietary
> and closed protocol to set up his private network. No need to publish it,
> nor to create a RFC about it, just set it up with your friends.
>
> A good example of consent is Donald Knuth. He has a web page explaining
> how to contact him. It's simple and efficient, and doesn't require any
> new standard to continue working.

He uses a secretary to filter his email. If only we all had that resource. 
Instead, my 12,000 users have me and a bunch of rules that I maintain.

A better example of consent is spamcop. If you want to report a spam 
message to them, you can send it to an email address like 
[email-masked] where xxxxxxxxxxxxxxxx is an 
apparently random string. Perhaps it carries some cryptographic 
authentication which prevents others from using it, perhaps not, so I've 
obfuscated it. I can't remember how I got the string - probably from a web 
form - I just keep it in my address book.

I wonder whether creating a standard just makes the idea easier to attack 
through automated means. I have, for example, a mechanism that prevents 
people spoofing local email (ie pretending the sender is in our domain when 
the recipient is in our domain). I could have used something clever, but 
went for something simple and very easy to attack. However, it's still 
working some years later, and has in the meantime kept our internal email 
pretty spam free. If someone does attack it, I'll do something more 
principled.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 24 Jun 2009 11:57:19 +0200

Ian Eiloart wrote:

> 
> He uses a secretary to filter his email. If only we all had that 
> resource. Instead, my 12,000 users have me and a bunch of rules that I 
> maintain.

An automated secretary...

> obfuscated it. I can't remember how I got the string - probably from a 
> web form - I just keep it in my address book.

Well, you submited my message to spamcop... ;-). Their address was in the list of 
recipients...

> I wonder whether creating a standard just makes the idea easier to 
> attack through automated means. I have, for example, a mechanism that 

That's a good point.

> prevents people spoofing local email (ie pretending the sender is in our 
> domain when the recipient is in our domain). I could have used something 
> clever, but went for something simple and very easy to attack. However, 
> it's still working some years later, and has in the meantime kept our 
> internal email pretty spam free. If someone does attack it, I'll do 
> something more principled.

You're right. A standard will just work till the moment it will be cracked. And after that 
the standard will be droped down and people will go back to their own home made rules.

Either way, a good point to think when proposing a standard is if people is open to it. 
E.g., is spamcop open to replace their consent mechanism by a standard one ?

JM

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Jun 2009 11:59:23 +0100

--On 24 June 2009 11:57:19 +0200 Jose-Marcio Martins da Cruz 
<[email-masked]> wrote:

> Well, you submited my message to spamcop... ;-). Their address was in the
> list of recipients...

Sorry - was using my mail client's autocomplete to check the format. Forgot 
to delete the address <blush>. Actually, the report isn't complete until I 
confirm it, and spamcop probably won't be able to parse the report because 
my message to them didn't include your message headers.

Hmm, maybe some address harvester will harvest that address and start 
spamming spamcop directly, cutting me out of the loop! Perhaps I'd better 
try to change the address.

> You're right. A standard will just work till the moment it will be
> cracked. And after that the standard will be droped down and people will
> go back to their own home made rules.
>
> Either way, a good point to think when proposing a standard is if people
> is open to it. E.g., is spamcop open to replace their consent mechanism
> by a standard one ?
>
> JM

---

From: Seth <[email-masked]>
Date: Wed, 24 Jun 2009 12:00:52 -0400 (EDT)

Jose-Marcio Martins da Cruz <[email-masked]>

> internet as a private network. But this is contrary to internet

No, it isn't.  The Internet philosophy is "we ship bits around.
Interpretation is someone else's problem."

VPNs aren't against that philosophy, they're embraced by it.

Seth

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 24 Jun 2009 20:08:29 +0200

>> internet as a private network. But this is contrary to internet

Hmmmmm.....

> No, it isn't.  The Internet philosophy is "we ship bits around.

That's what spammers do...

> Interpretation is someone else's problem."

and this is what usual spam filters do.

In your idea, the problem is pushed into recipients. Consent pushes the problem to the sender.

Either way, I don't think we can agree.

> VPNs aren't against that philosophy, they're embraced by it.

Ther's a big difference between VPNs and consent.

VPNs are really private - information about VPNs instances (IP address of entry points, 
protocol, flavour, ...) aren't public and aren't available to unknown users.

Consent users information is public : Claudio Telmon email address is public and known by 
everybody.

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]

---

From: "Claudio Telmon" <[email-masked]>
Date: Wed, 24 Jun 2009 17:20:51 +0000

> try to change the address.

This is a joke you made me, isn't it? :)  Spamcop is using address tagging, and you happened to demonstrate what I said about the risks that tags get disclosed when sending messages to multiple recipients, since addresses may be in many places in the body of the message, whereas a specific header could be detected and purged by the MUA/MTA...

---

From: "Claudio Telmon" <[email-masked]>
Date: Wed, 24 Jun 2009 17:27:35 +0000

> the standard will be droped down and people will go back to their own home made rules.

I don't agree with that. A standard is a way many people can manage have good rules in an interoperable way. A good standard is peer reviewed and hard to break. Home made tricks usually just work for security through obscurity, and are not available to the community, which may try to invent tricks that usually don't work.

---

From: "Claudio Telmon" <[email-masked]>
Date: Thu, 25 Jun 2009 09:09:18 +0000

> Da: Jose-Marcio Martins da Cruz <[email-masked]>

I can't follow you on this. A telnet port is public, yet you must be welcome in order to use the service.The same for ftp, where you access the service, but the owner decides what to share with everybody (public ftp) and what to keep just for some buddies (authenticated). It has always been like this, Internet has been about sharing, but just what the owner wants to share. I choose this two very old services because they are part of the Internet since the beginning. This long before the Internet being about freedom, which is an issue that came up much later.

---
Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 25 Jun 2009 07:35:21 -0400

On Wed, Jun 24, 2009 at 09:36:14AM +0200, Claudio Telmon wrote:
> spam to the list.

(a) How would your friends know?

and

(b) What stops an attacker who has compromised Fred *and* Barney's
computer from using Barney's tokens from Fred's computer?  Keep in
mind that since the attacker has full control over both systems,
he/she also has, or can have, all of Fred and Barney's email
credentials -- login names, passwords, etc.

and

(c) I get the sense that this will scale as N^2, which doesn't bode well.

> impossible.

So you want me to stop using the mail client I've used for years --
which I've deliberately chosen because of its simplicity, speed,
features, and most importantly, security?

Not a chance.

Moreover, even if I had a mail client with an address book, why would
I want to put 11,500 people in it?  Especially since the overwhelming
majority of those communications are one-time?

> With respect to numbers, I cannot answer. People and

I'm already way too busy to even try to answer most of my email; where
am I going to get all the extra time needed to do this task?  Especially
given that there is no meaningful anti-spam value: if today I approve
a token from Fred, that doesn't help me at all if Fred's computer
is compromised tomorrow night and delivers 50 spam messages to me before
I wake up the next morning.  I could have done *nothing* and done just
as well.

> some of them? This would actually severely limit the usability of the

Two points; first:

If it's not automated, it won't scale.

If it's automated, then it will be faked billions of times and people
will quickly learn not to pay any attention to it.

Second: how am I going to communicate with correspondents "not by email"
when that's the only way I *have* to communicate with them?  You can't
seriously expect me or anyone else to spend out time IM'ing or phoning
or otherwise trying to convince people that their system is compromised.
I see several thousand attempts per day on this address alone that
are obviously from compromised end-user systems.

> "reinstall" their systems because they are full of garbage. [...]

We're now 6-7 years into the period when Windows systems are compromised
at will by attackers and used not just for spam, but for DoS attacks
and all kinds of other mischief.   Yet there has been no mass migration
away from these insecure and insecurable systems -- just a little bit
of movement here and there.  Your approach won't get them to change either.
They'll either (a) deny there's a problem (b) run some anti-malware tool
on their compromised system and believe what it says (c) get someone
else to do (b) or (d) in rare cases, get the system detoxed using
known-clean boot media or by starting over...but will then get it
re-infested a month later the same way they got it infested the first time.

---Rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 25 Jun 2009 13:37:46 +0200

Jose-Marcio Martins da Cruz wrote:
> VPNs are really private - information about VPNs instances (IP address 
> of entry points, protocol, flavour, ...) aren't public and aren't 
> available to unknown users.

They are available to allowed users (nearly) transparently. Once it is 
properly setup, users can run "internet" software that uses the 
existing connection --obviously including SMTP.

> Consent users information is public : Claudio Telmon email address is 
> public and known by everybody.

However, it is not enough to set up consent at the local server. Each 
user has to take care of tokens management in order for it to work. 
That's one way that consent pushes the problem to users.

AFAIK, there is no way SMTP can be configured so that a given sending 
location can be whitelisted. One can try and detect what MTA sends the 
message and whitelist specific filters, presumably doing detection by 
the IP address of each mailout. That's much like VPN: being at a 
higher level doesn't ease the task. For example, assume someone trusts 
Gmail's egress filtering and wants to skip content filtering for mail 
coming from there. What work is required to accomplish (and maintain) 
that task, on typical MTA software?

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Thu, 25 Jun 2009 14:54:43 +0200

> the IP address of each mailout. That's much like VPN: being at a higher 
> level doesn't ease the task. For example, assume someone trusts Gmail's 
> egress filtering and wants to skip content filtering for mail coming 
> from there. What work is required to accomplish (and maintain) that 
> task, on typical MTA software?

Hmmmm.... You're raising a problem which is similar to the problem of management of user 
preferences on a border smtp gateway. This isn't a problem at, say, gmail or mailbox 
providers as most of the time users have only one email address.

But talking about universities, or look alike organisations...

Myself, I have many **non shared** identities : only to cite two, the one you can see in 
this message and my login.

But also I have many **shared** identities. These identities correspond to email addresses 
  (administrative or not) which resolve to many people. I can hardly see some kind of 
management of *shared consent* for these addresses.

---

From: "Claudio Telmon" <[email-masked]>
Date: Thu, 25 Jun 2009 13:46:43 +0000

Da: Rich Kulawiec <[email-masked]>

> (a) How would your friends know?

They too get spam with my tokens, unless the spammer decided to just target the mailing list. Each of them will receive spam messages carrying the token they provided (just) to me

> credentials -- login names, passwords, etc.

Hmm, Maybe I don't understand the scenario. If the spammer uses the tokens he found on Barney's computer, he will be able to send spam to Barney's contacts, no matter from which computer. And, Barney's contact will know that Barney's computer has been compromised, since they gave that token to Barney, no matter where the message comes from. 

> (c) I get the sense that this will scale as N^2, which doesn't bode well.

I considered this issue, but I think it doesn't apply. It would be a problem if  some part of the system would need to deal with all of the tokens. However, each user will deal win N tokens, no matter if they are equal or different from the tokens others use. To be clear: each will have N addresses of their correspondents, which scale with N. Each will have N (well, 2N) tokens for their correspondents, even if they are different for each couple and scale with N^2. They won't see the difference, nor will any part of the system.
 
> features, and most importantly, security?

:) Each tool has some drawbacks. As we (almost) switched from telnet to ssh, people started to need keyrings, which are very similar in terms of usability. There was a good reason for this, which had to be evaluated by each person vs. the convenience of telnet. 
However, if you won't adopt the consent framework, you may still be required to insert tokens if your correspondents adopt the framework. But, if most (of your correspondents) agree with you and don't see a benefit from the framework, they won't adopt it either and you won't be required to put tokens in your messages.

> majority of those communications are one-time?

If a communication is one-time, you don't need to add the address to an address book, since you won't need to keep any token for future contacts. BTW, this may increase the use of short text-only messages for fast email exchanges, instead of html or similar. This kind of messages would fit the constraints of consent requests, and wouldn't require to actually manage tokens.

> am I going to get all the extra time needed to do this task?

The goal is to have less useless messages to deal with. If you have a very low noise/signal in your messages, then the framework probably wouldn't fit your need. I see it somehow as to publish the cell number and spend the time answering the (few?) undesired calls, instead of spending time giving the number only to people you want to talk with. 
However, I would avoid any evaluation based on personal taste (mine or yours), that's why I asked if there are available statistics on how many correspondents people have.

>  Especially

So you don't think that being able to tell Fred that he, and not "the Internet", is the reason why you receive spam, would not  help convincing Fred to keep his computer clean? I mean, if Fred cares about your opinion, which usually happens with at least some of our correspondents (and usually happens much less if the communication comes from some unknown person).

> If it's not automated, it won't scale.

It will, in my opinion, since it is distributed among the same people that increase the number. Saying that anything that is not automated won't scale is a bit too generic.

> or otherwise trying to convince people that their system is compromised.

Well, I do :) Either you are interested into communicating with them, or you're not. If you're not, just invalidate their token and avoid providing a new one. If you are interested, and you know that their system is compromised (don't think at the consent framework, it doesn't matter in this), wouldn't you search a mean to tell them? If someone I want to send mail to has some consistent delivery error, so that I cannot contact him by email, I usually manage to inform him through some other channel.
For what I understand and hear about social networks (actual social networks, not the services that support some), they are very effective in forcing people to a behaviour that is accepted by their peers. BTW, this is how the Internet managed to have a "netiquette" in the beginning. 
This interest in not having our peers as our main source of spam, is the "social" base for the whole framework, be it because you tell them, or because you invalidate their token.

> are obviously from compromised end-user systems.

These thousands of attempts are due to thousands of compromised systems, not to thousands of compromised correspondents of yours. The number of systems the spammer would use with the same token is not relevant, since they would all be blocked by invalidating that token.

>  Yet there has been no mass migration

Why should they? People is used to these problems, which to them seem to be part of ICT. However, I don't agree that a properly configured Windows system is that undefendable these days.
 
(b) run some anti-malware tool
> re-infested a month later the same way they got it infested the first time.

Well, they will do what they can. Which, in my opinion, would take us anyway to a much cleaner Internet than it is now.

---
---
Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: "Claudio Telmon" <[email-masked]>
Date: Thu, 25 Jun 2009 14:11:34 +0000

> Da: Alessandro Vesely <[email-masked]>

> that task, on typical MTA software?

It's not clear to me if you're asking how the consent framework would deal with the problem, but I can tell you.
Suppose that Gmail implements the consent framework in their MUAs. Then, MTAs could whitelist Gmail with respect to the consent framework. Let's see what it means to example.com's incoming MTA.
1. [email-masked] is not consent-enabled. Then the framework is not used, and nothing relevant happens, mail if acceptet/rejected as it currently is.
2. [email-masked] is consent-enabled, and a message arrives with proper headers/tokens; then, the framework is deployed and the message is accepted/rejected based on tokens (and some other usual controls), whitelisting is not relevant
3 [email-masked] is consent-enabled, a message without tokens arrives from address@gmail, and gmail is whitelisted; in this case:
- [email-masked] expressed the will to enable the framework;
- address@gmail can use the framework, since gmail is whitelisted, so the sender MUA implements the framework;
- however, the message has no proper token; this means that user2 didn't provide a token to the sender, and the message can be safely rejected, with no need to other controls
This way, nobody can send messages to [email-masked] with a forged address from any gmail address (unless the attacker manages to get a token from a user2's gmail correspondent). So, implementing the framework could be of some interest e.g. to banks, since accessing their token should be hopefully hard
4 [email-masked] is consent-enabled, a message without tokens arrives from address@gmail, and gmail is not whitelisted;
In this last case, we don't know if the message is without token because the token was not provided, or because the gmail MUA doesn't implement the framework and thus the token cannot be inserted in the message. It's up to the receiver to decide if the message sould be rejected, or handled as if user2 were not consent-enambled (that is, go through the usual checks), which is what would probably happen at least until the framework were widely implemented.
In any case, no work is required to the sender MTA, the sender domain/organization is only required to implement the framework support in the MUA

---
---
Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: "Claudio Telmon" <[email-masked]>
Date: Thu, 25 Jun 2009 14:58:10 +0000

> Da: Jose-Marcio Martins da Cruz <Jose-

If you mean by shared consent that all receivers must agree on consent, I think it can' t be done in a usable way. However, shared addresses usually mean that the consent of one of the receivers suffices. Then, from a technical perspective, it can be partially done. Anybody can distribute tokens for the address, and upload them to the MTA database. Since it is the MTA database that matters for filtering, messages will be properly accepted/rejected. Should a token need to be invalidated, any of the receivers should be able to do it, even if the token is not in his7her address book, again because its the token on the MTA that matters. However, they will need to cooperate in order to understand e.g. whose system has been compromised, since only one will probably have associated the token to an address. 
The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue.

---
---
Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Thu, 25 Jun 2009 17:22:33 +0200

> The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue.

This is something which appear in other situations too : like users preferences management 
(enable filtering, filtering threshold, ... to name some of them).

You can't do any inference about what to do : unanimity, majority, one win, ...

Eventually, the border SMTP gateway just know that an address [email-masked] shall be 
routed to [email-masked], but [email-masked] will be expanded into a dozen 
address, when reaching the mailserver of dept.domain.com (which aren't known from the 
border gateway).

The other problem I mentioned is multiple addresses (jose-marcio.martins_da_cruz, 
jose-marcio.martins, martins, ...). I can't imagine managing preferences for each 
identity, nor a system telling that each address is equivalent to some other one, in a 
domain with, say, 10000 or more users.

Unless you're able to build an "usine à gaz" (as we say in France), with preferences for 
each valid address, there isn't a clean solution.

---

From: Seth <[email-masked]>
Date: Thu, 25 Jun 2009 12:11:11 -0400 (EDT)

> That's what spammers do...

And pirates, and people sending email to their aunts, and people
making VOIP phone calls to their lovers, and . . .

That's what using the Internet _means_.

> and this is what usual spam filters do.

And every application likewise.

> In your idea, the problem is pushed into recipients.

I didn't say that.  The Internet moves bits around; that's what IP
does.  You put a packet into the Internet, with a specified
destination address, and the Internet gets it there (or not).

> Consent pushes the problem to the sender.

Consent is at a higher level, just like interpretation (though consent
is around level 9).

> Ther's a big difference between VPNs and consent.

They aren't anywhere near the same thing.  Why are you comparing them?

> VPNs are really private - information about VPNs instances (IP
> address of entry points, protocol, flavour, ...) aren't public and
> aren't available to unknown users.

Whether or not they are is up to the owner of the equipment providing
the VPN.  (Hint: encrypted proxies are VPNs, and with the current
events in Iran there are a lot of public ones.)

> Consent users information is public

What does that mean?  Information that is mine is public to the extent
I publicize it.

> Claudio Telmon email address is public and known by everybody.

Very unlikely.  Even "[email-masked]" isn't known by
_everybody_.

And I personally have hundreds of email addresses, each of which is
(or should be) known by precisely one entity.

Seth

---

From: Danny Angus <[email-masked]>
Date: Tue, 23 Jun 2009 23:14:08 +0100

I've skimmed your paper, it seems very well thought out, I also believe that
a distributed consent system, or more accurately distributed  rules denying
consent, would be beneficial as it would allow any "upstream" MTA to discard
messages for which a rule existed saving downstream MTA's & MUA's from the
effort of even considering them.

I tried some time ago to articulate some tests which any proposal ought to
at least acknowledge, which you can find here..
 http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html

You may find them helpful.

I'll try to find time to give your paper fuller attention.

d.

On Sun, Jun 21, 2009 at 10:25 AM, Claudio Telmon <[email-masked]> wrote:

> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
>

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 11:17:29 +0100

--On 24 June 2009 17:20:51 +0000 Claudio Telmon <[email-masked]> wrote:

>
>> > Well, you submited my message to spamcop... ;-). Their address was in
>> > the list of recipients...
>>
>> Sorry - was using my mail client's autocomplete to check the format.
>> Forgot  to delete the address <blush>. Actually, the report isn't
>> complete until I  confirm it, and spamcop probably won't be able to
>> parse the report because  my message to them didn't include your message
>> headers.
>>
>> spamming spamcop directly, cutting me out of the loop! Perhaps I'd
>> better  try to change the address.
>>
>
> This is a joke you made me, isn't it? :)  Spamcop is using address
> tagging, and you happened to demonstrate what I said about the risks that
> tags get disclosed when sending messages to multiple recipients, since
> addresses may be in many places in the body of the message, whereas a
> specific header could be detected and purged by the MUA/MTA...
>

A fair point. Some of the same considerations apply, though, especially 
with regard to obtaining the token.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 11:22:50 +0100

> and this is what usual spam filters do.

You miss his point. You're talking about senders and recipients, he's 
talking about different protocol layers (IP versus VPN, perhaps). For an 
Internet application like VPN or SMTP to work, both the sender and the 
recipient need to have the same interpretation of what the bits mean.

Similarly, a conversation is just exchange of words, for it to be useful, 
both the sender and receiver need to have (at least to some approximation) 
the same interpretation of each word. ;)

> VPNs are really private - information about VPNs instances (IP address of
> entry points, protocol, flavour, ...) aren't public and aren't available
> to unknown users.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2009 13:37:59 +0200

> gradual, albeit less effective transition path is required.

Your are right, in turn: after reading the "deployment" section, it is 
fairly clear that a transition is not necessary. I'm not sure how well 
point "Voluntary participation" 2.3.9 of Danny's criteria connotes 
your framework as not being an anti-spam technique. I think it may 
actually have more chances when explicitly targeted to guard children, 
rather than generically "non FUSSP".

---

From: Claudio Telmon <[email-masked]>
Date: Sat, 27 Jun 2009 18:02:04 +0200

Alessandro Vesely wrote:

> point "Voluntary participation" 2.3.9 of Danny's criteria connotes your
> framework as not being an anti-spam technique. I think it may actually
> have more chances when explicitly targeted to guard children, rather
> than generically "non FUSSP".

I considered to use terms like "protected mailboxes", but at the end it
didn't like it, since it describes an expected effect (protection) and
not what is actually done (enabling the framework). Also, while the
"children" case is a clear one, I think that many other classes of users
could benefit from this option. I only used the term FUSSP in the
message to this list :)
Anyway, the "voluntary participation issue" is probably not clearly
stated in the document. If I enable the framework, you're not forced
into enabling the framework, you just won't be able to communicate with
me. The same happens if I enable https on my webserver: you're not
forced into adopting https, you just won't be able to access my content,
you can access the rest of Internet. This doesn't make https a "non
voluntary" protocol.

BTW, there is still a couple of points in my paper on which I would
really like to have a comment from this list. One is the key point that
spam (at least, UBE) respecting the constraints of consent requests,
that is "short text-only messages", would reduce the workload for MTAs
with respect to protected/consent-enabled addresses. This wouldn't be
true e.g. if most filtering is actually made on the envelope.

Also, I suppose that the burden of dealing with the token database on
the MTA is not a big issue for the MTA itself (not for the user), but
you surely know better.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 28 Jun 2009 15:06:12 -0400

> fundamental to combatting spam.

You're correct that we're in that position: we see it everywhere,
from Google's needlessly-obfuscated Usenet archives (like spammers
don't have their own NNTP feeds and haven't already harvested all email
addresses long before Google publishes them) or the presence of
address-obfuscation code in mail archivers (e.g., even the notes
on the newest/development version of Mailman talk about the need
for such obfuscation).

And I _think_ we're in concurrence that it's a pointless waste of
code and effort: spammers either have or will have soon any address
that's actually used.  (And will successfully guess at many that exist
but aren't used.)

The meta-problem we face is that "cargo cult" mentality that persists
in the belief that it's possible to hide addresses from spammers.  I've
found it quite difficult to dislodge, and -- as I commented elsewhere --
am often by the irony that the people prattling the loudest about it
are running Windows on their desktop/laptop are thus stand a reasonable
chance of being the primary vector by which their address(es) is/are
harvested by spammers.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 29 Jun 2009 07:31:56 -0400

On Thu, Jun 25, 2009 at 02:54:43PM +0200, Jose-Marcio Martins da Cruz wrote:
> But also I have many **shared** identities. These identities correspond 
> to email addresses  (administrative or not) which resolve to many people. 
> I can hardly see some kind of management of *shared consent* for these 
> addresses.

A brief check of my own procmail config indicates that I'm on over 500 of
these -- the overwhelming majority of which are role addresses such as
those specified in RFC 2142.  A secondary check indicates that about 3/4
of those are shared with one or more other people, which means I'd have
to work out some kind of "shared consent" for several hundred addresses.
That's not feasible in a reasonable period of time, especially since
neither the addresses nor the pool of people they're shared with are static.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 29 Jun 2009 08:08:26 -0400

On Thu, Jun 25, 2009 at 01:37:46PM +0200, Alessandro Vesely wrote:
> egress filtering and wants to skip content filtering for mail coming from 
> there. What work is required to accomplish (and maintain) that task, on 
> typical MTA software?

Yes, MTAs can be configured so that a given sending location -- that is,
IP address -- is whitelisted.  I do it all the time.  But it's not a
very good solution, and it doesn't scale.  Moreover, it's brittle: if the
sender's outbound mail server changes its address, then it stops working.
Conversely, if someone else acquires that server's previous address,
then it starts working for someone I didn't intend it to work for.

Level of work?  I think, roughly speaking, it's one or two lines of
configuration with most MTAs.  But (as I think you're pointing out) the
actual configuration itself isn't the issue: it's the time and effort
that it takes to figure out what should be in the configuration, and
then to maintain it.

---Rsk

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 29 Jun 2009 15:12:12 +0200

> neither the addresses nor the pool of people they're shared with are static.

Well, I suppose that most of those mailboxes shouldn't be
consent-enabled anyway. Addresses like "abuse" or "postmaster" are meant
to be contacted by anybody that needs it, right? The same for the
official contact addresses of companies.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Jun 2009 16:46:37 +0200

Claudio Telmon wrote:
>> I think it may actually 
> I considered to use terms like "protected mailboxes", but at the end I 

What about "adult-assisted mailboxes"? Besides the fact that you could 
adapt an MTA to do mixed enabled and non-enabled reception on the same 
email address, if the two addresses correspond to different persons, a 
child and a supervising adult, you don't have to. Targeting children 
does not necessarily imply that adults refrain to self assist 
themselves, if they like.

Having a clear case would help working out the specification details 
that are currently missing. (How much software is needed? What exactly 
should each piece of software do? Do both mailboxes have to be on the 
same host? And the database? Etc.) In addition, it may help reckoning 
a potential user base. Finally, anything that helps to protect the 
children may get the attention of specific organizations.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Mon, 29 Jun 2009 17:37:51 +0200

> to be contacted by anybody that needs it, right? The same for the

No !

> official contact addresses of companies.

In fact, at our domain, few of these kind of adresses aren't protected. Most of them are 
adresses of the kind "everybody in the engineering department" (addresses which are of 
internal use only) "butterfly research workgroup" (a closed group working on some 
particular subject) and so. These are adresses which *are* protected and the concept of 
consent-enable is materialized by checking if the SMTP client sending messages to is in 
some known network or if the connection was authenticated. But nothing prevents that this 
kind of consent should be expanded. Either way, in an organisation like the ours, users 
couldn't understand that the same consent system used for individual addresses couldn't be 
used for collective addresses.

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 29 Jun 2009 18:04:21 +0200

>> to be contacted by anybody that needs it, right? The same for the

I'm just saying that RFC 2142 are not meant to be consent-enabled.
Anybody should be able to contact these addresses, but:
- other (antispam) protections may well be enabled;
- other shared addresses may be meant to be "for closed groups" or
consent-enabled

> In fact, at our domain, few of these kind of adresses aren't protected.
> Most of them are adresses of the kind "everybody in the engineering
> department" (addresses which are of internal use only) "butterfly
> research workgroup" (a closed group working on some particular subject)
> and so. These are adresses which *are* protected and the concept of
> consent-enable is materialized by checking if the SMTP client sending
> messages to is in some known network or if the connection was
> authenticated. But nothing prevents that this kind of consent should be
> expanded. Either way, in an organisation like the ours, users couldn't
> understand that the same consent system used for individual addresses
> couldn't be used for collective addresses.

This is a very interesting case. I'll have to think at the implications
of it.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 29 Jun 2009 18:27:32 -0400

> official contact addresses of companies.

In some cases, yes: certainly "abuse" is a role address that should be
reachable by everyone.  But for a counterexample, the "-request" and
"-owner" addresses corresponding to various mailing lists don't need
to be.  (Neither do some mailing list addresses.)  It's turned out to
be rather complicated in practice to figure out what policies each
role address should use, doubly so when there are sharply differing
opinions among the people sharing those addresses.  I can't claim to
have any "good" answers to this, only "adequate" ones.

---Rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Jun 2009 10:41:48 +0200

Rich Kulawiec wrote:
>> location can be whitelisted. [...]
> 

Thanks for confirming that. My feeling is that we are overloading IP 
numbers with an accountability functionality that doesn't belong there.

For a different approach, there is a Message Security Level[1] SMTP 
extension that allows the above configuration to be written as

  example.com:  /SECURITY=STARTTLS

for each destination domain. That way, on can establish secure mail 
delivery channels between trusted domains, connected by an untrusted 
public network. It works by recognizing the certificates rather than 
the IP addresses. The option configured merely requires that TLS is 
used at each hop; it may be specified on the MAIL FROM command.
1: http://www.courier-mta.org/draft-varshavchik-security-smtpext.txt

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Tue, 30 Jun 2009 12:16:59 +0200

> This is a very interesting case. I'll have to think at the implications

You got the message ! 8-)

And as said Rich, I'm only pointing you points to taking into account.

---

From: Claudio Telmon <[email-masked]>
Date: Tue, 30 Jun 2009 23:46:05 +0200

Jose-Marcio Martins da Cruz wrote:

> The other problem I mentioned is multiple addresses
> (jose-marcio.martins_da_cruz, jose-marcio.martins, martins, ...). I
> can't imagine managing preferences for each identity, nor a system
> telling that each address is equivalent to some other one, in a domain
> with, say, 10000 or more users.
> 

I need some more clarification on this, maybe it's just me not knowing
enough about MTAs internals. As the border MTA receives a RCPT TO for
either of these addresses, it should be able to know if it is a valid
address. In my (very limited) experience, this means that each of these
addresses mut be defined as a valid address, the MTA doesn't have rules
to decide that since jose-marcio.martins_da_cruz is a valid address,
jose-marcio.martins must be valid too. So, if each of these addresses is
individually defined in some list/database accessed by the MTA, then
with the same rules, the related token database should be accessed too.
Should an "automatic aliasing" rule exist, then the same rule could
exist for the token database. Also, if "somewhere" an alias is defined
for an address, then the correspondent database could just be a pointer
to the database of the "main" address. This could even implement "chains
of aliases" as "chains of pointers to token databases".
This unless you use forwarding, which is not aliasing and which should
be handled as having different addresses.
Now, from the user perspective, the address book management tool could
just keep a "default" token database, that is valid for each address the
user send messages from. So, each time a correspondent is added, the
appropriate token is pushed on the MTA databases for all the user's
addresses. While this may seem a lot of work and "database space", again
this should be in fact fully automated and need very little space
compared to current mailbox sizes. Should there be a specific address
that needs different tokens for different addresses, this could be
explicitly set when adding the address to the address book. Again, since
it is just the address owner that knows if a correspondent is permitted
to send messages to one address and not to an alias, there is no
solution but to involve some manual handling by the user.

> Unless you're able to build an "usine à gaz" (as we say in France), with
> preferences for each valid address, there isn't a clean solution.

I think this is feasible with an appropriate address book manager.
Anyway, the load is for the MUA, not for the MTA, so the number of users
shouldn't matter.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org