publication
published on
2012-01-25
by Maciej Duda

Send email away

Available in PDF format

Reviewed by Alex Tomic

Abstract

This paper is participation in discussion about current status and future of an email Internet service. It's based mostly on my observations and experience in email and jabber server administration.

Introduction

Email is the most popular communication method over the Internet. It's also very old - it was designed in the early 70s, when people couldn't even dream of the Internet as it is now and that it would become this popular. Therefore they weren't putting a big effort to several architecture aspects crucial in the modern Internet. The way we use email now has evolved from simple sending of text messages to much more advanced tasks such as sharing files, using web-based user interfaces and using advanced sorting/filtering methods to organize our correspondence.

Emails' early great success prevented people from implementing drastic changes into protocol, because they were afraid of losing users by blocking old clients from communication with new ones (backward compatibility). This brings many issues with which we must struggle nowadays.

Problems

Over time email gained additional functionalities. It became a platform, which inspired users with new ways for conversation and data exchange. To fulfill new requirements, developers wrote many add-ons and workarounds such as anti-spam filters, authentication and encryption, which resulted in a very chaotic protocol architecture. So to deploy a solid and useful email service, system administrators must solve all the issues installing and configuring additional software. Lets take a look at details of email problems.

Security: authentication and confidentiality

Email doesn't require any type of authentication - everybody can send it from any host connected to the Internet and "From" field can be filed with anything the sender wants.

telnet target.email.server.com 25
HELO senders.domain.com
MAIL FROM: John Doe
RCPT TO: someone@target.email.server.com
DATA
body of message

There is no verification for sender so identity theft is quite easy. Some servers might perform reverse DNS lookup, which will check if IP address of telnet connection matches senders.domain.com DNS records, but it's just an unofficial naming convention, and does not have to be followed.

The problem is that email is used in business and other communications, which requires a higher level of confidentiality during exchange of important information. There are available solutions such as PGP signatures, but they require preparations for both exchange sites to comply, so it's fairly difficult to be sure that the received email is legitimate and/or has been intercepted during transfer. SSL is another way to encrypt messages, but it's only for network transfer and the message itself is stored in plaintext on the server. Also recent SSL Certificate Authority problems [5] decrease the level of confidence.

Another aspect is the lack of end-to-end encryption. By default not only passwords are sent via plaintext, but also a body of correspondence, which makes it very easy to grab. It's worth mentioning, that emails are stored on servers in unencrypted format, which results in full access to them by system administrators and if server is being compromised, unauthorized person gets full access to email content.

It's terrifying if you imagine that every email, which you read could be fabricated or read by somebody else.

Spam, fraud and scam

According to MAAWG [1]:

from the first and second quarters of 2010, the percentage 
of email identified as abusive has oscillated over the last
six quarters between 88% and 91%.

Users receive and process 9 out of 10 unwanted emails - bandwidth, hard drive space and processor time is simply wasted on spam. Filtering messages may end up with deleting important ones by accident. People get regularly tricked into using phishing websites distributed mostly over email.

File exchange

So you can add attachment to your email. Did you know that attachment size is 30% bigger, when you send it via email? It can't be stressed enough that email is not designed for file exchange. It's inconvenient, not efficient and ineffective. Also from an interface perspective inbox is not a file folder - files are not accessed in a straight-forward manner, you cant search the content of files and they are fully dependent on emails, which they are attached to - if the email is moved or deleted, the same happens to the attached file. Transmission is not peer-to-peer and that slows down whole process, so email delivery with large attachments is not instant. It needs to be fully delivered to server and then the recipient can download the email with the content.

There are much better ways to exchange files over the Internet.

Standardization

Have you ever had a situation, where your legitimate email address was rejected by a website form validation? The problem is that there is lack of one true email address regular expression [2] available, because RFC [3] can be interpreted in many ways. This problem became visible, when Google Mail announced that every user can add suffix to his username to build additional email addresses for his account. The separator was '+' so John Doe can have email: "johndoe+spam@gmail.com" or "johndoe+slashdot@gmail" and every email sent on these accounts will end up in johndoe@gmail.com inbox. Many subscription services rejected subscribe forms with '+' in email address, which prevented Gmail users from applying this feature.

I recommend to see this talk by rjbs, who covers most issues with email implementation and explains why standards are in terrible condition [4]

Can we do something about it?

Surely there are many solutions and workarounds, which cover most of the mentioned problems (Gmail is a great example), but nevertheless the best solution would be to introduce a new standard, which wouldn't be backwards compatible to current email components and was adapted to present email use-cases.

One of the most important improvements would be email filtering based on contact list - before delivering email, the sender would be required to be identified by the recipient as if he is willing to receive any emails from that sender. This kind of contact list is implemented in the XMPP protocol [6] and it solves many problems mentioned before: identity and spam/fraud. Perhaps this functionality should be optional, nevertheless it would be useful and efficient.

Google Wave was one recent email replacement attempt. It was supposed to be an email alternative by bringing new breath into communication over the Internet. Wave had everything - security, authentication, grouping and filtering messages and well designed file exchange. Unfortunately this project has been rejected resulting in it being shut down.

Another alternative might be the already mentioned XMPP protocol (which BTW Wave is based on), but it requires a suitable GUI to serve as an email alternative replacement, which it lacks for now.

The future of email

Email does not go away, but there are trends in replacing POP3/SMTP interface with GUIs based on Web 2.0, which might be a chance to renew email standards so that it will fit more with current requirements. Users wont see any difference, because they don't need to set up anything in their Gmail or Facebook. Although they might gain new features like better grouping and threading correspondence.

References

[1] http://www.maawg.org/sites/maawg/files/news/MAAWG_2010_Q3Q4_Metrics_Report_14.pdf
[2] http://www.regular-expressions.info/email.html
[3] http://tools.ietf.org/html/rfc2822#section-3.4.1
[4] http://rjbs.manxome.org/
[5] http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx
[6] http://xmpp.org/rfcs/rfc3921.html#int