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.
But this will help me out tremendously.
Not getting joe jobbed will be a huge step forward. Not to say that everyone's going to instantly adopt these standards but it won't hurt that these are Official now.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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
It's all well and good that something is being attempted to alleviate spam in this manner, but I think a much bigger problem that needs to be addressed is ISP's selling your email address before you even log in the first time to check your mail. *Cough*Cox*Cough*. I've had 3 seperate email addresses (from 3 seperate accounts) with Cox and each one filled up with junk mail without me giving anyone the email address.
The best thing I have come across so far is Incredimail, but even that is a pain in the ass to right click each spam and choose block sender or bounce to sender. What Incredimail needs to do is come up with an automatically updated block list for known spam. It would help greatly.
In the end, I think that spammers should be beaten, shot, stabbed, hanged, drawn and quartered, eviscerated, castrated, tortured, set ablaze, and be kicked in the shin.
Halitosis - (n.) Halle Berry's Camel Toe.
Example from ASF
within a couple weeks at most the spammers will find another way arround it as they have everything else.
Do you even understand how SPF works? It sure sounds like you don't. It's meant to prevent spammers from forging domains, not to put an end to all spam. If you own your own domain then something like SPF can be a HUGE help if your domain name is used to forge spam.
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.
Since SPF doesn't even claim to be a method of reducing spam, why would anything think it would?
As it happens, a couple of my bosses have been having email rejected recently by the receiver's ISP because we are SPF compliant.
SPF breaks email forwarding, and most mailing lists. It's a bad idea, poorly conceieved, and poorly implemented.
No matter what we do, SPF will cause some of our email to be rejected.
That is a way to help spammers, not hinder them.
Yes, they did, and they did not change their mind. They labelled these documents as "experimental". See here for details.
Show me on the doll where his noodly appendage touched you.
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.
It might not be a lot of spam, but it's quite a lot of mass-mailed viruses. The vast majority of virus attachments get opened because "oh, my friend sent this to me". Stopping a virus from harvesting address book entries and impersonating everyone in it easily is a Very Good Thing Indeed.
No, it won't put a stop to anything, but it WILL help with the most important vector for virus transmission, and that's clueless users who assume the "from" line is always legit...
Obviously this guy has not heard of Postfix, a truely awesome mailserver
This space available for rent.
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.
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".
--
make install -not war
They aren't, "conducting an experiment". The draft was submitted as "experimental".
Unless MS have pressured them into it, so they can get a crack at declaring Sender-ID as the de facto standard and thereby sidestepping the standards process, of course. That might explain it.
They aren't "sidestepping" the standards process. An "experimental" designation is part of The Internet Standards Process, but is not on the standards track.
Show me on the doll where his noodly appendage touched you.
There is ample documentation available. Try this if you've got a PDF viewer.
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.
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.
I stopped answering my telephone yesterday. So far nobody has called and complained.
Mods are on crack. You're closer to funny than insightful, and it's "funny" as in "so far misguided that it's amazing you're not a Darwin Award recipient." The OP's point is that for domains that already offer an SPF record, checking that record allows them to reject a fair number of messages. Your analogy is like rejecting by default, whereas they are accepting by default and rejecting if verification information is available and fails.
My opinions may have changed, but not the fact that I am right! =)