Subject: [apps-discuss] Is e-mail going to die?

From: Jacob Palme <[email-masked]>
Date: Sat, 15 Jun 2013 18:52:46 +0200

I wrote a message in November 2012 which is quoted at the end of 
this message.

One thing I am noting since then is that other message systems 
are more and more used instead of email.

Examples of such alternative messaging systems are SMS, Facebook 
and Kik.

Large companies more and more are telling people who want to 
communicate with them to use a special web page instead of e-mail. 
Banks only allow me to communicate through a message system where 
I first have to log in to my bank account before sending and 
receiving messages to and from my bank. Other companies may do the
same.

It would not surprise me if email will die out, or rather will be less
and less used as alternative messaging systems will replace email,
so that in a few years most internet messaging will be done using
another protocol than email.

The reason why email may die out, is that email has not succeeded
to ensure that I get all messages I want, but not a large number
of unwanted messages (spam). Email is therefore not percieved as 
reliable. Some other network will be percieved as more reliable.

There are anti-spam systems like SpamSieve and SpamFire, but they
have the problem that sometimes wanted messages are wrongly filtered
out. And to manually read the mailbox containing all messages which
have been filtered out, will mean that I do not get the advantage
with spam filters - I have to scan through a list of all spam
messages, and this is what the spam filters are meant to avoid.

Even though there are technical problems, I still believe that
email's opportunity to succeed is to replace email into a system
where the sender pays a fee, say $0.10 per recipient, for sending
messages. The old, unpaid system can continue to live in parallel
to the new system.

This new e-mail network should use all the existing standards,
technology and client and server software which e-mail is using
today. That would be a huge advantage compared to competing
systems like SMS, Facebook and Kik. I would enter my ordinary email
client, and first see all messages for which the sender paid a
fee, and then, if I have time, also see unpaid email. Probably
I would sort the old, unsafe mail into an alternative mailbox
than my ordinary inbox.

The new mail network will probably not get much spam, because spammers
will not be willing to pay $0.10 per recipient for sending messages.
And since spam filters are not needed for messages arriving through
the new network, there is no risk that messages which are important
to me will be filtered out by mistake.

Certainly there are technical problems with such a new email network.
For example handling of mailing lists - you should not have to pay
for every member of a mailing list when you post to the list.
Technical problems have to be overcome.

But having more and more messages sent through alternative networks
like SMS, Kik and Facebook is not a happy future. We who have spent
a lot of effort into making email into a good standard will not be
happy if our effort has been in vain, and if some competing system
will replace e-mail as the major messaging system on the internet.

On 8 nov 2012, at 17.58, Jacob Palme wrote:

> Talk to ordinary people, people who are not technical experts, as we are in this mailing list. Ask them what is good and bad about the Internet. You will find that most people will answer that spam control is IETF's largest failure.
> 
> IETF started as a network for university people. They wanted a network to make interconnection between university and research people easy. They had no expectation that these people would misuse the network such as spammers do today.
> 
> The root of the problem is that the cost of seinding e-mail is so low. You just submit your message, no fee, and a network of SMTP servers is eager and willing to forward your message to thousands or millions of recipients. We even get messages which ask us to buy software which makes it easy to forward your message to many recipients. Companies collect e-mail addresses from various sources and sell lists of millions of e-mail addresses for a low cost.
> 
> The only solution which works is to make it more expensive to send messages. IETF should establish a new network, independent of the present e-mail forwarding network, with separate mail servers (SMTP, POP, IMAP servers) using new, separate ports for spam-free e-mail. The main difference is that there should be a charge, perhaps 0.10 dollars, to submit e-mail. 0.10 dollars per recipient when you submit your message. The new network should use cryptographic methods to stop bandits from using it without paying this fee. The money collected from paying clients should use to further recognize and stop any spammers which might get into the new network. But the important thing is not to detech and stop spammers - this has been tried for many years and thus not work. The important thing is the fee per recipient for submitting messages into the new network. Spammers will not be willing to pay this cost. Their business model is built on the idea that you can for a negligible cost submit mail to millions of recipients. Their business model will collapse if they have to pay for submitting messages.
> 
> I expect that recipients will be happy to recieve messages from the new spam-free network.
> 
> There are, of course, problems with this solution.
> 
> One large problem is mailing lists. Mailing lists, such as the one to which I am sending this message, will be too costly if the list maintainer has to pay a fee for every recipient. And people who submit messages to mailing list may not be willing to pay 0.10 dollars for every member of the maling list. The solution will have to allow exceptions from the 0.10 dollars/message for messages coming from mailing lists. There should be some kind of authority, established by IETF, which identifies serious mailing lists which are allowed to forward messages to members of mailing lists. However, the 0.10 fee will pay for the cost of running such an authority body.
> 
> Another possible problem might be spammers who are willing to pay 0.10 dollars/recipient because they are able to identify recipients who will buy the product they are selling, so that the 0.10 dollar is acceptable cost. However, if a message is so interesting to recipients that senders are willing to pay 0.10 dollars per recipient for the sales message, then the recipients may be willing to read this spam and not regard it as spam.
> 
> The new network should run in parallel to the present mail networks. Protocols should be mostly the same as those used today for the mail networks used today. Recipients will have to modify their POP or IMAP client so that it collects mail from two networks, the old spam-allowing network and the new spam-safe network. Mail reading clients will either put incoming messages into two "In" folders, one for the new spam-free mail and another for the old spam-containing net. Or alternately mark messages with different colors for messages from the spam-free and spam-containing net. The result may be that most people will not want to download any message from the old network. But if that is the case, it just shows the value of establishing a spam-free network.
> 
> The establishing of a spam-free network, based on a fee per recipient for sending messages, will not be entirely easy. Some people may not be willing to pay for sending messages. Especially senders of private mail may not be willing to pay. The running of two parallel mail networks, one for spam-safe and one for non-spam-safe messages, will be a major effort for the IETF. But the gain is so large, and many people will be so happy for getting spam-free messages, that this is an effort which will cause people to thank IETF for the effort of establishing this new mail network.
> 
> The income of 0.10 dollars per recipient will allow paying the cost of running the new spam-safe mail network.
> -- 
> Jacob Palme <[email-masked]>, university professor emeritus
> for more info see URL: http://www.dsv.su.se/jpalme/
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Professor Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 15 Jun 2013 21:59:20 +0300

> are more and more used instead of email.

Email usage still keeps growing though.

> Examples of such alternative messaging systems are SMS, Facebook 

Companies don't use those to communicate.

> receiving messages to and from my bank. Other companies may do the

I don't see that happening. Sure, for banks and other such institutions that actually require secure mail a regular email won't currently really work (a bank can't force customers to encrypt their mails before sending them and leaking confidential data). I doubt it's going to catch on to many other companies though.

> messages. The old, unpaid system can continue to live in parallel

http://www.taugh.com/epostage.pdf was mentioned as a reply to your last post, which I think describes pretty well why I doubt any actual money transactions aren't going to work. But I do wonder how far people have thought about using hashcash. I haven't really followed antispam efforts myself.. but I'd think a hashcash and some crypto combination could be made to work, if enough people show interest. A high level plan:

 - Every time you send a mail to a new contact, you'll have to pay with hashcash. The recipient SMTP server specifies the cost requirement and rejects the mail at RCPT TO stage if the payment isn't given.

 - For big ISPs/webmails and such the cost would have to be offloaded to the actual sender client, not the sending SMTP server. Yes, some slow clients might have to calculate it for minutes and show the user a progress bar showing how long it's going to take. ISPs could also sell this as a service to do it on the server side. Users could also opt to send it the old way and hope it gets through.

 - Each email you send to someone will contain a crypto key header that allows the recipient to send you back emails without calculating the hashcash.

 - Mailing list subscriptions would be done by sending them an email with the crypto key, which mailing lists can remember to make it free for them to send you the actual mails.

 - A crypto key would be specific to a single email address, so the crypto key headers could be thought of as public information. This requires SPF/DKIM to be enabled for the senders.

 - If your private crypto key gets leaked, you need to switch to a new one. This wouldn't be too bad, except you'd have to re-subscribe to the legitimate mailing lists, which perhaps could be automated with some extra work.

 - During transition phase this would basically just affect the spam scoring, so this could be implemented incrementally.

 - Requires new software for sending and receiving SMTP servers to be able to use this, but not necessarily new email clients. Webmail providers could calculate hashcash using Javascript on the background during composing the email. The main problem would be the old IMAP/POP3 clients trying to use free email providers.

I don't see any obvious reason why the above couldn't work, other than the huge amount of work required and convincing all the major players to implement it. And it of course wouldn't completely eliminate spam, but it would make it much more costly, hopefully dropping the amount of spam from 99% of all mails to a few %. Botnets aren't free to use either.

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2013 21:18:52 -0000

>> are more and more used instead of email.

The death of e-mail has been regularly predicted for over a decade.
It remains the best way to communicate between entities over the
Internet because it doesn't require that you go poll every different
place that might want to send you something.

>http://www.taugh.com/epostage.pdf was mentioned as a reply to your last post, which I think
>describes pretty well why I doubt any actual money transactions aren't going to work. But I
>do wonder how far people have thought about using hashcash.

Far enough to realize that through the magic of bot nets, the bad guys
have far more resources to burn than the good guys.  (Keep in mind
that the bots doing the computing don't have to be the same ones that
are sending the spam.)  Hashcash also has all of the same white listing
problems of any other epostage scheme.  My paper you cited says that
on pages 4 and 5.  I haven't updated it since 2004, but nothing of
importance to the analysis has changed.

I ran into Cynthia Dwork, who invented hashcash, at a conference a few
years ago and she concurred.

R's,
John

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 16 Jun 2013 01:20:54 +0300

On 16.6.2013, at 0.18, "John Levine" <[email-masked]> wrote:

> are sending the spam.)  

Bad guys have a lot of computing power, but not more than the legitimate guys sending mail. If the hashcash is made expensive enough, at some point generating them would require so much computing power that all the botnets wouldn't have enough enough power to send the amount of spam they are sending now. And I've understood that many spammers still pay for the use of botnets, and that they could be sold for other purposes as well (becoming more lucrative than spamming at some point). Or assuming that the bad guys actually buy the CPU power from AWS and such, the hashcash would just need to be slow enough that it wouldn't be worth the cost for most spammers.

So the question is mostly about how much would we be willing to waste CPU cycles for sending legitimate mails. With whitelisting the hashcash would only need to be done during the initial introduction, whereas spammers would need to do it to all the mails. The introduction hashcash could also be avoided entirely by sending the whitelist token out-of-band (e.g. as part of a vCard you send to someone). And all of the hashcash calculations could be outsourced to the end user clients, where it wouldn't necessarily even be a huge problem if the calculation for a single recipient took even a minute. (A side bonus: People mass-Cc'ing 1000 people within a company would have to wait a long time for it to finish, hopefully causing the sender to rethink if they really intended to do that. :)

> Hashcash also has all of the same white listing

I think the main idea in my previous mail that I hadn't seen before, was about how the whitelisting could be implemented in a pretty practical way using cryptographic tokens. It would go a long way without requiring anyone to even have a "whitelist database", because the whitelist token would be in the email itself that you're replying to. And in particular the receiving SMTP servers wouldn't need a whitelist database, they could simply verify that the token is a valid digital signature for the sender+receiver combination (using a single cert+private key). The email clients would ideally store received tokens to the address book for future use, or this could also be done at SMTP/IMAP level.

After a bit of googling, I found that CAMRAM attempted something similar, but since its web page is gone I'm not sure how exactly it worked. I think it was more complex than what I was envisioning.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Jun 2013 15:27:26 -0700

> are more and more used instead of email.

This is a remarkably poor choice of venue for discussing hypothetical 
industry usage trends.

And as raised, it's a topic that lacks any utility, no matter where it's 
discussed.

If there's a technical proposal or a technical criticism to consider, 
lets' hear it.

Otherwise, the topic is entirely noise to the list.

d/

ps. and as John L. notes, the topic isn't new, nevermind the irony of 
trying to discuss it through the medium that is purportedly vanishing...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Nico Williams <[email-masked]>
Date: Sat, 15 Jun 2013 18:08:38 -0500

> messages. The old, unpaid system can continue to live in parallel

This again.  Once in a while someone proposes this nonsense again.

Stop it.  It won't happen, and anyways, this is the wrong forum for
you.  If you want it to happen you'll have to get Google, Yahoo!, and
others to stop providing free e-mail services, but they make real
money off of free email services.  And you'd have to figure out who
gets paid these fees, who gets a cut, ...  You'll find it'd probably
have to be a tax in order for it to be fair at all.

You'd have to be *bigger* than Google, Yahoo!, and friends to get this
to happen, or come up with a new business model for Google and
friends.  The only entities that can pull this off today are
governments, and this is the wrong forum for lobbying governments
though.

So please stop it, stop bringing this to us.  It's *boring*.

Maybe we should have a filter for "$0.10" anti-spam spam.

Nico
--

---

From: "John R. Levine" <[email-masked]>
Date: 15 Jun 2013 19:29:58 -0400

> Bad guys have a lot of computing power, but not more than the legitimate 
> guys sending mail.

Bad guys have multiple botnets with 100,000 nodes or more.  Of course they 
have more than the legitimate senders.  There probably aren't 100,000 
legitimate mail servers in the whole world.

> So the question is mostly about how much would we be willing to waste 
> CPU cycles for sending legitimate mails.

The answer hasn't changed in a decade -- nowhere as many as the bad guys 
have, by orders of magnitude.  There is also the "everyone in the world 
has to implement my FUSSP" problem, of course.

> I think the main idea in my previous mail that I hadn't seen before, was 
> about how the whitelisting could be implemented in a pretty practical 
> way using cryptographic tokens.

The technology isn't the problem, it's the social part of bad guys gaming 
the system by persuading people to whitelist them and then spamming.

By the way, there's nothing in this discussion so far that we couldn't 
have said a decade ago.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 16 Jun 2013 02:30:52 +0300

> So the question is mostly about how much would we be willing to waste CPU cycles for sending legitimate mails. With whitelisting the hashcash would only need to be done during the initial introduct…

Actually the more I think about this the more I like it. If each user is able to specify how costly hashcash they want, it would effectively become a negotiation between the sender and the receiver about how much the sender wants to send the email vs. how much the recipient wants to receive it. So for example:

 - [email-masked] - Company wants a lot of sales, so hashcash could be very small, even nonexistent.
 - [email-masked] - Medium large hashcash to avoid most spam
 - A very public person might have a very large hashcash. Bill Gates's spam would drop from millions of mails a day to almost nonexistent if his hashcash took 1 week of CPU time to calculate.

The more someone would get spam, the higher they could increase their hashcash to get rid of it (at the expense of the new initial contact senders). So the price of electricity for the sender would make sending the mail a real cost, and the less the recipient wants emails the more the sender would have to pay for it.

I think a lot of the things previously against hashcash/whitelisting don't really apply anymore:

 - SPF/DKIM prevents spoofing and is getting more and more popular anyway (having this working correctly for the sender would be a requirement)

 - Too expensive for GMail/Hotmail/etc. They can simply offload this to client's Javascript. Google would probably even be happy to advertise to people: "Sending email is too slow? Switch to Chrome to make it 10x faster!"

 - Mailing lists can avoid hashcashes entirely using the methods I mentioned earlier.

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 16 Jun 2013 02:42:23 +0300

On 16.6.2013, at 2.29, "John R. Levine" <[email-masked]> wrote:

>> Bad guys have a lot of computing power, but not more than the legitimate guys sending mail.
> 
> Bad guys have multiple botnets with 100,000 nodes or more.  Of course they have more than the legitimate senders.  There probably aren't 100,000 legitimate mail servers in the whole world.

There are actually millions of mail servers in the world (6M SMTP servers by my count a year ago). But more importantly: There are hundreds of millions of email senders! If each email sent required at minimum 30 seconds of CPU time (from the *user's device*, not the email server), a 100k node botnet could send only 288 million mails a day. To send the 30 billion spams/day they do now would require 1000 such botnets. (And if the botnets used 100% CPU all the time, I'd think that the people owning the machines would at some point start to wonder about their electricity consumption, reducing the botnet's size.)

>> I think the main idea in my previous mail that I hadn't seen before, was about how the whitelisting could be implemented in a pretty practical way using cryptographic tokens.
> 
> The technology isn't the problem, it's the social part of bad guys gaming the system by persuading people to whitelist them and then spamming.

I don't see how that could be a big problem. If I accidentally do whitelist a bad guy's email address, I could just then just blacklist that one specific address and the spam would be gone. But yes, such blacklists would make this more complex. But then again it would still make the situation significantly better than it is now. Spam filtering will always be required anyway, just the spam amount would be far less than now.

> By the way, there's nothing in this discussion so far that we couldn't have said a decade ago.

I listed a few things that have changed in the mail I just sent.

---

From: "John R. Levine" <[email-masked]>
Date: 15 Jun 2013 19:55:54 -0400

> There are actually millions of mail servers in the world (6M SMTP 
> servers by my count a year ago). But more importantly: There are 
> hundreds of millions of email senders! If each email sent required at 
> minimum 30 seconds of CPU time (from the *user's device*, not the email 
> server), a 100k node botnet could send only 288 million mails a day. To 
> send the 30 billion spams/day they do now would require 1000 such 
> botnets. (And if the botnets used 100% CPU all the time, I'd think that 
> the people owning the machines would at some point start to wonder about 
> their electricity consumption, reducing the botnet's size.)

Your numbers are vastly different from the numbers I hear at MAAWG 
meetings.  There may be millions of hosts that respond on port 25, but 
there aren't millions of hosts sending mail that anyone wants to get. 
(That's SMTP servers, not submit clients.)

In any event, the suggestion that everyone in the world wait an extra 30 
seconds every time they send a mail message is so absurd that I don't see 
much point in continuing the discussion.

R's,
John

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 16 Jun 2013 03:13:57 +0300

On 16.6.2013, at 2.55, "John R. Levine" <[email-masked]> wrote:

> Your numbers are vastly different from the numbers I hear at MAAWG meetings.  There may be millions of hosts that respond on port 25, but there aren't millions of hosts sending mail that anyone wants to get. (That's SMTP servers, not submit clients.)

Yeah, I meant the number of hosts responding to port 25. But that's irrelevant anyway, since my plan was to make the clients do the calculation in most situations. (The 30B spams/day I just found with google.)

> In any event, the suggestion that everyone in the world wait an extra 30 seconds every time they send a mail message is so absurd that I don't see much point in continuing the discussion.

I've been typing this mail already for well over 30 seconds. The hashcash would have been calculated already by now without any extra wait by the time I send the mail. And that would have been necessary only the first time I sent you an email, for further replies the mail would have been whitelisted (since you also sent me a private reply, which would have contained the whitelist token). At least 99% of the emails I send go to either mailing lists or replying to other people's mails, and all of them would be whitelisted already (except if there were new Cc'd people).

I think this is nearly practical enough to be implemented and if used widely to significantly reduce the amount of spam. The important part is that the recipient decides how costly the sending would be, and the sender can then decide if it's worth it even. And that this is a technological solution that requires nothing more than software upgrades to become used, and it can be done incrementally. But I can see why overall people don't think implementing all this is worth the trouble. Even though people complain about spam, the filtering works well enough nowadays that they aren't demanding something better.

---

From: Franck Martin <[email-masked]>
Date: Sat, 15 Jun 2013 21:23:50 -0500 (CDT)

Email has been pronounced dead so many times, we should call it zombie messaging!

Printed on recycled paper!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 15 Jun 2013 21:57:23 -0700

On Sat, Jun 15, 2013 at 9:52 AM, Jacob Palme <[email-masked]> wrote:

> [...]

The death of email has been predicted more times than I can remember.  At
no point in my career have I ever been told we need to throttle back on
email related infrastructure because volumes are dropping.  Some large
companies do their own private message systems where the communication is
highly sensitive (banks, hospitals, the IRS), but they're relatively small
in number.

Facebook, Kik, AIM, and whatever other communication platform you can think
of (apart from SMS) all rely on email for account recovery in case you
forget your password.  That goes for just about every other web site I've
ever used, except maybe the few exceptions we've already covered.  That
suggests to me they think it's reliable and long-lived enough for those
purposes.

Just about every social media site I know uses email to ping you about
account activity of interest if you haven't logged in lately.

>From where I sit, if anything, email use (even without considering spam) is
still increasing.

-MSK

---

From: Eric Burger <[email-masked]>
Date: Sun, 16 Jun 2013 09:12:08 -0500

I will second Franck's comment, by pointing out that 1.7 MILLION fax machines were sold last year in Japan alone.[1] If we cannot kill off fax, we certainly have no hope of killing off email.

[1] Fackler, Martin, "In High-Tech Japan, the Fax Machines Roll On," The New York Times February 13, 2013, 
http://www.nytimes.com/2013/02/14/world/asia/in-japan-the-fax-machine-is-anything-but-a-relic.html

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jun 2013 10:35:35 -0400

The question of whether email will die is silly. There is no way that I am
getting accounts on every proprietary platform people might use. I have a
FaceBook account only to stop other people taking my name there. If someone
sends me mail on Facebook is it is not going to reach me unless it gets
forwarded to my SMTP email.

There have always been closed email communities but open email has always
dominated. Email now means an account identifier <account>@<dns-name>.

We can change the SMTP and DNS protocols. The DNS may end up run by
different institutions over time. But continuity with the DNS namespace is
certain.

A more interesting question is whether chat/IM/video is ever going to
escape completely from closed communities. It looked like that was going to
happen but it doesn't seem to have done in the same way as email. People
tell me to get a Yahoo account or a Skype account or whatever just to chat
which is a stupid situation.

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Jun 2013 09:48:39 -0500

> messages. The old, unpaid system can continue to live in parallel

Perhaps I was too quick to dismiss this.  Instead of thinking of a
$.10 per-email charge we might think of periodic settlements between
MTA operators, who might then pass costs on to their users.
Delinquent MTA operators would see that others don't take their
e-mail.  Is there any way to deploy such a scheme?  I think it'd be
like moving a mountain.  I think too many operators would want to
setup something akin to peering agreements and we'd end up with
something not unlike routing.  It would suck.  But it was worth more
thought than I'd thought.

Nico
--

---

From: Evan Prodromou <[email-masked]>
Date: Sun, 16 Jun 2013 10:50:08 -0400

> This is a remarkably poor choice of venue for discussing hypothetical 

+1. Please move this discussion elsewhere; it's inappropriate for this list.

-Evan

---

From: Dave Raggett <[email-masked]>
Date: Mon, 17 Jun 2013 09:09:31 +0100

On 16/06/13 15:35, Phillip Hallam-Baker wrote:
> escape completely from closed communities. It looked like that was 
> going to happen but it doesn't seem to have done in the same way as 
> email. People tell me to get a Yahoo account or a Skype account or 
> whatever just to chat which is a stupid situation.
>

This is where a federated approach based upon personal zones may help. 
In the EU FP7 project "webinos" [1] we have been exploring the concept 
of a personal zone which encompasses your personal devices and services 
with each device being secured as part of the zone. The zone is exposed 
24x7 by a hub on which can you install personal services. Our 
implementation is based upon Node.JS.  The hub could be hosted by your 
ISP in the cloud, or run on a home gateway device. Finger can then be 
used to find the URI for someone's hub based upon their email address.

We are already seeing browser sync across devices, but only for the same 
brand of browser. Non-proprietary sync is the next step and will require 
some notion akin to the webinos personal zone, as users will in most 
cases have devices and browsers from different vendors. The notion is 
also relevant to managing privacy and security, especially for services 
based upon the Internet of Things. In conclusion, I agree that email is 
here to stay, but federated services for chat etc. are likely to emerge 
as a result of consumer pressure for non-proprietary means for managing 
a collection of personal devices and services.

[1] http://www.webinos.org/

-- 
Dave Raggett <[email-masked]> http://www.w3.org/People/Raggett

---

From: "Michiel B. de Jong" <[email-masked]>
Date: Mon, 17 Jun 2013 13:08:16 +0200

On 2013-06-17 10:09, Dave Raggett wrote:
> Non-proprietary sync is the next step

That is exactly what "remote storage" tries to propose: a 
non-proprietary protocol that does something like 
Dropbox/GoogleDrive/SkyDrive over cross-origin HTTP.

We uploaded the -01 version of the I-D last week:

     http://www.ietf.org/id/draft-dejong-remotestorage-01.txt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jun 2013 07:42:03 -0400

Interesting idea. I was thinking about a similar scheme only with the data
being encrypted on the storage drive and a decryption key issued bound to
each device authorized to read. The idea being to leverage the Ford-Wiener
model of CRM which is coming out of patent very soon.

Much of the protocol complexity of this type of scheme ends up being how
the end user establishes a device as authorized to access their account.
When I wrote Omnibroker I discovered that ended up being about 80% of the
protocol and the actual query-response piece was very straightforward.

Since this piece is applicable to many similar Web Services, I took it out
and made it a separate draft as Web Services Connect:

http://tools.ietf.org/html/draft-hallambaker-wsconnect-02

One issue that I have is working out what to call it as " Web Services *"
has been effectively grabbed by the SOAP/WS* crowd. And this is a JSON
protocol. I changed to JSON Connect (JCX) but I don't like that either.

On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <
[email-masked]> wrote:

> That is exactly what "remote storage" tries to propose: a non-proprietary
> protocol that does something like Dropbox/GoogleDrive/SkyDrive over
> cross-origin HTTP.
>
>     http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt<http://www.ietf.org/id/draft-dejong-remotestorage-01.txt>
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

-- 
Website: http://hallambaker.com/

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Jun 2013 13:57:29 +0200

> http://tools.ietf.org/html/draft-hallambaker-wsconnect-02

Also in this space:

The mission of the Linked Data Platform (LDP) Working Group is to produce a
W3C Recommendation for HTTP-based (RESTful) application integration
patterns using read/write Linked Data. This work will benefit both
small-scale in-browser applications (WebApps) and large-scale Enterprise
Application Integration (EAI) efforts. It will complement SPARQL and will
be compatible with standards for publishing Linked Data, bringing the data
integration features of RDF to RESTful, data-oriented software development

http://www.w3.org/2012/ldp/charter

It's the combined effort of about 30 firms including IBM, Fujitsu, Apache,
Oracle, BBC and more.

This is expected to become a W3C REC around March 2014

---

From: Bob Wyman <[email-masked]>
Date: Mon, 17 Jun 2013 11:23:48 -0400

Reading remoteStorage, I can't help seeing another excuse to rehash the
"folders" vs "labels" debate. "Folders" typically imply some sort of
containment and a unique location-based address for an object while labels
are attributes and allow a single document to be viewed as having a variety
of retrieval specifications. (i.e. you can retrieve based on any attribute
or set of attributes.)

Why do you introduce the complexity of "folders" in this proposal? Why not
just have document PUT and GET and define a "document collection" (aka:
folder) type? Then, "folders" would simply be documents that could be
fetched. One assumes that a 'document collection" would be able to link to
another "document collection" (i.e. either a sub or parent folder) and that
there would be a "well-known" name for that document collection which would
correspond to a "root" folder. Also, it would be good if there were no
binding between a document's retrieval name (URI) and the folder-paths or
set of attributes associated with it. The metadata for a document can often
change even if the document doesn't change and in many applications, the
folder-path or attributes can reveal information that has a higher security
level than the document itself. Thus, it would be good to allow at least
fetching of documents without knowledge of meta-data other than the
document's potentially opaque URI.

bob wyman

---

From: "Michiel B. de Jong" <[email-masked]>
Date: Mon, 17 Jun 2013 17:36:58 +0200

On 2013-06-17 17:23, Bob Wyman wrote:
> Why do you introduce the complexity of "folders" in this proposal? 
> Why
> not just have document PUT and GET and define a "document collection"
> (aka: folder) type? Then, "folders" would simply be documents that
> could be fetched. One assumes that a document collection" would be
> able to link to another "document collection" (i.e. either a sub or
> parent folder) and that there would be a "well-known" name for that
> document collection which would correspond to a "root" folder.

thanks for asking that question! The reason is that the tree structure, 
with folder versioning, allows a client to retrieve the root of a 
subtree, see if its ETag changed, and if not, know for sure that none of 
the contained documents changed. If folders were mere tags/pointers, 
then a client would have to check for changes in each document 
individually, which would be much more work.

---

From: Patrick Logan <[email-masked]>
Date: Mon, 17 Jun 2013 10:02:04 -0700

Clearly if there will be a "death of email"  it will be a long, slow,
painful death for the reasons given. Almost as clearly, the use of
email has shifted. As people pointed out we hardly distribute photos
via email, we hardly announce things via email.

But as people pointed out, there's still not a good way to send
secure, encrypted, and/or signed messages via email (or any other
standard protocol.) Also "RSS is dead", etc.

My position would be "although email will be here for a long time to
come, the landscape of standard messaging is still wide open".

In the short run I would look at emerging standards like Web Keys [1]
and HTTP Signatures [2] to contribute to a improved messaging systems.

In the long run I would look at something like Named Data Networking
[3] which has a really good general solution to many problems of
messaging today, including email. But NDN is not a new layer 7
protocol. It's a redesign influenced by IP, not dependent on IP,
intended to be deployed alongside IP based on what we know now about
the internet.

[1] https://payswarm.com/specs/source/web-keys/#messaging
[2] http://tools.ietf.org/html/draft-cavage-http-signatures-00
[3] http://www.named-data.net/

On Mon, Jun 17, 2013 at 1:09 AM, Dave Raggett <[email-masked]> wrote:
> A more interesting question is whether chat/IM/video is ever going to escape
> completely from closed communities. It looked like that was going to happen
> but it doesn't seem to have done in the same way as email. People tell me to
> get a Yahoo account or a Skype account or whatever just to chat which is a
> stupid situation.
>
>
> This is where a federated approach based upon personal zones may help. In
> the EU FP7 project "webinos" [1] we have been exploring the concept of a
> personal zone which encompasses your personal devices and services with each
> device being secured as part of the zone.  The zone is exposed 24x7 by a hub
> on which can you install personal services. Our implementation is based upon
> Node.JS.  The hub could be hosted by your ISP in the cloud, or run on a home
> gateway device. Finger can then be used to find the URI for someone's hub
> based upon their email address.
>
> some notion akin to the webinos personal zone, as users will in most cases
> have devices and browsers from different vendors. The notion is also
> relevant to managing privacy and security, especially for services based
> upon the Internet of Things. In conclusion, I agree that email is here to
> stay, but federated services for chat etc. are likely to emerge as a result
> of consumer pressure for non-proprietary means for managing a collection of
> personal devices and services.
>

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Jun 2013 19:21:00 +0200

> document's potentially opaque URI.

The Resource / Container pattern seems to have some traction.  It may be of
interest the way that Linked Data Platform Containers are modelled:

https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#linked-data-platform-containers

---

From: "John R Levine" <[email-masked]>
Date: 17 Jun 2013 15:26:02 -0400

> standard protocol.) Also "RSS is dead", etc.

The technology is there, but the usual key distribution problems apply.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Jun 2013 17:41:35 +0300

Hi,

On 06/15/2013 09:59 PM, Timo Sirainen wrote:
>>> where the sender pays a fee, say $0.10 per recipient, for
>>> sending messages. The old, unpaid system can continue to live in
>>> parallel to the new system.
> http://www.taugh.com/epostage.pdf  was mentioned as a reply to your
> last post, which I think describes pretty well why I doubt any actual
> money transactions aren't going to work. But I do wonder how far
> people have thought about using hashcash. I haven't really followed
> antispam efforts myself.. but I'd think a hashcash and some crypto
> combination could be made to work, if enough people show interest. A
> high level plan:
>
> - Every time you send a mail to a new contact, you'll have to pay
> with hashcash. The recipient SMTP server specifies the cost
> requirement and rejects the mail at RCPT TO stage if the payment
> isn't given.
>
> - For big ISPs/webmails and such the cost would have to be offloaded
> to the actual sender client, not the sending SMTP server. Yes, some
> slow clients might have to calculate it for minutes and show the user
> a progress bar showing how long it's going to take. ISPs could also
> sell this as a service to do it on the server side. Users could also
> opt to send it the old way and hope it gets through.
>
> - Each email you send to someone will contain a crypto key header
> that allows the recipient to send you back emails without calculating
> the hashcash.
>
> - Mailing list subscriptions would be done by sending them an email
> with the crypto key, which mailing lists can remember to make it free
> for them to send you the actual mails.
>
> - A crypto key would be specific to a single email address, so the
> crypto key headers could be thought of as public information. This
> requires SPF/DKIM to be enabled for the senders.
>
> - If your private crypto key gets leaked, you need to switch to a new
> one. This wouldn't be too bad, except you'd have to re-subscribe to
> the legitimate mailing lists, which perhaps could be automated with
> some extra work.
>
> - During transition phase this would basically just affect the spam
> scoring, so this could be implemented incrementally.
>
> - Requires new software for sending and receiving SMTP servers to be
> able to use this, but not necessarily new email clients. Webmail
> providers could calculate hashcash using Javascript on the background
> during composing the email. The main problem would be the old
> IMAP/POP3 clients trying to use free email providers.
>
> I don't see any obvious reason why the above couldn't work, other
> than the huge amount of work required and convincing all the major
> players to implement it. And it of course wouldn't completely
> eliminate spam, but it would make it much more costly, hopefully
> dropping the amount of spam from 99% of all mails to a few %. Botnets
> aren't free to use either.

for the record, Goodman et al have investigated spam mitigation with 
human-interactive proofs and computational puzzles:

http://dl.acm.org/citation.cfm?id=988779

Levchenko et al have analyzed that payment infrastructure is the 
bottleneck of the spam value chain and argue that spam could be tackled 
most effectively by political means, i.e, by enforcing a payment tier:

http://cseweb.ucsd.edu/~klevchen/kklevps-ccs08.pdf

I have been myself involved in investigating how to use the built-in 
puzzles of Host Identity Protocol for spam mitigation:

http://www.cs.helsinki.fi/u/starkoma/xhip_final.pdf

Deployment is an issue, similarly as in hashcash.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 19 Jun 2013 08:52:55 -0400

> are more and more used instead of email.

There have been for years, because each provides a different kind of 
service.  SMS and IM are usually for short messages that often encourage 
a relatively immediate response.  Bulletin boards of old and sites like 
Facebook today have always had private messaging capabilities.

> receiving messages to and from my bank. Other companies may do the

This is a pain point of mine and there are two parts to this.

First, there is the requirement to log in to send a message. The reasons 
for this are often said to be for "security" reasons. That's probably 
true in part, because end-to-end security of email often does not 
exist.  Another reason is likely because it's easier to build a 
proprietary messaging platform than to try to integrate the messaging 
platform with email.  And the banks will want to record and keep all of 
these messages.  Also, spam is a real problem, so they'd prefer to know 
who is sending messages.  Still, the end-to-end security is an issue.

Second, my bank will not send me communications, primarily for security 
reasons.  There is no guaranteed end-to-end security.  I'd love to have 
bank statements to me, but that will not happen with the current lack of 
security.  It would be very nice if the bank's MTA would be able to 
require end-to-end security and each MTA in the path would honor that 
request.  That would mean that each MTA in the path would have to refuse 
to forward messages unless the next hop agrees to adhere to the required 
end-to-end security procedures (whatever those are).

> another protocol than email.

I do not think it will die out, but I think it is falling short of its 
full potential due to lack of end-to-end security and uncontrollable spam.

> messages, and this is what the spam filters are meant to avoid.

Yeah, I have found no good solution.  If I filter spam, something gets 
misclassified.  I do block a lot of IP addresses if I get repeated 
spam.  I white list those that I know are known good senders.

> messages. The old, unpaid system can continue to live in parallel

Email fees have been discussed for years, but the problem is that valid 
senders of bulk email get hit pretty hard.  Just imagine how much money 
the IETF would have to pay to send messages to all of its subscribers.  
I don't think that's a workable solution.

What I do wish I had was better end-to-end security.  This security 
would include TLS so that communicating MTAs could mutually 
authenticate.  I would want MTAs to accept mail only over TLS and only 
to users that authenticate.  I would want all messages to be signed 
using DKIM.  I would want to be able to look at a message and know 
exactly who sent it and know it was secured end-to-end.  Any message not 
signed, I could reject.  Any legitimate sender would play be these rules.

Spammers would go to a CA and get a certificate and try to present 
itself as a valid sender, but once a purchaser of certificates is 
identified as a spammers, the CA could refuse to issue new 
certificates.  Essentially, the CAs can do a lot to help bring an end to 
spam.

Not every domain owner would necessarily need a certificate, but the 
hosting company would have to enforce rules that require entities using 
its services do not abuse its mail servers by sending spam.

Until we can get anything better in place, I continue to block millions 
of IP addresses.  I do enforce SPF if the domain indicates clearly all 
of its authorized mail servers, but that only prevents certain types of 
abuse.  I cannot enforce DKIM at all, because some senders do not sign 
messages properly.  I cannot even indicate that my domain always signs 
messages, because the signatures become invalid when going through some 
mailing lists and then rejected by receiving domains.

While I don't think email will die, there are certainly things that 
could and should be done to make it a more useful service and to cut 
down on spam.

Paul

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Jun 2013 09:06:28 -0600

I think the solution is for person-to-person email is for MUA's to 
develop the ability to generate their own certs and a secure way to pass 
them as you see fit.

Clubs, mailing lists, and groups could post their public cert on their 
web pages so you can get them as you subscribe.

A new email header that says where your public cert is located. If it is 
a new email sender and you want to have secure email with them, click on 
a button on your MUA to load it.

Forget the pay for cert companies. It is easy to generate your own CA 
and cert for your own usage.

You could create black and white lists. No cert in the email, filter to 
a separate folder and decide on your own.

It is not common for me to get an email that I want from someone I have 
never heard of.

With MUA modifications, the MUA could select the appropriate cert for 
the destination email address. Sign up  for a mailing list, you get a 
cert for that list or organization you download. The MUA (for example), 
notices it ends with ietf.org and selects the ietf.org-cert it 
previously loaded.

There is MUCH more to think about, I think it would be an interesting 
discussion.

Doug Royer - (K7DMR.us / DougRoyer.com)
[email-masked]
714-989-6135

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 08:09:07 -0700

> and cert for your own usage.

How is this different from the OpenPGP model?

d/

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Jun 2013 09:24:14 -0600

> How is this different from the OpenPGP model?
Mostly I am talking about modifications to the process and MUA's when 
sending and validating email. I will read more about OpenPGP later today 
(I am not up to date).  As I remember PGP was a trust ring. So maybe it 
would be the same process logical process, if the MUA supported it.

Few MUA's allow for non-technical persons to use S/MIME or PGP.

The act of using it (S/MIME or PGP) in the IETF mailing lists to start 
seeing what people like or works needs to start. Several years ago I 
used S/MIME to sign my email and the IETF mailing lists trimmed off the 
signature. Whatever methods that need to work, we need to try them. The 
mailing lists trimmed them off because MUA simply displayed them, did 
nothing with them, and users had to manually trim off the signature when 
replying. So people complained. No one ever complained that the message 
had a verified sender.

Heck, If we can agree to some real trial methods, and the mailing list 
does not trim it off - I'll write an add-on for Thunderbird to use it.

This topic has been discussed for decades. There does not seem to be a 
perfect solution. I don't think we will ever get to a solution until the 
MUA's support it.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Jun 2013 10:27:03 -0500

I'd be happy with an MUA adaptation of OTR.  Exchange a couple of
e-mails and you have a session key in which to encrypt everything.
Then you could do ad-hoc authentication just like OTR.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jun 2013 09:33:54 -0600

> Then you could do ad-hoc authentication just like OTR.

Hi Nico,

Paul Wouters and I plan to spend some quality time together in Berlin
(postponed from Orland) working on an I-D about OTR as it stands
today. If we can get that published even as an informational RFC, the
OTR community might become more comfortable with working in the IETF
and we could look into an initiative to work on next-gen OTR-related
topics, including what you propose.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2013 17:32:58 -0400

> Then you could do ad-hoc authentication just like OTR.

Most MUAs that support S/MIME will remember the key from messages like 
this one and encrypt (perhaps after tweaking a global setting) mail to 
recipients whose keys they have.

S/MIME is also supposed to solve the introduction problem (how do you know 
that a correspondent is who she says she is?) so most MUAs get unhappy 
with unsigned certs, but I'd think that a tweak to accept them would 
typically be pretty easy.

Regards,

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Jun 2013 17:15:03 -0600

On 06/19/2013 03:32 PM, John R Levine
wrote:

...

S/MIME is also supposed to solve the introduction problem (how do
you know that a correspondent is who she says she is?) so most
MUAs get unhappy with unsigned certs, but I'd think that a tweak
to accept them would typically be pretty easy.  ...

The MUA implementations also need a way with S/MIME to load them in
a more friendly manner. They ask this horrific question on a root
cert load that scars the heck out of non-technical persons.

In addition, if I could go to my Google, Yahoo, Bing, AOL, ...
whoever and get a cert from my web  email page. And they support
using it, uploading it, and verifying it on reading email, this
would go a long way.

If the MUA gets a new cert it does not recognize, it
could verify it with some process yet to be defined. Ask the user,
verify it against the ISP root cert (cert list, whatever...) the
first new one (or updated one) would go through the verification
process.

If I press a button that says, 'someone stole my cert', then I think
the replacement process could be simplified (perhaps?) by adding an
email header saying 'by the way, my cert ID 'X', 'Y', and 'Z' are
invalid. Over time, as I send email, those I communicate with would
get updated with the new cert and my revocation list. They don't
have to remember the revocation list, they just have to delete my
'X', 'Y', and 'Z' certs.

Having tried the public free and paid for CA/cert sites, the
verification and distribution process is sometimes so complex that I
have been unable to get a couple of them to work. They need to have
rigid user verification processes because they are responsible for
the certs and for verifying the identity of the email address. If
however the certs are issued by the ISP's themselves, they don't
need to do complex verification, as Google knows that
[email-masked] is in fact [email-masked] . They can
generate that cert, make it available to me, and if I can load it
into any MUA I desire, I can just use it.

I got over 300 spams last week. Ramping up to holidays where people
tend to buy gifts, I have received up to 1200 in a day. Some of this
is very rough thoughts, but I really think it is time to start it.

I would think that Google for one would like me to one day say 'if
it is not signed, toss it". And later "if it can not be verified,
toss it'. It would save a ton of disk space.

I would also like to see a POP/IMAP extension that allows the MUA to
inform the POP/IMAP server that a message is SPAM. I can think of
all kinds of spam unfriendly things a server can do with their smart
spam filters.

--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Jun 2013 18:25:04 -0500

Also, one of the nice things about OTR is that you don't need to have
a device that can memorize keys.  If you lose your device or your
peers change keys you just... re-authenticate them.

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2013 00:10:45 -0000

>If the MUA gets a new cert it does not recognize, it could verify it with some process yet
>to be defined. Ask the user, verify it against the ISP root cert (cert list, whatever...)

Um, that's what it does now, verifies it against a list of signers.

>If I press a button that says, 'someone stole my cert', then I think the replacement process
>could be simplified (perhaps?) by adding an email header saying 'by the way, my cert ID 'X',
>'Y', and 'Z' are invalid.

I think we've just invented CRLs.  Keep in mind that bad guys will
send mail pretending to be from you saying that your certs are all
invalid.

>Having tried the public free and paid for CA/cert sites, the verification and distribution
>process is sometimes so complex that I have been unable to get a couple of them to work.

Yes, it's widely agreed that key distribution is the hardest part of
any signing scheme.

R's,
John

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Jun 2013 08:49:46 -0600

On 06/19/2013 06:10 PM, John Levine
wrote:

Have you ever tried to get a new root CA into your browser or MUA?
Could your grandmother do it? Most of this is MUA
implementation issues. I still want to help move
*something* forward.

PGP or S/MIME in my opinion are not being used because it is too
complicated for the average user to use.  Recently
[email-masked] sent an email to the list that was PGP signed. No
MUA that I have did anything except show it as in-line text. The
text in the PGP signature said it was sent using Thunderbird. I am
using Thunderbird - it did NOTHING with it, except show it as text.

He could have generated that text from a random number generator,
Thunderbird does not care. What process in the data flow of that
email message cared to verify it or show it?

Would it be possible for SMTP submission or relay sites to do some
validation?

I would think it would be reasonable for Google , to require that
when I submit an email using their SMTP server that it be verified
with their signature or cert?

Signed by me? With my new Cert ? Maybe I am uninformed. How would
that work?

I think that most of the problem is MUA implementation. Perhaps a
S/MIME and PGP in a nutshell for implementers draft. Not sure,
that's why I am poking around.

--

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Jun 2013 16:45:59 +0100

Timo Sirainen <[email-masked]> wrote:
>
> But I do wonder how far people have thought about using hashcash. I
> haven't really followed antispam efforts myself.. but I'd think a
> hashcash and some crypto combination could be made to work, if enough
> people show interest.

Proof of work proves not to work:
http://www.cl.cam.ac.uk/~rnc1/talks/040607-ProofWork.pdf

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2013 16:44:53 -0000

>Have you ever tried to get a new root CA into your browser or MUA?

Yes.  Browsers are easy, visit http://www.abuse.net, scroll down to
the bottom, click, ignore the warnings as we have been trained to do,
and install my root CA.  I agree that getting them into MUAs is a lot
harder since they never have a UI for it.  Getting them into a browser
is too easy, into an MUA is too hard.

> Could your grandmother do it?

Probably not, since she's dead, but I take your point.

>I think that most of the problem is MUA implementation. Perhaps a S/MIME and PGP in a
>nutshell for implementers draft. Not sure, that's why I am poking around.

What you're thinking about is the introduction problem, how to tell
that a new acquaintance is who she says she is.  It is one that people
have been thinking about in computer contexts for decades, and in the
real world for millenia.  Before dashing off to solve it, I would
encourage you to do some homework so you know how and where your ideas
have failed before.

Also, if you think that better authentication will solve the spam
problem, don't waste your time.

R's,
John

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Jun 2013 11:59:58 -0500

> encourage you to do some homework so you know how and where your ideas

There are no (and almost certainly will not be) new solutions to the
introduction problem.  However, OTR is about as workable as we can get
with no infrastructure and no web of trust, and it's the
infrastructure and web of trust that makes existing systems hard to
use.  OTR is therefore the easiest-to-use solution.

> problem, don't waste your time.

Indeed, there's no solution to the spam problem (hmmm, except
deterrence; there are times when the death penalty seems too lenient
for spammers).

Nico
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 10:09:14 -0700

> use.  OTR is therefore the easiest-to-use solution.

Just to add some seasoning to the frankly bland abstractions of this 
technical exchange, I'll suggest that the only interesting problems in 
this space are with the human factors.  Figure out how to make this 
usable for non-technical folk.

The state of the art -- nevermind the state of the industry -- for 
usable security is remarkably and tenaciously poor.  As an example, we 
still have software from major vendors that issues security alerts 
users' screens without indicating what package is generating the alert; 
and then, of course, there's the cognitive demands at the foundation of 
most such alerts.

As a hint, I'll note that "get a new root CA into your browser or MUA" 
is a technically reasonable piece of the puzzle, but it primarily 
highlights the failed UX design that we currently experience.  That is, 
simply casting a design goal in terms of a user's adding a root 
guarantees failure.

d/

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2013 13:25:13 -0400

> use.  OTR is therefore the easiest-to-use solution.

OTR does a nice job of protecting the channel.  It has some ways to verify 
the other party, but it is my impression that everyone turns them off.

Perhaps if we more clearly separated the identity applications from the 
channel applications, we'd be able to design stuff that addresses one or 
the other more effectively.

Regards,

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Jun 2013 16:11:21 -0600

On 06/20/2013 10:44 AM, John Levine wrote: (and Below Response to Dave 
Cocker email)
> have failed before. Also, if you think that better authentication will 
> solve the spam problem, don't waste your time. R's, John 

I agree it will not stop spam. It might help me or an ISP identify it.

I think that adding a IMAP/POP extension that says message #3 is spam 
can help the ISP filters when 10,000 people have clicked spam for the 
same message. If signed email was required for submission or acceptance, 
and the spammer generated a new CA for each set of spam messages, you 
could identify and stop it real fast with dynamic feedback to the 
servers. Or if they used the same cert for all of their spam, again it 
could be stopped real fast.

I think that moving to cert based email submission will prevent the 
person that broke in to my hotmail account last week that hacked my 
obscure and complex password from submitting email as me - unless he 
also steals my cert. I knew it happened only after getting some nutty 
replies to email I never sent. If I would have had to supply an S/MIME 
message to be submitted, it would have not made it to a few hundred (or 
more) people.

My other concern is the few emails I send per year that I want private.

I did some consulting work for mortgage processing and home loans 
(mismo.org) where they concluded that they wanted to be in control of 
their CA. There distribution process was certified snail mail. I would 
be happy if Google gave me my cert for my gmail account with a simple 
button to generate a new one when needed. A protocol between the browser 
and MUA to their server that auto-loaded and set it up to work. My MUA 
(browser) connects to your email's POP/IMAP or SMTP (or email web page) 
server, their server recognizes I have not submitted THEIR cert or have 
an old one. It sends message, agreed on authentication occurs, my 
MUA/browser gets auto-updated via SMTP, POP, IMAP, extensions or some 
other out of band protocol.

I have been reading IETF lists since 1978 when my email address ended 
with .arpa, and have seen a lot of failures. Technology has evolved, 
S/MIME would have been impossible when a 1-MIP VAX cost $1-million 
dollars and the IT staff said HELL NO - don't waste any CPU time on that 
stuff. I tried S/MIME and the only complaint I got was "what is that 
stuff at the end of your email?".  An MUA that supports S/MIME reported 
it as authenticated. That is backwards, they should flash a red box that 
says "not authenticated"

I have not seen an ISP generated certs for their customers auto loaded 
and by default get used. I have not seen signed email required or even 
preferred for submission.

And Dave Crocker Wrote:

 > As a hint, I'll note that "get a new root CA into your browser or MUA 
" is a technically
 > reasonable piece of the puzzle, but it primarily highlights the 
failed UX design that we
 > currently experience.  That is, simply casting a design goal in terms 
of a user's adding
 > a root guarantees failure.

Yes. The solution needs to include a user model that can be easily 
replicated by any MUA. Same well thought out steps in the same order to 
reach a new and safer working conclusion.

I want it to be as simple as: (1) Get an email address (2) run your here 
is my email address to my MUA, (3) it asks the same difficult to figure 
out SMTP/POP/IMAP questions (4) does agreed on authentication (5) when 
happy AUTO-LOADS my new cert.

Perhaps a SMTP/POP/IMAP configuration protocol? I know the mobile world 
would love that. I did some technical work for a huge mobile phone 
company last year.  The most annoying problem to solve was how to convey 
to a grandmother that wants to get grandchildren photos via email and 
just knows her email address. They had a small staff of people that did 
nothing but try to keep up to date on the port, protocol, user name vs 
email is the user name, vs IMAP or POP, vs other Android or iPhone 
specific ways of asking the same questions different ways for each ISP. 
And  while your at it, auto-load the cert and send a test email message 
to the grandmother so she knows it worked.

Gmail has spam filters, Thunderbird has spam filters. Did you know that 
Google recommends you turn off Thunderbird spam filters? I have no idea 
how (or if) Google knows that I think a message is spam. I can configure 
Thunderbird to auto-delete it or store it in a local or gmail spam 
folder. Only the latter might be how they figure it out.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 21 Jun 2013 17:27:53 +0200

> message to be submitted, it would have not made it to a few hundred (or

I disagree, irrespectively of my inclination toward S/MIME.  You clearly
identified the failure point, although it is not clear what kind of
attack revealed your password.  Until that is fixed, you cannot know
whether adding yet another certificate or password would help.

> folder. Only the latter might be how they figure it out.

Perhaps they think their filters are better.  IMHO, it would be good to
report messages that users classify as spam, independently of how such
classification was made.  That would contribute to determining mailbox
providers' reputation, and could cure false positives.

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 21 Jun 2013 18:57:10 +0300

> http://www.cl.cam.ac.uk/~rnc1/talks/040607-ProofWork.pdf

Not in 2004, but nowadays the work could be delegated to email clients (not email servers), such as GMail using Javascript to force users to calculate the necessary work. There is a LOT more CPU available to legitimate email clients than there are for botnets. Using crypto based "whitelists" (crypto signature token encoding a specific sender -> recipient) could avoid most of the hashcash calculations, and especially would avoid them completely for mailing lists (each user would provide the whitelist token when subscribing).

It wouldn't of course completely solve spam problem, but I think it could be used to significantly reduce it. But I guess spam isn't big enough of a problem to actually bother implementing this currently, and the cure is especially bad because as the pdf says: "warms up the planet :("

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2013 17:57:24 -0000

>It wouldn't of course completely solve spam problem, but I think it could be used to
>significantly reduce it. But I guess spam isn't big enough of a problem to actually bother
>implementing this currently, and the cure is especially bad because as the pdf says: "warms
>up the planet :("

This particular FUSSP has the "won't work unless everyone does it" and
the "millions of PCs in botnets" problems.

If people really want to rehash well known ineffective anti-spam techniques, I can give
you the info for the son-of-ASRG list.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 11:05:12 -0700

> you the info for the son-of-ASRG list.

Of course, less work, quicker result and a better summary is at:

    http://craphound.com/spamsolutions.txt

d/

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 21 Jun 2013 21:33:14 +0300

On 21.6.2013, at 20.57, John Levine <[email-masked]> wrote:

> This particular FUSSP has the "won't work unless everyone does it"

It could help even without everyone by using it as part of the spam score, but yeah, it definitely needs a few of the major ones implementing it to be worth the trouble. I wouldn't bother with it unless I got a large number of people to agree with it, which doesn't really look like it's happening. I think the core idea is still workable enough though.

> and the "millions of PCs in botnets" problems.

I still don't agree with this. There are at least 100x more legitimate email clients than spammers have servers, and most of the mails that legitimate senders send would be sent to known recipients or mailing lists which are whitelisted anyway, bringing the total amount of work required by spammers vs legitimate senders closer to 10000x.

Also I'm thinking that it's possible that email will evolve into something slightly different in future than how it's used now. It's about the only thing now where if you simply know one ID string you can send a message to anyone in the world, and everyone has at least one. Perhaps at some point it wouldn't be considered impossible that sending a mail to a new contact would take even hours, depending on the popularity of the recipient and how much effort the sender is willing to do to send the mail. Mainly it would be different than now, worse in many ways but also better in some ways, depending on what you want to use it for. For my email usage it wouldn't make much of a difference if it worked that way, and I send quite a lot of emails each day. But anyway, lets see again in 10 years :)