Slashdot Mirror
Yahoo Submits DomainKeys Draft To IETF
NetWizard writes "According to a mailing list post at the IETF, Yahoo's website and a Wired News story, Yahoo has made the DomainKeys draft public and submitted to the IETF." Russ Nelson explains "Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice. There's also a SourceForge project for a DomainKeys library."
An anonymous reader asks "It seems to me that it doesn't offer anything more than the Sender Policy Framework by pobox.com, other than doing relay-based signing of the messages to provide the sender verification. SPF has already grown to over 14,000 domains so far and only requires an addition to your DNS to support (from the sending side). Verifying messages on the receiving MTA is as simple as doing a DNS lookup, most MTAs can support SPF now, the code is available and well tested. What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?"
Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice.
Computationaly that sounds mighty expensive...
OK... It seems that SPF would have a little easier setup, only requires setup on one side. While DomainKeys would have more of an upfront cost to get it working and setup costs on both sides. However, pobox.com has theirs software up an working while Yahoo only has a working document to offer proof of concept. I would like to see Yahoo's example up and running and see how it would compare once out in the wild.
Hmmm.
Email needs to get a few new features like gpg or this to fight spam, viruses and spoofing pranks.
And it better be an open solution not a proprietary one.
The only way I can see something like this happening though is if a few major backers get behind the same thing and most mta's/clients (depending on what the agreed upon implementation is) start supporting it.
Artists against online scams http://www.aa419.org/
Why not just use pgp or something of the sort?
GeekLeak.com - Silly name, serious geeks
Can anyone see if it has a harmful patent license like Microsoft's Caller-ID?
There's more info on why CID's patent license is harmful at the boycott caller id for email site.
I barely have the patience to hold down CTRL when I hit Enter to send emails.
God fuck me in the ass if I'm going to be required to do all that other crap.
SPF breaks forwarding. Domainkeys doesn't. That alone is a serious enough problem that I can't implement SPF.
SEOUL - CRUCIAL TALKS here this week on Meng Weng Wong's SPF ambitions made modest progress but failed to bridge the divide on major issues concerning the 11-month tension.
Wrapping up their two hour negotiations Thursday, Wong, Danisch, Fecyk, Brand, Hardie and Fältström adopted a chairman's statement in which they agreed to set up a working group for detailed discussions and hold the next talks in August, at San Diego...
Use Evolution instead of Outlook? Bewa
But doesn't this miss the point of spam?
Based on articles refered here on Slashdot, I'd assumed a major source of spam were machines that have been compromised. Spammers use known lists of unwitting relays to forward spam through legitimate hosts.
Email today will tell me the name of the host where something came from, that doesn't really help. At best, I could (a) contact the owner of the domain (which I can do today) (b) develop a list of open relays that I won't accept mail from (which I can do today).
It seems to me the net effect of this is to limit email to large ISPs. It won't be good enough for me to buy a T1 and run my mail server from there, I'll have to rely on Yahoo, MSN, AOL, Comcast and a few others to be my MTA because people won't accept mail from a small provider (or a single point system) any more.
I'm the SysAdmin of an ISP. We had to turn off SPF after some users couldn't send e-mail to people that used mail forwarders. For instance, if someone has a domain 'foo.com' that sends all mail sent to it to 'foo@verizon.net', and foo.com resides outside of verizon.net, my users wouldn't be able to send him mail if Verizon uses SPF.
SPF is junk. The number one priority of e-mail: Legit mail must reach the recipient.
What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?"
The only additional standard this needs is a "caliber".
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
SPF's handling of relays is broken:
If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I know this perhaps sounds silly. Could someone perhaps keep bouncing messages off the MTA and using the signed messages from that to try to decrypt the cipher and such? If a system is compromised (i/e: with a virus/worm) couldn't the technology be defeated via that as well? Signing messages like that sounds like a good idea but when you have weaker links or loopholes that aren't readily being fixed or are being ignorant by apathetic admins how does one handle that?
( o ) one could say I'm rather baked
The post above has the wrong URL. The site that describes the patent issues with caller id for email is actually boycott-email-caller-id.org.
It has a brief mention of domainkeys as well.
Cut to the chase. Is this going to make it any harder for me to send and receive email from my small (2 person) domain?
You want to implement both. SPF detects envelope forgeries before you have wasted much bandwidth. You can then use right hand side blacklists on sender domains. Yes, spammers too are adopting SPF. This is OK - those who like spam have something other than instinct to warn them when they are dealing with a scammer instead of a spammer. Those who hate spam can ignore it more efficiently.
Domain Keys validates the message headers. It protects you against forgeries by users in the same domain - e.g. a spammer on yahoo forging an innocent party on yahoo. SPF can also detect envelope sender forgeries from the same domain in conjuction with SES (Signed Envelope Sender) - which adds a crypto cookie to the local part.
You should implement SPF first. It is simpler, and eliminates most forgeries before SMTP DATA. SPF requires sepcial consideration for forwarders (SRS - Sender Rewriting Scheme) or whitelisting.
DK is a good addon for large ISP domains like yahoo and aol, but is broken by forwarders or mail processing tools that modify the body. For instance, my DSPAM bayesian filter adds "tags" to messages.
Yet another Your Rights Online that doesn't have anything to do with alerting the Slashdot crowd that perhaps one of our basic rights in the electronic age is being infringed or will be degraded to the point that someday it will be gone.
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
Really, the constant usage of YRO for these kinds of articles is diluting the effectiveness that YRO is supposed to handle. Keep these in articles, editors, please!
Human nature is the same everywhere; the modes only are different. -- Earl of Chesterfield
1. Domainkeys does not break forwarding.
2. Domainkeys can be used either on the MUA or the MTA, for both sender and recipient sides. This makes it possible to still use 3rd party relays.
3. Domainkeys spoof-protects the domain in the "From:" header field, which is what Joe Sixpack sees in his MUA application.
Domainkeys does have the problem that you can't add headers to messages without re-signing them. If you re-sign them you must also rewrite the "From:" header. This will affect mailinglists.
Domainkeys will not ultimatively solve the spam problem, but it is better than the broken SPF.
SPF tries to assure the sender of the message (MAIL FROM, return-path, whatever you want to call it) is legitimate. DomainKeys can be used to assure the author of the message (From: header) is legitimate.
I quote this from the very top of the SPF FAQ itself:
"Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys."
Ironically, the word ironically is often used incorrectly.
Marginally better in theory because the sending hosts can change without requiring DNS changes, but in truth neither approach has much of a hope of affecting spam in any significant way. Might as well standardize over SPF which is the more estabilished method, instead of fragmenting further.
Still, even if all of the sender verification and SMTP hardening methods were to be universally implemented, spam would just work its way around them, and even appear to be more legitimate, as long as throwaway domains are an option. You'd just get 100%-authenticated emails from 1stmortgageusa.biz and naturalviagra4u.com.
The only real weapons against spam are legislation and enforcement.
This is definitely targeted to the big players. Yahoo, MSN, GMail and the like. I can't see how this will change anything in regards to how spam is "sent". The Rennen
SPF requires you to send mail from certain IP addresses or at least relay it via certain servers. Sounds to me like the Yahoo! proposal does it without this requirement.
Not bad, but far more complexity.
Do I really want all this extra code in my small, secure qmail-smtpd binary?
these acronyms. JWTFIGOWE?
(Just what the heck is going on with email)
Anyone able to give me a quick run down in human?
will cause some admin log watching heads to turn..."boycall....org?" "Wonder what they are in to?"
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
I admit that I haven't studied the proposal in detail, but if all it does is guarantee that the sender address isn't spoofed, then it's hardly a significant improvement over the present situation.
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when asked to identify the spammer behind authenticatedsender@optin.business.tld, or is there some postal address hidden in the digital signature?
And if you think sender authentication will prevent obscuring the origin by using millions of 0wned proxies, think again. Unless the authentication process requires manual intervention by the sender for each message (say, by requesting a password), all the data necessary to authenticate a sender will be found on the machine at risk of being 0wned. Instead of seeing junk from moremoney@hotmail.com via your neighbour's IP address, you will see junk from your neighbour's authenticated e-mail address via your neighbour's IP address.
If all e-mail is required to come with a valid sender address, all spam will come with a valid sender address too, and we are back at square one.
The same goes for SPF.
smtpauth isn't always an option, and most DNS hosting providers don't make it terribly convenient to keep on adding and removing temporary TXT records as necessary, nor would a company's IT department be terribly happy about needing to do the same for corporate travellers.
What needs to happen instead is a domain having a public key registry (probably provided via NAPTR records; just do a NAPTR query on, for example, username.example.com and then get either NXDOMAIN or the public signature) and then signed messages. Of course, the fun thing then is the limit of the size of an NAPTR record, so it'd have to be a pretty small key. For this purpose I don't think it's necessary to have more than a 128-bit key or so, though, especially since discarding keys is so trivial (just set a TTL of 30 on the records and use dynamic DNS updates or whatever).
There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
My passphrase is 1,2,3,4. Or is that l-2-3-4? Isn't a 1 the same as an l?
Fight Spammers!
Because the gateway would not be able to scan the messages for viri... only the end users could see what the content was.
Imagine what it would be like if everyone right now had encrypted email by default so hitting send automatically fetched a users public key to encrypt the data.
Viruses would start using the same methods to encrypt email going to all those users. There would be more viruses getting through to users than there are now since gateways would not be able to scan the email.
What is needed is a system backed by a company such as yahoo. As long as it achieves the end goal, and starts to sort out the spam problem, then I say go for it.
It won't be good enough for me to buy a T1 and run my mail server from there, I'll have to rely on Yahoo, MSN, AOL, Comcast and a few others to be my MTA because people won't accept mail from a small provider (or a single point system) any more.
Sure they will. With SPF, for example, you setup the SPF rule for your domain to allow that domain to be a sender of mail for the domain.
You will need to have your own domain, I admit.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I think the main advantage over SPF is that this approach doesn't break forwarding as horribly as SPF does. Yes, you can do envelope rewriting for forwarded messages, but Yahoo's approach doesn't require that *all* the servers along the way support it.
Cynical I am occasionally, but why would Yahoo do this? They are a for-profit company, and if they got everyone to adopt this, then come out with a patent, they would reap a great deal of money from it...
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
I don't see how that could be objectionable...
And the points on http://boycott-email-caller-id.org/ are nonsensical.
So What? I think its great that there are multiple proposals out for the same goal, may the best one win. Or is there going to be a boycott-photoshop.org since Adobe is writing software that conflicts with GIMP?
Doesn't look to "encumbered" to me. Its free for anybody to use, even in GPL code, as long as you pass along the license agreement. Or wait, would that be considered "Viral licensing" like the GPL itself?
WTF? Its not the standard - in other words, they are trying to innovate! We wouldn't want someone come up with a new way of doing things. Were these people around in 1994 saying "who needs HTTP/HTML, gopher/archie/wais is the de-facto standard".
Also, SPF is quite far from being "the standard". It might have 10,000 hosts, but how many users send mail through those hosts? Face it, until aol/yahoo/hotmail pick something, it wont be the standard.
Read this article which points out that boycott-email-caller-id.org is biased, and wrong. That article links to this msg from microsoft where they say they are working on submitting it.
I'm no expert on either of these formats, but it appears that hotmail is sending back a lot more data (unique IP addresses). Thats more a server-config issue for hotmail.com vs aol.com than any comment on the protocol. Obviously XML has more overhead, but this example is contrived. A real apples-to-apples comparison would be returning the exact same data in each format...
Postmaster, admin, root, abuse, etc aside, clearly whitelisting is the only way.
Nothing else guarantees a complete lack of spam in your inbox. Nothing. I even get spam on e-mail addresses I've never published thanks to
dictionary scans of the namespace. What are you gonna do? Call Granny and say "Yeah my e-mail is z93397fj398fj3@34ofj39fj2.com?"
It'll probably be us slashdot early-adopters and other technophiles who use it enough to make it ubiquitous and all sexy and stuff. Word of mouth
over a good whitelisting system will take care of the rest... "What do you mean you don't get any spam????!?!?!"
First guy to bang out a tool that seamlessly integrates gpg public and private key generation into outlook so easy Granny Johnson from Duluth can use it will win.
Not because outlook is cool or anything like that, it's just what unfortunately most people use until they climb up the techno-literacy ladder a few rungs.
That or making SPAM a hanging offense, I'm fine either way.
It is known that most spam-sending machines is trojaned computers on broadband networks with clueless owners.
.com with possible endless subdomains), configure SPF/DK DNS records and send spam.
:-)
I think the only way this problem can be solved by ISPs with firewal between Internet and end-users. And may be sell unfirewalled connection to power users.
With SPF/DK spammers will just register bogus domains ($30 and may be even less for single domain in
As always, sorry for my bad english, I hope you understod me
As long as SPF breaks forwarding (and as long as SPF supporters behave as though this is no big deal), it'll fail.
/etc/aliases! (postmaster and abuse accounts, anyone?)
SRS is nothing but re-hashed bang-pathing, and the SRS folks don't address any of the problems inherent in bang-pathing.
Show me a Unix system that doesn't use
.@.
Are there any lightweight milters that would work under FreeBSD that I could use to start using SPF on production systems? While I certainly won't be filtering out unknown mail at this time, I'd like to start inserting result headers to see how accurate it is in the real world.
Dewey, what part of this looks like authorities should be involved?
While working implementations are essential, they are by no means sufficient for estimating the effects of Internet-wide adoption of the proposed solution. Therefore the quality of the theoretical discussion matters a lot too.
When e-mail was first deployed, there was hardly any spam at all, for obvious reasons. It appeared later, not because of a change of technology, but due to a change of Internet demographics. Any proposal promising to do away with spam must be scrutinized in terms of: What if everybody does it this way, will it still work?
You can't try out new traffic regulations in a laboratory, even if you have a few actual cars at your disposal.
I find the broken forwarding to be the biggest problem with SPF. -- Their solution SRS, rewriting the Envelope addresses so that the middleman then handles all the bounces seem like a definite kludge. (You can read about it here
/etc/mail/virtusertable to forward mail for customer domains, I don't want my setup/setup tools broken by having to implement a more complex mechanism and in turn have a higher server load handling bounced messages when a client's mail box is filled.
As someone who provides hosting for small companies and usually uses
While I haven't read the DomainKeys proposal, it has occurred to me before that a variation on SPF with encryption could be implemented without having to extend the ESMTP protocol. TTBOMK (To the Best of My Knowledge) ESMTP allows you to send parameters following the "MAIL FROM" command and these parameters would be preserved as part of the message envelope when forwarding. It would seem to me that an PGP/GPG, private key, encrypted string sent as a parameter would allow updated MTAs to verify the original source by decrypting the string with the orignating servers published public key. How does one publish their public key? Simple, use the TXT record in DNS (similiar to SPF's use of DNS). At the same time, this shouldn't in anyway break compatability with receiving SMTP servers that don't recognise the new parameter.
While I haven't RTFA, this has been on my mind for a while, as a "better than SPF" solution and I'm sharing it here. How do you think it stacks up to SPF/DomainKeys?
--Aaron Greenberg
Okay... where's the obligatory ~50 bullet reason checksheet that we always see? C'mon... who's going to post it?
You know... the one that starts of with something like... "Here are the reasons why this solution will not work...."
SELECT * FROM USERS WHERE A_WINNER = "YUO";
http://spfproxy.com
Just add the DNS record as instructed, change your MX, and get free SPF protection.
the biggest thing domainkeys has in its favor is yahoo.
If you're an isp, and having problems sending mail to yahoo, you're going to have to adopt domainkeys anyway, regardless of spf.
From: http://www.faqs.org/rfcs/rfc2821.html
Please read the bazillion posts on this thread about SRS. If you have a server running SPF then you also are likely running SRS. Any mail forwarding service should likewise support SRS. With either SRS/SPF or DomainKeys, you need software upgrades, and SRS/SPF are a lot simpler to implement. (Very small patches or plugins for existing MTAs and a whopping 1 tiny line in DNS for each domain.)
Why can't someone develop a standard and software to make e-mail communication similar to how instant messaging works?
With ICQ I have amazing control over who can communicate with me. I'm sure it would not be as effective for business users that need their email to be public, but IMO it would be 100% better than the current situation.
Worst case you could have a "public" e-mail address with loose restrictions and a "private" e-mail address with tight restrictions so you wouldn't have to dig through 100 viagra spams to find that important business communication from a trusted pool of associates.
Having a bookmark to Google does not make you an expert on everything.
Your ultimate spam solution will not work.
Any sufficiently advanced libertarian utopia is indistinguishable from government.
Currently register.com does not support adding spf records in their DNS server. If you are a register.com customer call their support number (800) 899-9724 and ask to have it supported. perhaps enough lobbying will work
True, but that's a solveable problem.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
here (it's linked in the text you quoted from FFS).
HAND.
BTW, What the hell does using Ximian have to do with 3 year old worms and viruses?
The primary reason for DomainKeys HUGE advantage over SPF is prevent Spammer from fishing for a valid username (for more spamming).
With the SPF, spammer (and other evil deities) can perform trial and error DNS (starting with a basic dictionary then rolling odometer attack) for a successful username with brute-force.
With DomainKeys, you must compute the SHA1-MD5 and even then, you may or may not get a valid username.
I prefer SPF as a short-term protection whereas DomainKeys is the more correct solution.
Hi.
SRS is a pain in the butt, and the comments in this thread agree.
I have been mulling over alternative ways to solve the forwarding problem.
Would people like SPF better if we replaced SRS with a less onerous workaround?
If so, and if the workaround is agreeable, I think the last remaining technical hurdle goes away; all that is left to do is get buy-in from all the major industry players. I can try to do that next week.
cheers
meng
What we need is so simple, DNS security. The root servers have private keys which are well known. They hold public keys for the tld servers. When you look up your tld server, get the public key too. Tld servers hold public keys for lower DNS servers, etc... recursive system, etc... This has several advantages.
1) No more public key madness. Everyone's public keys are part of the DNS system if you have a domain name. Simple, easy. Everything can be ssl with the press of a button, no need to setup keys.
2) Now require that the sender of email signs the email with the appropriate (as determined by DNS) key.
Simple, easy, problem solved. No more email spoofing, no more certificate BS. WHen you get a domain name, you register your public key (for free, presumably) and you're done.
So you might ask, why hasn't this been done before? The answer has something to do with the fact that Verisign controls the TLD servers, and makes a killing off of selling Certs. So if this caught on, no need to pay for certs, and that's bad for Verisign, so they'll torpedo any such proposal.
This idea has been around for a long time, perhaps it should finally be implemented this time.
Huh, SPF doesn't do anything at the username level, it only rejects based on the registered ip and domain names that can send for a particular domain. How can you get user names from that?
I'm actually quite hopeful on the DomainKeys implementation, for the reasons I'll list here. SPF is a good attempt at a method of "Reverse MX", but ultimately will fail due to the forwarding problem. DomainKeys, however, uses the only true method of Sender Authentication - a proven foundation of PKI encryption on which to build the next generation of email.
To date, it is true Sender Authentication which has been missing from allowing email to become a more secure and legal means of doing business. The use of encyption in email is a sorry state of affairs - few use it even when it is available to them. SMTP Authentication is available but hardly used and rarely enforced.
DomainKeys presents a new opportunity for accountability (through the infamous Web of Trust model) and the wider acceptance of encryption in email. When an ISP/Company signs a message with it's DomainKey, there will be an implicit stamp of approval on that message. Accountability is assumed, and identification is guaranteed. Policy decisions can then be set upon that level of identification. This accountability will force the usage of SMTP AUTH, thereby pushing accountability down to the level of the end user. Simultaneously, the wider use of server-level encryption encourages best (or at least, better) practices by corporations and individuals alike, as needed.
So, while my hopes will likely be dashed upon the rocks as lazy CTOs and admins will ultimately deem DomainKeys as "too expensive, too complex, too much", I still dare to dream that good authentication using good encryption will ultimately lift the state of email as a whole.
-t
And Chaos begat Freedom...
I get email that is addressed @mindspring.com or @yahoo.com so the domains are already valid domains that they are coming from. In most cases not all. So this will reduce spam, but not eliminate spam. Not sure what the real solution is, because spam filtering is not working when they start sending crap words through email that dont mean anything. What's with the pr0n and pn31s crap in the subject line. Yeah okay so your spam reached its destination without being filtered. Maybe the subject line was looked at, but it was most likely deleted.
Only 'flamers' flame!
Does slashdot hate my posts?
SPF, domainkeys, etc, etc seems to fit well with a whitelist or challenge response system in that they prevent domain name forgeries/Joe Jobs. Other missing (but presumably easily fixed) for universal C/R are standard challenges, and modifying mailing list software to not forward challenges to everyone on the list. Oh, I'm probably missing some other things, but I ran C/R client for a while and when configured correctly it worked VERY well. Personally, I can't believe paypal, ebay, citibank, etc haven't implemented SPF yet to help prevent all those dasm phishing scams (IE: "we need to verify your account info. Please send us your usename and password...")
1. Route all outgoing port 25 traffic through the sender's ISP mailserver NO MATTER WHAT.
2. If 1. is not done then use:
a. POP-BEFORE-SMTP to curtail unauthorized mailserver use. This is the simplest authentication scheme to use.
b. Otherwise only allow connections to bonafide mailservers. All other connections are refused (no more proxy access).
3. The recipient mailserver REFUSES to act as a 3rd party relay to relay email messages for the other two parties. The sender mailserver should look up the recipient's mailserver and directly talk to it instead.
4. The controversial step would be to employ spam filtering at the SMTP/DATA phase of the email transmission. Once the sender mailserver sends the recipient mailserver the email message, it is scanned for 'spamminess' and, if deemed spam, is rejected with a '421 try again' code to disconnect and slow down spammers or outright reject the message with a '570 THIS IS SPAM!' code and wait for the sender mailserver to disconnect. I wouldn't advise this as a rouge mailserver spewing spam could simply keep the connection open and tie up the recipient mailserver's resources.
Technical solutions to a problem that shouldn't be a problem are fine but I would prefer the direct approch myself.
Spammer sends spam. You accept spam. Track down spammer and rearrange his personality by rearranging the bumps on his head. With a blunt Instrument of your choice. I would think a trumbone would do nicely but in a pinch a tuba would suffice.
I read at +2. If your post doesn't reach that level I will not see or respond to it.
Why do people keep saying SPF is based on IP addresses? Here's my SPF string: "v=spf1 a mx a:safe.acme.com a:widget.acme.com a:pill.acme.com -all" Do you see any IP addresses in there? I don't. SPF is based on domain names.
And another thing. People keep complaining that SPF and other similar schemes won't stop spam cause spammers use hijacked machines. Duh! What these schemes will stop is worms, not spam. That also explains why Microsoft is interested - rather than fixing their god damned software so it's secure, they want to fix everyone's email so that broken Microsoft software isn't quite so annoying. Well, whatever.
Domain Keys principle weakness is in a replay attack. Here's how to do it.
A spammer sends a single email from his Yahoo! account to himself. He takes the sent message, encrypted with domain key, and then sends this message billions of times to servers across the planet. Since the message is encrypted with Yahoo!'s domain key, it is apparently authorized by Yahoo!.
Domain Keys without SPF won't work, because SPF says which servers are allowed to send email, while domain keys just says an email was signed by a particular key. If Yahoo! had SPF records as well as domain key records, the spammer would have to infiltrate a valid Yahoo! mail server to send the mail.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Eventually, the spam solution will come down to a smtp whitelist.
But this whitelist should ultimately be IP based, not key-based. The spammers will be much more easily able to circumvent this system when the database gets large enough. On top of that, this scheme probably adds more processing requirement at the MTA and will dramatically slow down mail delivery.
Of course, all this would be unnecessary if the authorities got off their butts and started prosecuting some of these spammers for the criminal violations they perpetrate on a daily basis.
I'm sorry, but 99.99% of legitimate mail is not forwarded anymore. The remaining .01% have other, better options available. If I want mail addressed to me@foo.com to go to me@bar.com, then the relaying server can simply resend the message, modifying the headers appropriately. I can also go to foo.com and download via IMAP or POP my email into their account at bar.com. Fetchmail and similar programs have existed for several decades to handle this.
If I want to setup a mailing list using procmail, I need to get a life and use real mailing list software that does sender validation and membership management.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Advantages:
1) very easy to setup.
2) no forwarding issues as with SPF.
Disadvantages:
1) potentially computationally expensive
2) requires MUA or MTA support to sign messages
The disadvantage #1 is not as big as it sounds, since most spams won't be signed at all -- so you can reject them outright with no computational overhead at all.
And I suspect spam/virii scanning is far more computationally heavy than key verification.
Since forwarding's coming up a lot in here I have to say how NOT to break forwarding.
x t
First, think of Accountability instead of Trust. Trusting someone remains with the recipient. Holding the sender accountable for their mail by making sure such mail actually came from them, is an easier solution, and is enough of a solution given that spammers don't want to be held accountable.
So, why not hold the forwarder acocuntable if they want to forward mail, rather than the original sender?
DMP does this by allowing the receiver to verify a forwarder instead of or in addition to the original sender. See chapter 5 of
http://www.pan-am.ca/dmp/draft-fecyk-dmp-02.t
Use Evolution instead of Outlook? Bewa
Problems with Domain Keys:
(1) How do you change the public key? If you publish a new one, which private key do you sign email with while DNS propogates the change? Choose wrong and your email will get rejected. Or do you have to stop sending email until the propogation is complete?
(2) Replay attack. A spammer can get his email signed with your domain key by sending it through your service once. Then he can send that same message to billions of "subscribers" from his own servers. That message will be signed with your key, and it will be apparently authorized by you.
(3) Encryption export laws. How are we going to send domain-key signed email to North Korea? How is North Korea going to send signed email?
(4) Legitimate "From:" renaming. Mailing lists send emails from their servers using a false From: name. When joe@foo.com sends an email to mailing-list@bar.com, john@baz.com expects to get an email "From: joe@foo.com". However, bar.com doesn't have the foo.com private domain key, so it can't sign the message, and so the mesage will be classified as a forgery, even though it is not.
The radical sect of Islam would either see you dead or "reverted" to Islam.
SPF only validates the envelope, not the message headers. It does nothing to prevent phishing by messages that have a valid envelope and spoofed from: headers.
Domain Keys signs the entire message including headers. The downside is that it requires reading the DATA.
Are you saying that the receiving site that checks SPF must keep track of every MTA that forwards mail to one of their users?
Let's say that a Foo University student forwards mail from her foo.edu address to AOL. While foo.edu doesn't implement SRS, aol.com does implement SPF. Some Hotmail user sends mail to the student's foo.edu address, and it's forwarded to her aol.com address, no sender rewriting. AOL finds that the foo.edu MTA is not among the permitted mail servers for the hotmail.com domain and rejects the message.
Out of the five independent actors involved here (Hotmail, Foo University, AOL, sender, student), who has acted incompetently?
In section 3.7.1, domainkeys is supposed to either "verify" or "fail to verify" the message. To be useful in identifying spam, virus/worm messages, phishing scams and other junk, these two outcomes by correlate well with whether the message is desirable or junk. Or at the very least, at least one output must have a very low correlation with legitimate messages, because only the most agressive anti-spam advocates are willing to tollerate "false positives" (accidentally mistaking legit messages for spam)
Saddly, reading the rest of section 3.7 (and scanning most of the draft quickly), I'm seeing what looks like a lot of design that will cause "verify" to be a very strong indication that the message is good, but "fail to verify" seems like to correlate with spam/virus/scam, domainkeys not implemented, and a variety of configuration problems (not like computers would ever be configured incorrectly....)
I believe this binary output clause in section 3.7.1 doesn't match up well to the real world, where at least three board categories are likely:
Most people will only want messages rejected or filtered in condition #3, but accept then in #1 and #2. I strongly disagree with this conclusion from section 3.8:
Until DomainKeys it very widely deployed, condition #2 will be the norm.
Worse yet, it seems unlikely many large, well-known domain names (the ones spammers spoof the most) would select an outbound signing policy (section 3.6.2) indicating all outgoing messages are signed... at least until they've made sure ALL their MTA are upgraded and running DomainKeys flawlessly.
Saddly, it appears that the DomainKeys binary output of section 3.7.1 returns "verify" only on condition #1, and "fail to verify" in conditions #2 and #3. To be useful, especially in a gradual adoption phase, what is needed is a good indication of condition #3... when a message is most certainly junk and should be deleted.
If DomainKeys section 3.7.1 were rewritten for a 3 state output, and perhaps section 3.7.5 were replaced with something less vauge, and a more realistic way to act upon the results (section 3.8) is suggested... then DomainKeys would probably be as effective as SPF and MS's CallerID, but with the cost of only reworking transmission on forwarding MTAs to reworking transmission on all MTAs.
Or maybe I misunderstood something from the draft, or missed some part? Maybe someone will reply and explain why my pessimistic view of DomainKeys is misplaced?
BTW: full-disclosure, my domain is one of the 14500-some that is currently publishing a SPF record. I'll probably publish a MS CallerId record if the patent issues are cleared up, and if DomainKeys takes off, I'll probably add whatever patch signs outgoing messages too.
PJRC: Electronic Projects, 8051 Microcontroller Tools
DomainKeys is much better than SPF because it doesn't break forwarding.
SPF is much better than DomainKeys because it doesn't require intensive computation.
Take your pick.
There's more than that at stake. Any method that uses an outside party for email makes the individual beholden to the outside party. Some of us have the idealistic notion that we could run email servers ourselves without a DNS entry. As things are, all you need is a static IP, and ISP that does not block ports and a recipient that is not dependent on an ISP that blocks said IP addresses. It's one of those "world of ends" ideas that seem to be going away.
Friends don't help friends install M$ junk.
Really they do! Domain Keys makes having an email list nearly impossible while SPF destroys forwarding. You know I hate spam as much as anyone else but we're going to wreck one of the most useful parts of internet because of some dicks who want to make ours bigger.,
Digitally signing email is better than examining the transport layer because it pushes the smarts to the edge. It will work (in theory) regardless of the network it runs over - IPv4, IPv6, dial-forwarding, SoNet, or whatever.
...)
.sig
However, SPF is being field tested, while DomainKeys is a draft of an idea.
There's still a lot of handwaving that I'd like to see actually working code for.
For example, DNS TXT records don't just have "some problems" when they go over 127 bytes in length - they completely break most of the current implementations of DNS.
That could be a major problem for large keys.
A real implementation would have run into that problem and have a solution (or maybe the implementer would give up on the idea
It's fine to say "sign the headers" but the real world of SMTP is nasty - it can do unexpected things to non-ascii text, change the end of line character(s) trim or convert white space.
Hell, there are still servers out there that put '>' in front of any line that begins "From "
Solvable problems, but much easier to deal with if the recommend solutions are mentioned in the spec.
-- this is not a
Incompetent users are a fact of life, and robust systems should be designed to deal gracefully also with human errors. It seems to me that while the inconvenience may be small, SPF does actually break forwarding (in terms of no longer supporting something that was once supported).
I wouldn't mind too much myself having to give advance warning to my ISP about the mail I intend to forward (and I sometimes even want such warnings from the users I serve), provided I could see the direct benefit. However, I'm not convinced SPF yields such a direct benefit, and I'm worried that changing the protocol without said benefit may set a bad precedent for the future. Every change comes with a cost, and I don't want to pay that cost, wait a few years, and learn that the benefit turned out to be zero (or even negative).
It's difficult enough explaining to our users why we should enforce existing standards (such as requiring valid return addresses on inbound mail). When one of our business partners ended up in dsn.rfc-ignorant.org for not accepting null sender returns, their mail to us resulted in an error message saying their mail server was broken. The sender knew nothing about RFC 2821 and complained to the recipient (our user). The issue was escalated, and rather than whitelist that particular business or help them fix their MTA, we decided to drop the dsn.rfc-ignorant.org check entirely because it had demonstrated a risk of blocking legit mail (I was not involved in that decision).
As you may guess, I'm not looking forward to having to explain to our users that the reason we are blocking legit mail sent to one of their addresses is that we have begun enforcing a new protocol, not mandated by the IAB, for the purpose of forcing future spammers to forge sender addresses using the domain of the abused relay rather than some random domain.
Our 200 users aren't incompetent, they just want to spend their time at the office doing other things than tweaking our highly user-configurable junk mail prevention system until their keyboards glow.
Implementing SRS may be as trivial as breathing, but I still want to ask who benefits from it, and who gets to pay the cost. I suppose making SRS optional for individual users is out of the question, thus the rewriting rules will apply to any forwardings or list expansions, and many users will be affected by the change, sometimes in unexpected ways. Whether the change is announced in advance or not, those who pay the cost are generally not those who enjoy the benefit of being able to forward mail to an SPF-reliant domain, and I'd say that's a pretty small benefit even to those who enjoy it.
I have considered defining SPF records for my domains for much the same purpose (making life easier for someone else), but I have so far decided not to, simply because I see no direct benefit to myself, and I even question the potential benefit to others (yes, some of our domains are regularly abused for address forgeries, and we could do without the attempted bounces from AOL and Yahoo).
This is a much better solution then SPF. Why? Because SPF is dependant on IP addresses, which is just absolutely horrible.
Suppose, for example, you want to move your mail server to a new location. Mail sent before you change the SPF record might not get delivered. Sure, you could add the new and old IP address to the SPF record, but for some people it might be to expensive to keep both IP addresses hooked up for however long, or they might not have the chance in an emergency.
I have been hoping someone would come up with something like this (and I've been to lazy to do it myself).
It doesn't offer any more protection then SPF, but it is a much more "correct" solution. Of course, the problem is CPU time, as it could be very expensive for some servers to sign all email.
Hopefully, it'll catch on soon.
autopr0n is like, down and stuff.
... the ability to actually implement it. I would prefer to use SPF, but my DNS provider Active Domain refuses to implement it.
So, as I don't have the ability to easily configure support within DNS I'm stuffed.
PGP client programs encourage the use of strong passphrases. The OpenPGP standard accomodates weak passphrases or no passprases at all. DomainKeys' solution requires control over a domain, not a strong passphrase to protect the key representing a domain, so Grandma doesn't need to worry about anything new. According to the DomainKeys draft, "technical minutiae is not completely covered" (1.6), and "other candidate algorithms could include GnuPG [GPG] variants" (3.2.2) so it doesn't look like an OpenPGP structure has been ruled out.
The only verified data that one has about the sender with SPF is the IP address. The A records in your line all resolve to IP addresses (that's what an A record does; it turns a domain name into an IP). The MX resolves to a domain name (which resolves to an IP address). Thus, SPF (and Microsoft's Caller ID system) just verifies that the sending IP is allowed to send for that domain.
Domain keys does not check the senders' IPs to verify them. Instead, it uses a digital signature. The difference between it and other signature programs (e.g. GnuPG) is that it operates at the mail server level rather than at the sender level. Digital signatures would work as far as verifying the sender, but that is not really their purpose. They are actually intended to maintain privacy (i.e. to encrypt the transmission). Identity verification is a side effect rather than the intended purpose.
IP address based verification would be effective in countering many existing spam situations, e.g. joe jobs and virus emails sent direct from the infected computer. Hijacking the client's connection info for the mail server is vulnerable under whatever system. All systems are vulnerable to spammers buying a legitimate domain for their own use.
There is already an IP based verification method. Technically speaking, all mail servers are supposed to have PTR records. Unfortunately, it is not effective, since not everyone is able to set PTR records for their IPs. Thus, one can't filter on lack of a PTR record. SPF allows one to verify that an IP is allowed to send for a particular domain, so accounts on domains with SPF records are much more difficult to joe job. Domain keys does not add to this; they are just vulnerable to a different set of exploits.
My opinion is that the domain keys exploits (e.g. domain key hijacking) will be easier to exploit than the SPF exploits (e.g. IP hijacking). However, others disagree. SPF is certainly less computationally intensive to operate.
Well I'm sure there are at least a few.
I think that the ultimate end point of the discussion is that true private key security is needed. In my (not really anon, just too lazy to log on, I'm andrewmuck) opinion the best way for this to happen is a seperate handheld device that can show what is being signed, that way the key can not leak back to the unsecured computing device. (I consider even a heavily DRM'd machine unsecured as it is not the operator [in essentially all cases] that ultimately controls the signing process)
Private keys are only worthwhile if the key can be held fully accountable, how much do you trust that a private key on a PC can remain safe, it has to be a seperate device that just displays and signs. I am working on something along these lines, hunt me down and email if you wish to discuss.
SPF (or domain keys or even Caller ID) gives you a choice. You can choose to not use SPF or to set a +all for your domain (anyone can send using your domain). SPF does not take away your ability to send anonymous messages (which doesn't exist anyway; all SMTP tracks the originating IP; you need to use a proxy to get anonymity).
What SPF allows one to do is to say that one's own domain will only send from certain IPs (allows DNS to determine the list of IPs). I need this, because my business email *must* be exposed so that I can get new business. Without a solution like SPF, I am very vulnerable to having my address used in a joe job.
If you choose not to filter based on SPF, that's fine; it's your choice. Just don't complain if you get a spam that claims to come from me. I can't help it if you do not take advantage of the info I make available. This is one of the great benefits of SPF: not everyone has to use it for it to help. Heck, if just Yahoo, HotMail, and AOL used it, it would get rid of a lot of fake addresses.
1. SPF breaks pre-delivery forwarding: this is called relaying and is in fact one of the problems of the current system. Breaking it is desirable.
2. SPF is at loggerheads with RFC 1123 (breaks forwarding): this is acknowledged in the SPF proposal. Fixes (e.g. SRS) are being examined.
3. SPF is at loggerheads with RFC 974 and RFC 2821: see 1.
4. SPF hijacks existing DNS mechanisms: this is absurd. SPF does not block any existing uses for TXT records (unless it happens to have the same format as an SPF record, which is rather unlikely). It just offers a proposal on using TXT records to hold the info (until a new resource record could be assigned). That's the whole point of TXT records, to offer data that can't be kept in other records.
5a. SPF is useless for SMTP Relay clients with dynamically-assigned IP addresses: no, they can use either a separate email server (recommended) or a dynamic domain name (e.g. dyndns.org).
5b. SPF is useless for roaming SMTP Relay clients: again, the recommended handler for this is to authenticate with an external email server.
6. SPF relies upon DNS for security, but DNS isn't a security service: true (of any DNS service), but of limited impact. This is basically an argument that SPF won't be 100% effective. Neither will any other single proposal. This objection mainly suggests that *DNS* should be fixed, not SPF per se.
7. SPF is vulnerable to race conditions during database changes: see 6.
8. SPF creates new categories of third class citizenship: SPF could be used this way; however, there is nothing saying that it has to be. The primary use of SPF is to verify that @domain.com email actually comes from someone authorized to send email from that domain.
9. SPF doesn't actually address unsolicited bulk mail at all: this is true. If someone uses their actual domain name, SPF does not prevent spam. However, it does prevent spammers from joe jobbing SPF enabled domains (if the receiver checks). Further, the statement "Microsoft Worms run on infected machines, and using the same mail submission tools that the machine's owner uses to submit normal mail, they mail themselves to other people" is generally untrue. Most worms run their own SMTP server, since using the normal mail submission tools is subject to detection by the mail server (virus scanners, etc.). Most worms pick the sending address from the address book. SPF usually will block this, since your personal PC is probably not SPF enabled on any domains.
10. SPF hands Verisign its next unwelcome "innovation" on a platter: it would be trivially difficult to check if a domain name has been assigned as part of the SPF checks. If not, no need to accept the email. Further, I don't think that that Verisign would actually do this; the legal liability is too high (AOL, et. al. would sue them if they authorized spam this way).
Basically, the "refutation" points out one weakness of SPF that could limit legitimate mail: the breaking of sender forwarding (for most people, SRS will be sufficient replacement). The rest of it is just FUD.
last time I checked you could have multiple records, you arent limited to a single TXT.
you can do something like
bla IN TXT "1 blablablablabla"
bla IN TXT "2 blablablablabla"
bla IN TXT "3 blablablablabla"
not perfect, but it is one solution.
A handheld authentication device, that sounds pretty much like a pen to me...
g -it-secure talking just confuses the issue. Spammers are already running in circles around our ideas; there is no point in us trying to chase them in the same circles. Better concentrate on what they keep stealing from us, and make sure to get it back: Our time and money.
But I agree that what you describe is probably what's needed if the general public is ever to enjoy the benefits of digital signatures. Some vendors may for a couple of years be able to maintain the notion that user authentication can be achieved on generic PC hardware, but I can't imagine a court of law upholding that view once a user is hit by a virus that finds his key and messes with his personal bank account. The sooner this happens, the better for the rest of us.
I have so far refused to obtain any kind of digital ID for my private use, be it for my bank or for filing my income tax declaration, because I lack the necessary equipment to maintain a clear and visible level of security. No way am I going to give Redmond even indirect access to my bank account by placing critical keys on a Windows system! Of course, a Linux system wouldn't be acceptable either, due to its complexity.
Thus a separate device is needed, and I expect the design to be open to public inspection (no security through obscurity, please).
But to get back to the original subject: All this fighting-spam-by-changing-the-protocol-and-callin
SPF makes the system public, instead of protected by patents. That's better for everyone except the company who wants everyone to use their patented system.
In a convoluted way SPF as the solution will violate various peoples right to privacy.
Why? Down the line, the ultimate mail situation is everyone sending mail peer to peer. i.e. running your own mail server. Why? One reason is so that you can implement end to end encryption such as TLS and not have your mail end up on some ISP's archive that the governments have forced them to implement. As well as better performance. However SPF causes a big problem here for people with dynamic IP addresses. The advocates of SPF say "use your providers mail server", or use a VPN. What if you don't want to use the providers mail server for the above reason? Or what if you don't have your own T1 with a fixed IP address to create a VPN to? But you still value personal privacy.
Domain keys would work with this, SPF would not and the work around would either cost a lot of money by having to have your own "base" of fixed IP addresses, or would compromise your privacy down the line. Which admittedly loads of people do, but I value my personal privacy myself.
(BTW, to preserve my privacy, I would have to receive my mail to my dynamic IP address as well
I guess, but I can do that with dyndns MX records).