[MlMt] DKIM validation at client level

[Bill Cole]

On 11 Oct 2017, at 12:56, Alexandre Takacs wrote:

> Thanks for your insight.
>
>>>> The value of DKIM validation at any point is dubious, given that 
>>>> anyone can DKIM-sign their messages for the cost of a domain and 
>>>> some DNS and MTA config clues.
>>>
>>> Sorry I am not sure to understand / agree on this one. I personally 
>>> find value in being able to verify that the mail I am getting from 
>>> domain "x" is not spoofed.
>>
>> That's really only true if you know the value of mail which is 
>> actually from domain "x".
>
> Not sure to understand that one ? Care to elaborate ?

The fact of a valid signature only proves that a mail server along the 
transport path was able to construct a valid signature for the message. 
If the "d" attribute in the signature matches the domain part of the 
 From header address and the SMTP envelope sender address AND you can 
validate that the domain has implemented DNSSEC, then you can say with 
some certainty that the message really came from that domain.

However, if you don't really know whether the signing domain is run by 
angels, demons, or merely mostly well-meaning humans, you get no value 
from knowing that they signed the message.


> One use case I actually have: I get a message from my law firm -

OK, demons it is, but demons that are on your side. Now you get value 
from the signature.

> obviously it might (and is) usually cryptographically (s/mime) signed 
> but it would be interesting to be able to check that the server which 
> sent it did in fact DKIM sign it.

So what would you believe if one of the signatures is valid and one is 
not?

I'd be slightly more willing to believe the S/MIME signature because it 
is a more mature technology that is under the control (hopefully) of the 
actual human sender, not a signing tool on a server that handles signing 
for at least a whole domain and maybe multiple unrelated domains.

>> In security terms, DKIM is pure authentication without any intrinsic 
>> authorization value. If you don't add your own careful authorization 
>> layer, you're at risk of being fooled by domains like 'paypa1.com.' 
>> There is also the more arcane (but real) problem of DKIM replay 
>> attacks, (explained in depth by Steve Atkins: 
>> https://wordtothewise.com/2014/05/dkim-replay-attacks/) which makes 
>> the authentication less meaningful than one would hope.
>
> That's an interesting point - thanks for the pointer.
>
>>> And it would be nice, if not ideal, to be able to do so client side 
>>> (i.e., in MailMate). Do you have any specifics to substantiate "DKIM 
>>> validation after final delivery and IMAP retrieval is potentially 
>>> problematic" ? I'd be interested to learn about it.
>>
>> DKIM relies on DNS records which are ephemeral by their nature. One 
>> mitigation of DKIM replay attacks is the use of short-lived domain 
>> keys, so the signature might have been valid when transported via 
>> SMTP but not 5 minutes later when you try to validate it. There are 
>> also some local delivery mechanisms that make modifications to 
>> message headers or bodies that will invalidate the signature.
>
> Some food for thought here indeed - but all that assumes that one is 
> actually able to check the sig in the first place...

Well, you CAN, if you really feel you must...

There is a port of opendkim in MacPorts. There's probably a formula for 
Homebrew as well, if that's your preferred package manager. It would 
probably be relatively simple to create a MM Bundle to use opendkim to 
validate messages, but even without a Bundle you could install opendkim 
and use it manually in a Terminal session.