Slashdot Mirror
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.
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
I thought the IETF had already rejected Sender-ID because it was MS proprietary.
Hmm... Microsoft announces hotmail will be restricted to user-ID and now it's been passed as an experimental phase. Coincedince? I think not.
Live life to the fullest. It's not that life is short, but that you are dead for so long.
Example from ASF
Both SPF and Sender-ID solve only one problem: faked sender domains.
;) We can dream.
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.
There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".
See "The Internet Standards Process":
The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.
Show me on the doll where his noodly appendage touched you.
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.
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).
Cyric Zndovzny at your service.
I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.
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.
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.
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.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban