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

 



Forgot your password?
typodupeerror
×
Patents Software Microsoft The Internet Apache

Apache Rejects Sender ID 351

hexene writes "In an open letter to the IETF MARID Working Group, the Apache Software Foundation has rejected the patent-encumbered Sender ID specification. This means no Sender ID support for SpamAssassin, Apache JAMES, etc. They state that the current license is generally incompatible with open source, and contrary to the practice of open Internet standards."
This discussion has been archived. No new comments can be posted.

Apache Rejects Sender ID

Comments Filter:
  • by Euphonious Coward ( 189818 ) on Thursday September 02, 2004 @12:46PM (#10140384)
    I don't see any reason to use SPF either. It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses. Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.

    The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.
  • by garcia ( 6573 ) * on Thursday September 02, 2004 @12:47PM (#10140398)
    We will not be implementing support for Sender ID until such time as the issues with the license are fixed and acceptable to the Apache James and Apache SpamAssassin Project Management Committees.

    It's obvious that Apache's concerns are of the utmost importance to both MSFT and those conducting the discussions. If they were SO concerned this would have been taken care of long ago. MSFT figures that either Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution or that they will end up having to break down themselves later. It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

    As an alternative resolution, we would find it acceptable if the pending patents were granted to a non-profit organization such as ISOC and licensed under sufficiently open
    terms.


    This, OTOH, is a valid option and should be exercised but I highly doubt it will be for obvious reasons.
  • by bryam ( 449040 ) on Thursday September 02, 2004 @12:56PM (#10140517) Homepage
    "Sendmail releases open source milter for Sender ID
    August 30, 2004
    Today, Sendmail, Inc. is releasing an open source implementation of the IETF's Sender ID specification for testing on the Internet. This implementation utilizes the milter interface to plug directly into the sendmail MTA.

    Sender ID is a standards-track proposal that merges Meng Wong's SPF and Microsoft's Caller ID for email. Authorizations records are published in DNS in an SPF-compatible format, and then used to validate user-visible message headers using the Caller ID "Purported Responsible Address". This sid-milter release implements the marid-protocol and marid-core draft standards, leaving the marid-submitter SMTP Extension to be implemented directly by the sendmail MTA.

    Downloadable source code for sid-milter can be found at: sendmail.net/sid-milter"
  • by Skiron ( 735617 ) on Thursday September 02, 2004 @12:58PM (#10140532)
    RMS E-Mail to IETF MARID WG ML [imc.org]

    All listen to the man!
  • by jhunsake ( 81920 ) on Thursday September 02, 2004 @01:05PM (#10140618) Journal
    It's an inferior attempt at authentication. Yahoo!'s DomainKeys is superior in every respect.

    I was really interested in SPF for a while, but I'm tired of this shit. Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...
  • by scorp1us ( 235526 ) on Thursday September 02, 2004 @01:15PM (#10140747) Journal
    According to this [newsforge.com] article SenderID in the agreed upon form is nothing new. Indeed it seems that MS has embeaced and extended someone else's IP and put their own claim to it.

    Therefore, Apache maybe abandoning something that it needs not to abandon.
  • by Daniel Boisvert ( 143499 ) on Thursday September 02, 2004 @01:25PM (#10140856)
    There's a difference between knowing which IP's in your netblock are allowed to send mail, and which IP's are allowed to send mail from your domain. SPF requires you to know the latter, which is something you really ought to know if you're running a domain.

    The former is much harder to know, for a zillion reasons (subnets controlled by downstream entities, legit residential mailservers, etc.).
  • by Ridgelift ( 228977 ) on Thursday September 02, 2004 @01:31PM (#10140925)
    I think this is the first time I've seen a situation where Microsoft is unable to dictate to others on "how things are going to be". The question I have now is "what will Microsoft do next?". Are they willing to be directed by an Open Source project, or will they go their own route to stave off the perception that Microsoft isn't as omnipotent as they want everyone to believe?

    Fascinating. Absolutely fascinating.
  • Re:Hoody Hoo! (Score:3, Interesting)

    by jaaron ( 551839 ) on Thursday September 02, 2004 @01:35PM (#10140967) Homepage
    In fact, the ASF just rather recently set up SPF filtering on their own internal mail servers.
  • by sphealey ( 2855 ) on Thursday September 02, 2004 @01:46PM (#10141091)
    This is just the logical outcome of the RAND debate [w3.org].

    I hope Apache wins the day here. However, the entire reason for the RAND proposal in the first place was to allow commerical interest to capture open Internet standards. I don't think they will be easily deflected.

    sPh

  • by Anonymous Coward on Thursday September 02, 2004 @01:49PM (#10141110)

    i have a small email server at home that i use for website signups & imdb movie queries, i have a domain name pointing at it but the reverse dns of my IP gives me not my domain name but my ISP's name of my machine as i dont control the dns for that, so how can i use these email certification systems ? i have complete and correct mail headers and am willing to verify who iam but iam a bit pissed at being denied the use of smtp, whats next ? SSH or [insert port here]

    so how will these email schemes protect me ? or is this a case of screw the honest geek on a cable modem and render being in control of my own email useless, forcing me to use "approved server$" from [insert large corp name and another fee here]

  • by kantai ( 719870 ) <kantai@gmail.com> on Thursday September 02, 2004 @01:54PM (#10141171)
    open standards (truely open) and protocols will win over closed source solutions.

    Some examples, please? Ogg over mp3?

    the reason is simple...the desires of the many will trump those of the few or only. so the majority will move on to the open technologies.

    Speaking of logic not flowing, what does even mean? How are the desires of the many related to Open Standards? How are Closed Standards only few? You failed to make that connection there.
  • by pjrc ( 134994 ) <paul@pjrc.com> on Thursday September 02, 2004 @02:32PM (#10141579) Homepage Journal
    Yahoo!'s DomainKeys is superior in every respect.

    Records already published by 70000+ domains, including some very important ones like aol.com.

    A way to guess a default record for any domain not yet publishing, that works for most existing mail servers.

    Code already under development and in beta testing for all major MTAs.

    Algorithm already implemented in upcoming SpamAssassin filter, which is currently in release testing

    It's an inferior attempt at authentication.

    Yeah, yeah, yeah... it has crypto, so it must be strong.

    Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...

    And replace it with a yahoo DomainKey? How are you going to do that? Oh, you're going to go download the reference implementation [sourceforge.net], compile this alpha-release source code, and run the "dknewkey" to get something like this:

    testkey._domainkey IN TXT "k=rsa; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANazc9du4IFEWnSr idEMAuv9UvCojT8hiTg1L646F6T4dRTsz7MB0WdnG2cF5J6HgA AlvpIB8HN1bh43FBb1MqkCAwEAAQ=="

    Then you're going to head over head [sendmail.net] and grab this while ignoring the advisory section:

    THIS IS PRE-RELEASE SOFTWARE, and should not be used in any critical production environments.

    For someone highly concerned about what is and is not a waste of time (unlikely, posting to slashdot).... if you already did publish a SPF record, your best course of action is probably to just leave it there.

    Certainly, Yahoo's DomainKeys is not yet to a degree of maturity to be actually used for much more than development and alpha testing.

    In contrast, SPF is already protecting 70000+ domains and numerous sites are beginning to filter out forged messages pretending to be from those domains.

    Very soon, SpamAssassin 3.x will be released (already on second release canidate), with SPF checking built in and turned on by default. Other anti-spam filters will follow.

    From a practical point of view for the near future, choosing between installing a TXT record of the form "v=spf1..." or "k=rsa...", it's pretty clear which of these is useful today and which (unless you're a developer working on DomainKeys) is a waste of time.

  • by sakeneko ( 447402 ) on Thursday September 02, 2004 @02:39PM (#10141673) Homepage Journal

    After reading the statement on the ASF web sit, I reluctantly had to agree with the Apache Software Foundation on the issue of Sender ID. The "free license" offered to those that support SenderID in open-source software packages has too many pitfalls, too many places where it could encumber open source projects. The SpamBouncer [spambouncer.org] will therefore not support SenderID either until there are fundamental changes in the license.

    This is a shame. Meng Weng Wong's original idea for SPF was quite good, and I was planning to support it.

  • Microsoft Patents (Score:5, Interesting)

    by SiliconEntity ( 448450 ) on Thursday September 02, 2004 @02:58PM (#10141871)
    I think we are missing the real danger here. There was never all that much difference between SPF and Microsoft's Caller ID. The differences were in the details of how they were put into the DNS, the use of XML vs text formats, and maybe some issues about exactly which mail headers were checked. But the basic idea was almost identical.

    This means that Microsoft's forthcoming Caller ID patents probably cover SPF. That's the real problem here.

    We can't just tell Microsoft to get stuffed and then go ahead and use SPF. There's too much risk that Microsoft will surface with a patent in three or four years that covers a technology which is by then widely used on the net.

    I think this decision kills SPF and everything along those lines. Some may cheer and some may be upset, but that is the reality we face. Going forward with SPF under these circumstances is far too risky. Microsoft has warned us about the patent applications and we can't ignore them.
  • Beyond Control (Score:1, Interesting)

    by Anonymous Coward on Thursday September 02, 2004 @04:55PM (#10143024)
    At this point, MSFT is basically beyond the control of the United States.

    I'm not talking about life and death. The Constitution was made to cover life-and-death, and keep those kinds of decisions in balance. We're talking about optimizing life. And within the confines of that issue, MSFT is un-touchable.

    Like I've said before, if the revolution ever does break out, MSFT will be the first ones up against the wall. There will be a bunch of hippies up against the wall with MSFT, as well, simply because we know they don't have any guns.

    Christ, we'd have a clean nation again. I don't know what we would do with ourselves. Probably, like, making space stations or something. Conquer space. I dunno...
  • by Alan Cox ( 27532 ) on Thursday September 02, 2004 @06:16PM (#10143971) Homepage
    Nobody can fork the standard. The patent "grant" is for compliant implementations only. So its microsofts document, microsoft controlled and thats the end of it.

    SPF also has another deeply fundamental flaw - it requires the ISP to be vaguely competent. That alone is fatal for many of ISPs.

"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan

Working...