MBOX-Line: From mrc+imap at panda.com  Wed Jan 25 07:37:54 2012
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] FETCH n BODY[1.MIME] for a single-part message
In-Reply-To: <2607DEC0-FA3A-4D7D-885E-ECA7B2CF9EA8@iki.fi>
References: <201201241544.q0OFi3S2028880@mxout13.cac.washington.edu>
	<alpine.OSX.2.00.1201240857570.38441@hsinghsing.panda.com>
	<2607DEC0-FA3A-4D7D-885E-ECA7B2CF9EA8@iki.fi>
Message-ID: <alpine.OSX.2.00.1201250729360.38441@hsinghsing.panda.com>

On Wed, 25 Jan 2012, Timo Sirainen wrote:
> I would think it is incorrect for the client to even ask for that, so
> it's more of a GIGO issue.. It looks like Dovecot returns the header,
> but I didn't intentionally make it do that, it just happens for some
> reason.

You are correct; a client should not ever ask for that. As far as IMAP is
concerned, there is no such part. The correct server response in IMAP to a
request for a non-existent body part is to return the empty string.

There are complicated, and to some extent historical, reasons why the
empty string (as opposed to an error) is the correct return. Suffice it to
say that a client that never asks for any body part without first
verifying that it exists via BODYSTRUCTURE will never encounter that
behavior; but there are reasons why a client might do otherwise.

Hint: "BODY[1]<1:128>".

-- 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.

