Description
I sporadically had trouble extracting attachments from some received mails, which when checked do work in GMail. After analysis, I traced it down to extraneous whitespace in the Content-Disposition header of the attachment part.
Specifically, the following headers:
--boundarystring
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename = "file.pdf"
[base64 data]
fail with the follow parse error:
#<Mail::Field::IncompleteParseError: Mail::ContentDispositionElement can not parse |attachment; filename = "file.pdf"|: Only able to parse up to "attachment; filename">
removing the extraneous whitespace around the = character:
--boundarystring
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="file.pdf"
[base64 data]
works as expected.
Both cases work as expected in GMail.
I've checked RFC 2183 and RFC 822, and it is not entirely clear to me whether this white-space is legal (RFC 822 section 3.1.4 does say "free insertion of linear-white-space (which permits folding by inclusion of CRLFs) is allowed between lexical tokens." but I do not know if that applies here).
Regardless of standards conformance, there is probably no downside to being slightly more lenient here and allow the spaces.
Probably somewhat related: #200