Slashdot Mirror

← Back to Stories (view on slashdot.org)

IETF Decides On SPF / Sender-ID issue

Posted by Hemos on from the making-the-hard-choices dept.

Zocalo writes "The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past."

6 of 269 comments (clear)

  1. I love it by kc0re · · Score: 5, Insightful

    I love it when the world has a moment of clarity and decides that Microsoft has enough damn patents and we're not going to let them run everything. Adopt the open standard that everyone can use. It makes more sense.

  2. Standards == Monopoly?? by bunburyist · · Score: 5, Interesting

    Question: Is the IETF allowed to adopt patent-encumbered standards? I mean, wouldn't that grant some sort of monopoly license in effect for MS, seeing as if you want to adopt a standard, you need to pay somebody? Shouldn't standards be free, and people can make money off the implementation of said standards? I don't know how these things work, nor am I a lawyer of any capacity.

  3. Will ITEF make a difference? by milgr · · Score: 5, Interesting

    When Microsoft ships their method on all their mail servers and mail clients, will it matter that it is not a sanctioned standard?

    --
    Where law ends, tyranny begins -- William Pitt
  4. Good. Now let's improve SPF. by jefp · · Score: 5, Interesting

    The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.

    It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.

    I'm interested in comments on this idea.

  5. Re:I've always wondered... by Doctor+Crumb · · Score: 5, Informative

    If your system asks the sending *server*, this is redundant, as you already know the sending server sent it, by definition.

    If your system asks the domain that the mail is supposedly from, then you may as well be using SPF, as it saves on network traffic and gets you the same answer.

  6. That's certainly not how I read it by mccalli · · Score: 5, Informative
    From the judgement:
    3. On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.

    Look closely. The wording to pay close attention to is "This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application.".

    In other words, we don't know what the patent is, so we shouldn't waste time doing any work an anything that might infringe it. That's significantly different to saying that the original patent-encumbered work won't be accepted, in fact the wording has been very carefuly picked to remain non-committal on that point.

    Next, look at an extract from point 4 of the summary:
    4. ...With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.

    In other words, not only the should the committee not waste its time until all the patent claims are made public, but neither should anybody else try submitting new things until the committee knows what's happening with the current proposals.

    I read the summary as a glorified "we can't know what to do as not all claims have been made public, so we'll just put everything off until the claims are fully known". Neither backing for, nor rejection of Sender-ID. And certainly nothing whatsoever about falling back purely onto SPF.

    Cheers,
    Ian