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: [EMAIL PROTECTED], [EMAIL PROTECTED] > >[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: > > [EMAIL PROTECTED] and another with Sender: [EMAIL PROTECTED] > >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. [EMAIL PROTECTED] +1-714-875-8870 ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp