AMTP as an Alternative to SMTP

Yes, but by Anthem.uxp · 2003-08-31 23:33 · Score: 5, Funny

does it involve the Evil Bit ?

Re:Yes, but by Eunuchswear · 2003-09-01 01:26 · Score: 2, Interesting

does it involve the Evil Bit ?
Why not read the RFC?
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
Re:Yes, but by Directrix1 · 2003-09-01 02:09 · Score: 3, Insightful

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
Re:Yes, but by Brushfireb · 2003-09-01 02:17 · Score: 2, Interesting

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.

Its a good idea by blaster · 2003-08-31 23:34 · Score: 5, Insightful

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

Re:Its a good idea by Ed+Avis · 2003-09-01 00:17 · Score: 4, Insightful

I'd hardly call it end-to-end. Here we have the mail server poking its nose into what type of mail is being delivered. It would make more sense for the mail system to get out of the way, deliver the messages, and let the users decide what they want to receive. Nobody advocates that IP routers should inspect each packet to see if it contains spam.

However, authenticated connection for mail delivery might not be a bad idea anyway, to stop DoS attacks based on sending millions of messages - even if all those are rejected by the recipient it still clogs the network, and unlike spammers, DoSers aren't trying to make money but just to cause a nuisance.

Apparently the main point of AMTP is to make it harder to spoof addresses. But it's still possible, so I don't think AMTP will change the general rule that no message header is to be trusted. PGP signatures blah blah blah are the only way to make sure a message comes from who it claims to.

--
-- Ed Avis ed@membled.com
Re:Its a good idea by AftanGustur · 2003-09-01 00:28 · Score: 5, Insightful

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.

If the state is serious enough about this problem (and they will, one day) they will manage and issue certificates for whoever wants one.
It shouldn't have to cost more to manage a certificate than it costs to manage a credid card account .. Even less, since once the issuer has issued the certificate, he doesn't have to protect any part of it himself.

--
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Re:Its a good idea by dnoyeb · 2003-09-01 01:13 · Score: 4, Interesting

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.
Re:Its a good idea by Omnifarious · 2003-09-01 01:28 · Score: 4, Insightful

Why is central signing needed at all? That's a complete fallacy. How do you decide that someone is who they say they are in the real world? Do you look at their driver's license or passport? That only happens during the minority of communications in which you actually pay someone, and even then it doesn't happen if you use cash. It cetainly isn't appropriate for every email messge.

--
Need a Python, C++, Unix, Linux develop
Re:Its a good idea by Eunuchswear · 2003-09-01 01:28 · Score: 2, Interesting

it has not been possible to get central signing in a way that can be administrated cheaply enough
What, you find 370 EUR/year too expensive. Funny, so do I.
Why does slashdot not let me put &EUR;?

--
Watch this Heartland Institute video
Re:Its a good idea by arivanov · 2003-09-01 01:46 · Score: 4, Interesting

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/
Re:Its a good idea by Zeinfeld · 2003-09-01 04:23 · Score: 3, Informative

I'd hardly call it end-to-end. Here we have the mail server poking its nose into what type of mail is being delivered.
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/
Re:Its a good idea by Omnifarious · 2003-09-01 06:55 · Score: 3, Insightful

We do present id every time we speak. We normally call it a face or voice.

The 'official' id is the equivalent of certificate signed by a generally accepted authority. And, most people would (rightly) be highly offended if you asked them to present something like that every time you spoke to them, even if it took them no time or effort to present.

--
Need a Python, C++, Unix, Linux develop

Free Certificate by CountZero007 · 2003-08-31 23:35 · Score: 4, Informative

Try http://www.cacert.org/ as a free Certificate Authority...

--
-- Shaun "Blessed are the geeks, for they shall Internet the earth"

Re:Free Certificate by Komarosu · 2003-09-01 00:41 · Score: 3, Informative

Ahh yes free, but still u need to install there root certificate...and if you have to do that then you might as well sign your own.

Lookie here: http://www.cacert.org/index.php?id=16

Basiclly means that every user (sender and reciver) has to have that CA root cert added to there setup...

--

"What do you mean you have no ice? Do you expect me to drink this coffee hot?" - Random Customer, Clerks
Re:Free Certificate by Shadowspawn · 2003-09-01 03:03 · Score: 5, Informative

If you sign your own certificate, you don't have the level of trust as getting a cert from CACert.org.

CACert works on a point system for the level of trust. You must provide proof of your identity to other people that vouch for you - either with legal documentation (depending on the country/legal jurisdiction that you reside in) or inherited trust from another CA - or even from PGP/GPG.

CACert is currently working on getting its root certificate included with browser distributions, such as Mozilla.

To vote, go here: http://bugzilla.mozilla.org/show_bug.cgi?id=215243

If you need to register on Bugzilla first, go here: http://bugzilla.mozilla.org/createaccount.cgi

Certificates can be created for businesses and persons, unlike from most (all?) other certificate providers.

--
It's always darkest before ... daylight savings time.

Why should we pay CA? by oolon · 2003-08-31 23:36 · Score: 4, Interesting

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

Re:Why should we pay CA? by Anonymous Coward · 2003-08-31 23:47 · Score: 5, Insightful

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.
Re:Why should we pay CA? by Eric+Savage · 2003-08-31 23:51 · Score: 2, Interesting

Actually that is the case. Spammers aren't going to be able to fake hotmail and yahoo addresses anymore, and they will have to pay $$ for each domain they get, which will probably last a day or two before its blacklisted, and makes tracking them down easier (if CAs are at all cooperative and/or proactive).

--

This is not the greatest sig in the world, this is just a tribute.
Re:Why should we pay CA? by mabinogi · 2003-09-01 00:24 · Score: 2, Insightful

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!
Re:Why should we pay CA? by hattig · 2003-09-01 00:45 · Score: 2, Interesting

Domains and Certificates aren't the same thing.

You might want certificates for a certain email address or subdomain of the domain name.

The best you might get is a certificate parented off of the registrar's own certificate and the ability for the administrator of the domain name to create more certificates off of that certificate. I don't see companies wanting to give up such a lucrative product however so easily, and I don't see that being free when you pay sweet FA for domain names these days.

And whilst the cost of certificates is ridiculously high for what you get, the details are checked to a reasonable extent, at least with the more mainstream certificate authorities.

Of course, certificates can be used as another means of validating your email. The mail client could have a rule such as "Move all untrusted e-mail into folder 'Not Verified'", and it will have things like "Reject all e-mail authorised via SpammerCA"...
Re:Why should we pay CA? by eer · 2003-09-01 02:10 · Score: 2, Insightful

"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?
Re:Why should we pay CA? by letxa2000 · 2003-09-01 03:55 · Score: 2, Informative

When you buy a certificate it isn't the certificate file that is of real value, it's the procedures and policies that the CA runs their business on.
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.

but...does it work? by njet · 2003-08-31 23:37 · Score: 3, Insightful

So why is this SO different from using TLS ?

Remember that smtp is still used and you have to be backward compatible....

Re:but...does it work? by Anonymous Coward · 2003-09-01 00:02 · Score: 5, Informative

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!
Re:but...does it work? by geirt · 2003-09-01 00:06 · Score: 4, Informative

njet wrote:
> 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
Re:but...does it work? by bourne · 2003-09-01 06:58 · Score: 2, Insightful

This solution will only work if it is exclusive of existing practice.

That was their first mistake.

Had they designed this as an SMTP Service Extension so that it could be integrated into existing mail servers, it would stand a chance of eventually being adopted. Sites could accept both, perhaps treating AMTP messages as SPAM-free for filtering purposes, until use was widespread enough to turn away messages that didn't have AMTP verification.

But to make an all-or-nothing stand will just doom the project. Sure, some rare people will want to run AMTP for cred and SMTP for the rest of their mail. Everyone else will wait for sendmail to create a service extension to do the same thing without having to rip out the plumbing.

Should we change HTTP as well? by acegik · 2003-08-31 23:39 · Score: 2, Insightful

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

Re:Should we change HTTP as well? by Rhinobird · 2003-09-01 00:21 · Score: 4, Interesting

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
Re:Should we change HTTP as well? by ColdGrits · 2003-09-01 00:22 · Score: 4, Interesting

"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.
Re:Should we change HTTP as well? by Gunzour · 2003-09-01 00:45 · Score: 4, Insightful

Yes, this proposal is a drastic move. Quite frankly, I think it's time we start considering drastic solutions to the spam problem. Spam is threatening to collapse our entire email infrastructure. Consider the following:

Some ISPs have long believed that most spam is not about making money but instead is just a massive denial-of-service attack

Recent worms appear to have been designed as a way to send spam through unwitting victims' computers

Spam blocking services are currently combating massive denial of service attacks

Sure, you can track down and go after individual spammers through the legal system, but so far that have proven to be little more than a game of whack-a-mole: knock one down and five more pop up.

AMTP appears to be based on the concept of forcing mail to have accurate headers. To me that seems like a good idea. Unfortunately it does essentially mean replacing the entire email infrastructure. Is it the best solution? I don't know, but it seems to me that it merits serious thought and review.
Re:Should we change HTTP as well? by shokk · 2003-09-01 02:01 · Score: 2, Interesting

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."

What will stop the spammers by Billly+Gates · 2003-08-31 23:40 · Score: 4, Interesting

Can these certificats be over written ? What about a spammer puting a false "Personal" bit instead of "commercial" in the protocal to get through? If part of the CA key is in the message can it be extracted and used again. For example could a spammer get the key out of IBM and pretend the message came from IBM? I know the CA has the other key to verify it but it would have to do it per message. Both keys could easily be extracted or the spammer could fool the CA to thinking that its message really is from IBM and could gain a key from them. If its a different key per message it would surely help but that seems unlikely since billions of emails are sent daily.

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/

Re:What will stop the spammers by StrawberryFrog · 2003-08-31 23:49 · Score: 4, Insightful

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
Re:What will stop the spammers by Eric+Savage · 2003-09-01 00:01 · Score: 2, Interesting

Your point about a huge company like IBM putting all it's eggs in one basket is very valid. The notable difference between this and an SSL certificate is that email is a push, while web is a pull.

Switching ISPs isn't really a problem. The vast majority of spam isn't sent through an ISPs mail server, they almost all have stringent controls in place. Its the people that set up DSL/Cable/Colo mail servers that generate most of the spam, and this would force them to buy a new certificate every day or two, which pretty much blows the budgets of alot of spammers. If someone went ahead and got a whole bunch of certificates, there would hopefully be a much better paper trail for litigation, and the veil of forgery and anonyminity would be greatly weakened.

I can see this becoming a "preferred" transport method. So when you send your mail, if your server uses it, it will see if the destination server uses it, and if not, will revert to SMTP. Once it reached a critical mass (through the help of MSFT, sendmail, postfix, etc all adopting it) it would be a pretty effective way to flag messages as spam (or not).

--

This is not the greatest sig in the world, this is just a tribute.
Re:What will stop the spammers by Richard_at_work · 2003-09-01 02:03 · Score: 2, Insightful

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.

"What kind of mail is being sent" by Anonymous Coward · 2003-08-31 23:41 · Score: 2, Insightful

As if a spammer's mail will be marked "commercial".

Oh yeah, sure. And I've got this really nice bridge to Brooklyn for sale here, too.

No protection against viruses by Anonymous Coward · 2003-08-31 23:43 · Score: 5, Insightful

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.

Security concerns by fr0z · 2003-08-31 23:43 · Score: 4, Insightful

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...

Re:Security concerns by Steve+Cox · 2003-09-01 00:11 · Score: 2, Insightful

> 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.

Thats right. Spammers in Asia will feel compelled to comply with US laws.

Finally! by fuzzix · 2003-08-31 23:48 · Score: 4, Funny

I reckon we can use this system to help Microsoft and AOL track those unsolicited forwards to maximise their donations to sick infants...

Certificates by h0tblack · 2003-08-31 23:51 · Score: 4, Interesting

Certification costs don't seem to be a problem to me. After reading the rfc it seems that self-signed certificates are fine:

A system operator MAY establish different criteria for use over a private network. For example, an ISP may provide self-signed certificates for use by its customers from dynamically-allocated address space. The ISP system operator must use its own precautions to ensure that those self-signed certificates are considered valid only when presented from connections under its control.

Using self-certification a web of trust can be built up, if this is abused, then whichever server is casuing the problems can easily be removed as a trusted server from associated agents. Sure, the system isn't perfect, but it appears to provide a nice balance of compatibility and authentication without adversely effecting a users e-mail experience.

Re:Certificates by linuxtelephony · 2003-09-01 02:33 · Score: 2, Interesting

That's fine for the ISP and the ISP's customers. What is not clear is upstream.

This entry sounds more like the ISP can issue self-signed certs to its customers for them to connect to its mail server.

What is not clear is if the ISP will have to have a different, paid for, signed cert to communicate with anybody on connections NOT under its control.

I am all for improving mail, but look at what happened with signed certs on http. I do not want to see something like that start again. Not unless there is an "open" period where anyone can submit their own CA key to be included free of charge and have them recognized automatically by mail servers after X date. And this "open" period would need to be widely publicised. If not, then we end up right back with just a few companies offering certs for outrageous prices and little to no competition.

One more thing, you can sure bet that as soon as something like this is created, big players are going to figure out how to charge the world for delivering mail. It will be represented to their customers as a way of controlling and preventing spam and viruses, perhaps even called secure mail or something like that. Imagine if AOL or MSN/Hotmail required an MTA license, with a fee, in order to deliver mail from your server. No big deal you say, if enough people are inconvenienced they'll leave. Sure they will, but not enough to make any difference, after all they have "secure mail" now. Of course, the AMTP with required certs signed by a CA just makes all this easier to implement and track, technically I guess the same model could be attempted with SMTP.

It would almost seem better if they could use a model more like SSH. Here's my idea, feel free to dissect it and tell me where I left huge gaping holes (point of view is from your server):

1. Remote MTA attempts to deliver mail to local MTA. Remote MTA is unknown. A key exchange similar to SSH is performed - primary difference is the local MTA gets the key from the remote MTA (instead of the remote SSH client getting key and remote user accepting it) and sends it to the postmaster.
2. The remote MTA queues the message for X hours/days/weeks/whatever and retry at appropriate intervals.
3. Postmaster gets mail alerting of new MTA wishing to connect, including details about the remote end. Postmaster would reply to local MTA with confirmation to accept mail from remote MTA. [This could be automated any number of ways, i.e. automatically accept key from MTAs that correctly resolve forward and reverse lookups and that are not on a black list (host or IP based). This would mean only those that failed the forward/reverse test would be sent for manual review. Other rules could be created as well.]
4. If postmaster replies to deny the request, or if the local MTA expires the request after a period of time, and the remote MTA reconnects and gets a denied message, then the remote MTA would immediately bounce the message.

This is just a rough idea. I am pretty sure the proposal for AMTP is meant to force a bit of control to a third party for authentication purposes to prevent abuse of mail like we have now. However, I don't like being forced to give up that control to be compliant with the AMTP approach.

The idea I propose, while still allowing each to create their own identity, still gives the Admin of the local MTA the full control to determine what/how/who/etc. In addition, the remote ends could in theory remain anonymous.

Of course, both methods fail to address hosts that act as relays. If a relaying host has a CA, then it can be used as a relay. Similarly, my idea, if an lax system allows mail from anyone, and acts as a relay, it has the potential to cause problems. With my idea, the local MTA can just bar the remote MTA from his system once he realizes it is an open relay.

--
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley

how about charging for mail? by zarniwhoop · 2003-08-31 23:55 · Score: 2, Insightful

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.

Re:how about charging for mail? by esj+at+harvee · 2003-09-01 01:14 · Score: 4, Informative

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
Re:how about charging for mail? by zarniwhoop · 2003-09-01 01:33 · Score: 2, Funny

if they are willing to rob a bank to finance their spamming activities, they're far more stupid then we thought!

Good start by orv · 2003-08-31 23:56 · Score: 3, Interesting

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.

Re:Good start by orv · 2003-09-01 00:33 · Score: 3, Informative

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.
Re:Good start by orv · 2003-09-01 02:07 · Score: 2, Insightful

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.

Nice Idea by Goo.cc · 2003-08-31 23:59 · Score: 2, Insightful

but anonymous communication via e-mail is probably dead with this idea. I wonder if the price is too high.

Re:InstantSSL by muirhead · 2003-09-01 00:03 · Score: 3, Informative

I agree!
www.instantssl.com/ is he only Certification Authority providing low-cost, fully-validated and warrantied SSL Certificates.

Open to abuse by Twylite · 2003-09-01 00:10 · Score: 5, Interesting

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

Re:Open to abuse by fyonn · 2003-09-01 00:42 · Score: 4, Interesting

hello twy

I agree with some of your points, I'm not sure that this is the way forward, spam is an evil perhaps but I've not seen a proposed solution to deal with it that I am happy with. I certainly get my fair share of spam which I tag at the server and filter into a special spam folder in my imap mailstore. this is the best solution I've come up with so far for myself and it works pretty well.

the big problem I have with most of the proposed solutions is that it destroys the open and free ethos of the internet, the ability to send email to anhyone, perhaps anonymously is a good thing I think, sure it's abused and there is a certain amount of locking down that we all do, not being an open relay or using dns blacklists for example, but in general we accept mail from anyone using well defined standard allowing the interconnection of any mua/mta/OS to any other.

I don't like segmenting the net into distinct chunks that cannot communicate, ie smtp vs amtp vs internet mail 2000 etc. it's like the IM networks which, imho, really ought to be able to all intercommunicate but can't.

yes, spam is an abuse of the system, but I find most of the cures worse than the disease. maybe my spam problem isn't as bad as some (around 30-40 emails a day reach my spam box and a small few a week make it to my inbox) and while I'd like to get less spam, I'd rather peer through my spam folder once every day/few days to scan for false positives, than have a good chunk of the net completely unable to talk to me should they want/have a need to.

im2k is an interesting idea but it's not short of problems itself. I want my emails to be waiting for me in my local mailbox, not have to chweck my mail, click allow on 18 mails, deny on 32 and then "download" and wait for the 3 meg avi attachment from a friend on dialup (and would he have to be online at the time? or would we have im2k smarthosts?).

also the idea of "pay per email" systems I disagree with too, maybe I'm a tight git, but why should I pay to send email, I've already paid for my bandwidth to (mostly) freely access the net and hosts on it, and what about mailing lists I run a few low bandwidth mailling lists which would mean that other people (the ppl on my lists) would be costing me (the list owner and mailserver admin) money.

while I like the idea of more of our email being encrypted (my server supports tls, with my own self signed cert) I certainly don't want to restrict my incoming email to only those that come in one TLS links, a) hardly anyone uses it, more the pity and b) I get spam via tls too. I don't really feel like going out and buying a proper cert and this stuff isn't a commercial venture, it's for me and some friends.

the other thing is that just because I don't like spam, doesn;t mean that others don't actively want it. it's the same reason that I disgree with those who say that ISP's ought to firewall ports 135-139 etc to stop ppl using windows networking over the internet, after all, it's only supposed to be a lan only protocol. well, perhaps it is, but that doesn't stop some people wanting to share a directory over the net, and why shouldn't they, if it hurts no-one else?

I don't like disrupting the supposedly free end to end connectivity that we supposedly have.

dave

PS. okay, okay, so I was rambling there :)
Re:Open to abuse by NearlyHeadless · 2003-09-01 02:51 · Score: 2, Interesting
You need to do some reading on spam economics. Traditional postal spam is economical to advertisers, despite the cost of snail mail (even given bulk discounts). The costs run into a lot more than a couple of hundred dollars per "run" of mails.
I have read on the economics of spam. Given the real response rate, it would not be economical for spammers to spend an extra hundred dollars a day. Note that if the certificate authority is acting properly, not only will that particular certificate be revoked, but the information used to purchase the certifcate can be used to revoke any other certificates of the spammer, plus track them down for legal action.
In my particular proposal for TLS-based email (not the AMTP proposoal), I stress that it is important for CAs to not only try to verify identity, but to try to verify to a unique identity. In the U.S., that would be something like a Social Security Number (or taxpayer id for business). I don't know how feasible this is in the third world.
Your estimation of the significance of the cost of a certificate is based on US economics. It doesn't take into account the cost relative to income of $200 to an ISP in countries with lower per capita incomes and weak currency. It also doesn't consider the prejudice to small ISPs in poorly serviced regions.
There are certificate authorities in third-world countries. Presumably they charge appropriately for their own country. There are several things to note:
1. I think you are underestimating how much third-world ISPs have to pay for hardware and bandwidth charges. These charges are still likely to be much more than the cost of a certificate
2. Strong identity and inconvenience can be substituted for cost in issue certificates. If you have to present a government-issued photo ID in person, that will help prevent spammers from obtaining excessive numbers of certificates
3. It is not necessary for each mail server to have its own certificate. Mail servers can forward to a shared host. It would be relatively simple for someone in the U.S. to set up an AMTP server. It would accept authenticated SMTP connections from those who are too small or cheap to want to pay for their own certificate. The AMTP provider would count the number of mails sent by each account to make sure that it is not excessive.
  There are already SMTP providers that do this for less than $100 per year. If that is cheaper for someone than running their own server, they should do that.

the MTA buys the Cert by Anonymous Coward · 2003-09-01 00:13 · Score: 2, Informative

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...

Too much work for too little gain by amcguinn · 2003-09-01 00:19 · Score: 4, Insightful

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 will be... by Anonymous Coward · 2003-09-01 00:19 · Score: 2, Insightful

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).

What about bankruptcies? by taliver · 2003-09-01 00:27 · Score: 5, Insightful

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!

Re:What about bankruptcies? by JKR · 2003-09-01 00:43 · Score: 4, Informative

That's what revocation certs. are for. Any certificate/PKI system needs to be able to revoke certificates/keys.
Jon.

Re:No more anonymous emails? by ColdGrits · 2003-09-01 00:27 · Score: 3, Insightful

"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.

creating and enforcing more strict SMTP helps too by HTD · 2003-09-01 00:27 · Score: 2, Insightful

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.

This won't stop spam, but what will? by Cooper_007 · 2003-09-01 00:29 · Score: 2, Interesting

All this does is prevent people from using their own mailserver to send mail directly to the user. It may provide a clearer path back to the original sender, but you already have that with plain ol' SMTP, and it's not exactly proving effective in stopping, or better yet, PREVENTING spam.

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.

Won't work by Fefe · 2003-09-01 00:53 · Score: 4, Insightful

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.

Re:So... by Homology · 2003-09-01 01:15 · Score: 2, Informative

...I can't run an AMTP server off my DSL unless I pay for a CA?

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 Subject of the certificate MUST have a fully-qualified domain name in the Common Name (CN) field that matches the PTR record found by a DNS query of the associated IPv4 address in the IN-ADDR.ARPA zone.

PGP is a better model by DrXym · 2003-09-01 01:18 · Score: 4, Insightful

I don't understand why OpenPGP is not being adopted here.

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.

Re:PGP is a better model by azaris · 2003-09-01 05:28 · Score: 2, Insightful

I don't understand why OpenPGP is not being adopted here.
Why? Because McAfee killed PGP. Something the US DOJ never managed to do.
PGP was a nice idea when it came but then S/MIME became the proposed standard, Microsoft adopted it and McAfee killed the commercial PGP implementation which meant that everybody went to using S/MIME with Outlook. Well not everybody obviously but enough people to make commercial PGP use unviable.
Bunch of *ix hobbyists sending PGP signed mails to each other was not enough to create an Internet-wide standard. Now we're forever stuck with VeriThawte and their greedy two-bit certification schemes that get pasted on just about every new Internet security proposal.

Re:Technical solution to a social problem by Gunzour · 2003-09-01 01:18 · Score: 3, Insightful

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.

There are also other alternatives alternative? by cluge · 2003-09-01 01:23 · Score: 3, Interesting

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 certificates are for servers, not individuals by Gunzour · 2003-09-01 01:36 · Score: 4, Insightful

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.

Certs for all by Directrix1 · 2003-09-01 02:25 · Score: 2, Interesting

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

Re:The certificates are for servers, not individua by warpSpeed · 2003-09-01 02:32 · Score: 4, Insightful

Therefore, your ISP would have a cert to say "yes I really am someisp.com" when sending your mail.

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*...

Re:InstantSSL by geirt · 2003-09-01 02:44 · Score: 3, Funny

muirhead wrote:
I agree!
www.instantssl.com/ is he only Certification Authority providing low-cost, fully-validated and warrantied SSL Certificates.

Try this:

https://www.instantssl.com/

They can't even get the certs right for their own site ...

--

RFC1925

DRIP is a better option, IMHO by bobcat · 2003-09-01 02:54 · Score: 2, Interesting

https://www1.ietf.org/mail-archive/working-groups/ asrg/current/msg05876.html

--
-- Ziggy Sig Sig

Re:DRIP is a better option, IMHO by hey · 2003-09-01 03:58 · Score: 2, Insightful

Thanks for the pointer. DRIP (Designated Relays Inquiry Protocol) sounds pretty good.
Abstract The Designated Relays Inquiry Protocol, DRIP, is a method for domain name owners to specify the IP addresses that are authorized to relay mail as a domain name. The protocol provides a method for server MTAs to reject SMTP connections from IP addresses not authorized to use a domain name.
I like this because it remains decentralized and is optional.

Re:It helps against faked "from" by valdis · 2003-09-01 02:57 · Score: 3, Insightful

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....

ISP's and Abuse by infra-red · 2003-09-01 02:58 · Score: 2, Informative

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.

Breakdowns by Todd+Knarr · 2003-09-01 03:10 · Score: 3, Insightful

The obvious one: if we can't trust spammers not to forge sender addresses and such in SMTP, why should we suddenly trust them to supply correct policy codes in AMTP?
What do you do about individuals getting certificates? There's an increasing number of people who run their own MTA as part of a client setup, bypassing their ISP's mail servers to deliver personal mail directly to the recipient's mail system. This produces the need for an efficient, cheap way of handling a large number of certificates.
Who do you trust to give out the certificates? You have to trust the CAs to never provide havens to spammers by giving them certificates on demand with slightly different names, for example. Is there any authority we can trust to do this?
In section 4.1 of the RFC, what do you do about mail servers that legitimately have more than one name but only one PTR record? Basically, mail servers that server more than one domain. It'd be reasonable for them to announce themselves as being the domain of the mail they're currently sending, but that would cause the certificate security check to fail. You'd have to require that the server uses only it's primary name in the EHLO line, which may be a problem in some cases.

Re:Why a central cert? by maynard · 2003-09-01 03:24 · Score: 2, Interesting

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

It's possible to get a signed certificate for free by krico · 2003-09-01 04:48 · Score: 2, Informative

Thawte offers free e-mail certificates.

- Can't those be used?
- Isn't that a good enough price?

Rule #1 by taustin · 2003-09-01 06:44 · Score: 2, Insightful

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.

For everyone wanting mandatory digital sigs by scrytch · 2003-09-01 06:52 · Score: 3, Interesting

... 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.

price certificates high, not low by firewood · 2003-09-01 07:24 · Score: 2, Insightful

Sounds like a solid plan...now to get a certificate signed for a decent price is the challenge."

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.

My own idea for authentication by Shdwdrgn · 2003-09-01 09:11 · Score: 4, Insightful

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.

Slashdot Mirror

AMTP as an Alternative to SMTP

83 of 328 comments (clear)