[Dovecot] RFC 2822 - message-id

[Bill Cole]

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