[Mailman-Users] Mailman reusing message-id, leads to duplicate message suppression

Stephen J. Turnbull stephen at xemacs.org
Wed Nov 6 03:56:43 CET 2013

Richard Damon writes:

 > It is not clear to me that mailman should add the Resent-* headers. The
 > RFC states:

No, it's not clear to me, either.  I do have a very strong opinion in
favor, to the extent that I would make it an option defaulting to ON.

 > "Resent fields SHOULD be added to any message that is reintroduced by a
 > user into the transport system."

This is relevant, and I agree that it's not clear whether Mailman is a
"user" as referred to by the RFC.  Because the Resent-* headers are
purely informational, I think it's harmless to add them: they're the
non-MTA equivalent of the trace headers added by MTAs.  Mailman is
clearly not part of the "transport system" (it's not an MTA even
though does implement parts of SMTP), and often there is human
intervention ("moderation" and user configuration such as "notmetoo")
in the process of reinserting the message into the transport system.
Based on those facts, I think it's reasonable to strengthen the MAY
implied by "harmless" to SHOULD.

Also, I believe that Resent-From is preferable to unstandardized
mechanisms for detecting loops such as "X-Been-There".

 > and later
 > "They MUST NOT be used in the normal processing of replies or other
 > such automatic actions on messages."

This isn't relevant.  The "normal processing of replies or other such
automatic actions on messages" referred to here is by the MUA of the
final recipient, *not* the agent that adds the Resent-* headers.  It
means that replies MUST NOT be directed to any Resent-From address
automatically (note there is no Resent-Reply-To), and In-Reply-To and
References MUST NOT be initialized based on any Resent-Message-ID.


More information about the Mailman-Users mailing list