Bronze or iron age?

Bronze or iron age?

Summary: In my interview with Vint Cerf, he characterized the Internet as moving from the stone age to the iron age. Now in a BBC interview another Internet pioneer--Paul Mockapetris, who created Domain Name System (.

TOPICS: Browser

mockapetrisIn my interview with Vint Cerf, he characterized the Internet as moving from the stone age to the iron age. Now in a BBC interview another Internet pioneer--Paul Mockapetris, who created Domain Name System (.com, .org, etc.) in 1983--says: "At best we are at the Bronze Age, we are not even at the Iron Age stage in the network." Bronze or iron age, the Internet is still in a primitive, or perhaps formative, state.

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Some points to clarify about Larry's article


    I manage the antispam operations at Outblaze (we run mail for lycos, and a bunch of other sites - ~ 40 million users)

    Here are a few counterpoints to what you wrote -

    > Spammers can and?do bypass port 25 restrictions
    > by using the zombie computer’s legitimate SMTP
    > servers.

    Precisely. That's already happening. BUT coupled with smtp authentication being enforced (you can use any email address you want in the from address - you just have to set your mail client to login to your smtp server with your username and password) .. it make it much, much easier to locate and cut off zombied PCs. Think of it this way .. all the spam that normally leaks out of several thousand IP addresses (cablemodems, dialups etc running infected PCs) is funneled through a single set of servers, that are set up to watch for outbound spam and clamp down on it.

    > Many legitimate users need outbound port 25
    > to send e-mail through an SMTP server that may
    > not necessarily be hosted by their ISP of the

    Port 587 (the message submission port) is defined by RFC2476 - and that RFC is dated 1998. Since then, most if not all major mailservers do support both port 25 and port 587. So what people who want to use an offsite smarthost do is to get their ISP to open it up on port 587, with SMTP authentication enabled, if they haven't done so already and they're all set.

    > Some low budget domains use their broadband
    > accounts to host their own SMTP servers.? They
    > would also be harmed by port 25 blocking.

    Static IP broadband- or anything else on a static IP - would not be subject to port 25 filtering. That is for dynamic IPs (dialup, residential broadband etc). Even if people do run servers on dynamic IPs, they can set their mailserver to route outbound mail through their ISP's servers, or through their dynamic DNS provider's smtp auth mailserver - dynamic dns providers do provide this service now.

    > Getting most or all ISPs to block outbound TCP
    > port 25 would be very controversial with their
    > users. It would be very difficult to get
    > universal compliance.

    Agreed. But it would be even more difficult for them if they failed to clamp down on trojan / zombie originated spam and viruses from their network.

    And speaking of controversial ...

    > If the top 50?domains?in the world who are sick of the spam problem
    > implemented the non-SPF ban, this would force every other domain in
    > the world to comply with SPF–unless they don’t care for their e-mails

    That is going to be far, far more ruinous, if only because SPF is badly thought out and fails horribly in several edge cases. Several spammers can, and do publish spf records. And the implication of publishing spf records absolutely forces people to rely only on their email provider's mailserver assuming the restrictive -all spf record - more conservative ?all and ~all records are not going to be very useful, and -all is guaranteed to lose you mail, given the number of forwarding email providers who dont implement the other side of the spf coin - ses / srs return path rewriting of forwarded mail.

    You'll find that it is going to be far easier to ask for port 25 blocking than for spf publication

    And, port 25 blocks are an expression of an ISP's intent to crack down on outbound spam. Checking on spf records - a procedure that's guaranteed to lose you valid email as I mentioned above - is trying to solve an entirely different problem. Consider for example, which has an SPF record set. Trojans sending out emails as random addresses render your ideas of spf checking quite useless.

    > to be delivered to the top 50 domains.? Contrast this with the port
    > 25 ban, which requires every ISP and hotspot in the world to comply
    > with outbound port 25 blocking. Which is the more practical solution?

    Again - "if you want to deliver mail to the top 50 domains". You dont need to do it at "every hotspot", believe me - this is something that is done at the edge of the ISP's network. Most if not all hotspots get themselves a DSL or a T1 or whatever from a large ISP, and these filters are best applied at the ISP's end.

    The other part - about requiring bonding of bulk senders? That works for the legitimate people. Spammers, on the other hand, work on the basis of other peoples money - letting other peoples bandwidth, cpu etc subsidize the costs of their spam. Take the case of Jeremy Jaynes, who was recently sentenced to 9 years for spamming. He spent something like $50K a month in buying lots and lots of bandwidth, and setting up spam servers to run on them. He sent out 300 million emails a month and got maybe 10,000 orders a month for phony stock advisories etc at $40 a pop. His revenues were on the order of $450K to $700K ..

    Finally, speaking of SPF, we recently decided to stop publishing spf records for several of our domains, such as, that have published spf records for over a year now.

    Over the last several months, I've become less and
    less convinced that SPF is going to be of any long term use, especially for sites that publish ?all or ~all records, or for any domain at all that sends mail.

    spf records like "v=spf1 -all" do come in handy if you want to say a domain sends no email at all .. but that's an edge case.

    Speaking of edge cases, what triggered this removal of our spf records is basically an expression of my strong disapproval of a white paper on authentication technologies that Meng Wong, the author of the spf spec, has published -

    My assessment of that whitepaper -

    * 70% spf, classic spf, unified spf etc
    * 10% domainkeys / cisco identified internet mail
    * One short paragraph (and mostly inaccurate) on BATV

    Followed by this paragraph that appears in a list of ways SPF / Domainkeys can be worked around (such as hijacking a domain and its authentication credentials, buying accreditation using zombies etc) ...

    Quoted verbatim - it's the last paragraph on page 22 of that PDF


    Spread FUD about the edge cases

    None of the approaches are perfect. A message could be forwarded through a site that does not perform SRS and does not prepend Resent: headers, that message could then pass through an MTA that munges the content for perfectly good reasons. This corner case is a favorite of technical perfectionists who use it to argue that one can never reliably reject a message based on sender authentication. If this point of view gains widespread public acceptance, you will be able to continue to spoof messages.


    My take on it? Meng Wong is saying that when SPF is criticized for having a proposal that's got major issues that lead to a lot of email being lost (forwarded email, such as where a university account is set to autoforward to a webmail or other personal mailbox can hardly be described as an "edge case"), so this means they're aiding spammers by retarding the growth of SPF.

    That's not just plain wrong, it is downright insulting to a whole lot of people who have valid and correct objections to SPF.

    Edge cases? "v=spf1 -all" (meaning "this domain does not ever send mail") is an edge case - and one where SPF does work as advertised. Another way to express the same, without SPF, would be this draft by Mark Delany of Yahoo, that I contributed a few suggestions to, and codifies an already well known and widely used DNS factoid -

    Corporate mail domains that have a corporate IT policy that stops their employees from setting up offsite email addresses that forward to their corporate mailbox could definitely use SPF, and not worry that mail autoforwarded to their mailboxes will bounce. But those are, again, edge cases.

    SPF seems designed to work best in edge case situations, rather than as the multipurpose solution (stops forgery! stops phishing! etc) that it is being promoted as.

    So when people point out breakage of SPF in edge cases, it is completely wrong to call this FUD - and even more wrong to call this FUD in a whitepaper he has been commissioned to write.

    Removing SPF records that we have deployed earlier (I think is listed on various sites as an early adopter of SPF) is the least that I could do to express my strong disapproval of this behavior.

    • Thanks for your well informed input


      I appreciate your input very much. It is well written and sincere.
      • Thanks. A little more about your article

        Thank you very much.

        btw - your story is rather high on google news searches for port 25 blocking, and spf, after that circleid story i posted ..

        The stuff about requiring AUTH is just great. SPF on the other hand is something I think has potential if used right, if modified substantially, and if not persistently billed as the surefire cure for everything from spam to forged email to phishing.


        suresh ramasubramanian gpg # EDEDEFB9
        manager, security & antispam operations, outblaze limited
  • Nice article on SMTP and SFP

    RE: Fix SMTP and leave port 25 alone for the sake of spam

    requiring a user's email program to authenticate to an SMTP server would request a secure session that adds some complexity to the discussion, but doable. sending username and password in the clear is not a good idea at any time.

    Good article. Let's see if 50 large ISPs bite?