Slashdot Mirror
Gmail Begins Signing Email with DomainKeys
NW writes "According to a post at IETF's MAIL-SIG list, Google has begun to sign outgoing email from Gmail with Yahoo's DomainKeys signatures. This is the first large provider of email that is actually doing so (not even Yahoo has started that yet)."
Google has almost everything now, why don't they make their own Anti-Spam domainkey type service?
You mean the e-mail I got from BUYYYY_CH33P_M3DZ@gmail.com might not have been authentic!?!?
To figure out how to implement DomainKeys. Seriously, that thing is a best.
hum.. thats an interesting thought.. i dont see why that would be a concern, but you could always just usea free yahoo account for those emails you want to be deniable...
Nathan Friedly
-
Don't get me wrong, I'm not one of them Google bashers (I don't believe the Google Desktop is spywer, for example), but in this case I would like to have an opt-out option!
Since Gmail's a free service, I believe your opt-out mechanism is to use something else. Given this is largely an anti-spam technique (to prove an E-mail is legitimately from the domain it says it is) I can't see Google being willing to provide an opt-out on this, it would undermine the whole effort.So will this prevent spammers from sending spams via a Gmail account?
This DomainKeys system relies on both sending and receiving servers to validate an email, will it ever catch on?
Rock that crushes, Paper & Scissors that don't matter.
I saw DomainKeys and read DonKeys. I took me forever to work out how such an animal could be used to sign emails for spam-filtering... I'll be releasing a white paper on it shortly.
Why does google have to do this? Their adoption of ANY email program will help sway people to use that service.... If something is widespread, people will follow, is google the first step?
Sometimes the majority just means all the morons are on the same side.
Use something else. Gee, that was hard.
Dear god, please tell me this was a joke ... Yahoo is the one setting up this DomainKeys system!
So we have all these featurs even Yahoo doesn't have.. and yet we're still beta?
I like muppets.
All that DomainKeys does is let the recipient know that the domain name is accurate. In the usual case (not that gmail is necessarily usual), the recipient could check the reverse DNS, and match it against the forward DNS. So unsigned mail is not necessarily unidentifiable.
-russ
Don't piss off The Angry Economist
What if you send mail through domain you own, A, but they only provide redirects for that account. Ie... user@A. Your ISP, the one you pay money to have access to an smtp server, is domain B. This technology now requires either i) I set up my own SMTP server to send mail for said domain, or ii) start handing out my redirect account, which DEFEATS the purpose of a redirect account. Or, I'd have to contact the ISP and get them to set up an smtp server just for my domain, so that it could sign keys. Or maybe I've misinterpreted the technology, but that's how it appears to me at the moment.
I don't see how it's any better than SPF?
In fact, it could be worse since now a calculation is required to verify the sender in addition to the DNS query.
Anybody care to enlighten me?
No sig
Here is an example from NW's blog.
Opera Watch - An Opera browser blog.
How DomainKeys Works
How it Works - Sending Servers
There are two steps to signing an email with DomainKeys:
1. Set up: The domain owner (typically the team running the email systems within a company or service provider) generates a public/private key pair to use for signing all outgoing messages (multiple key pairs are allowed). The public key is published in DNS, and the private key is made available to their DomainKey-enabled outbound email servers. This is step "A" in the diagram to the right.
2. Signing: 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, and the email is sent on to the target recipient's mail server. This is step "B" in the diagram to the right.
How it Works - Receiving Servers
There are three steps to verifying a signed email:
1. Preparing: 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 step "C" in the diagram to the right.
2. Verifying: The public key from DNS is then used by the receiving mail system to verify that the signature was generated by the matching private key. This proves that the email was truly sent by, and with the permission of, the claimed sending From: domain and that its headers and content weren't altered during transfer.
3. Delivering: The receiving email system applies local policies based on the results of the signature test. If the domain is verified and other anti-spam tests don't catch it, the email can be delivered to the user's inbox. If the signature fails to verify, or there isn't one, the email can be dropped, flagged, or quarantined. This is step "D" in the diagram on the right.
In general, Yahoo! expects that DomainKeys will be verified by the receiving email servers. However, end-user mail clients could also be modified to verify signatures and take action on the results.
Well I guess were all beta testing testing Yahoo's Anti-Spam thing on Goolge's GMail. Therefore yahoo has free beta testers using their competion.
For our part we are definitely working hard to both sign and verify with per-domain statistical analysis by the end of this quarter. At that point, our ability, as perhaps the largest sink of email traffic world-wide, should afford some pretty meaningful data.
Being a pragmatist at heart, I strongly urge others to conduct similar experiments and trials in their own space, so that we can dispense with the speculation that seems to surround much of the discussions on /..
IOW, design by speculation strikes me as sub-optimal.
Alright, I DID RTFA, and basically what this describes is just another way to authenticate that the user is from that domain. Isn't that the same thing SPF does? They both seem to accomplish the same task, but SPF appears to be easier to manage and easier to support. My personal (commercial) mail server already supports SPF, sendmail et al. support it (via external component), and my Barracudas (awesome product!) are beta testing spf support right now.
Oh yeah, and gmail already support SPF. Why promote different standards that are apparently identical in purpose?
If you are out to describe the truth, leave elegance to the tailor - Albert Einstein
For those (like me) that have no idea what this would actually look like, here's the DomainKey header from an email I just sent myself from GMail:
c t:mime-version:content-type:content-transfer-encod ing; b=ONG9HfGg74ZbrOOI8IwjwhGUX+PlGp1+clGIyvWriiltDmXE xdmdDWoblELIrVMw3yex7xRyib6m4Q5pInSfi2mr1IQRZINzf2 qTI/9QtFMkpwJUcWJeBt8VPzdxpNCdItxyNnALLIXjrsBAcYsY 8Gv7C6HJR0E6OFZCM0qWrCo
DomainKey-Signature: a=rsa-sha1; c=nofws;
s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subje
I'd like to see personal signatures, not a per server one. That seems like it'd do much more to prevent spam than Yahoo's system, since Yahoo's system only tells you whether mail did indeed come from their servers. Just my two cents.
US businesses that currently accept chip and PIN/signature
This allows for someone with an account to send email from their own server, or for a company to use multiple servers. So it's better this way.
I hate to break this to you... but you're not Google!
I wonder when Mozilla will implement them.
They haven't included a version of SpamAssassin either which would be good for Windows users.
Im suprised that we dont have to sign an honor code every time we send an email these days.
no more gmailfs?
Correct me if I am wrong, but if I understand this correctly, and if filtering with this becomes widely adopted, then it will also prevent me from sending mails with my gmail-address from my smtp server.
So I would have to use their web-interface, or hope they wil eventually make a smtp-server useable for a fee
Not that this is not their right and all, and I could just stop using it if I don' like it, free service, yada yada..
Still, this gives a little too much control to my email-domain-provider about which smtp-server I can use, than I am comfortable with.
I have a web domain mainly to receive e-mail.
When I send mail, I use my domain in the "from."
However, my domain provider doesn't allow smtp, so my outgoing mail is through my ISP.
If my ISP supports domain-keys, they will sign my outgoing mail, but it will NOT match my totally-legitimate "from."
According to the domain-keys summary, this would flag my mail. In medical terms, this is called a false-positive.
How does domain-keys prevent something like this from being a problem, other than by forcing users to adopt a completely different e-mail stragegy?
I've quoted some of the interesting looking parts below.
See what I've been reading.
SENDER ID... Power UP! Kill the spammer scum. Captin we just don have the power! Engines to full throttle scotty.. Makes out with captin janeway humm lil offtopic GOGO Sender ID Ranger!
Ambient [Servlet Based Webapp Engine]
Why is everyone flipping out about domainkeys and SPF? Gmail already HAD spf...looky what I get from 'dig':
;; ANSWER SECTION:
...and from the headers of my email:
gmail.com. 300 IN TXT "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com ?all"
Received-SPF: pass (mojo: domain of gmail.com designates 64.233.170.203 as permitted sender) client-ip=64.233.170.203; envelope-from=xxx@gmail.com; helo=mproxy.gmail.com;
What we should question is why this is in my Exim logs for each gmail mail I receive:
2004-10-17 23:00:25 H=rproxy.gmail.com (mproxy.gmail.com) [64.233.170.203] Warning: remote host presented unverifiable HELO/EHLO greeting.
That's the mail server I'm running at home on my Debian server.
Yahoo's page says that this authentication system is currently being implemented only on the Sendmail server.
Stimutax!
Step 1: Make something addictive.
Step 2: Give it out for free.
Step 3: Start charging money.
Step 4: Rake in the money!
One of the greatest episodes ever.
"It feels like a Koala crapped a rainbow in my brain"
How would this work for people who use own domain name but forward their emails to Gmail
(Note: Gmail allows you the option of using a different Reply-To address instead of your @gmail.com address)
yes, it was a joke, the punchline revolving around the aforementioned fact that yahoo has not started using their domain keys system.
Nathan Friedly
Does this mean MS's caller-id is dead? It seems as if Google is going to set the defacto standard. We should all jump on board as soon as sendmail support DomainKeys.
Google using Yahoo's private domain key to sign their email?
;-)
If so, then I would say that Yahoo has serious problems and if Google is forging their signature, should revoke the key immediately and probably sue!
LedgerSMB: Open source Accounting/ERP
One of the things that really irked me about SPF was that it used the TXT record of the main domain to store information. Now granted, not many people use the TXT record in DNS, but I found it very short-sighted of SPF to use the TXT record of the domain itself, rather than having a separate subdomain. For DomainKeys, this is the case. According to the spec, information is stored in TXT records in domains like so:
sanfrancisco._domainkey.example.net
In this case, "example.net" is the domain this is all about, and "sanfrancisco" is the name of they key (yep, it seems you can have multiple keys per domain).
I haven't looked too hard into DomainKeys, but it looks very promising.
(not even Yahoo has started that yet)
/.) that they had now the absolutely perfect SPAM filtering solution in place, I wrote them why they implemented this for their freebie "mail.yahoo" accounts, but not for folks that are paying them 15 bucks a month.
..... the fuckers..... So, I replied to them that I didn't think it fair that freebie customers got a better SLA than those people paying 150 bucks a year.
Doesn't surprise me. My domain was once hosted with a pretty satisfactory ISP called SimpleNet (what a name, but their service was good!!). They were absorbed by Yahoo and continued under the brandname Yahoo WebServices. So far, so good...
Over the years, I got more and more spam, so when Yahoo one time announced (I'm sure I read it on
Oh dear, had I underestimated Yahoo logic!! The reply was that I could upgrade my account to a business account (for 30+ bucks a month) to obtain the SERVICE (!!!) of spam filtering
No answer of course and I moved my domain to another ISP at the end of the year.....
Browsers shouldn't have a back button!! It's all about going forward...
What about all of those zombie machines out there that send spam via Outlook - since that email is going out with a valid account, it would be flagged as legit.
Tell me where I'm wrong.
I am using X.509 certificate to sign all my email.
I feel that this gives better protection from email address spoofing that other domail or SMTP-server based scheme. I wish more people do like me.
I have just started taking advantage of my gmail account and like this feature being added. IMHO, it should be adopted by other free email hosting companies.
web hosting
So if the domain key says "comcast email" because im using their SMTP, does that mean my @blahblah email will be filtered out because the smtp doesnt match the domain in the To: field?
I see all of these articles on Slashdot about new ways to help prevent spam and forgeries but they have yet to do this themselves. Also you, or software developers for that matter, can't call it "Yahoo! DomainKeys", read the license. IEEE should reject this the way they did with Microsoft's SenderID until they come to their senses and stop being so stingy.
http://shit.slashdot.org/article.pl?sid=04/10/18/0 236201
What about
9. ????? 10. Profit!!! Wow, maybe I'm getting old. In Soviet Russia (jokes), Old memes are YOU!
My Favourite Meme
No, this will really work. It enables differential filtering based on the managed reputation of the sending service. (faughnan.com/spam.html).
I advocated this many years ago, but it doesn't need advocacy -- it will simply happen.
Unsigned email gets filtered very aggressively. Some will get lost of course -- aggressive filters err to false positives. People who want their mail to be read will move to authenticated sending services.
Signed email from domains with bad reputations will be deleted in the pre-filter. Reputation services will manage domain reputations.
Email from an authenticated sending service with a good reputation gets lightweight filtering. If the domain doesn't manage their members the domain reputation suffers -- and filtering gets more aggressive. Domain members head for the exits.
BTW, the same policy of managed reputation of sending services has a 'real world' equivalent. In the future world of high security, privacy may yet exist within communities that manage their reputations.
John Faughnan
jfaughnan@spamcop.net
has anybody succeeded in verifying one of the domainkey headers from a gmail message?
- delany-d omainkeys-base-01.txt
... s=beta; d=gmail.com; ...
after reading the ietf draft:
http://www.ietf.org/internet-drafts/draft
if this is in the message header:
DomainKey-Signature:
i think you should be able to retrieve the public key necessary to verify it by querying dns for a txt record for
beta.gmail.com
but i don't get anything back in the answer section when i run
dig TXT beta.gmail.com
anyone have better luck verifying one of these messages? or is the gmail domainkeys implementation incomplete at present?
about sean dreilinger
The Google engineers aren't stupid, they know that mail messages are routinely modified in transit, both the headers, which can be wrapped, rearranged, removed or added, and the MIME bodies, which can be decoded, reencoded, and even modified.
As engineers, they also know that cryptographic signatures are designed to detect message tampering.
Combine these two ideas and you get a system which will flag routine message modifications as forgeries, making the DomainKeys signature completely useless in practice. And yes, I've read the rfc draft, and found it wanting.
It *would* work if there was a standard set of well defined transformations performed on emails from the sender's MUA to the recipient's MUA. So if one Gmail user sends to another Gmail user, it'll be ok, because the message won't leave Google's servers.
But Google has no control over other people's systems. When I download mail by POP3 from my ISP, they've added SpamAssassin headers, which will simply destroy the DK cryptographic signature. When I get mail at work, they remove ZIP attachments, which destroys the DK signature. When mail passes through an older gateway, some MIME attachments can be decoded and reencoded, destroying the DK signature.
I could go on but you see the point. Once I get the mail in my mailreader, the DK header is useless junk, and it might as well have been forged, for all the good it does. In fact, if my trust in Google is so high that I'm willing to accept the DK header even though it fails, just because Google are the only ones using it so far, I guarantee that the spammers will pick up on that real fast.
DK is a draft, and is far from ready yet. It should be allowed to mature. Google shouldn't be deploying incomplete solutions. Unless... could this the beginning of the PHB era at Google? If so, I'm disappointed.
If you sign up with one of these "trusted sender" schemes, be very careful that there's no way mail bounces, virus-generated mail, or mail via open proxies can become "trusted". Your ID will be on the mail, and you'll be blamed. Spammers are going to be targeting those sites, since they provide a bypass around some spam filters.
Yes, punny. Mod me down.
Hi!
... and hate web-forums like this :-) Is this the reason why all my mailing lists have suddenly gone very quiet? I'm not getting emails from them? I also noticed that the emails I sent to the list do not come back to me. The list adds it's footers to the message and I do not see those on my emails (Well, OK, I checked the headers and my emails, the ones that are withing my inbox and attached to the conversation of the list, have never been at the list server...)
I still love mailing lists
From what I can see DomainKeys appears to be patented by Yahoo!
If Microsoft had done this the sky would be falling - what's the difference here?
omg teh Googel is teh graetestest!!! go ,googel, go!!! wheeeeew!! hehe! lol
Free as in beer.
Free as in speech, well, not all that necessary here.
paintball
Is it just me, or is the length of email headers these days starting to eclipse the length of the body?
1) Write spam email
2) Create account on target domain.
3) Send yourself the contents of your email from the domain.
4) Add a CC or BCC header line and use the signature from the mail you just sent yourself to sign all of the forged spam you send from your spam zombies.
5) PROFIT!
paintball
Geez!
You haven't tried their spam filter, have you? It sucks stones, really.
Maybe, using procmail or mutt?
Thanks,
M.
At which point, I predict a lot more trojaned machines sending spam out through the users ISP.
If the ISP requires authentication, then the person with the infected machine will be easy to find after a spam complaint and shut down for a few days till they clean up their machine.
They'll also start receiving loads of bounces from incorrect email addresses from all the spams going out, and will therefore have a huge incentive to fix their machine...
Leaving aside the question of how the DNS records get updated, is it possible to implement Yahoo's domain signatures (both signing and verification) in a mail client (Evolution, Thunderbird), or does it have to be in the server? It looks to me like that should be possible, but it's not completely clear from the spec.
If it is, then one way of getting these more widely used might be to integrate support for them into mail clients. That way, people with personal domains can sign their outgoing messages, and they can write filter rules (e.g., in Mozilla/Firefox) to deal with unsigned messages, correctly signed messages, and incorrectly signed messages as they like.
On my news submission form, there's a field for people to enter their email address. When I receive the completed form (it's forwarded to my Gmail account) and the sender has used a Gmail address, a yellow warning bar appears cautioning about trusting the email.
PocketGamer.org - For the gamer on the go!
Putting the public keys only into the DNS system seems to make adoption of such a system quite a bit more difficult than it needs to be. Why not also allow people to put the public keys on web pages? The goal is to have senders prove their identity, and the level of proof required by recipients as well as the nature might differ depending on the application. Many people may be quite happy knowing a web site under the control of the sender of a piece of mail.
So, say, you get mail from "someone@mydomain.com". The signature specifies that the public key is on "http://www2.mydomain.com/mail_signature.html" and uses that to verify the signature on the mail message. The recipient gets to decide whether the URL "http://www2.mydomain.com/mail_signature.html" is close enough to "someone@mydomain.com" to accept the public key from there (a reasonable default would be to accept it when the mail host is a suffix of the URL host).
This wouldn't exclude putting public keys in the DNS system, and those keys might be "more trusted" by users, but it would make it much easier for regular users to deploy and use such a system, regardless of whether their ISP is keeping up with the times. In particular, I would imagine users writing mail rules to treat different cases differently (signed with DNS key, signed with matching web site, signed with non-matching web site, incorrect signature, unsigned).
You know, when a discussion about those new anti-spam techniques comes up, I get this voice in my head that says the problem has already been solved by PGP. So I have to wonder, why is it that SPF, CallerId, SenderId and DomainKeys are falling over each other to be the anti-spam standard, whereas PGP is left in the dark?
PGP provides sender authentication (not just server authentication like SPF, CID and SID, or domain authentication like DK), by signing the mail with the sender's private key. The receiver can verify the sender's identity, because the signature can be decryted only with the sender's public key. Additionally, PGP can be used to encrypt the message. The functionality provided by these hot and hyped techniques doesn't even come close to what PGP can do.
So what's wrong with PGP? One argument I can come up with is that it puts a burden on the user, who has to generate keys, and make sure he can always access the keys when sending mail, but nobody else can. However, nothing in PGP demands that the user do all this work. A webmail system could generate a key for the user when he signs up, and the same applies to ISPs. Voila, PGP without any effort from the user.
Another problem could be scalability of the key database. PGP obviously needs more keys that the other systems. However, the amount of keys is in the same order as the number of mail accounts. Surely the mail system could store a few extra bytes per account, and answer the occasional request for public keys?
Can anyone provide more insight here?
Please correct me if I got my facts wrong.
Do not ever do this! It is an extremely bad advice.
From addresses are almost always forged, usually there are just random junk in the From. Quite often there are valid addresses there, and your autoresponders will spam those innocent bystanders. They will be very thankful, you bet!
Finally, it is not uncommon that spammers forge in anti-spammers who have successfully shut them down before in there. When I was still actively pursuing spammers, I had my addresses forged this way. I have had my share of moronic autoresponders. It is not fun at all. If you do this, you only contribute to the spam, and you bet that if you annoy a real anti-spammer enough, you will find your own connection to be a smoking hole faster than you can imagine.
In fact, having autoresponders at all is not recommendable at all at this time. If you first accept an e-mail and then generate a bounce message, if the MAIL FROM was forged, that bounce will go to a random bystander, which is bad. If you use autoresponders, or generate bounce messages, you should be careful not to bounce at forged from addresses.
Allthough it is a bit controversial still, you may configure your system to reject spam and viruses at SMTP time. Then you will not generate a bounce, a relay may, but then, hijacked relays usually don't either (I think it is good reasons for this). So, I am of the opinion that this is good practice.
Autoresponders are Evil however.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Any invites would be appreciated.
I see future clients being configurable for handling unauthenticated email:
1) Reject,
2) Display a visual flag or warning that email may not be trustworthy.
3) Continue as normal
Once this becomes standard, it should be simple to extend it to allowing individual users to publish their public keys in some shared repository, and then email clients can offer you the option of encryption in the case that the receiever of your message has published his public key.
... I don't think the NATIONAL SECURITY goons in the US (FBI, NSA, et. al.) are going to like this. Maybe this is why it has taken so long for this method of spam filtering to be implemented, and why the first to do so is Google -- a company that seems to take the subversive view that we should all act as if constitutionally guaranteed freedoms are really inviolable.
Yes, that could have been done at any time, I know. The point is that once domains start doing this and it becomes standardized, that gets the ball rolling and extending it to universal encryption of email becomes simple.
Hm
yet another supply of invites.
I have 7 gmail invites available. first 7 ppl to email me at kredal at gmail dot com get them.
Whoever stated that signature sizes should be limited to one hundred and twenty characters can just go ahead and kiss my
.. get your arguments straight?
A little while ago, weren't you all up in arms becuase someone proved that SPF ISN'T STOPPING SPAM? You all claimed "It's not supposed to!"
Now, you're claiming that it *will* stop spam.
SPF is broken, fucked, and just plain WRONG. It should not be. It breaks (at least) two *VERY* important features of SMTP, with absolutely * NO * impact on the spam problem.
Spam is a social problem, not a technological one, so your entire argument is pathetic.
or, more seriously, if you attach enough worms or viruses... which is kind of the point.
Paul "Say no to feeping creaturism"
first come - first serve ...
http://www.fundisom.com/free-gmail.php
5 invitations to give.
and if you manage to catch one and feel like saying thanks -there's that fat & ugly ad you might want to have a look at
My sending e-mail that says (for example):
From: myaddress@gmail.com
Sender: account@somewhereelse.com
is totally legitimate as per the RFCs. If DomainKeys doesn't allow it, then it's broken.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Sure, domain spoofing is an issue - but there are legitimate reasons for spoofing email (mail2web is an example - you want people to think the mail is from you @yourdomain.com even if you're using mail2web as your temporary client)...and the key management seems like it would be a headache for large mail systems (with thousands of domains).
Like the idea, but needs some work....some of this is obvious and I'm sure there are fine minds out there tackling the issue.
Yahoo! DomainKeys Patent License Agreement v1.0
(this "Agreement")
Copyright (c) 2004, Yahoo! Inc.
All rights reserved.
You agree to be bound by all the terms and conditions set forth below and, subject to those terms and conditions, You may use the intellectual property described below.
1. LICENSE GRANT.
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.
2. DEFINITIONS.
2.1. "DomainKeys Developer" means Yahoo! Inc. ("Yahoo!") or any licensee or sublicensee (direct or indirect) of the Yahoo! Patent Claims.
2.2. "Implementations" means the specific portions of a hardware or software implementation expressly required to be compliant with the Specifications for the sole purpose of a sender verification solution in connection with e-mail.
2.3. "Specifications" means the specification having submission ID "draft-delany-domainkeys-base-01.txt" dated Aug 2004 published through the IETF (Internet Engineering Task Force). The Specifications may be found at the following link:
http://antispam.yahoo.com/domainkeys/draft- delany- domainkeys-base-01.txt
2.4. "Yahoo! Patent Claims" shall mean those claims of all Yahoo! foreign and domestic patents and patent applications that base their priority on U.S. Provisional Patent Application Ser. Nos. 60/497,794, filed Aug. 26, 2003, or 60/553,300, filed Mar. 15, 2004, or Patent Application Ser. Nos. 10/671,319, filed Sep. 24, 2003, or 10/805,181, filed Mar. 19, 2004.
2.5. "You" or "Your" means an individual, company, or other legal entity exercising rights under this Agreement. Any individual exercising rights under this Agreement on behalf of a company or other legal entity represents and warrants that the individual has the authority to enter into this Agreement on behalf of the company or other legal entity.
3. TERMS.
3.1. You agree not to assert against Yahoo!, or any other DomainKeys Developer, a patent infringement claim against any Implementation ("Implementation IP Claim").
3.2. To indicate your assent to the terms and conditions of this Agreement and in order to obtain a license to make, use, sell, offer for sale, and/or import Implementations, You must include or preserve the following prominently displayed statement in the source code and object code of any such Implementations : "This code incorporates intellectual property owned by Yahoo! and licensed pursuant to the Yahoo! DomainKeys Patent License Agreement.".
3.3. You will not use the name of Yahoo! to endorse or promote any products or Implementations without specific prior written permission of Yahoo!. "DomainKeys" is a trademark of Yahoo!. However, You may state Your Implementation is "DomainKeys compliant", "supports DomainKeys", or is "DomainKeys-enabled", without citation to Yahoo!, but You should create Your own product names or trademarks for Your specific Implementations and the term "DomainKeys" shall not be used by You in or as part of a name for Your specific Implementations.
3.4. You may choose to distribute Implementations under this Agreement or a separate agreement, including without limitation a sublicense agreement, provided that:
(a) such agreement complies with the terms and conditions of this Agreement;
(b) a copy of this Agreement or the separate agreement is included with each copy of the Implementations along with the following prominently displayed statement: "By making, using, selling, offering for sale, and/or importing this product, you agree to the terms and conditions of the Yahoo! DomainKeys Patent License Agreement or other separate agreement contained herein."; and
(c) if distributed under a separate agreement, such separate agreement must contain terms no less protective of DomainKeys Develope
I don't understand this at all. If I send an email claiming to be from innocent_joe@yahoo and I send it through a different Yahoo! account it is still okay? That doesn't really help. It just means the Bad Guys will change accounts more often.
One question, when will it be availble for postfix??
Eh..one more question, how hard will it be to DOS a mailserver..sending a zillion fake emails so the emailserver has to check (was it RSA ? ietf seems unreachable for me...) each and every one, if it is RSA that would put some load on the server...heh..
"In your mail reader, configure your various email accounts to send mail to the appropriate mailserver for each account, connecting to the port that was allocated specifically for new mail submissions, port 587, the mail submission port."
Exactly.
This solution depends upon people sending email through the same company which they want to receive email. If you use any kind of webmail, then you're golden; if you're a vanilla internet user who only checks email from one location using the email address provided by your ISP, you're golden; if you're a corporate user working very similarly to the vanilla user, you're golden. But these groups are growing smaller, not larger.
Yahoo's implementation does not handle personal domains, as I send mail through my ISP's mail server but with a "From:" for my personal domain. AOL has (had?) something called "Bring Your Own Access" where you used your AOL software across another ISP. Many people have had email addresses for years, but are now moving to high speed connections with other providers. The instances where your email address does not match your ISP are numerous. Some people have suggested using the "From:" header of your SMTP service but setting your "Reply-To:" to your regular address. While this works in some cases, it causes issues with address books (most mail user agents pull "From:" not "Reply-To:"), filters (spam or otherwise), and readability.
What about SMTP-authentication? Why not use the SMTP service for whomever your email address is through? Many ISP's, in retaliation to spammers who used open relays, blocked outbound connections on port 25. Oops, that won't work.
What about users who travel? I have a laptop; at home I use one provider, at work I use a second, when I travel I use a third. I would have to configure three "From:" headers dependent upon which ISP I was using.
This is a start but its benefit is limited to your "vanilla" users. And how will it damage users who use different SMTP service than their email address? Even AOL users may be negatively impacted, and they're as vanilla as you can get. People can't get all jumpy as if this were a solid solution--it works for Yahoo and it works for Google, but those are the target audience.
Someone asked if I had patched against MSBlast; I said yes, I installed Linux.
I just sent a test email from Gmail with a different address as the Reply-to:. Using the Reply button in MS Outlook 2000 (connected to an MS Exchange server), the reply was correctly addressed to the address on the Reply-To: line, not the From: line. I went through the Options and found nothing that would alter this behavior.
But maybe you're talking about out Outlook Express, something with which I have had no real experience. I find it annoying when people call "Outlook Express" "Outlook." The two programs are very different.
One poster said, "SMTP AUTH over SSL. Works like a charm. You need an ISP or service competent enough to configure it though."
Easy for YOU to say.
There are a lot of people (like myself) who have ONLY ONE CHOICE for a broadband provider (which blocks outgoing port-25), yet who need to use -- SIMULTANEOUSLY -- THAT SINGLE PROVIDER's SMTP, while using a different "From:" domain.
This happens for various LEGITIMATE reasons -- for example, if you have long-standing historical relationships which are dependent upon a large and impersonal *mail* provider -- NOT your ISP -- who won't provide a mechanism for circumventing the ISP's block on port-25.
What are we supposed to do?
Qoute from IETF draft and refers to 'paid' authentication.
;-)
So, all a spammer will have to do in the future is pay for a certificate. Maybe a portion of revenue?
I know this was evil.
How about something simple.
MTA MTA does HELO now.
Problem with HELO is domain spoofing.
Solution?
Originating MTA sends an encrypted serial number that is unique to that message. Receiving MTA does usual HELO thing but includes a copy of that still encrypted serial number. Originating MTA does not answer HELO if the serial number doesn't match.
Any spam that follows user > MTA > user route
is responsibility of the domains mail service.
Were this scheme turned on all at once I'd predict an initial flurry of sound alike and look alike domain name registrations but once these were identified and blocked by existing filters, there would be a LOT less SPAM. From the get go, there will be NO domain spoofing which will make the zombies easy to find.
Complicated?
Some rewrite rules for sendmail or whatever you use and a bit of AWK SED PERL NYP(name your poison)
The hard part is an agreement on standard
Hopefully the guys at google doing DK are not the same guys managing 'answers'. My advice, sell your google stock and buy it back after their head swellng sunsides.
It's especially useful against spammers sending their own email, though they could set timeouts to prevent it, and for spammers who abuse open relays/proxies, it's even better because the spammer is running the relay's vanilla mail transfer agent which isn't designed to teergrube-rejecting timeouts (almost by definition....) It's tougher against zombies, because spammers often spread their workload among a bunch of zombies, and zombies usually have cable modems or DSL these days, but if everybody with broadband who isn't running their own SMTP server were running a teergrube, with lots of fake email addresses seeded around the net that resolve to a teergrube somewhere, the spammers would have a much tougher time. But a zombie on an ADSL or cable modem with a 128kbps upstream can easily be kept busy with a few kilobits of ACKS from you, while not making much of a dent in your downstream bandwidth - you probably need only about 10% as many teergrubes as zombies to keep the zombies busy.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks