Re: Threads and &
Hi,
* Kyle Wheeler wrote:
> On Friday, June 19 at 02:43 PM, quoth Rocco Rutte:
> > Hmm, I think the reason is rather that nobody thought of this case.
> > A problem with assigning it a locally generated Message-ID is that
> > it's locally generated, i.e. nobody else that. If this is, for
> > example, a mailing list message, and you assign a new one, you'll
> > break everybody else's References because they don't know you
> > generated an ID for it.
> That's true, but...
> > Anyway, shouldn't the first MTA in the mail path that sees a message
> > without an ID assign one?
> Nope. Message-ID is an optional field, according to RFC 822. Some MTAs
> *do* add Message-IDs to messages, but they're not required to and so
> not all of them do. More recently RFC 2822 says all messages *should*
> have a Message-ID field, but doesn't explicitly encourage MTAs to add
> one to messages that don't have one. Because of this, I think an
> argument similar to the one you made above could be made against MTAs
> adding Message-ID headers: they can only add a locally generated
> header, and cannot guarantee that every recipient of the message will
> receive that Message-ID header with that message.
My point was about the _first_ MTA only. Later MTAs in the delivery
process are not allowed to make these changes as per RFC5321:
The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting (message submission) protocol:
o Addition of a message-id field when none appears
o Addition of a date, time, or time zone when none appears
o Correction of addresses to proper FQDN format
The less information the server has about the client, the less likely
these changes are to be correct and the more caution and conservatism
should be applied when considering whether or not to perform fixes
and how. These changes MUST NOT be applied by an SMTP server that
provides an intermediate relay function.
Even if the messages comes in through SMTP, a server could check the presence
of Received: headers to determine if he's the place where delivery starts.
> In any case, if MTAs are "allowed" to add Message-IDs to messages even
> if the message did not originate locally, then why can't mutt do the
> same? It's true that, if we then reply to that message, nobody will
> recognize the referenced message-id, but so what? I don't see how that
> would have any major drawbacks compared to refusing to generate a
> local message-id.
I can't see any major problems either... it's just that I think mutt shouldn't
mangle messages. On the other hand, I've never even tried to link to message
without and ID. Maybe also the implementation isn't that easy because you have
to change two messages, I don't know.
Rocco