Yahoo! Mail Now Using Domain Keys To Fight Spam

scubacuda points out this CNET story, writing "In addition to beefing up its storage (100MB -> 250MB), Yahoo! Mail has implemented Domain Keys to find spam. The idea is simple: give email providers a way to verify the domain and integrity of the messages sent. Sendmail, Inc. has released an open source implementation of the Yahoo! DomainKeys specification for testing on the Internet and is actively seeking participants and feedback for its Pilot Program. Yahoo! has submitted the DomainKeys framework as an Internet Draft, titled 'draft-delany-domainkeys-base-01.txt,' for publication with the IETF (Internet Engineering Task Force). The patent license agreement can be found here."

Comments

Is this going to help?

[Anonymous Coward]

Can't spammers just get verified domains to send their mail from?

Re:Is this going to help?

[mdfst13]

"Can't spammers just get verified domains to send their mail from?"

Sure, and if they do illegal things with their verified domains, those domains can be suspended and their purchase tracked. If they do legal but distasteful things with their verified domains, we can block the domain.

SPF, Sender/Caller ID, and Domain Keys are all basically identity verification services. They allow responses to emails that assume that the sender information is correct.

Re:Is this going to help?

[Technician]

Can't spammers just get verified domains to send their mail from?


Certanly.. Sending mail from your owned machine is a good start. Your machine, your MTA, your key, but not your message...

Expect more agressive attempts to find unpatched machines to become mail bots on the net.

Re:Is this going to help?

[asuffield]

If they do legal but distasteful things with their verified domains, we can block the domain.

Of course, you can already block their domain; none of these things actually help there.

Perhaps you are labouring under the illusion that it is expensive to setup a domain covered by this stuff. It isn't. Spammers will just continue as they always have.

Re:Is this going to help?

[Anonymous Coward]

wouldn't having the sending servers wrap up the headers and md5sum them also work?

99% of the time it's a spoofed header and if the sending server checks the from and sees that it does not match, it borks it back as refused to the sender?

if we simply remove the ability to create the header from the sender and only the server can then they have to put up servers and get blocked that way.

Re:Is this going to help?

[luvirini]

I think you are missing the point.

Today I can easily send mail seemingly coming from any domain. The idea with this is that the sender can be verified to come from the named domain. Ie. To stop domain spoofing.

Ofcuourse spamers can set up domains for the purpose of sending Spam, but they will be easier to track, as you can be sure the sender is actually connected to that domain.

Further many of todays Scam pretend to come from your bank, sent with authentic Email address. With this, if you get email from the bank, you can be sure atleast that the email came from the email server of that bank (though as usualy you should be careful)

Re:Is this going to help?

[Anonymous Coward]

firstly, there is a big difference between SPF and DomainKeys. SPF is an IP based solutions looking at the most recent IP address from where an email came. Unfortunately this breaks frequently given the prevalance of email forwarding systems (vanity domains and university email systems that provide life long forwarding) and thus, while SPF could be a positive step, it doesn't allow the receiving system to apply the reputation of a domain (or IP address) credibly and universally.

In contrast, DomainKeys is a signature based or crypto solution that uses a public private key set to enable a receiving mail provider to know definitively if the mail came from the domain it says it came from - regardless of the most recent (forwarding system) IP address.

Does this help? unquestionably. With a robust authentication system in place (DomainKeys) - Y! Mail can apply with more confidence the reputation engine - at Y! this is called SpamGuard and benefits immensely from user reports saying "spam" and "not spam". As other's have wondered in this thread, even if it's a new domain, with no reputation - this in and of itself is helpful and by definition more suspicious. If its not a new domain and spammers are just using domainkeys - the reputation can be enforced reliably.

DomainKeys provides definitive authentication of the sending Domain. I think of this as the first domino in a long line of Dominoes that needs to be knocked over to truly root out spam. The good news is that DomainKeys knocks this first one over in reliably providing identity of the sending domain - now it's up to the industry to keep knocking over additional Dominoes.

Re:Is this going to help?

[jokumuu]

In the case of a windows computer(as is the backbone of most botnets) there is normally no MTA configured. Instead the bots will install their own MTA, thus this stops such reasonably well.

Re:Is this going to help?

[Anonymous Coward]

And what is Outlook Express using to send out e-mails?

It doesn't need to be a local MTA, it just needs to be there.

Re:Is this going to help?

[dnoyeb]

This favors heavily webmail and other in-domain authorized sending schemes.

So now people will get the impression that you can now reject from addresses with domains that don't match the servers they were sent through.

But have you checked headers? Only time from addresses match the server address is with webmail or other in-domain type of sending mechanisims.

For instance, my domain is hosted on a remote server as a home user without mounds of $$$. But my smtp is comcast because that is my ISP. So the from will be my domain but the server will be comcast. So are we going to reject everyone else who refuses to use their ISPs email service but is forced to use their SMTP?

Re:Is this going to help?

[otprof]

So are we going to reject everyone else who refuses to use their ISPs email service but is forced to use their SMTP?

In a word, yes.

Re:Is this going to help?

[arivanov]

One minor problem. The license explicitly specifies the current draft and only ther current draft - version 1. There is nothing in it about further enhancements to the draft.

Considering that the draft will be enhanced with things like per-hop signing, trust schemes, etc I find this bit slightly worrying.

Re:Is this going to help?

[Shulai]

Yes.
That is why also authenticated and secured SMTP is being promoted. You will need to use your own SMTP, and if it is not in your own network, you will need to authenticate yourself (obviously, leaving the server as an open relay is no alternative), and probably using a secure connection to avoid password sniffings,

Re:Is this going to help?

[Anonymous Coward]

firstly, there is a big difference between SPF and DomainKeys. SPF is an IP based solutions looking at the most recent IP address from where an email came. Unfortunately this breaks frequently given the prevalance of email forwarding systems

SPF only breaks if your DNS is insecure or incorrectly configured. Which would be no surprize.

DNS Bind/9 would be best to use as you can control this behavor by answering up differet TXT records.

There is not a nivana solution to spam, but SPF does box them into having a real domain, real registration so they can be sued or prosecuted.

Re:Is this going to help?

[bs83]

Over the last several years spammers have been turning computers into zombies, and using them to send their spam. Soon lots of unsuspecting people will have their E-Mail shut down. Have we done anything at all to improve the situation? No, we just made it harder to communicate! The ONLY usefull thing is that we may be able to find the zombies.

Re:Is this going to help?

[LiENUS]

If you have access to your domain and server, in general you can use domainkeys or spf to give your isp permission to relay email for your domain.

Re:Is this going to help?

[2004.3]

The "phishing" scams are a real worry, but banks don't send email, generally. You usually have a mailbox off your account page where you can read/send messages. So, what we really need for this problem is a lotta neon! bright signs everywhere, tell people not to respond to email from their bank;-)

Re:Is this going to help?

[luvirini]

Indeed, but if the emailprogram had a popup box saying: "This email did not come from the Domain it claims to come from" should kind of help...

Re:Is this going to help?

[jokumuu]

There is an corollary to murphy's law stating that:

"Time is a race between software engineers and universe. Software engineers try to make programs more and more foolproof. Universe tries to make more and more fools. Sofar Universe is winning"

most "phishing" attacks fall into that category.

Re:Is this going to help?

[mwood]

Of course, if my bank would simply sign all electronic communication and tell all customers to disbelieve and immediately report any unsigned ones seeming to come from them, it would be an awful lot harder for scammers to fool any customer who cares.

Re:Is this going to help?

[mwood]

Most phishing *attacks* are laughable. Most phishing *successes* fall into that category.

Really, I must've read a hundred of these things and my first thought is always, "*this* mess is from an internationally respected business? did someone spike the water cooler?"

Re:Is this going to help?

[mwood]

I care who the sender is, not what domain he sent from, and for that the sender already has a choice of PEM and OpenPGP.

Re:Is this going to help?

[Smallpond]

What happens with Domain Keys if you don't include a header? Does the receiver reject the message? If not, spammers just don't include the header. If yes, then every email sender has to switch to use DK before it becomes useful.

SPF doesn't require a change to the mail message, only an added TXT record in DNS. If the TXT record is present, I make the check at the receiver. If it isn't, I don't. I added a TXT record to protect my domain from being spoofed, and I don't care whether you add one or not. Spammers are now using spf records more often than legitimate senders because they understand the potential.

Your forwarding objection is incorrect. The envelope From address is checked by SPF, not the From header in the message. Why would it not match its SPF record?

Re:Is this going to help?

[luvirini]

But the real problem are the people who do not understand computer technology. They will not understand what a signed message is...

Re:Is this going to help?

[2004.3]

Yes, you have a point. I should have mentioned that I support such an idea my self. I think that Yahoo's idea is a good one. I was trying to point out that it shouldn't be solely an email provider's responsibility to provide this type of authentification technique for a bank. I think that when a customer begins internet banking for the first time, their bank is responsible to inform them clearly and precisely how they will be communicated with online. What's the old adage? "An ounce of prevention is worth a pound of cure." (metric=28.3g of prevention worth 0.453kg cure)

Re:Is this going to help?

[mwood]

So, they will understand that a message vetted by their ISP or even their browser is not necessarily from who it says it is from, since the signature is attached by the original sender's ISP and depends on the security of the purported sender's password and equipment?

Re:Is this going to help?

[timster]

This comment doesn't apply to the subject at hand, which is Domain Keys. With Domain Keys, Yahoo might reject a message sent from a zombie mail server, but only if it's a spoofed message. It won't affect the user's ability to send mail normally.

Re:Is this going to help?

[Vellmont]

But my smtp is comcast because that is my ISP. So the from will be my domain but the server will be comcast. So are we going to reject everyone else who refuses to use their ISPs email service but is forced to use their SMTP?


You're totally missunderstanding what domainkeys does. Very simply, your domain publishes a public key that anyone can use to verify that you (and only you) signed a message via the private key. The public key gets published via a DNS record. When you send an outgoing message the sender signs each message with his/her private key. The private key is kept as a secret to only authorized signers. The signing can happen in the email client, or via the SMTP server. In your case this would very likely be done by the mail client.

All that's required to use domainkeys for the sender is the ability to add a TXT record to a domains DNS record, and a mail client (or possibly server) that supports signing mail.

Re:Is this going to help?

[realdpk]

They'll learn a lot faster if the banks, paypal, etc. start using signed messages than if they don't.

If the next Outlook Express included PGP/GPG signature checking, I think we'd be in much better shape. Unfortunately, it is basically all in Microsoft's control where we go from here.

Re:Is this going to help?

[bs83]

Spamers are not stupid, they learn. They will start using the domain of the zombi host instead of some other domain and the domain key of that of the zombi's computer. Soon that domain will be blocked as it is producing spam. The users of that domain will not be able to send mail. The spammer moves on to another zombi on another domain.

So is it on topic? Yes, the domain keys don't help preventing spam, because the spam comes from all sorts of domains. It might help with the bank scam, if you know your banks domain. That is unless they had to change their domain because they had been blocked.

Re:Is this going to help?

[Too Much Noise]

How many service providers you use digitally sign their mails to you? Does your bank do it? yes, it's a moot question now, as they don't use DomainKeys either, but since DomainKeys make for a more transparent scheme (just try to get the PR guy to revoke a PGP key) it would be a lot easier switch to.

Re:Is this going to help?

[schickb]

The good news is that DomainKeys knocks this first one over in reliably providing identity of the sending domain.

I agree that DomainKeys is a positive step. But it should be noted that this "domino" will not fall until DomainKeys (or even SPF)is widely adopted. In other words, it isn't very useful until most non-spammers are using it. Until that point, I can not assume the absence of a DomainKeys signature means spam. We have to start somewhere, but unfortunately I think the domain forgery domino is still years away from being knocked over.

Re:Is this going to help?

[Antique Geekmeister]

No, it doesn't help much. Domain keys, like Microsoft's SenderID, rely on the sender to purchase or generate a key, and on the recipient's client or their SMTP server to decrypt the public key. This is a significant computational load on the recipient: if it wasn't, there'd be no point because the keys would be easy to forge.

Expect this system to seriously bog down typical mail servers which already run at 20% or better of their available CPU capacity, especially if it gains any prevalence or is used for mailing lists for which email arrives for multiple users in big bundles.

Re:Is this going to help?

[Anonymous Coward]

I think you misunderstand how SPF does not allow forwarding of e-mail.

For example, mail from "user@example.com" to "alum@ForwardU.edu", which forwards to "alum@aol.com", would fail the SPF check since AOL would see FowardU seemingly trying to forge mail from example.com. Mail sent through mailing lists has similar problems.

Various hacks have been proposed to work around these limitations but they're messy and require all MTAs to be upgraded to use the same schemes. This is unlikely to happen.

Re:Is this going to help?

[mdfst13]

"wouldn't having the sending servers wrap up the headers and md5sum them also work?"

No. The problem is that the sending server is lying about its identity. Instead of saying, "I am a mail server for a spammer" (or a virus infected PC), it is saying "I am Gmail's mail server." Having it do an md5sum would be useless, as it would lie *first* and then create the checksum.

Btw, in regards to checking that the sender matches the from, how do you check that? In theory, you could check the PTR record, but many legitimate mail servers do not have PTR records set up (not to mention that it would be difficult for multi-domain mail servers to operate; they would need to set up a PTR record for *each* domain that sends mail through that server). Thus, a spammer can simply not provide a PTR record and bypass the from check (even if the legitimate mail server does have a proper PTR record).

Basically, the biggest thing that this (as well as SPF, et.al.) provides is that a domain holder can say, "Hey, any server that is sending mail for me *should* have a PTR record or similar. If it doesn't, it's not from this domain!"

Re:Is this going to help?

[mdfst13]

Zombie computers do not have domain keys. They are PCs. They send through a mail server. The mail server will have the domain key. To use that domain key, they will have to send *through* the server. Currently spammers avoid doing that, because it makes them easy to detect and shut down (mail servers usually have 24 hour admins that can respond quickly to a compromise; PCs have users who do not know what it means to be compromised).

Finally, even if a server is compromised (and thus its domain key), they wouldn't change the domain. They'd cancel the domain key and make a new one. Domain blocking is something that you do with a new domain that doesn't send legitimate mail, not an existing domain (e.g. gmail.com or yahoo.com).

Re:Is this going to help?

[mdfst13]

"Of course, you can already block their domain; none of these things actually help there."

Which is really effective when they send you email from *your* domain or that of someone with whom you keep in contact (e.g. gmail.com or yahoo.com). Blocking domains is useless unless you know that the email is actually coming from the domain. That is what Domain Keys, etc. provide, assurance that email that claims to be from someone@example.com really did come from the example.com mail server.

"Perhaps you are labouring under the illusion that it is expensive to setup a domain covered by this stuff. It isn't. Spammers will just continue as they always have."

Perhaps you are laboring under the illusion that it is expensive to send spam. It isn't. Even if it only costs $10 per million spams to set up a domain key domain, it could double the costs of most spammers. Email is cheap.

And at the very minimum, at least I won't have to get failed delivery notices at *my* domain for their spams. If that were the *only* benefit, it would be enough.

Re:Is this going to help?

[Anonymous Coward]

What about the hundreds of insecure BSD boxes around? We can't expect them all to have upgraded to Linux, can we?

Re:Is this going to help?

[gabonl]

That's all great, but I'm a travelling user connecting to a multitude of networks. In addition, I send mail from multiple accounts in parallel. So if I'm at work should the mail from my home account be blocked, or when I'm at home should mail from my work account be blocked, just because I'm not relaying the mail through that particular server? Most ISPs block relaying these days, meaning that, even if I wanted to, I cannot use my home ISPs mail server to send from the account I have with them unless I'm dialed into them, or hooked up through from home with DSL. And what if I'm at a customer site? After getting tired switching SMTP server addresses constantly to avoid relaying prohibited messages, I installed a local SMTP server that will route directly to the target domain. But I suspect SDF or domain keys is going to block that route as well. Any idea how to accomodate this situation?

Re:Is this going to help?

[mwood]

"How many service providers you use digitally sign their mails to you?"

Ironically enough, one: Microsoft. This is one of their business practices that I wish everyone would adopt. I would love to live in a world where it was reasonable to set up procmail to silently toss any unsigned mail and expect to lose nothing of value. If you ever get an unsigned email seeming to come from me, it's a fake.

In fact that's one reason I don't carry on electronic correspondence with my bank: they never mention signing/encryption and I won't trust such correspondence without them. I think that banks actually are missing out on a natural side business, as certification authorities for their cusotmers.

DK is easier to get people to switch to (since the ISPs just force it on their customers without asking) but it's weaker: it authenticates the ISP, not the sender. I probably know how my cousin Herman treats his secrets, and how much to trust him; I know nothing about how e.g. Earthlink protects its ability to identify its customers, or its own secrets.

For business communication, I don't see why "the PR guy" or any other person directly involved with customers would even be *permitted* to generate or manage keys. When a corporate security officer becomes aware of a key compromise, *he* would revoke the signature and issue a new one, and since he does it all day long we would reasonably expect him to know how to do it right.

Re:Is this going to help?

[Lost Race]

Hm, this has been a common complaint and the answer seems pretty obvious. If you get a message without a signature, but the "mail from" domain does publish a key, then you know it's a forgery and you can reject it. No evidence of "spam" anywhere, just forgery. You don't have to wait for anything, this works right away.

Re:Is this going to help?

[mdfst13]

Domain keys allows client level authentication if you absolutely need it. Alternately, you could install a domain key on your local SMTP server (SPF can achieve the same effect with dynamic DNS entries). However, the obvious solution to this is to *authenticate* with your non-local mail servers (port 587 is provided for this for times when port 25 is blocked). Both my current and immediately previous mail servers do support this, as well as the services like NetIdentity, Pobox, GoDaddy, etc.

Re:Is this going to help?

[schickb]

I'm far form an expert on this, but I think you missed the point. When most "mail from" domains do not publish a key, the absence of a signature means little. Your solution only works when most domains have published keys. In other words, if I send you an email right now it will not have a signature and the domain will have no key. What did you learn from that? I was just pointing out that it will take a while for domain keys to kick in.

Big boys

[martingunnarsson]

This is exactly what we need, the really big companies can to a great deal to prevnt spam from being profitable. It all makes sense. If the major e-mail providers (Hotmail, Yahoo, Gmail etc.) find a way to prevent spam from reaching their inboxes, the number of people who recieve a certain spam message will be drasticly cut. It's also these big companies that have to pay the most for spam I think, in bandwidth and storage costs etc. I just hope the big players can descide on a single standard so we can see some action instead of just talk talk talk.

Re:Big boys

[major.morgan]

While I think ideas like DomainKeys are a step in the right direction, I don't think that the proposition that the "Big Boys" are the key to cutting back spam is on target. I get very little spam with hotmail, essentially none with gmail. I think the "Big Boys" can take care of themselves (and their users) alright, it's the myriad of small business domains, fansites, home based websites, misc. forums, etc. It's the little guys that are profitable (because they are easy) - simply due to their lack of involvement and in-depth technical savvy.

Any solution needs to be EXTREMELY widely adopted and easy to implement. In order to achieve this it has to be simple to understand, definately of friendly license and easy (and free) to implement on *ANY* MTA. Finally it must hold the promise to the small guy that it will reduce spam.

I would ask how many of you (or someone you know) has wound up on one of the RBL lists? Was it through a simple configuration error, from simply not understanding the implications of all of the configuration options or from just trying to solve a problem (such as the boss not being able to send mail)? At the same time, how many actually just check the RBL's on incoming mail? It's the simplest, cheapest way to reduce spam, yet....?

If most don't implement what we have already, we should anyone expect widespread implementation (key to success) of a new system?

Re:Big boys

[Jugalator]

Gmail already support DomainKeys too.

Re:Big boys

[littlem]

It's also these big companies that have to pay the most for spam I think, in bandwidth and storage costs etc.

Call me a cynic, but aren't the big companies the ones who make the most from spam, by selling the email addresses of their (non-paying, at least) customers to all comers? I'm afraid when MS and Yahoo are concerned about spam, I always think of dracula complaining about an excess of blood.

Re:Big boys

[v01d]

I would ask how many of you (or someone you know) has wound up on one of the RBL lists?

I have. It had nothing to do with me, the RBL (can't remember which) just screwed up. It took about a week to recover.

It's the simplest, cheapest way to reduce spam, yet....?

Yet, email is vital to the daily operations of the company. I can't hand control over to some group that is completely unaccountable.

Re:Big boys

[SillyNickName4me]

> If most don't implement what we have already, we should anyone expect widespread implementation (key to success) of a new system?

The problem is that quite a few people have a very strong dislike of RBLs, and will not use them as a matter of principe. Others feel less strongly, but believe that the drawback of the RBL solution is bigger then what it gets us. (you can argue a lot about this, but there are people who feel that way, accept it as a fact for the sake of the discussion about domainkeys)

So, that people don't implement what is there has its reasons, and will not directly affect if peopel will implement things like domain keys or spf really.

Re:Big boys

[Anonymous Coward]

Domainkeys has to be implemented by the *sender* domain in order to be useful. If Yahoo implements it for all mail "From" @yahoo.com, then everyone can use that to determine wether a given mail really is from an authorized Yahoo user (as opposed to some spammer just forging a yahoo.com sender).

This wont do much for mail *arriving* at a yahoo.com mailbox, unless the domain it is 'from' also implements domainkeys.

Re:Big boys

[Fweeky]

"I would ask how many of you (or someone you know) has wound up on one of the RBL lists?"

Quite a few. None of them were running an open relay; it was just RBL software/maintainers deciding to arbitarily block a nice big chunk of address space, probably because of a single host a few thousand IP's away.

"It's the simplest, cheapest way to reduce spam, yet....?"

Yet they block tonnes of legitimate mail if you use them as blackhole lists, instead of just factoring them into your content-scanning filters.

I just RTFA... submarine patent potential

[Neo-Rio-101]

Well so far, the patent on Domain Keys *seems* pretty benign. All they seem to want is that if you implement it, Yahoo! wants the free advertising and their trademark to stay intact.

The point that worries me is that Yahoo still retain the right to alter this agreement at any time and (heaven forbid) change it to force licence payments.

I fear it may be used as a submarine patent.
Damn shame.

Re:I just RTFA... submarine patent potential

[MavEtJu]

You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.

So even if they change it, you don't have to change along.

But then, *every* description they give can be interpreted as a submarine patent, which is /. version of terrorism.

Re:I just RTFA... submarine patent potential

[zurab]

The point that worries me is that Yahoo still retain the right to alter this agreement at any time and (heaven forbid) change it to force licence payments.

The license states that it is "sub-licensable":

1.1. Subject to the terms and conditions of this Agreement, DomainKeys Developer hereby grants You, a royalty-free, worldwide, sub-licensable, non-exclusive license under its rights to the Yahoo! Patent Claims to make, use, sell, offer for sale, and/or import Implementations.

IANAL, but to me it means that once I obtain this license, I can sub-license it to someone else without Yahoo! being involved in the contract. So, even though there is nothing preventing Yahoo! from charging for the license in the future, the licensors that would have already executed the license agreement would be under no obligation to do so. Those licensors would be able to sub-license the patents to new licensees under the original terms. So, there's no real problem there.

This, of course, is in sharp contrast to Microsoft's SenderID patent licensing scheme when the license granted by MS was "personal" and not sub-licensable. So, in effect, Microsoft would maintain control over any new licensee agreement. The Yahoo! agreement doesn't seem to suffer from the same impediment.

Re:I just RTFA... submarine patent potential

[EJB]

If you read the license thoroughly, you find that you may continue to use the old patent license when Yahoo updates it, at your choice ("If Yahoo! makes such a modification, You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.")

This very much like the clause in a well-known free software license, the GPL. ("you can redistribute [...] under the terms of the GNU GPL [...]; either version 2 [...], or (at your option) any later version.")

In theory, if Yahoo changes the license, new developers wouldn't be able to use the older license, so they could wait until the patent becomes popular and then demand payment from new licensees.

But there's hardly any danger of that becoming a problem, since: "3.4 You may choose to distribute [...] a sublicense agreement, provided that: [...] such agreement complies with the terms and conditions of this Agreement"

So as long as there is anyone who accepted the old license (I just did) who is willing to sublicense to a new developer (I will, free of any charge) under the old license, the new developer doesn't need Yahoo.

- Erwin

Re:I just RTFA... submarine patent potential

[doctormetal]

If you read the license thoroughly, you find that you may continue to use the old patent license when Yahoo updates it, at your choice ("If Yahoo! makes such a modification, You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.")

This very much like the clause in a well-known free software license, the GPL. ("you can redistribute [...] under the terms of the GNU GPL [...]; either version 2 [...], or (at your option) any later version.")

But what if, after some time, they make a small but significant adjustment to the specs and make that only available under the new version of the license?

In that situation implementation of the old spec is not a problem, but implementation of the new spec is.

Re:I just RTFA... submarine patent potential

[scum-e-bag]

Then the new spec would be worthless as long as the old spec continued to stop spam. The licence allows you to sub-licence as many times as you wish. You can pass it onto yourself an infinite ammount of times, which should allow you to distribute as many versions of your software that incorporates the spec.

Re:I just RTFA... submarine patent potential

[geg81]

1.1. Subject to the terms and conditions of this Agreement, DomainKeys Developer hereby grants You, a royalty-free, worldwide, sub-licensable, non-exclusive license under its rights to the Yahoo! Patent Claims to make, use, sell, offer for sale, and/or import Implementations.

IANAL, but to me it means that once I obtain this license, I can sub-license it to someone else without Yahoo! being involved in the contract.

Probably. But lawyers have the term "irrevocable" to make that clear. If that term isn't being used, it's either an oversight that should get fixed, or it's a potential problem.

Also, a page of text posted on a web page isn't a legal agreement, so these terms only apply to people who do something more than just look at a web page.

Really the safest thing to do would be for Yahoo! to officially dedicate the patent to the public domain through the USPTO. I trust Yahoo! current management, but their management can change.

Re:I just RTFA... submarine patent potential

[Pieroxy]

If you read the license thoroughly, you find that you may continue to use the old patent license when ...

As someone else said in the same thread, the keyword missing in their agreement is "irrevocable". If is is not, it may be revoked at any time.

Re:I just RTFA... submarine patent potential

[EJB]

What do you mean with "at any time"? If you mean "without a cause specifically described in this contract", then you are just wrong.

The patent license clearly describes under which circumstances it is automatically (intrinsically) revoked, such as when you sue Yahoo for patent infringment relating to the implementation of the DomainKeys specification, or upon notice in other clearly described cases. See section 3.7. Apart from that, once you accept the offer of the patent license in a legally binding way, both you and Yahoo are bound by it and cannot revoke other than by section 3.7 or other ways described in the laws.

(You don't want to know the impact of international law, which makes this all much more complicated; I'm not a US citizen, so international contract law applies when I accept the license. Plus the fact that Yahoo's patents may (probably aren't) valid outside the United States - which doesn't preclude me from accepting the offer)

Re:I just RTFA... submarine patent potential

[zurab]

Probably. But lawyers have the term "irrevocable" to make that clear.

I'm not sure about this but if Y! licensed a sub-licensable patent to party A, and A licensed it to B - how can Y! revoke B's license? There have been no contracts between Y! and B. So, even if we assume that the license is revokable, Y! can only revoke A's license; and only A can revoke B's license. If Y! does revoke A's license, A can re-license it from any of the other B parties that previously had sub-licensed from anyone other than Yahoo.

Really the safest thing to do would be for Yahoo! to officially dedicate the patent to the public domain through the USPTO.

Dedicating the patents would be ideal from an outsider's point of view; but who knows what's going on with executives and lawyers? Fiduciary responsibility, investor lawsuits - IANAL to know all the factors.

Re:I just RTFA... submarine patent potential

[HiThere]

To me, IANAL, it looks like the old BSD license WITH the advertising clause. The one that was incompatible with the GPL.

This, if correct, would make this a non-GPL compatible Open Source license.

OTOH, it seems to me that this is offered without a termination clause, so it seems that Yahoo would not be able to change the terms for those agreeing to the original terms. And those terms allow the agreement to be sublicensed. So I don't THINK that there's sub-marine patent potential (unless there's some other patent covering much of the same material from a different angle). Again, IANAL.

Re:I just RTFA... submarine patent potential

[geg81]

I'm not sure about this but if Y! licensed a sub-licensable patent to party A, and A licensed it to B - how can Y! revoke B's license? There have been no contracts between Y! and B.

In any case, I don't know what happens in that case, you don't know what happens in that case, so it is therefore something that the contract should clarify.

Dedicating the patents would be ideal from an outsider's point of view; but who knows what's going on with executives and lawyers? Fiduciary responsibility, investor lawsuits - IANAL to know all the factors.

I don't doubt that it may be politically hard for people inside Yahoo! to sell this to management. But Yahoo!'s internal politics don't change what may be necessary for the community to accept this as a standard. And the people caught by corporate politics right now could have avoided the whole issue by just not patenting and publishing instead, which would have been for the good of the community and the good of Yahoo! Because a patent on a technique that nobody uses because of legal concerns is just a waste of money for them.

Strangely enough...

[cow_licker]

GMail used it first.

http://it.slashdot.org/it/04/10/18/0236201.shtml ?t id=111&tid=217&tid=95&tid=1

Licence

[stewwy]

Read the licence , seems pretty decent at first glance , they just want acknoledgement of their IP and the licence is p[erpetual so they can't revoke it unless you break their terms

Re:Licence

[pe1rxq]

Its a bit like the BSD with advertising license...
(Although only in source & object code so not on boxes or ads and stuff, but even object code is already a problem)
It seems reasonable at first (Just one line saying 'thank you Yahoo') but it has the same problem as the BSD license had: You end up with an ever growing amount of lines of all kind of people wanting the world to know you used a pieco of their 'IP'.

Imagine a helloworld program like this:

~$hello
Hello world
This program was compiled using the GNU C compiler ,Copyright The Free software foundation, Richard Stallman, etc
This program uses header files written by Linus Torvalds.
This program was linked against the GNU C library
This program was written in the C language which contains IP from K&R.
This program uses SCO owned IP.


Would it be a great world if all software was like this?

Jeroen

Re:Licence

[Anonymous Coward]

Your point is good, but in case someone takes your hyperbole literally:

Advertising clauses typically only require acknowledgement wherever you already put your own copyright notices. So, using your example, the output of "hello -V" and the second page of your manual, if you had one, might have to contain the additional text. Mixing copyright notices into the expected regular output of your program would be silly.

Re:Licence

[Anonymous Coward]

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.

Re:Licence

[nenolod]

Umm, the BSD licensing clause ONLY applies to documentation. The actual requirement to display a copyright notice upon execution, was removed in the later version of the license.

Re:Licence

[pe1rxq]

I was talking about the old BSD license with advertising clause which covered more than just execution:

3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.


Jeroen

Comment removed

[account_deleted]

Comment removed based on user account deletion

Patents and Standards ....

[Gopal.V]

If it gets accepted as an RFC standard, I think we all deserve a royalty free patent grant :)

Or even better a patent grant for code under "OSI approved" licenses ... (*wishful thinking*)

Seems to be a very nice Public key based system using standard RSA algorithm too . But I still want my ogg streams over DNS ... not just Domain public keys :)

Re:Patents and Standards ....

[SillyNickName4me]

Please read the patent license (link is in the writeup).

Re:Patents and Standards ....

[Rod.Dorman]

> Please read the patent license (link is in the writeup).

Perhaps, but where in the draft does it say there *is* a patent license? The only thing it says is "I certify that any applicable patent or other IPR claims of which I am aware have been disclosed" but I see no indication that there actually is one.

This is touching upon the "Is The Lone Coder Dead? thread but how does someone who wants to implement Domain Keys discover that there's a patent license?

If the answer is do do a search, whats the point of having the patent boilerplate in an RFC?

Not that helpful in stopping spam

[auzy]

Due to the way the can spam act works with the opt-out links, this doesn't really stop spam at all. Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters. Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

The problem with spam is slowing it down, whats really needed is a CPU intensive solution like the hashcash suggestion (like which has been suggested before), that way mass spammers can be differentiated from different users. While mailing lists may suffer due to it, with the addition of a standard mailing list protocol where you email a certain message to your mailing server, they send a message to the mailing list to subscribe on behalf of you, and for your account prevent the need to use hashcash.

The only way this could help spam is if Microsoft started charging for emails (which they have wanted to do for a while now).

Re:Not that helpful in stopping spam

[avel599]

Thank you! The title in this article is the common misleading thing about such 'caller ID' methods.

Bob Beck from the OpenBSD team says it better than me. (Read the whole interview btw, it's very very interesting).

What's my conclusion? SPF and caller ID does two things, which I would do if I were writing spam software:

1. Encourages spammers to publish SPF records (and they have).

If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it :) The biggest SPF adopters I see on my site (from No. 2 above) are spammers.

2. Encourages spammers not to spam from SPF-publishing addresses.

(And don't forget, this is what AOL and MSN *really* care about.)

Re:Not that helpful in stopping spam

[Jugalator]

Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters

However, I doubt this will hold true for long if enough mail providers start supporting it, companies starts registering them, and black lists with "bad domain keys" are created. Yes, it might take a while for all this to happen, but so would it do for many people to accept your suggestion.

Re:Not that helpful in stopping spam

[cgreuter]

Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters. Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

It's a common misconception that things like SPF and domain keys are tools for stopping spam. They're not. They're infrastructure to be used for building anti-spam tools.

The real advantage to domain keys is that there's an immediate advantage for using them. Senders benefit because it gives their messages more credibility (making it practical for people to, for example, whitelist mail from yahoo.com,) and receivers benefit because they can identify some spoofed messages with absolute certainty, saving some bandwidth and thwarting some phishers. The more implementers there are, the more valuable the system becomes and the more implementers there will be.

And once anti-spoofing is in place, then we can leverage those into anti-spam techniques to root out throwaway domains. (E.g. seriously throttle the incoming connection from any domain that is blacklisted, doesn't implement authentication and that has not sent out at least one message a month for the last six months.)

Re:Not that helpful in stopping spam

[Reverant]

I would *hope* that spammers start using DomainKeys, because when they do, to send their spam, they effectively "tag" their mails with their private/public key. So, when you get a "signed" spam email, you submit it to "version 2" of SpamHaus, which should now not only block IP addresses, but also domains based on the public key. That makes our lives a whole lot easier.

The point here is that DomainKeys is not by itself a solution, as is not an SPF or a SBL. You need both to be very effective.

Re:Not that helpful in stopping spam

[advocate_one]

The problem with spam is slowing it down, whats really needed is a CPU intensive solution like the hashcash suggestion (like which has been suggested before), that way mass spammers can be differentiated from different users.

fix isn't to slow it down, the fix is for Microsoft to fix their borked OSes and make it impossible for them to be zombified... then spammers will have to go to using more awkward methods. In the meantime, ISPs should be more proactive and toss zombied boxes off the network. Users will soon get the clue when they cannot connect.

Personally, I'm of the suspicion that it's all a conspiracy to push a technical solution on us from above making it mandatory to only connect with certified clean boxes. And wondrously so, Microsoft and the hardware manufacturers will magically appear with the solution in the form of new hardware and software.

Re:Not that helpful in stopping spam

[SillyNickName4me]

> What's my conclusion? SPF and caller ID does two things, which I would do if I were writing spam software:

Now, while that line is correct, it also shows quite clearly what is behind Bob's statement (see below)

> 1. Encourages spammers to publish SPF records (and they have).

> If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it :) The biggest SPF adopters I see on my site (from No. 2 above) are spammers.

Yes, they can do that for sure.

> 2. Encourages spammers not to spam from SPF-publishing addresses.

> (And don't forget, this is what AOL and MSN *really* care abo

ANd it also happens to be what I as a small business and private user care about.

WHen I get an email from a site that publishes SPF records, I can have a reasonable level of confidence int hat it really comes from that site (ie, my bank, ebay etc etc).

It will also help reducing the flood of failure messages that result from anti virus software and mail viruses.

It will also help create an environment where we can held peopel responsible for what they send out since we have a reasonable assurance they indeed did send it.

Together this makes for an environment that also discourages spam, but that is not the primary goal of it, and it wont stop spam by itself.

It seems from reading the interview that Bob has a bit of an issue with SPF and similar for emotional rather then technical reasons. The way he says things (is this the interview?) is suggesting he believes SPF makes the situation worse. It appears to me however that 1. that is not the case, and 2. that opinion is mostly motivated by his support for the RBLs and not wantign alternative solutions.

RBLs are a bad solution because they create a bigger problem then the one they try to solve.

- It creates small groups of people with an insane amount of influence on email delivery, thereby putting power in the hands of people who can not be held accountable for their actions, but can disrupt things quite seriously.

- In order to be usable, an RBL has to be both very fast and very accurate. Those two are managable as long as there are few incidents only.

We do not need dictatorships or burocraciies to manage the flow of email, and they are more serious issues then spam in the end.

Re:Not that helpful in stopping spam

[pqdave]

Broadband ISP's should include a router in whatever they use to convert to ethernet. This router should be set up with reasonable security by default, and have physical switches to lock out "advanced mode" settings that can lead to bypassing the built-in security.

Re:Not that helpful in stopping spam

[evanh23]

it's going to suck 10 years down the road when you buy your uber cool new domain name from someone else (because it was previously registered), only to find that you can't use it for email without spending hours trying to get yourself delisted from half a zillion domain key blacklists. seriously, this is going to cause a whole new set of problems unless the blacklists are run by the domain registrars (yeah right) at least with ip blacklists, there is a hierarchy of authority to blame when you get stuck with a bad ip (as i've had happen more than once) and yes, i monitor *all* of our mailservers against all the major blacklists. and i have my aol feedback loop (what a pain in the ...)

Re:Not that helpful in stopping spam

[mattdm]

Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

Whatdya mean that's no better? That's a *huge* step forward. Suddenly, you can implement simple domain-based whitelists and blacklists. And you've got a lead for tracking down con artists and other illegal schemers.

Re:Not that helpful in stopping spam

[advocate_one]

no... ISPs should just toss them off the network and only connect them to a stock page to be told what's wrong. I don't want my ISP getting any stupid ideas to fix what is basically a Microsoft problem (you may have gathered that I do not use microsoft products in any shape or form).

Re:Not that helpful in stopping spam

[pqdave]

Toss who off the network when? I'd agree if the insecurity only affected the customer that didn't secure their box, but by the time the ISP sees the problem that box has adversly affected the rest of us.
I'm advocating the ISP version of OS best practices: Defaults are sensible and safe, unneeded and potentially harmful services and networking are turned off until the user decides otherwise. If someone isn't smart enough to flip a switch to the direct connection position, they aren't smart enough to handle their own security where it affects others.

Re:Not that helpful in stopping spam

[Saint Aardvark]

>> 2. Encourages spammers not to spam from SPF-publishing addresses.
>> (And don't forget, this is what AOL and MSN *really* care abo
>ANd it also happens to be what I as a small business and private user care about.

Bingo! Why is it a bad thing that AOL and MSN don't want people faking emails that appear to be from them? Stopping forgery, while it isn't the same as stopping spam, still has a huge benefit.

Re:Not that helpful in stopping spam

[jmason]

'Recent research pointed out that the majority of domainkey users so far have been spammers'

Got a link for that? It's news to me, and I'm one of the SpamAssassin development team. I think you're confusing DK with SPF.

Either way, it's an irrelevant point. Sure, spammers can tie themselves down to one IP by using SPF, or tie themselves to a domain by using DK -- and we then have removed a layer of their anonymity and given ourselves a new tool in our armoury against them. *THAT* is the point.

Re:Not that helpful in stopping spam

[c4ffeine]

CPU intensive solution? It seems that you are forgetting the vast armies of zombie computers. I think that this would only increase the demand for zombies, and therefore increase the number of worms...

I can't wait for my 250MB.

[PeteDotNu]

After all, I'm using an entire 1% of my current 100MB allowance. That extra 150 will really come in handy.

It's not to fight spam, it's to prevent forgery

[RollingThunder]

As I understand it, the biggest benefit of domainkeys is not the person that is receiving the mail from a dk-enabled domain, but rather the dk-enabled domain stops seeing so many bounces coming back from people claiming to be them.

Instead, when a spammer tries to send a dk-enabled recipient, faking a dk-enabled domain, the recipients MTA rejects immediately, rather than bouncing, which would go to the wrong place.

Domainkeys don't mean "not spam". They mean "this MTA is authorized to send on our behalf". That MTA may well be a spam-friendly MTA.

Re:It's not to fight spam, it's to prevent forgery

[garver]

IMHO, fixing forgery will go a long ways toward fixing spam. Spammers can not only be anonymous, but they can even spoof legitimate addresses. Remove that anonymity by tying them to a domain, which is registered, and we can hunt them down and have our way with them.

Think about your inbox. Immediately remove the scam mails spoofing banks, etc. Now, bring the ones from known good domains to the front and push known bad domains to the back. Finally, mark the spam and your MUA automatically notifies the domain's registrar that the domain is being used for spam. The registrar could revoke the domain or maintain a signal to noise ratio and let you decide.

Idea simple... too simple

[IBitOBear]

Like nay good quick fix, this is "good idea" from the pre-history of fact.

Spam sent from zombie (pwned) machines and open relays will all come from valid domains.

Forged from locations *also* can come from valid domains.

For an idea to be good it has to be "simple" _AND_ "effective".

This will just encourage less traceability and cut of legitimate and careful operators.

Consider I have a domin, I do tiny bits of email, my *reverse* domain is going to show up as bunch-of-numbers-provider-tld, which won't match my sendings unless I pay lots and lots of money to my provider (Ok, I'll say it, "Comcast") for a business account wiht a proper inverse DNS entry.

So this is shaft common people and encourage virus/trojan writers and open the door for profiteering.

Yea... that'll help a hell of a lot.

Re:Idea simple... too simple

[samael]

You have a domain - why aren't you using _it_ as your SMTP server? Then you would set it up with a domainkey and bingo - you'd be unforgeable.

Re:Idea simple... too simple

[a24061]

I agree. I already have trouble with arrogant admins blindly using dynamic IP blacklists and telling me I should use my ISP's unreliable SMTP servers. This will just make matters worse, as my e-mail address uses my registered domain rather than my ISP's, so it will be impossible for me to get my domain to match the IP my mail comes from.

Re:Idea simple... too simple

[kiddygrinder]

Actually, a zombie will not be able to provide a matching domain key unless it generates it based on it's current ip address. So yes, it will shaft common people, and no, it won't benifit virus/trojan writers. Seriously, some chick at my work gets over 1.2k spams a day, if i don't have to try to slow them down again, I'll give satan i nice iced lolly.

Re:Idea simple... too simple

[Brian Blessed]

Consider I have a domin, I do tiny bits of email, my *reverse* domain is going to show up as bunch-of-numbers-provider-tld, which won't match my sendings unless I pay lots and lots of money to my provider (Ok, I'll say it, "Comcast") for a business account wiht a proper inverse DNS entry.

This doesn't make any sense. If you have your own domain then you will just put the DK public key in the record for that domain. It doesn't matter what your sending IP address reverse-resolves to, because that isn't how Domain Keys works. You can even relay the signed mails through your ISP because, once signed, their authenticity can be verified regardless of the MTA that is passing them on.

- Brian.

Re:Idea simple... too simple

[Anonymous Coward]

Read the domain keys draft. What IP you are on is irellevant. What matters is whether or not you have access to DNS so you can make a domain key available in the zone for your domain. If you can do that you can sign your mails with the private key and send it through whatever mail server you want and the signature will verify correctly.

Re:Idea simple... too simple

[The Cisco Kid]

You are confused.

This doesnt validate the PTR record for your IP - the sending MTA signs the message, with the key for domain in the 'From' header. If you have a domain, and you want to use domainkeys, you make a domainkeys public key, put it in your domains DNS, and then setup your MTA to add the sigs. It doesnt matter what your IP is, or if you relay thru another MTA.

Re:Idea simple... too simple

[jmodule]

I have a domain, but the provider doesn't provide SMTP services (and the instructions even tell me to use my ISP's SMTP server). So that is not always an option for everyone.

But it seems to be a moot point in the discussion below since the domain key is tied to the domain name and not the SMTP server address.

Re:Idea simple... too simple

[IBitOBear]

"...domain key is tied to the domain name and not the SMTP server address."

Yes, and no. The domain name of an SMTP remote end is often reverse-resolved to verify that the message is comming from the machine that named in the "hello" message in the SMTP exchange.

My reverse resolution doesn't match my forward claim.

This is (currently) ok [I think] for some agents, but not for others. As soon as the triangle is closed (all three must match) the damage will be intense.

Remember that a lot of black/white listing is done by address range. Reverse resolve isn't that far away.

Among other things it will prevent a spammer from registering "foo.com" and then inventing X.Y.Z.foo.com (where X Y and Z are varables) and *flooding* the domain key space with keys for these multiple domains. Then the servers and the lists will have to deal with a plurality of origin domains. The lists cannot really be geared to just use foo.com because lots of real organizations (mit.edu etc) use real multiple level domains (the way we are supposed to but don't out here in the untaimed stupidity-infected as-many-words-as-we-want.com world).

The problem space becomes "elaborative". As soon as the spammers decide to get clever the system will colapse, or at the least form its very-own self-denial-of-service ring.

In the evolution of things, this is bad.

Re:Idea simple... too simple

[IBitOBear]

I over-simplified myself I guess. You are right.

And kind of wrong too...

See, as soon as spammers begin dilluting their namespaces by registering foo.com and then running their onw name-server so that they can create X.Y.Z.foo.com they will be able to flood the keyspace. The providers will not be able to just fliter on two-names automatically (e.g. foo.com) because real organizations that use the DNS correctly (like mit.edu etc) don't flatten tehir domain space.

Alternately, the infinite number of zombie machines can (do) spew the spam from real machines which would presumably generate real signed mail via outlook. Or the spammers will send the mail through the zombies already crafted with their plurality of domains and keys.

So it is *INEVITABLE* that the reverse-resolve that is already part of the SMTP "hello message" verification will *have* to be brought into the standard in version 1.1 or 2 or whatever.

So, to summarize:

1) bogus sub-domains leads to flooded domian key space and self-imposed denial-of-service as the receiving-side key-store has to look up pluralities of keys.

2) existing reverse-resolve gets factored in to prevent zombie relay of well crafted, elaboratly keyed "domain key valid" email.

3) common small-scale users get screwed.

yep... no holes there...

Re:Idea simple... too simple

[IBitOBear]

(Oversimplified myself)

[step zero, I get to convince register.com to add key record support at no extra charge or start my own full-time DNS server. but I digress.]

So spammer bob comes along and registers foo.com and points it at his own DNS server.

Then he fabricates X.Y.Z.foo.com (where X Y and Z are variables) and generates accompanying keys. [Or he slips $1000USD to some lacky at yahoo.com and makes off with their secret key.]

He then sends his email through open relays and zombie machines.

The mailer agents *MUST* then start relying on reverse-resolve (which already happens in the "hello message" of most SMTP agents anyway) to make sure that the "most prior step" is valid, which is fine until you get to the origin machines with valid domains that don't identify themselves with their reverse-resolvable ids.

Meanwhile: Spammer Ted just buys some trojan time on a zombie network and send out his spam as "properly signed" email from you and me, "prooving" that you and I are the ones offering penis cream.

So you have this rolling yellow-snow ball galumphing down hill containing:

-- elaborate key spaces constructed by spammers
-- compromised keys
-- complex fee-structures for legitimate small operators to get support from registrars and ISPs
-- unvarifiable origins or over-verified origins
-- INCREASED INCENTIVE to virus/trojan PCs to have mail go out with those owned-machines' identies.

Yep, nothing half-baked or easily spoofed here...

Carry On...

Re:Idea simple... too simple

[The Cisco Kid]

Once it became known that *.foo.com was a spammer, you could block foo.com *AND* *.foo.com, Domainkeys isnt intended to stop spam, its intended to stop *forgeries* - Once you know a mail isnt *forged*, then it makes it easier to identify and block spammers.

I welcome the spammers to setup domainkeys for their domain, and to sign their mail. If they really mean it when they say they dont want to send mail to anyone that doesnt want it, it will make it that much easier for those that dont want it to identify it.

Re:Idea simple... too simple

[a24061]

Oops! Will this system help encourage the lazy admins to start allowing cable modem customers to route their own mail?

Re:Idea simple... too simple

[IBitOBear]

I think you are insufficently paranoid... 8-)

the tollgate for the next "eyeballs" of the net...

[Anonymous Coward]

I prediced when they first came up with this idea, that owners of large numbers of "free" mailboxes would promote this idea wrapping themselves in the flag of fighting spam - but later they will turn it around and use it to bill companies for access to those mailboxes.
How? you ask (or not)

1. Company BigBox declares "All mail destined for our free mail accts must use Yahoo! Domain Keys (TM, R, SM, Patent #suckitlosers)"

2. Their mail servers count the number of emails signed by company X. (incrementing a long int counter associated with cert X in postgresql or yoursql is much less expensive than the YDK verification process)

3. They send a bill for USD 0.01 per email to the (email) address associated with the signing cert for company X during a given month.

4a. Company X says fuck off and doesn't pay the bill, BigBox tags Company X's cert record in their db and which blocks all incoming emails signed by that cert at the mail server untill the bill is paid.
4b. Company X tries to say "we didn't send that many emails to your captive eyeballboxes, it was Bad People (TM) who did it with our cert" BigBox says "Then you should have revoked your keys, beeeyyyyoutch!"

Don't say I didn't warn you - I even tried to make a long bet about it because at the time we didn't know how long it would take before the major players would implement YDK - and I wanted Yahoo! to bet against me, so that they couldn't disingenuously act as if they had never heard/thought of that use for Yahoo! Demon Keys.

PGP Signing?

[Anonymous Coward]

I'm probably wrong, but this sounds like automatic PGP signing on outbound emails, at a domain-based level.

It's too bad webmail and other MUAs don't include PGP as a more standard option.

Re:PGP Signing?

[kiddygrinder]

It's pretty much the same principle, except it's at a domain level (I believe) rather than a individual level.

Re:PGP Signing?

[Anonymous Coward]

The "level" isn't defined. A minimum of one selector needs to exist for a domain in order to use domain keys, but the upper number is unbounded so it's quite possible to use a selector per user.

One major drawback

[OSXpert]

The only possible flaw i see in this system is that now, in soviet russia, spammers can block Yahoo. Is this fixable or does Yahoo just have to deal with this?

opening myself up to ridicule

[circletimessquare]

how would one implement dk with iis's smtp service?

and yes, this is an honest question

DomainKeys breaks RFC 2821 and 2822

[spafbnerf]

RTFA. Interesting reading on what may hinder adoption of DomainKeys for some.

Re:DomainKeys breaks RFC 2821 and 2822

[Anonymous Coward]

Um, there is no way you can verify the integrity of the headers unless you make them immutable. So DomainKeys isn't broken. The RFC is broken and needs to be fixed.

Pity about the MTAs that do change the header.

John Roth

Re:the tollgate for the next "eyeballs" of the net

[Anonymous Coward]

some smart people browse at "0", you are a a smart guy and you are correct

will i mod you up? no. i never have modded anyone up or down in my life (but i have posted over twenty posts as AC that immediately shot to +5) the reason... i post real juicy dirt and provocative facts.... just as you do.

your prediction is a valid one

How is this so much better and easier than SPF?

[Anonymous Coward]

Why do we need something else than SPF? SPF is open, easy and already working in many places. It doesn't need vastly new software or much special at all.

All you do is to add a TXT record to your domain and write down which addresses are permitted to send mail in your name.

http://spf.pobox.com/

Re:How is this so much better and easier than SPF?

[Anonymous Coward]

Actually there is a big difference between SPF and DomainKeys. As you point out, SPF is an IP based solutions looking at the most recent IP address from where an email came. Unfortunately this breaks frequently given the prevalance of email forwarding systems (vanity domains and university email systems that provide life long forwarding) and thus, while SPF could be a positive step, it doesn't allow the receiving system to apply the reputation of a domain (or IP address) credibly and universally.

In contrast, DomainKeys is a signature based or crypto solution that uses a public private key set to enable a receiving mail provider to know definitively if the mail came from the domain it says it came from - regardless of the most recent (forwarding system) IP address.

Given that Y! approached DomainKeys with an opensource license and implementations (http://domainkeys.sourceforge.net) are already available from qmail, sendmail and CERN has developed an exchange implementation, it's a pretty easy path to a better solution that SPF.

Spam and patents

[Elektroschock]

Software patents are bad for the market and patents that have to be granted royality-free are not worth the transaction cost burden the software company pays to the patent industry (= patent professionals). Patent trolls contribute much to market insecurity in the software market.

I hope in Europe we will get safe from software patents. It is worth to fight for that.

I don't believe that conceptual protection of software was bad but patents ARE the wrong instruments. Players such as FFII's Hartmut Pilch propose Industrial Copyright to fill the gap. It there is a gap.

For the EU Patent directive European market players need certain amendments into the directive.

Yahoo could save wasted money.

To find out more about patents I recommend a short introduction text of FFII.

How will I grow my penis size now?

[Anonymous Coward]

Or help rescue Nigeria? View sexy cheerleaders? Take the blue pill? Discover better Dell deals? Get flat screen plasma TVs for free? Huh? Huh?

Re:How will I grow my penis size now?

[boutell]

You forgot your rolex.

Hope this helps.

Re:How will I grow my penis size now?

[Anonymous Coward]

Yes, but will it really mighty my penis, man?

-- Sean Connery, Celebrity Jeopardy

Re:How will I grow my penis size now?

[Anonymous Coward]

Just turn of pop-up blocking in Firefox!

DomainKeys and Spamassassin

[Anonymous Coward]

I don't think this will take off until there is an easy way to plug this into Spamassassin.

Re:DomainKeys and Spamassassin

[BitwiseX]

I don't see how that would hold it back. It's fairly easy to add as a sendmail milter. Why make Spamassassin do all the work (IE: DNSBL) when sendmail can take care of business before Spamassassin?

Except this will break my Email

[Macka]

The only problem with this solution is that it's going to make sending email virtually unusable for people like me. I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network. Similarly, when I'm away from my office, I connect to the net using GPRS and use my mobile provider's SMTP server. And sometime if I'm on a clients network I'll use their SMTP server instead.

In all those cases it doesn't matter where I'm sending from, cos the From: and Reply-To: headers point back to my domain, so when people reply to me their email goes to the right place. It's even more important these days with spam filters in front of everyone's Inbox that my From: field correctly identifies who I am. And from a business point of view that has to remain consistent.

The Yahoo site describing this states that for DomainKeys to work, the domain is extracted from the From: field, a DNS lookup fetches the public key, and that is then compared to the email's private key to confirm the email came from the correct place.

For me this is always fail, whether I'm working from home, or I'm out on the road. Basically, it's a complete disaster. Right now I'm not sure how I'd get round that.

I can't be the only person this would screw up. There must be tens of thousands of other people out there who legitimately use email this way and would be badly affected by this.

Re:Except this will break my Email

[Ewan]

It is a bit of a pain, but if it's a decent hosting company it will be implementing SMTP with authentication for you to use, to send emails via them instead of whichever ISP you are connected to.

Pretty much every mainstream email client now supports it, and a any decent hosting company selling you service should support it too.

Ewan

Re:Except this will break my Email

[RollingThunder]

Well, firstly - domainkeys are optional. If your domain doesn't publish them, your mail should still go through. I can't think of any reasonable reason to require dk before receiving mail, because as I mentioned, it's primarily for the benefit of the domain that publishes a domainkeys record.

Secondly, there's lots of ways that your hosting company could fix their setup to allow you to safely and reliably relay. Things like pop-before-smtp, or authenticated SMTP (either by normal SMTP port 25 or by the submission service) both work well. True - neither are as fast as a local server but that doesn't mean it's un-doable.

Really though, for your situation I would just say "Don't publish a domain key record", or else "Publish a DK that states anyone can send on your behalf".

Re:Except this will break my Email

[Macka]

Thanks for your thoughts. Hopefully then, if whichever outbound SMTP server I'm using signs the mail with a private key, but my hosting company doesn't publish a public key in DNS for my domain, then the default behavior will be to allow email through and not drop it in the bit bucket. I wonder if this behavior will be written into an RFC or left to be implementation specific.

I've tried pinging my hosting company before now about setting up an authenticated SMTP server when I first learned about the possibility of SPF. So far, no joy.

Re:Except this will break my Email

[Anonymous Coward]

You can set up per-user domain keys, and take the private key with you (as long as you can add your own DNS records). You could also set up multiple keypairs, one for each of your devices. See section 6.4 (Roving Users) of the DomainKeys spec. This is one of its advantages over SPF.

But your hosting company SHOULD allow you to use their SMTP server over an SSL connection, as long as you authenticate.

Re:Except this will break my Email

[g0at]

I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network.

I work for myself too and I have the same problem, except I don't, because I can relay from anywhere thanks to authenticated SMTP.

This is what they invented it for.

-ben

Re:Except this will break my Email

[gehrehmee]

Can't you just tell your domain hoster to add your other ISP's SMTP servers to your DK relayer record? 1) random recipient X sees email from your domain A sent via ISP B. 2) X checks A's DK entry, finds B in the 'good list', and marks the email valid.

Re:Except this will break my Email

[The Pim]

To reiterate what the anonymous parent said, this shouldn't break your email, and the reason is a fundamental advantage of DomainKeys over SPF and Sender-ID. The latter require you to send mail through a special host, breaking the end-to-end nature of SMTP, which says that all hosts are equal. DomainKeys just requires you to use a special private key, which can be on any machine or even carried around with you on a keychain. It may require a bit of configuration, but it is far more flexible and egalitarian.

Re:Except this will break my Email

[Big Boss]

Does your hosting company have the submission port (587) open? If so, you might be able to get around your ISP port 25 blocks.

The reality of spam and network abuse means that we are going to have to move to something more locked down. SPF and YDK give us this without ditching SMTP. It does mess some people up, but there are existing soultions for all those problems. The submission port is one of those. There are also SMTP-Auth and POP-before-SMTP. I also have a webmail service running for my home email. That helps me with the port blocks and proxy server issues when roaming. There are numerous options for all the complaints I see about SPF and YDK, but it requrires people to change how they do things. Yeah, it sucks. But unless you want to give email to the spammers, it has to be done.

Re:Except this will break my Email

[Anonymous Coward]

Simple: use a webmail in _your_ domain.

access by https signed by a CA for less than $25/year, if you wish. This way you will always be able to send emails, no problems there.

For the inbox, use imaps (SSLed imap) so your client and webmail have the sent, draft, etc folders.

No big deal, I already do that.

Ivan

Re:Except this will break my Email

[Anonymous Coward]

This is not a flame or an attempt to put you down. But you _can_ use ssh to connect to a shell host, independant of your ISPs network, unless they have outgoing ssh blocked! Over ssh you can tunnel the pop3 connection, or just use ssh/scp to transfer the mailbox files. Now, I'm not saying this isn't a technical project, but it can be done, and very often, most UNIX/BSD/Linux web hosts also allow ssh access. SDF and JVDS are two that come to mind.

Re:Except this will break my Email

[MarkRose]

I thought I had this same problem -- my ISP blocks outgoing port 25 except to their SMTP servers. Of course, I have a few domains hosted elsewhere, but my hosting provider is kind enough to provide SSL-enabled SMTP on port 465. Because I have to authenticate to the SMTP server anyway, this has a nice benefit of encrypting the connection to prevent anyone from snooping my creditials. This is the way it should be done for everyone anyway...

Call me a cynic but...

[TooCynical]

In all reality, this is just driving toward another revenue stream for them. It is much easier to charge Spamers a fee to reach you than it is to get you to pay 19.99 a year for Mail Plus.

Re:Call me a cynic but...

[adzoox]

The article has nothing to do with how spammers can send email if they have Premium accounts.

I have a premium yahoo account. I was pleased yesterday to find it had jumped to 2GB of storage and the attachment size had jumped from 5MB to 25MB.

The other thing I noticed though is that you can only send to 10 recipients at a time and it won't send ANY email if one of those addresses is an invalid email account or is even port blocked.

I tested this out several times yesterday.

I do believe you are correct that this is a push towards revenue for Yahoo.

Think about it:

The more space that is available, the less they have to deal with their #4 customer complaint - my inbox is full and bouncing email!

Also, Yahoo cleverly markets to you eventhough they say they don't sell your email address. Bulk lists of users are available to most anyone by making a bot to find yahoo domain email addresses. For instance; find all email addresses that begin with "a" and end with "@yahoo.com" (That finds me) - guess who makes and sells a tool that can do that? (Psst...yahoo)

Re:Call me a cynic but...

[Spoing]

1. In all reality, this is just driving toward another revenue stream for them. It is much easier to charge Spamers a fee to reach you than it is to get you to pay 19.99 a year for Mail Plus.

Why would Yahoo! do anything that would cause them to be blacklisted?

(Before you say nobody would blacklist Yahoo check history; national mail providers have been blacklisted in the past -- when they decided to do nothing about spam and pissed off enough people.)

Why is everyone so hopped up about junk e-mail..

[Anonymous Coward]

..in comparison to the amount of paper junk that appears at their front door?

It seems every nerd and his dog only understand computers and go on and on about this major threat to humanity. Outside their bedroom, in real life, huge amounts of environmental waste is being created from paper junk mail.

Nerds need to switch off their computer once in a while, wash the dried in sperm off their hand and step outside to their mail box and see where the real problem is.

Re:After A While In The Works...

[soyle]

Probably because the submitted link ends up pointing to dc.h4xx.com rather than the indicated yahoo.com link.

No, it won't.

[warrax_666]

You're confusing the the envelope From (ie. where bounces and suchlike go) and the From: mail header. DomainKeys/SPF still allow completely arbitrary From: mail headers.

Re:No, it won't.

[DrSkwid]

Nothing to do with the Envelope, all to do the with the RFC822 message :

http://antispam.yahoo.com/domainkeys

"When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email."

"The DomainKeys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key from DNS for the claimed From: domain."

This is good news for our roving buddy, all he needs is a way to sign the message himself.

This also means that you could sign and send the messages on *any* machine so long as you had the private key handy.

I wonder how long it will take for people to realise that their private key has been stolen and is being used to sign spam ?

Re:No, it won't.

[lowar]

I wonder how long it will take for people to realise that their private key has been stolen and is being used to sign spam ?

A very short time, since the bounces will start rolling in in no time.

CU Micha

Re:No, it won't.

[demi]

This is good news for our roving buddy, all he needs is a way to sign the message himself.

As I read the DomainKeys(tm)(pat. pending) spec, he can't. The signature includes all the headers, and if some get added or changed (as they will when passing it through the MTA) the signature's invalid. See the DK FAQ discussion on mailing lists.

Now, let's say I send mail From: my domain "example.com" through MTAs at tmail.com and hosting.com in addition to example.com. Can I publish the public keys for those domains in records for example.com? This I don't know.

Re:No, it won't.

[DrSkwid]

but they won't though.

bounces are sent to the envelope from, not the RFC822 From: header on which DomainKeys operates.

MAIL FROM:dev.null@slashdot.org
RCPT TO:lowar
From:drskwid@hotmail.com
x-domain-key:b lahblahblahb_valid_signature

If I stole Hotmail's private key I could sign it just like hotmail's outgoing MTA as valid email and have bounces sent to dev.null@slashdot.org

Re:No, it won't.

[DrSkwid]

nope, the outgoing MTA signs the source email as it leaves the MTA, so long as two different MTA's would generate the same same signature for the same email the contents of that source email is irrelevent.

He just needs an SMTP sending script on his laptop.

One can also imagine that one would sign just the body text of the email and let the headers be freely altered. All that can be checked is that the signature was as expected from the MTA delegated to sign for domain in the From: user@domain

The only new piece of information provided by DomainKeys is that the entity that signed the email knows the passphrase for the key that's in the central database for the domain in the From: header.

You still can't trust *any* of the other information to be accurate beyond whatever means you have in place already.

Re:No, it won't.

[lowar]

Sure, one can use different envelope and header From-addresses. But spammers could use different adresses now and still I get bounces from spams which use a forged address from my domain.

As for the stolen key: you need to protect it the same way you protect any authentication tokens today. If you suspect it got compromised, simply generate a new pair and be done with it.

Re:No, it won't.

[DrSkwid]

you're missing the point

I can steal your key and sign messages with it, use my *own* MAIL FROM: in the envelope and you will *never see* any bounces from it and will be none the wiser.

Re:No, it won't.

[lowar]

You are right, I hadn't thought of differing envelope addresses in my first reply.

But (and that is something I've already said) the whole situation is in no way different from any other authentication scheme. If someone gets a copy of your password/certifikate/thumb print/whatever and starts sending e-mails using smtp-auth and an empty envelope-from, you will never find this out too.

Necessary Evil

[Trestop]

While software patents are indeed evil, the situation would have been worse has Yahoo not take out a patent on the algorithm.

Being a highly visible algorithm, its quite likely that has it not been patented already, someone (for example, a large software corporation, hint hint) would just go ahead and patent Yahoo's DomainKeys instead - or maybe just something similar enough that will be called, maybe, "Authenticated Sender Identification". US Patent office officials, being dumb enough or greesed well enough will just pass it w/o due examination and then said corporation can just go ahead and sue everyone deploying a mail server with Domain Keys!

Now, of course the best solution would be to have software algorithms not patented (in the US and elsewhere), but that being no more then wishful thinking the next best thing is exactly what Yahoo has done.

I myself thank them for that.

Re:the tollgate for the next "eyeballs" of the net

[igaborf]

5. Company BigBox's customer says, "I'm supposed to be getting mail from Company X and it's not showing up in the mailbox I'm paying you for. Deliver my fucking mail RIGHT NOW or cancel my fucking account and refund my money."

Put your tinfoil hat back in the closet, AC.

Should work for virus mail too then

[steve_l]

I hate my inbox being full of bounce mail from viruses; domainkey and SPF can make it easier for auth systems to silently kill it.

Of course, I suspect this won't happen because even today, when all virus mail uses forged sender addresses, too many virus scanners insist on sending "your email has a virus, here it is attached" responses, despite the fact the up-to-date virus scanner could trivially have a flag to say "spoofed, delete it" next to the fancy virus signature stuff you have to pay $$ for.

Re:the tollgate for the next "eyeballs" of the net

[Anonymous Coward]

or cancel my fucking account and refund my money.

The reason why no tinfoil is involved and why this will happen is the same reason google can display ads on your gmail box - to support the free service that they are giving you for free .

It will become acceptable to charge companies for access to large herds of eyeballs (that gathered there because something was free) - that is my bet/prediction. And it will be accepted because "it is a good way to reduce spam and support free services".

I hope I'm wrong, but I won't the way things are going.

I use it, it sucks

[walterbyrd]

I use yahoo email. It's okay, but the spam checking feature sucks.

It seems to work in almost arbitrary fashion. It never "learns" like it is supposed to. No matter how many times I indicate that certain senders are not spam, or that certain senders are spam, yahoo files emails from certain senders in "bulk mail" other in my standard inbox.

Since I have to check both my "bulk mail" and inbox anyway; there is little benefit to yahoo's spam checking. I appreciate the effort, But, it doesn't work well enough to be very helpful.

Re:I use it, it sucks

[The Cisco Kid]

domainkeys is a way to tag your *outgoing* mail with a signature, to enable others a chance to determine if a mail 'from' your domain is valid, or is a forgery.

It has nothing to do with incoming mail unless the sender domain of a given peice of mail uses it, then if you get a mail claiming to be from that domain, you could check it. So before it will have much of an impact, *lots* of domains will have to implement it. But since (at one point at least) the big freemail providers domains were popular for forging as the sender of spam, this will help everyone to be able to identify and block or devnull that..

Yes, but this isn't what is important

[Trestop]

What's important is that DomainKeys signs the content of the email itself, so you know not only that this email came from an approved sender, but also it wasn't tampered with on the way. As a result remailers that add content (such as mailing lists) will have to re-sign the messages passing through or remove the DomainKeys headers at all, which is quite a headache.

OFF Topic!

[Donny Smith]

WTF?

Your posting is named "Spam and Patents" and there's not a single thing about spam (except in the subject).

Your posting, Sir, is non-relevant and off-topic.

Re:OFF Topic!

[Elektroschock]

Everybody knows that Spam filter technology is covered by many trivial software patents. In Germany there was a case Nutzwerk vs. cobion. Patent trolls like spam-filter patents. You can search the patent database http://gauss.ffii.org Unfortunately spam is not named spam. As far as I remmeber Eolas and McAfie also hold anti-Spam patents. It is worth to start a collection of swpat. Note that currently some large corporations funds a company that buys bad patents from patent trolls.

Why not a different approach

[halftrack1950]

Most spam is designed to generate a purchase using a credit card. Most credit card companies are controlled by US companies. Why not go after the spam sites merchant accounts and get the cooperation of the credit card companies to shut them off.

Re:Why not a different approach

[Anne Thwacks]

Why not remove the banking licence from credit card companies that don't shut them off?

How much profit do credit card companies make from spam?

Maybe that explains why there is so much spam!

Re:Why not a different approach

[clive_p]

I also realised that spam only works because almost nobody responds. Nearly all spam now wants you to click on some web-site. What if there were some free software that we could all download and use, which when our computers were otherwise idle just continually tried to access the URLs listed in all our recent spam messages - if enough people did this, say a few millions of us, then all spam-related web-sites would become unusable because of overload. Wouldn't that tend to put spammers out of business?

Re:Why not a different approach

[Neoncow]

Spammers would become DOSers.

Patent it

[codepunk]

Well if this is what is going to happen then why don't you patent it? This would probably be covered nicely by a business method patent. When they start doing it you sue the hell out of yahoo and retire.

Re:Trouble for campus emails also

[Anonymous Coward]

You misunderstand - if your college implemented it, then *other* people would be able to use it to verify the authenticity of mail sent from your college. To combat mail forged 'from' banks, the *banks* need to implement it for their domains.

Hosting multiple domains

[IgorMrBean]

I'm wondering about that, because, as a hosting provider, we host a lot of domains.

By reading this proposal, it means that each domain will need a pair of private/public keys.

My customers will probably don't care about that, and will require that we take care of handling dozens of keys... that can be a mess for hosting compagnies....

Re:Hosting multiple domains

[Russ Nelson]

Each domain will need a dns entry, but you can point multiple domains to the same key pair.
-russ

Re:Hosting multiple domains

[PalmerEldritch42]

I think you are looking at this wrong. This is a chance for the hosting companies to add a value to their service offering.

For an additional $5/month, we'll make sure that all of those pesky DomainKeys paperwork gets filled out on time...

I think it could be a winner.

Re:Why is everyone so hopped up about junk e-mail.

[SillyNickName4me]

This may not be true where you live, but overhere (the Netherlands) you can stick a small sign to your door forbiddign delivery of comemrcial and/or unaddressed (surface) mail. Ignoring this sign can and at times will get the sender into quite a bit of trouble.

So, I don't get huge piles of paper junk, actually, I get evry little of it, and it is no issue for me at all. Spam mail on the internet is an issue.

How to break DomainKeys

[Ben Hutchings]

Suppose someone sends a single message from one throwaway web-mail account to another, getting it signed on the way. Then suppose he spams the signed message via whatever mail servers he normally uses - ideally zombies that won't change the signed headers. Am I missing something, or does this make DomainKeys worthless?

Re:How to break DomainKeys

[Russ Nelson]

Not worthless, but harder to administer. You would have to give a separate selector to each user. If the DNS queries for that selector got "too large", they might want to revoke that selector.
-russ

How this will cost me money....

[guttergod]

By implementing this ISPs can make money by selling hosting of domainkeys on their mailservers. This would totally suck for those of us who are not able to keep our own mailserver. My ISP has blocked port 25 and spamlisted all the public IPs (which really sucks), as soon as they realize people use this, they are most certainly going to charge me for sending mail using my domainname because they would have to set up their server for my emails.

Postfix or Amavis?

[koehn]

I'm interested in using domainkeys (heck, I use SPF, I even greylist), but I'm unable to find an implementation for Postfix or Amavis. Is anybody working on an implementation? I saw the library that yahoo has, but I just don't have the time to code my own right now.

I'd think an Amavis implementation would be ideal, since it scans everything anyway, and integrates with other mail servers so easily.

SPF is the better choice

[slashfun]

While i'm all for leveraging any tool possible to combat spammers, as long as it follows the EFF's policy on SPAM filtering, I think it is important to standardize on a proposal created and put forth by the Open Source community, and the best game in town is SPF.

Let's git er done...

Peripheral vision

[johansalk]

I first read that as "Yahoo! now using donkeys" to deliver mail

Where are the patent claims?

[sunset]

I think an even more basic question is, where are the patent applications and what do they claim? Especially as Yahoo's licensing agreement says:

3.1. You agree not to assert against Yahoo!, or any other DomainKeys Developer, a patent infringement claim against any Implementation ("Implementation IP Claim").

They proceed to give identification numbers for patent applications, not granted patents. I was not able to locate these applications at the USPTO, so perhaps they are unpublished?

For all we know, Yahoo is trying to win legitimacy and enforceability for overly broad patent claims, where we don't even know what they are. How could a rational person agree to that?

Heres why it stops spam

[Jahz]

There seems to be alot of confusion amound /.ers about how SPF and DomainKeys fight spam. The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants. e.g. you cant pretent to be Bank of America anymore.

DomainKeys makes it harder to send general spam as well. It allows spammers to be tracked. It also allows easy blacklisting of known spam servers. ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.

Finally, while it is possible for a spammer to change SMTP servers frequently, this adds significant financial overhead. I believe DomainKeys has the ability to eliminate all of the small spammers, as well as almost all phishing scams.

Re:Heres why it stops spam

[Daedala]

It won't stop phishing. They'll just use the domain names they've already bought -- secure-visa.com, ebay-fraud.com, etc.

Or accountonline.com or verifiedbyvisa.com...oh, wait, those are real.

Or they'll go down to smaller, localized ISPs and vendors who haven't yet implemented, like spamming for Podunk Bank on the @podunk.net addresses.

On the other hand, it's _much_ better than SPF (SPF headers are easily forged, and I'm more likely to get spam that passes its SPF check than legitimate mail that does).

Re:Heres why it stops spam

[Jahz]

It won't stop phishing. They'll just use the domain names they've already bought -- secure-visa.com, ebay-fraud.com, etc.

Actually Daedala, you have touched on one of Domain Keys greatest strengths. If all spammers used their legit, yet misleading, domains to spam, DomainKey-enabled servers could effortlessly block the keys associated with these domains. Thus, properly signing scam e-mails will cause your server's key to be blacklisted *very* quickly, and permenantly on the organization level.

Perhaps....

[Anonymous Coward]

Have you checked the headers on those "white listed" addresses that end up in bulk mail? If they are mailing lists, it could be they are using the bulk mail precedence flag and Yahoo is doing the right thing.

agreed, is broken - DomainKeys should be chainable

[ClarkEvans]

DomainKeys should use 'sender' and not 'from' line. In this way a gateway can read the incoming mail, verify the DomainKey signature of the sender, perhaps mark that it was accepted for delivery and adding what ever headers it wishes, and then using DomainKeys to sign the outgoing message (but using its own sender). In effect, DomainKeys should be 'chainable', trusted gateways should continue to work as they do today, in a sequence of trusted servers.

Yahoo Mail looks horrible in Firefox

[jvagner]

Got the latest Firefox on FC3 and as of a week ago, or so, the left hand nav column shows up in the middle of the page, with a huge whitespace to the left.

I've never had layout issues with Yahoo, but this makes it pretty useless for me. Anyone else have this issue?

This is with a stock Firefox, no extensions.

Re:Yahoo Mail looks horrible in Firefox

[Anonymous Coward]

FC3? 1.0 final has been released. Go upgrade!

Re:Yahoo Mail looks horrible in Firefox

[jvagner]

I did that.

Re:Yahoo Mail looks horrible in Firefox

[Anonymous Coward]

Looks fine in mine. I've also block the javascript advanced features and popups - only allowing cookies. Maybe there's something there?

Oh, and I run the AdBlock extension. This may help reduce the garbage they dump on your screen (all one line):

/(/|\.|\?)(banner|page|fuse|side|get|klip)?a(d_?(s |sc?|se?rv(e|er)?|banner|opt|click|log|js|ids)?)?( /|\.|\?)/

Re:Yahoo Mail looks horrible in Firefox

[jvagner]

Yeah, I'd checked that. It's not cookies or javascript. It's putting the rest of the left nav to the right of the three buttons up there.

Aggravating.

People unclear on the concept...

[CustomDesigned]

SPF helps stop forgery, not spam.

Suppose I want to be sure to get purchase orders from joe@example.com. I add his domain to my whitelist so it doesn't go through my bayesian filter (in my real life experience, POs tend to look like spam to filters). Unfortunately, I now get 6 spams claiming to be from joe@example.com for every real message from joe@example.com.

So I ask Joe which IP addresses he normally sends mail from, and whitelist his domain only when it comes from those IP addresses. This is really what AOL used to do with high volume mailers (not necessarily spam - think mailing lists). Now I reliably get Joe's POs without all the forgeries.

Now Joe gets a great deal at a new ISP, and all his email IP addresses change. Drat! I missed one of his POs! So Joe and I decide we need an automatic way for him to keep me up to date on which IP addresses are authorized to send his mail. After a handful of false starts and as many months, we come up with.... SPF. (Well, actually some other guys came up with it - I just use it.)

Since SPF is published on DNS, people getting spams claiming to be from me can now check my SPF record and REJECT them - instead of sending me death threats (yes, I really get death threats from irate recipients of spam forged in my name).

This also cuts down on bounces from spammers forging my email and trying to send to non-existent targets. The bounces I still get, I can ignore because I sign my outgoing MAIL FROM with SES (Signed Envelope Sender).

Now, most of the spam I still have to deal with is not from spammers (who are mostly blacklisted now), but from idiots who send replies (instead of a DSN) when they detect a virus that forged my email. Some ninkompoops even send replies for non-existent email targets - usually with some stupid message about how they had to change their email address because of spam.

Re:Why is everyone so hopped up about junk e-mail.

[BitwiseX]

http://www.emailias.com/learning/spam_facts.php Do you think there is that much lost revenue from paper junk mail? Junk snail mail is also a problem. Thank you Captain Obvious.

here's why it doesn't.

[argent]

The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants.

You're mixing up phishing and similar identity theft scams and spamming. This is like arguing that laws against online porn will stop spam: you're targeting particular uses of spam... and this has never worked except partially and temporarily.

DomainKeys [...] also allows easy blacklisting of known spam servers.

We already know from the contents of the message, from the source address, the envelope, and the headers, exactly where the spam is injected. DomainKeys provides precisely NO new information about the source of spam.

ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.

Spammers don't use their ISPs servers, except by accident. They run an SMTP server right on the injecting system, and spam direct from the dialup, Cable, ADSL, or T1. When possible they don't even own the injecting system: it's a hijacked wireless link or a PC they've taken over with a virus. When they do find they're going through the ISP's servers they switch to a different ISP, because the only reason an ISP forces SMTP connections through their SMTP servers is to block spam.

Re:here's why it doesn't.

[Jahz]

Spammers don't use their ISPs servers, except by accident. They run an SMTP server right on the injecting system, and spam direct from the dialup, Cable, ADSL, or T1.

This is precisely the form of spam that will be impossible under domain keys. If I send spam from my Comcast cable account, the outgoing message will have my insanely_long_dhcp_dns_id.attbi.net or whatever ridiculously long DNS entry they assigned me this week. There will be no DomainKey or SPF record on the attbi.net DNS server corresponding to my SMTP server. Therefore such mail will be rejected. Note: I have'nt finished reading the ASTA's proposal to the IETF so I may be slightly off on this one. Anyway, I do not claim that the standard will eliminate spam, I do claim that it will make it much more difficult to spam from low cost ISP accounts, such as my cable account.

Re:here's why it doesn't.

[argent]

This is precisely the form of spam that will be impossible under domain keys.

Only if DomainKeys are universally supported for all such cases. And ISPs are willing to let their own customers register when it's appropriate.

I mean, we can already block dynamic addresses through an RBL pretty reliably, and since you're assuming enough ISPs go along to make it worthwhile you might as well assume they would self-RBL their own dynamic space and make it absolutely accurate.

And they haven't, in general.

This may help, though I'm not at all convinced that it'll be as effective as an RBL and they don't even make an order of magnitude difference in the spam level. To really have an impact on spammers, you need at least three nines coverage and you need to keep the spammers from working around it, or they'll just concentrate in the part of the net that's not served by cooperative ISPs... and that's an awful lot of it.

Re:here's why it doesn't.

[Jahz]

But with 99% global cooperation, wouldnt this solution provide additional accuracy for existing spam filters? What I mean is this: - Assume 99% of all ISPs implement DK. - Assume the major email providers (AOL/Time Warner's cable co's, AOL itself, Yahoo!, MS,......) got together and formed a public blacklist consisting of domains that send alot of spam. If the blacklist database listed spamming domains along with the ration of spam:legit e-mails from those domains, that data could be used to make filtering more accurate. For example, SpamAssassin could add a few points to an e-mail from a domain with high spam volume. Im not saying combining these solution would even approach four nines, but it may help. Otherwise, I see your point, this system is not very useful without full participation.

Re:here's why it doesn't.

[argent]

But with 99% global cooperation, wouldnt this solution provide additional accuracy for existing spam filters?

With 99% global cooperation we could stop spam in a year any number of ways that would be easier and less damaging than adding layers of criplling checks to every SMTP transaction.

The reason we need technological aids to fight spam is simply because we can't get anything like that. It took years of hard work and real effective blacklisting by RBLs just to get as much cooperation as we currently have. Getting 99% of ISPs or even getting the ISPs responsible for 99% of the global market to agree on things as simple as blocking port 25 for dial-up users... let alone cooperating in something like this... is science fiction.

Something that *is* helpful in stopping spam...

[argent]

whats really needed is a CPU intensive solution like the hashcash suggestion

Which kills legitimate mailing lists.

There's one way to prevent spam and that's to make it a lot more expensive in human time to send unsolicited bulk email. There's no way to do this, though, without making it a little more expensive in human time to send single messages, or to sign up to a mailing list.

I've been using it for my family's mail for the past few years and so far as I know a total of one Nigerian has decided it's worth their time to jump through the hoop to get in.

The problem with this is that people who haven't yet accepted that spam can't be solved without making mail a little harder to use aren't willing to jump through any hoops, and that most people running mailing lists aren't yet set up to give people the necessary information to whitelist them.

There's a bunch of different mechanisms that can be used, once you decide to do it. Right now just demanding a specific keyword in the subject line is more than enough to keep the spammers out. Later, I'm sure, cryptographic techniques will become necessary as spammers start parsing bounce messages and looking for clues. But right now this is all you need to do... it works, it works well, and it's easy to implement...

Amazon referral whore looking for karma.

[Anonymous Coward]

Who modded up this two-sentence junk message?

Check out cloudkj's posting history and see.

What's Wrong With Spam?

[peccary]

I have about a hundred email aliases. I get about three genuine spams per day - and a lot of "junk email" from vendors who I've done business with, but that stuff is, strictly speaking, legit. It's just kind of annoying in its volume.

So I ask again -- what's wrong with three spams a day? BFD.

Re:What's Wrong With Spam?

[Anonymous Coward]

3 spams a day?? Only?

My personal server turns away over 100 a day. Sometimes up to 4 thousand a month.

On top of that, I still get 10 or so a day that make it through.

You want one unavoidable way to get on a spam list? Register a domain and put one of your e-mail addresses as a contact. See how long your inbox stays clean without any type of filter.

humm

[Ambient_Developer]

A patent entrenched system, we will all see how well this works, I think we all remember Sender ID and it's brilliant failure.

SPF still better than DomainKeys

[Anonymous Coward]

SPF looks up the allowed IP addresses where a domain can send e-mail from and allows or disallows a connection from a server on that basis. If it's disallowed, then no message is sent.

DomainKeys looks at the signature provided in the header to see whether it's spam. Oh wait. The spam was already received (wasting my bandwidth) and stored on my server (wasting my disk space), and now I have to verify the signature is correct (wasting my CPU cycles). Even Yahoo admits it will add 10% to your CPU overhead.

So, what about the small percentage of e-mail that is forwarded or relayed? People may complain that this e-mail then can't be checked by SPF. Then do one of two things:
1) Turn off your server's SPF checking just for that forwarder or relay, or
2) Turn on SPF checking at that forwarder or relay then do #1. If the forwarder or relay is SPF checking, then you don't need to worry on your end.

SPF wins hands down. It's the only one that actually decreases spam e-mail traffic!

open source

[torrents]

anything that helps fight spam can't be all bad, but it would be nice if there was a completly transparent/open source system that we could all agree on rather than a dozen competing standards

Solution - canonicalize or ignore headers?

[dwheeler]

This is a nasty problem; ideally, MTAs shouldn't change the headers at all. One solution would be to canonicalize the headers. Say, "remove all headers beginning with X-, then sort the headers alphabetically; identical header names use the pre-existing order". That would solve this. Another solution would be to ignore all but certain headers. Ugh.

Not anti-spam - authentication. It authenticated!

[dwheeler]

Ben Hutchings has thought of a clever attack (send a single spam message from one throwaway web-mail account to another on the same system, getting it signed on the way, then send copies of that out via other zombies). But I think you're missing the point. DomainKeys doesn't prevent spam; it just proves that the email really was sent from the given domain. So, if all the zombies are sending out copies of the email, then so what -- the recipient can correctly determine who the "real" sender's domain was, using the DomainKeys values to prove it.

Basically, things are working just how they're supposed to work - you can confirm that the email really was from a Yahoo! account, or whatever the domain said it was from. So in some sense, this isn't a problem at all.

This attack does reveal an underlying assumption, though -- it's assumed that if a message is signed, then only the sender will be sending it, and a "good" sender will try to stop spam. This attack ruins this assumption; an attacker can use a mail hosting service like Yahoo to create a valid signature, and copy that email to the entire world. The problem isn't that it's not authenticated -- the problem is that it's hard to stop someone from sending those extra messages.

This approach would still work, if you could at least determine WHOSE email was being spammed. It does look like straight DomainKeys does have this as a weakness. If there's one key per domain you might not be able to exactly determine who sent the message (by itself). I guess a signer could record each hash it signs, and who sent it, so you could trace it back to the specific individual. Alternatively, you could use per-user signatures, and then you'd be able to tell.

So, if a signer records the hashes it signs (along with who made the request), or uses individual user keys, I think it still works.

Re:the tollgate for the next "eyeballs" of the net

[Anonymous Coward]

You aren't wrong. In fact, customers who subscribe to Yahoo!Mail, .mac, etc.. would likely be made fully aware by their service provider that only people on "paying-domains" can interact with them (including other major service providers, like Hotmail, Gmail, etc..) and customers are likely to use this as a new metric for deciding who to do business with. In other words, people who discover they can't interact with a certain domain will begin to assume that the lost messages are due to financial issues and shy away from them. (TCM's "The American Way" begins playing.) While interesting and technologically practical, if it ever goes into effect, it is certain to be defeated by legislation from the Republican controlled Congress or Senate or by the Republican controlled high-court. Why? Because it screws small business and so it is bad for the economy.

Re:the tollgate for the next "eyeballs" of the net

[Anonymous Coward]

Nice thought, but the Legislature would never permit such a system to stand for very long. First of all, there will be a call to tax it if it were allowed to stand, and we all know how the legislature feels about taxing things related to the Internet. Second, this is bad for small businesses (and thus, the U.S. economy), so the Legislature would likely impose a regualtion on any ISPs who have more than, say, 10K subscribers that they have to carry everyone's e-mail unless they can charge in a way that is equitable to domains run by small businesses (meaning they are paying back as much as they are taking in from them).

> beeeyyyyoutch

Uh, are you trying to say: biatch ? I have to say, I also enjoy your use of "fuck off" and "Bad People(TM)". You may want to broaden your horizons a little so you understand the Big Picture. You are half-way there, at least.