[Imap-protocol] FETCH Response

Mark Crispin mrc+imap at panda.com
Fri Apr 15 11:14:24 PDT 2011


It took me a while to figure out what you were asking in your example, as
you omitted some important information: specifically, the BODYSTRUCTURE
that identified the type/subtype/encoding of message part 3. Also,
where did those spurious \ in the server responses come from?

Anyway, I think that your answer is as follows:

The BODY section specifiers HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and
TEXT only apply to message parts of type MESSAGE/RFC822. Implicitly, the
entire message (the top level) is typed MESSAGE/RFC822.

Your example presumably shows a TEXT/HTML message part with encoding
BASE64. At least, the BODY[3] contents appeared to be BASE64, and when
put through a BASE64 decoder came up with a short HTML document.

In other words, HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT are all
meaningless for BODY[3] in this example. The appropriate server behavior
is:

C: A18 FETCH 1 BODY[3.HEADER]
S: * 1 FETCH (BODY[3.HEADER] "")
S: A18 OK that was a silly thing for you to do!
C: A19 FETCH 1 BODY[3.TEXT]
S: * 1 FETCH (BODY[3.TEXT] "")
S: A19 OK that was a silly thing for you to do!

As a matter of good design, you should always use an zero-length quoted
string, rather than a zero-length literal, to represent the empty string.
Of course, implementations MUST accept either form.

The reason why you don't have a blank line in the 3.HEADER fetch is that
there is no "message" (it is a TEXT/HTML, not a MESSAGE/RFC822) and thus
if you are substituting an empty string the "message which has no body and
no blank line" rule applies.

If I were to do things over today, I would have required:

C: A18 FETCH 1 BODY[3.HEADER]
S: A18 BAD meaningless to fetch header for type TEXT/HTML
C: A19 FETCH 1 BODY[3.TEXT]
S: A19 BAD meaningless to fetch header for type TEXT/HTML

It's historical as to why meaningless text fetches return the empty string
rather than a BAD; there were good reasons once upon a time but those
reasons have long since been rendered moot. A related history is why
BODY[1] and BODY[TEXT] are equivalent for a non-MIME message.

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


More information about the Imap-protocol mailing list