John Levine wrote in
<[email protected]>:
|It appears that Alessandro Vesely <[email protected]> said:
|>> Is that a thing? A message with multiple "From"?
|>>
|>> https://www.rfc-editor.org/rfc/rfc6854.html
|
|We beat this to death a few years ago. While it is possible to put \
|two addresses
|in the From header, it is very uncommon, it is even less common to have two
The result is RFC5322.From from DMARC, and overy simplification
for no purpose, and it poisened the entire of SMTP.
The other approach will do the same with other aspects of it.
|addreses in different domains, and the few examples I've seen are either
|mistakes or malicious. They are rare enough we can ignore them, messages \
|with
|multiple From header domains can't be DKIM2 signed.
But now the infrastructure is poisened, not on the (good) MTA
side, ie postfix will work just fine, but on the accompanying
software side, as shown on the mailsec@ list (a milter enforces
5322.From to match 5321.MAIL FROM, and the software needs an
iteration).
So then yes.
Otherwise .. what is wrong with that decade old "if there are
multiple addresses in From:, you need to set Sender:", not to talk
about RFC 6854 that updated 5322?
Throw it in the trashbin because the infrastructure is poisened.
And you go on further on this road.
|>Wei convinced me that there must be at most one rt=, because, he said, \
|>the
|>official recipients, To: and Cc:, do not need to be repeated in rt=. \
|> They are
|>already signed and delivery to them is due. rt= is only needed for \
|>Bcc: and
|>forwards (which can be thought of as Bcc:). This way, there must \
|>be at most
|>one rt=, but there may be none.
|
|By far the most common scenario where the recipient isn't in the header \
|is mailing lists.
|
|There will always be exactly one rt= because we don't allow more than \
|one, and a mail
|delivery without an envelope recipient isn't a mail delivery.
I'll append a message i did not send.
And what happens if some man-in-the-middle or intermediate
recipient resends the message somewhere else, but does not create
a signature according to the iterated DKIM?
- if the final recipient does not support the iterated DKIM, you
know.. it is plain DKIMv1 (at best) anyhow.
- if it does, it will know it is not the original recipient,
otherwise there would be a dedicated subsignature.
The ACDC check thus failed.
o Now it falls back to DKIMv1, and if just any signature
verifies, then the message passes DKIM, as it always did.
+ What happens now? I do not know. A user interface could
adapt via traffic light semantics, for example.
Automatization i do not see, except what is in use already
(ARC, SPF, whatever), unless the iterated DKIM has found
widespread adoption.
You cannot automatize this.
This is why all the examples are absurd. There is also SPF, etc,
there are mitigations (signature removals, From rewrites) etc, so
unless *all* the infrastructure *always* uses the iterated DKIM,
and even then.
Does the other approach (not counting DKOR) do anything regarding
RFC5322.From "misalignment" in Sender->Mailing-List->Subscriber,
if Mailing-List performs adjustments, ... how could it? There
were modifications.
So i say, again, it should be talked more about mitigations, if
you listen or not, in general, for alias expansion (SPF
alignment in at least EHLO: VERP mitigation), and From: (DMARC
alignment, eg if the mailing-list did not do it itself).
But now: *if* the iterated DKIM *itself* applies mitigations, for
at least the near forseeable future.
Then: the signature verification *will* succeed for the next
recipient *unless* there are intermdiate hops, and they modified
the message/envelope maliciously.
This is, as one of the readers of this list correctly stated (in
between the lines, ~"the signature is not supposed to fail"), the
core of the ACDC concept! That is it.
And because there is no failing signature, you do not need DMARC,
not really SPF (or: you can truly "-all" not "~all" since it is
mitigated to succeed), let alone that, i censor myself, ARC.
Throw it away, it poisened the infrastructure. And the DKIM2
concept is much too complicated and requires anything anew, tagx=,
tagy=, what is that. DMARC alignment, rubbish! How do you want
to automatize "this adjustment is ok, that is not"?
Now. The iterated DKIM protects message and envelope integrity in
between the sender and the sender-desired recipient(s). For ACDC,
if the recipient domain announces support, we can utilize parallel
delivery for *any* recipient, including those in Bcc. With
a possible SMTP VERP extension, any recipient can nonetheless have
its very own return path for bounces. If not, the Bccs require
single-delivery. Regarding bounces: just like today, MTA and
support could be configured to always do it, (otherwise).
It does not matter: if a multi-delivery message is then replayed
further, we end up at the top of this message: do all support
ACDC, replay is detected, and if they do not, normal DKIMv1
kicks in, nothing changes.
And then we have a valid, cryptographically safe message in our
inbox, but which is totally different from the one that was sent.
Because say the mailing-list replaced it!
But it has a superb reputation, and its signature is valid!
Now this you cannot automatize even with your DKIM2 stuff plus
DMARC2 plus what not.
But ACDC and DKIM2 come with difference tracking. (One with the
better.)
You thus can unroll changes along the path, and, Richard Clayton's
correct claim back and forth, this can be used to agree to some
kind of change pattern: and especially in conjunction with
a specific "message path" this *can* be automatized.
So i *can* say, that if *i* have been addressed by [email protected],
and there were no changes in between (ACDC signature would break
otherwise), then that [email protected] specific pattern of changes can
be agreed to.
This cannot be automatized via that DMARC or what. It can only be
part of the user interface, which needs to adapt, and the ACDC
draft shows, in bad language etc but still, one approach i thought
of and said to Dave Crocker on the internet-history list quite
some years ago, unless i am mistaken, with some kind of tree view
(stations along the path) and traffic light semantics.
So, to make this long story short. For ACDC, there is no
alignment to nothing. The signature verifies, but otherwise the
message was maliciously broken, and *WHY* should such a message be
delivered at all. You may quarantine it, you may sent it to some
spam, but i would simply reject it: the latter is what the ACDC
solely covers; a new version could express this context in an
introductionary note once.
This is all "iterated DKIM only". Otherwise it falls back to
DKIMv1, and then you have all that DMARC/ARC/SPF/Authentication-
Results stuff to deal with, anyway. Any i really think there
should be expert talk on applying active mitigations *also within
your DKIM2* on envelope alias expansions (SPF) and From:.
Having said all that, best would be if the iterated DKIM directly
restarts support for also multiple-from/sender as you verify the
latest signature (or, with ACDC, if there are multiple with the
highest sequence, but with different algorithms, the one with the
algorithm of your desire; or, if you collect reputation, all of
them), so that in the future a sane SMTP environment can be
approached again. It cannot be used at the moment, though.
--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]
