Bringing this back onlist... > Hope you are well, wallowing in the miasma of your success with DKIM :) (ps:
Other projects have come up and so DK/DKIM signing remains unfinished, unfortunately. It's still in the plans, but other more important things are being worked on and overcome for right now. I've got it verifying, so that's half of the battle. > I intend to implement domainkeys and DKIM (and publish SPF) as some rumour > has it that Yahoo will not throttle e-mails from any domain that does these > (DKIM+SPF). Heard it? I don't know about "will not throttle", but they are more lenient of the volume of email you send to them (provided that volume contains statistically a very low amount of spam). > So I have a question on your mode of implementation, which seems rather > simple though, thanks for your efforts and for sharing. > > 1. All these configs go at the top of mentioned ACLs sections? Just to be clear, the part that goes in the ACL will verify the signature of incoming emails. You can only verify a signature once you have received the whole message, so a logical place would be the ACL for acl_smtp_data. I put it near the top of the ACL, after I do a few sanity checks: oversize subject header, demime defect detection, and missing Date header. > 2. Why do you find it necessary to log libdomainkeys/lbdkim versions always? Another older mail system runs sendmail with dk-milter and dkim-milter. It always logs the version of the milter that's running, which can be useful when trouble-shooting why a signature failed. "Oh, I upgraded to version X.XX and it stopped working" or "Signatures failed before $DATE because I updated to a new version which fixed a bug", and other things like that. It's good, to me, to have that information available, but if you prefer to keep your software choices more secret, it's entirely up to you. Just remember that security through obscurity does not solve problems, it only gives you a false sense of security. > 3. Do you also publish SPF? If so, how did you do it? We are a webhoster, so we create a generic SPF for each domain that a customer hosts with us. We allow changes to that TXT record to lock down or expand SPF settings. But if you're doing just a few domains for your company, a few static settings are all that are required, a one time configuration and an occasional tweak are all that are necessary. > 4. In all, has this helped with Yahoo in any way (they don't throttle your > servers)? This did help, but it depends on the amount of email that comes from your server that: a) Their scanners detect as spam. b) Their users submit as spam. c) Is addressed to non-existent users. You are still subject to throttling, tempfailing, or outright rejection if any combination of those starts getting exceeded. -- Regards... Todd -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
