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..."
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.
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
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)'