Is anyone else looking into (or has implemented) "domain keys" on their MTA (sendmail, etc)?
For those who don't know yet, domain keys is another "grand solution to spam", like SPF and DKIM. It's being pushed by Yahoo, and almost any mail sent to yahoo.com without DK will be tagged as Bulk.
http://antispam.yahoo.com/domainkeys
I just spent 4 hours making it all work (and figuring it all out) in FC5 on my firewall/router/mail-server/workstation/kitchen-sink. My impression is it's still pretty experimental, and there are no prebuilt yum packages available for it. The source for dk-filter (a sendmail milter) is pretty buggy and obtuse.
But it seems to work finally. I have it setup mainly for outgoing mail, so my mail will get through to yahoo/etc ok. I have the incoming check options set to "allow no matter what", yet it provides some pretty cool fine-level control. One option in particular that looks very useful is:
# signaturemissing, miss * The DNS TXT record for the sending host indicates that every message should contain a DK signature, but none was found in the message.
I'm thinking I could reject all "miss" emails fairly safely. If a domain is setup properly and says "we always sign our emails", and if dk is working, then an unsigned/badly-signed email purporting to be from them must be a spoofed spam. I wonder how many domains are marking themselves as "we sign every email". I wonder how you even indicate that option in the TXT record; I haven't found a doc for that cryptic code yet. Likewise, if I'm confident dk is working well then turning that option on may help the world by allowing dk-aware MTA's to drop spam purporting to be from me!
I have some other observations/questions:
If I email to myself @yahoo.com, yahoo puts a little blue message under the From: header saying domain keys were confirmed. Neat!
For the emails to domains that I have to forward through Shaw (or they get blocked by the RBL's because of my dyanamic IP), will Shaw introduce headers that will cause the sig check to fail? Certainly they must plop in a Received: header? If so, how are domain keys to ever function properly when an intermediate mail server is involved? (Also would apply to people sending to me where it goes to easydns, my backup MX server, first.)
In that scenario, having domain keys would be worse than not because then the normal-config dk-filter would reject the "corrupt" email. If there were no dk's at all, then the email would go through (albeit marked as bulk). I don't want a scenario where I may get *more* "lost" or "dropped" emails, especially without bounce debugs!
Am I reading the functioning of domain keys correctly with the above point? Or perhaps the intermediate host is supposed to verify the dk then regen a new one for the next hop? But if the intermediate MTA isn't dk-aware, it may just leave the original header intact causing the final dk check to fail?