On Mon, 8 Sep 2003, David Harris wrote: > I'm looking for guidance on the best practice when handling syntactically > invalid message id's in FETCH ENVELOPE responses.
It was my intent when defining IMAP that an IMAP server not do any special syntax handling of the Message-ID; that is, it would treat the Message-ID: header in more or less the same way as Subject: when reporting it in the ENVELOPE. That remains my position today. Given your message of with an RFC [2]822 syntactically bogus Message-ID: > Message-ID: <5WIP7R4KN55D57C.84PY0HY1T52U."WinXPnews" <[EMAIL PROTECTED]>> I would recommend transmitting the text: <5WIP7R4KN55D57C.84PY0HY1T52U."WinXPnews" <[EMAIL PROTECTED]>> as-is, as an IMAP literal rather than as the quoted string: "<5WIP7R4KN55D57C.84PY0HY1T52U."\WinXPnews\" <[EMAIL PROTECTED]>>" The reason is that IMAP2 clients can grok the literal form but not the quoted string since IMAP2 did not have \-quoting. So, if you're sending it as a quoted string, try changing it to a literal and see if that addresses the problem. > If I report this message-id to the user's copy of Outlook Express as-is > (but properly quoted and escaped), it barfs and pretends that the > message doesn't exist: what's worse, when it does this, it seems to get > its internal message sequence out of step and can end up accessing the > wrong message on subsequent commands. OE fetches envelopes?? That's news to me. I thought that OE just fetches message text and didn't do anything truly IMAPish. > I'm *assuming* that the best practice in a situation like this is for me (the > server) to report NIL for the message-id field when the field is not > syntactically valid, but would appreciate feedback from on high. I would not criticize a server that elected to return NIL for the Message-ID field if the Message-ID: header violates RFC [2]822. "GIGO" is a principle that I hold near and dear to my heart. However, I advise against attempting to "fix" the Message-ID header by transmogrifying it into something valid. Well-intentioned (but IMHO ill-advised) efforts at "fixing" often lead to worse problems than the problem that was "fixed". So, IMHO, it's your choice: either return the Message-ID as-is, warts and all; or return only sane Message-IDs and return NIL if the header is bogus. But before you change your server to send NILs, please try my suggestion of using a literal and see if that makes OE better. Given a choice between losing data and not losing data, I'd prefer the latter... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
