IN api FOLDER THIS PATCH FIXES EMBEDDED IMAGES AS ATTACHMENTS FROM OUTLOOK 2007

The normal attachment logic looks for “disposition” and then tests it and ctype.

THIS IS NOT ELLEGANT, not configurable in present form, and will not filter small images which would likely be signature images or backgrounds.

But hopefully it will start someone on the right track. Maybe I’ll improve it later.

--- pipe.php.ORIGINAL Thu Mar 4 23 2010

+++ pipe.php Fri Mar 5 01 2010

@@ -125,6 +125,13 @@

if($filename && $cfg->canUploadFileType($filename)) {

$ticket->saveAttachment($filename,$part->body,$msgid,'M');

}

+//THIS PATCH ADDS THE ABILITY TO SAVE EMBEDDED IMAGES IN AN HTML EMAIL FROM OUTLOOK 2007

+ } elseif (!($part->disposition)

+ && (!strcasecmp($part->ctype_primary,'image')) ) {

+ $filename=$part->ctype_parameters;

+ if($filename && $cfg->canUploadFileType($filename)) {

+ $ticket->saveAttachment($filename,$part->body,$msgid,'M');

+ }

}

}

}

2 months later

Hey Mitch,

Thanks for the updated code. Not sure if you've got any ideas.. but here goes.. I've got some emails that come in that don't have a filename or disposition.. The inline/embedded images are screenshots.. which have no native filename.. and neither the stock code, nor your update, seem to recognize these images..

I've looked it over but can't seem to figure out what needs to be changed in order for the decoding to find these images and extract them as attachments.. Any ideas?.. (below is an example)..

--=_alternative 007FAD2E0A25771F_=--

--=_related 007FAD2E0A25771F_=

Content-Type: image/gif

Content-ID: <_1_06A0F21006A0D880007FAD2E0A25771F>

Content-Transfer-Encoding: base64

R0lGODlhAAQAA+cAAP///+jo2AAAAICAgPDw6PDw8PDo4NDQyOjo0Ojo4NjY2GCYyDiA8HiY4Ojg

0ICo6JiYmPDo2HiQ2HiQ4KiomNjQuMDQ+HiY2HiYuNjYyHig4PDw4Ojo6Ojw6PCoMHBoYNjg+ODg

0NjYwDh48ICg6ODgyMjIuDB44BhQuEBAQMDAwICg4NDQwDhwuDCA4DCI6JCQgJiw6NjQwLi4sJi4

6MjIyDBo0DiI6EiQ4BhAoBhQwCBY2ACAgAAAgLDI+MjY+Iio6ABYiLjI8CBg2MjQ+ECA8GCo2CBQ ...

Rich

You might try making it simpler

+//THIS PATCH ADDS THE ABILITY TO SAVE EMBEDDED IMAGES IN AN HTML EMAIL FROM OUTLOOK 2007

+//This just looks for ANY IMAGE

+ } elseif (!strcasecmp($part->ctype_primary,'image')) {

+ //$filename=$part->ctype_parameters;

+ //Assign a name?

+ $filename='NoName';

+ if($filename && $cfg->canUploadFileType($filename)) {

+ $ticket->saveAttachment($filename,$part->body,$msgid,'M');

+ }

You might need to tweak this. You might want to add some filter - on file size for example. Otherwise you will end up with what I did... every little signature icon being attached as an image. This is not tested.

Cheers.

10 days later

Hey Mitch..

Thanks for the new code.. I'm so close, I can taste it!... I believe I just found out what the problem was/is. I went into the Attachment settings of the OST config and enabled ".*" for the acceptable file types (just for the one test). Here's what I found..

The image attachment came through into the ticket as "ATT_3.dat" (and ATT_4, 5, 6 for additional attachments, if any), regardless of the mime type of the attached file. The files are intact as I can download them, change their extension (from .dat to what I know it should be) and they're viewable.

I'm not sure where/how the file name was generated, as it didn't use the "NoName" nomenclature which means that it didn't get caught by your function, but by a previous function. I'm not sure that this name is even being generated by the pipe.php.

Any other ideas Mitch? .. (or anyone else)

Thanks again!

Rich

Could be generated by whatever makes the email...

You likely have to have the proper file name for the web server to serve the right content type... two options, one is to associate the extension with the proper mime type, the other would be to detect the file name and rename it. Hard for me to guess when I can't see the message. You can probably run the pipe.php from a command shell to debug it - that would allow you to echo some debug information - or you could use the error_log function to throw it to a tmp file...

Something like:

error_log(print_r($someobject,TRUE)."\n",3,'/tmp/yourlog.txt');

Should help you understand what you are getting... the output will tell you more about the structure of the variable you dump to the log while the program runs.

18 days later

First.. I'm not able to figure out which process is having the problem with the inline images.. I'm not sure if it's an OSTicket PHP script that's the issue or if it's a PEAR problem..

I found a new piece of weirdness..

My attachments are still doing the ATT_3(or 4, 5, 6).dat thing.. when I'm using IMAP to fetch the email. When I switched it to POP fetching for that account, it didn't return the attachment for the inline image at all.

So, any ideas?.. I'm digging through the PEAR mail extensions now to see if I can figure it out, but so far nothing sticks out..

Rich

4 days later
20 days later

no inline attachments being detached

Please can you help ?

I've tried adding your code to pipe.php but I still get nothing in osticket about my inline images...

Would it be possible to attach a copy of your "working" pipe.php file so I can compare to my own ?

Thanks.

Imap

Hi everyone

Does anyone have a working example with IMAP?

Best regards Laurits

10 days later

bump

bump....

Anyone got this working and is willing to share ?

Thanks in advance... Steve

Anybody willing to share indeed? I think this "patch" could be applied to class.mailfetch.php too since that one also needs to attach images somehow, but it doesnt right now... I'll have a look into this.

I just noticed that the original 1.6 ST does handle inline images when using IMAP to receive mail.

It does work when sent from Outlook but not when sent from Outlook Express! Because Outlook Express doesn't use Content-Disposition: inline;

It does indeed happen because stupid outlook express doesn't use a content-disposition, that's the one thing osTicket checks for when attaching an attachment.

Okay I have a ("dirty") fix for inline attachments sent using Outlook Express. This only applies for those that let osTicket fetch mail via IMAP or POP3:

Replace the saveAttachments function within class.mailfetch.php with this one:

function saveAttachments($ticket,$mid,$part,$index=0) {

global $cfg;

// Default disposition attachments

if($part && $part->ifdparameters && ($filename=$part->dparameters->value)){ //attachment

$index=$index?$index;

if($ticket && $cfg->canUploadFileType($filename) && $cfg->getMaxFileSize()>=$part->bytes) {

//extract the attachments...and do the magic.

$data=$this->decode($part->encoding, imap_fetchbody($this->mbox,$mid,$index));

$ticket->saveAttachment($filename,$data,$ticket->getLastMsgId(),'M');

return;

}

//TODO: Log failure??

}

// Bugfix for that crappy Outlook Express (and others?) that ignore Content-Disposition :(

elseif ($part && $part->ifparameters && $part->type == 5 && $part->encoding == 3) {

$filename = 'Attachment_'.$index;

// Lets get the right attachment name

foreach ($part->parameters as $parameter) {

if (strtoupper($parameter->attribute) == 'NAME') {

$filename = $parameter->value;

}

}

// Quote: do some maginc

$data = $this->decode($part->encoding, imap_fetchbody($this->mbox,$mid,$index));

$ticket->saveAttachment($filename,$data,$ticket->getLastMsgId(),'M');

return;

}

//Recursive attachment search!

if($part && $part->parts) {

foreach($part->parts as $k=>$struct) {

if($index) $prefix = $index.'.';

$this->saveAttachments($ticket,$mid,$struct,$prefix.($k+1));

}

}

}This works for me, it might just work for you too :)

UPDATE

I've updated the function because it didn't catch the right name from inline attachments sent with Incredimail (let's face it, people who are using incredimail also need support )

A reply - my faith in forums has been restored

I was beginning to think I was invisible ;)

Sadly I use the piping method so as you say, this won't work for me..

(Grrrr is only I knew php, as so many others seem to - RTFM time for me!)

How do you use piping? If you could tell me that, I could check this out and create a (temporary, untill they fix it themselves) fix for that too.

I've updated my "fixed" function in post (#12) to support attachments send with Incredimail.

piping emails

@[deleted] - I followed the instructions in the wiki (http://osticket.com/wiki/Email_Piping(http://osticket.com/wiki/Email_Piping)) and use procmail for the filtering...

So in the SCP admin panel, I have the "enable email piping" box checked

In my procmailrc file, I have the following

* ^TOemail@notrealdomain.com

* !^From.*root@localhost.localdomain

* !^Subject:.*\

| /etc/smrsh/pipe.php

( /etc/smrsh/pipe.php is a symbolic link to /var/www/html/osticket/api/pipe.php - before doing this I'd get an smrsh error)

AFAIK emails which successfully pass through the filter (procmail) are piped into "pipe.php"

Thanks in advance for any help you can offer...

Cheers, Steve

In fact, looking at the pipe.php code, the code provided in the first post of this thread could work. Although I'm unable to test this...

pipe.php

Sadly, it's not working for me.... Normal attachments (including images) do work !

When I check the user account that receives the emails (before procmail pipes it into osticket) the inline image is "attached" in the mbox email (see attached zip file for screenshot of this email with "attached"/"inline" GIF)

Sadly, it doesn't get piped into osticket !

I've also attached the raw email - I've seen "headers" mentioned a lot so thought this might be useful ?

I've also attached my pipe.php which has the modification from ...

All attachments are in the 1 zip file.

Please let me know if you spot any obvious mistakes.

or need any other info....

Thanks in advance again....

Cheers,

Steve

[pipe_info.zip](https://forum.osticket.com/assets/files/migrated/c/b17d56cdbcc2dd1b97dc94e0d4df453.zip)

22 days later

Hi

The code from post #12 works great... to a degree. The code actually, only works for inline attachments when there also is a normal attachment. ie the "attachment triggering thingy" does not work when there only is an inline (embedded) attachment.

Witch part of this code needs to be changed to accommodate this effect?

//Save attachments if any.

if($msgid && $cfg->allowEmailAttachments()){

if(($struct = imap_fetchstructure($this->mbox,$mid)) && $struct->parts) {

if($ticket->getLastMsgId()!=$msgid)

$ticket->setLastMsgId($msgid);

$this->saveAttachments($ticket,$mid,$struct);

}

}

Hi

The code from post #12 works great... to a degree. The code actually, only works for inline attachments when there also is a normal attachment. ie the "attachment triggering thingy" does not work when there only is an inline (embedded) attachment.

I have to disagree, since on my install it also saves inline images/attachments when there aren't any "normal" attachements attached.

The saveAttachments method is called when there are multiple message id's/parts, see //Save attachments if any.

if($msgid && $cfg->allowEmailAttachments()){

if(($struct = imap_fetchstructure($this->mbox,$mid)) && $struct->parts) {

if($ticket->getLastMsgId()!=$msgid)

$ticket->setLastMsgId($msgid);

$this->saveAttachments($ticket,$mid,$struct);

}

}

Just to be sure, I've just tested this by sending an email using Outlook and pasted an image in the text (inline attachment):

blank blank

()