Richard Damon writes:
> The internet protocols disagree on that minor modification create a new
> email.
No, they don't. There's only one RFC that matters, and that's RFC
5322 (or whichever version of that standard that you prefer, but on
this they're basically in agreement). RFC 5322 says:
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.
Here, "Sender" is ambiguous, it could be the OP or it could be
Mailman. I think that since Mailman actually accepts the message and
then decides whether or not to reinject it and in what form, probably
Mailman is the sender referred to.
In that sense, if willi really wants to give the message a new
Message-Id, he may do that in conformance to the RFC. That is a
statement on his part that his administrative needs override the risk
to the users of the list, and that the list "owns" the posts it
transmits.
It's possible to imagine a situation where the risk is quite minimal.
For example an announce list, or a list where only the list is allowed
to appear among the addressees (but in the latter case the list can't
know whether there were Bccs, so the risk is non-zero).
The Mailman developer community considers that the role of Mailman is
to convey the original poster's message to the users, in accordance
with list policy, but that the "message content" should remain
unchanged if the message is distributed at all. For that reason, most
of us feel strongly that the Mailman program as distributed by the
project should never change the Message-Id.[1]
Mailman could add Resent-Message-Id (and other Resent-* headers) but
in default configuration at least it doesn't. Still that wouldn't
help to address the GMail MUA design issue.
willi writes:
> > But, please, let us discuss more about the principles. I don't analyse
> > the sources from mailman and thunderbird to know on what points they
> > use the message-id for what process. What header-fields use
> > thunderbird for thread-ordering? Maybe, on this list read some people
> > from the thunderbird developer group or from other mailtools to
> > explain the needs.
MUA developers mostly don't hang out here. As far as I know they all
agree that Mailman does the right thing for them (as list users) and
for their users, so they're not interested in Mailman development. I
suspect that if Mailman started changing Message-Id, they'd show up in
force. ;-)
As far as I know all modern MUAs such as ThunderBird, Evolution,
GMail, Yahoo! Mail, SquirrelMail, etc use Message-Id, References, and
In-Reply-To for threading. I am certain that archiving programs (such
as Mailman's Pipermail) and services like GMane and Mail-Archive.com do.
> > The message-id should be a unique id for a mail. The mail is a
> > combination of the header and body. This two parts together build
> > the specific mail. If you change one part, you create a new mail.
No, that's definitely an incorrect reading of RFC 5322. See above.
Footnotes:
[1] Although we may *add* one if somehow one arrives at Mailman
without a Message-Id -- but this is extremely rare, as modern MTAs
almost always add a Message-Id on the way to Mailman.
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
