mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Mark Crispin <mrc+imap@panda.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:47 -0000
Message-ID: alpine.OSX.2.00.1201240857570.38441@hsinghsing.panda.com permalink / raw / eml / mbox
In-Reply-To: 201201241544.q0OFi3S2028880@mxout13.cac.washington.edu
References: 201201241544.q0OFi3S2028880@mxout13.cac.washington.edu
On Tue, 24 Jan 2012, Pete Maclean wrote:
> I have just come across an IMAP client, ibisMail, that sends
>     FETCH n BODY[1.MIME]
> commands for single-part messages.  If memory serves, this is the
> first time I have seen such behavior and I find myself unclear as to
> how a server should handle it.

Simple answer: for all body parts that are not children of a MULTIPART,
the "MIME" specifier returns the empty string (not NIL).

> Considering the case when the MIME part is anything bar a message, it
> seems reasonable either to send the full header section of the
> message (as I observe the Cyrus server does) or to send just the MIME
> headers extracted from the lot.

Both of these behaviors are incorrect. MIME returns only the mini-headers
of a MIME encapsulated part (under the "--boundary") and does not parse
or extract from any message header.

> And what about the case when the single part is, say, of type
> "message/rfc822"?  There I am completely lost!

Return the empty string. To reiterate:

MIME returns only the mini-headers of a MIME encapsulated part (under the
"--boundary") and does not parse or extract from any message header.

Only a child of a MULTIPART has a .MIME part.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Reply