On Fri, 2004-07-30 at 18:32, Robert Storey wrote:
SPF - Embrace and Extend?
Richard M. Stallman, otherwise known as RMS, touched off a small
firestorm when he made a post to the IETF mailing list, which was soon
transformed into a Slashdot story. The subject of the message was
"Sender-ID and free software". The interesting part of it all - at
least for me - was that I'd never heard of SenderID.. So I went off to
investigate, and found it all to be quite an entertaining tale.
Indeed. Stallman is quite right. Microsoft should be making use of a
license such as the BSD or Apache licenses that simply state that you
give credit where credit is due in both binary and source code, and that
the licenser is void of any responsibility due to any legal or other
issues that could arise from resulting use of the technology the license
is covering.
Personally, I find it interesting that MS would not license their
useless technology (CallerID) under the GPL since it would literally be
perfect for them, and I'm certain that should someone violate it that
the GPL would wind up in court (finally?)... and of course compound this
with the fact that they have their Patents handy which they claim they
will not enforce... a claim I think is complete bullshit.
Before you can understand SenderID, you need to know about SPF. The
chief promoter of SPF (Sender Policy Framework) is Meng Weng Wong (age
28), a native of Singapore but now residing in the USA. Meng is the
founder of Pobox.com, an email forwarding service. Meng did not
actually invent SPF, but rather forked it from two other open source
projects (RMX and DMP). He was further assisted by SPF co-author Mark
Lentczner. If you'd like to know a little bit more abouthe history of
Spelling mistake there ^ "abouthe" should be about the
SPF and see a photo of Meng, you can look here. There is also this
interesting interview with Meng (published June 29).
I think you should provide a little more background information, even a
single sentence would suffice. Just what is SenderID? You should state
that SenderID is the name chosen for the merger of technology between
SPF and CallerID hence the name "SenderID". In the following paragraphs
you go on to reference SPF in a manner which is fitting of what I've
just said, and if you don't say something to that extent you may confuse
a reader who is just coming onto the scene.
The essential purpose of SPF is to make it easy to detect
address-spoofing, which is a common spammer's trick. If one could
detect address-spoofing with a high degree of accuracy, it would be
possible to create spam filters that would delete all such mail. This
wouldn't necessarily kill all spam, but it would put a sizable dent in
it. Unfortunately, address-spoofing is currently difficult to detect
because SMTP (the primary service for sending mail around the
Internet) does not support this feature.
I would word your descriptive sentence somewhat differently, perhaps
something like:
"The essential purpose of SPF is to eliminate the problem of SMTP
(E-mail) forgery. Initially this forgery was used to simply send out
spam with fake addresses to avoid detection. Today domain names that DO
exist are being used in place of non-existent ones so that the resulting
blow-back of these spam blasts has mail being sent back to the address
that was originally used in the forgery, resulting in an administrative
nightmare."
SMTP (Simple Mail Transfer Protocol) was invented in the 1980s and -
in the opinion of many - outdated and inadequate for the needs of the
modern Internet. Indeed, some have suggested that it should be
scrapped entirely and replaced with something else. Unfortunately,
that would require a lot of cooperation from a lot of people. SMTP is
an integral part of MTAs (mail transfer agents) - that is, mail server
software such as Sendmail, Postfix and Microsoft Exchange Server. In
order to replace SMTP, everybody would have to first agree on a new
standard, and then replace their MTAs all at the same time. Anything
less that 100% compliance would break the world's email system.
You should mention the use of Qmail given that it has had the status of
the second most popular MTA on earth which still could be true however
the survey's that revealed this placement have not continued.
(http://cr.yp.to/surveys.html)
This is where SPF can help. SPF is an additional protocol that can
co-exist with SMTP. It doesn't seek to replace SMTP. In order to use
SPF, a system administrator must install a patch to the mail server's
MTA - patches are available here. Currently, there are patches for
Sendmail, Postfix, Exim, Courier, Qmail and MS Exchange Server. If SPF
catches on, developers may incorporate this feature in the future,
thus eliminating the need to patch.
It should be noted that the Exchange support is limited time. Michael
Brumm is offering the Exchange Server plugin freely until the commercial
entity that purchased the rights to the software from him is ready to
start selling, at which time users will have to pay for it.
Aside from having the requisite software installed, the other major
infrastructure requirement is to persuade domain name registrars to
support it. All domains already publish email (MX) records to tell the
world what machines receive mail for the domain. SPF works by domains
publishing "reverse MX" records to tell the world what machines send
mail from the domain. Those "reverse MX" records are easy to publish:
one line in DNS is all it takes.
The software is not a prerequisite! SPF is easily divisible into two
parts, of which you only need to do one of to participate. The natural
step is to first publish then parse if you are wary, and this has been
what many have done. You can participate simply by publishing even if
you plan to never participate in parsing, although obviously its
recommended that you do both.
So if SPF is so easy to implement, why isn't everybody using it? In
fact, it is catching on quickly - more and more domains sign up
everyday. Sooner or later, critical mass should be reached and SPF
will become an accepted standard.
Unfortunately, SPF isn't the only game in town. A competing standard
named CallerID was introduced by (surprise) Microsoft. Less
surprisingly, free software advocates (as well as many commercial
ISPs) are very leary of CallerID since it is encumbered by Microsoft's
software patents. For that reason, it has not gained wide acceptance.
Not only that, but its proposal its absolutely ludicrous and void of any
wisdom what-so-ever. The very idea of using XML within DNS records
shows the full scope of the retardation of that proposal. This is my
speculation as to why no one has accepted it, because its ludicrous and
a vehicle for the world's largest dDoS attack. Combine also the
aforementioned patent issues and you've got a real stinker.
However, the marketplace is now thoroughly confused - everyone who
understands the issue would like to see a single standard emerge. For
this reason, an attempt is now being made to merge SPF with CallerID,
producing a new standard called SenderID. However, even this new
standard will be encumbered with Microsoft's patents, unless Microsoft
grants a license for unlimited free use, or better yet, donates its
patents to the public domain (don't hold your breath). Members of the
SPF team say that they have been "working with Microsoft lawyers" to
get an acceptable license. These negotiations have been continuing for
over a month, and there is optimism that something concrete will
happen soon, perhaps as soon as next week.
While all this is happening, the IETF (Internet Engineering Task
Force) has formed a group to create a standard SPF (or SenderID). The
group is called MARID (MTA Authorization Records in DNS). IETF is a
standards-setting body, so if it approves SenderID, this could be very
influential. Which is what worries Richard M. Stallman - that IETF
will approve a standard encumbered with a software patent, effectively
giving Microsoft the green light to demand a licensing fee from users
of free software. The big problem is that nobody is even sure what
patents Microsoft holds, but for sure there is one on XML XML which
would effect SenderID. Could we later discover a "submarine patent" -
that is, one which is hidden, but unexpectedly "torpedoes" us when we
least expect it? Microsoft did something like this recently with a
patent on their FAT filesystem. And they are still going for more
patents.
I think this article is going to confuse people, since my interpretation
of it is that you believe SenderID to be a renaming of SPF and that its
separate of the MARID ASRG effort. If I am wrong I apologize, but if I
am right you would do well to open this article up about SPF and discuss
that separately from SenderID.
SenderID is NOT SPF. Its a bastardization of SPF if anything, but your
confusion is not singly yours, since you will find ample reference to
"SPF Classic" as we have been referring to it for clarity reasons.
SenderID is SPF + CallerID, and its scope is a lot larger then that of
SPF Classic.
Of course, the SPF folks are not stupid, and are not likely to agree
to a bad licensing deal. Meng himself is considering taking out a
defensive patent on SPF for one simple reason - to prevent someone
else from getting the patent and then suing for infringement. If SPF
is patented, it could then be declared public domain. But will be
sufficient to protect it? It should be kept in mind that there are
already many silly anti-spam patents, like this one.
Software Patents are stupid. The true morons are the Patent Issuers who
are not technically competent to be issuing such things. You can't
blame Microsoft for looking for and obtaining a Patent since if they
don't do it, someone else will and then they possibly loose out. I
simply repeat that Software Patents are stupid.
So that's where it stands. The SPF developers seem to feel that it's
possible to get a good licensing agreement from Microsoft. Many others
(and not just RMS) are highly sceptical. Which should provide a
fertile ground of discussion for Distrowatch readers this week. Can
Microsoft be trusted?
I am sceptical of any such licensing agreement from Microsoft, and I
personally would refuse anything less then GPL/LGPL/BSD/Apache style
license to the technology, and the patent given into trust of a group
which would be formed to facilitate further and future development of
said technology.
Obviously I do not represent the thoughts of everyone of the developers,
but I can assure you, there are many more than just me who feel close to
or identically the way I have just described.
Good luck with your article and thanks for sharing it with us before you
publish it, excellent way to make sure you get your information
accurate! Are you sure you are a journalist, because double checking
your facts is not behaviour becoming of a journalist ;) ROFL.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part