RFC 3501 violation in FETCH BODY responses
Stephan Bosch
stephan at rename-it.nl
Sun Dec 18 14:16:20 UTC 2016
Op 8/22/2016 om 2:29 PM schreef Guilhem Moulin:
> Hi there,
>
> Quoting RFC 3501 sec. 7.4.2 “FETCH Response” (data item BODYSTRUCTURE):
>
> “A body type of type MESSAGE and subtype RFC822 contains,
> immediately after the basic fields, the envelope structure, body
> structure, and size in text lines of the encapsulated message.”
>
> According the ABNF (RFC 3501 sec. 9) the envelope structure is that of
> the ENVELOPE FETCH data item, and the env-{from,sender,reply-to,to,cc,
> bcc} fields are non-space-separated address lists:
>
> body-type-msg = media-message SP body-fields SP envelope SP body SP body-fld-lines
> envelope = "(" env-from SP … SP env-to SP … ")"
> env-from = "(" 1*address ")" / nil
> env-to = "(" 1*address ")" / nil
>
> While this is indeed the case for ‘FETCH … (ENVELOPE)’, for ‘FETCH …
> (BODY)’ dovecot 2.2.25 adds a space between addresses of an address list
> of the envelope structure of an encapsulated MESSAGE/RFC822 message.
>
> See the attached patch to ‘src/lib-imap/test-imap-bodystructure.c’,
> which currently (2.2.25) fails as follows
>
> test-imap-bodystructure.c:122: Assert failed: strcmp(str_c(str), testmsg_body) == 0
> test-imap-bodystructure.c:129: Assert failed: strcmp(str_c(str), testmsg_bodystructure) == 0
> imap bodystructure parser ............................................ : FAILED
>
> because the ‘env-to’ field of the envelope structure of the encapsulated
> MESSAGE/RFC822 message is printed as
>
> ((NIL NIL "sub-to1" "domain.org") (NIL NIL "sub-to2" "domain.org"))
>
> while it should be
>
> ((NIL NIL "sub-to1" "domain.org")(NIL NIL "sub-to2" "domain.org"))
>
> After a quick look at the source, this seems to be due to
> src/lib-imap/imap-bodystructure.c:imap_write_list, which always
> separates list items with spaces. In the case of an envelope, only the
> top-level list should be space-separated. Indeed, not adding a space
> between items of type IMAP_ARG_LIST in the recursive call makes the test
> pass again.
Fixed:
https://github.com/dovecot/core/commit/f549b400d50935754cbeb6ceabd922ab777b4d77
Regards,
Stephan.
More information about the dovecot
mailing list