Slashdot Mirror
FTC Wants Comments on Email Authentication
An anonymous reader writes "Groklaw has the scoop. The Federal Trade Commission and National Institute of Standards and Technology (NIST) will co-host a two-day 'summit' November 9-10 to explore the development and deployment of technology that could reduce spam. The E-mail Authentication Summit will focus on challenges in the development, testing, evaluation, and deployment of domain-level authentication systems. The FTC will be accepting public comments until Sept. 30, 2004 via snail-mail or email (authenticationsummit at ftc.gov). The FTC has a list of 30 questions they would like answers/comments to. The list available in this PDF of the Federal Register Notice." In a related subject, reader Fortunato_NC submits this writeup of the sequence of events that led to Sender-ID's abandonment.
You only found 2 issues with SPF?
How about a few more
Since I wrote that, I've managed to come up with SPF rulesets that cause DOS on some of the common implementations, my dns has been scaned countless times looking for SPF records and I've had over 1000 spam messages with valid SPF records.
Yes it will. Almost all of those trojanned machines send mail directly to the receiving server, not through the mail relay of the spoofed sender. If the email purports to be from jblow@someplace.com, the receiving mail server can check someplace.com's spf record and see that the ip address of the trojanned machine is not allowed to send mail. That is the very essense of what it does.
You are correct that a spammer with a server can publish an spf record, but he is much, much easier to blackhole than a rapidly changing large selection of compromised dsl machines.
There are two kinds of sysadmins: paranoids and losers. I'm both kinds.
I'd like to know how many of those domaines actually are applying effective policies.
SPF is great for communicating a domain's policy and for allowing the reciever to check for compliance, but this does little if the originating domaine's policy is lax (or worse, "no policy). This brings us back to what I have seen as the heart of the SPAM problem since the beginning, ISPs are all for protecting their users from SPAM, but as soon as you ask them to do something about spam originating from within their domain, they act as if nothing can be done. Only if the ISP is willing to set an effective policy, and is willing to take measures to enforce it, does SPF help to reduce spam.
That said, SPF does appear to be the most effective and implementable tool that has been proposed for ISPs to use in the fight against SPAM so far. I just hope all of those participating ISPs have admins that are capable of using it effectively.
Read, L
It doesn't cope with world hunger, the war in Iraq, or many other issues. SPF doesn't really have anything to do with unsolicited email. Its only intented effect is to make solicited email more distinctive. This can eliminate some significant false positives in spam filters (email that would be spam if it weren't sent from a government agency that you had applied for a grant from, for instance).
SPF will not prevent or help mark any email as SPAM. It will mark a lot of phishing scams as forgeries. It will let people avoid having spam sent with their address forged on it. It will give people sending non-spam to people who know them a way of marking their email as non-spam in a way that is very difficult for spammers to imitate.
Not only do I expect many F/OSS people to be allowed in, I expect the concerns of deploying anti-spam solutions in F/OSS mail servers to be front and center. I also expect there to be people who don't give a flip about F/OSS to be there too, along with a bunch of spammers^Wethikal bidnizmen.
SPF support for most open source mail servers can be found at libspf2.
Repeat after me, "SPF DOES NOT PREVENT SPAM. SPF DOES NOT ATTEMPT TO PREVENT SPAM. IF YOU EXPECT SPF TO PREVENT SPAM, YOU WILL BE DISAPOINTED."
Ok, yelling done (sorry, but this comes up so often, you'd think the "S" stood for Spam). What SPF *does* do is validate that mail was sent from a machine that was (or was not) authorized to send it by the originating domain.
It's nothing more or less than that. As a first-pass on the roots of the problem of spam, it's a great tool, but I would never suggest that anyone treat it as an actual solution for spam per se. Joe Jobs are mitigated and you can also begin to build a reputation with the sources of SPF-identified mail. Once you get spam from a machine that's listed as a valid SPF sender for that doamin, you have a great deal more information to apply ot that domain's reputation than if you recieved spam from a non-SPF sender.
It's not perfect (SPF has its warts, though I think many of your concerns are too minor to be blasting them over), but it is an excellent start, and combined with various other systems out there, helps to address many existing problems.
I don't like greylisting, primarily for one reason. It destroys the possibility of near real-time message exchange between persons that have never exchanged e-mail. Consider, for example, a salesperson and a potential customer. Waiting an hour for information someone "just now sent" can be costly. Obviously there's no guranteed e-mail delivery timeframe without SPF, but in practice, it typically arrives before I'm off the phone. Because I cannot turn it on or off as an individual mail recipient, I find it somewhat draconian and inappropriate for admins to impose artificial delays on my communications.
I'm amazed that I haven't seen more about Proof of work tokens for spam-fighting.
Proof of work tokens are hashes (like md5's) that take a relatively long time to compute and are very quick to validate. For most purposes, adding a few seconds to the delivery of email is unnoticable. For spammers, however, it greatly decreases the number of emails that can be sent out within a period of time.
Even though this does not completely eliminate the problem, it can significantly reduce the amount of time spent sifting through spam. Used in combination with public-key cryptography, it could even allow for mass-mailings from known users. (For instance, the Red Hat mailing list.)
The current problem with spam is a result of the fact that it takes almost no money to send spam. Increasing the amount of time spammers need to use in order to send out email is the only way to make a dent.
Links:
HashCash.org
Reusable Proofs Of Work
Currently down, but look at the google cache
"My religion is to live --and die-- without regret." -- Milarepa