Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Spam The Internet

AMTP as an Alternative to SMTP 328

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."
This discussion has been archived. No new comments can be posted.

AMTP as an Alternative to SMTP

Comments Filter:
  • Yes, but (Score:5, Funny)

    by Anthem.uxp ( 646163 ) on Monday September 01, 2003 @06:33AM (#6843639)
    does it involve the Evil Bit ?
    • Re:Yes, but (Score:2, Interesting)

      by Eunuchswear ( 210685 )
      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!.

  • Its a good idea (Score:5, Insightful)

    by blaster ( 24183 ) on Monday September 01, 2003 @06:34AM (#6843646)
    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 (Score:5, Insightful)

      by Ed Avis ( 5917 ) <ed@membled.com> on Monday September 01, 2003 @07:17AM (#6843768) Homepage
      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 (Score:5, Interesting)

        by dnoyeb ( 547705 ) on Monday September 01, 2003 @08:13AM (#6844006) Homepage Journal
        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.
      • 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.
        • 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:Its a good idea (Score:4, Informative)

        by Zeinfeld ( 263942 ) on Monday September 01, 2003 @11:23AM (#6844891) Homepage
        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 (Score:5, Insightful)

      by AftanGustur ( 7715 ) on Monday September 01, 2003 @07:28AM (#6843817) Homepage


      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 (Score:5, Insightful)

      by Omnifarious ( 11933 ) <`eric-slash' `at' `omnifarious.org'> on Monday September 01, 2003 @08:28AM (#6844075) Homepage Journal

      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 (Score:2, Interesting)

      by Eunuchswear ( 210685 )
      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 (Score:5, Interesting)

      by arivanov ( 12034 ) on Monday September 01, 2003 @08:46AM (#6844139) Homepage
      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).
  • Free Certificate (Score:5, Informative)

    by CountZero007 ( 39755 ) on Monday September 01, 2003 @06:35AM (#6843649)
    Try http://www.cacert.org/ as a free Certificate Authority...
    • Re:Free Certificate (Score:3, Informative)

      by Komarosu ( 538875 )
      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...
      • 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 (Score:5, Informative)

        by Shadowspawn ( 24914 ) on Monday September 01, 2003 @10:03AM (#6844511)
        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.

  • by oolon ( 43347 ) on Monday September 01, 2003 @06:36AM (#6843653)
    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
    • by Anonymous Coward on Monday September 01, 2003 @06:47AM (#6843679)
      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.
    • 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).
    • 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
    • by hattig ( 47930 )
      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 whils
  • by njet ( 189864 ) on Monday September 01, 2003 @06:37AM (#6843655) Homepage
    So why is this SO different from using TLS ?

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

    • by Anonymous Coward on Monday September 01, 2003 @07:02AM (#6843714)
      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!
    • by geirt ( 55254 ) on Monday September 01, 2003 @07:06AM (#6843731)
      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 [bw.org]:
      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 ....

      • by bourne ( 539955 )

        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 [faqs.org] 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 proj

  • 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.
    • by Rhinobird ( 151521 ) on Monday September 01, 2003 @07:21AM (#6843782) Homepage
      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.
    • by ColdGrits ( 204506 ) on Monday September 01, 2003 @07:22AM (#6843787)
      "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".
    • by Gunzour ( 79584 ) <gunzourNO@SPAMgmail.com> on Monday September 01, 2003 @07:45AM (#6843891) Homepage Journal
      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.

      • 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.
  • by Billly Gates ( 198444 ) on Monday September 01, 2003 @06:40AM (#6843662) Journal
    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.

    • by StrawberryFrog ( 67065 ) on Monday September 01, 2003 @06:49AM (#6843687) Homepage Journal
      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.
    • 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, w
    • 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 th
  • by 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.

  • by Anonymous Coward on Monday September 01, 2003 @06:43AM (#6843669)
    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.
    • 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.

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

  • Security concerns (Score:4, Insightful)

    by fr0z ( 658466 ) <fr0z AT myrealbox DOT com> on Monday September 01, 2003 @06:43AM (#6843673) Homepage
    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.
    • > So it would be interesting if implemented with
      > legislation rather than without; that way there
      > is a serious disincentive for spammers who manage
      > to subvert the policy.

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

  • Finally! (Score:4, Funny)

    by fuzzix ( 700457 ) <flippy@example.com> on Monday September 01, 2003 @06:48AM (#6843681) Journal
    I reckon we can use this system to help Microsoft and AOL track those unsolicited forwards to maximise their donations to sick infants...
  • Certificates (Score:5, Interesting)

    by h0tblack ( 575548 ) on Monday September 01, 2003 @06:51AM (#6843692)
    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 (Score:3, Interesting)

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

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

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

      I am all for improving mail, but look at what happened with signed certs on http. I do not want to see something like that start again. Not unless there is an "
  • 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.
    • 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 the
      • by esj at harvee ( 7456 ) on Monday September 01, 2003 @08:14AM (#6844012) Homepage
        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
  • Good start (Score:4, Interesting)

    by orv ( 398342 ) on Monday September 01, 2003 @06:56AM (#6843703) Homepage
    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.
  • Nice Idea (Score:2, Insightful)

    by Goo.cc ( 687626 ) *
    but anonymous communication via e-mail is probably dead with this idea. I wonder if the price is too high.
    • 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.
  • Open to abuse (Score:5, Interesting)

    by Twylite ( 234238 ) <[twylite] [at] [crypt.co.za]> on Monday September 01, 2003 @07:10AM (#6843744) Homepage

    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 [cr.yp.to] 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 (Score:5, Interesting)

      by fyonn ( 115426 ) <dave@fyonn.net> on Monday September 01, 2003 @07:42AM (#6843878) Homepage
      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 :)
      • '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 f

        • 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

    • 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

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

    Tagged as commercial, in the bin if goes!
  • 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 soluti
    • 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.
    • by Gunzour ( 79584 ) <gunzourNO@SPAMgmail.com> on Monday September 01, 2003 @08:18AM (#6844030) Homepage Journal
      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.
  • by 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...
  • by amcguinn ( 549297 ) on Monday September 01, 2003 @07:19AM (#6843772) Journal

    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 [slashdot.org]).

  • Email will be... (Score:2, Insightful)

    by 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).
  • 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 botto
  • by taliver ( 174409 ) on Monday September 01, 2003 @07:27AM (#6843807)
    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.
  • 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

  • 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

  • Won't work (Score:5, Insightful)

    by Fefe ( 6964 ) on Monday September 01, 2003 @07:53AM (#6843917) Homepage
    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.
    • 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 w

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

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

  • by DrXym ( 126579 ) on Monday September 01, 2003 @08:18AM (#6844025)
    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.

  • by cluge ( 114877 ) on Monday September 01, 2003 @08:23AM (#6844050) Homepage
    As I recall djb [cr.yp.to] had an alternative to SMTP called Internet mail 2000 [cr.yp.to]. 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
  • . . . 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 n

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

  • 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?
  • Breakdowns (Score:4, Insightful)

    by Todd Knarr ( 15451 ) on Monday September 01, 2003 @10:10AM (#6844542) Homepage
    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.
  • Rule #1 (Score:3, Insightful)

    by taustin ( 171655 ) on Monday September 01, 2003 @01:44PM (#6845473) Homepage Journal
    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.
  • by scrytch ( 9198 ) <chuck@myrealbox.com> on Monday September 01, 2003 @01:52PM (#6845501)
    ... 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...
  • by firewood ( 41230 ) on Monday September 01, 2003 @02:24PM (#6845596)
    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.

  • by Shdwdrgn ( 162364 ) on Monday September 01, 2003 @04:11PM (#6846040)
    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.

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...