Barry, in my previous note, I used MTA generically, but was particularly thinking of forwarders. I assume that senders and their outbound filtering services will be smart enough to not undermine their own signatures.
I have tried unsuccessfully to accept your assertion that a forwarder is not a participant in DMARC, or John's related assertion that forwarders need no advice. There are many small hosting services that become forwarders as a side effect of a client choice, and do not have the same level of understanding as a mailing list admin who has been through the DMARC-AOL wars. These admins and their software vendors need guidance, as confirmed by a conversation that I had just last week with an admin who was having forwarded messages blocked. Legitimate forwarders have two objectives: 1. To have their forwarded messages accepted by the ultimate recipient, and 2. To avoid forwarding messages that are harmful to the ultimate recipient. To accomplish these goals, a forwarder SHOULD be aware of DMARC, and SHOULD use it to block malicious impersonations. If the forwarder makes changes that render signatures unverifiable, it SHOULD undertake other efforts, such as ARC and From Munging, to prevent wanted messages from being blocked incorrectly. These objectives cannot be achieved if the forwarder is uninformed or if the forwarder claims to be a non-participant in DMARC. Doug Foster On Thu, Jul 6, 2023 at 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
