[DNSOP] Re: [art] Re: DNS-designated Public Key Author ities (DKA)

"John R Levine" <[email protected]> 26 Jun 2026 11:38:42 -0400
Newsgroups gmane.ietf.dnsop,gmane.ietf.apps-discuss
Message-ID <[email protected]>
On Fri, 26 Jun 2026, Ben Schwartz wrote:
>> At a lot of organizations the people who run the mail and the people who run the
>> website do not talk to each other. So if you want to publish key info for
>> [email protected] ... you would often be told to
>> forget it.
>
> Dynamic integration between the email account database and the web
> serving could be difficult, sure, but that's not what we're talking
> about here.  All we need is a static JSON file at
> ./well-known/dka.json that says {"dka-url":
> "https://dka-provider.example/"}.  Even a pretty disorganized
> operation should be able to manage that.

You can say exactly the same thing about /.well-known/mta-sts.txt and they 
ended up with the mta-sts label.  I gather the issues are partly content 
management systems that don't make it easy to add a file at an arbitrary 
place, partly turf wars.

>> While an SMTP extension is a technical possibility, in practice, again 
>> forget it. ...

> We are starting from the assumption that the SMTP server operator
> _wants_ to announce a key distribution server.  So why wouldn't they
> want to announce that server over SMTP?

There's two separate issues here.  One is that adding extenstions to mail 
servers is also complicated.  On the server I use, it's a one-line config 
change and a plugin, but more typically it requires a software upgrade 
from the vendor who may not have your particular extension high on their 
roadmap.

The other is that anything that makes it easy to verify email addresses is 
asking for trouble.  There's a whole disreputable industry known as 
listwashing that does it, with endless cat and mouse games as mail 
operators try to block or defeat them.  So no matter how you find the 
server, you need to think hard about the ways people will misuse it and 
how you deal with that.  I'd be inclined to return a fake but technically 
valid key to requests for invalid names, or to requests at suspiciously 
high frequency but I'm sure there's other approaches.

R's,
John

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]