Hallo Charles, On Sat, 3 Jul 2004 01:02:13 +0200GMT (3-7-2004, 1:02 +0200, where I live), you wrote:
>>> Danger, Will Robinson! Did you know that Outlook 2003 does not generate >>> them? KA>> Outlook doesn't have to. This is the job of the mail server. CMG> What rfc states this? It isn't. Why would a mta do that if it doesn't CMG> know where it's coming from? RFC2822 states this about message-id's: 3.6.4. Identification fields Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below. The "Message-ID:" field contains a single unique message identifier. The "References:" and "In-Reply-To:" field each contain one or more unique message identifiers, optionally separated by CFWS. The message identifier (msg-id) is similar in syntax to an angle-addr construct without the internal CFWS. <skipping description of message-id> 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. And the bottom part of RFC2821 section 6.3 states: In response to these weak SMTP clients, many SMTP systems now complete messages that are delivered to them in incomplete or incorrect form. This strategy is generally considered appropriate when the server can identify or authenticate the client, and there are prior agreements between them. By contrast, there is at best great concern about fixes applied by a relay or delivery SMTP server that has little or no knowledge of the user or client machine. 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 protocol: - Addition of a message-id field when none appears - Addition of a date, time or time zone when none appears - 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. In all cases, properly-operating clients supplying correct information are preferred to corrections by the SMTP server. In all cases, documentation of actions performed by the servers (in trace fields and/or header comments) is strongly encouraged. Especially when you look at the last paragraph, it's clear that TB should destroy the message-id before sending the message out. -- Groetjes, Roelof Disclaimer: Any opinion stated in this message is not necessarily shared by my budgies or rabbits. ________________________________________________ Current version is 2.11.02 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
