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.
This'll just help to encourage microsoft implement it and then we can all say goodbye to that horrid hotmail.
australian project gutenberg is better than the original.
I dunno, but hasn't this failed with caller ID?
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
It might work a little at first, but within a couple weeks at most the spammers will find another way arround it as they have everything else.
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
there goes my next pay check.....
It'll definatley be a nice step in the right direction. I think it promises to be one of those long/gradual changes that eventually will be all the way in place but it will take time. I'm likin it in any case...
I thought the IETF had already rejected Sender-ID because it was MS proprietary.
What's to stop the spammers from using a zombie to fake the sender id? It's a good step forward (you would know where the zombie was), but the bigger challenge would be to have some kind of capability to restrict mail servers to authenticated ones rather than some kind of recipient call-back mechanism. Otherwise the future of email will be "sender ID from mail server ZOMBIE294346.earthlink.net"
"Scientists don't change their minds, they just die." -- Max Planck
1. Register a 4-letter acronym
2. Start "approving" proposals
3. ?
4. Profit!!
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.
I know this site is for geeks but, wtf is IETF and WTF are all those other acronyms?
Thank-you.
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.
Whey aren't we hearing from the Big Pipes? They should be opposed to the widespread implementation of anti-spam techniques. Indeed, their main financial focus is on the usage of bandwidth. Spam consumes massive amounts of their commodity. They should be against any proposals that will decrease bandwidth usage, as it will hurt their financial bottom line.
Cyric Zndovzny at your service.
"Bounce to sender", what a dumbass feature. You (and Incredimail) don't KNOW who the sender is. That option should be "forward this email to some random person who probably has nothing to do with sending spam".
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.
I'd personally love to see the Apache Project coordinate and release a mail server. Considering their expertise in such matters, forming such a project should be well within their means, and the results would be fantastic! Indeed, combining the quality of Apache httpd with the innovation of their other projects, and there would be a winning combination. They could probably even muster up the talent to combat spam in a sensible, community-friendly way.
Cyric Zndovzny at your service.
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.
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.
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.
Yet again it is proven that we can't trust the editors here to provide valid, truthful news content. Indeed, this is the sort of misleading that I would expect from a lower class site such as OSNews. But thank you for clearing this up.
Cyric Zndovzny at your service.
Is M$ still asserting patent claims over either or both?
Disinfect the GNU General Public Virus!
Spam = Death penalty.. back to being primitive baby!
www.brido.com : not your average blog..
The refined man's Spam
One ring to bind them - should probably have more fiber and less rings in their diet.
I honor spf entries on my mail server. It stops about 1000 emails/day. So far no legit mail being bounced.
who is this joe guy giving all these jobs anyway?
STFU and RTFA!
Why don't we have two types of email...
1) What we've got today - sucks - freakishly low signal to noise ratio
2) Sender Hold Email. I tell my email client the email address of everyone I consider trusted. Largely this is based just on looking at emails that I haven't marked as SPAM. From then on, when I want to read email, my client tries to connect to the address in the sender's email address. My client asks, "Any email for me from this user on your system?"
If you want to imagine the system scaling a bit better, a larger client system representing your domain asks the neighboring domains for emails and sorts them with the same scheme of trust as described above.
The polling rate can be adjusted... Heck, the system can be designed such that the client knows to poll the sender when it receives a notification email through the old system.
Anyway - I officially open this idea to the public domain (assuming it hasn't already been implemented and patented.)
Now comes the part where everyone on Slashdot tells me I'm a moron...
Education is the silver bullet.
SPF: Shortest Path First routing protocol
IETF: Internet Explorer To Firefox conversion
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.
No really, that's all I wanted to say.
...because "hacker" sounds way sexier than "code drone."
That's right, I can't. Because I have no fucking idea what IP or domain name my email is going to be coming from when I send it, and Verizon can change it anyhow.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
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
The big difference is that you don't poll known addresses. You poll when an event is sent from the sender.
There are other differences, take a look.
My goals were slightly different:
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.
The Internet was designed such that every endpoint was a valid one. When you require 'authentication' at the server level for the right to be a valid end point (which is what this is) then you are saying that certain endpoints are more valid than others.
That is not the Internet.
There are far simpler ways to lessen our problems with spam that don't damage the basic relational nature of the medium.
I should not be required to be validated by a third party to send mail...regardless of the spam problem.
-Tom
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.
Admittedly I don't get a lot of spam by most people's measures, but all the spam I get uses at least some form of impersonation.
-- No matter how great your triumphs or how tragic your defeats, approximately one billion Chinese couldn't care less.
So, at my company users like to send company email from home. If they use Cox, for instance, they use their SMTP servers, as everything else is blocked. They send out an email from my domain from Cox. Someone with SPF checks the registry and finds that Cox is not me, bounces the email. Is this the standard result of SPF? Is the solution to run SMTP servers on random unblocked ports for your users and teach them how to send email through them? Does anyone else find this to be a pain? Am I missing some piece?
I thought the IETF wouldn't approve patented specs [zdnet.com] as standards. This MS move to take over the Internet must come bundled with some pretty good checks to "the right people".
They're not checks, they're stock options.
-- Tigger warning: This post may contain tiggers! --
After the Hotmail announcement the other day, I went poking through the SPF and Sender-ID specs to figure out how I could gain the benefits of SPF without rewarding Microsoft for their attempt to subvert the specification and lock out OSS implementations during the original standards discussion. Their behavior was especially nefarious considering the duplicitous and underhanded way they tried inject the patented PRA algorithm into the standard with a serious of slippery half-truths.
For those of you wanting to thumb your nose at MS and their attempt to "embrace, extend and extinguish" the open source MTA's, you have a couple of options.
1) Only mildly breaking RFC2821, you can add the header
Resent-Sender: goaway@microsoft.com
to all of your outgoing mail. This shouldn't have any detrimental effect on MTA's not implementing the PRA algorithm, but will certainly cause any that do to think your email is coming from a "bad-guy".
2) Add the SPF classic records to your DNS and add a "drop all" record for Sender-ID:
"spf2.0/pra -all"
If you want to be more specific, you can change that to "spf2.0/pra,mfrom -all" to drop everything from any MTA/MUA implementing the Sender-ID specification using either the PRA algorithm or MAIL FROM. I wouldn't recommend doing that, however.
Note that any of these steps will possibly prevent your email from being delivered through weak-willed MTAs (but that's kind of the point...).
Let's hope that there's intelligent life somewhere out in space 'Cause there's bugger-all down here on Earth.
They're late. It's already standardized.
What Smallpond says bears repeating --
when reporting spam to anyone but your own ISP (and even them if you are one of certain large ISPs), use a throw-away account.
SPAMbots use their own servers. They can make their own envelopes.
Until we can afford the processor and network time to put a certificate in every item in the envelope, and the processor/network load to look every certificate up, this only pushes the problems back a few weeks.
IETF: Internet Engineering Task Force
They're the people who maintain the RFC's (Request for Comments) that are the basis for the protocols used on the internet. These include the protocols used for packet transmission, email, telnet, ftp, etc.
Basically, they're similar in purpose to the W3C or the X consortium, except instead of document formats or windowing systems they maintain standards for networking.
Now that you know this, you can google for any other related questions you have.
Those who can't do, teach. Those who can't teach either, do tech support.
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
It's a common misconception, that SPF isn't about fighting spam. It is. This is how it works:
SPF is meant to work with other mechanisms. A DNS blacklist is obvious, but internal whitelists are even more obvious. If SPF is used with greylisting, blacklists and bayesian filters, then this is how it can work for specific e-mails:
E-mails from well-known e-mail addresses, that are known not to send spam, are usually automatic whitelisted. If the e-mails are sent from the correct mailservers, they just pass through the entire spamfiltering system. If they are sent from a forged server, they are rejected as part of the SMTP session and never even enter the mailserver.
E-mails from people we don't know, but have SPF records, work like this: If the mailserver is forged, the mail is rejected immediately and doesn't enter the mailserver. If the mailserver is OK, first time they try to deliver the e-mail, the greylisting system activates and delays the delivery. Second time they try to deliver, the sending mailserver and e-mail address is looked up in blacklisting services. If the system is still OK, a bayesian filter is applied. If the e-mail is still OK, it's delivered.
If the e-mail is from a sender that doesn't have SPF at all, greylisting and bayesian filtering is applied as usual, but with greatly increased risk of being marked as spam. Some mailservers may even reject the e-mail immediately because of lack of SPF record.
As you can see, the SPF record is about getting your e-mails through spamfilters. System administrators will experience less load, because the automatic whitelisting in combination with SPF records makes most e-mails pass without running bayesian filtering.
Very obvious domains to whitelist are your own. If you have two or more domains, the mailservers for these should whitelist each other, making all e-mails pass. Since you want to be able to change, which servers you use, SPF records are a good way of communicating to these mailservers, which other mailservers they should trust.
I need to provide a few comments:
- Bad SPF records should be considered as not being there at all. For instance "v=spf1 all" would enable all mailservers in the world, and should therefore be ignored.
- Most spamfighting techniques just put the e-mail into a spam folder. The sender does not know, that the e-mail didn't arrive in the inbox, and that's bad. With SPF, it is much more likely that a non-spammer gets his/her e-mail delivered or bounced because it isn't able to deliver it via smtp to the receiver (misconfiguration).
As long as we want to receive e-mails from people we haven't communicated with before, spam (unwanted e-mails) will exist. SPF just makes it a lot easier to filter them out.
Lars.
What we need to do the SPF thing is a checksum/messageID whatever in every checksum, and then a sender mailserver to contact to verify it has been sent from there. This will allow mail forwarding.
Fighting spam should first be done at the gate, by the receiving mail server. To facilitate that, SMTP should be extended, to create a non-bulk variant of the standard.
This requires a few extensions to SMTP, so that the receiving mail server is allowed to
- limit the number of recipients per message
- limit, per IP-nr and subnet, the total number of messages and recipients per time window (like 24 hours)
- limit the number of concurrent connections, per IP-nr and subnet
- communicate these limits, and the current quota for the specific client, at the initiation phase
Of course, current SMTP implementations can already impose such limits, by rejecting to process the message, like with a 554-reply.Death penalty is too cudly and soft.
.. .. NOW we're talkin ...
25 years quality time down at Guantanamo Bay, -THEN- death penalty (public firing squad maybe?)
> What it WILL do is keep spammers from imitating ...
> existing domains in their "from" headers
It will not and it cannot. It can only stop forging "Sender" headers (Sender-ID) or envelope-from (SPF). The "From" header that is shown to the user of any email client can still be anything,
> Anyone with an SPF record of "every sender is OK"
> probably should be blocked as a probable spammer.
And that is where the current email system starts breaking. You're telling people how to use their eamil. WHere do you stop? What you describe is a system to force people to change their systems. Many would have to change their software or hardware to achieve that, and there's lot of money to be made. That's what MS wants...
> mail.gmail._com checks the From:/return of
> slashdot._org and checks their SPF record
> for slashdot._org
Actually they do not. Neither SPF nor SenderID check the "from" header. SenderID checks the "sender" header and they require forwarders to add/rewrite this header (or use one of the "resent" headers). SPF checks the SMTP envelope from and they expect forwarders to produce one in their own domain and arrange for relaying relayed mail/error messages. The "From" header can be anything. Forwarders complying would get through. So will phishers, using exactly the same methods.
This article advocates a
( ) technical ( ) legislative ( ) market-based (x) 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.)
( ) Spammers can easily use it to harvest email addresses
(x) 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
( ) 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
(x) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) 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
(x) 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
( ) Asshats
( ) 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
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) 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
( ) 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
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
(x) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
(x) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
I use to have an ISP that wouldn't let me send mail unless I used their server. Luckily I could still change my From: header to look like it came from my real address instead of the horrible ISP one.
With this SPF crap, it sounds like I'll be screwed.
My main address is 95% spam. But I've had it since before the telcos even coined the DSL acronym. I don't want to stop using it! I just want the spam to go away.
But since Sender ID, I _still_ receive ever more spam but now I can't send email to, among others, my wife AND come November, I won't be able to email any of the poor souls using Hotmail.
I *will not* use the email address my DSL provider's assigned me. Their mail server has 1/10 the reliability of my regular address.
Sender ID (in my experience) hampers spammers NOT ONE IOTA but it jerks me around. A LOT!
Don't jerk me around; execute spammers!
But that won't happen. They won't even slap their wrists hard.
I'll just stop using the net at the end of the year. It'll just be too useless to bother with by then.
Astro