Taking a look at the RFC, my explanation is incorrect. Separators lines are defined as two dashes followed by the separator. Looking closer at the message, it appears that the message separates lines by /n instead of the required /r/n characters. I know that the mail gem has a bit of code to recover in many cases for this problem in mail headers, but apparently not for this case in the mail body.
- Sam Ruby On Mon, Nov 5, 2018 at 8:45 PM Sam Ruby <ru...@intertwingly.net> wrote: > > The answer I'm about to give is not likely to be very enlightening. > > That particular message, when parsed by the Ruby mail gem, has no attachments. > > https://whimsy.apache.org/secretary/workbench/201811/f19c4032c4/ > > If you look at the raw version of the message, you will see > boundary="----=_NextPart_5BE02944_0A60A880_294A6503". If you look a > few lines later, you will see > "------=_NextPart_5BE02944_0A60A880_294A6503". Note that the boundary > has FOUR leading dashes, and the line itself has SIX. > > The mail gem does not consider this a match, so it doesn't identify > any attachments. > > I don't know enough about the relevant RFCs to know whether this is a > malformed message (which some mail readers may compensate for), or if > it is RFC compliant message that isn't parsed correctly by the mail > gem. > > - Sam Ruby
