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.
_______________________________________________
mailmate mailing list
[email protected]
https://lists.freron.com/listinfo/mailmate
