Allow unnamed file attachments to be saved

I will check what is going on - unnamed attachments were not intended to be discarded, and there is (should be!) code inside to name them "unnamed_attachment" (I recall thinking once to make this a user definable name, but never got round to it).

I'll check the patch versus the mailsave code and check I didn't accidentally break something recently!

Thanks!

In _mailsave_use_mailhandler_attachments() only parts that have a filename are saved.

OK - I checked mailsave and simulated a blank file name, and I get the image being attached with the filename of unnamed_attachment. I'm processing with mailsave_to_image and I see the image fine on the page.

This line of mailsave

if ($mimepart->filename != MAILSAVE_UNNAMED_ATTACHMENT || ((strpos($mimepart->filemime, 'TEXT') === FALSE) && (strpos($mimepart->filemime, 'MULTIPART') === FALSE))) {

is designed to handle the unnamed case. The patch you have makes this test true for your messages since $mimepart->filename will never have the value MAILSAVE_UNNAMED_ATTACHMENT.

Because the attachment normally gets discarded that must mean the message isn't coming through as multipart mime, since we know $mimepart->filemime must be image since that is used to assign image.jpg as the filename in your patch!

Can you send me an AT&T test message to mailsave@stuartandnicola.com? That way I can pick it up and see a direct example. I am now trying to remember why I set the multipart test. I think it was because some messages that arrived as HTML but were NOT multipart got turned in to content PLUS an attachment, so the multipart test was designed to screen them out.

That said, I quite like the idea of mapping a few file types to be 'helpful' names like unnamed_image.jpg, unnamed_audio.mp3, so I think your patch has some inherent value, but I'd just like to understand a little better why the AT&T messages don't process properly without this change!

(NB - so far I have found no easy way to get filenames out of Content-Location as the PHP mime handlers don't pick it up, but if someone knows of a way...)

In _mailsave_use_mailhandler_attachments() only parts that have a filename are saved.

LOL - we are obviously both here at drupal.org at the same time :)

And I just re-read the line code that is testing the attachments properly, and now I am puzzled!

_mailsave_use_mailhandler_attachments() will save unnamed files, but provided the mimepart being checked is NOT text, and is NOT mime type MULTIPART.

The filename is unnamed, we know that since the attachment is being skipped.
The filemime is IMAGE/JPEG, we know that as the mapping works (and the more I think about that the more I think it should be included!)

So the filemime is NOT TEXT, and is NOT MULTIPART, so the existing test should pass and your attachment should be saved! Which is the result I get locally?!

One more request for info - are you using any mailsave extensions (mailsave to image etc) or clean up filters - the unnamed file could be being discarded elsewhere later in the process.

_mailsave_use_mailhandler_attachments() is actually a bit of legacy code - mailhandler never used to get attachments so mailsave did it itself. When mailhandler gained attachment capability I stripped the code out, but kept this function as a fix that simply rearranges the mailhandler format to "old" mailsave style (this avoided me re-writing all the handlers which I didn't have time to do and have never got back to!)

Sorry, I jumped to an incorrect conclusion above! I had tried to implement a cleanup hook with some debug code looking at the $node structure, but apparently I cannot print out the $node structure past the point where the binary file data appears in the $node object in $node->mimeparts. The file I was looking for actually was in $node->mailsave_attachments all along...

The actual problem is, an unnamed file fails to attach if you're relying on upload module, which won't attach a file without a file extension. If you still want this code it could also go in _mailsave_save_files(), see the attached patch where I moved it around a bit. Or it could go in a mailsave_clean hook.

Thanks for test message - yes - this looks like a bug. If I run your message with mailsave_to_image active then the image appears as intended, but if I run it without mailsave_to_image then I can repeat this issue and I get no attachment.

The proper fix is to work out how to get the filename out of the Content-Location, but I tried this once before and couldn't do it. The fallback of mime type -> file name mapping looks like the best way to go in the meantime, I just need to figure out the best place to implement it.

I was wondering if the inaccessible Content-Location header is a bug in PHP imap, or maybe the underlying c-client library?

I do know from previous experience that PEAR Mail_mimeDecode can provide you the Content-Location header (I used it to receive MMS messages on another site not using Drupal or PHP imap).

By the way I also had this problem with so-called "unnamed" inline-attached files not being recognized by imagefield.

Since this problem also cropped up with mailsave_to_imagefield I moved it into _mailsave_use_mailhandler_attachments().

Also there was a problem with always using the same file name for each inline attachment -- not a good idea when there are hundreds of files with the same name, and drupal has to use its sequential numbering scheme for generating unique file names. I added some code to generate unique file names using uniqid() and mt_rand() functions.