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

Comments

Yes, but

[Anthem.uxp]

does it involve the Evil Bit ?

Re:Yes, but

[Eunuchswear]

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

Re:Yes, but

[Directrix1]

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.

Re:Yes, but

[Brushfireb]

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.

Re:Yes, but

[Directrix1]

OK, look the first statement I guess was a bit too simplified. You don't immediately block the ISP. First, you email the ISP about the infringing emails and give them a notice of compliance. The ISP, since all email traffic is authenticated, can just block the account. But if the ISP does not block the account then the other amtp server blocks that ISP after a certain number of violations in a certain time period. Also, since everything is authenticated then it should be the destination ISPs right to obtain the user-info and sue him (make it economically infeasible to spam). Or sue the ISP if he does not provide the details of the user (make it economically infeasible to be an accomplice to a spammer). It works out, and it essentially equals drastic reduction of spam.

Re:Yes, but

[shigelojoe]

Forgive me if I'm mistaken, but wasn't SPEWS supposed to work that way?

Re:Yes, but

[Directrix1]

Isn't SPEWS just a blacklisting service? This is an end-to-end authenticating mail protocol. This essentially just allows for the exclusion of anonymous access, which is how you can get at spammers.

Its a good idea

[blaster]

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

[Ed Avis]

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.

Re:Its a good idea

[AftanGustur]

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.

Re:Its a good idea

[geek2003]

So will it really reduce spam?

Re:Its a good idea

[dnoyeb]

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

[Ed Avis]

In the short term the ISPs need to keep spam off their network. In the longer term, once nobody seems spam any more (because their ISP or mail client has filtered it out, based on trusted senders or micropayments or hash cash or whatever), spammers will no longer make money and will stop spamming.

Actually, I'd reckon that ISPs will move to a model where large users pay by the bit (many already do), so spam is not really their problem: it's the spamming ISP that foots the bill.

Re:Its a good idea

[Omnifarious]

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.

Re:Its a good idea

[Eunuchswear]

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;?

Re:Its a good idea

[arivanov]

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

Re:Its a good idea

[Anonymous Coward]

by blaster (24183)

That bug has mutated to... Talk!?

Re:Its a good idea

[schon]

It cetainly isn't appropriate for every email messge.

And it _still_ won't do anything to stop (or even slow) SPAM. All it will do is force them to pay a little bit more in order to do so.

Re:Its a good idea

[Zeinfeld]

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.

Re:Its a good idea

[Omnifarious]

You're right, it also does absolutely nothing to stop spam. *sigh*

Re:Its a good idea

[Adrius]

since once the issuer has issued the certificate, he doesn't have to protect any part of it himself

Uh, reality check. The issuer has to diligently protect its private key(s), and the keys that he receives from clients during transactions. Both from hacking into machines that store it, and from people cracking it on their own time. Public key isn't always as secure as most people believe.

And this doesn't even address people's ability to impersonate others while signing up for that cert. Or having a good process in place to revoke certificates when machines are compromised. Or making sure that certificates can't be revoked by third parties posing as the client. Or...

Honestly, putting this in government hands sounds a lot like advocating national ID numbers. It looks good on the surface, but the modes of failure could be catastrophic.

Re:Its a good idea

[Gleef]

Who needs central signing for this? Only the mail backbone? The whole "SSL implies central signatures implies supporting the Verisign behemoth" is for servers who have no idea who will be connecting to them, like webservers or DNSSEC servers. They need a signature by one of the root CA certificates that are supported by a wide range of browsers (or DNS servers). This problem doesn't carry over to here.

Any "leaf" nodes, or even branches, have a finite and known group of email servers they communicate with. The certificate has to be signed by someone they trust, but it doesn't have to be trusted by the world. For example, if your AMTP server passes email up to your ISP or down to departmental servers, a certificate signed by your ISP would suffice (and self-signed certs for your departmental servers).

So basically, if you want your AMTP server to be allowed to go to random machines and deliver your mail directly, you need a centrally signed certificate. If you just want to pass your email to the next server up the line, you just need a cert signed by someone they trust, like them.

Re:Its a good idea

[JoeNotCharles]

We don't present id every time we speak to someone in real life because it's not efficient. But this isn't real life - it's a computer, and if it can do it automatically, why not?

Re:Its a good idea

[Abcd1234]

but the modes of failure could be catastrophic.

And how is putting this responsibility in the hands of the private sector any better? It's already been proven that the commercial sector has a great deal of difficulty with security (MS is the obvious example, but look at all the companies who are hacked and their credit card databases stolen?) At least in the hands of the government the process is (hopefully) transparent and auditable (unlike, say, ICANN), not to mention accessible to the common citizen (ie, I could get a cert without having to pay ridiculous fees).

Re:Its a good idea

[timftbf]

You're assuming everyone uses their ISP's smarthost. It's not the case, and it shouldn't have to be the case. Requiring signed certs doesn't affect end-user Windows PCs, it *does* affect everyone running a mail server that knows how to look up an MX record.

Unless you're saying that only ISPs are allowed to run mail servers now?

One of the wonders of the Internet as it stands is that I can pay my ISP (or another third party) to do pretty much everything for me, or I can pay for unfiltered IP connectivity and run everything else myself. Or indeed, anywhere in between.

Every step we take that *requires* centralization, registration, additional fees or anything else that's trivial for a mega-corp but burdensome for an individual is another step towards turning the Internet into a clone of TV. Dumb, paying consumers at the edges, a few fat-cat suppliers of everything in the middle :(

Regards,
Tim.

Re:Its a good idea

[MSZ]

It's not really a good idea. And it's not significantly better than SMTP - it's worse!

First fault is quite obvious - spammers can obtain new certificates. They have money to pay... even if these certificates are blacklisted within hours, they will pump out a lot of their shit before that.

Second one is less visible but even worse. Anyone on dynamic IP is expressly denied possibility of sending mail via AMTP. Do you think ISPs will bother with special configurations, certificates for dynamic addresses, etc? No, they will force everyone to use some shitty webmail (a calamity in itself).

Third, classification is useless. How do you differentiate net/ngo/com/pol/whatever classes? Most of the TLDs are free for any use, so you can't use sender address, and declaration in incoming email is just a declaration, not necessarily truthful.

Someone with more free time can probably find a few other issues.

So we're offered bad and complex protocol instead of bad and simple protocol. Way to go?

Re:Its a good idea

[anthonyrcalgary]

I like your idea because it won't break anything. Any of the gateways involved can be old versions without causing problems, and the client side can benefit without server support.

Something that might cause problems might be overzealous blocking of non certed gateways, but at least there's a way out now. If you want to run a mail server on your cable modem, you can get a cert rather than begging every ISP on the planet to believe you.

Re:Its a good idea

[Anonymous Coward]

In Belgium everybody is getting an electronic identity card which can also be used to sign whatever you like to sign.
So the signing is already done by the government.

Z

Re:Its a good idea

[Adrius]

It's already been proven that the commercial sector has a great deal of difficulty with security

You are claiming government security is better? Unless it is run directly by the NSA, it probably won't be much better in that respect. The dept of Homeland Security is running on M$.

You can get a cert right now without paying a rediculous fee. You can create your own CA right now. Your friends can sign your CA certificate and create a web of trust. As you begin to trust your friends more, you can stop trying to filter their incoming connections for spam, and focus on mail from people outside of your web. If the major ISPs formed a partnership in this way, then mail from their systems would at least be authenticated, and there wouldn't be a single root, owning the responsibility of all email users on the planet.

The only reason you think you have to pay that now is because VeriSign has a monopoly, and they have convinced everyone that the only way to become trusted is to register with them. They should be sued under anti-trust and broken up. We have laws against monopolies in this country you know.

However, by leaving it in commercial hands, there is at least the option of splitting up the task. Putting all that power in one place is extremely dangerous, no matter where it is. Giving the government more power of this right now is just stupid if you ask me. That is, so long as we continue to elect tyrants.

Now, I agree the process behind it should be open. Perhaps government regulation of a number of private entities would be a middle ground? Sorta FDIC-style?

Re:Its a good idea

[artemis67]

A blacklist based on gateways sounds like it's just as limited as current blacklists based on IP ranges. If someone using a BellSouth DSL line does a spam blast, and the BellSouth.net gateway is added to the blacklist, then it represents tens of thousands of people who just got added to the list erroneously.

Re:Its a good idea

[Omnifarious]

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.

Re:Its a good idea

[Anonymous Coward]

One of the wonders of the Internet as it stands is that I can pay my ISP (or another third party) to do pretty much everything for me, or I can pay for unfiltered IP connectivity and run everything else myself. Or indeed, anywhere in between.

And one of the bad things about the Internet is that any criminal scammer can do the same thing. And the costs of spam are so great that most providers no longer want to be in the business of subsidizing someone else's abstract freedoms. Tough shit cowboy - wild west days are over and people are building fences.

This is not a new societal problem -- and the solution has traditionally been to increase the costs and bureaucratic overhead involved for the activity. Modern society requires "centralized registration" to perform haircuts or have your house painted. That's the way it is -- why should running a mailserver be any different?

(And, no, society hasn't stopped bad haircuts or paint jobs. But it has minimized the problem and provided a mechanism to track the culprits.)

Re:Its a good idea

[Anonymous Coward]

I haven't seen a real amount of spam from "mail.isp.net" for years and years. That implies that BellSouth and so on is already doing a good job of policing their relay customers.

Re:Its a good idea

[Anonymous Coward]

Why is central signing needed at all? ... It cetainly isn't appropriate for every email messge.

In a word, transitivity.

There is no a priori way to externally judge the value of a message as it passes over the network. One very dangerous thing to do would be to mark a message as being especially valuable. A much better thing to do would be to authenticate all messages. You get economies of scale, you get reliability on which to build new services, and you provide an always-on mechanism to eliminate abuses such as spam.

Re:Its a good idea

[|>>?]

This is absolute rubbish.

Issuing certificates does not solve the SPAM problem at all. There is no method to detect if the person who is applying for a certificate is an evil spammer or not.

Most evil spammers actually run a business, so they'd qualify to get a certificate for their business.

Getting central signing, or issuing cheap certificates does not solve the spam problem in any way.

Re:Its a good idea

[Abcd1234]

You are claiming government security is better?

Not at all. I'm saying the commercial sector is as insecure, if not more so, without providing any benefit to the consumer.

Now your point about a "web-of-trust" is a reasonable one. However, I should point out that it simply isn't scalable. The reality is that without an organized hierarchy, trying to set up all the trust relationships is simply infeasible... well, assuming that the ISPs, media companies, etc, don't continue to merge. :)

Now, I agree the process behind it should be open. Perhaps government regulation of a number of private entities would be a middle ground? Sorta FDIC-style?

Now, this I could live with. However, I must point out that the government hasn't exactly proven itself when it comes to regulating public entities (this is especially true in the current, shall we say, business-friendly government in office). This is blatantly obvious in the case of ICANN (which is, only now, getting a *little* pressure, and even then, only a little), and don't get me started on privatization of other industries (look how well the privatization of power worked for California). The fact is, the US government seems quite reluctant to regulate private industry (hell, just look at the behaviour of the FTC lately), and until that changes, I'm not sure you can trust private companies with something as vital (and potentially "abusable") as identity verification.

'course, one could ask if you could trust the government in this case. However, I would contend that, with the lack of a profit motive, it's at least more likely that the government could be trusted with this kind of responsibility as compared to the private sector.

Re:Its a good idea

[stonecypher]

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.

In my opinion, this quote is the essential SPAM problem. Most people believe that the ISP should be held responsible for stopping their SPAMming users. In general, they do.

You cannot expect an ISP moral behavior issue to be the solution, though. The capitalist model is in direct competition with expectations of moral behavior. There will always be an ISP which sees SPAMmers as a customer base. Unfortunately, the only answer that could involve ISPs would need to be legal.

I'm not suggesting that this makes AMTP inappropriate. Quite the opposite: it'll make the ISPs' jobs easier, and will moderately reduce SPAM from clueless ISPs (there are many) and from ISPs where SPAMmer customers are more proficient the administrators.

That said, what I am saying is that this is not a solution. This is, rather, a tool. The supposition that ISP good grace is the one final answer seems naive to me. Whereas I don't have a practical better answer, I do think we need to be focussing less on patches for the current system and more on a replacement system that eliminates some of the current problems at their outset.

Re:Its a good idea

[Illbay]

spammers will no longer make money and will stop spamming.

My impression is that it isn't the "spammers" that are making the money, but rather those selling "spamming services" (spamware, upstream/downstream support networks, etc.)

Sort of like "Make millions in real estate wtih no money down"(TM). The only ones who REALLY make the money are those selling the books, tapes and videos.

Re:Its a good idea

[thedillybar]

The endusers CAN define their own rules. Anything ALLOWED by the MTA will be passed to the enduser with the "message type" left intact. If you don't want to see optin/optout mail, you simply add a filter to your mail client to move it to the trash (or bounce, or whatever). This means 2 or 3 filters to eliminate "spam", not hundreds of filters & algorithms currently employed by anti-spam software techniques.

Re:Its a good idea

[Zeinfeld]

That said, what I am saying is that this is not a solution. This is, rather, a tool. The supposition that ISP good grace is the one final answer seems naive to me.

What is needed is a way to hold ISPs accountable. I don't accept the Nadarite 'corporations baaad' ideology you are spouting but the problem is one of accountability.

That is why the answer has to be at the message level and not the transport layer. We need non-repudiation. We need a means of holding the ISPs accountable.

Re:Its a good idea

[Omnifarious]

Oh, I think signing each and every message is an excellent idea. I think X.509 and PKI with their central certificate authorities are awful ideas. They aren't one and the same even though many people seem to think they are.

Re:Its a good idea

[rew]

If you think that the mailserver should get out of the way, ask your provider (or make your mailserver) to accept all types of mail. But now you have a header on the Email written by a "trusted" mailserver that says what type of Email it is.

You get better tools to complain. I got virusses claiming to be from Alan Cox and other wellknown people. This means that someone's mailserver allowed forging of that address. This worm would have allowed me to figure out the policies of hundreds of remote mailservers.

Re:Its a good idea

[Gleef]

timffbf wrote:

You're assuming everyone uses their ISP's smarthost.

No, I'm not. I gave an ISP as an example, since that's the most common case. You can just as well use an alternative service provider, or even set up your own little networks of AMTP servers where you sign each other's certs.

I work for a small not for profit organization. We issue several certificates a month for our own little private network of clients and friends. There's nothing to stop you from doing it too.

If you want your little cluster to have contact with the rest of the world, one of you will need a certificate that's signed by someone outside the cluster. But that's only one of you, and it still could just be another cluster's signature.

Every step we take that *requires* centralization, registration, additional fees or anything else that's trivial for a mega-corp but burdensome for an individual is another step towards turning the Internet into a clone of TV. Dumb, paying consumers at the edges, a few fat-cat suppliers of everything in the middle :(

And that's what I like about AMTP. It implies centralization and registration, so the megacorps and fatcats will support it, but it doesn't actually require this centralization and registration. In fact, it really encourages postmasters to sit down and think about who they trust really, and to set up relationships based on that.

Re:Its a good idea

[bweinman]

1. Security does not go any further then the TLS extension to ESMTP. If you force TLS in ESMTP you get the same result.

The TLS extension to ESMTP does not require authentication by a trusted third party. AMTP's authentication requirement is intended to authenticate servers in order to provide a path of recourse in the event a server should abuse the system. Such recourse demands authentication.

2. There is a plethora of "codes" for SPAM which will be abused the same as now and will require regulation.

Yes, the system will be abused. The difference is that with authenticated servers you will be able to stop the abuse.

3. It suffers from the same problem of SMTP as it is hop per hop, not end-to-end.

This was a design choice. I have chosen to change as little as is necesarry in order to make implementation as trivial as possible. If you have suggestions as to how that can be improved, I welcome your feedback.

4. It breaks country laws in many countries which are still being anal-retentive on encryption.

This is something that will need close consideration. I belive that server authentication is vital to solving the problem. I am not aware of countries where TLS is illegal, but that doesn't mean there aren't any. If TLS violates laws in some countries, then I am open to suggestions for avoiding that problem.

Instead of this horrid garbage all that is needed is the following simple fix/extension to SMTP:

Your implication that my solition is "horrid garbage" and that the problem of stopping UBE, which has baffled great minds for years, is trivially solved by a "simple fix/extension to SMTP", is duly noted.

1. Messages should be signed by every gateway on the way with the sertificate of the gateway.

A cryptographic signature does not solve your own problem #4 (above).

It also does not solve the problem of a lack of uniform definitions of "spam".

2. Gateways should no longer modify any headers prior to the ones they add (some do - see spamassassin for example).

Spamassasin is not a gateway. It's a user-space program that some people use to filter or block mail at both MUA and MTA levels. RFC-2821 (section 3.8.2) already proscribes modification of previous gateways' "Received" headers.

--Bill (author of AMTP)

Re:Its a good idea

[stonecypher]

I don't accept the Nadarite 'corporations baaad' ideology you are spouting

Read much into what people are saying? I said no such thing. What I said was that the market economy provides niches for companies which behave badly, and that as a result there are always going to be a few greedy fucks ruining it for everyone else.

Accountability hinges on a good definition of spam. As soon as you have one that people don't argue over, you may remount your high horse.

Naderite. Sheesh. Try harder with the slander. I think you missed a spot.

Free Certificate

[CountZero007]

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

Re:Free Certificate

[Komarosu]

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

Re:Free Certificate

[badzilla]

How about these guys in Barcelona for free six-month validity server certs? Or free two-year validity for .edu domains.

Re:Free Certificate

[Anonymous Coward]

Thawte offers a free certificate, and the CA root certificate is already installed pretty much everywhere.

Re:Free Certificate

[dnoyeb]

You have to start somewhere. If you do not support them, how will they be able to get their cert installed by default. You know MS and Sun and perhaps netscape likely don't allow root installs for free.

My biggest problem with this system is it does not have a trust model that I can see. I like PGP a lot better, where the trust can be increased. but if you didnt sign it, you cant really know anyway.

Re:Free Certificate

[Anonymous Coward]

The CACert root certificate may be going into mozilla quite soon. There is even a bugzilla entry for it, but ive lost the link.

Re:Free Certificate

[Anonymous Coward]

Which means that asshole companies like netsol are going to be rubbing their hands together with glee

Re:Free Certificate

[Anonymous Coward]

Passports aren't free :)

Re:Free Certificate

[Shadowspawn]

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.

Re:Free Certificate

[Anonymous Coward]

I've never actually gotten them to respond to a request, though. It's like nobody's home.

Re:Free Certificate

[Anonymous Coward]

Yes, and then they spam you, signing with their own CA to ensure your system accepts the messages. This is completely counterproductive.

Re:Free Certificate

[nomad42]

search no longer: http://www.SwissSign.com/ section "MySwissSign", open new profile ("john_a.doe") and order any number of "Bronze" type certificates.

Why should we pay CA?

[oolon]

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?

[Anonymous Coward]

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?

[Eric Savage]

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

Re:Why should we pay CA?

[packethead]

You write of CA like it's a single entity. Verisign is an example of a Certificates Authority. There are others. That said, I like your idea..

Re:Why should we pay CA?

[oolon]

Yes I do, Certificates to me do seem a bit like Snake oil damn expensive for what they are. Email is one of the big reasons why you might want a domain name, the certificate for the domain name would cost more than the name for a year! I just think it should be supplied as part of the domain name, perhaps you could lodge a certificate (home generated) with the registry for your domain. That way if your mail server gets comprimised, you can replace the certificate straight away. Yes spammers could also register certificates, but that is not a problem, because the certifciate system is just to work out exactly what domain sent the mail. The spammer would be locked out by domain name not certificate so it don't matter if they do change it.

James

Re:Why should we pay CA?

[mabinogi]

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.

Re:Why should we pay CA?

[hattig]

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?

[Steven Reddie]

Why should I pay for software to run on my domain too? The reason being is that these things are coming from different vendors. 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. They can check your drivers license, or social security number, or use even tougher measures for determining if you really are who you say you are. A certificate's values comes from who signs it, not who it is issued to. It turns out that most of us are willing to trust a massive accountable multinational company to vouch for other people than we would a small domain reseller.

Re:Why should we pay CA?

[Zocalo]

only that a CA accepted money to vouch for your identity

Ah, but that's the point. Suppose I'm a spammer that spent a few dollars on the domain "foo.com" and I pay some more dollars to get a cert from CA #1 and spam away. This obviously gets noticed, and CA #1 revokes my certificate and blacklists the domain. So I go to CA #2 and pay some more money - same thing; cert revoked and domain blacklisted. However, dodgy CA #3 is prepared to take a few extra dollars for a guarantee to not revoke my cert. So I pony up the cash and keep spamming. Fairly obviously, people complain to CA #3. Repeatedly. Eventually they get fed up and stop trusting CA #3 altogether.

So, the key points are twofold. Firstly the spammer has to keep paying out money to stay in business, either on new domains or new certs. Probably the former since domains are cheap, but that rather hinders the prospect of repeat customers if they can't find you. Secondly it's not worth a CA going rogue, because if they lose the trust of the community and get blacklisted, then the value of their certificates plummets and they suffer financially.

Ultimately, it's making it more expensive to spam. At some point the cost of spamming must become more expensive then the dividend from those who fork over cash to you, and at that magical point spam dies on the vine. Well, in theory at least, since what's going to happen first is that the smaller players go out of business, improving the chances of the majors to get a sale.

We've got a long way to go yet...

Re:Why should we pay CA?

[tomstdenis]

"Anyone could create their own certificates, but without a mutual trusted third party signing it, how do I know it's real?"

What is real anyways? Just bcause I paid 200$ for an RSA key I can make in 200 milliseconds on my PC doesn't mean I'm not a criminal or spammer.

CA's and PKI in general [well as the corporate world sees it] is a huge fucking scam. Just because some random signing-whore [which is what a CA is really] signed your key doesn't mean you can trust it. The CA will sign *any* key for a price.

web-of-trust ho!

Tom

Re:Why should we pay CA?

[MarkSwanson]

I've always thought that DNS should be enhanced to provide the CA for the domain. This would let people be their own CA, and the CA install process would be automated. Also, a CA should only EVER be an authority for a specific domain.

Re:Why should we pay CA?

[shokk]

This involves:

a) trusted CAs to take care of certificate revokations on individuals in a timely fashion, and

b) teaching people to revoke CA certificates in a timely fashion and learning about that in the first place.

I think "a" is more likely to happen than "b" in the near future. Trusting "b" might be better left to the ISP. If there is a way for the ISPs to filter mail based on cert content, then this can work well. Do we know whether "a" is true?

I think bigger spammers are more likely to be legislated away once the smaller once have faded due to technical/economic combinations. Because of their size, their operations are less likely to be mobile, easier to find, easier to audit, and thus stop.

Re:Why should we pay CA?

[eer]

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

[letxa2000]

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.

Re:Why should we pay CA?

[Trepalium]

You misunderstand the role that CAs play. They don't verify that they owner of the certificate is reputable. They only exist to verify that the owner is who he or she said they were. If there were no falsities on the application for the certificate, it's unlikely they'd get their cert revoked. What this move would likely do, however, is create spam middlemen, who's only role is a clearinghouse for spam. It'll raise the bar for the cost of sending spam slightly, and raise the bar for owning your own personal e-mail domain to the point of being unattainable by normal individuals.

Re:Why should we pay CA?

[pixelfreak]

Because someone who presents fraudulent credentials to a CA is committing fraud, which last time I checked is clearly illegal. Using misleading message headers is a unethical, but not illegal.

Re:Why should we pay CA?

[Zocalo]

In the sense of HTTPS, yes, the CA is essentially saying "We confirm that this entity is who they claim to be". However, in this case, the role of the certificate is slightly different; it's to vouch for the fact that the sender is not sending spam. In effect the CA is now saying (or will be required to say) "We confirm that this entity is not a spammer". In both cases it's "to the best of our knowledge of course".

At least that's the way I understood it. There certainly has to be a mechanism for certificates to be declared invalid, or the whole concept falls apart. Either way, anything that increases the cost to spam is a good thing in the fight to reduce it.

Re:Why should we pay CA?

[Anonymous Coward]

However, in this case, the role of the certificate is slightly different; it's to vouch for the fact that the sender is not sending spam.

The CA won't be performing that function. The only time they would revoke a cert is if the information on it is fraudulent.

Instead, some other bodies will need to maintain "blacklists" of spammer certificates, much like they do now with IP blocks.

However, unlike IP blocks, certificates are significantly harder to get and change. There's also very little "collateral damage" involved certificate blocking. No more blocking an entire ISP because of a couple spammers somewhere -- It makes "pink contracts" pretty much worthless.

Re:Why should we pay CA?

[Anonymous Coward]

CAs whose certificates are trusted be default are essentially vouching for the identity of the certificate holder. To ensure that this is the case, CAs need to verify the holder's identity. This has costs associated with it. Any CA offering free certificates probably doesn't do the background check, so there's no point having them as a trusted CA.

Re:Why should we pay CA?

[T-Ranger]

Because domains dont mean anything.

Just for fun, do a whois freewebemail.com. Compare that to the output of whois designerlove.com...

The listed registrar of freewebemail is compleatly bogus. The address and phone number are invalid.

The whole point of certficates is that someone does analysis on who is buying them. The CA dosent care who you are, only that you are who you say you are. Domain registrars on the other hand, dont give a flying fuck who you say you are, as long as your CC goes through.

Re:Why should we pay CA?

[Ben Hutchings]

Suppose I'm a spammer that spent a few dollars on the domain "foo.com" and I pay some more dollars to get a cert from CA #1 and spam away. This obviously gets noticed, and CA #1 revokes my certificate and blacklists the domain.

No they don't; you still own foo.com. Instead, your domain gets blacklisted by third parties.

Re:Why should we pay CA?

[mabinogi]

Actually, the Australian government had a plan for a PKI system where the government would act as a CA (or maybe they'd designate one or more CAs, can't quite remember), and for you to obtain a certificate from them, you would have to provide the standard 100pts of identity that you need here to get things like drivers licenses and passports.
The idea was that it could be used as a true digital signature when using government (and other) services.
It doesn't look like it ever caught on though.

I think the scheme was called "Gatekeeper"

Re:Why should we pay CA?

[Trepalium]

Here's another way of thinking about it. A CA will never revoke a certificate because of spam because of the liability it would cause. Can you imagine the lawsuit if a major corporation was prohibited with communicating with the rest of the world because of a fraudulent claim, or even a legitimate one. No, instead we're going to have a system nearly identical to the one today, with independant parties maintaining blacklists who are vulnerable to DDoS attacks.

I still don't believe that this would ever stop spam. It might slow it down for a few months, but getting it implemented would take years, so the gains would be worthless. All that would happen in this kind of set up would be middle men would appear, and buy dozens of domains and certificates to go with them. On the upside, this would likely create new jobs. But, I'm betting that spam companies could easily amortise the cost of 10-20 certificates over the process of a year, with even modest fees for spammers. And if you thought spam was bad now, just imagine how bad it'd be if it were legitimitized by an entire industry.

No, I think this is a very bad proposal and will do far more damage than good.

but...does it work?

[njet]

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?

[Anonymous Coward]

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?

[geirt]

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

Re:but...does it work?

[xenophrak]

All of which can already be done with Milter.

See http://www.milter.org

I am currently working on a project to do what AMTP wants to do. TLS + Milter is about as effective as you can get today for policy enforcement. AMTP has the possible benefit of having faster code (if written in C) but then again, you could code your milter in C as well.

I'm more waiting for SASL and reverse MX's to take off. That will be just as good IMHO as root CA chain singing.

Hrrrumph.

Re:but...does it work?

[bourne]

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.

Re:but...does it work?

[Anonymous Coward]

I read the RFC and to my eyes it looks no better than the current SMTP based infrastructure.

Imposing TSL with root signed certs will only allow you to know who the server connecting to you is operated by and nothing more - we already have that in that I can determine who operates a server from it's IP.

Beyond that the proposed system is just as weak to the problem of relays that are not open but lax in their policies.

Those who claim that this system will allow you to determine who they are and block them are simply re-implementing RBLs.

And anyone who really believes that spammers will honour a classification system that will see their messages dropped easily should be contacting me with regard to this bridge I have to sell - it's a lovely bridge known locally as Tower Bridge.

Should we change HTTP as well?

[acegik]

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.

Re:Should we change HTTP as well?

[Anonymous Coward]

There are also down sides to http/ftp should we change them as well? The answer is no.

what kind of argument is that?

Re:Should we change HTTP as well?

[Rhinobird]

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.

Re:Should we change HTTP as well?

[ColdGrits]

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

Re:Should we change HTTP as well?

[Anonymous Coward]

And actually, Gopher IS superior to FTP. It was designed to be a replacement to FTP. Pity no one uses it.

Re:Should we change HTTP as well?

[Gunzour]

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?

[weileong]

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

Actually, should we also move off to a different "naming scheme" as well?

The protocol allows you to build a "trusted/known", signed network, but what do you do about the untrusted parts of the net?

If we're going to have parallel mail systems, having one kind gateway into the other will defeat the purpose of spam prevention (all this does is it funnels SMTP-traffic onto AMTP-accepting machines which also accept SMTP, no?). Spam problem not solved, and it also does nothing to mark off a date whereby we can kill the old SMTP setup. On the receiving end it also does not help except as a kind of inbox-filtering tool where you know which incoming mails came via AMTP and are signed, and which are not - but then you still have to go through the "possible junk mail" folder to try to discover people still sending from SMTP machines.

You could have people who cannot send mail to a@b.c because they're on an SMTP machine and the recipient is "AMTP only", but then to the end-user there's no clear difference because his email address also looks the same (d@e.f).

But joe-on-the-street is helped to understand "Instant Messaging" != "email" by the fact that, e.g., IM uses nicks/UINs and not "a@b.c".

Choosing a new symbol to replace "@" is goign to be tough, though.

Re:Should we change HTTP as well?

[shokk]

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.

Re:Should we change HTTP as well?

[Anonymous Coward]

> I begin to wonder who would have an interest in bringing down an infrastructure like email.

The Internet email infrastructure is not in danger of collapsing. Plenty of bandwidth to handle all current and future traffic.

What's greatly endangered is the usefulness of the Internet email infrastructure to anyone except mass-mailing spammers, who frantically send out mailbombs like male garter snakes glom onto a newly-arrived female. Sure, the infrastruture can handle it, and deliver all those hundreds of spams to everyone in the world - but who want to use such a setup?

Only the self-deluded spammer community really believes they offer ANY kind of value, and the more honest-minded among them realize it's all about making money and has nothing to do with trying to help their targ^h^h^h^hcustomers.

What will stop the spammers

[Billly Gates]

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.

Re:What will stop the spammers

[StrawberryFrog]

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.

Re:What will stop the spammers

[Eric Savage]

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

Re:What will stop the spammers

[Anonymous Coward]

Read the draft. The protocol authenticates *servers*, not individual messages, and the communication between servers is encrypted (by RFC2246), so there no plain-text certificates going around the net.

Re:What will stop the spammers

[jeremyp]

TLS encrypts the connection, not individual messages. The idea is to authenticate the client mail server, not the sender of the e-mail.

I don't know the exact technicalities of TLS, but I imagine it would work something like this

The client presents the server with a certificate which contains a) its DNS name, b) a public key, c) the name of a certificate authority, d) an electronic signature from the authority.

The server checks the cert to see if the name does match the DNS name of the client and that the CA is one that the server trusts and that the signature is genuine.

An electronic signature is a secure hash of the data to be signed encrypted with a private key. The signature can only be decrypted with the public key.

So now the server knows that the client has presented a valid certificate. Of course the client might have "borrowed" that certificate from the genuine owner, but if so the client will not be in possession of the corresponding private key and so will not be able to sign anything with the cert or decrypt anything that has been encrypted with the cert's public key. That gives two ways that the server can verify the client is the genuine owner of the certificate, either a) ask the client to sign something or b) encrypt something for the client to decrypt.

Anyway, with TLS once the certificate exchange has taken place, a symmetric encryption technique is negotiated and the rest of the connection is encrypted using the symmetric method. One or more e-mails is then transmitted across the encrypted link.

Note that all of the above is already available with SMTP. The only thing is that under the SMTP RFC mail servers are not allowed to reject messages across non-TLS connections if they are destined for the domain for which the server is a public mail exchanger i.e. the domain's MX record points at that server.

Re:What will stop the spammers

[Richard_at_work]

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.

Re:What will stop the spammers

[AmunRa]

Good god, when will people actually post about things they have a clue about? or even better, actually read the spec! OK, let's go through your points...

1. These are the same certificates that HTTPS uses, so I don't get your concept og 'overwritten', but basically every SMTP (or AMTP now) server has to have a cert. If a spammer puts 'personal' instead of 'commercial', then as soon as you find out that spammer is lying about the type of mail, you ban them - the use of certs allows this

2. You can't steal someone's cert - go a read a book about public/private key cryptography to find out why.

3. all they big spammers use their own servers - and take advantage of open relays / other servers that accept anything - if everyone is forced to use AMTP, then this is made a hell of a lot harder.

Re:What will stop the spammers

[diatonic]

Perhaps corresponcance marked as 'personal' could be limited to 250 emails a day (high enough not to be a problem, low enough to prevent abuse)... any email sent in addition to that could refuse to be routed, based on the certificate being suspicious, and notify the user that it failed... try again tomorrow.

It may be tough though to keep track of how many emails are being sent per certificate, unless the CA could somehow do it.

.:diatonic:.

Re:What will stop the spammers

[Anonymous Coward]

> 2. You can't steal someone's cert - go a read a book about public/private key cryptography to find out why.

Of course they can steal someone's cert (and whatever other data is needed to make use of it) - go read about remote root/administrator exploits to find out why.

Re:What will stop the spammers

[StrawberryFrog]

I realised after posting that comment that it's not such a big deal. Most spam is deceptive or fraudulent somewhere in the chain of its creation, such as the from header, already.

However the AMTP protocol seems, at a brief inspection have the principle that you have to say who you are and what you are doing. You can be called to account for it. Transgressions can be traced back to thier originator.

Spammers would be driven further into illegality. The rest is really a social problem, not a technological one. For this protocol to work it would need action taken against those who break the code. AMTP would make them easy to find - that is definitely a good thing, all that's up for debate is if AMTP goes far enough.

Re:What will stop the spammers

[Anonymous Coward]

For example could a spammer get the key out of IBM and pretend the message came from IBM?

That would be extremely embarassing for IBM, considering they specialize in hardware solutions to protect private keys. There are two keys, one public and one private. The public key is only good for decryption, and the private key (which, in theory, never needs to cross the network) is only good for encryption-- the private key can't be derived from the public key. Yes, the private key could theoretically get hijacked, but it isn't very easy. This is what makes digital signatures so dang difficult to forge and requires a more sophisticated criminal than most current spammers.

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.

Different certification schemes require different levels of identification, but part of the reason for charging money to receive certificates is to make it very expensive to do what you suggest. Also, if a sufficient level of identification is required in order to receive a certificate, spammers will be forced to break identification laws (such as forging drivers licenses, fingerprints, retina scans, etc.) in order to get around the identification policy.

While strong identification policies won't stop criminals, they WILL require spammers to break laws that are more often prosecuted and which receive stiffer penalties. Would you rather hope a porkbarrel bureaucrat will slap a spammer with a measely fine that will hardly cover court costs, or sic an existing FBI task force on them to lock them in the clink and throw away the key? The likelihood of getting caught will go up dramatically, which should theoretically cause spam scum to find some other way to harass poor unsuspecting internet enthusiasts.

"What kind of mail is being sent"

[Anonymous Coward]

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.

Re:"What kind of mail is being sent"

[Eunuchswear]

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

So, I get a com/optout message marked as per/individualy. I complain to the sender. If this continues I ask the senders CA to revoke the certificate. If they refuse I stop trusting that CA.

The Usenet death penalty applied to mail.

Re:"What kind of mail is being sent"

[Anonymous Coward]

That's not the point. Having a type identifier in every mail means the user gets to choose between opt-in and opt-out.

Re:"What kind of mail is being sent"

[FireBreathingDog]

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

Cool! How much?

No protection against viruses

[Anonymous Coward]

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.

Re:No protection against viruses

[rew]

I'm not sure what the last worm did, but either it did the SMTP itself, in which case that would be forbidden by AMTP: your computer doesn't have a certificate for your dynamically assigned IP.

Or it just connected to your configured SMTP server, where your ISP can determine: There is no way that this guy could be typing so fast.... and take appropriate measures.

Roger.

Security concerns

[fr0z]

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.

Re:Security concerns

[Anonymous Coward]

DMCA perhaps?

Re:Security concerns

[Steve Cox]

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

Re:Security concerns

[Eunuchswear]

So it would be interesting if implemented with legislation rather than without;

Why are slashdot readers such a bunch of statist pansies?

No, you don't need the law. If a MTA sends mis-identified mail then you complain. If it doesn't fix the problem you complain to the CA. If the CA doesn't revoke the certificate you blacklist the certificate, or even the whole CA if you're bloody minded.

The point is that the certificates cost money, so the spammer has to spend to send. A certificate blacklist would be a lot cleaner than the current IP address blacklists.

Also a CA blacklist would be a WMD!

Re:Security concerns

[Spoing]

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

They won't, but maybe the spammers clients will be. At some point all commercial spam involves money exchanging hands...and to do that, there has to be a hand to recieve it.

The users of the spam services -- sometimes the spammer themselves but not always -- should be the primary targets of any law enforcement (let alone any personal/private efforts). The spammer should be second in line, and primarily target to locate all the spammer's clients.

Analogy: A company asking for a spammer to spam is like someone asking a thug to kill. Both the thug and the person asking the thug to murder are murderers, even if one of them don't actually pull the trigger. The thug is still scumm, though without the request to murder would probably find something else less dammaging to do.

Finally!

[fuzzix]

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

Certificates

[h0tblack]

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

[tomstdenis]

pay per message is good provided the price isn't $$$. Why should only rich people be allowed to talk?

Besides if you pay monthly bills for your cell [as I do] you shouldn't/wouldn't appreciate even more bills for actually using your cell [I don't].

Something like hashcash [or the memory-bound approach shown at CRYPTO'03] would work wonders if people in authority [e.g. authors of kmail, moz, ....] implemented it.

Tom

Re:Certificates

[linuxtelephony]

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.

Re:Certificates

[ImpTech]

That sounds to me like the ISP could sign its own certificates so that its users could communicate with its AMTP server, but the ISP itself would still have to have a certificate that was universally recognized (i.e. not self signed), or nobody would accept mail from that ISP or any of its users. Likewise, I can run my own SMTP server right now at no particular cost to me, and it will cooperate nicely with virtually all other SMTP servers out there just so long as I don't get blacklisted or something. With AMTP I would have to get a certificate from a CA, or else AOL, for example, would not trust my server and would drop any mail I sent to someuser@aol.com. I could sign my own certificate, sure, but I see no evidence that other AMTP servers would necessarily accept that as valid. In fact if they did, the whole system would be pointless, and we might as well continue using SMTP.

how about charging for mail?

[zarniwhoop]

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?

[Anonymous Coward]

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.

If the spammers are willing to write viruses to create open relays to send the spam on, steal bandwidth, ignore court orders to stop spamming, what makes you think they won't steal the money to send the spam?

Re:how about charging for mail?

[eric76]

Spammers would just duplicate the tokens. You'd have a hundred thousand people claiming payment for the same token.

There would be ways to prevent or reduce that practice such as the token itself being a digital signature for the message, but that would be really miserable to do. You'd have to send your e-mail to a bank who would deduct the charge from your account, add the token to the e-mail, and then transmit the e-mail.

It would be a nightmare.

But if someone calls me on the telephone and gives me their credit card number, I'll accept any legal e-mail they send me at a rate of $10 each.

Re:how about charging for mail?

[esj at harvee]

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?

[zarniwhoop]

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

Re:how about charging for mail?

[zarniwhoop]

hmmm, very interesting. sorry - no karma to mod you up ;-)

Re:how about charging for mail?

[Anonymous Coward]

Who receives the fee paid ?

If it's the recipient, then I think it could work; ordinary people would usually balence out, and possibly offset some of their internet costs by receiving lots of spam.

If it is the ISP or someone else, no way. It's just a different cost structure for some old ISPs selling the service of sending spam, or, should it be the receiving ISP that get's the money, suddenly a lot more ISPs are in the business of delivering spam to your inbox.

On the otherhand, if I can get a "commercial" ISP account, and distribute rather large amounts of money to many people by sending spam, then it is a new way to launder money, and it will be fought by the government for the same reason they fight every type of non-centrally controlled money.

Re:how about charging for mail?

[hankaholic]

Does it scale up to allow large mailing lists to be run using the same commodity hardware which can currently serve them?

The problem with "sender-pays" schemes is that people often forget that there are legitimate reasons to send out thousands of messages, such as the Linux kernel mailing list.

Re:how about charging for mail?

[esj at harvee]

yes it does scale up. One of the principles is that "strangers cost, friends fly free". A mailing list is a "friend" and therefore, there is no charge to receive mail from the mailing list.

Today, mailing lists are not as easily white listed as I would like. In the future when we start using opportunistic signatures, then mailing list white listing will become extremely easy.

Good start

[orv]

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

[tesmako]

It is a nice technological way to force spammers into illegal activity however. It is hard to outlaw spam, systematic cracking of peoples computers already is illegal however. Since the certificates will be withdrawn within the hour of the machine starting to spew spams it also requires very large-scale cracking. Also it is a bit hard to be anonymous, for one the crack will be revealed very quickly since you are mailing around so much, also you kinda have to give correct contact information in the spam for it to be worth anything :)

Re:Good start

[orv]

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

[Eunuchswear]

True but who's going to actively sue the spammers for their illegal activity?

One doesn't sue for illegal activity, one calls the police. If the police do nothing complain to your nearest politician.

Re:Good start

[orv]

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.

Re:Good start

[Eunuchswear]

a) my local constabulary in Surrey is going to be totally disinterested in the actions of a florida spammer

So someone can come from Florida, chuck a brick through your window and nick your VCR and the police will do nothing?

Sounds reasonable, it's about what they'd do if a guy from Runnymede held you up at knifepoint and asked you to sign over all your propery.

b) so is my local MP. I have enough problems getting him to tackle very local issues.

Maybe the aforsaid knifepoint trick would work? It's been used in the past to some advantage.

Re:Good start

[orv]

+5 Funny.
Well... probably nothing yes. :-)

I think there would be a perceived problem of where the crime was committed (the spam not the brick!).

Hmmm not sure about the knifepoint trick though, tempting though.

Re:Good start

[Eunuchswear]

(the hint in the knifepoint trick is the placename, or, for the rot-13 enabled:
Zntan Pnegn, fvtarq ba gur svryqf bs Ehaalzrqr

Re:Good start

[Czmyt]

The ISPs can implement a limit on the number of messages that each customer can send per day, say 100. I think it's reasonable for this kind of limits on residential customers.

Re:Good start

[valdis]

my local constabulary in Surrey is going to be totally disinterested in the actions of a florida spammer.

"Why didn't you go to the police?"

"Well, I noticed that the bloke carrying the thermonuclear device was the local constable...."

(Apologies to Monty Python and the Pirhana Brothers)

Re:Good start

[Anonymous Coward]

Yes, it is very reasonable, especially if someone can get the account banned during a high traffic time with a false complaint.

Sic'n the spam nazi's on the email account's of the volunteer network of Howard Dean right before the primary election . . . yeah, I could see that being worth a about $10,000 to somebody.

We could make the internet kind of like a country club, where the unwashed masses can peer through the fence but you need to pay more to actually pay. That'll keep out the scum.

Oh wait. That will just make sure that the people with lots of money . . . i.e., people selling things . . . are the only ones who can afford to send lots of email . . .

Re:Good start

[thedillybar]

Whoever is pissed off about the spam is going to notify the "responsible" sender. If this sender isn't actually responsible, then his certificate will be removed from the "responsible" list until he complies. If he wants to sue the spammer to prevent illegal mail so that he can be re-instated as "responsible", then so-be-it.

Re:Good start

[complete loony]

Why don't you start forwarding ALL the virus emails to their email address? otherwise they may never know how annoying it is for you to receive them.

Anyway, AMTP is a good start, here's another:

I think the POP/IMAP protocols should be extended to allow the client (or spam filter program) to flag an email as abuse. The mail server should then send an automated response back to the abuse email address, the entire email should be forwarded to help convince the ISP to deal with the problem (eg DDoS flood of the spammers ISP).

Ideally the abuse email address should have an automated process to block users who get more than X abuse responses per day.

Thus the sender of spam, or compromised relay, of a spam un-friendly ISP should quickly get blacklisted.

If the ISP is spam friendly, they would still get blasted with more abuse email than the spammer sends.

Re:Good start

[bweinman]

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.

That may actually happen. It's human nature.

My goal in writing AMTP was simply to provide a way to protect email. I love email, I've been using it for 20+ years. It's becoming unwieldy for me to wade through hundereds, and sometimes thousands, of UBE messages in my inbox every day. I just want to solve that problem.

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.

Today that is possible, with AMTP it will be far more difficult. Today, a machine can look up an MX record and connect to the associated SMTP server and will (usually) get a message delivered. With AMTP that message won't be accepted unless several conditions are met: 1) a valid certificate from a recognized CA; 2) Reverse DNS that matches the subject of the certificate; and 3) an EHLO argument that matches the reverse DNS. In order to accomplish all of that the virus writer would have to hijack the appropriate DNS server and crack the encryption keys of a recognized CA. Not impossible, but extremely difficult.

Can the virus writer hijack Outlook to send the message on its behalf using the ISP's self-signed cert and bouncing through the ISP's mail server? Sure, but that's a well-contained threat. All the ISP has to do to stop that is to add the hijacked user's cert to their local CRL and it's over.

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.

True, people can and will lie. That is why AMTP includes authentication. It is more difficult to lie when your identity is easily discovered.

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

I belive it, I've had similar experiences. Actually this kind of response is part of the reason for the codification part of AMTP. Most people define spam as "mail that I don't want". Unfortunately, that's not an enforcable criteria. With reliable codification of mail policies we can hope to resolve something.

--Bill (Author of AMTP)

So...

[Anonymous Coward]

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

Re:So...

[Homology]

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

Re:So...

[valdis]

Umm... the IETF isn't trying to do ANYTHING. It's been published as an Internet-Draft. This is the IETF way of getting (possibly half-baked) ideas out for wider review and commentary. As such, there's very little editorial control over what gets out as an I-D. If you don't believe me, google around for these gems:

draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8- 11 .txt

draft-terrell-math-quant-new-para-redefi-bin-mat h- 04.txt

Nice Idea

[Goo.cc]

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

Re:Nice Idea

[pyrotic]

If you read the RFC, the point is that anonymity is still possible as far as usesnames go, the authentication is aimed at servers, not users. So as an ISP you could have a setup allowing anonymous usernames, just not anonymous domain names. It's a compromise, but given the scale of the problem these days, it makes some sense.

Re:Nice Idea

[tomstdenis]

But many people run their own servers over cable modems [because their ISP mail sucks!]

I refuse to pay some signing-whore 200$ or whatever to get a pretty RSA key so I can "legitimately" send email.

Tom

Re:Nice Idea

[Goo.cc]

I do the same thing but I can't e-mail anyone at AOL because of their stupid policies.

Re:Nice Idea

[Anonymous Coward]

You can't email us either if you're running a server off ADSL from comcast, roadrunner, adelpia, verizon, att, frontiernet etc. You probably have no idea the amount of spam which comes off these ISPs. Fortunatly, most real companies aren't so cheap they set up mailservers on ADSL. Please, do youself a favour and get a colo box and stop whining about how everyone is out to get you.

It helps against faked "from"

[leuk_he]

If the from: field does not correspond with the Cert then the MTA will know this and might block the mail . So al least you knwo WHO you get the virus from.

The Sobig-Z variant will use your own e-mail adress if this is in place.

tres clever

[Anonymous Coward]

All spammers will choose code 94RB493-5P4M.
So filtering spam will be extremely easily and the spam problem is finally solved.
Next revolution: making your house secure by attaching a plate "Please don't break in !" to your door.

Re:tres clever

[Anonymous Coward]

Well, writing "Please do not make illegal copies of this CD" works juuuuuust fine for some people ............

Re:InstantSSL

[muirhead]

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

Linky, linky!

[StupidKatz]

You forgot to include a decent reference.

Besides, don't you want to hear some poor sod's server scream out its last dying breath early on a Monday morning? Ahh... better than fresh coffee.

ISP's wont buy it

[ExEleven]

Unfortunatly the ISP's of today wont buy it, if 60% of email is spam then lots of ISP's will be making money giving spammers service obviously.

So anything that had potential of stopping Spam or just Making Money in general wont be brought by todays ISP venture companys. Well certianly the larger ones.

MPCs...

[someme2]

I don't think MPCs seem to be a good idea. They are

arbitrarily selected and

impossible to enforce.

Case in point: "pol The email message was sent on behalf a politician in public office"

Having said that, I suggest the following MPCs: mil, sex, drugs, rocknroll, ???, profit.

Open to abuse

[Twylite]

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

Re:Open to abuse

[Anonymous Coward]

Certificate "revocation" is not needed. If you dont like the spam coming from a certain MTA, just stop accepting it.

As far as demands on end users, I would think this would be handled more as an "account type" classification. If you are an "average internet user" you would only be allowed to send per/individual mail. If you are running a biz then you should be able to deal with classifing the email.

I do like the idea of just sending a "you have a message waiting at X server" that you pull from. The sender should bear the cost.

Re:Open to abuse

[fyonn]

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

[Twylite]

The system relies on being able to identify which nodes aren't playing ball, and banning them. This means either certificate revocation, or a "filter" list of certified MTAs that are ignoring policy enforcement on their end.

Your suggestion of end user "account types" sounds like an accurate assessment of how this would be implemented -- again very scary. Now ISPs will be able to add charges for another "class" of Internet use. Small businesses who want a single mail address and don't want to buy business class services or hosting will be violating policy by sending business e-mail from their per/individual account.

Re:Open to abuse

[Anonymous Coward]

The issues regarding spam and the like, could be solved using different form of costs (like factoring huge numbers and so on). But this has been discussed before here on slashdot. It is a shame this was not included in the draft.

Re:Open to abuse

[Twylite]

'ello fyonn.

I think your point about anonymity is a good one. AMTP won't necessarily kill it, but IM2K would. We definately need to be able to receive all e-mails without being concered that some MTA somewhere is blocking them (I'm already having trouble talking to friends in the UK because of generous additions to spam blacklists).

The problems with IM2K are pretty well known, and we're still waiting for a solution ;) My biggest issue is having to download from a remote site at 0.5kbps instead of a full (wow) 56kbaud.

Pay per e-mail sucks because it can't account for foreign exchange disparities. $1 to send 100 e-mails is a whole lot cheaper for an average income earner in the US than R7 is here (ZA). The countries that will be the worst affected are the poorest 3rd world countries, that most need the benefit of cheap Internet access to improve their economic condition.

Well, that's my $0.0047.

Re:Open to abuse

[fyonn]

last time we had a discussion like this on slashdot we were at odds as I recall, this time we're on the same side :)

I think your point about anonymity is a good one. AMTP won't necessarily kill it, but IM2K would

it's funny, in my various discussions about the value of anonymity, there are so many people who don't get it. why should people have anonymity, whats the point and, my favourite, if they have nothing to hide... well, you know the rest.

and you know I have a hard time argueing with them. I know I want it to be around and I try and explain several contrived situations asbout why it's a good thing (usually private human rights activists in X third world countries come into it ;) but still some people just don't get why a lack of anonymity worries me. but then, of course, they are my more fascist friends :) (and, surprisingly, that doesn't don't include you, who woulda thought ;)

I'm already having trouble talking to friends in the UK because of generous additions to spam blacklists

I only use 1 blacklist at the moment, spamcop's, and even that doesn't stop mail to postmaster (he says... thinking, is the postmaster entry above the blacklist entry in exim's conf... think it is yes). mind you, a friend suggested denying blacklisted ip's with a "user unknown" error, as an attempt to get spammers to give up on that address, not sure how successful it would be.

however, afaik spamcop isn't as zealous as some other lists, like spews for example who just seem far too keen to put whole networks on.

The problems with IM2K are pretty well known, and we're still waiting for a solution ;) My biggest issue is having to download from a remote site at 0.5kbps instead of a full (wow) 56kbaud

well, exactly. the whole point of mail is that it is fie and forget, you send it and it should arrive at the recipients mailbox to wait for them to check their mail, and hopefully that mailserver should be local to them so they can get their mail quickly and with little delay (gotta check the daily spam).

Pay per e-mail sucks because it can't account for foreign exchange disparities

hmm.. hadn't thought about that one but you're quite right. that would suck mightily, not only with the disparity of what a rand is worth today vs tomorrow (hmm.. I'll hold off sending this email until the exchange rate improves) but also with the fact that the same value of money is worth different amounts to people from different countries, ie the price of bread here vs the price of bread there. a penny per email for me isn't that much (exlcuding mailing lists) though I would still resent paying it, however, the cent equivalent of a penny per email costs more in za as the cost of living is lower and people get paid less (in general, of course).

The countries that will be the worst affected are the poorest 3rd world countries, that most need the benefit of cheap Internet access to improve their economic condition.

hmm.. while I do advocate more widespread access to t'internet, I think that most third world countries have alot more they need to improve their economic situation, more equitable IP laws for example.

Well, that's my $0.0047

thats, what, R30 these days?

dave

Re:Open to abuse

[NearlyHeadless]

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.

The problem of distribution of certificate revocation lists does need to be addressed, but the problem is not as serious as you suggest. CRLs are signed, so can be replicated easily. The same people who now run RBLs can both replicate the CRLs from the CAs and publish their own list of certificates that they feel should not be trusted.

Although people on slashdot are complaining that CAs charge for certificates, it is precisely that fact, that certificates are much more expensive than domain names or IP addresses, that makes the system workable. Spammers cannot afford to pay a couple of hundred dollars for a certificate that will be revoked after a few days of abuse.

The idea that paying $100-$200 per year for a certificate is a significant burden on an ISP is ridiculous. The hardware, bandwidth, and administration dwarf this. The savings on bandwidth alone from solving the spam problem will more than make up for this.

Re:Open to abuse

[Twylite]

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.

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.

Re:Open to abuse

[NearlyHeadless]

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.

Re:Open to abuse

[Twylite]

I'll start with an aside. Let's say postage costs $0.01 per snail letter. $200 buys you 2,000 letters. Yet somehow you believe that it doesn't make economic sense to pay $200 to send 60,000 spam mails under the pretence of them being opt-in (that's not unreasonably large for an opt-in mailing list)? It costs a spammer around $20 to send that many messages, and they can expect at worse a 0.1% positive response, for a total profit of $380 if they can make $10 off each response and pay the $200 for a certificate. This is in line with the MO and expected income of your average spammer, according to various studies.

End users (like spammers) don't obtain certificates in AMTP. MTA's (ISPs and possibly large companies) do. You can't just revoke MTA certificates and prevent the ISP from reregistering -- the ISP has to take some proactive steps to prevent abuse, and then respond when it does occur.

The spammer can happily move to another ISP (which is what already happens), without having to pay for a new certificate, or have to give their credentials to anyone. If you're proposing black lists shared between ISPs -- forget it. It doesn't work at the moment, and its horribly open to abuse. The same goes for CAs: there will be more than one authority, and they are unlikely to share (or reliably share) blacklist data.

Any proposal based on end users having certificates and having to present ID verification destroy anonymity.

Re:Open to abuse

[Trepalium]

You think that a CA is going to revoke a cert just because spam originated from it? Not likely. You misunderstand the role that CAs play. They simply exist to try and prove that someone is who they say they are. All AMTP is likely to do is make spam middlemen appear on the scene. Instead of sending their spam through normal means, they'll transmit it to these spam middlemen, who will take all the means nessesary to make sure they have a wide variety of certificates across many domains. The spam will keep flowing, except there'll be new job opportunities for new scum.

Re:Open to abuse

[NearlyHeadless]

It costs a spammer around $20 to send that many messages, and they can expect at worse a 0.1% positive response, for a total profit of $380 if they can make $10 off each response and pay the $200 for a certificate. This is in line with the MO and expected income of your average spammer, according to various studies.

Sources, please. From what I've read, the actual positive response rate (for an actual sale, that is), is about 0.0023%, so you're off by about a factor of 40. And you're ignoring other costs. Estimates are that the current cost per sale for spam is about 4.50. If we can drive that up ten-fold, they're out of business.

End users (like spammers) don't obtain certificates in AMTP. MTA's (ISPs and possibly large companies) do. You can't just revoke MTA certificates and prevent the ISP from reregistering -- the ISP has to take some proactive steps to prevent abuse, and then respond when it does occur.

Most spammers do not go through their ISP's SMTP server. Instead, they run their own and they use open relays or open proxies to send mail. Of course you can revoke MTA certificates, just like RBLs block them now. ISP's SMTP servers are not the source of very much spam.

Besides using certificates instead of IP addresses, the main difference from the current situation is that ATMP is a whitelist system. Right now RBLs just can't keep up with the constant stream of open relays--several hundred new ones per week--nor with the prospect of hundreds of thousands of PCs infected with Sobig.xyz relaying spam.

Re:Open to abuse

[Anonymous Coward]

Sources, please. From what I've read, the actual positive response rate (for an actual sale, that is), is about 0.0023%, so you're off by about a factor of 40. And you're ignoring other costs. Estimates are that the current cost per sale for spam is about 4.50. If we can drive that up ten-fold, they're out of business.

This is an excellent point. The vast majority of e-spam is fraudulent products like penis pills and mortgage scams. Increasing the cost, even slightly will eliminate much of this. And this should put the problem it into the range of "legitimate" products -- AOL subscriptions and the other things you find in your snail mailbox.

Re:Open to abuse

[curunir]

Pay per e-mail sucks because it can't account for foreign exchange disparities. $1 to send 100 e-mails is a whole lot cheaper for an average income earner in the US than R7 is here (ZA). The countries that will be the worst affected are the poorest 3rd world countries, that most need the benefit of cheap Internet access to improve their economic condition.

Pay per email has promise, but if it is limited to actual currencies, it is destined to fail (for all the reasons you've enumerated.) The other way to force the sender to pay to send the message is to force them to expend a certain amount of CPU cycles before sending the message. It's a negligible cost (in time) to someone sending a few messages, but to someone sending millions of SPAM messages, it would bring the cost of sending those messages above the profits they can generate from sending those messages.

What's needed is an extension to SMTP which uses HashCash or something like it to ensure that the sender has to do a certain amount of work to send the message. If all the large MTAs began to support such an extension and the larger ISPs (err...largest ISP...*cough*AOL*cough*) began to require it to send messages to their users and through their servers, SPAM would end up being almost non-existant and the anonymous nature of email would be preserved.

Re:Open to abuse

[Twylite]

Google for "spam economics". Here are some of the links you'll find.

Even if I'm out by a factor of 40, my figures were based on a tiny 60,000 mails, and the only reason for this was the assumption that the ISP would be proactively monitoring traffic through its MTA or network in order to prevent policy violations, and would pick up attempts to send a number of messages unreasonably large for an opt-in list.

Re:Open to abuse

[rew]

SPAM now pays. For every dollar spent on sending Emails, more than a dollar is earned in the selling of whatever is advertized.

Once nine out of ten ISPs switch to using AMTP, that one ISP that's left out will not be very popular anymore as that's where you still get (lots of) spam. And when the number of people who get the SPAM is reduced, we can only hope that some threshold of the spammers is reached: that it starts to cost more than a dollar to earn a dollar in the selling of the product.....

Evil bit?

[Realistic_Dragon]

Does that mail policy code sound like an evil bit to you too?

Tagged as commercial, in the bin if goes!

Re:Evil bit?

[Have Blue]

Don't forget that things like online order confirmations would also be tagged as commercial.

No more anonymous emails?

[CreatorOfSmallTruths]

wait. I don't want to flame or troll - but wait a sec...
Having a centralized hub from which all are certified means that the central junction can log each and every email sent or received (not just the body, as being done now, but also the *true* source of the email).
So? What happened to the freedom of speech?

I think that the real solution will involve some sort of "grouping" of hundred of thousands of people all over the world who trust each other and all have the same signature... that way no one could ever be traced on the one hand and anonymous posts will remain anonymous while the global signature will testify the validity of the sender (mass emailers, spammers and the such will just never be accepted to any of these groups).
It would be like "a guild of emailers".

Any sense in the above? share.

Re:No more anonymous emails?

[ColdGrits]

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

Technical solution to a social problem

[broothal]

This is yet another technical solution to a social problem. It's one of the better I've seen - no doubt about that - it's just that ... it wont work.

I reckon we can work out technical solutions all that we want, which in turn will give us a brief relief for spam. But then the spammers catch up, and we're back where we started.

As long as there's money in spam, there will be spam. We've already seen that spammers are no good scumbags that doesn't stop at *any* means - including dDos attacks. The only solution to spam is a political approach. First of all, we need good, sound anti-spam laws. A very simple law like "it's illegal to send commercial email to anyone without prior consent" would do. Now we have a useful tool, and when the first dozen spammers has been sued back to the stoneage, I believe the spam load will drop for good.

Besides, why do *I* have to jump through hoops to get rid of something I never asked for in the first place?

Re:Technical solution to a social problem

[mgkimsal2]

A very simple law like "it's illegal to send commercial email to anyone without prior consent" would do."

That's simply too broad. Me sending an introductory email to a new business welcoming them to the area could be construed as 'commercial' because I might be angling for new business in the future.

Re:Technical solution to a social problem

[Gunzour]

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.

Re:Technical solution to a social problem

[agentk]

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

Wow, that's a good conspiracy. Those pesky extra terrestrial islamist terrorist nazi CIA-funded hacker-spamers again!

Those guys that aren't really selling anything are just collecting your email address and other information to sell to real companies that sell similar products.

Re:Technical solution to a social problem

[Anonymous Coward]

What part of Unsolicited Commercial Email do you not understand?

I suppose you get these new business addresses from WHOIS, spammy.

the MTA buys the Cert

[Anonymous Coward]

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

Re:the MTA buys the Cert

[Anonymous Coward]

The problem is that the certificate is no more a unique identifier than an IP address currently is. Possibly less so.

If it would be easy to get new certificates, spammers could just switch occasionally. If it would be hard to get new certificates, this could become too cumbersome for legitimate users.

Minor nit - the MTA doesn't buy a certificate, whoever installs the MTA does...

Re:the MTA buys the Cert

[Anonymous Coward]

You obviously don't run your own mail server!

Too much work for too little gain

[amcguinn]

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

[Anonymous Coward]

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

serious questions about validity and reliability

[esj at harvee]

Any form of certificate based authentication is a serious problem for freedom of speech and reliability. Anytime you can use a certificate to turn off a spammer, you can use it to turn off anyone's ability to speak/communicate.

Reliability also becomes critically impaired because there is now an additional requirement for every single piece of mail transfer to check the validity of its certificate with a given certificate authority.

If a certificate authority is unable to handle the load, what happens to e-mail? Is it delayed? Is it let through (opportunity for spammer)?

Who pays for the infrastructure to handle all of these requests?

Additional questions to consider is what happens if you have a rogue certificate authority who hands out certificates to spamming entities and will not revoke them?

Who controls turning off certificates? Is there any oversight on their actions?

Can a certificate authority be influenced by a government or large corporate entity to revoke a certificate?

if this plan is adopted, how can one maintain competition in the certificate market unlike what happened in the Web server certificate market with VeriSign?

my bias is from the sender pays world. A certificate controlled environment is more receiver pays then it is today. The receiver will pay for all of the changes in hardware, bandwidth, network reliability at the ISP and certificate authority. It will not be cheap. On the other hand, sender pays systems such as camram (http://www.camram.org) are decentralized, highly cost-effective and shift costs to the sender.

No no no!

[jbert]

OK. Can someone please tell me the difference between this and:

- adding a 'X-Header: this is not spam'
- extending trust to specific IP address/address ranges (if someone from 1.2.3.4 says "its not spam" then I trust them)?

If you are going to say that it uses certificates to establish trust relationships and so it is more secure then you can just go and whistle. You can't reliably spoof an IP address on a TCP connection over the Internet (UDP yes, TCP no. LAN yes, Internet No.)

Spam is a problem because it is convenient for us to be able to receive mail from people we don't know.

If we choose to not receive email from people we don't know, then there are many ways to achieve that now, within the existing protocols. They are even easier for home users to use too.

THIS DOESN'T NEED A NEW PROTOCOL-LEVEL COMMAND.

Phew, sorry, but this comes up on slashdot WAY too often. Please stop it.

Re:No no no!

[amcguinn]

Absolutely right, but this time it's not "coming up on slashdot", even people in the "real world" are producing this rubbish. You can hardly blame slashdot for reporting it.

seems like a solution in search of a problem

[penguin7of9]

AMTP seems like a solution in search of a problem. Unless most of the Internet switches, there will still be open relays. Spammers that don't use open relays and operate through existing ISPs will continue to be able to do so.

Also, to accomplish what AMTP apparently wants to accomplish, it's not necessary to involve a central, costly certificate authority--anybody who wants to talk safely to sites they know and trust can exchange keys with them.

AMTP looks like it's mostly going to be a boon to the bottom line of certificate authorities, and an erosion of privacy for "the little guy". I don't believe it will make a big dent in spam.

What about bankruptcies?

[taliver]

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.

Re:What about bankruptcies?

[JKR]

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

Jon.

Re:What about bankruptcies?

[the_truk_stop]

I believe the number one thing needed is accountability

You made good points, but I disagree with the proposed standard's certificates plan and your above statement. Do we users really want or need an independent and centralized third party deciding who can and cannot send email?

Re:What about bankruptcies?

[taliver]

No, but being able to trace back mail to the computer that sent it goes a long way towards accountability. Kinda like having caller ID tell you who it is. When you get "Out Of Area", you know it's a telemarketer. Now, wouldn't it be great if you could know which ones were hanging up on you?

That's the level of accountability I'm referring to, not some sort of "Mother May I" for email. I'd take spam over that system any day.

creating and enforcing more strict SMTP helps too

[HTD]

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?

[Cooper_007]

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.

even better idea...

[ecalkin]

why not the isp mail provider to start. if you get the isp to issue certificates, make them responsible for their mail users. people that get their own mailservers could still get a cert from their isp.

if the isp riske being bounced, i think they will manage their mail system/users a little more closely.

eric

I was thinking of http in relation to gopher

[Anonymous Coward]

As gopher was designed for distributed document search and retrieval, I was thinking of it more in terms of http than ftp.

But, but, but...how will I send mail with Telnet?

[Anonymous Coward]

(I'm not kidding)
My favorite client, Telnet, is now too simple for this protocol... how can I hope to use certificates when I have to type them in manually?

Re:serious questions about validity and reliabilit

[iangoldby]

Any form of certificate based authentication is a serious problem for freedom of speech and reliability. Anytime you can use a certificate to turn off a spammer, you can use it to turn off anyone's ability to speak/communicate.

Not this old one again. Freedom of speech is not the same as a right to be heard. You can say what you want. And I can choose not to listen. You still have your freedom of speech.

Reliability also becomes critically impaired because there is now an additional requirement for every single piece of mail transfer to check the validity of its certificate with a given certificate authority.

You can validate certificates without needing to contact the CA by (in effect) just verifying the checksum.

legislation in your country or mine?

[YouOverThere]

The internet is a really big place. I would suspect most spammers already do it from outside North America.

If you want to use legislation to stop spam, make it illegal to get buisness from spam. morgage company XYZ gets your name from a broker, who used an agent, who got your name via a reply to their spam.

XYZ should be at fault. There are already laws in countries like this dealing with drug money...

As mentioned above, adding a CA will only make it 'more difficult' for spammers. It will not stop them .

Er.. Am I wrong....

[MasterSLATE]

Am I wrong or doesn't Thawte give away free certificates?

Won't work

[Fefe]

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:Won't work

[amcguinn]

The certificate isn't meant to prove that the sender isn't a spammer, it's only meant to prove that the sender really is the owner of the domain. The CA's are theoretically capable of checking this: that's how https works a well.

That said, this is rather pointless as the reverse DNS can be checked anyway. It makes the domain owner a little more traceable, but not much.

As far as revoking is concerned, the idea is not so much that certificates of spammers will be revoked as that domain names of spammers will be blocked using block lists. Again, this is a negligible advance on the current (highly unsatisfactory) system of DNSBLs.

Re:Won't work

[Ath]

You left a major point out: spamming is illegal in many jurisdictions and that number is increasing every day.

The current problem with spammers is they are hiding and very difficult to track down. The certificate requirement will make any legal consequences enforceable.

In the US, I think it is very unlikely that spamming will be made entirely illegal. Instead, you will see opt out requirements and/or tagging of the message as unsolicited commercial email.

Regardless, if you can truly identify who is sending the email, you can enforce the other requirements.

The real issue is whether we are now ready to give up the ability to send anonymous email directly. But there will still always be anonymous remailers.

Free Certificate

[Anonymous Coward]

The International Postal Union and the national postal authorities of all the countries of the world should provide free certificates for their citizens. Its a basic authentication document like a passport that should not be left to private concerns for security reasons. Private corporations could be charged some kind of nominal user fee (*really* nominal). I know we don't usually go for government programs but I've never heard anyone suggest that Verisign should be allowed to raise an army, mint coins or issue passports. I think I heard awhile back that the Canadian government is issuing certificates to all its citizens so they can access their confidential government info online. Of course the benefits would be lost if the U.S., for example, subcontracted to Verisign to do the work. That would just be another taxpayer rip-off by a big political contributor. If U.S.P.S. couldn't do the job with internal resources maybe we should find some new people to run it.

Re:serious questions about validity and reliabilit

[Homology]

Can a certificate authority be influenced by a government or large corporate entity to revoke a certificate?

DMCA could easily be used here to block e-mails from any domain using USA based CA's.

Just pretend I'm a German citizen living Germany, having a .de domain, and have a few mailinglists. One of the mailinglist is about how to exercise my legal fair use rights in Germany, which sometimes relates to some products from USA based companies.

Now, imagine that my CA is VeriSign. This beeing an US based company, it can be slapped with a DMCA for my mailinglist. Suddenly I got real problems sending e-mail at all.

Freedom of Speech != anonymity

[Anonymous Coward]

Freedom of Speech does not require anonymity.

DNS PTR record required by the RFC draft?

[LynXmaN]

o 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. Equivalent tests SHALL apply to connections using IPv6 or other non-IPv4 protocols.

I don't know if this happens to everybody but I have my servers in collocation and the IN-ADDR.ARPA records are controlled by the Collocation Company (in this case MCI Worldcom) and I don't have access to that records so my SMTP server doesn't resolve right when doing a reverse query.

Maybe it's only my problem but I think that the certificate should be enough check already, PTR records do not always conform to your mail server name.

Re:It helps against faked "from"

[amcguinn]

The certificate authenticates the MTA passing on the message, not the sender. Many people send out mail with a "From:" address quite independent of the network originating the message; I do myself.

Certificates

[ajs318]

What's to stop a spammer doing this?

1. Get a certificate on credit
2. Send out an absolute stackload of emails in one go
3. Have the certificate revoked
4. Don't pay for certificate
5. ???
6. Profit!
7. Goto 1

What we really need is a pay-per-message system. It would work just like mobile phones: you buy "credit" from your ISP, it doesn't get topped up until they've actually seen the money, and it goes down each time you send a message.

But it might not be necessary if everyone just configured their SMTP servers properly, checked the HELO/EHLO and refused anything without a valid reverse DNS lookup, and barred anything with Inappropriate Attachments. {I once got sent a .exe attachment. They still haven't found all the bits of the sender. Nobody has EVER sent me a .doc that could not have been sent in the text of the message, nor are they ever likely to}. I personally don't accept attachments, period. People can use my FTP server if they want to send me stuff ..... it's configured with a one-way trapdoor {incoming directory can't be read at all by anon users, can only be overwritten on the same session as it was sent}.

PGP is a better model

[DrXym]

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

[azaris]

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:PGP is a better model

[Anonymous Coward]

"Web of Trust" is great if you are some sort of CyhperPunk HzX0r who wants to remain trusted, but anonymous. But it's useless for commercial transactions (unless it's something illegal like drugs).

"A trusts B who trusts C who trusts D" is pretty much useless info in most cases. It does not imply any trust between A and D, nor does it even do the basic stuff like verifying a postal address.

The only way the PGP model would be useful in the real world is if you set up the equivalent of central certificate authorities to sign keys. And one can implement homegrown CAs with x509.

Re:PGP is a better model

[DrXym]

As I said, CAs can or could sign PGP keys, so there is no issue there. Individuals who don't care or need the bother of a worthless CA signature can do without, while business can go ahead and buy one. As for 'web of trust' being only useful for hax0rs, think again, since it would be easy enough to set up a key server in a company that issue PGP keys automatically signed (with built in expiration if need be) that bestowed trust.

The issue (and it is one) is to integrate PGP encryption into the existing certificate system, for example as an extension. I have no idea if something has done to do this already, but I don't see leading proponents such as RSA being too keen to push it.

Even if PKI were dumped or sidelined for email, it would still be a great leap forward. The format stinks and if you've ever tried to send a large attachment you'll know how painfully slow it is too.

Re:PGP is a better model

[Anonymous Coward]

> since it would be easy enough to set up a key server in a company that issue PGP keys automatically signed

Well, a company can set up an internal CA for free to do this also. (In fact, I know of several companies who have done that, while I know of noone that use PGP in that way. Just run the Wizard that comes with Windows and yer a CA.)

And that's not an example of the "web of trust" because there's only a one tier relationship.

Re:PGP is a better model

[DrXym]

Yes, but if company A is on friendly terms with company B, C, D etc. then it's easy enough to build up that web of trust on a business level. And as I said, company A could go and buy themselves a sig from a proper CA if they wanted.

Re:PGP is a better model

[sal]

The big problem with PGP is the effort in building the web of trust. Personally, I'd like to see the following:

Keep SMTP broken, this isn't where the problem is.

Build a new protocol to allow end users to exchange pgp keys, allow for server keys and group keys. It should be as lite as pop3

A new RFC for mail clients to use the web of trust. It should be easy for end users to add/remove/unsign from that web of trust.

The MDA would use these keys to decide when to soft bounce a "you don't know this person" message back to the origin.

It should be possible to set up "open" keys that anyone may email, but such open keys may only be for receiving email, not sending it.

As an example, let's say that person A joins a web site W. As part of the sign up process, he adds W's server key to his WoT. At that point, all other users of W can send him email. If at some point site W starts spamming him, he can remove W from his WoT and block all email that comes to him by way of W. But, if there are people B,C and D that he knows from the W site, he can add them to his WoT and still get those messages.

Likewise company I and J can peer their server keys to allow all employees to email safely.

Users should be able to easily set a thresh hold, say five levels of trust. Also, there should be ways for to people at a bar to pass a note on a napkin on how to join each other's WoT.

The idea is not to stop all spam, but to prevent spammers from exchanging user email addresses. Once I block spammer S from my WoT, he can never pass my info to spammers T, U and V as they get blocked in advance.

There are also other alternatives alternative?

[cluge]

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

Electronic Sigs are nice, but . . .

[werdna]

. . . the tag is all you really need to provide a legitimate, constitutional anti-spam process, and that can work just fine under SMTP without adopting a new transport protocol. What if we simply adopted the convention that adding the following header:

X-DISTRIBUTION 100 7

to mean something like "this e-mail, or copies substantially similar thereto, has been mailed to fewer than 100 different e-mail addresses, excepting to the e-mail of a person who has affirmatively requested the distribution and has not subsequently withdrawn the request, within the past 7 days."

The proposition is true for virtually all ordinary e-mail, including list services, so that ordinary mail can routinely place the listed message without misrepresentation. However, virtually every piece of spam including the header would affirmatively misrepresent its means of distribution. User clients could filter for or against appropriate X-DISTRIBUTION headings.

Add to this a legal regime making it strongly actionable, not to send lots of unwanted mail, but to send mail misrepresenting the manner by which it has been sent. Because it punishes only false statements, does not require any speech be added to existing e-mail, while still permitting anonymouscommunication, the First Amendment considerations are obviated. Now make the penalties as bad as needed to deter -- make it a crime, provide powerful civil statutory damages and automatic attorney fees and so forth. Make the penalties apply to everyone down the line facilitating the spam, including the persons commissioning the spam and those contributing to its production

True, the process doesn't meaningfully deter truly anonymous spam that doesn't seek any reply or reaction -- but most spam DOES actually try to sell me something or get me to look at a web site, and so forth. Provide a means to sell or obtain information about the receiver to somboedy, and you have provided a honeypot hook.

Reducing the incentive to engage in commercial spam could significantly reduce the commercial interest that drives much of modern spam and, visible prosecution or judgments against contemptible spammers could suffice to dramtiacally impact the problem.

Re:Electronic Sigs are nice, but . . .

[buss_error]

. . . the tag is all you really need to provide a legitimate, constitutional anti-spam process, and that can work just fine under SMTP without adopting a new transport protocol. What if we simply adopted the convention that adding the following header:

Because spamming slime have no problem at all with forging anything they want. Without accountabillity, nothing changes.

Some common tricks spammers use:

Set up their own ISP, or buy one

Steal IP space from dead netblocks

Use your pc as a spamming zombie via virus, hacking, cracking, or because the PC isn't otherwise secure.

Dialup IPs

Dialup IPs with Janus connections (use a dialup IP and forge that IP in the highspeed line. When you get a kill on the source, you are only killing a dialup line.)

buy bulletproof connections from lazy/incompentant/bankrupt ISPs

From your description, your idea depends on the spammer telling the truth about himself. Rule 0. Spammers lie.
I see problems with AMTP too.

Spammers set up their own CA and fake being legitimte by selling to non-spammers too. The non-spammers become human shields.

A CA, even if it were 10,000.00USD, wouldn't stop them. They would happily spend that to get a 24 hour spam run.

Spammers already infest many ISPs that have a large group of legitimate users. If you cut that ISP off, you also cut off their legitimate users.

The only way I see being able to cut off spammers is whitelisting people you want to email and using challange/response to those not whitelisted. This doesn't require changing SMTP, CAs, or all the mail clients in the world, but it also doesn't make money for anyone, so it unlikely to see wide adoption in large ISPs.

As for using the law, the problem there is that over half the states already have laws against UBE, and the rate of spam keeps going up. How are you going to sue when the mail is sent from an open proxy in .BR, with a web server for payment in .CH, and the payment processor is in .RU, and the product is shipped out of .NZ?

Silly as this all seems, spamming is big bucks. Remove the money, remove the problem. But you can't do that by suing all over the globe. You will do that when you stop lying, stealing scum suckers from being able to contact anyone in the first place.

Re:Electronic Sigs are nice, but . . .

[Anonymous Coward]

It is "strongly actionable" to hack into someone else's computer (and use it to send spam). It is "strongly actionable" to lie to someone that you have 25 million in a Nigerian bank account in order to rip them off for $500 in a bank account opening fee. It is "strongly actionable" to sell viagra creame or other stuff at a lose just to collect credit card numbers to sell to professional identity theives.

And the prosecutors manage only an occasional feeble thrust at those activities.

How is criminalizing a header going to suddenly fix everything ?

pay per message bad

[amcguinn]

What we really need is a pay-per-message system. It would work just like mobile phones: you buy "credit" from your ISP, it doesn't get topped up until they've actually seen the money, and it goes down each time you send a message.

Lots of people suggest this. It's too expensive to run. Already for domestic landline telephony, the cost of billing is a significant proportion of the total cost even for postpay. Prepay is considerably more expensive to run. (I used to work on telephone billing software).

The system would be awash with fraud, as well.

Prototype Anyone?

[geek2003]

Is anyone working on a prototype for this already? How soon will it be before M$ tries it's embrace and extend strategy to obfuscate the protocol. Lets see...

put some thawte into it

[shokk]

Get yourself a free Thawte community cert. This doesn't scale for large organizations, but for a very small org it can work.

Re:put some thawte into it

[shokk]

And the URL for that is http://www.thawte.com/html/COMMUNITY/.

Drop it already

[photon317]

This tried to go through as an article on k5 a while back too but got voted out. AMTPs commercial/personal/spam field can easily just be a header field inside a message, as has been suggested several times - and TLS security and authentication already exist in ESMTP. So what exactly does AMTP do that can't be done with the existing widely deployed protocol?

The certificates are for servers, not individuals

[Gunzour]

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.

Re:It helps against faked "from"

[Eunuchswear]

Many people send out mail with a "From:" address quite independent of the network originating the message; I do myself.

And the MSA (not MTA) that accepts the message with the forged From: address is broken and should be fixed or blacklisted.

Sorry, the days of trust and friendliness are over.

(I send almost all my mail from a network that has nothing to do with my From: address, but I send it via a MSA that checks my From: address. In a AMTP system the senders *MUST* be authentificated by their MSA. I'm not sure the RFC says this.)

Let each domain have its own CA

[karji]

& then have each domain's key be downloaded from somewhere like domainkey..com

Then you won't have to pay anything for the signature.

And when the spammer forges another cert?

[Anonymous Coward]

What then?

Not good enough

[Anonymous Coward]

Virus hooks into existing outlook instance (usually installed by default)

Sends legitimate spam under that virus infected user.

SPam spam spam...Whats new. All this is doing is shifting them from simply sending emails to ATTACKING computers to get mails sent.

I think this is going to cause more problems that it solves.

Not everyone needs to run a mail server.

[sabecon]

One solution is for not everyone to be able to run a mail server.

Have a network of Authorized Servers to start. These can communicate through SSL or any number of encrypted and authenticated systems.

You want to start a mail server into the "club", you have two choices, get a sponser (ie: your ISP) or put real money in an escrow account.

You get a rating in the group as to the the kind and amount of mail you send. If you get too many complaints about your mail, you lose points. If you behave well long enough without problems, you gain points. Operate long enough without problems, and your account is split off to become your own entity seperate from your sponsor.

If you are sponsored, you not only lose points from your mail domain, your sponsor gets points deducted as well. If you are self sponsored, you lose money from your escrow account.

This will have two main benefits. You make it hurt (expensive) for people sending mail that people do not want. You also make this reputation for managed content a bankable commodity. An ISP for instance can have some "four star" (as an example, probably tradmarked scoring would be needed) rating as an enticement to get people to send mail through them.

Corrolary benefit: Takes away the temptation for the ISP that would look the other way for a price and let people send bulk mailings.

Could be expanded to do things like limit amount of mail that you could send until you recieved sufficient ranking. This could build in several levels. X number of points and you could send over 10 mails/ day. More points and your cap goes up to 100. More points and you can operate a listserv. Final level is you are a peer that is unrestricted.

The individual rules could be set by the sponsoring ISP. Don't like their policy, get another provider for mail. Another selling point for the ISP.

The whole point of it is to make it more attractive to be well behaved and to have a way to make it too expensive to send unwanted mail.

I have not focused in on either spam or email viruses. Treat them the same. Poorly managed email is poorly managed email.

Re:Not everyone needs to run a mail server.

[Anonymous Coward]

As someone who has abused meta-mod privedges extensively, I can tell you that the escrow accounts of people I don't like are going to be forfitted to my fake complaints that they are sending spam.

Think about that.

A bad example of commercialisation of the internet

[Anonymous Coward]

At best ... This will just be a way to create a user-pays 'private internet', that will work and be spam-free for a while, make some spotty faced .commie (or worse, a rich multinational corp) a lot of money, and then turn into a messy spam-laden free-for-all within 12 months.

It's a really really crap idea, that will not remotely solve the problem it is attempting to address any better than authorised smtp already doesn't solve it.

Spam filter is the solution !

[garaged]

I really think that sentence. I know the internet traffic is a problem, but we're paying for it right now, and the internet does not collapses. With good spam filtering, the spammers would eventually stop sending spam, because it would not be profitable. Any thoughts ?

Re:Spam filter is the solution !

[pair-a-noyd]

People are too stupid to use them.
Most of them are mouth breathers, like that moron on the AOL commercial who's awed by the "get your lure on" animation while his kid is stuck somewhere.

People like that ARE NOT CAPABLE of installing or configuring filters, much less anything else. To them a computer is like a TV, they watch it, they don't USE it. It's a mystery box that automagically does stuff for them.

The vast majority of the public is brain dead.
Your thought is correct in theory, but in practice it requires that the end users be capable, which they are not in most cases..

might be expensive for others

[Anonymous Coward]

good idea, but already, the internet's interconnect costs seem to make access expensive for all of us in the third world, even your pennies might break the backs those who just want send some harmless mail.What you are proposing is to start paying the ISP's. as it is we are tired of the increasing commercialisation of the internet... using CA cert might be the way to whitelist enmasse...

And everyone said: "No E-Mail Tax"

[Anonymous Coward]

oh well it was fun while it lasted.

Re:It helps against faked "from"

[amcguinn]

I just checked the RFC, because this is important.

RFC2822 just says

The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message.

As you say, the world is changing, but have you any reference to some document saying it is now expected that the From: header of a message should represent the sender's mailbox on the system the message was sent from? I'm quite willing to adapt if there's a genuine move in this direction.

The AMTP RFC says nothing about the sender of the mail at all. It is concerned solely with authenticating the mail server.

My understanding was that the envelope sender should be checked by the MTA, not the header fields

Certs for all

[Directrix1]

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.

Re:It helps against faked "from"

[Eunuchswear]

but have you any reference to some document saying it is now expected that the From: header of a message should represent the sender's mailbox on the system the message was sent from?

I have no RFC for that, and in fact I think it's not necessary. What's necessary is that the MSA (i.e. the first MTA that gets the message) knows who the sender is, and knows that the From: address is (one of) the address of the sender.

AMTP seems to give a reliable method of tracking a message back to the sender, or back to the first badly behaving MTA. If that MTA won't fix the problem it'll get blacklisted.

I doubt it's the end of the war against spam, but it might be the beginning of the end. Oh my God I've gone bald!

Why a central cert?

[maynard]

Why not have the site administrator generate a public/private keypair and embed the private key in the mail server? This allows for the same level of authenticity by cryptographic signature, without resorting to a central certificate authority. --M

Re:Why a central cert?

[Anonymous Coward]

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?

Re:Why a central cert?

[maynard]

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

Re:Why a central cert?

[Anonymous Coward]

Read the FAQ. One of the more interesting aspects of the protocol is the publishing of "concisely-defined policies".

The question is: who enforces that those policies are followed? And who defines the terms? Just because a servers policy is "no spam", how to I know that's true (and what it means by "spam").

A nice idea, but cooperation on the 'net has degraded over the last 10 years. A decade ago, you could've easily done this. You didn't have to convince isp.com. Today, I doubt it.

Re:Why a central cert?

[maynard]

Read the FAQ. One of the more interesting aspects of the protocol is the publishing of "concisely-defined policies".

Read it. Enforcing "policies" comes after authenticating a valid connection between two parties. This is where the cert comes in, and where I'm arguing that a public/private key pair is a better solution. Also note that encrypting the session between both mail servers is not a critical function of authenticating the validity of both servers, which can be done strictly by passing signatures, though it may be desirable.

Just because a servers policy is "no spam", how to I know that's true (and what it means by "spam"

In this case "spam" is definied as any message originating from a server or client that does not offer proper authentication in order to assure the validity of a chain of trust from sender to recipient. It's assumed that a valid user would not SPAM, or at the very least if one did site administrators and/or authorities would be able to determine just who did so.

I just happen to think a PGP private key embedded in the server, and thus used to sign the message envelope with a signature and public key for the recipient server to verify, is better than using a public cert. But that's JMO.

Cheers,
Maynard

Re:The certificates are for servers, not individua

[warpSpeed]

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

[geirt]

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

Re:It helps against faked "from"

[amcguinn]

In that case I'm happily compliant with your new master plan, since the first MTA that gets the message is exim running on my debian box, and it knows perfectly well that it's me sending the message - in fact it rewrites the From: address from andrew@ to andrew@.

I'm not sure how that helps anyone else, mind, as the next step is my ISP, and it's only going to be aware that my mail is coming from an MTA and not a client if it bothers to look at the Received: headers.

In short, I think you need to think this through more fully, or at least explain yourself better. Maybe you could write a journal entry on the subject? (I do believe you're on the right lines.)

DRIP is a better option, IMHO

[bobcat]

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

Re:DRIP is a better option, IMHO

[hey]

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:DRIP is a better option, IMHO

[WuphonsReach]

DRIP / DMP / SMTP+SPF / RMX -- all work of the same basic idea and just vary in details. Allow the domain owners (if they wish) to specify which servers are allowed to send e-mail for that domain. The destinations can then choose whether to accept e-mail that is not from an approved IP for the source domain. Reasonably simple implementation, and decentralized. It at least takes a large bite out of the forged domain issue and makes whitelisting much more reliable.

This is a BAD idea!

[Paul68]

It requires the ORIGINATOR to qualify the type of mail. Right, for SPAM we know the originator is untrustworthy. This is an obvious hole in the system. Because of this, any system of this type is bound to fail.

Storing the email on the server side as suggested by Internet Mail 2000. Is even worse. So I will have to indicate to the sender WHEN I am readying their mail and from WHERE (which IP address)? You have got to be kidding!

It's so obvious we need authenticated email

[tjstork]

I am STILL getting replies from random people indicating that my address is being hijacked.

I am STILL forwarding requests to get IPs from the original SMTP requests, if available, and then tracing back to the ISP.

email is so hopelessly broken it is beyond compare.

Authenticated email would at least mean that if an email came from my address, it actually came from my computer(s), and I can keep control of my own address. Right now, I have none, and I am completely po'd.

Re:It helps against faked "from"

[valdis]

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

[infra-red]

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.

Re:It helps against faked "from"

[Eunuchswear]

So, if I have a problem, I know who your ISP is (I got his cert), he knows who your MTA is (he got its cert, or otherwise identified you), and you know who you are. (you do, don't you?)

Your ISP shouldn't accept mail from you (or your system) if he doesn't know who you are.

So you spam me. I complain to you, if you don't fix it I can complain to your MTA, if he doesn't fix it I can blacklist him.

The system might work if certs are not cheap :-)

MOD UP or at least disagree

[Anonymous Coward]

This is the key point. If no-one can explain why this guy's wrong, why don't they mod him up?

Re:The certificates are for servers, not individua

[Anonymous Coward]

Maybe you are looking for greylists?

Breakdowns

[Todd Knarr]

1. 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?
2. 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.
3. 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?
4. 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:It helps against faked "from"

[Eunuchswear]

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:

Yup, and who is the biggest CA?

Verisign.

Very trustworthy.

not a good idea

[Anonymous Coward]

Do you think a spammer is going to label their spam as commercial? They don't even include a real reply-to address today. They fake their identity to attempt to get you to read the email and include subject lines like "Re: about that proposal".

How is this system or any system going to fix the problems we've got now where people LIE all the time?

Should have done it the right way the first time. Now it will be nearly impossible to fix.

How is this different from email whitelists?

[Grahame]

This seems to be effectively like the whitelist approach to spam blocking, with the CAs becoming the whitelist maintainers (for a fee).
But right now we already have the choice of using blacklists or whitelists, mostly provided free on an open-source kind of philosophy. Basing it on a certificate means that there is less traffic going to DNS blocking list servers, so they don't become a bottleneck, but this doesn't seem to be a problem at the moment anyway.
The proposal drags domain names into the picture, rather than just IP addresses, but what is the point of that? Each server along the path of an email can currently include a received line to identify the IP address that it received the message from, and IP addresses are already identified against their owners by the allocation authorities, so I don't see what the certification adds.
The identification of message types does add something, but either it will be hard to maintain because of all the nuances of types, or else all mail will have to be pigeon-holed into often ill-fitting categories.
We already see the problems caused by (over?)zealous use of blocking when those of us with our own, uncompromised and quite secure web servers are blocked by AOL just because we are on supposedly "dynamic" cable or DSL lines (even though our IP address never changes for years at a time).
We have a system currently whereby an MTA is just that: a Mail Transport Agent, and SMTP only deals with the transport of mail. The standard for mail transport should not be complicated by additional filtering, classification and blocking functions.

Re:It helps against faked "from"

[valdis]

EXACTLY.

And you can't pull Verisign out of your 'trusted root CA' list because you'll cut yourself off from too many places you want to talk to. As Randy Bush often says on the NANOG mailing list, "I encourage my competitors to design their networks this way".

the inevitable IM2000 reference

[caudron]

If we are to go through all the trouble of rolling out a new protocol, why would we roll one out that only kinda fixes the problem?

The IM2000 protocol fixes the problem at its source. Isn't that the kind of solution we should be looking for?

-Tom

ISPs not really annoyed by spam

[dcavanaugh]

If they were really annoyed, they would cut out all the pink contracts. If spam were not profitable to the ISPs, it would be gone faster than you can say "fees and surcharges".

Re:ISPs not really annoyed by spam

[RollingThunder]

The ISPs that are getting annoyed aren't the ones writing the pink contracts. They're the ones that are being victimized by spammers on other ISP's who did write pink contracts.

Re:ISPs not really annoyed by spam

[dcavanaugh]

It's like the electric company complaining about too many people using their air conditioners. Sure, they complain about people wasting energy, but at the end of the day, more product is sold, over-consumption justifies expanding the infrastructure, along with the next rate increase to pay for it all. Sound familiar?

Re:ISPs not really annoyed by spam

[RollingThunder]

No, you just aren't getting it.

Your power company analogy has nothing to do with this, as the ISP's that are suffering ARE NOT SELLING TO SPAMMERS. They are being overloaded by spammers, not profiting from them.

Re:ISPs not really annoyed by spam

[dcavanaugh]

There are many ISPs complaining about the cost of spam, but there is a smaller number of ISPs that actually lose money on spam. If every ISP who complained about spam was not actually supporting it, there would be no problem to solve.

Insurance companies complain about fraud. Those who actually lose money due to fraud are going to go out of business. If they can pass on the cost to consumers, everything is ok (sort of). If fraud raises costs 25% and they can jack up the rates 35% (while complaining about fraud), then it becomes a profit center (more fraud == more profit). If the fraud were stopped dead in its tracks tomorrow, would your rates drop?

I would be more inclined to believe the ISPs if I had not seen so many cases of spam traceable back to the same ISPs, with zero response to complaints. There is very little enforcement of anything resembling an anti-spam AUP. It's totally obvious -- (a) the spammers are a source of revenue, (b) spam victims are not, (c) there are a whole lot more ISPs supporting spam than will admit it.

Margins are tight in the ISP business. Anyone who is having a rough ride is going to be mighty tempted to enter the world of sleaze. If the margins were better, I think most of the ISPs would behave. The bad apples could then be isolated and forced into compliance. But today's reality is just the opposite. There are so many spamming ISPs that you either quietly support spam or get drowned in cost by those who do. Very few managers are going to let their business go down the drain if they could save themselves (even if just for this month) with a pink contract.

Re:ISPs not really annoyed by spam

[bahamat]

If they were really annoyed, they would cut out all the pink contracts. If spam were not profitable to the ISPs, it would be gone faster than you can say "fees and surcharges".

You aparently know nothing about business or customers. I run and ISP and I loathe spam. Unfortunately there's nothing I can do about it. People want e-mail (we even have some bastard users who want spam).

Spam sucks, and it costs money in bandwidth (about 40% of all our bandwith is spam or spam bounce) but the only way to eliminate it is to drop e-mail all together, and that would cost us much more money.

In short, dealing with spam is cheaper than dropping e-mail, and thus we are stuck.

www.cacert.org

[emancitech]

now to get a certificate signed for a decent price is the challenge,
check out www.cacert.org
they offer free certificates, and has a reassurance program, that trys to give some validity to the certificate holders...

Hash Cash to stop UCE

[Anonymous Coward]

I'm suprised noone has brought up Hash Cash yet as a technical means to stop spam:

"Hash cash is payment in burnt CPU cycles by calculating n-bit partial hash collisions on chosen texts.

The idea of using partial hashes is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly. This can be used as the basis for an ecash system measured in burnt CPU cycles. Such cash systems can be used to throttle systematic abuses of un-metered internet resources."

Now we just need a decent RFC for mail transfer!

Re:Hash Cash to stop UCE

[caluml]

Not a bad idea - I'm surprised that I didn't think of that myself.
Yeah, choose a nice high amount of bits that takes maybe 30 seconds to sign an email with.
When an email arrives at my server, the first thing it does is verify that signature. If it's bad, sling the email.

That'll for sure slow down the spammers.

Re:Hash Cash to stop UCE

[WuphonsReach]

And the basic problem with HashCash is that there is at least 1 order of maginitude in processing power among machines on the market.

So something that would take 30 seconds for machine A will only take 3 seconds for machine B. And 2 years down the road, machine C will do it in 0.3 seconds.

Also, you can't trust the originating machine not to lie about it's CPU power. As a result, honest brokers get burnt, while dishonest brokers get away with abuse (which basically means that everyone will lie even if their original motives were pure).

It's possible to get a signed certificate for free

[krico]

Thawte offers free e-mail certificates.

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

Hell no.

[MKalus]

I am just looking but I activly use at least 10 different emails plus some I only use occasionally, if I have to buy certificates for ALL of them I am going to go broke.

IF I need certificates than at least make them by domain, otherwise this is going to be expensive (though who knows, maybe it get's rid of things like hotmail for good).

HashCash is a better approach

[koreth]

This idea is way too much work and won't even solve the spam problem. A better approach would be widespread deployment of something like HashCash that makes sending large amounts of unexpected E-mail prohibitively expensive, but doesn't do the same to mailing lists or to individual unexpected messages.

AMTP?

[sharkey]

SMTP - Simple Mail Transport Protocol

AMTP?
Asshole's Mail Transport Protocol?
Antipasto Mail Transport Protocol?
Anaheim Mail Transport Protocol?
Asimple Mail Transport Protocol?
Advertising Mail Transport Protocol?

I proposed a different AMTP a little while back...

[bennomatic]

Mine stood for "Audited Mail Transfer Protocol". I've got a little information on it in THIS POST

Community CA

[austad]

Would it be possible to build a community CA? One where people sign up to receive a certificate, and then trusted members of the CA vote on whether or not to grant it. You could use the site to establish a huge web of trust. If someone started abusing their cert by sending spam, people could file complaints with the site and the trusted members could revoke their cert. It wouldn't even have to be a website type community, it could be a p2p app to eliminate hosting costs, and it would run continuously on one's mailserver. This way, it would receive notifications of revoked certificates immediately.

This solution obviously would not be perfect, but, it would definitely make it harder for the spammers to stay ahead of the game like they are now.

My thoughts... any opinions?

[joeykiller]

I guess this signing idea is good, but I still don't think it'd be an end-all solution to the spam problem.

Lately I've thought about this: I didn't start using Instant Messaging until six months ago. What I found interesting was that not only did I have to add my friends to my address book, but they had to accept my doing so, before any communication could take place at all.

If a technique like this had been implemented as a standard in mail transfer protocols, a lot of the spam problem would go away.

Of course, you'd have to sacrifice the option that strangers could send you mail, and corporation or private person who don't mind getting mail from strangers, should be able to say that "my inbox is open for all".

Would this be doable, or is the idea idiotic?

AMTP from a spammer's perspective

[Anonymous Coward]

The spammers will just continue their old routine:

• Signup at new ISP
• spam like hell
• eventually, get kicked by ISP
• Repeat

I fail to see how AMTP will solve this issue. If the ISP is reacting to your complaints, you don't want to block his mail server, do you? PS: No, I'm not a spammer :-)

Funny

[Darioush]

Yeah, and then microsoft could buy it

Viagra Gnomes Business Plan

[Anonymous Coward]

1) Get certificate
2) Accept cash from spammer, conviently fail to update next Windows patch
3) Laugh as spammer uses the certificate to blast away
4) Announce you were hacked, demand FBI investigate, and revoke certificate and get another
5) Back to step 2

The problem is that certificates just validate that the person who sent the email had access to a certain secret. That secret is just as secret as they want it to be.

What this will devolve to is a black market in valid, un-blocked (yet) certificates, and if you succeed then the price of an un-blocked certificate will go higher than the price of getting a new one, and you will fail.

Essentially, you will constantly be updating a revokation list and a certificate block list instead of list of IP addresses. You are still just updating a list of bad numbers which is never complete and always has false positives in it.

The false positives will come from the fact that larger ISPs will experiment with what allowable fraction of spam can get through without their certificate being blocked. You will always be faced with the choice, do refuse 10 innocent people's emails because their ISP has one occasional spammer who is trying to see if he can increase volume ? 100 ? 1,000 ?

Just because the numbers in your block list are certificates instead of IP addresses doesn't mean anything.

Re:creating and enforcing more strict SMTP helps t

[Anonymous Coward]

Because I use Road Runner residential class network access, your scheme will always block me as well, because I don't have access to the reverse DNS.

On the other hand if I use their smtp server I can't send mail for days at a time. I don't see why I should have to use their server anyway. Methods exist to distinguish spam from non-spam (according to whatever your definition of spam is) that have a lower false positive AND false negative rate -- look at the various "Bayesian" (most aren't technically Bayesian) filters. The HELO / reverse DNS technique is one that is known to be less accurate than other techniques; the only reason why people like it is because they don't pay in bandwidth for the spam attempts they never see.

Re:SMOC likes to thank the moderator

[Anonymous Coward]

Does SMOC have a hidden sid, mailing list, irc channel, yahoo groups, or newsletter to which I might subscribe ?

regulation of cyberspace by code

[ender's_shadow]

Labeling mail as "commercial," etc should decrease the amount of spam, yes? I'm assuming AMTP wouldn't have open relays

Rule #1

[taustin]

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.

How does it know what type?

[tedhiltonhead]

I read the Draft, and I see no provision for the user to specify what type of message he's sending. Surely the mail server cannot make a determination itself.

For everyone wanting mandatory digital sigs

[scrytch]

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

Mail servers make policy decisions all the time

[T-Ranger]

RBL's durring the SMTP phase, content filtering durring the SMTP phase, receive and filter with spamassassin. Mail servers inspect messeges and decide what to do with them based on content all the time.

Re:Mail servers make policy decisions all the time

[Ed Avis]

Yes, I know, but it hardly merits the description 'end-to-end'.

The pieces are in place, then!

[mcrbids]

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

Anybody here ever notice that Bind9 comes with support for DNSSEC?

It's much like a certificate, only issued by the name server, rather than some random third party.

The name server is responsible for telling the world how to get there - shouldn't it also be responsible for ensuring that you did?

price certificates high, not low

[firewood]

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.

Spammers lie!

[Anonymous Coward]

The optout/optin flag will be abused because every spammer says it operates an "opt-in" list because your email address came from a "partner" or "affiliate".

Re:It helps against faked "from"

[Alizarin Erythrosin]

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

You mean you'd actually want to receive email from AOL?

My own idea for authentication

[Shdwdrgn]

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.

Re:My own idea for authentication

[Shdwdrgn]

(grumble grumble html tags...)

Let's try that again. The header info I was trying to post is -
X-Authenticate: <MTA Key + Email Body Hash><Destination Address Hash>

Great idea,

[TCaM]

I'm sure the spammers would have their own community in no time.

Re:InstantSSL

[passion]

And they actually have decent customer service - perhaps implying that they would like their customers to return for future purchases...?

Boycott Verisign!

Re:It helps against faked "from"

[Anonymous Coward]

Oh please? Please can't we have the whole world blacklist AOL? :-)

Re:The certificates are for servers, not individua

[thedillybar]

This may save you a few bucks for your small operations. What about the LARGE ISPs that now have to hire an additional department to block hundreds of proxies used by a single spammer? They're now spending more money, and in turn passing the cost to their customers (i.e. YOU). So what? You're still ahead. Everyone else is behind.

Re:It helps against faked "from"

[valdis]

No, I'm speaking as the hypothetical person in charge of an ISP. I may not want to receive mail from AOL, but I can't afford to piss off my users who want to get mail from their Aunt Tillie.

Explain to them that they can't get mail from AOL because some other company called CA-something sold a wazziz to somebody in Zimbabwe who misused it? And AOL wasn't even involved in the slightest? But you can't get mail from there anymore?

Yeah. Right. Dream on. And pass me that pipe, I'm trying to forget the last time I had to explain this sort of thing to users, and it *WAS* AOL's screw-up. Maybe if I take enough hits from that pipe, I won't hear that sucking sound of subscribers leaving for an ISP that actually delivers the mail....

Re:It helps against faked "from"

[tricorn]

The only legitimate reason for faking a From: address is so that replies go back to the correct mailbox while submitting them through a different mail server. It seems to me that the first step has to be to pressure all mail client and mail server programs to support using the MSA protocol/port. Sendmail has this enabled by default, I believe, and many mail clients can use it as well. If it was made pretty much universal and supported, the necessity of submitting to a local SMTP only (or using hideous kludges like SMTP-after-POP) would be eliminated.

Use all the different e-mail addresses you want, as long as you send them via a mail server that is authorized by the domain specified in the "From:" (or at least "Sender:") field. AMTP or something like it could be used to validate that. People who want to run their own mail servers can still do so. If something like AMTP becomes the standard, and you don't want to get your own certificate, you could still make arrangements with your ISP to deliver mail through their server, authenticating your server using their own certificates, knowledge of your IP address, or whatever.

nothing will suddenly fix anything . . .

[werdna]

The CFAA actually does deter a fair amount of hacking, as do laws governing murder. As a civil lawyer who does quite a bit of litigation in this arena, I can tell you that CFAA litigation is a tremendously powerful tool. Of course, murder is criminal, and wrongful death and assault are civily actionable, yet murder persists. Does this mean these laws are useless? probably not.

Everybody's spam mix is different, but the spam I see tends to come from folks trying to make quick bucks by collecting money with "legitimate" but stupid businesses, rather than by various means of fraud. The criminals are likely to persist no matter what, I agree -- but it would be nice to deter those who are not, and thereby reduce the noise and volume of spam, and with it, much of the harm.

Nothing will "suddenly fix everything," but the proposal suggested above would be both constitutional and fairly effective in improving the situation. I commend it to your attention.

more accountable than you might think . . .

[werdna]

Because spamming slime have no problem at all with forging anything they want. Without accountabillity, nothing changes.

You seem to think I am concerned about trailing people by means of forensic analysis of the e-mail. I am not.

Ultimately, some commercial interest is involved, and someone is receiving the money -- there is an account into which funds are transferred, and therein arises the accountability. By making civilly responsible those folks in the money chain, we obtain leverage to find those they support and pay -- and by making criminals of all of them, we either deter them or turn the less bad ones on the worse ones. As with all crime and bad acting . . . .

Nothing is a panacea. But nothing at all is nothing at all. I'd rather do something that might work somewhat better than the status quo, without invading meaningful civil liberties in the process.

Re:more accountable than you might think . . .

[buss_error]

You said:
Ultimately, some commercial interest is involved, and someone is receiving the money -- there is an account into which funds are transferred, and therein arises the accountability.

And I said before that:
Silly as this all seems, spamming is big bucks. Remove the money, remove the problem. But you can't do that by suing all over the globe. You will do that when you stop lying, stealing scum suckers from being able to contact anyone in the first place.

As for your point in violating civil liberties, see my sig. I've used the same one for quite a while.

Re:The certificates are for servers, not individua

[jmorris42]

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

Which is the entire point. Your ISP and my ~3000 system are supposed to get the hell off the net and leave it to AOL, MSN, Earthlink and few other large players. This is just another attempt at that and hopefully it will fail. It won't do a damned thing to stop spam, that is for sure. Anyone believe any of the DSL/Cable providers will do one damned thing extra to stop their users from canning the pink meat like substance? Now does anyone think their will be a single cert revocation on one the big players for allowing spam to continue? Didn't think so. Nothing to see here, move along.

The quest for free digital certificates is over ..

[nomad42]

Get your certificate here for free:
http://www.SwissSign.com/

go to the MySwissSign section, open a new profile ("john_a.doe") and get any number of certificates ("Bronze" type).

enjoy!

Hm

[Anonymous Coward]

This is just blahblahblahblahblahblahblahblah.

Re:The certificates are for servers, not individua

[rew]

I play a very small ISP. Paying $100 for a certificate is a significant investment. (which I HAVE to have even if I just need to recieve Email on my server!)

My clients generally don't send Email through MY server. So they will be connecting to their dial-in or broadband provider and Emailing (for example) "From: slashdottroll@bitwizard.nl". (will the spammers pick this up? Let you know in 12 months... ;-)

I can see the small ISPs here accept that. Phone them, have the guy on the phone hack the asendmail config file, done! I can see the larger ISPs accept it as long as you host your domain with them. They can automate the config file generation. But as a small ISP without dial-in services, I'll be forced out of business: none of my clients get to send Email from their own domain anymore....

why?

[werdna]

Silly as this all seems, spamming is big bucks. Remove the money, remove the problem.

This is precisely my point.

But you can't do that by suing all over the globe. You will do that when you stop lying, stealing scum suckers from being able to contact anyone in the first place.

If you say so, but really, all you have done here is say so. Being able to sue people has a remarkably palliative effect on the extent to which they are willing to stick their necks out -- particularly if they have money. My view is that I don't need to get the "scum suckers," per se, to stop them, just the more traditional people with the money who are funding them.

Skepticism about Spam Bandwidth Consumption

[billstewart]

I have trouble believing that 40% of your bandwidth is spam-related, unless you're a niche ISP that focuses on email services and doesn't provide basic IP access to your users.

Spam as a percentage of email traffic is certainly high (40% seems low, actually :-), but I use more bandwidth just reading Slashdot most days than I use receiving all my home email, which is about 80% spam. (Work email doesn't count - it's full of Microsoft attachments, but doesnt get much spam.)

On a typical day, I probably get about 200 emails, and they're under about 5KB each for text or html, and most virus emails are also under about 10KB. Some of the spam has JPEGs, and I'm not sure how big those are, but most of it doesn't. So that's maybe 1MB of spam - not small, but the slashdot front page is about 60KB, and the page for this article is about 393KB (plus some cacheable images), so my day's spam is like reading 2-3 Slashdot articles, or 8 sites like the Google News front page (60kb text, 60kb small GIFs), or a total of 20-50 non-small GIFs, or downloading one minute of music.

Low Priority Spam-bounce mail?

[billstewart]

I meant to add this - is there any way to set spam-bounce mail to a lower priority, so it only soaks up bandwidth that's not otherwise busy? The trick is how to do it without interfering with real bouncemail, which is relatively high priority.

Re:The certificates are for servers, not individua

[bweinman]

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.

You have described how many current RBLs work, which is also why spammers now use a network of millions of hijacked desktops. It's a moving target.

AMTP associates certificates with reverse-DNS so that histographic ideas like your suggestion can be effective.

--Bill (author of AMTP)

Re:The certificates are for servers, not individua

[warpSpeed]

AMTP associates certificates with reverse-DNS so that histographic ideas like your suggestion can be effective.

I like the idea and generally agree with you. If we can get everyone to do it... I guess you could get an automatic reduction in your spam score coming from an authenticated IP address. I think that is what we can hope for to start with.

It is nice to see someone attacking the problem in a nice and novel way to. Kudos to you!

Re:creating and enforcing more strict SMTP helps t

[HTD]

Because I use Road Runner residential class network access, your scheme will always block me as well, because I don't have access to the reverse DNS.

Well, all providers i know here in europe at least have setup domainnames for all the IPs they own. So what your mailserver needs to do is send a HELO with that domainname. Or another option is to send out a HELO [123.123.123.123] (your IP in brackets) which is valid too. This way i can check if your HELO domainname/IP matches the name/IP of the connecting machine, nobody forces you to use a domain-name.

filters are all nice and good, and i use them but as you correctly mentioned - identifying spam at smtp level lowers bandwidth usage a lot. This may not be a problem for US citizens but not everybody has access to unlimited traffic connections...