What RFC3501 says isMy 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.
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:
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.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".
Yes, sorry -- from RFC2822, 2.1: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".
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
