General discussion


Is it time to fundamentally change email?

By Jaqui ·
I decided to read the specification for smtp, and found a few links on wikipedia that had the information on it, with a few links to even more information on a proposed new email protocol.

Currently email is effectively a server push methodology, making it very affordable for a spammer to send an email to a lot of recipients.

The proposed new protocol is a client pull methodology, making the sender spend more money to send to a lot of people. It is also a step back to version one of email, requiring both sender and receiver to authenticate themselves, promoting less spam in and of itself.

HTMP the HyperText Mail Protocol is the latest version of this implementation to be proposed, in the comments to this Blog entry the links for the earlier versions are posted.

Receiver Driven extention to the current smtp email system. This is an RFC format text document, it is essentially little more than a few more options in the smtp server to create the same system at HTMP, with support for the current methodology still in place.

Email 2000 is a plain english proposal for a receiver pull system, with several points raised in it that need to be addressed before even starting development of such a system. This is also the oldest of the receiver pull proposals.

To summarise the implementation of a receiver pull system:

You send and email to 10 people, the email client sends a note to the server, which creates a private, static web page, uploads the email to it, with all required authentication, then the server creates a new email notice that it sends to the recipients. This notice contains the uri for the email message, and the subject for the email.

The recipient downloads this 1 kb text message and chooses to veiw the entire message or not.
they can, if they want, download the entire message at that time to save in local archives.

The result, for the receivers of emails, is drastically reduced inbox size requirements.
The Sending party actually has to have a much larger amount of drive space allocated for their email, and has to pay the data transfer for every person that views the full email.

The last will make spamming people much less cost effective, since right now the receiver pays the data transfer.

to Quote Nathan Cheng in a comment on the HTMP Blog entry:

If you send an email message of size S from your email client A and it passes through mail transfer agents B1...Bn before reaching its final destination email client C, the total bandwith requirements T(P) on each of the participants is as follows:

Currently: T_c(A) = S, T_c(Bi) = 2 * S, T_c(C) = S;

HTMP without obfuscation: T_wo(A) = s + S, T_wo(Bi) = 2 * s, T_wo(C) = s + S;

HTMP with obfuscation: T_w(A) = ( ( n + 1 ) * S ) + s, T_w(Bi) = ( 2 * s ) + S, T_w(C) = s + S;

where s is the (very small) size of the Stub Email.

From this it is evident that with the log file obfuscation requirement, the increase in bandwith for transfer agents and the receiving user agents is extremely minimal, whereas the increase in bandwith for sending user agents is massive. This is a good thing. In fact, this is a wonderful thing, because it will increase spammers? bandwith costs enourmously while keeping everyone else?s just about the same. So instead of crippling the HTMP idea, I submit that the solution to the privacy issue is actually an even better reason to hope for the quick implementation and worldwide adoption of HTMP.

Another benefit of the recipient pull method, is that huge mailouts, such as spammers use, will effectively cause them a ddos attack, unless they have the data transfer and hardware capability to deal with it.

With a receiver pull system, the data transfer usage, which is currently around 75% I heard, from bounced emails would go away, making email, and the internet itself, much less congested in traffic.

Do you think this idea is something that should be concidered? It does increase the costs of email for business purposes, but this is directly deductable for tax purposes as an increase in operating expenses.

Email 2000 proposal:

Receiver Driven Email RFC:

Hypertext Mail Protocol (a.k.a. Stub Email):

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

not really

by apotheon In reply to Is it time to fundamental ...

Spamming methodologies are already evolving past the point where this would be particularly effective. Spamming is mostly achieved by way of bot armies these days, so that the sending is distributed and the bandwidth usage costs would be incurred by the owners of the zombie computers, not by the spam initiators themselves. It's an end-run around the potential effectiveness of a client-pull email standard for mitigating spam issues.

In addition to this, I see some significant potential problems arising with a web URI being the repository of email, and for people with nonpersistent connections trying to send email, depending on how it's all handled.

Collapse -

I disagree

by jmgarvin In reply to not really

I've been saying (for years) that email is borked. Email doesn't follow the three basic tenets of information security. Confidentiality, Integrity, and Availability. Email violates 2 of the three (availability isn't an issue in this case). What needs to happen is this:

1) A clear and easy way to authenticate the user(s). No more nobody@localhost.localdomain. No more (foo@localhost). Why is this allowed?

2) Validating email servers by a DNS type schema only makes sense. I need to be able to ensure I'm actually getting a mail from domain A.

3) email needs to have some method of confidentiality. Plain text just doesn't cut it. Encryption should be manditory for all email traffic. In the long run this will assist with non-repudiation.

4) STOP PORT 25 FORWARDING. There is NO reason to allow an SMTP server to send mail from a direct connection. This allows spam bots and leave a great enty point.

5) The problems with POP/IMAP need to be sorted out and they both need to be clarified. We also need to choose one as a standard and lock it down.

Collapse -

which one

by Jaqui In reply to I disagree

to pick though? with the extentions to the base protocol to allow images and binary iles, to support other character sets than ascii........

both are very little different.

pop automatically downloads the email from the server, deleting it unless you tell the client not to.

imap leaves it on the server.

that is the sum of the differences.

most isp, only allow for pop, to reduce server load. free [ webmail ] services are imap, which keeps it unless otherwise selected. Those isps that have broadband also offer both services, to allow for using a local client as well as for webail type access.

Collapse -

No you don't.

by apotheon In reply to I disagree

That doesn't disagree with me at all. I pointed out problems with the proposed "solutions". I didn't say email didn't need to be fixed.

Collapse -

maybe not

by Jaqui In reply to not really

if the spam email is infecting systems, having it on a single machine and those receiving the spam have to choose to view / download the thing, rather than the current it's brought onto your machine by default, the spam bots will die a slow painfull death, and the spammers will wind up having to pay for data transfer used by their spam campaigns.

Collapse -

not on a single machine

by apotheon In reply to maybe not

When spammers use an army of Windows zombies, the email being sent won't be on a single machine. It'll be on every machine in the army. A spammer using such techniques doesn't email the spam to the machines he's compromised, y'know.

Related Discussions

Related Forums