Slashdot Mirror
IETF Decides On SPF / Sender-ID issue
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."
SPF and Sender-ID don't prevent spam, they are used so that systems recieving e-mails can verify that e-mails are sent from servers that are authorised to do so for particular e-mail addresses. This prevents JoeJobs and (hopefully) allows for faster tracking of e-mail abuse. Spammers implement/support SPF or Sender-ID records in order to circumvent systems that discard e-mails that SPF or Sender-ID marks as spoofed.
combatting spam. It's about being able to verify that the envelope sender is actually authorized to send mail for the domain in the envelope. That is all.
HAND.
Yes, the IETF does accept proposals which are subject to IPR claims in whatever form.
Here's for more information about the official IPR position of the IETF:
http://www.ietf.org/ipr.html
-- "Life is a bitch - and she hates me..."
My mail server is setup so users can waive spf on a per-address basis. That way if their forwarder doesn't have SRS, they can choose to skip out on the benefits.
With my MTA of choice (exim) it's pretty easy to do.
The domain you are sending as is what matters. So if you send mail from renelicious.com through your ISP, renelicious.com just needs an spf record that looks something like "v=spf1 include:yourisp.net -all"
Your ISP doesn't need to do anything at all.
I think you need to read up on this flaw a little better. What SPF breaks is pre-delivery forwarding (not the forwarding you would associate with the forward button in your email program), which is the ability for an email to go from one smtp server to another and then to another until it reaches its destination server.
This is a non-issue however, because most sane people that run good email servers do not allow smtp pre-delivery forwarding to take place at all (unless its for messages that are being forwarded to another one of their own servers) as this "feature" (when manipulated correctly) can be used to make their servers into open relays, thus making them into some spammer's bitch.
And yes, for those that need pre-delivery forwarding, there are workarounds available.
While not designed to stop spam, I'm more than sure spam was a big consideration. Certainly it impacts on spam - either spammers have to use domains the have bought - which leaves a paper trail most spammers would rather didn't exist or not use SPF. If they are using SPF it makes using 0wned computers for bulk mailing a lot more difficult - either they need to do a DNS update for every new machine, ot use -all in the spf record, a flag that would probably then be used by spamassassin to increase the spam score.
You are correct in that SPF won't stop spam, but to suggest that it's not another tool diseigned to be used against spammers is, however, wrong.
Unfortunately, that's what's covered by Microsoft's patent.
Really.
Microsoft want to patent going through a header to see who the message claims to have been sent by - the "Purported Responsible Address" - aka the PRA.
Take a look at the algorithm they are trying to patent and ask yourself how many times you've done this yourself when trying to figure out where mail came from.
It's like trying to patent an algorithm to find the author of a book: 1) look for a name on the cover 2) look for a name on the spine 3) look for a name in the copyright declaration 4) if you've found it, there you go! 5) if you haven't, too bad.
How can they expect to be taken seriously?
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.
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: ...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.
4.
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
The kind of forwarding you are refering to is broken, and should not be done anyway. SPF works at the SMTP-envelope level. There's no reason that your server should forward mail to me, claiming that the mail is "from" some third party unless you're my MX. If none of this makes sense to you, then you should not be posting to Slashdot about why SPF doesn't make sense ;-)
Yakov Shafranovich, the former co-chair of the Anti Spam Research Group (ASRG), has written an excellent dissection of the history of Sender ID, published on the CircleID website. Part 1 Part 2
Opera Watch - An Opera browser blog.
3.5: "CARP License" and "Redundancy must be free":
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.
Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.
Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.
SPF support for most open source mail servers can be found at libspf2.