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: Petite Abeille <petite_abeille@mac.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:47 -0000
Message-ID: BAA75CE5-7AE6-4C96-821E-A56A41337B9F@mac.com permalink / raw / eml / mbox
Hello,

Can the fetch command contain the same attribute multiple times?

For example, the following request , curtesy of dbmail test suite [1], sports the BODY.PEEK attribute twice, for two different header fields:

C0000A UID FETCH 1:* (BODY.PEEK[HEADER.FIELDS (Subject)] BODY.PEEK[HEADER.FIELDS (Message-Id)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)

Is such fetch request compliant? Can the fetch attributes be repeated multiple times?

If yes, what's the expected response? Two BODYs, one for each header? One BODY with the two requested fields? Either?

Thanks in advance.

[1] testfetch.txt
Reply
E-mail headers
From: mrc+imap@panda.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:47 -0000
Message-ID: alpine.OSX.2.00.1111270821030.931@hsinghsing.panda.com permalink / raw / eml / mbox
On Sun, 27 Nov 2011, Petite Abeille wrote:
> Can the fetch command contain the same attribute multiple times?

Yes.

> For example, the following request , curtesy of dbmail test suite [1],
> sports the BODY.PEEK attribute twice, for two different header fields:
> C0000A UID FETCH 1:* (BODY.PEEK[HEADER.FIELDS (Subject)] BODY.PEEK[HEADER.FIELDS (Message-Id)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)
> Is such fetch request compliant?

Yes.

> Can the fetch attributes be repeated multiple times?

Yes, but that is not a repeated fetch attribute.

BODY[HEADER.FIELDS (Subject)] and BODY.PEEK[HEADER.FIELDS (Message-Id)]
are two entirely different FETCH attributes. The stuff in the [] is part
of the fetch attribute, and thus makes the two different. By special
dispensation, ".PEEK" is not part of the attribute and does not appear in
the response.

An example of a repeated fetch attribute is this pointless example:
 	tag FETCH 1 (UID RFC822.SIZE UID)

In this case, UID is repeated. This is valid/compliant but pointless. The
server may respond by sending the UID twice, or it may send it just once;
either way satisfies the request. On the other hand, nothing prevents a
server from (pointlessly) sending UID twice. So, in the end, the effect is
identical to:
 	tag FETCH 1 (UID RFC822.SIZE)
even if some servers may be babble more

Also, consider this pointless example:
 	tag fetch 1 (BODY.PEEK[HEADER.FIELDS (Subject)] BODY[HEADER.FIELDS (Message-Id)]

The response and effect is identical to
 	tag fetch 1 (BODY[HEADER.FIELDS (Subject)] BODY[HEADER.FIELDS (Message-Id)]

This is because the same attributes are fetched, and the second BODY
(without the .PEEK) causes the \Seen flag to be updated as if the first
.PEEK was not there.

IMAP does not prevent pointless client commands; however the server is
supposed to behave sensibly.

> If yes, what's the expected response? Two BODYs, one for each header?

Yes.

BODY[HEADER.FIELDS (Subject)] and BODY.PEEK[HEADER.FIELDS (Message-Id)]

> One BODY with the two requested fields? Either?

No. That would be a response with a different FETCH attribute. The server
must respond with the requested attributes.

If the client requested Subject and Message-Id separately like that, it
wants them returned separately. If it wanted them together, it would have
requested them together:
 	tag fetch 1 (BODY[HEADER.FIELDS (Subject Message-Id)]

In this case, the server MUST return attribute
 	BODY[HEADER.FIELDS (Subject Message-Id)]
with a single string containing both.

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