wasm-demo/demo/ermis-f/imap-protocol/cur/1600095110.22920.mbox:2,S

45 lines
1.9 KiB
Plaintext

MBOX-Line: From janssen at parc.com Thu Mar 8 14:12:32 2007
To: imap-protocol@u.washington.edu
From: Bill Janssen <janssen@parc.com>
Date: Fri Jun 8 12:34:38 2018
Subject: [Imap-protocol] question on BODY[n.MIME]?
In-Reply-To: <alpine.OSX.0.83.0703081129120.11046@pangtzu.panda.com>
References: <07Mar8.112542pst."57996"@synergy1.parc.xerox.com>
<alpine.OSX.0.83.0703081129120.11046@pangtzu.panda.com>
Message-ID: <07Mar8.141232pst."57996"@synergy1.parc.xerox.com>
> 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.
> 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.
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"?
> 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.
Bill