The internet protocols disagree on that minor modification create a new
email. For instance, EVERY step of mail deliver is REQUIRED to change
the headers of the message, so that would say every step should change
the Message-ID, which distorts some of its use.
The RFC's also say that if a message is received and immediately
automatically forwarded, that is should retain the same Message-id.
The case where changing the Message-ID like you are proposing will cause
problems is this:
A message is posted to the list.
A person replies with a reply all, sending a reply directly to the
original poster, and to the list, and asks the list for a new Message-ID
Copies of that reply now exist with two different Message-Ids
If the original poster now replies to the direct copy they got back to
the list, the Reference headers will not point to the message it got
that he replied to, so threading for ALL other members is broken.
The problem being tried to solve is an unusual behavior by a given MUA.
You don't break a fundamental rule of email to solve that problem, you
get the MUA to behave the way you want, or change MUA.
On 6/24/14, 9:50 AM, willi uebelherr wrote:
Dear William and Mark and all,
many thanks for your answer. I understand, that never you want to make
any special action for a specific task for Gmail.
But now, for me it is not a question of the specific "duplicate
suppression" from google-mail. it is a more general debate about the
principles of "Internet Message Format".
i have have now many alternatives.
1) the proposal from Richard Damon
2) a second account on gmail
3) a non-gmail account like gmx (i have) or a new riseup account
Many thanks for your proposals.
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.
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.
Following of that, if mailman change the subject line or append a
footer, it is a new mail and need a new message-id. Consequently, we
can say, if the header of a mail is extended on his way from one
client to the other client, an all chainpoints there are creating a
new mail. Because they axtend the header with header fields for the
in/out nodes.
This is the result of the logic of the RFC 5322.
I know, in our time we have a confuse situation. Many things from our
history overlaped this logic. And the people for one single project
are not part of the whole project, the mail processing in the
internet. They work seperated and sometimes against.
We can see, that hotmail create a wrong message-id in relation to RFC
5322. But is the syntactical structure important? I think no. Only the
uniqueness, the singularity, is important.
In my thinking i prefer that mailman can be a reference implementation
for maillist-server. Because in principial, only a Open Source project
can can fulfill this function. But this makes it necessary to reflect
our own doing and to discuss the process algorithms on a open and free
base. Committed only the basic fundamentals.
And what i read from Mark i see, that he act in a personal defense
against Gmail. And that is not good. I had the same positiob before.
But now, i changed my thinking. I see, that the argumentation from
bkennely is correct. And this is independent from, that he work for
Google Gmail.
mant thanks and many greetings, willi
Panama City
--
Richard Damon
------------------------------------------------------
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
