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.
Most ISO standards (such as MPEG-4) have more patents relating to them from more different companies than you would believe. Although they're supposed to offer non-discriminatory licensing of them, its still licensing.
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.
Patents are always a monopoly.
That said, the answer seems to be no. The IETF can adopt a patent-encumbered method as a standard.
As you can see here, there appear to be quite a number of patents which may or may not relate to IETF standards. And you can see that in these cases, it appears that the IETF demands that the patent is licensed on "fair, reasonable and non-discriminatory terms".. whatever that means.
Note that all you need is the ability to add TXT records to your DNS information. See this list of domain registrars that support SPF.
Watch great movie opening scenes!
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?
Your comment is a bit deceptive. When I first read it, having not read anything but the most brief description of SPF, I thought you meant that it broke forwarding from the client/MUA. In other words, I took what you said to mean that if my mail local servers implemented SPF, and I sent a message to someone, that person would not be able to forward my message to someone else via their client.
But the actual problem you're talking about exists when forwarding is done at the MTA level, which is utilized by a smaller set of users. See this article for more info ("The Price of SPF", about halfway down) for a better explanation.
Keyboard not found.
Press F1 to continue.
That's not what you'll be thinking when a Joe Jobber effectively slashdots your server: you'll say No to a few people at first before your server melts down.
Besides, this would require a fair amount of stateful information on your mail server- what do you think you should do, store a message digest of each message you send? If so, how long do you store it? When do you get rid of it- first time it's asked for? What if no one ever asks for it (probable, given the adoption lag)? What if the mail is delayed several hours for various reasons? It's a rather complicating feature.
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
That only works if you have control of the domain, or the people who do are responsive to your request to add your IP address. It's not going to help me much sending email with a yahoo.com domain in it. There's no way Yahoo will add my IP address to their DNS record.
This means a configuration pain for my MUA, and the loss of logging I get from using my own MTA to transfer directly to the recipient's MX.
Generally though, I'm supportive of SPF as I believe it will make a difference to the volume of messages we have to filter, especially at work.
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.
#1. No, it would not look up your ISP's SPF record. It would look up the SPF record of the domain you claimed to be sending from. If that SPF record included the mail servers from your ISP, it would be fine.
#2. What happens when the SPF record does not exist or does not match is entirely up to the implementation.
Example: SpamAssassin
I can set the rule to add 20 (or any other number) if the SPF doesn't match.
I can set the rule to add 1 (or any other number) if there is not SPF.
It all depends upon which system you use to check the SPF and what the capabilities of that system are.
There are two (at least) types of forwarding.
.forward file to do mailbox forwarding.
Message forwarding, this is when a single message is forwarded to another address or more then one. This should in my opinion should have the From: field filled out with the address of the person who forwarded the mail message.
Mail Box forwarding, this is when all of the mail going to a specific mail box is forwarded to a different mail box. Think of this a what you do with the post office to forward you mail to a new home. This should retain the original from address. However it probably would be a good idea to add something to the headers to indicate that you are receiving that message as a forward from address old@blah.com. Etc.
Most products tend to either do forwards as one or the other. I know that Novell GroupWise only really does message forwarding, while most unix systems use the
Do you mean like .forward [ing] from several accounts on various systems to which ever account I happen to want to read email from?
http://www.hawknest.com/
Doesn't matter what you're running (i.e. old versions of Exchange). For the old-Exchange-org, for their outgoing mail all they have to do is put the TXT records in their DNS. Doesn't matter what their mailer is. For incoming (to use SPF to check incoming mail) all they have to do is have a front-end mail relay in front of their exchange server which deals with the filtering before passing mail onto Exchange -- which they should do anyway, only a nutter exposes an old version of Exchange directly on the internet.
Oolite: Elite-like game. For Mac, Linux and Windows
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)'
Because
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
No software patents are per definitionem fucking evil.
When you patent software, you patent algorithms, and algorithms are nothing but... mathematical formulas. It makes absolutely no sense to patent mathematical formulas, since - if they exist - they can be derived from the mathematical system's axioms. This means that _nothing_ can be invented in the field of mathematics, but only derived from the axioms. Thus, patent law doesn't apply, anyway.
Of course, _implementations_ of certain algorithms can be protected, but that's what copyright is for.
A monkey is doing the real work for me.
Not at all. ISPs generally allow customers to send outgoing mail through the ISP server as a relay. This is very common and has nothing to do with open relaying, as it's only permitting relaying from the customer's IPs.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
This list is not up to date. Ckeck out http://www.spf.idimo.com/ instead.
I know I'm feeding a troll but "Ligitimate Email Marketers" (AKA: spammers) were pushing for SenderID because it forces recievers to accept the entire message before processing. This lets spammers claim successful delivery even without having valid MARID records.
Microsoft wanted SenderID to be visable to end-users (The "PR" part of "PRA"). A convienient way to leverage their desktop monopoly, unfortunately for Microsoft the MARID charter specifies MTA's and not MUA's.
They also wanted XML in DNS and there has been no discussion between Microsoft and the company that brought you the amazing sitefinder service about patenting this and forcing it as a future standard. No-siree-bob, none at all... honestly!
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.
Now Microsoft says they have applied for a patent on reading the headers on an email to determine -- what? Who sent the mail! Could the writers of the RFC 822 have ever imagined that the headers on an email might be used for something so non-obvious -- so brilliant -- as determining the email address, including the domain name, of the person/entity that sent the email?
And Microsoft doesn't even have to be granted this amazing patent to throw the MARID working group into a tailspin. They only have to mention that they've applied for it...