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:
http://cr.yp.to/im2000.html
Receiver Driven Email RFC:
http://www.cs.fsu.edu/~duan/publications/draft-duan-smtp-receiver-driven-02.txt
Hypertext Mail Protocol (a.k.a. Stub Email):
http://www.circleid.com/posts/hypertext_mail_protocol_aka_stub_emaill/