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

 


Forgot your password?
Close
typodupeerror
×
Spam The Internet IT Technology

IETF Approves SPF and Sender-ID 220

Posted by Zonk from the protocols-forward dept.
NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.
This discussion has been archived. No new comments can be posted.

IETF Approves SPF and Sender-ID More

IETF Approves SPF and Sender-ID

Comments Filter:

  • I'm not sure about a dent in spam (Score:3, Informative)

    by Mustang Matt ( 133426 ) on Friday June 24, 2005 @03:59PM (#12904065)
    But this will help me out tremendously.

    Not getting joe jobbed will be a huge step forward. Not to say that everyone's going to instantly adopt these standards but it won't hurt that these are Official now.
    • Amen to that.

      I run a personal mail server and am getting hit with up to 100,000 bounces per day because some spam gang decided they like my domain (might be due to the fact that I also report *all* spam I receive through Spamcop [spamcop.net].

      Fortunately they use random sender account names and don't hit my account and my server easily blocks the bounces, but this could be a disaster if they instead chose valid account names.

      • I noticed that I got joed after reporting spam. It would make sense for the spammers to try to kill off the reporters. Now I remove all identifying info when I report spam (including message IDs) and send the report from a gmail account. I also post that way on NANAS.

  • Not about spam, it's about joe-jobs. (Score:5, Informative)

    by khasim ( 1285 ) <brandioch.conner@gmail.com> on Friday June 24, 2005 @04:00PM (#12904071)
    Before the rush of posts about how this won't do anything about spam, this is not about spam. This is about stopping spammers from using your address which results in your email servers dealing with the mass of bounces and spam reports from clueless admins.

    Of course, only the admins with a clue will correctly implement either of these so ...

    • Re:Not about spam, it's about joe-jobs. (Score:5, Informative)

      by dsginter ( 104154 ) on Friday June 24, 2005 @04:28PM (#12904317)
      Joe Job [everything2.com]

      For those wondering.
    • I have a domain that has been the victim of joe-jobs for years.
      I don't use it for mail myself, so I have put bogus MX records on it. This yielded an rfcignorant listing, but the joejobbing continued.
      Then I put an SPF record up and restored a valid MX record. The number of bounces was as before, and did not decrease noticably over several months.

      My conclusion is that adoption of SPF and other DNSblock checks is far to little to make any dent into the spam, and certainly not enough to make the spammer remo
    • Except you don't have any control over it. I can set up an SPF record for a domain, but if they don't look at the record on the other end, it does me no good. As you suggest, my server may still have to deal with "the mass of bounces and spam reports from clueless admins." Not to mention, servers that just mark this as "spam" and send it on to the end user aren't doing me any favors. The end user doesn't know I'm not the one spamming them.

      I think this is about spam. I block spam using SPF all the ti

  • Did IETF change their mind? (Score:5, Interesting)

    by ravenspear ( 756059 ) on Friday June 24, 2005 @04:02PM (#12904088)
    I thought the IETF had already rejected Sender-ID [messagingpipeline.com] because it was MS proprietary.

    • Re:Did IETF change their mind? (Score:5, Informative)

      by pyrrhonist ( 701154 ) on Friday June 24, 2005 @04:16PM (#12904220)
      I thought the IETF had already rejected Sender-ID because it was MS proprietary.

      Yes, they did, and they did not change their mind. They labelled these documents as "experimental". See here [slashdot.org] for details.

      • Which still doesn't really explain why they're conducting the experiment.

        Unless MS have pressured them into it, so they can get a crack at declaring Sender-ID as the de facto standard and thereby sidestepping the standards process, of course. That might explain it.

        • Which still doesn't really explain why they're conducting the experiment.

          They aren't, "conducting an experiment". The draft was submitted as "experimental".

          The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been

          • They aren't, "conducting an experiment". The draft was submitted as "experimental".

            Oh, well, silly me then.

            They aren't "sidestepping" the standards process. An "experimental" designation is part of The Internet Standards Process, but is not on the standards track.

            Useful link, thank you. Everything is now much clearer. Apart from the use of the word "approved" in the OP, anyway.

            It's funny though. Since MS are presumably not going to make Sender-ID FOSS friendly, the factors that blocked adopti

    • When things went south on the SMTP auth fast track last year the chairs suggested that all the protagonists submit their proposals as experimental standards. Once again, the /. title overstates the matter. We can expect other experimental proposals for IP-based authentication like CSV.

      But it's all just jerking off now because Domain Keys has won the authentication battle in the market [eweek.com].

  • Zombies anyone? (Score:2, Interesting)

    by dancpsu ( 822623 )
    What's to stop the spammers from using a zombie to fake the sender id? It's a good step forward (you would know where the zombie was), but the bigger challenge would be to have some kind of capability to restrict mail servers to authenticated ones rather than some kind of recipient call-back mechanism. Otherwise the future of email will be "sender ID from mail server ZOMBIE294346.earthlink.net"

    • Re:Zombies anyone? (Score:4, Informative)

      by Anonymous Coward on Friday June 24, 2005 @04:15PM (#12904205)
      Because the SPF record is a DNS record. It's not exactly trivial to fake this. Plus, in your specific case, it won't work.

      Earthlink owns earthlink.net. Therefore, they get to set the policy for who gets to send mail originating from the earthlink.net domain. I can't set up an SPF record claiming to control who can/can't send e-mail from earthlink.com, because I don't own that domain.

      Now, the BIGGER problem is not "faking" an SPF record. It's users who set up their own domain and publish a valid SPF record that includes spammers or zombies. So, I can set up spamdomain.com, and have my SPF record include ZOMBIE1234.earthlink.com as an allowed sender. This means mail COULD come from this zombie that claims to be from spamdomain.com. It's even possible for spamdomain.com to set up an SPF record that says EVERYONE is an allowed sender, and so anyone could send e-mail from spamdomain.com.

      So, this won't actually prevent people from spamming. What it WILL do is keep spammers from imitating existing domains in their "from" headers. Which doesn't sound like a lot, but will help with impersonation. It will also make it fairly easy to tell the spam domains. Anyone with an SPF record of "every sender is OK" probably should be blocked as a probable spammer. And anyone claiming to be from a reputable domain actually is. It will also make it harder for viruses that go through your address book for "to" and "from" headers to work.
      • >> What it WILL do is keep spammers from imitating existing domains in their "from" headers.

        If it works, that's plenty. If you've ever had one of your domains placed in the "FROM" field of a spam campaign, you'll know what I mean.

        It's not going to work %100 though - TFA (microsoft's site) indicates the recipient would do the DNS lookup for the SPF record before accepting the SPAM, so I'm guessing anyone who's mail client doesn't support this will get the spam even if I add SPF to my DNS entries..
        • Surely it's not the mail client's (MUA) responsibilty to do the lookup, but rather the MTA's. Doesn't SPF work with the envelope from field, rather than the header from field (which MUAs normally use)? Incidentally, what does this do for faked header from fields? MUA can still be duped, although it shouldn't result in an automatic bounce going to the wrong person.

          • I believe that is the problem with forwarding. (Score:5, Informative)

            by khasim ( 1285 ) <brandioch.conner@gmail.com> on Friday June 24, 2005 @06:02PM (#12905100)
            http://spf.pobox.com/faq.html#whichfield [pobox.com]
            So, this is implementation specific, but it seems that it will compare published SPF record of the domain in the FROM: or the return path with the fully qualified domain name of the sending machine (zombie123.earthlink.net yields "earthlink.net").

            So, if the incoming email claims to be from/return-path taco@slashdot.org and slashdot.org publishes an SPF record, that SPF record had better list zombie123.earthlink.net as a legitimate mail server or it will fail.

            What, specifically, happens when it fails is also up to the implementation.

            The problem appears when taco@slashdot._org sends an email to my old college which offers forwarding services for alumni.

            taco@slashdot._org sends to khasim@example._com

            mail.example._com forwards that message to my gmail account.

            mail.gmail._com checks the From:/return of slashdot._org and checks their SPF record for slashdot._org.

            slashdot._org does not list any example._org boxes as a mail server so the message fails the SPF check.

            Again, what happens at this point depends upon the implementation of SPF that is being used. It can range from increasing the SpamAssassin score to dropping the connection attempt.
  • It's all well and good that something is being attempted to alleviate spam in this manner, but I think a much bigger problem that needs to be addressed is ISP's selling your email address before you even log in the first time to check your mail. *Cough*Cox*Cough*. I've had 3 seperate email addresses (from 3 seperate accounts) with Cox and each one filled up with junk mail without me giving anyone the email address.

    The best thing I have come across so far is Incredimail, but even that is a pain in the ass t

  • Microsoft related? (Score:4, Interesting)

    by john_is_war ( 310751 ) <jvines@@@gmail...com> on Friday June 24, 2005 @04:07PM (#12904146)
    Hmm... Microsoft announces hotmail will be restricted to user-ID and now it's been passed as an experimental phase. Coincedince? I think not.
  • Whey aren't we hearing from the Big Pipes? They should be opposed to the widespread implementation of anti-spam techniques. Indeed, their main financial focus is on the usage of bandwidth. Spam consumes massive amounts of their commodity. They should be against any proposals that will decrease bandwidth usage, as it will hurt their financial bottom line.
    • Decrease bandwidth usage? No, SPF will *increase* it due to all the extra DNS checks people will make.

      You don't think spammers are going to look at this and think "fuck that, I'll sell my stuff some other way" do you? They'll just try sending even more messages to counter its effects.

  • Read what ASF had to say... (Score:4, Informative)

    by tolkienfan ( 892463 ) on Friday June 24, 2005 @04:09PM (#12904158) Journal
    Sender ID is not particularly trusted by everyone, to say the least.

    Example from ASF [apache.org]

  • It's one SMALL step (Score:5, Interesting)

    by realmolo ( 574068 ) on Friday June 24, 2005 @04:10PM (#12904174)
    Both SPF and Sender-ID solve only one problem: faked sender domains.

    That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.

    What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.

    In other words, a total revamp of the mail system protocols. ;) We can dream.

    • A central database is open to abuse. (Score:5, Insightful)

      by CyricZ ( 887944 ) on Friday June 24, 2005 @04:15PM (#12904214)
      Of course we will never see a central database of mailservers. That has been proposed before, but will always be unsuitable for the Internet. Remember, the Internet is meant to be decentralized. And a centralized database is open to abuse by governments, corporations, and whoever runs it (or provides the funding for it).

      There's nothing to stop spammers from infiltrating such a system, via legitimate and illegitmate means. So it just plain won't work.

      Between the fact that it is easy to abuse, it just won't work and it won't provide any benefits over existing systems, your system is just a bad idea (no personal offense meant, of course).
    • What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.

      Who would run this registry? Why do you need to pay to get on it
    • How do you figure you can prove you're not a spammer?
      Better is to allow your approval to be revoked, if you are initiating spam.
      Plus, the cost of such a system would be prohibitive to say the least.
      Who would be resposible? A US company? And I assume all the other countries are just dying to subscribe to that system!

      I think a protocol change is in order. Instead of sending the message via SMTP, only send a notification that an email is waiting to be picked up, and it's location. When your email is ch

      • Hmmm. Not only would this move the cost to the sender, but it would also prevent spoofing. The mail client could ignore mail from "dotted quad" addresses and only go to legitimate DNS entries. It would be nice to have dates in DNS entries, too, indicating that the domain has been around for a while.

        You need to work out some kind of public key authentication so that nobody else can swipe your email from the server, but you don't have to exchange unique keys with every mail server on the internet.

        Clean u

      • Re:It's one SMALL step (Score:3, Insightful)

        by julesh ( 229690 )
        I think a protocol change is in order. Instead of sending the message via SMTP, only send a notification that an email is waiting to be picked up, and it's location. When your email is checked, it loads the email from the server.
        This has the following benefits:

        1. The cost is on the sender. It would be prohibitively expensive to send millions of messages - you'd have to host all the clients!

        Huh? You'd still only transfer the same amount of data, it would just become unpredictable how much you would t

    • Re:It's one SMALL step (Score:5, Funny)

      by bunnyman ( 121652 ) on Friday June 24, 2005 @05:51PM (#12905005)
      This article advocates a

      ( ) technical (x) legislative ( ) market-based ( ) vigilante

      approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

      (x) Spammers can easily use it to harvest email addresses
      ( ) Mailing lists and other legitimate email uses would be affected
      ( ) No one will be able to find the guy or collect the money
      ( ) It is defenseless against brute force attacks
      (x) It will stop spam for two weeks and then we'll be stuck with it
      ( ) Users of email will not put up with it
      ( ) Microsoft will not put up with it
      ( ) The police will not put up with it
      ( ) Requires too much cooperation from spammers
      (x) Requires immediate total cooperation from everybody at once
      ( ) Many email users cannot afford to lose business or alienate potential employers
      ( ) Spammers don't care about invalid addresses in their lists
      ( ) Anyone could anonymously destroy anyone else's career or business

      Specifically, your plan fails to account for

      ( ) Laws expressly prohibiting it
      ( ) Lack of centrally controlling authority for email
      ( ) Open relays in foreign countries
      ( ) Ease of searching tiny alphanumeric address space of all email addresses
      (x) Asshats
      (x) Jurisdictional problems
      ( ) Unpopularity of weird new taxes
      ( ) Public reluctance to accept weird new forms of money
      ( ) Huge existing software investment in SMTP
      ( ) Susceptibility of protocols other than SMTP to attack
      ( ) Willingness of users to install OS patches received by email
      (x) Armies of worm riddled broadband-connected Windows boxes
      ( ) Eternal arms race involved in all filtering approaches
      (x) Extreme profitability of spam
      ( ) Joe jobs and/or identity theft
      (x) Technically illiterate politicians
      ( ) Extreme stupidity on the part of people who do business with spammers
      (x) Dishonesty on the part of spammers themselves
      ( ) Bandwidth costs that are unaffected by client filtering
      ( ) Outlook

      and the following philosophical objections may also apply:

      (x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
      ( ) Any scheme based on opt-out is unacceptable
      (x) SMTP headers should not be the subject of legislation
      ( ) Blacklists suck
      ( ) Whitelists suck
      ( ) We should be able to talk about Viagra without being censored
      ( ) Countermeasures should not involve wire fraud or credit card fraud
      ( ) Countermeasures should not involve sabotage of public networks
      (x) Countermeasures must work if phased in gradually
      ( ) Sending email should be free
      (x) Why should we have to trust you and your servers?
      ( ) Incompatiblity with open source or open source licenses
      ( ) Feel-good measures do nothing to solve the problem
      ( ) Temporary/one-time email addresses are cumbersome
      (x) I don't want the government reading my email
      ( ) Killing them that way is not slow and painful enough

      Furthermore, this is what I think about you:

      ( ) Sorry dude, but I don't think it would work.
      (x) This is a stupid idea, and you're a stupid person for suggesting it.

    • That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.
      Admittedly I don't get a lot of spam by most people's measures, but all the spam I get uses at least some form of impersonation.

  • There is no "Experimental Standard" (Score:5, Informative)

    by pyrrhonist ( 701154 ) on Friday June 24, 2005 @04:13PM (#12904195)
    According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards.

    There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".

    See "The Internet Standards Process" [ietf.org]:

    Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.

    Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense.

    The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.

    • The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.

      Thank you for adding a dose of sanity to these proceedings. :) Moderators, please mod parent up.

      Both of these so-called "standards" are harmful at best. SPF breaks email forwarding, and Sender-ID has Microsoft patent issues.

  • Reduce spam? (Score:3, Informative)

    by taustin ( 171655 ) on Friday June 24, 2005 @04:15PM (#12904212) Homepage Journal
    Since SPF doesn't even claim to be a method of reducing spam, why would anything think it would?

    As it happens, a couple of my bosses have been having email rejected recently by the receiver's ISP because we are SPF compliant.

    SPF breaks email forwarding, and most mailing lists. It's a bad idea, poorly conceieved, and poorly implemented.

    No matter what we do, SPF will cause some of our email to be rejected.

    That is a way to help spammers, not hinder them.

    • Um, no. (Score:3, Insightful)

      by Anonymous Coward
      Let's place the blame where it is due. If the recipient's ISPs are rejecting your bosses' mail on the basis of SPF records (as you claim), it means your boss is sending mail through a SMTP server which is not authorized by the SPF records you have published.

      Which means your bosses' machines are misconfigured. It's lame to try to lay the blame for that on SPF, which, while imperfect, should never lead to cases like this.
      • Say the receiver forwards e-mail to another address. For example, I run my own mail server for my domains, but I have it set up to simply forward all of my e-mail to my gmail account. If gmail were to reject e-mail based on SPF, then any e-mail sent by the grandparent poster's boss to my address would never reach me. Why? Gmail would see the mail as coming from my mail server, which is not authorized to send mail from the grandparent poster's boss.

        Also note that if I subscribe to any mailing lists -- e

      • Re:Um, no. (Score:5, Interesting)

        by taustin ( 171655 ) on Friday June 24, 2005 @06:55PM (#12905483) Homepage Journal
        You are completely, totally, and entirely incorrect, and know nothing about the situation.

        We are 100% SPF compliant. Tested and everything. The server we send through is on the only IP address allowed in our SPF record.

        The address we send to is a virtual domain that does not offer POP3 mailboxes, only forwarding service. This is not under our control. It forwards to a third domain, also not under our control, that rejects based on SPF, because the second server - the forwarding service - does not rewrite the MAIL FROM address (and is not supposed to, so far as I know, under the RFCS).

        All three machines are 100% compliant wit the RFCs, and the two using aspects of SPF are 100% compliant with those specs. And yet, legitimate email is being rejected.

        And the only way around it is to misconfigure the server not using any aspect of SPF to violate the RFCs regarding how email is supposed to work.

        Or, even better, use -all on our SPF, and thus explicitly enable precisely the kind of forgery that SPF is supposed to prevent.

        That is the very definition of a broken system.

        • The address we send to is a virtual domain that does not offer POP3 mailboxes, only forwarding service. This is not under our control.

          But it is under the control of the recipient.

          It forwards to a third domain, also not under our control, that rejects based on SPF, because the second server - the forwarding service - does not rewrite the MAIL FROM address (and is not supposed to, so far as I know, under the RFCS).

          So we have a sender sending to the recipient's forwarder sending to the recipient.

          Reci

    • No, Sender-ID (specifically, the PRA algorithm) breaks forwarding and most mailing lists. SPF (the MAIL FROM "algorithm") breaks most forwarding.
  • Is M$ still asserting patent claims over either or both?

  • SPF in the real world (Score:5, Interesting)

    by SamMichaels ( 213605 ) on Friday June 24, 2005 @04:36PM (#12904373)
    I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.

    • Re:SPF in the real world (Score:5, Insightful)

      by ryanvm ( 247662 ) on Friday June 24, 2005 @06:12PM (#12905174)
      I stopped answering my telephone yesterday. So far nobody has called and complained.

      • I stopped answering my telephone yesterday. So far nobody has called and complained.

        Mods are on crack. You're closer to funny than insightful, and it's "funny" as in "so far misguided that it's amazing you're not a Darwin Award recipient." The OP's point is that for domains that already offer an SPF record, checking that record allows them to reject a fair number of messages. Your analogy is like rejecting by default, whereas they are accepting by default and rejecting if verification information i

  • I have my own domains. I send email from home through Verizon's mail servers, but Verizon doesn't publish an SPF record, so how the hell can I publish SPF for my domains?

    That's right, I can't. Because I have no fucking idea what IP or domain name my email is going to be coming from when I send it, and Verizon can change it anyhow.

    • So here's your SPF record:

      v=spf1 include:verizon.com -all

      If verizon doesn't have an SPF record, then it's a wash. When they publish one, then it will immediately be able to cover your domain as well.
      • So, what you are basically telling me is that publishing an SPF record would accomplish exactly nothing, and therefore it would be worthless for me.

        I'm pretty sure I already knew that.

    • What what you do is take put your ISP's mail server in your DNS records for SPF, since the ISP's mail server is obviously considered an authoritative host to relay for your domain(s). (tough, huh?)

      PS: You might want to avoid casual use of profanity - swear words are "power" words and excessive use reduces their power to create an effect. The end result? They fail to add power to your words, and make you look like low-class scum, or at the very least, just a kid who hasn't figured this out, yet.

      I mean, go

  • Pay To The Order Of (Score:4, Informative)

    by Doc Ruby ( 173196 ) on Friday June 24, 2005 @05:26PM (#12904805) Homepage Journal
    I thought the IETF wouldn't approve patented specs [zdnet.com] as standards. This MS move to take over the Internet must come bundled with some pretty good checks to "the right people".
  • The Internet was designed such that every endpoint was a valid one. When you require 'authentication' at the server level for the right to be a valid end point (which is what this is) then you are saying that certain endpoints are more valid than others.

    That is not the Internet.

    There are far simpler ways to lessen our problems with spam [im2000.org] that don't damage the basic relational nature of the medium.

    I should not be required to be validated by a third party to send mail...regardless of the spam problem.
    • You aren't, but neither am I required to receive it without such certification. Regardless of the spam problem.
      • but neither am I required to receive it without such certification.

        If you had that choice, I'd have already sided with you, but you don't. This isn't about whether I want to send it or you want to receive it, but whether your ISP is going let you receive it. They want to block it before it ever reaches you and toss it as spam, regardless of your preferences. Thus, we, as two valid endpoints on the Internet, get a validity downgrade.

        I hate spam as much as the next guy, but these kinds of decisions belo
  • After the Hotmail announcement the other day, I went poking through the SPF and Sender-ID specs to figure out how I could gain the benefits of SPF without rewarding Microsoft for their attempt to subvert the specification and lock out OSS implementations during the original standards discussion. Their behavior was especially nefarious considering the duplicitous and underhanded way they tried inject the patented PRA algorithm into the standard with a serious of slippery half-truths.

    For those of you wanting
  • They're late. It's already standardized [slashdot.org].

  • Want to stop spam? (Score:5, Insightful)

    by swordgeek ( 112599 ) on Saturday June 25, 2005 @12:16AM (#12907255) Journal
    Arrest the fuckers. Throw Scott Richter in jail for a decade or two for fraud and theft. Break the back of the organised crime syndicates that are profiting. Revoke FDIC/CDIC approval for banks who benefit from mortgage spam. Have the CEOs of explicitly supportive ISPs (MCI, for instance) arrested and fined tens of millions of dollars. Threaten economic sanctions against countries who don't take reasonable action.

    Like most crime, the laws exist to stop the small criminals, and have no ability to nail the true sources. Technology is always used to try to fix this problem, and always fails.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close