Re: [exim] Understanding DKIM examples

On 04/04/2013 04:00 PM, Ian Eiloart wrote:
>> I'm wondering if any of you have any numbers on DKIM usefulness for
>> anything? I've been running some tests on a couple of low volume
>> servers, and I really have no correlation of dkim failures to
>> anything except bad configuration or transient errors.
>
> I think the trick is to combine it with SPF. A mailing list isn't
> really forwarding: it's sending a new message, even though the
> content is largely the same. If the list domain publishes SPF
> records, then the message should still pass an SPF test. Oh, and it
> should ideally add a DKIM signature, too.

Yes. If SPF is used, I can realistically also check the sender's
envelope and check if a signature was added, in the same spirit as I was
asking. I can only realistically check the signature that was added in
the last hop, and this is exactly what I was hoping to achieve (though,
in practical terms, if I'm only validating the last signature, SPF does
already the job).

> Of course, passing the tests doesn't mean that you've got a reputable
> sender. It just means that you know who the sender is. But that means
> that you can apply domain based reputation tests, instead of IP based
> reputation tests. And that makes whitelisting (a) safe, and (b)
> feasible.

I agree. But I've been running mail servers for years now, and I cannot
really get the benefit of DKIM, unfortunately. I was against SPF in the
beginning, mostly because it breaks forwarding, but we are to a point
now where nobody forwards anymore and we all use esmtp-auth so my point
was less and less strong over the years. Validating the envelope does
have a lot of benefits, and SPF is a reasonable implementation in my
eyes. Simple, elegant and straightforward.

But DKIM cannot be validated as simply as SPF. DKIM signatures have no
simple way of being interpreted, which introduces the need of policies.
It seems that mailing lists software doesn't "get it" either, because it
doesn't take a lot to strip a header if you know that you're tampering
the message. It's also just about as useful as esmtp-tls, or in
practical terms, next to useless since there's no way to enforce that
the whole chain of servers involved behaves correctly. Contrast this
with SPF, where correct behavior can always be attained at the receiving
end, if so desired.

I guess my main argument is that if I wanted to make sure my message
wasn't tampered I would use pgp/s-mime, definitely not DKIM. If I wanted
to ensure secure communication between two servers I own, I wouldn't use
DKIM policies, but enforce TLS and check the certificates.

As an user, I could /potentially/ check the DKIM validation myself when
in doubt, but at this point it seems that the client is in a better
position to do the validation then the receiving server. At least
thunderbird has an option to do that via addons. So I'm thorn about
performing DKIM validation server side entirely.