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