APPEND vs RFC2822 vs STD0011

[John Alton Tamplin]

Edward Reid wrote:

>What RFC3501 says is
>
>      The APPEND command appends the literal argument as a new message
>      to the end of the specified destination mailbox.  This argument
>      SHOULD be in the format of an [RFC-2822] message.
>
>Since it's the client that constructs the literal, it appears to me
>that the RFC is giving the client the choice. The language appears to
>specify only the client/server combination. Obviously it would be
>better if the language were clearer, but it's not. In other places, the
>RFC explicitly refers to the server, for example, the lines immediately
>after the above:
>  
>
My interpretation is still that it is describing the protocol and that 
SHOULD in this case allows (but certainly does not require) the client 
or server to relax this restriction where they see fit.  If the server 
is allowed to not relax this restriction, then clearly the client has to 
be prepared to deal with a response from a server that doesn't.  I agree 
there should be clarification there, but as written I don't see how it 
can be interpreted as "the client MAY choose not to send an RFC2822 
message and the server MUST be prepared to accept a message that is not 
in RFC2822 format".  Surely if such a strong requirement of the server 
was intended it would have been said, rather than SHOULD which is 
intended to give the implementation room to relax requirements if necessary.

>      8-bit
>      characters are permitted in the message.  A server implementation
>      that is unable to preserve 8-bit data properly MUST be able to
>      reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
>      content transfer encoding.
>
>           Note: There MAY be exceptions, e.g., draft messages, in
>           which required [RFC-2822] header lines are omitted in
>           the message literal argument to APPEND.  The full
>           implications of doing so MUST be understood and
>           carefully weighed.
>
>I had not previously noted the implications of that last paragraph. It
>implies that even the headers are not necessarily required to be
>RFC2822 compliant. But it's even less clear about whether the client or
>the server makes the choice. But again, I'm not personally concerned
>about headers.
>
>The formal syntax is no help in this case, because it includes no
>restriction beyond "literal".
>
The addition of this example seems to me to strengthen the "SHOULD be an 
RFC2822 message" statement, since it clearly suggests that even a 
reasonable exception (involving only missing header lines but 
maintaining the basic format) requires careful consideration of the 
implications.

>>Regarding bare newlines, RFC3501 2.2 states:
>>
>>   All interactions transmitted by client and server are in the form
>>of
>>   lines, that is, strings that end with a CRLF.  The protocol
>>receiver
>>   of an IMAP4rev1 client or server is either reading a line, or is
>>   reading a sequence of octets with a known count followed by a line.
>>    
>>
>
>This clearly does not mean that a literal cannot contain CR or LF -- in
>fact, in general the APPEND literal will always contain CRLFs which do
>not end the literal. The literal is prefix-coded with the octet count,
>and so the rule about lines ending in CRLF does not apply until the
>octet count is exhausted. The part of 2.2 that applies to this
>situation is the last line, "reading a sequence of octets with a known
>count".
>  
>
Yes, sorry -- from RFC2822, 2.1:

   Messages are divided into lines of characters.  A line is a series of
   characters that is delimited with the two characters carriage-return
   and line-feed; that is, the carriage return (CR) character (ASCII
   value 13) followed immediately by the line feed (LF) character (ASCII
   value 10).  (The carriage-return/line-feed pair is usually written in
   this document as "CRLF".)

I guess there is still the debate of whether a client should expect the 
server to store something that isn't an RFC2822 message, and on that I 
guess we will have to disagree until the next IMAP RFC is written and 
clarifies it.

-- 
John A. Tamplin                               Unix System Administrator
Emory University, School of Public Health     +1 404/727-9931