Murray S. Kucherawy wrote in
<cal0qlwa885tsxoydayo88rljgzmviennt9ed6zxf8yfd-et...@mail.gmail.com>:
|On Sat, Aug 17, 2024 at 12:36 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.
...
|As you point out this is very similar to ADSP, which never got much
|traction and still suffers from the same problems DMARC does regarding
These were other times.
Since then myriads of possibilities have been added to generate
"more identification value" of an email's source, even "over the
corner", and what not.
Maybe the significance of ADSP was therefore simply not
understood.
Yes.
Like i said, the sentence
o signature verification failure does not force rejection of the
message;
was possibly misunderstood by the entire IETF.
Read over it.
Throw it away.
It was an easter-egg.
Because -- *why* should it be like that?
Signature verification is comparable to what happens during a TLS
handshake. It is a cryptographic operation using currently
non-broken algorithms.
It simply does not get any better than that.
|indirect mail flows. I think you'd need to address those as well. Do you
|have something in mind?
I must admit i currently do not know what you are talking about.
I do not follow DMARC and ARC development except when something
comes in via announcements, i often glance over drafts and such.
To me there are exactly two possibilities for email messages,
regardless of how many stations the message has passed:
1. the (core of the) message is unchanged
2. the message has been altered
And whoever creates a DKIM signature
1. has access to the private key
2. has to have write access to the DNS zone of the domain the DKIM
signature applies to (to place the public key)
If a message has been altered, all bets are off.
This is a tremendous failure of the IETF and those giants which do
it the way they do it.
Funnily one of those many drafts mentions this,
draft-chuang-dkim-replay-problem said in 2023 (!)
Mailing List: [.] nearly always break any existing DKIM signatures.
I mean there is RFC 6377.
But then again there is only thing plain, the original message no
longer exists. It is as simple as that.
In my humble opinion the solution is
- announce this change in the DKIM signature via a new, backward-
compatible flag
- create your own DKIM signature for the altered (new) message
(thus)
Finished. User interfaces should have been designed to signal
this to users. It cannot be automatized. You cannot warp
reputation around the corner, what chuang writes in the mentioned
draft
ARC [RFC8617] is a protocol to securely propagate authentication
results seen by Mediators
is pure rubbish in my opinion, sorry. Yes the propagation is
secure with lots of effort, but the result cannot be trusted,
especially not by minor sites somewhere in the corner of the
internet. And if, you could very well include it in your DKIM
signature. No need for myriads of processing, DNS lookups,
signatures and all that. No.
No. If you have to alter the message, flag that this has
happened, and user interfaces need to be changed over time so that
users are given possibilities to white/allow-list some specific
party which does that, like a mailing-list.
Google and/or KI may even (offer) auto-pilot(s for) *that*, simply
by tracking their users: ie, if a thousand people say "yes" to
some IETF mailing-list, there is a high probability this is ok.
(But it is not more than that, never. Without a real person.)
Ie, you have to rewrite From: and all that, this ship has sailed,
and someone on this list posted years ago, that he "does not know
how to do that", and i do not, either.
And i am now fine with that, after fighting it for long.
It is just the actual environment as it is that makes this bad.
And regarding DKIM signatures of "all the MTA hops along the way",
if that is still true, they are fine.
One *could* build up some data stock with the involved host names,
so that in case of DKIM signature breakage different steps can be
taken, ie, "Organizational Trust" as of RFC 5863 could be fed with
this. This is of course true for ARC, too, but i want to remark
that here it is only about "service quality", not about "believing
authentication over the corner".
Greetings, and a nice Sunday i wish.
--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]
