Slashdot Mirror


Email Authentication Schemes - Friends or Foes?

jtprice writes "At a time when spam levels have exceeded 80%, there's growing momentum behind Microsoft's email CallerID, the SPF effort, Yahoo!'s DomainKeys, and the IETF's new MARID Working Group initiatives to address various email abuse problems including spam, joe-jobbing, phishing, and so on. Sendmail has already implemented DomainKeys and CallerID. 10,000+ domains have turned on SPF now. Where the heck are we going with this? Are these efforts at cross purposes, confusing at best or likely to be consolidated? Seems to be less about the end of spam and more about the end of open, uniform, standards-based email as we know it. Apparently the people behind these initiatives are getting together for the first time for something called the Open Email Accountability Symposium next month, at the Inbox Email Conference in San Jose, with the intent of outlining their proposals and answering questions. Any thoughts about all of this, or hard questions that should be asked of these people? Is the email dilemma creating just another monopoly opportunity to force email into proprietary territory?"

54 comments

  1. It's worth it... by danielrm26 · · Score: 3, Insightful

    "Is the email dilemma creating just another monopoly opportunity to force email into proprietary territory?"

    Perhaps, but this doesn't make it a bad idea. Any good idea or technology can be taken advantage of; that in itself shouldn't keep those with good intentions from trying to bring about change for the better.

    --
    dmiessler.com -- grep understanding knowledge
    1. Re:It's worth it... by alchemistkevin · · Score: 2, Insightful

      you might say that today, but i'm sure you'll be shouting the loudest to put it under GPL when microsoft or other 'perceived' monopolies get away with it.

    2. Re:It's worth it... by Anonymous Coward · · Score: 0
      Any good idea or technology can be taken advantage of; that in itself shouldn't keep those with good intentions from trying to bring about change for the better.

      Except IRC. I think IRC has officially been written off as unsustainable because of all the abuse and DDoS attacks that fall upon servers. Try finding a Dedicated Server provider that will allow you to use an IRC *client* from the box, much less run an ircd server on your dedicated server. I was all ready to sign up with ServerMatrix under I realized their IRC ban applied to both clients AND servers. Their pitiful reason was "our network is more secure without IRC and the problems it brings."

      How long will it be before companies state the same thing about SMTP or NNTP? Sorry, you can't use FTP anymore, it is against our AUP because too many people have abused it in the past to store warez, therefore it is a bad protocol. Sorry, we won't allow mail servers because spam causes an unnecessarily large drain on our bandwidth.

  2. This would have been first post.. by slittle · · Score: 2, Funny

    ..but my corporate overlords got hit by Sasser and I couldn't get a new certificate :(

    --
    Opportunity knocks. Karma hunts you down.
  3. It still won't work by Anonymous Coward · · Score: 2, Insightful

    Because millions of small-company and household e-mail servers will never have the funds to implement any proprietary system. Make it public domain, and it will be worse- the spammers will just hack it.

    1. Re:It still won't work by Nasarius · · Score: 4, Insightful

      Right. Just like they hacked Apache or PGP or SSL or...
      Open standards and peer review are profoundly *good* things.

      --
      LOAD "SIG",8,1
    2. Re:It still won't work by StateOfTheUnion · · Score: 0, Troll
      Actually, I think it might happen the other way around, make it proprietary and from a big target like Microsoft, and your asking for the system to be hacked . . . Proprietary solutions from huge companies are irresistable targets for hacking.

      Float it under the radar as open source, encourage peer review and you may have something that would be hackers contribute to rather than destroy.

      Most email currently goes through Apache . . . I think that the open sorce community has done a pretty good job of creating the email server of choice. I think that they're probably the right group to also make it more secure.

    3. Re:It still won't work by Electrum · · Score: 2, Funny

      Most email currently goes through Apache . . . I think that the open sorce community has done a pretty good job of creating the email server of choice.

      Umm...

    4. Re:It still won't work by jonesvery · · Score: 2, Informative

      Most email currently goes through Apache . . . I think that the open sorce community has done a pretty good job of creating the email server of choice. I think that they're probably the right group to also make it more secure.

      To clarify someone's "ummmmmm" comment -- this is some sort of weird troll, right?

      The Apache Software Foundation does support a project known as James, a "pure Java SMTP and POP3 Mail server and NNTP News server, but ummmmm...well, not a whole lot of people use it.

      Are you perhaps thinking of qmail or postfix?

      --

      * * *
      It is a dada story -- it has no moral.

    5. Re:It still won't work by perlchild · · Score: 1

      Most likely he's one of those people who think forms that send email are the dominant form of email now, or that a web interface controlling a mailman or other mailing list controller, gives apache "control" over the flow of mail.

      Or else, it was just a typo over "email" meaning "http traffic". Because of greater fragmentation of the smtp server area, and greater specialisation of some of the parts, as well as several interpretations of much more complex standards(IMAP is certainly a standard with an awful lot of variance built it), there is no smtp server as dominant as apache httpd, nor would that server cover as much of the transaction between the client and the server.

      --
      You pays your money and you make your choices

    6. Re:It still won't work by Anonymous Coward · · Score: 0

      "Under the radar" is useless in the anti-spam world, because you are going to have to get buy-in from major ISPs and webmail providers.

  4. no real solution on the orizon by AnalogFile · · Score: 3, Insightful

    I've been thinking about the problem. And have looked around for the different proposals. There's been a mailing list for ng mail with many interesting ruminations. But then it was sinked with spam :-(

    IMO there main alternative is:
    1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
    2) a completely new and different system. Redesigned from scratch.

    Obviously a solution is not a solution if it may have a false positive (block nonspam).
    False negatives are just a matter of efficiency.

    Methink option 1 is not possible. And this has the added bonus of giving us the chance for a visionary change. But it's unclear if we can afford the time it takes. As the problem is really becoming urgent (much more urgent than the 32bit limitation in IP adress space. Expecially because NAT is addressing it very well.)

    There are MANY proposals that use SMTP and add up on the requirements actually ruling out cases that were originally legal. These I really think should be avoided. But I'm affraid that's were many will likely go because they are fast to deploy.

    1. Re:no real solution on the orizon by CatLord42 · · Score: 5, Insightful

      IMO there main alternative is:
      1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
      2) a completely new and different system. Redesigned from scratch.

      Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.), and there will still be ways to get around any protections we could add to SMTP.

      Unfortunately, I think it will take some major overhauling of the Internet and its core protocols to solve this problem. And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.

      So, what's worse, loss of bandwidth, over-burdened mail servers and everyone spending time deleting junk out of their inboxes, or everyone spending a significant amount of money, users for new e-mail programs, companies for the same programs, new mail servers and routers, ISPs and backbone providers for expensive new infrastructure, and none of it possible until all the protocols are reworked, let's say, five years from now?

      --
      Meow. Now!
    2. Re:no real solution on the orizon by AnalogFile · · Score: 4, Interesting

      Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.)

      Not exact. If we are revamping there's no need to sit on TCP. It may be TCP or UDP or something completely new. Or it may be even just be a non problem.
      - If the protocol assumes a connection and does not depend on it being anything in particular (technically: if it's an appllication level protocol), than it'll sit on any connection oriented protocol. That's exactly what the ISO layering is supposed to mean.
      - It is possible to design a completelly new connection layer protocol. TCP is having it's own problems. True most of these have been addressed with a handfull of extensions. Reno is good and Vegas is even better. But big speed*RTT links are still problematic. And links are going to become much faster and with possibly bigger RTTs. We should not abandon TCP. But maybe we could start thinking alternatives.

      and there will still be ways to get around any protections we could add to SMTP.

      There'll always be ways to get around anything, probably. Down this line of thinking there's no solution at all. But we may come to a point where getting around is not worth doing.

      I think it will take some major overhauling of the Internet and its core protocols to solve this problem.

      Ageed. That is exactly the point in my post. But if we take that lane, we may get extra benefits. Mail-ng need not just be mail. We may think messaging here, instead of mail. Mailing lists can be designed in upfront. And news too. Maybe even chatting and instant messaging. And did you notice people is now using SMTP to do what FTP was designed for (remember FTP supports push and even sidewise transfers, even if today it's mostly used in pull mode)?

      And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.

      Maybe. Maybe not. We should keep those possible consequences in mind. Lots of work in SW development may be a non problem (not for the F/OSS community, at least. I do not care what that means for an individual company that's not going to share). Lots of equipment I doubt. If we can sit on IP and care not what version of it is below us, than the routing infrastructure need not change. The firewalling/natting/tunneling part may need some fixes. But these are mostly SW and generally very close to the endpoints, not really a big deal if we are doing a revamp. Expenses? Again: SW upgrade at the endpoints is not a big cost. Not if you are on the sharing side of the fences. It is not zero (not for large companies with thousands of servers and more clients, for example). But it needn't cost more than any other SW upgrade.

      none of it possible until all the protocols are reworked, let's say, five years from now

      This sentence is the one I agree upon. That's what I worried about in my post. This may take time. And the problem is now so much urgent that people may be unwilling to wait. The worse that can happen is a partial solution. It would slow down a revamp (NAT slowing IPv6 is an example. And we risk the mail 'solution' is much worse than NAT is).

    3. Re:no real solution on the orizon by T-Ranger · · Score: 2, Insightful
      If the protocol assumes a connection and does not depend on it being anything in particular (technically: if it's an appllication level protocol), than it'll sit on any connection oriented protocol. That's exactly what the ISO layering is supposed to mean.
      Prehaps that is what it is supposed to mean, but two things
      - IP and friends came out long before ISO and their layer model. IP is based on the DOD model; and while DOD has less layers they dont exactly match up. Not really important, however
      - SMTP uses lots of things that assume IP. HELO/EHLO wants a hostname, and usually one that can be resolved to the address that the connection is from. From (in SMTP), From, To, CC, etc in RFC822 expect either UUCP routes, or IP hostnames. Any MUA written after 1990 would likely get confused if presented with a UUCP route.

      New stuff
      Cisco came out with IPv6 around 3 years after everyone else did, including Microsoft (Research). While a p120 with Linux is just fine in your apartment, and Cisco has competitors, Cisco not supporting something (relevent to their product line) means it wont become wildly used.
      - You don't necessaraly need new hardware, but routers are heavily optimized for dealing with IP sized data chunks.
      Upgrading endpoints v. backbones: lots of people are running IPv6 over v4 tunnles. Im willing to bet there are exactly 0 production, commercial, IPv6 backbones. New things happen on the edges.

      Five years is a very short period of time. The reason why IP is in use is because it works. There are more then a few system that are "better" on paper. IP has been proven to work, and is the only protocol to acheive its level of sucuess... v6 is in the process of being proven (and refined)

    4. Re:no real solution on the orizon by Ramses0 · · Score: 2, Interesting

      Check this one:

      http://cr.yp.to/im2000.html ..."Internet Mail 2000" ... no really. :^) Basically, you (user) don't receive the email. You receive a notification: "your email is available". Now: you have to download the email from the site that notified you.

      Imagine: I am a spammer. I must now host a server which has the capability to receive $millions of hits from all my wonderful spam-receiving customers. This is the first thing which begins shifting the burden of sending of email back onto the sender.

      Obviously it's not perfect, if I were a spammer, I'd probably have all my malware-infected robots be the hosts for sent emails. Buuut... they'd only be active when that malware-infected computer is on. Notifications could obviously be cheaper to send (b/c it's not so bandwidth intensive, just "hey, joe@joe.com has an email available at bob@spammer.com/msgid/12345/hash-password/a1e2ff" ...but, this scheme has the potential to conserve enormous amounts of bandwidth internet wide (mail is "fetched if desired", not "sent no matter what"). If too many reports of spam are coming from a particular server, blacklist that server. Boom. There are a finite # of IP addresses on the internet, and forcing a spammer to maintain servers so their messages are successfully delivered should eventually drive them further and further out of address space.

      This speaks really to "trust v. ip address", how much do you trust a residential DSL IP to deliver mail? (not much). How much do you trust Yahoo Mail's IP? (a lot, all kidding aside).

      So, what's the transition? Since it is such a drastic change (rather than sending mail, sending notifications), and directly impacts $zillions of installed mail clients, I couldn't wrap my head around a valid transition path until it hit me ... use email! ;^)

      Since most mailers nowadays support highlighting of http links, just send "Subject: regular", but make the body: "Internet Mail 2000 message. http://sending.server.com/msg/12345/hash/abc123" ... totally painless transition (apart from vulnerable browsers), until mail programs can be re-architected to fix it. ( if: is_im2k(): fetch( $url_from_message )

      Anyway, think about it.

      --Robert

    5. Re:no real solution on the orizon by smcv · · Score: 2, Insightful

      IM2000 does sound like a good idea; it's basically the way I send inconveniently large attachments, in fact (zip, upload to temp directory on web server, send an email "covering note" with the URL, ask recipient to let me know when they've downloaded the file so I can delete it).

      The immediate down side I can think of is that the sender knows (by observing their web server logs) that you received and read that message (or at least that you received it with a POP3-equivalent offline mail reader, which would presumably just have to download everything that wasn't blacklisted). This is possibly a good thing (debatable) if it's legit email, but is a bad thing if it's spam (the spammer now knows that joe@joe.com is a valid address which is read by a human).

    6. Re:no real solution on the orizon by SagSaw · · Score: 3, Interesting

      Imagine: I am a spammer. I must now host a server which has the capability to receive $millions of hits from all my wonderful spam-receiving customers. This is the first thing which begins shifting the burden of sending of email back onto the sender.

      The problem with this idea is that, on a per e-mail basis, spammers actually need fewer resources than non-spammers. Compare a spammer whose domain sends 1 Million e-mails a day, and a legitimate domain who also sends 1 Million e-mails a day. For the legitimate domain, most of the e-mails sent will be unique, most will be read, and it is probably vitally importatnt that the readers be able to access the sending server at all uptimes. This means the legitimate domain must maintain a mail server which can store millions of messages, which has a very fast connection, and which has a very high availaibility. The spammer, on the otherhand, is going to send out many copies of the same message, only a few of which will actually be read, and really doesn't care if his server is down for a few hours (after all, the same suckers who read the e-mail the first time will probably read another spam sent to their address). As a result, the spammer can get by with much more basic hardware. Which brings us to the second point:

      if I were a spammer, I'd probably have all my malware-infected robots be the hosts for sent emails.

      Here we have the basic hardware. Since the spammer doesn't need much storage, the user won't notice their computer hard-drive is filling up. All they will notice is that (if the spammer is successful) their connection is slower than normal. This will probably be blamed on the p2p software of the week the user's teenage daughter installed.

      --
      Come test your mettle in the world of Alter Aeon!
    7. Re:no real solution on the orizon by AnalogFile · · Score: 2, Interesting

      HELO/EHLO wants a hostname, and usually one that can be resolved to the address that the connection is from

      What about this ?

      From (in SMTP), From, To, CC, etc in RFC822 expect either UUCP routes

      What about this ?

      Of course those links may be wrong. I'm no big expert. Surely they seem convincing.

      Cisco not supporting something (relevent to their product line) means it wont become wildly used

      This is sadly true. And that's probably a sign CISCO should either make an extremely strong public commitment into early availability (even before the standard is actually a standard) of new protocols or be ready to face antitrust the way MS is doing. Or both. And wether the aforementioned commitment is done making the platforms totally open or investing in-house for development that may never turn out to be required is not my problem (but I have an opinion).

      New things happen on the edges.

      Amen!

      Five years is a very short period of time

      True. I did not make that number. Just refused to comment. But since we are at it: I think that 10 to 15 years for the new generation mail infrastructure is more likely. And that's exactly one of the problems as many will not be willing to spend 4 or 5 years just for preliminary talks. They want spam killed now. And will, sadly, be happy with half baked (non)solutions.

    8. Re:no real solution on the orizon by T-Ranger · · Score: 1
      FGA: Perhaps they are correct. Perhaps SMTP servers should be less anal about HELO/EHLO's. But many are, and we are talking about reality: how things actually are, not what the standard says, or what a better standard would be... Part of their argument is that given the state of the world, neither the SMTP client or server has a compleate view of reality, so judging the peer based on their view of reality is flawed... If we are building a replacement to IP, then we want to build one where peers can have a valid sense of reality, no?

      On addresses: looking at '821: yep, pretty liberal on what it accepts as an address. But, same argument as above; while (almost) anything is valid under 821, many MTAs and MUAs would likey get confused if presented with anything that a laymen wouldnt recogonized as an email addr.

      My point still stands: while in theory SMTP could run over things other then IP, and for that matter carry things that are not 822 messages, for 15 years it hasent, and current implementations make assumptions based on the set of {IP, SMTP, 822}.

      Cisco is very popular. But their popularity has yet to reach monopoly status. There have viable competitors. While there are more then a few Cisco propritatory protocols, generaly speeeking, they came out before a industry standard did (LAN trunking, VLANs over trunks.....). When the standard comes out, Cisco generally supports it. (even if in the case of IPv6, rather slowly). So they do support standards, before they exist, in a sense. It is entirely possible to do networking things without using Cisco products, without compromise. The same can not be made about Microsoft (doing desktop things).

    9. Re:no real solution on the orizon by mr3038 · · Score: 1
      The immediate down side I can think of is that the sender knows (by observing their web server logs) that you received and read that message [...] This is possibly a good thing (debatable) if it's legit email, but is a bad thing if it's spam (the spammer now knows that joe@joe.com is a valid address which is read by a human).

      Eh? Just because somebody or something goes to fetch the "sent mail" doesn't mean that the mail is read by human. I don't care if the message is send directly to me or via some hosted server, I still won't be reading all the mail by myself -- some kind of filter that reads through the content is going to do some sorting if not anything else. A filtering program already reads all mail sent to me before I read it, and if it's a clear spam, the sender will be informed that "the user account doesn't exist" and the mail will be stored to /dev/null.

      --
      _________________________
      Spelling and grammar mistakes left as an exercise for the reader.
  5. Spam Filters by Vokbain · · Score: 1, Interesting

    I think spam filtering should be left up to the user.

    There are plenty of client side systems that work well; I use Apple's Mail. Maybe 2 spams a day gets through to my main inbox (out of several hundred incoming spams a day).

    1. Re:Spam Filters by Vokbain · · Score: 0

      It seems I spoke too soon. A good 20 spams just got through my filter. >=(

  6. Off topic, but... by Nasarius · · Score: 3, Insightful
    Expecially because NAT is addressing it very well.

    No, no it's not. NAT is a quick-fix that just complicates matters.

    --
    LOAD "SIG",8,1
    1. Re:Off topic, but... by AnalogFile · · Score: 1

      NAT both complicates and simplify matters. It depends. From the point of view of keeping people connected in a 32bit adress space it's doing a hell of a good job. From the point of view of IPv6 deployment ... surely it did slow that down. But that's exactly because it's doing well. Of course there also are many other aspects to consider. But this is nother story.

    2. Re:Off topic, but... by Nasarius · · Score: 1
      connected in a 32bit adress space it's doing a hell of a good job

      Oh? Try using VPN a lot and pulling your hair out because of address space collisions.

      --
      LOAD "SIG",8,1
    3. Re:Off topic, but... by AnalogFile · · Score: 1

      True. But without NAT all the hosts that today are on reserved adress space (you only get collision on those) would just be off the internet. So do it. Disconnect all the hosts that have not a public IP or get public IPs for all the hosts. And then go VPN. I'm pretty sure you'll miss NAT as soon as you realize you are not going to get sufficient IPs.

      Yes, I know. There are providers with routing that is not sufficiently transparent to let you VPN even between public IPs. But it's mostly broken configuration in their net. And ... many of those would not be on business at all if they really had to get a public IP for everithing.

      As I wrote: NAT is doing well in having many clients connected despite 32bit space. So well that the real solution (IPv6) deployment is affected.

    4. Re:Off topic, but... by man_ls · · Score: 1, Flamebait

      We could solve the IP allocation problem by deallocating the space from countries that abuse their connections and placing them in a data embargo.

      IANA should have the authority to reallocate addresses as a method of punishment. I.e., deallocate all of Nigeria's address space.

      All of Africa, and most of Asia, for that matter.

  7. Dude, what are you smoking? by bergeron76 · · Score: 1

    What per chance would lead you to the conclusion that a "single" standard is a "proprietary solution"?

    Are you paranoid?

    The proposed solutions are [for the most part] standards based and they're also "open" in nature.

    Personally, I'm going to orient my servers toward the IETF/Marid standard; but you have the "freedom" to choose and implement whichever standard you choose.

    The fact that a pseduo-"standard" is being settled on in this realm is progress (in my opinion).

    --
    Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
  8. The question answers itself by kimba · · Score: 2, Insightful

    The person that asked the question provided the answer. The IETF MARID working group is designed to take all the existing proposals, find the best, and settle on it.

    This article is just making something out of nothing.

    1. Re:The question answers itself by AnalogFile · · Score: 1

      What if the best it finds is not a good one? This is the question.

  9. The problem has no solution ... by whoever57 · · Score: 1
    unless we change our expectations for email.

    What do we expect:

    1. To be able to send email from anywhere

    2. To be able to use various "from" addresses, irrespective of from where we are sending.

    3. To be able to cheaply register new domain names. The problem can only be solved if we accept limitations on how we send email.

    The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal (an *.org.uk domain is about $3-$4).

    Furthermore, even a medium size company cannot possibly predict all the sources of email if people are allowed to send from their home ISP.

    So, we could force people to pretty much always use their company's mailserver to send emails (requiring mass deployment of SASL or other solutions), yet this will not stop the spammer getting a cheap throw-away domain name and using that.

    So, I really think that our expectaions of email will have to fundamentally change, or we need to use plan b:
    A mix of technical and legal solutions to kill spam.In other words, kill the root cause of the problem.

    --
    The real "Libtards" are the Libertarians!
  10. Client-side filtering should be last step by TBone · · Score: 3, Insightful

    The problem is, in many places, people still pay per quantity of bandwidth or time online. Saying "filter it at the client" doesn't do anything to stop the spam from being sent to the user, and still requires the user to retreive and parse the message before deciding it's spam and filing it in the circular bin.

    No, client-side spam filtering should be the last line of defense against spam. Spam should be killed off before it ever reaches a mailbox, final or intermediate, by the servers that handle the mail.

    --

    This space for rent. Call 1-800-STEAK4U

    1. Re:Client-side filtering should be last step by Vokbain · · Score: 0

      How is that different from all the junk mail (paper junk mail I mean) that I get? I suppose since the sender is paying for that, it makes it more acceptable, but I bet without all that junk our postal systems would be a lot more efficient, and cheaper as well.

      Stopping both at the source is of course the best way, but it's also the hardest to implement. For one, who decides what is junk and what isn't?

    2. Re:Client-side filtering should be last step by Joakim+A · · Score: 1

      Filter at the client works for SPF since it does its check before the mail is received (after Mail From:, before Data). Microsoft CallerID has the problem you describe, MS also codes its DNS info in XML which makes it so big that it requires a TCP session.

      SPF rules.

  11. CallerID for email boycott by Anonymous Coward · · Score: 3, Insightful
    The concerns presented by the boycott of Microsoft's Caller ID still haven't been addressed by Microsoft. It's still patent-encumbered, still far too verbose and still not used by anyone besides Microsoft and Amazon.

    Stick to SPF, give DomainKeys a try once someone actually publishes some info about it. Skip caller ID.

  12. MOD PARENT UP by Anonymous Coward · · Score: 0

    read the site.. many good points.

  13. Re:The problem has no solution ... by AnalogFile · · Score: 1

    You are only scratching the surface of the problem.

    What do we expect:

    Defining the expectations is a big task by itself. Those doing some serius work on it identifyed many many different requirements. And of course many of them are contradictory.

    The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal

    Traceability. Autentication. Anonymous posting. Privacy. Each of these is a research task in and by itself. The cost of the domain is unrelated to the mail. The cost of mailing may be. There are proposals that follow exatcly that path. Receiving tons of mail (and storing it and sorting it out) is a cost. Sending mail, even bulk mail, generally costs close to nothing. They aim at reversing this. Put the cost on the sender instead of putting it on the receiver. This is just ONE of many possibilities (and a smart and promising one, IMO).

    we could force people to pretty much always use their company's mailserver

    IMO that's nonsense. Not even forcing people to use their provider mail server, is acceptable. As long as SMTP is the protocol, you need not have a mail server at all to send. The server is needed to receive. And one should not be forced to send from the server it uses to receive.

    SASL or other solutions

    SASL and similar solutions IMO just break the paradigm of SMTP. Beside being broken in many other respects too.

    a mix of technical and legal solutions to kill spam.In other words, kill the root cause of the problem.

    Making spam illegal is OK with me. Legally defining spam is not. Therefore I tend to be on the "keep the fucking law out of the net" side. But I agree that killing the cause of the problem is good. Unfortunatelly that cause may actually be SMTP itself.

  14. PERHAPS: by xgamer04 · · Score: 1

    An RFC could help here?

    --
    When you look at the state of the world, how can you not become a radical, liberal anarchist?
  15. OT: were's ESR? by AnalogFile · · Score: 1, Interesting

    Sorry if this is really OT but ...
    I just was curious to see if Eric Raymond had some post/opinion on this subject. I went and checked it out and ...

    Anybody noticed he's *completely disappeared* after posting "The Luxury of Ignorance: Part Deux" on february 29?

    No more posts on his site. Neither in the writing section, nor in the blog. Cannot google out any reference to a travel or something. Nothing.

    And looking at his back records, he's not used to being so silent for such a long time. Expecially not if we consider what's happened in this months. Not a word on MS vs. european antitrust. Nothing on latest SCO news. Nothing on the euro-patent issues.

    Where's ESR?

  16. SPF is Email Authentication by jgardn · · Score: 3, Informative

    SPF only authenticates mail as being approved mail from a domain. In itself, this only prevents joe jobbing and phishing, but domains can still send spam.

    As SPF adoption grows, there will be two types of email: authenticated and unauthenticated. Authenticated mail will consist of both spam and legitimate mail. Unauthenticated mail will be just like the mail we are sending around today.

    What does authenticated mail get us? As we can track mail down to the owners, we will begin to set up a trust system. DNS block lists will become viable. The owners of domain names can protect or abuse their domain names as they see fit.

    Eventually, there will be a system where domain names will have value again. If I don't abuse my home domain, and only use it for legitimate purposes, people will not add my name to black lists. If my domain has sent a large number of emails with a very low score of spam, it will be more legitimate than one who has sent only a few emails or has sent mostly spam.

    SPF is only the first step in stopping unsolicited email. Once it is in place, the next step -- accountability -- is easy to implement.

    The beauty of SPF is that it doesn't invalidate email as it is now. Participation is optional. Those who are early adopters get an early boost, so the incentive is there to adopt it early on. But email as it is now will not be stopped.

    --
    The radical sect of Islam would either see you dead or "reverted" to Islam.
    1. Re:SPF is Email Authentication by CmdrTHAC0 · · Score: 1

      "If my domain has sent a large number of emails with a very low score of spam, it will be more legitimate than one who has sent only a few emails or has sent mostly spam."

      What happens when $VIRUS turns your domain name into a spamfest? If you're supporting any normal users at all, you're likely going to find it hard to maintain that reputation.

      --
      __CmdrTHAC0__
      In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
    2. Re:SPF is Email Authentication by John+Hasler · · Score: 2, Insightful

      > What happens when $VIRUS turns your domain name
      > into a spamfest?

      You get blacklisted, as you should be.

      > If you're supporting any normal users at all,
      > you're likely going to find it hard to maintain
      > that reputation.

      Securing your domain is your responsibility.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    3. Re:SPF is Email Authentication by Anonymous Coward · · Score: 0
      when a virus on your machine sends email out for my domain, how is that my fault?

      you have no clue what you are talking about.

    4. Re:SPF is Email Authentication by Anonymous Coward · · Score: 0

      SPF only authenticates mail as being approved mail from a domain

      The problem with this, of course, is that domains don't send mail. People send mail.

    5. Re:SPF is Email Authentication by jgardn · · Score: 1

      You declare that only your machines are allowed to send email for your domain with SPF records. If his machine decides to send spam in your name, it will be marked as "SPF rejected" because you say his machines cannot send mail on your behalf.

      --
      The radical sect of Islam would either see you dead or "reverted" to Islam.
  17. What's wrong with OpenPGP? by Baloo+Ursidae · · Score: 1

    Seriously...I've been using it for a while now. It works well. It's bloody simple. Why more people don't use it, I don't know.

    --
    Help us build a better map!
    1. Re:What's wrong with OpenPGP? by Anonymous Coward · · Score: 1, Interesting

      There are two obvious reasons.

      1. Very few people know about it.

      2. Assuming that www.openpgp.org is the home page for this then there is too much digging for most folks to bother installing it.

      Here are some obvious questions I couldn't easily find answers to.

      1. Does it work with Kmail? (which I use at home)
      2. Does it work with Eudora? (which is what I recommend for my windows using friends/family.)
      3. I have a few Mac using friends, will this work for them?
      4. Does it work with my ISP's java based email client?
      5. Does it work with my free webmail accounts?

      If it can do all that then it can handle all of my email needs.

  18. (offtopic) Re:It still won't work by Anonymous Coward · · Score: 0

    Modded the wrong way, sorry, posting to undo moderation

  19. Black Helicopters.... by Anonymous Coward · · Score: 0

    Sighted near his dwelling on March fifth. I heard it from Art Bell, so I know it's true.

  20. Alternate Solutions by lachlan76 · · Score: 2, Insightful

    Backwards compatibility and security can't be combined. Just like you can't simultaneously find the position and momentum of a particle with perfect accuracy, any attempt to make a certified mail system backwards compatible with existing systems means that spam will still exist. So far the most promising method of slowing spam is cryptographic challenges. By sending the client a simple cryptographic challenge which can be solved in anywhere from 10 seconds to 1 minute, spam can be slowed significantly, since the limiting factor is a technical one, which can only be bypassed by running the servers on a *HUGE* server farm in order to keep the spam flowing at the rate it is today. The other problem is that if the key size is too small, then the challenges can be precomputed, although using a different IV would increase the storage space need to precompute a list of RC4 values by a factor of 2^24. Or, a distributed computing task could be used (you must text X RC5 keys or OGR nodes to send Y emails) to not only slow spam, but provide practical information about what amount of time it would take to crack a given encryption algorithm. Other distributed computing tests could be used of course. The only way to stop spam is to create a controlled (timewise) mail system completely incompatible with existing SMTP clients, as SMTP is anonymous and uncontrolled. A public/private key system could also be used to verify the identity of a sender, and spammers can easily be identified (ie. you get a spam, you verify it with the public key included in the mail header, and send the key to a central server. Want to send mail, but haven't got a key? Too bad, since your mail can't be traced back to you. What's that you say? Make your own key pair? Well then your mail is rejected by the server too, since you do not have a valid key) bye their registered public key. SMTP and similar, unauthenticated mail systems, though, can not be beaten for reliability, since there are no central servers to go down, and as long as the sending and receiving mail servers are working, what is sent is always received.

  21. OpenPGP plugins by aat · · Score: 1

    OpenPGP is a standard implemented by a few programs including PGP (non-free), and GnuPG (aka GPG) (Free). GnuPG support is either integrated into or supported via plugins on Kmail, Eudora, Mutt, Outlook, and many other clients. See http://www.gnupg.org/(en)/related_software/fronten ds.html for more details. There are a couple of Mac related links there. About the last two, GPG's privacy lies in the key, and thus you wouldn't want anyone else to be able to use your key -- they could sign messages as you otherwise. A hackish way to use GPG with these would be to manually use gpg to sign (and possibly encrypt a message) on the commandline, and then pasting them in. Someone could write client side code for dealing with webmail (Browser plugins that allow one to replace the current contents of a text input field with a signed message, but they could easily be security holes if not written correctly).

  22. Re:The problem has no solution ... by Anonymous Coward · · Score: 0

    There exist at least two solutions today, however, nobody bothers to use them:

    1) PGP,
    2) S/MIME.

    Provided one sets up an effordable Web-Of-Trust (esp. PGP), Non-SPAM gets authentificated by the client or even checked against a trusted trusted certificate database by mail relays. E.g. all certificates could chain to a final "Valid Mail certificate" trusted by anyone. Not only provides this technique user or organization signatures, you may deploy security against 3rd party lurkers along the transfer.

    Of course, the current commercial way to get a re-signed S/Mine certifcate is too heavy.

    All the techniques I saw so far limit the sending of one mail to specific hosts, breaking the oppertunity to take up roles while sending. Or inflict larger problems setting up secure connections to the "specific hosts" in organizations spread across multiple locations or with mobile or home workers.

    And, BTW, how get you sealed the ISP, for instance, against trojans, worms and virii, in order to prevent misuse of a box as it is standard today? Who really believes that Spamers use there own boxes to send ??