[Imap-protocol] question on BODY[n.MIME]?

[Mark Crispin]

On Thu, 8 Mar 2007, Bill Janssen wrote:
>> The BODY[n.MIME] specification returns the entirety of the MIME part
>> mini-header; there is no list of "headers in the mini-header to include
>> and header in the mini-header to exclude."  Note that MIME-Version is
>> normally not in the mini-header.
> Ah, my mistake.  I interpreted the language in the RFC:
> ``The MIME part specifier refers to the [MIME-IMB] header for this part.''
> to mean that only headers specified in [MIME-IMB] should be returned.

Remember that new MIME-IMB header field names can be defined at any time, 
and in fact some of the MIME-IMB header fields aren't defined in MIME-IMB.

The sole purpose of the BODY[x.MIME] fetch is to allow S/MIME software 
access to that data for S/MIME handling.  The fact that Thunderbird uses 
it (especially right after fetching a BODYSTRUCTURE) is one of many 
reasons why it can not be considered an IMAP-clueful client.

>> I'll note that the message is malformed in that
>> the TEXT/PLAIN is missing the mandatory CHARSET.
> I don't believe it's required by RFC 2045 or 2046, and it's not in the
> original message.  I don't see a requirement for it in RFC 3501; could
> you please cite the reference?  Thanks.  I'll add it to the server.

Hmm.  You're right.  I thought that back in MIME working group days we had 
made CHARSET mandatory.  I wonder when that changed.

Anyway, as a general rule the IMAP server should fill in defaults rather 
than requiring the client to do so.

> On a related subject, the BODYSTRUCTURE requirements for extension
> data for a multipart section are a bit unclear to me.  If "body
> disposition", "body language", and "body location" are not available,
> can they be omitted, as I did in my example?  If not, should NIL or ""
> be used to indicate a null "body location"?

The fields which are not in body-ext-1part and body-ext-mpart are 
mandatory.

Extension fields (those in body-ext-1part and body-ext-mpart) MAY be 
omitted IF no subsequent extension field is non-NIL.  Thus, if you have a 
"body language", you MUST have a "body MD5" and "body disposition" because 
they occur earlier in the list, but you MAY omit the "body location" or 
anything after that.

In addition, you may send NIL instead of omitting a field.  This is what 
my server does.

Put another way, omitted extension fields are imputed to be of value NIL.

>> My suggestion is that you try your server against a known IMAP-clueful
>> client (such as Pine or Alpine, hint hint).  That way, if there are
>> interoperability problems, it is much easier to diagnose.
> OK, I'll try that, and report back.  My target clients are Apple
> Mail and Thunderbird, so I've been working with them in an attempt to
> understand their peculiarities.

IMHO, neither of those programs is good for debugging an IMAP server; 
since when a problem comes up you have no good way of knowing if it is 
something your server does wrong or a peculiarity in that client.

Also IMHO, an attempt to work around client peculiarities in an undebugged 
server is an exercise in futility and frustration that all too often leads 
to a server which doesn't work well against proper IMAP clients.

I recommend that you debug against proper IMAP clients first, then tackle 
the peculiar ones...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.