Extensible Mail Protocol -- the new FUSSP?
In April, I briefly mentioned a new proposed Final Ultimate Solution to the Spam Problem.
This week, reader Jimmy B mentions Yet Another new email protocol, known as Extensible Mail Protocol, which is a web-based protocol intended to replace SMTP and POP3. In a nutshell, it packages messages as XML objects and transmits them over a secure and verified HTML connection. There are provisions for interoperability with SMTP and POP.
I haven't read the spec yet, but I have a couple of basic questions: Why does the protocol need to be HTTPS-based? A lot of ISPs use port 25 blocking to prevent their users from spamming. HTTP ports are not so easily blocked. Will this make it easier for spammers to abuse the protocol?
I'm also a little concerned about the GPL license. Will this be a barrier to commercial adoption of the protocol? I'm not entirely sure what the license covers, but I do know that a lot of commercial entities are terrified of it.
Finally, the reference implementation is written in C# for Microsoft. How much of a barrier will this be to adoption by the Unix world?
I'll write more once I've had time to read the documentation.
This week, reader Jimmy B mentions Yet Another new email protocol, known as Extensible Mail Protocol, which is a web-based protocol intended to replace SMTP and POP3. In a nutshell, it packages messages as XML objects and transmits them over a secure and verified HTML connection. There are provisions for interoperability with SMTP and POP.
I haven't read the spec yet, but I have a couple of basic questions: Why does the protocol need to be HTTPS-based? A lot of ISPs use port 25 blocking to prevent their users from spamming. HTTP ports are not so easily blocked. Will this make it easier for spammers to abuse the protocol?
I'm also a little concerned about the GPL license. Will this be a barrier to commercial adoption of the protocol? I'm not entirely sure what the license covers, but I do know that a lot of commercial entities are terrified of it.
Finally, the reference implementation is written in C# for Microsoft. How much of a barrier will this be to adoption by the Unix world?
I'll write more once I've had time to read the documentation.
9:14 AM |
permalink
3 Comments:
I fail to understand why we should use HTTPS, SOAP and XML when we already have SMTP/TLS, RFC(2)821 and RFC(2)822 in our toolbox.
The basic problem that an open system can be abused (ie spam, DoS etc) will not be solved through replacing the transport protocols. In fact, that problem can not be fully solved as long as we insist on an open system.
If "we" choose *not* to insist on an open system, there is still no need to replace the transport protocol. It's just a couple of lines in a configuration file and you will only accept mail from sources which present a valid certificate to your liking.
Just for the record, it is my firm believe that "we" should not abandon the open system.
As matthias said, this whole new protocol will have a lot of overhead imho. And the main problems still are:
- bad sysadmins
- spam laws are different in all countries
- people not updating there windows :)
And so on.
There is not a one-in-the-box sollution for this problem....to bad.
Gerwin
Why did I choose HTTPS, SOAP and XML, well firstly because is is a really simple protcol to use and basically you can completely encapsualte an email in an XML/SOAP object, allowing for a simple development and parsing model. Sure you could probably say that parsing XML documents is slow, but as SOAP gets more refined, so will the parsers.
HTTPS was nt my initial choice in protocols, instead I selected HTTP, the proble was how do you easily identfy a potential spammer? X509 Certs were an easy standard way in which a company who legitimately sends email could identify themselves. Most companies today are able to easily apply for an X509 client and Certificate, providing they are a valid company. No more hiding behind an anoymous system. All Client certificates can be traced back to a source, if they abuse the the system, their certificate is revoked, simple and reliable.
As with the GPL, I don't see the RFC Draft as part of the GPL, only the code I wrote to see if the idea worked, I wanted to protect the work I had acheived from being ripped off by some company and sold as an implimentation. As the the C# part, c# is really easy to develop Web Services under, and as a prototype it was the best choice. If anyone wants to develop it using C++ and gsoap, go for it!. BTW take a look at the Mono project, perhaps it would run on Unix.
There are lots of documents on the web site relating to the project, give them a read and we can discuss the idea further.
Post a Comment
<< Home