Issue with UTF-8 in from.name in HTTP API injection

[wez (Wez Furlong)]

OK, so there are two things happening here:

1. our qp-encoder for rfc2047 header encoding produces header lines that exceed the LINE_TOO_LONG threshold by 2 characters, which causes check-fix to want to rewrite the message. Since the rewrite uses the same encoder, the resulting message will never pass that conformance check if you run it a second time, so the rebuild in that case is totally wasted effort

2. Due to a whitespace precedence issue in the header parser, that split display name doesn’t parse the second token out as UTF-8, which leads to the weird representation.

You can workaround this by adjusting the check_fix_conformance flags in the HTTP injection case to just add the missing headers: none of the body transformations should needed because the HTTP API uses the same building logic that the rebuilder uses, so they are all redundant:

  msg:check_fix_conformance(
    '',
    'MISSING_DATE_HEADER|MISSING_MESSAGE_ID_HEADER'
  )

However, I’ve pushed:

mailparsing: fix whitespace precedence issue with long mailbox headers

and

mailparsing: avoid flagging as LINE_TOO_LONG when rfc2047 header encoding

to tackle the root causes of those issues

[fhf]

Thanks Wez, this seems to have also fixed the issue with the blank PDF attachments.