On 2020-07-10 at 17:59 -0700, Brandon Long via mailop wrote:
> Anyways, ecc has been added to DKIM, but I'm not sure how widely deployed
> verifying it is.
> https://tools.ietf.org/html/rfc8463
Exim has implemented a=ed25519-sha256 for some time, and verifies it.
By mail volume that's not a lot, but by independent installs it counts a
bit more. Support was added in Exim 4.91, released in April 2018 and
does require a modern GnuTLS or OpenSSL. That last requirement cuts
back the percentage of sites which might be able to verify. :-D
My domain dual-signs. There were a couple of glitches at first with
this hurting deliverability, but if (fallible) memory serves the only
offender I really noticed was Gmail and that one was quickly fixed after
I raised the issue. For the most part, receivers now just ignore the
second signature when they don't understand it.
The first three lines of an AR header added by Google, for instance:
Authentication-Results: mx.google.com;
dkim=pass header.i=@spodhuis.org header.s=d202005 header.b=GJ0knaFX;
dkim=neutral (no key) header.i=@spodhuis.org;
In that, the "no key" is for selector `d202005e2`.
At present, support is not widespread enough that you can realistically
just use Ed25519 keys and expect it to work.
On 2020-07-11 at 15:02 -0400, John Levine via mailop wrote:
> For one thing, while it was kind of cute that we could still check the
> DKIM signatures on old DNC mail (I did)
[...]
> The other is that nobody I know found the DKIM validation to be more
> than a curiosity. People believed the messages were real because they
> knew who used the account and they were otherwise plausible.
I had a couple of people come to me and ask; one of them said something
along the lines of "They're saying these are faked, but they're
DKIM-signed, which is supposed to prevent that isn't it? Can you check
to see if they really are fake?"
They were _inclined_ to believe the mails were legitimate but were
_insulted_ by the lies claiming that they were faked. I believe that
they ended up voting third party (in their state it didn't make much
difference). There's a difference between "what people will believe
about the origins" and "how people assess your behavior when you're
caught out and then start lying".
I can understand why folks might want their mails to be validated as
legitimately theirs for authenticity near delivery time while still not
wanting them to suddenly be elevated from "ephemeral" to "provable"
communications. Even if in my judgemental moments I do raise an
eyebrow.
I've had cause to integrate DKIM signing from various providers into
$employer domains and the best ones have said "set up three CNAMEs
from your domain to these names under our control; that way, we can
rotate keys freely and you never need to care about our rotation
schedules". They either pre-set the names, or let you choose freely and
just tell them your selector names.
The worst (of those that implement DKIM at all, so it's "worst of a good
bunch") are those which have you set up one selector, with a fixed
unchangeable name, whether CNAME or direct TXT. Those are the ones who
will never be able to sanely rotate and will be facing an expensive
up-hill battle trying to get _all_ their customers to add extra names so
that they can one day stop signing with the older key. Or, they will
just change the key behind the selector and risk breakage during the
cache invalidation and mail queue overlap periods.
Enough of the providers use fixed predictable names that my dns-email
script for doing domain integrity checks can derive a bunch from the SPF
records. Which is helpful for me and potentially useful for those with
databases of domains who want to use DNS queries to do third-party
auditing of market penetration to verify SEC statements about market
penetration, so I guess a win for legitimate ESPs too. :)
-Phil
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
