How is it MUCH easier to implement? The sender's DNS record is the same. On the receiving end, the difference between the to is parsing headers to find the 'responsible domain.' The hard part of the implementation is writing all that crazy macro language parsing.
>The main reason I have setup SPF for my clients is that AOL and Yahoo will probably start dropping all email without a valid SPF record soon.
No way that happens anytime soon. They have way to many users to do that. Imagine their customer call volumes if they woke up tomorrow and began rejecting all of ebay's mail, hotmail, yahoo, comcast, SBC, and tens of thousands of other domains. Its going to be a long time before those guys reject because a record does not exist.
Sender ID and SPF can positively prove that a message came from a domain, but can't prove it didn't come from a domain -- they don't stop forgery. The technologies ignored the fundamental architecture of email (store and forward instead of point to point), and in the process left a glaring hole for spammmers to use. How do you forge an email in the Sender ID/SPF world? You pretend that you forwarded it legitimately. In Sender ID with PRA, the spammer simply adds a Resent-From header. In SPF, the spammer makes the Envelope-From something different than the body From:. Both SPF and Sender ID leave these cases for the spam filters to figure out. If the spam filters can't figure it out today, there is no reason to believe they will figure it out tomorrow. We need a crypto solution to solve this correctly. How is domainkeys doing?
IETF really screwed themselves with this post. The patents were posted today by the patent office.
http://www.imc.org/ietf-mxcomp/mail-archive/msg048 44.html
and http://appft1.uspto.gov/netahtml/PTO/search-bool.h tml
and type 684020 for Application Serial Number in field1.
Now the IETF engineers have to pretend they are patent lawyers. Of course they couldn't have said that they were rejecting it because people didn't like the license -- the license does all the things that the IETF requires.
I'm not so sure it will lose. AOL and Earthlink have both publically said they will be supporting DomainKeys in the very near future. Add Yahoo (which hosts SBC and British Telecom's mail) to the mix, with a more elegant and open solution, and I think there is a chance...
Assume that example.com publishes SPF records and that this mail passes that check. The spammer has just passed its authentication check and successfully forged an email.
Lets make this a little more practical. Spammer buys CD of million names. >grep '@pobox.com' $id@pobox.com
He then sends mail to $id@pobox.com through his domain (even with valid SPF records). To hide his tracks, he continues forging -- saying that he received the mail from yet another forwarding service (ie, puts in a fake resent-from).
Pobox.com receives the mail, validates that the mail is from spammer and forwards it along to the end user. The end user's system verifies pobox's SPF -- bingo, we have gotten a forged email through. SPF delegates the identity check to domains that you do not control. In today's world that is not a good idea.
Today, 60-80% of the mail coming from pobox.com is spam. If the receiver applies pobox's reputation to its mail, then it should reject all its mail. I assume that would not make Meng happy.
More and more people are realizing that authentication is not an anti-spam solution, but that authentication allows reputation and other antispam components to be built on top of it. Unfortunately this is exactly why SPF will fail.
Not fair? The percentages used mirror real life -- 80% of mail is spam if not more. For a spam filter to say that it can't do well unless you run it in an academic environment -- one that does not mirror the real world -- strikes me as a lot more unfair than this unbalanced set.
Yesterday at the Inbox Conference, one of the panelist said that over 500 domains of known spammers were publishing SPF records. One of the mail points of this technology is that its braindead easy to publish the record. In the example you state above, you use the ~all flag -- meaning that any IP address across the internet can send mail for that domain, thus avoiding solving the security problem you mention. Can you remind us all again why you thing this will stop spam?
Slashdot Mirror
Domainkeys. http://antispam.yahoo.com/domainkeys
How is it MUCH easier to implement? The sender's DNS record is the same. On the receiving end, the difference between the to is parsing headers to find the 'responsible domain.' The hard part of the implementation is writing all that crazy macro language parsing.
Check out your post's inaccurate paraphrasing of the article... The article was written by Andy Sullivan for Reuters -- not Yahoo.
>The main reason I have setup SPF for my clients is that AOL and Yahoo will probably start dropping all email without a valid SPF record soon. No way that happens anytime soon. They have way to many users to do that. Imagine their customer call volumes if they woke up tomorrow and began rejecting all of ebay's mail, hotmail, yahoo, comcast, SBC, and tens of thousands of other domains. Its going to be a long time before those guys reject because a record does not exist.
Sender ID and SPF can positively prove that a message came from a domain, but can't prove it didn't come from a domain -- they don't stop forgery. The technologies ignored the fundamental architecture of email (store and forward instead of point to point), and in the process left a glaring hole for spammmers to use. How do you forge an email in the Sender ID/SPF world? You pretend that you forwarded it legitimately. In Sender ID with PRA, the spammer simply adds a Resent-From header. In SPF, the spammer makes the Envelope-From something different than the body From:. Both SPF and Sender ID leave these cases for the spam filters to figure out. If the spam filters can't figure it out today, there is no reason to believe they will figure it out tomorrow. We need a crypto solution to solve this correctly. How is domainkeys doing?
IETF really screwed themselves with this post. The patents were posted today by the patent office. http://www.imc.org/ietf-mxcomp/mail-archive/msg048 44.html
and http://appft1.uspto.gov/netahtml/PTO/search-bool.h tml
and type 684020 for Application Serial Number in field1.
Now the IETF engineers have to pretend they are patent lawyers. Of course they couldn't have said that they were rejecting it because people didn't like the license -- the license does all the things that the IETF requires.
I'm not so sure it will lose. AOL and Earthlink have both publically said they will be supporting DomainKeys in the very near future. Add Yahoo (which hosts SBC and British Telecom's mail) to the mix, with a more elegant and open solution, and I think there is a chance...
gmail currently doesn't include .s in their counting of letters for username purposes.
How is SPF going to deal with the Malicious forwarder?
Resent-From: pretendsitslegitforwarder@example.com
From: security@ebay.com
Subject: $I_wanna_steal_your_identity
$Body
Assume that example.com publishes SPF records and that this mail passes that check. The spammer has just passed its authentication check and successfully forged an email.
Lets make this a little more practical. Spammer buys CD of million names.
>grep '@pobox.com'
$id@pobox.com
He then sends mail to $id@pobox.com through his domain (even with valid SPF records). To hide his tracks, he continues forging -- saying that he received the mail from yet another forwarding service (ie, puts in a fake resent-from).
Mail From:
RCPT TO:
Resent-From: $id@pobox.com
Resent-From: spammer
Resent-From: another_forged_legit_domain
From: security@ebay.com
Subject: $I_wanna_steal_your_identity
$Body
Pobox.com receives the mail, validates that the mail is from spammer and forwards it along to the end user. The end user's system verifies pobox's SPF -- bingo, we have gotten a forged email through. SPF delegates the identity check to domains that you do not control. In today's world that is not a good idea.
Today, 60-80% of the mail coming from pobox.com is spam. If the receiver applies pobox's reputation to its mail, then it should reject all its mail. I assume that would not make Meng happy.
More and more people are realizing that authentication is not an anti-spam solution, but that authentication allows reputation and other antispam components to be built on top of it. Unfortunately this is exactly why SPF will fail.
Has anyone sold smather's email and other address information to the spammers yet?
Not fair? The percentages used mirror real life -- 80% of mail is spam if not more. For a spam filter to say that it can't do well unless you run it in an academic environment -- one that does not mirror the real world -- strikes me as a lot more unfair than this unbalanced set.
Yesterday at the Inbox Conference, one of the panelist said that over 500 domains of known spammers were publishing SPF records. One of the mail points of this technology is that its braindead easy to publish the record. In the example you state above, you use the ~all flag -- meaning that any IP address across the internet can send mail for that domain, thus avoiding solving the security problem you mention. Can you remind us all again why you thing this will stop spam?