Murray S. Kucherawy wrote in
<cal0qlwyqkmuovuj3jmd4oy_93hklc3jlivj-knwjveehewk...@mail.gmail.com>:
|On Fri, Aug 16, 2024 at 3:14 PM Steffen Nurpmeso <[email protected]> \
|wrote:
|> Instead there should be a (yet another) DNS entry that notifies
|> whether a host DKIM-signs its emails, or not.
|> Then receivers can peek that state.
|> This idea in several forms was posted here in the past, without
|> responses.
|
|Why do we need yet another one of those?
Domains need to be able to signal From: parsers presence of DKIM
signatures.
My desire would be to change the interpretation of DKIM away from
o signature verification failure does not force rejection of the
message;
This is needlessly far off from the now practically omnipresent
TLS that does not even establish a successful connection upon
"cryptographic handshake failure".
If domains signal they perform DKIM signing, and if DKIM
signatures signal they represent this "DKIM iteration" (via an
additional flag, which is backward-compatible), then there is an
interlock that can be used to tighten interpretation rules of what
to do with messages.
And if those tightening causes message rejection, the usual decade
old SMTP bounce mechanism will come into play.
So one *could* overload the meaning of a yet existing DNS record,
but *i* would long for loosing ARC and DMARC (and SPF) on the long
run, as i see no purpose for them if DKIM is empowered as it
should, in my opinion.
I think this new record, similar in spirit with, but different in
content, to RFC 5617, could signal for example key preferences.
This can aid minimizing cache storage on receiver systems, as well
as key rollover (if it would also include a preferred selector,
for example), it can aid in reducing processing cost along the
way, especially if this DNS entry is TTL cached, as only the
creator-preferred signature needs to be verified, and also message
modifications which remove for example the preferred things along
the way can cause normal SMTP message bounces, maybe via RFC 3463
4.7.7 Persistent Transient Failure/Message integrity failure.
One could of course join several new things into one.
Since this new / old thing is anyway smaller than a RSA public
key, quite a bit of draft-brotman-dkim-aggregate-reporting could
be folded, in my opinion all these masses of reporting
possibilities are mostly for the big ones anyway, totally
over-engineered, and minimizing all those DNS noise would benefit
a lot of people and traffic.
A nice Sunday i wish from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
