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."
But in general end to end security models like this have had trouble because it has not been possible to get central signing in a way that can be administrated cheaply enough to allow wide deployment. I fear that this will fester in the same acceptance purgatory as DNSSEC, for roughly the same reasons
So why is this SO different from using TLS ?
Remember that smtp is still used and you have to be backward compatible....
I truely dont see how this is usefull. It seems like a desperate act against spam. Instead of going after spammers legally and work on a better way to filter junk mail they go for the NUKE? There are also down sides to http/ftp should we change them as well? The answer is no.
Dont just mail it - Maileet
Oh yeah, sure. And I've got this really nice bridge to Brooklyn for sale here, too.
Now, viruses browse your contact list and send a message to everyone in the list. If this breaks through, the viruses will browse your contact list, and send a message to everyone in the list using the key, something which Outlook will probably do automatically.
Oh, yes, there is one difference. The CA will get lots of profit for selling certificates.
From the Draft:
This specification addresses the issue of Unsolicited Bulk Email (UBE) by providing coded tokens to identify mailing handling policies. It is possible for a sender to use a trusted MTA to transmit false tokens and thereby subvert an MTA's policies.
So it would be interesting if implemented with legislation rather than without; that way there is a serious disincentive for spammers who manage to subvert the policy.
Never underestimate the predictability of human stupidity...
A new 4 point plan for SPAM:
1. Hijack domain
2. Get CA to issue cert
3. Spam (or ?????)
4. Profit???
People who routinely hijack entire netblocks to send SPAM are not going to be bothered by providing fraudulent credentials to a CA.
What about a spammer puting a false "Personal" bit instead of "commercial" in the protocal to get through?
Let them. Advertising gadgets is not illegal. Lying in order to do so is.
My Karma: ran over your Dogma
StrawberryFrog
although i have not researched this idea in much depth, it seems to me that charging fractions of pennies for each outgoing email would go a long way to eliminate spam.
I would envisage building an MTA infrastructure around a PKI that works like the clearing banks. e.g I 'pay' to send you an email, you 'receive' the 'money'. You do the same for sending your email. At the end all the servers 'settle' up. Since spammers send so much more then receive they loose $$$$ and go out of business.
...I can't run an AMTP server off my DSL unless I pay for a CA? Sounds to me like the IETF are trying to lock the widest used method of internet communication into a more 'corporate' structure. I thought we learned our lesson with telco?
but anonymous communication via e-mail is probably dead with this idea. I wonder if the price is too high.
Using TLS has a benefit in cutting down forgery and making spammers easier to trace, but asking all mail system administrators to set up X.509 certs is a huge amount of work for that small gain. (eg. I'm sending an email to 10 of my friends to ask for sponsorship for a sponsored bungee jump -- how do I tell my ISP's mail server to use entity "ngo" instead of "per", and what are the chances I haven't a clue I'm supposed to do this?)
The Mail Policy Code is a waste of time. Spammers will lie, and a huge proportion of everyone else will get it wrong through carelessness. It's chief benefit would be to help legitimate bulk commercial email (which is difficult to allow through content-based filtering), but I think the future of that kind of communication is in "pull" protocols where the subscriber rather than the publisher controls the subscription. (I outlined a couple of ideas in an earlier comment).
Email is now Dead for public general use, good for corps, bad for people, Pay for a Cert, nope.
You are going to see SMTP run side by side with AMTP, its not going away, if it does, ur going to see IM take over for public comms. (Its already doing that).
The thing you're paying for, is trust.....
Anyone could create their own certificates, but without a mutual trusted third party signing it, how do I know it's real?
CAs are a fairly practical substitute for the Web of Trust concept used in things like PGP...
That said...it still feels wrong to have to pay someone for essentially nothing....
and you still have the problem that the certificate doesn't really prove who you are, only that a CA accepted money to vouch for your identity.
Advanced users are users too!
I'm company A.com, and I buy a certificate (or get one for free from some free-sign authority). I use it completely legitamately. Only for receipts to paying customers, and to deliver "timely updates" for their software or whatever.
Now I fall on hard times. And go broke.
In the liquidation proceedings, a spammer swoops down and buys my certificate. It's a valued commodity to him, and the courts, I don't believe, are not going to care about the nefarious purposes he may have in mind.
But now lots of people are getting spam in my name.
So, would the CA have the power to "ungrant" the certificate, and therefore also be able to hold thousands of companies hostage. (Imagine starting as a 'free' service, and then suddenly 'changing your policy'.)
Or will the clients at the end have to say that certain CA's aren't valid. If so, how is this different form white-list/black-list.
Now, anything that tries to fight spam I am for. However, I believe the number one thing needed is accountability. If someone sends me mail, I need to be able to reach out and touch them, with a phone number or anything else I feel like. And the latest round of email viruses wouldn't work if I couldn't fake the address it was being sent from.
I demand a million helicopters and a DOLLAR!
"What happened to the freedom of speech? "
Absolutely nothing.
You still have exactly the same freedom of speech as you did before.
Who is suddenly removing your right to say things? Nobody.
People should not be afraid of their governments - Governments should be afraid of their people.
If mailservers had valid reverse-DNS entries and would send their real name with HELO at the start of SMTP communication a lot of spammers were not able to spread their stuff.
If i enable checking of HELO domains almost all spam is gone, but also a huge number of valid email servers too (sourceforge.net for example) simply because they are setup incorrectly when it comes to HELO and DNS stuff. If DNS and HELO commands were setup correctly (and are checked at the servers) then spammers cannot stay anonymous like now, because they have to use their real domain-name (registered to somebody) have to setup valid reverse lookups (IP adresses normally belong to the ISP - so the ISP has knowledge of who requested which reverse domainname). Now i can log who sends me spam and can identify the person behind it, or blacklist the server. The problem is that correct HELO is not a must in current smtp rfc and people don't give a shit about correct dns setups.
Being more strict on SMTP will not stop spam, but it will make it harder for spammers to stay anonymous and operative (blacklist-servers) plus there's no need to pay a CA to issue SSL certs for all my domains.
First of all, the CA has a business interest in selling as many certificates as possible, so it does not make sense to assume it will exert due diligence to find out whether someone is a spammer.
Second of all, spammers won't go to the CA and make it obvious they are spammers. They will pose as flower delivery agents with a brand new name, and the CA will give them a certificate and that's it. Then the spammer will start spamming, someone will complain to the CA, and they will issue a revocation certificate. In case you don't know TLS very well: revocation certificates do not scale AT ALL, it basically means that the AMTP server needs to have all on disk or we need a protocol to get them (possibly LDAP?). Since spammers will be using throw away identities just like they do now, I am seeing millions of revoked certificates.
So the only thing this approach does is create an artificial bottleneck at the CA, because they will be responsible for revoking the spamming "rights". Spammers will still spam and then in response be denied access, just like now, so even if this CA stuff works perfectly, and we have a high performance revocation certificate request protocol (which by the way entails enormous bandwidth cost for the CA, if all the mail servers in the world send a query for each incoming email, think about it!), we will still have exactly the same amount of spam we have now, because spammers will still spam first and be denied access later.
The next question is: what do we do about non-responsive CAs? Let's say Verisign gets in the email CA business, and they basically run the same fully automated CA business they do now, and they get bribed by the spammers just like ISPs get bribed by them now, and they don't revoke the certificate of a spammer, what are you going to do? Not accept any mail from anyone signed by Verisign ever again? That is basically your only option, and it is even worse than the collateral damage we have these days, when "only" one IP is barred (not counting SPEWS). If you think bribing Verisign is unlikely, consider the stakes! If you successfully bribe Verisign as spammer, you basically have permission to spam everyone, all over the world, and nobody can do anything about it except what we do now, unsuccessfully, i.e. block single IPs. And the spammers are still in business, so it's not enough.
So all in all, I think this is a spectacularly bad idea that will not work on ANY level. The up side is that it may finally bring encrypted email to everyone.
Individuals don't really give a damn about getting CA signature, since if you read the small print for 'personal certs' you'll see the trust bestowed by the signature is worthless anyway. So after a lot of screwing around, you end up with a cert which if you're lucky is free but otherwise costs $10, that carries no trust and expires in a year or six months anyway. Whoopee. That's even assuming you have enough of a clue to figure out how to get a cert in the first place.
OpenPGP is the perfect solution here since people can whip up a key in no time, for free and it effectively implies the same level of trustworthiness as the one from the CA which is to say none whatsoever. Over time however they can build more trust into the key by getting their friends and associates to sign it.
Now for businesses, PGP is fine too. There is nothing to stop a CA signing a PGP key, so if a company wants to buy real trust for their key, it is there to be had in the same way as you get from PKI.
Which begs the question why anyone bothers with PKI at all, or why OpenPGP is not being integrated into the x.509 standard. As it stands no email software integrates PKI seamlessly, it's too complicated, it's too slow (it uses RSA for the entire message unlike PGP), it's too hard to get a key and it offers no more trust that PGP.
It seems to be somewhat of a lame duck really.
As long as there's money in spam, there will be spam.
What if, as some people believe, the spammers aren't in it for the money? What if they are just sending spam as a DoS attack?
I get lots of spam that has no business purpose. "Get out of debt now," "Add length to your member," "Herbal Viagra." I challenge you to actually buy the product or service these emails are supposedly advertising. In many cases, it's simply not possible. They are not actually selling anything; they are just being a nuisance.
First of all, we need good, sound anti-spam laws.
I get lots of other spam that is pure fraud. "Hotmail needs your credit card info to prove you are not a spammer. Just enter your credit card number and click submit" or "Help me launder $20 million from Nigeria. Just give me you bank account number and I'll wire it over." These are already illegal. We don't need new laws for these; we need enforcement of existing laws.
There are always already laws in many jurisdictions outlawing emails with forged headers. Yet such emails proliferate. Again, new laws are not the answer, enforcement of existing laws is needed.
Besides, why do *I* have to jump through hoops to get rid of something I never asked for in the first place?
Because we live in a society that is not utopia. As nice as it would be to live in a world where everybody is good and nobody behaves unethically, such a world does not exist. It is every individual's responsibility to take action to protect or defend themselves. When we sit back an accept something such as massive spamming, we are implicitly saying that the status quo is okay with us.
Lots of posters in this thread seem to be assuming this proposal is to force everyone to buy a cert to be able to send mail. The spec requires mail servers, not individuals, to have certs. Therefore, your ISP would have a cert to say "yes I really am someisp.com" when sending your mail.
The majority of spammers already stoop to lying in their FROM: header lines, so i doubt that setting a "personal" bit will keep them awake at night.
Yeah, good point... in a rational world, although, I suspect:-
a) my local constabulary in Surrey is going to be totally disinterested in the actions of a florida spammer.
b) so is my local MP. I have enough problems getting him to tackle very local issues.
c) the Florida DA (or whatever would be appropriate) is likely to be disintersted in the plight of some limey recieving spam from one of their tax paying, voting citizens.
Unfortunately I think in these situations the only people likely to get anywhere are the weasels , sorry, lawyers.
No all you do is block any Server with a fingerprint that has been shown to be the originator of spam, because that means that they are not authenticating its users, or that they are purposefully spreading spam.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
"Just because some random signing-whore ... The CA will sign *any* key for a price"
Speak for yourself. But your point drives home an issue that PGP handles well - webs of trust are more easily grown, though less able to bear liability, than top-down hierarchies. The real question is how do you write an algorithm that allows new folks to send you mail without allowing EVERYONE (including spammers) to send mail. Authentication helps, but it doesn't address the trust issue.
Remember the "old days" when email was mysterious, and the only way some folks could send you mail was if you could send them one first that they could reply to?
Well I am my own small ISP and I move about 10,000 emails a day for me any my clients (much of which is spam). _I_ would still have to pay an outragious sum for a cert...
What I would like to see is a Mail server with some memory of its history with other mail servers. Histogram of SMTP transations, by IP, sender id and domain, and recipient id and doamin. If you are getting hundreds of spams from an IP address, it would be nice to tar pit/block the SOB with a simple interface into the system, with automatic expiry times. It is the automatic expiry times that are key. If you do not have that it makes going back and cleaning up the future collateral dammage/innocent victims impossible to manage.
The SPAM problem would be significantly reduced if there were software to easly manage incoming mail using statistics by a human. The automates systems are ok, up to a point.
I would write something myslef, but I'm too busy combating the problem to have time. *sigh*...
Close..
The actual requirement is "The MSA knows who the sender is, and provides an audit trail".
There's no reason for the MSA that I use to know all my E-mail addresses. In fact, once it's authenticated me, there's no real reason for it to even look at the RFC822 From: header, because it knows who I am, it's logged who I am, and if I try anything funny, the MSA admin will know where to find me and beat the snot out of me.
The *real* problem with this proposal is that there's the underlying assumption that a CA can't go rogue because it will hurt business. There's only one problem with that:
There's several *large* providers that are spammer-friendly, and aren't being blocked by the rest of the world mostly because they also have enough *legitimate* customers that it's not feasible to block them.
If you're an ISP, you can't block another ISP because they're a spam haven if the other ISP also happens to be the home of CNN, or Amazon, or (fill in the blank).
Similarly, you can say "We'll just piss on any CA that goes rogue". It's a lot harder to actually DO if you suddenly discover that the same rogue CA also signed the cert for AOL....
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?
Maybe you are looking for greylists?
suggests using a 'Mail Policy Code' during the transaction to identify what kind of mail is being sent (administrative, personal, commercial, etc).
And we all know that spammers never lie!
Unless there is an enforcement mechanisms that involves cattle prods, this is a joke.
A major problem with the current system is that domain names and (misused, temporary or stolen) IP address are nearly free. Thus spammers can collect zillions, and the blacklists become unstable (where collateral damage effects some people worse than the spam). The way to avoid this with mail transport certificates is to make them costly enough that spammers can't collect them by the busload, and that also cost enough to pay for determining that the applicant is a real person with a verified contact address (where, say, papers could get served for forgery and violating UCE laws, etc.).
People (and spammers) who can't afford an account on a server with a proper certificate can still use SMTP. But, unless I'm a police/medical/whistleblowers tipline, or have family in Nigeria, I don't have to accept such email.
Maybe this has been suggested before, maybe not. How about a key that is only known to the MTA? Any legitimate email sent out will have a header added which includes the hash for the key and the actual email. This hash is added to a list of submitted messages with an expiration time. Once the email is sent out, the receiving end takes that hash, and submits it to the MTA which supposedly originated the message, to be verified or rejected. If a hash is verified the originating MTA will take it off its list.
This should be a simple process which has at least two major uses... First, email viruses which are bypassing the legitimate domain MTA will not have a valid hash in the header. Second, any email where the origination is forged will also not contain a valid hash.
The list of sent hashes that the MTA maintains could further be enhanced by including the hash of the destination address where the email was sent to.
In essence, a header would be added to each outgoing mail as such:
X-Authenticate:
With an ever-changing table of valid hashes, it would be nearly impossible for someone to forge a legitimate hash. Even on the off-change that a hash WAS forged, a spammer would only be able to send a single message with that hash, then the MTA would expire it.
Of course there are some cons against this plan as well... There would be a small increase in traffic required to send a single email (negligable, maybe a few hundred bytes at most). Each MTA would have to reserve space for a hash table, the size of which would be based on the number of unreceived messages at any given moment, and how fast hashes were expired from the table (do you give up on sending a message after 5 minutes or 5 days).
The best thing about this method is that it provides a means of authenticating the sender of a message which is backwards-compatible with existing MTA's.