The "resent" fields are currently used for their stated purpose, which as you correctly note, is to signal that a message has been re-introduced into the mail transport. These fields are typically used when a message which has already been delivered to a mailbox is resent unmodified (and possibly after a delay) to another email address.
A mailing list does not resend messages, it modifies and re-posts them to a subscriber list. The 5322.From and/or 5322.Sender fields are therefore more appropriate for mailing lists because they indicate the originator of the now re-posted/modified original message. Ken. From: dmarc <[email protected]> On Behalf Of Douglas E. Foster Sent: Wednesday 7 October 2020 03:47 To: [email protected] Subject: [dmarc-ietf] RESENT fields? Are the RESENT fields from RFC 5322 an interesting idea that everybody has ignored? For purposes of this discussion, they interest me because they provide a way of documenting changes to the SMTP sender, the From Header, and the recipient list. RFC 5322 Section 3.6.6 says they SHOULD by added whenever a message is re-introduced to the transport system. Mailing list activity seems to fit the language and intent of this section. But I do not see any RESENT fields on the most recent posts to this list. In fact, I am not sure that I have ever seen a message anywhere with these fields. Application: For forwarded messages, I don't want to trust the forwarder's spam filter, so I want to reconstruct the message identity as it appeared when the message entered the forwarder's ADMD. The Resent fields would allow that logic to be developed, but I would also need forwarders to use those fields. The usage would also need to apply to auto-forwarders, even though they are explicitly exempted from the RESENT header recommendation in the current RFC. Doug Foster
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
