At 5:35 AM -0500 11/10/06, Tom Allison wrote to many mailing lists
including the Dovecot list:>I was porting some email from one imap server location to another
>and ran into a feature of something. One of them writes message-id
>as 'Message-Id' and the other writes it as 'Message-ID'.
Because of
>this, all the messages are forever different.
No well-written mail software should see those as different.
>All mail is delivered from postfix and will be in the future.
Not relevant. The Message-ID header can be created at virtually any
point in mail handling but usually is created by the MUA that
constructs the message. Your message that I saw on the Dovecot list
carried one that was almost certainly created by Thunderbird, and I
expect that when you see this message it will continue to carry one
created by Eudora. Other mailing lists may discard the original MID
and impose their own on the copies distributed to subscribers. The
only times that an MTA is relevant are when messages arrive with no
header and the MTA is configured to add their own (which is the
default modern behavior for Sendmail and I believe for Postfix as
well.)
>But I'm asking which of these syntaxes is correct or if there is a
>right/wrong way of writing the headers? RFC2822 doesn't come right
>out and say it, but all the examples therein are "Message-ID".
RFC2822 says:
1.2.2. Syntactic notation
This standard uses the Augmented Backus-Naur Form (ABNF) notation
specified in [RFC2234] for the formal definitions of the syntax of
messages. Characters will be specified either by a decimal value
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
a case-insensitive literal value enclosed in quotation marks (e.g.,
"A" for either uppercase or lowercase A). See [RFC2234] for the
full
description of the notation.
In other words: anywhere in RFC2822 that you see letters instead of
numeric codes specifying a character, it indicates
case-insensitivity. Given the actual specifications of header fields,
this means that ALL message header field names can be in any case.
Mail (and things like HTTP and news that have based their message
formats on mail) have always worked that way.
Changing that in a specification like RFC2822 would be a very bad
idea. RFC's are supposed to describe working systems, not theoretical
ideals, and RFC's like 2822 that are updates to widely implemented
standards need to be written (as 2822 was) to reflect reality first.
Because case is explicitly irrelevant for header field names in
RFC822 (and its predecessors) there's really no chance of any
successor narrowing that to require a particular case pattern, and
any that did would simply be ignored in that respect. RFC's have no
more power than dictionaries.
--
Bill Cole
bill at scconsult.com