Slashdot Mirror
AMTP as an Alternative to SMTP
SamMichaels writes "AMTP was published as an Internet Draft last week. It suggests using a 'Mail Policy Code' during the transaction to identify what kind of mail is being sent (administrative, personal, commercial, etc). Another plus is the use of TLS using x.509 certificates signed by a CA so you know exactly where the mail came from. Sounds like a solid plan...now to get a certificate signed for a decent price is the challenge."
WHy should everyone pay CA for the certificates, we already pay for the domain name if they want to require certificates, then you should get one for your domain free with the domain! Ah I hear you say its so CA can vet people. No thats not the case, anyone can get a certificate for a domain they own all this does is make sure you know where the mail came from (not a bad thing) and impose a CA tax on all domains.
James
Also spammers could just register themselves and keep spamming. They could just use a different ISP every 48 hours so in this way could never be stopped. A new address for every spam could be used. They could identify themselves as a home user so email filtering software will let it through. After that spammer is banned he/she will have another address and use that.
http://saveie6.com/
A good idea to start with...
However, after having spent the weekend tracking and blocking a flood of SoBig viruses from a couple of large canadian ISP's which has focused my thinking this morning, I think this type of system will again simply cause the spammers to look for alternate delivery systems, i.e. as more ISPs take a tougher line against spam, more and more spammers will start to take extreme measures to propagate their product.
So cable modem users with big bandwidth and vulnerable machines will be used to send the spam. The spammer uses a worm to find vulnerable machines and piggybacks the users connection and sends the spam, it still goes through the ISP's mail server and so will get validated and delivered.
Also, unless I missed something (possible) even though the recipient can specify what type of email he will accept, there's nothing to stop the sender simply specifying whatever they feel like.
An amusing aside, I sent a warning to one of the ISP's (sprint.ca) that was the source of the viruses on friday warning them of their problem, the flood (one every 30 seconds) was still going on during sunday, so I sent the same warning but copied in their 'corporate customer email' and 'noc@' email contact addresses, believe it or not I got a response within an hour telling me that they didn't appreciate me "SPAM"ing their email addresses and I should just email "abuse@"! Oh and the virus flood is still going on. Ho hum.
This draft fails to provide any significant advance over SMTP. The use of TLS and authentication between MTAs merely provides a mechanism to identify policy violators. It does not (as the draft recognises) prevent fraud against a CA, it does not address the problem of distributing certificate revocations, it opens the door to a new era of DoS attacks against CA services (which will likely be far less robust than the DNS system), increases the barrier to entry for the ISP market (with costs being passed on to consumers, of course), and the opportunity for politically based service interrupts (like we already see with SPAM black lists) is just plain scary.
Further to the last point: ISPs are generally forced to react to SPAM rather than be proactive (it is generally impossible for an ISP to distinguish between UBE and opt-in lists). This means that spammers will always be one step ahead, and any network with enough bullying power can summarily demand the revocation of another ISP's certificate for policy violations. An entirely new class of disputes will arise, making SPAM black listing arguments seem tame.
The additional responsibilities this draft places on end users is also unacceptable. You will have to remember to flag your message "commercial" or "personal" and whether the distribution is "individual" or "customer". And of course is someone complains about the classification you could end up having your service terminates, so that the ISP can prove it took appropriate action against the "abuse".
We have to accept that it is a fact that we cannot get away from SPAM. The postal and Internet mail systems rely on the opportunity to send a message to any recipient. Implementing a client side PKI-based whitelist for mail would be trivial (and many people do this), but destructive to the communication medium. The object is not to get away from SPAM, but to ensure that we, as recipients, do not bear the cost of SPAM.
Any system that filters messages at your mailbox, or your ISP's server, costs you money. Your bandwidth and your ISP's bandwidth are wasted. AMTP may reduce this, but adds other hidden costs like a certified key and probably the ongoing maintenance of good relations with many peer MTAs to avoid accusations of abuse.
Anyone interested in alternatives to the SMTP system should take a look at D. J. Bernstein's Internet Mail 2000 ideas; in brief, the sender holds the message in his/her mailbox and make his/her bandwidth available to allow the mail to be downloaded by the recipient (who can obviously choose not to download it).
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
There are also down sides to http/ftp should we change them as well? The answer is no.
Actually, the answer IS yes. Or, maybe you would like to go back to using gopher?
If we change to a different email protocol we can still use the old protocol alongside of the new, and when the new protocol is widely accepted and in use, just shut down the old mail service.
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
"There are also down sides to http/ftp should we change them as well? The answer is no."
Erm, actually, the HTTP spec HAS been changed in the past to overcome deficiencies in the original.
HTTP/1.0
HTTP/1.1
HTTPS
I think the answer you were actually looking for was "yes".
People should not be afraid of their governments - Governments should be afraid of their people.
The best way to deal with spam is to educate the masses so that spammers get less and less ROI and eventually go belly-up. Problem is, this will probably *NEVER* happen. There are just too many suckers out there waiting to be taken advantage of.
Laws won't help. If you're lucky enough to catch a spammer in a state/country with strict laws on spam, they'll just get some small fine. If spammers can affort their own mansions from their work, the fine won't really work, and I fear the possibility for abuse with yet more laws is significant.
So what remains? Short of ritually butchering spammers, which I think is still illegal in some places, I don't see any viable options.
The International Postal Union and the national postal authorities of all the countries of the world should provide free certificates for their citizens. Its a basic authentication document like a passport that should not be left to private concerns for security reasons. Private corporations could be charged some kind of nominal user fee (*really* nominal). I know we don't usually go for government programs but I've never heard anyone suggest that Verisign should be allowed to raise an army, mint coins or issue passports. I think I heard awhile back that the Canadian government is issuing certificates to all its citizens so they can access their confidential government info online. Of course the benefits would be lost if the U.S., for example, subcontracted to Verisign to do the work. That would just be another taxpayer rip-off by a big political contributor. If U.S.P.S. couldn't do the job with internal resources maybe we should find some new people to run it.
The mail server can not get out of the way. Remember, the end users are annoyed at the SPAM, but the ISPs have to pay for all the traffic. The ISPs will jump at the opportunity to eliminate the SAPM traffic. End user is to late for that.
As I recall djb had an alternative to SMTP called Internet mail 2000. The interesting thing about that was that the e-mail wasn't stored on the ISP's spool, but the senders spool until requested by the person whom the message was delivered to. It's an interesting concept. I think the combination of AMTP and internet mail 2000 would a good idea. The biggest advantage of this 2 pronged attack would be that the amount of cost shifting that occurs with spam would be greatly reduced and identification of the spammer is easier.
AMTP is a good idea but like any good idea there are a few caveats -
1. SMTP is simple and requires little overhead - that is gone with the X.509 certs and TLS
2. One may setup a web-server or mail-server at a moments notice to deal with traffic or get a project finished pronto. With AMTP that machine will have to get an x.509 cert to be able to send mail (and have it accepted) - thus increasing the amount of time and money that it takes to get these services in place. (Site wide certs would sacrifice the ablity to truly identify an offending machine)
3. There is nothing to stop a spammer from getting thousands of certificates and burning through them as they spam. Many spammers already right off dial up accounts, DSL, T1s and other form of access on an almost daily basis. This will simply be a another small expense that must be endured to send out an advertisement to "21 million confirmed opt in customers".
4. This won't stop spammers from hijacking others valid certs, such as on webservers running formmail.pl or mail servers that allow relaying or proxying through them.
The saddest part of this proposal is that eventually the "altruistic" protocol SMTP will die. Don't get me wrong, SMTP has a lot of flaws, but if you think of it in a more philisophical sense, it's a little sad. The Internet was based on the free exchange of ideas - and more importantly traffic. The spammers have forced us to censor ourselves, reduce or try to eliminate anonomity and move away from the "I trust you" model to the "your bad unless I can prove otherwise" model. The death of an egalitarian idea, that anyone could send e-mail. One more victim of spammers.
In the end if you want to stop UCE you will have to take the costs of such a business out of the cyber world and put them into the real world. This is a step in that direction.
cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
The whole point is that it DOES involve the Evil Bit, aka com/optout, but that it includes a mechanism for detecting people who don't set the Evil Bit when they should have.
The only problem is that you have to trust the CA's to revoke certificates from people who misuse the system. Trust Verisign? Hah!.
Watch this Heartland Institute video
Why does slashdot not let me put &EUR;?
Watch this Heartland Institute video
Sorry. Not a good idea:
1. Security does not go any further then the TLS extension to ESMTP. If you force TLS in ESMTP you get the same result.
2. There is a plethora of "codes" for SPAM which will be abused the same as now and will require regulation.
3. It suffers from the same problem of SMTP as it is hop per hop, not end-to-end.
4. It breaks country laws in many countries which are still being anal-retentive on encryption.
Instead of this horrid garbage all that is needed is the following simple fix/extension to SMTP:
1. Messages should be signed by every gateway on the way with the sertificate of the gateway. The sig should be inserted as a "Received-signature:" header which covers the mail and the lines of the header that exist so far under it. Thus even if you do not have a cert for the end-user, but trust the relay you may decide to accept the mail and optionally add the user to your cert trust tree.
2. Gateways should no longer modify any headers prior to the ones they add (some do - see spamassassin for example).
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I begin to wonder who would have an interest in bringing down an infrastructure like email. Maybe not terrorists, but another crop of anarchists. Still, it is almost ridiculous that we put such an economic importance on something so unsecure. Everything else has to be locked down by all sorts of wrappers and authentication, but this we find acceptable. Time to lock the doors before all the horses get out.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
Right, but you cant just block *@comcast.net or *@aol.com, just because some jackoff using his cable modem is sending spam. Then you are no better than AOL.
The spec does not require everyone to get a cert. It requires everyone to have a log in with an amtp server which has a cert. This way if one server is shown to allow too many spammers through the whole server can be effectively blocked. Essentially, it will force servers to authenticate all mail transfers. But user to server authentication would still be done using user/pass, kerberos, SRP, CRAM, or whatever the server sets up. Sounds pretty good to me. I haven't read the spec yet, I only hope it still includes SASL authentication to make the move a lot easier.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
https://www1.ietf.org/mail-archive/working-groups/ asrg/current/msg05876.html
-- Ziggy Sig Sig
hm... so how is this supposed to stop any spammer? Of course this would authenticate the server, but couldnt some future spam trojan simply generate those keys?
To turn that question on its head: how would a central cert stop a spammer? As you point out, either the cert or a public/private keypair offers only assurance that a message was processed by a specific server. It's a signature in the header assuring traceability to a specific point. In neither case would it stop a spammer, especially if the server site administrator allows spamming services to originate from his/her server to the outside net. The primary advantage of a public/private keypair is to remove unnecessary central authorities from the email process. It allows for scalability through decentralization.
As for your trojan question, I'm not sure I understand. If the mail server was compromised, sure - someone could gain access to the private key and then sign outbound messages as that server. This is no different than if a server using a central cert were compromised.
Cheers,
Maynard
... Know who can afford to get "Level 1" certs by the dozens? Spammers. Know who can't afford to get a cert of any kind? The homeless guy at the library computer emailing to his buddies from hotmail about how the cops beat him up (yeah I'm pulling out emotional rhetoric, bad me).
How about those background checks for certs? I bet the aforementioned homeless guy would have alittle problem with that. Not to mention anyone with an interest in privacy. I'm *sure* the chinese government and the ashcroft regime would love a scheme that required that level of certification and registration in order to communicate online...
I've finally had it: until slashdot gets article moderation, I am not coming back.