If an email is sent with a single media-type part (eg. an image), rather than as a multipart email with an image attachement, then the single part fails to be imported.
What happens is MailhandlerPhpImapRetrieve::get_parts has the default part_number as FALSE, so when there is a single part, it pulls the entire message text including headers, and in my case attempts to base64 decode that (the content of the mail is base64 encoded, and this is recognised correctly from headers). the decoded data comes out as empty (the headers in the stream cause the data to be invalid base64 data), and I get a zero-byte file created. I haven't tested what happens to single-part text emails, but i suspect that it works better than base64 encoded data (you might get extra headers included in the final data or something, but text would probably survive).
I'm attaching an example mail to this issue to reproduce the issue. Headers will need customization in order to use it in testing. I have a patch for this and will attach shortly.
See http://www.ietf.org/rfc/rfc1730.txt section 6.4.5, which mentions single part emails as valid. The only part number in that case is "1".
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | mailhandler-1555792-4.patch | 1.18 KB | danepowell |
| #1 | mailhandler-single-part.patch | 1.07 KB | alan evans |
| examplemail.txt | 24.55 KB | alan evans |
Comments
Comment #1
alan evans commentedComment #2
danepowell commentedThanks for the patch. Will test when I can. Marked #1396976: Image attachments not working when body is empty as dupe.
Comment #4
danepowell commentedHere is #1 rolled against HEAD, so it has a better chance of passing testing.
Comment #5
danepowell commentedFixed in 6.x-2.x and 7.x-2.x
http://drupalcode.org/project/mailhandler.git/commit/8dd9119
http://drupalcode.org/project/mailhandler.git/commit/5756410
Comment #6
alan evans commentedBrilliant, thanks!
Comment #8
danepowell commentedTurns out that this is probably not the right way to solve this problem- it caused the following regression: #1597384: File attachments have zero bytes Thus, I have reverted the fixes in #5.
The problem seems to be that for multipart messages with only two parts (a text body and HTML body), the parts are indexed as "1" and "2". However, with the change in #5, get_parts adds a prefix and tries to access them as "1.1" "1.2", which fails and throws a 'No Data!!' error.
Comment #9
danepowell commentedAlso, oddly, even with the fix in #5 reverted, the single-part simpletest is still passing. So it would seem that that test is broken.
Comment #10
danepowell commentedOkay, I've figured out part of the problem- in #5, I actually committed something different than what's in patch #4, which has quite a different effect.
So, can you please confirm that this is still a problem with the latest dev release? If so, then I just need to apply #4 as-is (as long as it doesn't cause a regression, e.g. #1597384: File attachments have zero bytes).
Comment #11
danepowell commentedOkay- I've just committed some major changes to how messages are retrieved. I would appreciate if you would try the 7.x-2.x-dev version that rolls tonight and let me know if this is still a problem. Otherwise, I will assume this is fixed. Thanks.
Comment #12
alan evans commentedJust checked this on the latest 7.x-2.x from git and it seems to be working well using both the example single-part mail here as well as a standard email with an attached photo. Thanks!
Comment #13
danepowell commentedGlad to hear it.
Comment #14
foxtrotcharlie commentedI was also having the same issue but with version 6.x-2.5. The email attachment (an image) was not being shown in the content type (mapped to a cck image field) after importing and I was getting the "No Data!!" message in watchdog.
Upgrading to the latest dev (currently 6.x-2.5+19-dev) fixed the issue for me, thanks :-)