Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Todd Herr <[e-mail]>]

On Mon, Jun 19, 2023 at 8:25 PM John R Levine <[e-mail]> wrote:

> On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
> > I suggest that we do not only drop SPF, but also come up with better ways
> > (simplification, tools, exchange formats) to implement DKIM in order to
> allow
> > for a smooth transition.
>
> I'm scratching my head here.  On my system I publish and rotate DKIM keys
> completely automatically.  The only manual config is to edit the list of
> domains when I add or remove one from my mail server.  It's not totally
> trivial but it's not that hard.
>
> I suppose we could encourage people to implement ed25519 signatures since
> the keys are small and more likely to fit in a single TXT record string
> for provisioning crudware that doesn't handle multiple strings, but beyond
> that, what do you have in mind?
>
>
I can't speak for Patrick, but I don't think he's necessarily thinking of
different encryption algorithms here.

Not all who wish to have their email DKIM signed have the luxury that you
have John of full control of the DKIM signing process. I'm specifically
thinking of the entity (call them Marty Marketer) who has the authority to
employ a third party to send authenticated mail on behalf of a domain, mail
that the third party can and will DKIM sign using the entity's domain.
Sadly, Marty does not have the authority to update DNS for that domain in
order to publish a DKIM public key. This leads to challenges as the third
party presents to Marty a public key to publish, and Marty tries to figure
out to whom to pass along this information and in what format. This leads
to screen caps, or cutting and pasting errors, misdirected mail chains,
etc., etc.

Is this the way it should be? Probably not, but it's a reality for many,
and it's a problem we don't as an industry have an answer for yet. If we
did, there wouldn't be people in the other thread reporting such a high
percentage of DKIM failures due to malformed/missing keys.

Now, of course we could argue that Marty shouldn't be left to their own
devices to engage third party senders, and that should solely be the
province of the IT staff that manages DNS, but I fear that the energy
required to type and distribute such words would be wasted.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* [e-mail]
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.