[Mailman-Users] no dupes across lists?

[Allan Hansen]

This certainly explains the behaviour, Stephen and Brad. I had looked
through all the
options in Eudora and didn't find a way to turn off this pruning feature,
so I assumed it
to be non-existent.

As for RFC 2822, this is what it says about Message-ID. Given the
highlighted section,
I think that what you have done with Mailman (not touching the Message-ID)
is the
right thing to do. Besides, keeping Brad sane is certainly a worthy goal. :-)

Thank you all for a great program.

Allan


   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

   Note: There are many instances when messages are "changed", but those
   changes do not constitute a new instantiation of that message, and
   therefore the message would not get a new message identifier.  For
   example, when messages are introduced into the transport system, they
   are often prepended with additional header fields such as trace
   fields (described in section 3.6.7) and resent fields (described in
   section 3.6.6).  The addition of such header fields does not change
   the identity of the message and therefore the original "Message-ID:"
   field is retained.  In all cases, it is the meaning that the sender
   of the message wishes to convey (i.e., whether this is the same
   message or a different message) that determines whether or not the
   "Message-ID:" field changes, not any particular syntactic difference
   that appears (or does not appear) in the message.


At 19:12 +0900 12/17/07, Stephen J. Turnbull wrote:
>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,
>though).
>
> > 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
>couldn't.)
>
> > 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.

-- 
Allan Hansen
P.O Box 2423
Cypress, CA 90630
U.S.A.
hansen at rc.org
+1-714-875-8870