Imap4d: fix handling of nested message/rfc822 parts.

* imap4d/fetch.c (fetch_runtime_closure) <msglist>: New member.
(frt_register_message,frt_unregister_messages): New functions.
(fetch_get_part_rfc822): Look into encapsulated rfc822 messages.
(_frt_body_text,_frt_header)
(_frt_header_fields): Use frt_unregister_messages.
(imap4d_fetch0): Initialize all fields in struct fetch_runtime_closure.
Destroy msglist when finished using it.
* imap4d/tests/fetch.at: Add test cases for nested message/rfc822.
* testsuite/spool/msg.mbox: Add a message with nested message/rfc822 part.

1 files changed, 229 insertions, 0 deletions

diff --git a/testsuite/spool/msg.mbox b/testsuite/spool/msg.mbox
index dc90cb041..126934eb0 100644
--- a/testsuite/spool/msg.mbox
+++ b/testsuite/spool/msg.mbox
@@ -42,3 +42,232 @@ X-Envelope-Sender: gray@example.org
 
 --1595057156-1322340286=:8528--
 
+From gray@example.org Tue Nov 29 09:42:53 2011
+Message-ID: <20111129114253.10123@host.example.org>
+From: "Sergey Poznyakoff" <gray@example.org>
+Date: Tue, 29 Nov 2011 11:42:53 +0200
+To: <root@example.com>
+Subject: nested message
+Content-Type: multipart/mixed; boundary="1727955616-1322559692=:10106"
+MIME-Version: 1.0
+
+--1727955616-1322559692=:10106
+Content-ID: <20111129114132.10106.1@host.example.org>
+Content-Type: text/plain
+
+An example of nested message/rfc822
+
+
+--1727955616-1322559692=:10106
+Content-Transfer-Encoding: 7bit
+Content-Description: 
+Content-ID: <20111129114132.10106.1@host.example.org>
+Content-Type: message/rfc822; name="msg.mbox"
+
+Date: Sat, 26 Nov 2011 22:45:20 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <root@example.com>
+Subject: rfc2046
+Content-Type: multipart/mixed; boundary="1595057156-1322340286=:8528"
+MIME-Version: 1.0
+Status: OR
+
+--1595057156-1322340286=:8528
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: text/plain
+
+An excerpt from RFC 2046 regarding message/rfc822.
+
+
+--1595057156-1322340286=:8528
+Content-Transfer-Encoding: 7bit
+Content-Description: 
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Message-ID: <20111123103317.27412@host.example.org>
+Date: Wed, 23 Nov 2011 10:33:17 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <gray@example.com>
+Subject: Re: RFC822 Subtype
+In-reply-to: Your message of Wed, 23 Nov 2011 08:48:16 +0100
+         <87wrar6zzz@example.com>
+References: <87wrar6zzz@example.com>
+X-Envelope-Date: Wed Nov 23 08:33:17 2011
+X-Envelope-Sender: gray@example.org
+
+5.2.1.  RFC822 Subtype
+
+   A media type of "message/rfc822" indicates that the body contains an
+   encapsulated message, with the syntax of an RFC 822 message.
+   However, unlike top-level RFC 822 messages, the restriction that each
+   "message/rfc822" body must include a "From", "Date", and at least one
+   destination header is removed and replaced with the requirement that
+   at least one of "From", "Subject", or "Date" must be present.
+
+--1595057156-1322340286=:8528--
+
+
+--1727955616-1322559692=:10106--
+From gray@example.org Tue Nov 29 13:16:16 2011
+To: gray@example.com
+Subject: nested multipart + message/rfc822.
+Content-Type: multipart/mixed; boundary="2059362778-1322566623=:4927"
+MIME-Version: 1.0
+Status: OR
+
+--2059362778-1322566623=:4927
+Content-ID: <20111129133703.4927.1@host.example.org>
+Content-Type: text/plain
+
+The following multipart attachment contains a message/rfc822 as one of
+its parts.
+
+
+--2059362778-1322566623=:4927
+Content-Type: multipart/mixed; boundary="1110782568-1322566623=:4927"
+MIME-Version: 1.0
+
+--1110782568-1322566623=:4927
+Content-ID: <20111129133703.4927.2@host.example.org>
+Content-Type: text/plain
+
+Introductory text
+
+
+--1110782568-1322566623=:4927
+Content-Transfer-Encoding: 7bit
+Content-Description: Nested message
+Content-ID: <20111129133703.4927.2@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Date: Sat, 26 Nov 2011 22:45:20 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <root@example.com>
+Subject: rfc2046
+Content-Type: multipart/mixed; boundary="1595057156-1322340286=:8528"
+MIME-Version: 1.0
+Status: OR
+
+--1595057156-1322340286=:8528
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: text/plain
+
+An excerpt from RFC 2046 regarding message/rfc822.
+
+
+--1595057156-1322340286=:8528
+Content-Transfer-Encoding: 7bit
+Content-Description: 
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Message-ID: <20111123103317.27412@host.example.org>
+Date: Wed, 23 Nov 2011 10:33:17 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <gray@example.com>
+Subject: Re: RFC822 Subtype
+In-reply-to: Your message of Wed, 23 Nov 2011 08:48:16 +0100
+         <87wrar6zzz@example.com>
+References: <87wrar6zzz@example.com>
+X-Envelope-Date: Wed Nov 23 08:33:17 2011
+X-Envelope-Sender: gray@example.org
+
+5.2.1.  RFC822 Subtype
+
+   A media type of "message/rfc822" indicates that the body contains an
+   encapsulated message, with the syntax of an RFC 822 message.
+   However, unlike top-level RFC 822 messages, the restriction that each
+   "message/rfc822" body must include a "From", "Date", and at least one
+   destination header is removed and replaced with the requirement that
+   at least one of "From", "Subject", or "Date" must be present.
+
+--1595057156-1322340286=:8528--
+
+
+--1110782568-1322566623=:4927--
+
+--2059362778-1322566623=:4927--
+
+From gray@example.org Tue Nov 29 13:16:16 2011
+To: gray@example.com
+Subject: nested multipart + message/rfc822.
+Content-Type: multipart/mixed; boundary="2059362778-1322566623=:4927"
+MIME-Version: 1.0
+X-IMAPbase: 1322575861 2
+Status: OR
+X-UID: 1
+
+--2059362778-1322566623=:4927
+Content-ID: <20111129133703.4927.1@host.example.org>
+Content-Type: text/plain
+
+The following multipart attachment contains a message/rfc822 as one of
+its parts.
+
+
+--2059362778-1322566623=:4927
+Content-Type: multipart/mixed; boundary="1110782568-1322566623=:4927"
+MIME-Version: 1.0
+
+--1110782568-1322566623=:4927
+Content-ID: <20111129133703.4927.2@host.example.org>
+Content-Type: text/plain
+
+Introductory text
+
+
+--1110782568-1322566623=:4927
+Content-Transfer-Encoding: 7bit
+Content-Description: Nested message
+Content-ID: <20111129133703.4927.2@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Date: Sat, 26 Nov 2011 22:45:20 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <root@example.com>
+Subject: rfc2046
+Content-Type: multipart/mixed; boundary="1595057156-1322340286=:8528"
+MIME-Version: 1.0
+Status: OR
+
+--1595057156-1322340286=:8528
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: text/plain
+
+An excerpt from RFC 2046 regarding message/rfc822.
+
+
+--1595057156-1322340286=:8528
+Content-Transfer-Encoding: 7bit
+Content-Description: 
+Content-ID: <20111126224446.8528.1@host.example.org>
+Content-Type: message/rfc822; name="1.msg"
+
+Message-ID: <20111123103317.27412@host.example.org>
+Date: Wed, 23 Nov 2011 10:33:17 +0200
+From: Sergey Poznyakoff <gray@example.org>
+To: <gray@example.com>
+Subject: Re: RFC822 Subtype
+In-reply-to: Your message of Wed, 23 Nov 2011 08:48:16 +0100
+         <87wrar6zzz@example.com>
+References: <87wrar6zzz@example.com>
+X-Envelope-Date: Wed Nov 23 08:33:17 2011
+X-Envelope-Sender: gray@example.org
+
+5.2.1.  RFC822 Subtype
+
+   A media type of "message/rfc822" indicates that the body contains an
+   encapsulated message, with the syntax of an RFC 822 message.
+   However, unlike top-level RFC 822 messages, the restriction that each
+   "message/rfc822" body must include a "From", "Date", and at least one
+   destination header is removed and replaced with the requirement that
+   at least one of "From", "Subject", or "Date" must be present.
+
+--1595057156-1322340286=:8528--
+
+
+--1110782568-1322566623=:4927--
+
+--2059362778-1322566623=:4927--
+