mailmime_parse() parses the mail unexpectly

[dafanz]

The mailmime_parse() function in the master branch parses the following mail unexpectly:

From: AAA <aaa@example.com>
To: BBB <bbb@example.com>,
 CCC <ccc@example.com>
References: <msg-id-aaa@example.com>
	
 <msg-i
 d-bbb@example.com>
Message-ID: <msg-id-ccc@example.com>

A test mail

Here is the code to parse the mail:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <libetpan.h>

int main()
{
  int mail_file = -1;
  struct stat mail_file_stat;
  size_t index = 0;
  char *mail = NULL;
  struct mailmime *mime = NULL;

  mail_file = open("test-mail.eml", O_RDONLY);
  fstat(mail_file, &mail_file_stat);
  mail = mmap(NULL, (size_t)mail_file_stat.st_size, PROT_READ, MAP_PRIVATE, mail_file, 0);

  mailmime_parse(mail, (size_t)mail_file_stat.st_size, &index, &mime);
  printf("Header length: %ld\n", mime->mm_data.mm_message.mm_msg_mime->mm_body->dt_data.dt_text.dt_data - mail);

  mailmime_free(mime);
  munmap(mail, (size_t)mail_file_stat.st_size);
  close(mail_file);

  return 0;
}

Compile and output:

$ gcc -o etpan-test -letpan etpan-test.c
$ ./etpan-test
Header length: 121

libetpan marks the end of the 5th line as the end of the header.

libetpan will parse the header correctly with any of the changes below:

• the 4th line is deleted
• the 5th line is deleted
• the 6th and the 7th lines are deleted
• the 6th and the 7th lines are unfolded into a single line

The 5th line contains only a TAB. It is an obsolete syntax in RFC 5322, section 4.2, but the section 4 of the same RFC also says that "they MUST be accepted and parsed by a conformant receiver", so it should be considered as a Bug of libetpan.

[dafanz]

The function mailimf_fws_parse() does not support obs-FWS, which is defined in RFC5322, section 3.2.2.

For the example in #431, when msg-id-aaa@example.com is parsed and mailimf_fws_parse() is called after that, it will set cur_token at the position of '\r' in the 5th line. This will cause problems in certain situations. The example in #431 triggers the problem because the message-id afterwards is invalid. Another examples which also trigger problems are that there is a "WSP CRLF" line in the To header field or there are more than three continuous "WSP CRLF" lines in the References header field (see below).

From: AAA <aaa@example.com>
To: BBB <bbb@example.com>,
	
 CCC <ccc@example.com>
References: <msg-id-aaa@example.com>
	
	
	
 <msg-id-bbb@example.com>
Message-ID: <msg-id-ccc@example.com>

A test mail

The bugfix here adds the support of obs-FWS and fixes all these problems.