Whatever works within our constraints. It is certainly an interoperability consideration, and evaluators will have a hard time reverse engineering why the signature fails verification.
df On Thu, Jul 6, 2023, 11:25 AM Barry Leiba <barryle...@computer.org> wrote: > > This language works well for me. > > Excellent; thanks. > > > I suggest adding some language about why MTAs should not rearrange > message headers or MIME > > sections, even though earlier documents grant permission to do so. > > > > Additionally, when adding headers, an MTA must add them at the top if > (a) the header type is > > included in any verifiable signature, (b) the header is officially > labelled a trace header, or (c) the > > MTA chooses not to match the added header type to existing signatures > (ARC or DKIM) > > If you're talking about something related to the sending domain not > doing that after DKIM signing, we could say that as part of the "use > DKIM and do it correctly" part. If you're talking about MTAs further > along the path, that's out of scope here, at least in a normative > sense. We could say, informatively, that those practices break DKIM > signatures and thus hurt DMARC. But we can't place normative > requirements on MTAs that are not implementing DMARC. > > Barry >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
