Dear friends,
following the RFC 5322 all identification fields are optional. But they SHOULD have it. Of course, sometimes we need it.
RFC 5322: Internet Message Format http://tools.ietf.org/html/rfc5322
We have min 3 fields: message-id in-reply-to references
With that, we can create all ordering of mails based on a thread. I think, it would be never a problem to use a new (little changed) message-id, because if the listserver send the mail, he changed it. And consequently, he create a new message-id (but for himself and for tracking it can be a modification of the original message-id).
In the discussion on this list Mark and other people args, this would lead to a big confusion for the different mail clients. Is that true? I don't have the necessary oversight. But i think, you have it.
The easest way would be a configuratin point for the user to decide, that his sended mail get a new message-id, if the listserver changed it when he send the mail. And this he always do it.
many greetings, willi Panama City
On 06/23/2014 08:59 AM, willi uebelherr wrote:
The easest way would be a configuratin point for the user to decide, that his sended mail get a new message-id, if the listserver changed it when he send the mail. And this he always do it.
We have no plans or interest to change Mailman in this way for reasons already stated on this list.
Your issue is with Gmail's "discard duplicate message" feature, which we don't agree with except perhaps as a Gmail user setting, but Google has no plan to change this as far as we know.
Your choice is clear to me. If you don't like the way Gmail handles your list posts, subscribe and post from a non-gmail address.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Monday 23 June 2014, Mark Sapiro wrote:
Your choice is clear to me. If you don't like the way Gmail handles your list posts, subscribe and post from a non-gmail address.
Mark, off topic for *this* list though you might want to add this to the FAQ?
willi, some web hosting servers will allow customers to post outgoing mail with any address you own. Even if it does not match the domain you have hosted with them. My ISP (.tds) address has been outsourced to Gmail for about five years. When this message returns to me Gmail will not discared it as a duplicate since they did not see it out bound.
Only good solution I have found though it does cost $5 per month for hosting. Which I would have anyway just for my web site...
William
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.
- the proposal from Richard Damon
- a second account on gmail
- 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
Am 06/23/2014 07:11 p.m., schrieb William Bagwell:
On Monday 23 June 2014, Mark Sapiro wrote:
Your choice is clear to me. If you don't like the way Gmail handles your list posts, subscribe and post from a non-gmail address.
Mark, off topic for *this* list though you might want to add this to the FAQ?
willi, some web hosting servers will allow customers to post outgoing mail with any address you own. Even if it does not match the domain you have hosted with them. My ISP (.tds) address has been outsourced to Gmail for about five years. When this message returns to me Gmail will not discared it as a duplicate since they did not see it out bound.
Only good solution I have found though it does cost $5 per month for hosting. Which I would have anyway just for my web site...
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.
- the proposal from Richard Damon
- a second account on gmail
- 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
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.
participants (5)
-
Mark Sapiro -
Richard Damon -
Stephen J. Turnbull -
willi uebelherr -
William Bagwell