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
