dovecot - Mar 2020 - [PATCH] lib-imap: imap-bodystructure: add test with empty header field

This causes the body structure to be incorrect. The RFC says it's fine o
have empty header field values.
---

This just adds a failing test, inspired from an e-mail spotted in the
wild. Ideas welcome to fix it.

 src/lib-imap/test-imap-bodystructure.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/src/lib-imap/test-imap-bodystructure.c
b/src/lib-imap/test-imap-bodystructure.c
index 6f456a44530b..b8f215d689c4 100644
--- a/src/lib-imap/test-imap-bodystructure.c
+++ b/src/lib-imap/test-imap-bodystructure.c
@@ -41,6 +41,19 @@ struct parse_test parse_tests[] = {
 			"\"text\" \"plain\" (\"charset\"
\"utf-8\") NIL NIL \"8bit\" 8 2 NIL NIL NIL NIL",
 		.body  			"\"text\" \"plain\" (\"charset\"
\"utf-8\") NIL NIL \"8bit\" 8 2"
+	},{
+		.message +			"From: user at domain.org\n"
+			"Date: Sat, 24 Mar 2017 23:00:00 +0200\n"
+			"X-Spam-Level:\n"
+			"Content-Transfer-Encoding: quoted-printable\n"
+			"\n"
+			"body\n"
+			"\n",
+		.bodystructure +			"\"text\" \"plain\"
(\"charset\" \"us-ascii\") NIL NIL
\"quoted-printable\" 8 2 NIL NIL NIL NIL",
+		.body +			"\"text\" \"plain\" (\"charset\"
\"us-ascii\") NIL NIL \"quoted-printable\" 8 2"
 	},{
 		.message  			"From: user at domain.org\n"
--
2.25.1

Hi!

Thanks for the patch, we'll look into it.

Aki
> On 03/03/2020 20:38 Simon Ser <contact at emersion.fr> wrote:
> 
>  
> This causes the body structure to be incorrect. The RFC says it's fine
o
> have empty header field values.
> ---
> 
> This just adds a failing test, inspired from an e-mail spotted in the
> wild. Ideas welcome to fix it.
> 
>  src/lib-imap/test-imap-bodystructure.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/src/lib-imap/test-imap-bodystructure.c
b/src/lib-imap/test-imap-bodystructure.c
> index 6f456a44530b..b8f215d689c4 100644
> --- a/src/lib-imap/test-imap-bodystructure.c
> +++ b/src/lib-imap/test-imap-bodystructure.c
> @@ -41,6 +41,19 @@ struct parse_test parse_tests[] = {
>  			"\"text\" \"plain\" (\"charset\"
\"utf-8\") NIL NIL \"8bit\" 8 2 NIL NIL NIL NIL",
>  		.body >  			"\"text\" \"plain\"
(\"charset\" \"utf-8\") NIL NIL \"8bit\" 8 2"
> +	},{
> +		.message > +			"From: user at domain.org\n"
> +			"Date: Sat, 24 Mar 2017 23:00:00 +0200\n"
> +			"X-Spam-Level:\n"
> +			"Content-Transfer-Encoding: quoted-printable\n"
> +			"\n"
> +			"body\n"
> +			"\n",
> +		.bodystructure > +			"\"text\" \"plain\"
(\"charset\" \"us-ascii\") NIL NIL
\"quoted-printable\" 8 2 NIL NIL NIL NIL",
> +		.body > +			"\"text\" \"plain\"
(\"charset\" \"us-ascii\") NIL NIL
\"quoted-printable\" 8 2"
>  	},{
>  		.message >  			"From: user at domain.org\n"
> --
> 2.25.1

On 3. Mar 2020, at 20.38, Simon Ser <contact at emersion.fr>
wrote:
> 
> This causes the body structure to be incorrect. The RFC says it's fine
o
> have empty header field values.
The problem isn't empty header field. It's that the mail is missing
Mime-Version header. If that doesn't exist, then the Content-* headers can
be ignored. But because there are so many broken mails, Dovecot also allows it
to be missing as long as there is Content-Type header. Your test mail has
neither of these headers. It's arguable that Dovecot should parse Content-*
headers regardless of other headers, but I don't think the current code is
violating any RFCs.

On Tuesday, March 3, 2020 9:00 PM, Timo Sirainen <timo at sirainen.com>
wrote:
> On 3. Mar 2020, at 20.38, Simon Ser contact at emersion.fr wrote:
>
> > This causes the body structure to be incorrect. The RFC says it's
fine o
> > have empty header field values.
>
> The problem isn't empty header field. It's that the mail is missing
Mime-Version header. If that doesn't exist, then the Content-* headers can
be ignored. But because there are so many broken mails, Dovecot also allows it
to be missing as long as there is Content-Type header. Your test mail has
neither of these headers. It's arguable that Dovecot should parse Content-*
headers regardless of other headers, but I don't think the current code is
violating any RFCs.
Oh, sorry, I thought this caused by the empty header field.

The e-mail found in the wild doesn't have Mime-Version, so it would
probably be a good idea not to ignore Content-Transfer-Encoding indeed.