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(_at_)telmon(_dot_)org
http://www.telmon.org
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg