Slashdot Mirror
Yahoo! Develops Anti-Spam Architecture
prostoalex writes "Yahoo!, the owner of one of the largest e-mail systems in the world, is said to be developing a cryptographic product that will be offered freely to mail servers. 'Domain Keys,' according to the Reuters article, would require the message sender to authenticate in order for message to come across a trusted e-mail network. The idea has been around for ages, however, it required someone from the big league like Yahoo! to step in." While Yahoo! isn't the first name that comes to mind when I think of trusted email, it's still a step in the right direction.
$ telnet mx1.mail.yahoo.com 25
Trying 64.157.4.78...
Connected to mx1.mail.yahoo.com.
Escape character is '^]'.
220 YSmtp mta108.mail.sc5.yahoo.com ESMTP service ready
It looks like they run YSmtp, just like everyone else I know. In all seriousness, I'd imagine there isn't much of Yahoo's infrastructure that isn't highly optimized for Yahoo's own use. I think that Yahoo did a lot with FreeBSD at one time, but I'd presume whatever they have isn't just an out of the box app.
tmda
My experience over-all has been excellent, with on minor exception: This was from a google search on "yahoo marketing preferences", and pretty well sums up what happened. They basically reset user marketing preferences, twice in about 4 years if I remember correctly.
It was a bad decision IMHO, but easy enough to reset your preferences, here is yahoo's page on privacy, with links to reset your marketing preferences:
http://privacy.yahoo.com/
Other than this one issue, I've been very happy with Yahoo. Being able to check all my e-mail on one Web site for free is great. Never have lost any e-mails, no problems at all.
Maybe I don't understand the problem. I thought Yahoo's new scheme was designed to authenticate the mail server that originated a transaction with a Yahoo mail server, not to authenticate the domain in the "From:" line.
Mea navis aericumbens anguillis abundat
RTFA: "Yahoo said its 'Domain Keys' software, which it hopes to launch in 2004, will be made available freely to the developers of the Web's major open-source e-mail software and systems" ... "Yahoo's proposal should be attractive to other e-mail providers because it is free and comes with no special restrictions."
1) The domain owner/administrator (or their mail server administrator) I imagine. I expect that some tools will be available to generate the keypair. The public half will be configured on the DNS (would this require a new revision of BIND to handle a "DK" type or will a TXT field be abused for this?) and the private half will be installed into the mail server.
...
When a mail from that domain goes via the mail server, the mail server will calculate the hash of the message and encrypt with the private key and add that as a header to the e-mail before sending it to the recipient.
There will have to be some transitional period though, because it will take time for all mail providers to support domain keys, and any spammer can send spam via an undomainkeyed domain, yet you won't want to block undomainkeyed domains until all your contacts are using it. Maybe there would be a "Trusted Inbox" and "Untrusted Inbox"
Bayesian filters suck because they only handles spam at the end point, in the mail client. The best place will be on the mailserver, before you have to download it.
They run, or at least used to run a few months ago, a (possibly patched) version of qmail:
h tm l#7.47
http://www.qmail.org/top.html
and search for "Yahoo". I also know it from an independent source because I discovered a bug in qmail:
http://www.washington.edu/imap/IMAP-FAQs/index.
while tracking a bug report cocerning my MUA.
The proposal is very simple and most of the posts are just plain wrong about what it means.
All mail servers will have a public/private key of some type. The public key will be stored in the DNS system as extra data.
When an SMTP server connects to another SMTP server, the sending server will encrypt something (likely a checksum) with the private key for the domain the mail is from (likley the envelope from, not the From: header) and place it in a header.
The receiving server will then grab the public key for the domain in the envelope and verify the message is being sent by a server that is authoritative for that domain name.
Very simple. Now spammers can't send spam and make it look like it came from my domain. I'm currently getting flooded with bounces from a spammer doing this, so I really want this proposal adopted.
The implementation can be phased in, too. The mail server could add a header saying if the domain was verified and spamassassin could then adjust the spam rating of the message appropriately. Eventually servers would be configured to refuse mail from unverified domains.
So if you own a domain name, you just have to generate a key pair, add the public key to DNS, and add the private key to any SMTP server you send through.
Once this is required, you theoretically will always be able to contact a person responsible for the sending of the spam (whoever is listed in the whois database for the domain). Contacting them (or abuse@) would solve the problem with any major email provider, and you can just ban email from any small provider that doesn't give an adequate response.
Aside from the possible computational requirements for all the crypto work, I don't see any downsides to this. If by some chance a spammer broke/acquired your private key, you'd just generate a new one and update your DNS entry.
The basic idea, as I understand it, is that the DNS for a domain holds a public key, and mail sent with a "from" address in that domain must be signed with that public key. That's an old idea, and not all that bad. You create your own public/private key pair; you don't have to buy a "certificate" from somebody. (I think.) If you control a domain's DNS info, you can send mail from anywhere with that domain listed as the sender, as long as you know the private key.
For the free-mail services, it's fine. All their mail is authored via web applications and sent from their own servers. Only the service has the private key. Only the outgoing SMTP servers need to know the private key. That's the Yahoo Mail case.
If you own a domain, you should have full control over your own public and private keys. But adding additional info to a DNS record is not well supported by most hosting services. If you're not running DNS yourself, you may have problems setting your public key. Hosting services have to support this.
Signing can occur either in the original user agent (the SMTP sender) or in a mail forwarder. It's easier to implement this in mail forwarders, but if you want to send using a return address other than the one of the mail forwarder you're using, your user agent has to know how to sign mail.
If you're downstream from an ISP and don't control a domain, the ISP owns the key for the domain and can control what they sign. That has implications. They might force you to use web mail, for example. Or run their client software on your machine.
Spammers can still register domains, run their own DNS, sign their mail, and spam. It doesn't really stop spam.
Your public key is now valuable, and a target for spyware and viruses. Expect to see viruses that steal public keys from (inevitably) Outlook and send them to spammers. Or just send spam from the attacked machine.
What this really does is provide a clear way to identify joe-jobs using addresses from major mail services like Yahoo Mail. That helps Yahoo more than anybody else.