| Subject: | Embedded content in base64 encoded attachments |
We've had some occasional issues with corrupted attachments which turned
out to be due to the base64 encoded attachment data including some data
from one of the other parts of the message.
The attachment was specified by path, and is accessed over an NFS mount;
using ReadNow seemed to fix the problem (it wasn't a reliably
reproducible bug, so I can't be certain).
I think the problem may be due to the 45 byte read at
https://github.com/gitpan/MIME-Lite/blob/master/lib/MIME/Lite.pm#L2319
not getting all 45 bytes (an occasional NFS hiccup could explain the
non-reproducible nature) and then things lose the plot slightly. After
the other data is inserted in the base64 stream, the attachment data
picks up from where it has left off - ie the good file would have a line
like:
zgDJwFnw4Ca2Ka6TjlJFyhlhewgCFKLeEEYy9WCwhWiNlhopBRnIyPyAkbUVDUohr5FoaVlm0V/t
and the corresponding line for the corrupted attachment would start off
with:
zgDJwFnw4Ca
and then continue with a few lines of data that looks like it has come
from the html version of the message with non-base64 characters stripped
off (ie no spaces or angle brackets) as well as some other stuff I can't
place, and then this data ends and "2Ka6TjlJFyh" finishes off the
current line (which you'll notice is the next section from the good file
after the bad file stepped out of sync)
It's entirely possible I'm exceedingly incorrect and read() always
returns the requested number of bytes up until the end of the file, but
it seems like there's a reasonable chance that network mounts might lead
to things occasionally going a bit wrong.