[Mailman-Users] no dupes across lists?

Stephen J. Turnbull stephen at xemacs.org
Mon Dec 17 11:12:17 CET 2007

Allan Hansen writes:

 > One message from a subscriber's MUA goes to two lists in Mailman
 > because that person is addressing it using
 > To: list1 at abc.com, list2 at abc.com

[subscriptions of poster and recipient to list1 and list2 verified]

 > Mailman is the actual recipient of this message. However, being a
 > listserver, Mailman becomes the originator (literally) of two new
 > messages,

This may be true "literally", but it is definitely not true from the
point of view of Mailman or RFC 2822.  In fact Mailman will preserve
the Message-ID header, and thus the identity of the two messages.
This behavior conforms to RFC 2822.

 > one for the subscribers of list1 and another for the
 > subscribers of list2. It has to be two messages, because one message
 > has additional headers and a footer added for list1 and the other has
 > headers and a footer added for list2. In fact, Mailman even adds the
 > Sender: header with the list as the sender. 

RFC 2822 headers are not part of the message in the sense relevant to
duplicate pruning.  Messing with those headers (except Message-ID, of
course) should never change the identity of the message in the sense
of RFC 2822 (AFAIK, I haven't read it with that exact point in mind,

 > I'm subscribed to both list1 and list2, so I'll expect to see two
 > different messages being picked up by my MUA. One message with Sender:
 > list1 at abc.com and another with Sender: list2 at abc.com.

I don't suppose list1 is an umbrella list, with list2 subscribed to
it?  Or vice versa?  (I don't know for sure that this could lead to
the described effect, but I also don't see offhand how to prove it

 > In Mailman I'm seeing only the message corresponding to list2.
 > My MTA is Postfix and my MUA is Eudora (both running under Mac OS X
 > 10.4.11).

Eudora is a full-featured MUA; I would imagine it can suppress dupes.

 > I cannot imagine my MUA comparing the two messages and throwing one
 > out, as the message bodies are, in fact, different. Ditto for the MDA
 > and MTA. 

I can't imagine it, either.  But no duplicate-pruning agent I've seen
attempts to compare bodies.  Instead, they use the Message-ID header,
and assume that two messages with the same Message-ID are the same
message in the relevant sense.  Mailman does not touch this header,
because it interprets the addition of body headers and footers, and
even removal of unwanted content, to *not* change the identity of the
message.  (IIRC Mailman does add a Resent-Message-ID, however.)  So
duplicate-pruning agents will suppress one of the messages.

Mailman's internal no-dupes and not-me-too features work differently:
if an explicit recipient address (resp, the from address for
not-me-too) in the message's headers (a) is an exact match for a
subscriber address and (b) its subscription has the no-dupes (resp,
not-me-too) flag set, Mailman does not queue a delivery to that
subscriber address.  This also does not involve an attempt to compare
message bodies.

More information about the Mailman-Users mailing list