Slashdot Mirror
Apache Rejects Sender ID
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."
Microsoft Sender ID Framework
... and it goes on and on
The Sender ID Framework is an industry standard created to counter e-mail domain spoofing and to provide greater protection against phishing schemes. This combined specification is the result of Microsoft's Caller ID for E-Mail proposal, Meng Wong's Sender Policy Framework (SPF), and a third specification called the Submitter Optimization. These three draft technical specifications were recently submitted to the Internet Engineering Task Force (IETF) and other industry organizations for review and comment.
Is this why the sender ID article on Wikipedia is only a stub?
Please, click "edit this page" and help if you know anything!
I use JAMES for my mail transport, and have found it to be fantastic. A single XML file can configure all the services you need (SMTP, POP3, IMAP), with or without TLS. If you want TLS, you just add an entry for it.
Also, it's really easy to write custom programs for mail processing, called "Matchers" or "Mailets" (many already exist), for things like SPAM detection, custom mail delivery, etc. I highly recommend it over sendmail/qmail.
We already have an unencumbered standard for SPF: It's called SPF. You already said SPF predates MS involvement....
:-)
Here's for example the statement of the Courier maintainer on the mxcomp-list:
On Fri, Aug 27, 2004 at 08:01:16PM -0400, Sam Varshavchik wrote:
|
| The purpose of this message is to clarify my plans for any deployment of
| the Sender-ID specification in Courier (http://www.courier-mta.org).
|
| Microsoft has made certain patent claims on the Sender-ID specification.
| Microsoft has issued the IPR disclosures and royalty free license required
| by the IETF. It appears that IETF's contemporary policies do not prevent
| the sponsor/advocates from including patented IP material into
| standards-track specifications, without even requiring the sponsor to
| actually enumerate and identify their intellectual property; a mere claim
| of the existence of some nebulous IP rights is sufficient, which can be
| revealed at any point in the future, at the sponsor's discretion.
|
| The current development version of Courier implements the original
| SPF-classic specification, that predates Sender-ID. This will be rolled
| into a forthcoming release. I'm quite pleased with the results so far --
| there are a lot of classic SPF records in existence, as witnessed by my
| mail logs
|
| It will not be possible for me to implement Sender ID in Courier. Courier
| is licensed under the GPL. The FSF already flatly stated that Microsoft's
| IP license is not GPL compatible. I reviewed the most recent version of
| Microsoft's proposed IP license, and I've reached the same conclusion. For
| this reason Sender ID cannot be implemented in Courier; Courier's
| implementation will be limited to the unencumbered SPF-classic.
|
| --
| Sam Varshavchik
| http://www.courier-mta.org
So, keep up the hope - just ignore SenderID.
A few good articles on sender-ID controversy:
8 ,00.asp s p 1 555212 h tml?tid=137
6 78.html
http://www.eweek.com/print_article/0,1761,a=13402
http://www.circleid.com/article/730_0_1_0_C/
http://www.eweek.com/article2/0,1759,1639880,00.a
http://www.newsforge.com/article.pl?sid=04/09/01/
http://trends.newsforge.com/14/04/08/26/1326244.s
Also, here are the opinions of Eben Moglen of FSF and Larry Rosen of OSI:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03
You're mixing up the Apache HTTP daemon with other projects under the ASF's umbrella.
DomainKeys and SPF fit in differnt spaces for solving different problems.
SPF has a great deal of value. The only problem I see with it is the envelope rewriting schemem (SRS, I think it's called) which is cumbersome. I'm expecting a) someone will fork the SPF standard, since the original introducers got in bed with MSFT and b) they'll want to introduce a transfer-of-authority protocol into SMTP rather than trying to cram everything into the FROM part of the envelope.
After that, SPF is really all you need to stop forged spam.
What a lot of people (including the grandparent) don't get is that SPF isn't designed to stop spam. SPF is designed to stop two things: forgeries and bounces of forgeries. Stopping those two, however, then makes stopping spam a much more manageable problem.
If you're looking for the panacea spam solution, you're doomed. If you're looking for the right tools to eliminate almost all of the problem, SPF should be among your first few (along with a good, flexible, multi-technology server-based filtering tool like SpamAssassin; an extremely well maintained and liberal blacklist like Spamhaus; and an easy-to-use end-user spam filter like Thunderbird's).
To phrase it similarly, SPF doesn't do a damn thing with email headers. It only pays attention to the envelope sender, which is what is specicied in the SMTP MAIL FROM command, and winds up in the Return-Path header due to actions of the receiving server. It's not designed to stop phishing schemes.
Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.
Sender ID isn't one or the other, but the combination of those and some other weird thing M$ came up with. Sender ID is also what's patented, as far as I know, not SPF.
All I want is a kind word, a warm bed and unlimited power.
[source:http://www.anti-spamtools.org/SenderIDEmai lPolicyTool/Default.aspx]
No SPF Record has been found for the domain microsoft.com. However, MX and/or A records currently exist for this domain.
The domain's MX and A records contain the following information:
Addresses Listed in A Records
207.46.130.108
207.46.250.119
Mail Servers Listed in MX Records
maila.microsoft.com 131.107.3.124
131.107.3.125
mailb.microsoft.com 131.107.3.122
131.107.3.123
mailc.microsoft.com 131.107.3.121
131.107.3.126
I think the industry term is "eat your own dog food". thanks for the recommendation MS, let me know when you start using your own bloody system.
There is nothing against patented standards in the IETF policy guidelines. They've already issued a standard on firewalls which is patented (VRRP).
The OpenBSD created their own protocol (CARP) so they wouldn't have to use patented code in their code base.
"Home email servers" are exactly what these concepts are trying to kill... every DHCP typhoid zombie box out there that sources this spam-trash is a "home email server." From the outside looking in, your machine will be no different from them unless you take a few steps.
With that said, all isn't lost - you simply need to set up a legit domain to host your SPF records / etc. It won't be incredibly trivial, but then it isn't supposed to be - otherwise, some spammer could simply do it also, and we're back to square one.
help me i've cloned myself and can't remember which one I am
In less than a week, IETF Last Call for this standard will be over. As of the moment, there is no consensus on the Microsoft patent issue. This will almost certainly prevent the standard from moving forward. The IETF is too divided on this issue for the standard to progress as it is.
Also, a clarification of how the IETF handles patent claims seems to be in order.
Patents are allowed in IETF standards under any terms that the working group feels are acceptable. In most cases, since the goal is to produce a standard which is useful to the largest group possible, patented methods are only used if the patent holder is willing to grant a very permissive license.
For example: The latest working group I was part of was SEND (SEcure Neighbor Discovery), a part of IPv6. SEND makes use of Cryptographically Generated Addresses, which are patented by Erricson. Erricson agreed to license the patent on the terms below:
In addition, for the CGA submission, if said submission is included in the IETF SEND standard and Ericsson has patents that are essential to the implementation of such included submission in said standard, Ericsson shall not assert any such patent against any company or legal entity using said patents in the IETF SEND standard. The Ericsson non-assertion is conditional upon such company or legal entity not asserting any patents within the IETF SEND standard against Ericsson. For all other purposes Ericsson's general patent license statement as referred to above, shall apply.
This is a fairly normal license for the IETF and was found to be acceptable. In almost every case where a patent is relevant to one of our standards, a licence statement such as this one is provided.
The Microsoft license is different, and has sparked quite a bit of discussion. Since this standard has a very large intended audience and there is significant concern over the terms of the license, unless Microsoft changes the terms of their license, this will stop the standard from progressing as is. Either the standard will be restructured to avoid using the methods claimed in the Microsoft patent, or the working group will terminate without a standard.
A lot of people are irritated about this.
I'm a signature virus. Please copy me to your signature so I can replicate.
some apache.org subdomains have txt records:
$ host -t txt xml.apache.org
xml.apache.org TXT "v=spf1 mx -all"
w3.org started rejecting forgeries based on SPF records about a week ago, and has been rejecting about 10000 forgeries/day since then, including:
52 jakarta.apache.org
18 xml.apache.org
a few other domains that have been forged and rejected according to their SPF records:
1628 amazon.com
222 gmail.com
175 redhat.com
129 lists.sourceforge.net
17 sourceforge.net
(numbers above are # of rejections in the first week)
FWIW, EasyDNS has supported adding TXT records to your DNS entry for a few months now.
They're a little more expensive than the other DNS service providers out there, but they provide backup MX servers, and I haven't had a single problem with them in 2 years.
And no, I don't work for them, nor am I a member of their affiliate program.
I just want to take over the world...Why does that automatically make me EVIL?
On the 27th of last month, the author of the Courier mail system, Sam Varshavchik, announced that Sender ID would not be supported by his MTA software due to the Microsoft patent problems, but that SPF would be. The following is a copy of that eMail.
:-)
--
The purpose of this message is to clarify my plans for any deployment of the Sender-ID specification in Courier (http://www.courier-mta.org).
Microsoft has made certain patent claims on the Sender-ID specification. Microsoft has issued the IPR disclosures and royalty free license required by the IETF. It appears that IETF's contemporary policies do not prevent the sponsor/advocates from including patented IP material into standards-track specifications, without even requiring the sponsor to actually enumerate and identify their intellectual property; a mere claim of the existence of some nebulous IP rights is sufficient, which can be revealed at any point in the future, at the sponsor's discretion.
The current development version of Courier implements the original SPF-classic specification, that predates Sender-ID. This will be rolled into a forthcoming release. I'm quite pleased with the results so far -- there are a lot of classic SPF records in existence, as witnessed by my mail logs
It will not be possible for me to implement Sender ID in Courier. Courier is licensed under the GPL. The FSF already flatly stated that Microsoft's IP license is not GPL compatible. I reviewed the most recent version of Microsoft's proposed IP license, and I've reached the same conclusion. For this reason Sender ID cannot be implemented in Courier; Courier's implementation will be limited to the unencumbered SPF-classic.
--
Sam Varshavchik
http://www.courier-mta.org
grep -c helps avoid unnecessary use of wc -l
What were the skies like when you were young?
Indeed:
s p
http://www.eweek.com/article2/0,1759,1639576,00.a
qouth Allman: "...the legal folks made it further clear that they would rather see Sender ID die than back down"