Hi!
Not to contribute anything to the ARC question, as I'm
not knowledgeable about that.
It just looked like there might be a bit of misunderstanding
about the current DKIM2 drafts, and if so I'd like to help
clear that up.
On 2/10/26 03:42, Douglas Foster wrote:
[...]
DKIM2 does not solve this use case. Like DKIM, the signature is not
tied to the server that created it. Certain inferences can be made
based on header position, particularly if the possibility of header
reordering is ignored. But when a DKIM signature appears below the From
header, does it indicate that the signature was prepended by the
originating server, or appended by a downstream server? It is
impossible to know for sure.
I'm not sure if what you describe matches what I understand from the
recent DKIM2 drafts.
- The drafts provide for an explicit index number for each DKIM2-
Signature header field (i=). The message is only well-formed in
a DKIM2 sense if there is some number n so there's exactly one
DKIM2-Signature header field for each value of i between 1 and n.
- Each DKIM2-Signature header in turn binds to a message version
(described in Message-Instance, with explicit index v and a similar
property of one clearly defined sequence). Which in turn describes
header/body changes/versions (ideally with a kind of "diff").
- Each DKIM2-Signature commits to the previous DKIM2-Signature header
fields, the previous + current Message-Instance header fields,
the signer domain.
- Each DKIM2-Signature binds to the current mail envelope (mail-from/
rcpt-to), with a domain alignment requirement between signer domain
and rcpt-to within the same i=, and between mail-from of hop i and
rcpt-to of hop i-1.
With all this, it doesn't matter if a DKIM2-Signature is below or
above some From header. Position of DKIM2-Signature or Message-Instance
headers doesn't matter at all thanks to the indexing.
And the value of From corresponding to some hop (if it has been
manipulated) can also be determined unless a hop doesn't provide
the diff but declares an undisclosed change. Only then one is
relegated to some external notion of trust that the change is
benevolent. Otherwise one can look at previous/new values and
make a more specific decision whether this change is okay (or
even present the change history to the user at the MUA).
As far as I understand, the undisclosed "trust me" kind of change
is intended mainly for mail security appliances close to the receiver so
the receiver can decide if that appliance is actually the one they
contracted and trust (via signature validation).
[...]
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig,
Dr. Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte
den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
