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."
Try http://www.cacert.org/ as a free Certificate Authority...
-- Shaun "Blessed are the geeks, for they shall Internet the earth"
Simply put, it isn't.
If you actually had red the draft, especially section 3 you would have seen that it is in essence smtp enhaced by tls:
3. The AMTP Model
Authenticated Mail Transfer Protocol (AMTP) is based upon Simple Mail
Transfer Protocol (SMTP, [RFC2821]) and addresses the twin problems
of authentication and codification. AMTP uses Transport Layer
Security (TLS, [RFC2246]) to create an environment of trust between
Mail Transfer Agents (MTAs) involved in a transaction. MTAs then
exchange Mail Policy Codes (MPCs) to establish permission for mail
delivery.
AMTP inherits the specification of SMTP and builds upon it. This
document specifies only the changes to SMTP and therefore implicitly
incorporates the latest SMTP specification [RFC2821] except where
indicated.
So RTF!
www.instantssl.com/ is he only Certification Authority providing low-cost, fully-validated and warrantied SSL Certificates.
> So why is this SO different from using TLS ?
> Remember that smtp is still used and you have to be backward compatible....
From the FAQ:
Why not add this capability to SMTP as an option?
This solution will only work if it is exclusive of existing practice. In order to solve the problem we must stop accepting traffic from non- trusted sources.
So the diffference is just that, it's not backward compatible ....
RFC1925
True but who's going to actively sue the spammers for their illegal activity? The only people with the money and resources to do that effectively are the ISP's, and so far most aren't tackling the problem.
Re. withdrawing the certificate, no-one is going to withdraw the certificate of a major ISP even if a spam flood is originating from their network. The customers computer that has been compromised is connected perfectly legitimately to the ISPs mail server and is 'legitimately' sending it emails.
Sure the ISP could cut their account for sending x thousand emails, but then again they could cut existing spammers accounts at the moment for sending thousands of spam emails... but they don't.
Re. contact information in the spam, we're dealing with people here who really will simply ignore the law, they will use a myriad of techniques to claim that the spam advertising the service is in no way connected to them. Unless you can prove that the company/person identified in the body of the email was the person who sent it that doesnt get you very far.
Jon.
problem has already been considered and solved. The camram project uses a recipient bound token as its "payment". There's no need for any central infrastructure, it can't be co-opted by any central organization, it hit spammers where it hurts (throughput of messages, economics) and it can't be forged.
Take a look at the camram project you'll find a practical, working implementation of sender pays email today.
http://www.camram.org and camram.sourceforge.net
The end to end principle is vastly overrated. If you read the actual design documents written by David Clark on the end to end principal you will not find the dogmatism that has since surrounded it.
The Internet works in large part because the end to end principle has been applied in the right places. But that has a corrolary most of the problems with the Internet are cases where the end to end principle has been applied in thewrong places.
Nobody advocates that IP routers should inspect each packet to see if it contains spam.
No but almost everyone is advocating that ISPs should take action to make sure their users do not spam. The principal here is perimeter security, just as every enterprise should have a firewall every enterprise should be responsible for their spammy customers.
The problem I see with AMTP is that TLS only provides transport layer security. A much more robust approach is to apply message layer security.
The issue is not technology, it is politics. To get a change like AMTP to stick you have to have the political clout to effect a change in the Internet infrastructure. Bill Weinman does not have that clout. In a perfect world the IETF would, unfortunately the IETF has spent much of the last twenty years systematically pissing off every corporate developer and most of the open source ones as well.
That leaves us with the big ISPs as the way to deploy changes to the email infrastructure to fight spam. So far they have announced that they are talking and nothing have been heard from them. In fact there are quite a few folk associated with those companies who have gone very quiet all of a sudden.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/