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
Read the draft. The protocol authenticates *servers*, not individual messages, and the communication between servers is encrypted (by RFC2246), so there no plain-text certificates going around the net.
For those complaining (who havent read the spec). The MTA is the one who buys the Cert. Not the end user. Can people still spam? Of course. Any system is vulerable. This just lets you know where the spam is coming from. Then the local MTA can block it. If they dont, then the receiving MTA can block the sending MTA. It creates a "conform or be cast out" sort of system. Looks better than our current system.
Just my 2 cents...
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
Actually, it might be more difficult than that. If you have dynamic IP from your ISP, or (in my case) you have static IP but the ISP won't change the reverse lookup to my domain, then I can't run an useful AMTP server. You can kiss DynDNS a long kiss goodnight. Even mail to your domain will be affected, so it'll be hard to be RFC compliant respective to some domain e-mail accounts (like abuse@example.com).
The relevant quote from section 4.1 :
The amount of work that an ISP has to do to handle abuse complaints can be quite staggering. This whole concept scares me because I could see it creating a significant amount of abuse mail to ISP's. The worst situation to create is where you have opposing views on the nature of an email. I send an email to someone who's selling something on a personal buy and sell page. The email includes my signature which is very "corporate". They person receiving the message sees the signature, concludes its commercial though I sent it as personal and complains that it violates the policy. I'm not convinced that you could educate the users of the Internet enough to not have this situation exist.
With so many automated complaints coming in in poorly designed formats, from systems with incredibly out of sync clocks, and for the most frivolous issues (My favorite still is someone complaining that our DNS server was attacking them when they received answers to queries they were sending to it.) I think its completely understandable that abuse gets a relatively low response rate. As with everything else, the signal to noise rate gets so bad that the real valid and important complaints get buried.
I do have plans to improve abuse response at my place of work. We plan on automating most of it. Known good automated complaints would get automatically parsed and we would be presented with all relevant information so we can quickly respond (spamcop complaints are a good example of good reports). Anything else will trigger an incident ticket to be generated and require the complaint source to provide information to a website.
Don't even get me started on that. Like others have said, the whole CA scheme is a fraud. Pure money for companies like Verisign. We're paying for their procedures and policies? It is extremely easy to submit fradulent or manufactured document and you WILL get your certificate. At the same time, someone who plays by the rules can easily spend a few weeks dealing with the endless document requests (which seem to change each time you renew, even though they already "verified" who you are and had no complaints in the last year).
I originally had an SSL certificate from Thawte back in 2000 or 2001. At the time it was the cheapest, I think it was $150 per year or something. They requested documents that aren't needed in my state and as a result I didn't have. The final result was I had to get an SSL certificate registered to me personally because they requested documents a Colorado partnership wasn't required to have. When it came time to renew they asked me for a whole new set of documents that a Colorado partnership doesn't have. I explained to them that Colorado partnerships don't have the documents they were requesting and, besides, the dang certificate I wanted to renew was registed to me PERSONALLY, not the partnership. No go, it was like talking to a wall. I told them to cancel the renewal, went to Comodo where I pay $69/year instead, and they were able to process my certificate with no problem.
The whole CA scheme IS essentially a scam. I certainly don't trust someone just because Verisign or Thawte says I can trust them. That's just silly.
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/
I'm suprised noone has brought up Hash Cash yet as a technical means to stop spam:
"Hash cash is payment in burnt CPU cycles by calculating n-bit partial hash collisions on chosen texts.
The idea of using partial hashes is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly. This can be used as the basis for an ecash system measured in burnt CPU cycles. Such cash systems can be used to throttle systematic abuses of un-metered internet resources."
Now we just need a decent RFC for mail transfer!
Thawte offers free e-mail certificates.
- Can't those be used?
- Isn't that a good enough price?