IETF Approves SPF and Sender-ID

NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.

Comments

Not about spam, it's about joe-jobs.

[khasim]

Before the rush of posts about how this won't do anything about spam, this is not about spam. This is about stopping spammers from using your address which results in your email servers dealing with the mass of bounces and spam reports from clueless admins.

Of course, only the admins with a clue will correctly implement either of these so ...

Re:Not about spam, it's about joe-jobs.

[dsginter]

Joe Job

For those wondering.

Did IETF change their mind?

[ravenspear]

I thought the IETF had already rejected Sender-ID because it was MS proprietary.

Re:Did IETF change their mind?

[pyrrhonist]

I thought the IETF had already rejected Sender-ID because it was MS proprietary.

Yes, they did, and they did not change their mind. They labelled these documents as "experimental". See here for details.

Microsoft related?

[john_is_war]

Hmm... Microsoft announces hotmail will be restricted to user-ID and now it's been passed as an experimental phase. Coincedince? I think not.

Read what ASF had to say...

[tolkienfan]

Sender ID is not particularly trusted by everyone, to say the least.

Example from ASF

It's one SMALL step

[realmolo]

Both SPF and Sender-ID solve only one problem: faked sender domains.

That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.

What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.

In other words, a total revamp of the mail system protocols. ;) We can dream.

Re:It's one SMALL step

[bunnyman]

This article advocates a

( ) technical (x) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

(x) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(x) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(x) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(x) Asshats
(x) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
(x) Extreme profitability of spam
( ) Joe jobs and/or identity theft
(x) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(x) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
(x) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(x) Countermeasures must work if phased in gradually
( ) Sending email should be free
(x) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
(x) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

( ) Sorry dude, but I don't think it would work.
(x) This is a stupid idea, and you're a stupid person for suggesting it.

There is no "Experimental Standard"

[pyrrhonist]

According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards.

There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".

See "The Internet Standards Process":

Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.

Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense.

The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.

Re:Zombies anyone?

[Anonymous Coward]

Because the SPF record is a DNS record. It's not exactly trivial to fake this. Plus, in your specific case, it won't work.

Earthlink owns earthlink.net. Therefore, they get to set the policy for who gets to send mail originating from the earthlink.net domain. I can't set up an SPF record claiming to control who can/can't send e-mail from earthlink.com, because I don't own that domain.

Now, the BIGGER problem is not "faking" an SPF record. It's users who set up their own domain and publish a valid SPF record that includes spammers or zombies. So, I can set up spamdomain.com, and have my SPF record include ZOMBIE1234.earthlink.com as an allowed sender. This means mail COULD come from this zombie that claims to be from spamdomain.com. It's even possible for spamdomain.com to set up an SPF record that says EVERYONE is an allowed sender, and so anyone could send e-mail from spamdomain.com.

So, this won't actually prevent people from spamming. What it WILL do is keep spammers from imitating existing domains in their "from" headers. Which doesn't sound like a lot, but will help with impersonation. It will also make it fairly easy to tell the spam domains. Anyone with an SPF record of "every sender is OK" probably should be blocked as a probable spammer. And anyone claiming to be from a reputable domain actually is. It will also make it harder for viruses that go through your address book for "to" and "from" headers to work.

A central database is open to abuse.

[CyricZ]

Of course we will never see a central database of mailservers. That has been proposed before, but will always be unsuitable for the Internet. Remember, the Internet is meant to be decentralized. And a centralized database is open to abuse by governments, corporations, and whoever runs it (or provides the funding for it).

There's nothing to stop spammers from infiltrating such a system, via legitimate and illegitmate means. So it just plain won't work.

Between the fact that it is easy to abuse, it just won't work and it won't provide any benefits over existing systems, your system is just a bad idea (no personal offense meant, of course).

Re:I'd love to see an Apache Project mailserver.

[shane2uunet]

I'd personally love to see the Apache Project coordinate and release a mail server.

Obviously this guy has not heard of Postfix, a truely awesome mailserver

SPF in the real world

[SamMichaels]

I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.

Re:SPF in the real world

[ryanvm]

I stopped answering my telephone yesterday. So far nobody has called and complained.

Re:What's wrong with this?

[JohnGrahamCumming]

I'm not going to say you're a moron, but how do you allow for legitimate unsolicited email from people?

Currently I receive lots of unsolicited mails from people that I want to hear from. Let's call these people "customers".

Your scheme would have me polling only people I have already talked to.

John.

Re:Sender ID = Caller ID = Worthless

[joebubba]

In Qwest territory, incoming calls with no number never ring here. They are given the opportunity to unblock their number, or to manually key it in. Either choice will let the call ring through.

I've only had the pleasure of one telemarketer bold enough to get through that and my "no solicitation warning". After I got them to give me their information I informed them that my number is on the Fed/State do not call list and I reported them.

It has only happened once. My phone is now forever dead quiet unless it is someone I actually want to talk to.

Um, no.

[Anonymous Coward]

Let's place the blame where it is due. If the recipient's ISPs are rejecting your bosses' mail on the basis of SPF records (as you claim), it means your boss is sending mail through a SMTP server which is not authorized by the SPF records you have published.

Which means your bosses' machines are misconfigured. It's lame to try to lay the blame for that on SPF, which, while imperfect, should never lead to cases like this.

Re:Um, no.

[taustin]

You are completely, totally, and entirely incorrect, and know nothing about the situation.

We are 100% SPF compliant. Tested and everything. The server we send through is on the only IP address allowed in our SPF record.

The address we send to is a virtual domain that does not offer POP3 mailboxes, only forwarding service. This is not under our control. It forwards to a third domain, also not under our control, that rejects based on SPF, because the second server - the forwarding service - does not rewrite the MAIL FROM address (and is not supposed to, so far as I know, under the RFCS).

All three machines are 100% compliant wit the RFCs, and the two using aspects of SPF are 100% compliant with those specs. And yet, legitimate email is being rejected.

And the only way around it is to misconfigure the server not using any aspect of SPF to violate the RFCs regarding how email is supposed to work.

Or, even better, use -all on our SPF, and thus explicitly enable precisely the kind of forgery that SPF is supposed to prevent.

That is the very definition of a broken system.

Pay To The Order Of

[Doc Ruby]

I thought the IETF wouldn't approve patented specs as standards. This MS move to take over the Internet must come bundled with some pretty good checks to "the right people".

Parent is OVERRATED

[Medievalist]

It's all well and good that something is being attempted to alleviate spam in this manner

SPF and Sender-ID are anti-forgery technologies that do nothing to block spam .

There is ample documentation available. Try this if you've got a PDF viewer.

I believe that is the problem with forwarding.

[khasim]

http://spf.pobox.com/faq.html#whichfield
So, this is implementation specific, but it seems that it will compare published SPF record of the domain in the FROM: or the return path with the fully qualified domain name of the sending machine (zombie123.earthlink.net yields "earthlink.net").

So, if the incoming email claims to be from/return-path taco@slashdot.org and slashdot.org publishes an SPF record, that SPF record had better list zombie123.earthlink.net as a legitimate mail server or it will fail.

What, specifically, happens when it fails is also up to the implementation.

The problem appears when taco@slashdot._org sends an email to my old college which offers forwarding services for alumni.

taco@slashdot._org sends to khasim@example._com

mail.example._com forwards that message to my gmail account.

mail.gmail._com checks the From:/return of slashdot._org and checks their SPF record for slashdot._org.

slashdot._org does not list any example._org boxes as a mail server so the message fails the SPF check.

Again, what happens at this point depends upon the implementation of SPF that is being used. It can range from increasing the SpamAssassin score to dropping the connection attempt.

Re:SPF versus Multiple Sites?

[quantum bit]

No, the solution is that your company should have an external authenticated mail relay that is included in the SPF record.

Authenticated is the key word here. Anybody who's roaming uses the company's relay. Hell, use it internally too and you don't have to change any settings while away. I've yet to come across a mail client that doesn't support SMTP AUTH, and many allow you to "use the same password that I do for checking mail" for convenience.

The mail relay should run on the submission port (587), or better yet over SSL (port 465). This gets around the port 25 blocks and transparent redirects that many brain-dead ISPs and hotels have.

Want to stop spam?

[swordgeek]

Arrest the fuckers. Throw Scott Richter in jail for a decade or two for fraud and theft. Break the back of the organised crime syndicates that are profiting. Revoke FDIC/CDIC approval for banks who benefit from mortgage spam. Have the CEOs of explicitly supportive ISPs (MCI, for instance) arrested and fined tens of millions of dollars. Threaten economic sanctions against countries who don't take reasonable action.

Like most crime, the laws exist to stop the small criminals, and have no ability to nail the true sources. Technology is always used to try to fix this problem, and always fails.