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.