From: p d. t. <pdo...@an...> - 2003-09-26 07:47:40
|
> Thanks for adding this hook. I've not got a lot of response from the > community on the questions I've asked which I guess is more of a reflection > on the audience that squirrelmail is directed for than anything else. I Not sure what questions those are, but if you're referring to SM developers, it is also probably a reflection of how busy everyone is (what with real lives and regular jobs on top of SM). It's not that we're not interested in your thoughts and ideas! > really appreciate you helping me out with this. I've got a number of mods > that I'm adding to my version of squirrelmail to help it work in my > environment and hopefully I'll be able to contribute these things back. Look forward to seeing what else you have up your sleeve! > That hook will definately help handle this specific problem but it also > allows mime extensions mentioned in the RFC so that in the future they can > be added. It's in CVS (1.5 and 1.4.2). (Thanks to Seth for the initial code.) It won't show up in anon CVS for at least another day, so if you want to play with it, the decodeBody function now looks like this: /* This function decodes the body depending on the encoding type. */ function decodeBody($body, $encoding) { global $show_html_default; $body = str_replace("\r\n", "\n", $body); $encoding = strtolower($encoding); $encoding_handler = do_hook_function('decode_body', $encoding); // plugins get first shot at decoding the body // if (!empty($encoding_handler) && function_exists($encoding_handler)) { $body = $encoding_handler('decode', $body); } else if ($encoding == 'quoted-printable' || $encoding == 'quoted_printable') { $body = quoted_printable_decode($body); while (ereg("=\n", $body)) { $body = ereg_replace ("=\n", '', $body); } } else if ($encoding == 'base64') { $body = base64_decode($body); } // All other encodings are returned raw. return $body; } So your plugin should do this in its setup.php: <?php function squirrelmail_plugin_init_your_plugin() { global $squirrelmail_plugin_hooks; $squirrelmail_plugin_hooks['decode_body']['your_plugin'] = 'check_encoding'; } function check_encoding($encoding) { include_once(SM_PATH . 'plugins/your_plugin/functions.php'); return check_encoding_do($encoding); } function your_plugin_version() { return '1.0'; } ?> And in functions.php: <?php function check_encoding_do($encoding) { if ($encoding == 'x-uuencode') { return 'my_x_uuencode_handler'; } } function my_x_uuencode_handler($action, $body) { if ($action == 'decode') { // work your magic $body = .... } return $body; } ?> |
From: p d. t. <pdo...@an...> - 2003-09-26 12:12:53
|
Ryan, Here is the patch previously posted for uuencode (supposedly x-uuencode as well) on the web site. Can you please look over the difference between this and your code? It might be nice to have both of these taken care of in your plugin. Thanks, Paul --- mime.php Fri Sep 19 15:58:43 2003 +++ mime.php.orig Mon Jun 30 05:15:29 2003 @@ -535,19 +535,6 @@ } else if ($encoding == 'base64') { $body = base64_decode($body); - } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { - $encode = $body; - $b64chars='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012345678 9+/A'; - $encode = preg_replace("/^./m","",$encode); - $encode = preg_replace("/\n/m","",$encode); - for($i=0; $i<strlen($encode); $i++) { - if ($encode[$i] == '`') - $encode[$i] = ' '; - $encode[$i] = $b64chars[ord($encode[$i])-32]; - } - while(strlen($encode) % 4) - $encode .= "="; - $body=base64_decode($encode); } // All other encodings are returned raw. |
From: Ryan P L. <rp...@un...> - 2003-09-26 15:23:02
Attachments:
uudecode.php
|
Paul, The change that I made in the decodeBody function was just to add the : + } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { + $body = uudecode($body); part right before the else and then modified Seth's uudecode function so that it could deal with the base64'd uuencoded data. Attached is what I currently have. I haven't found a mailreader that I can test the base64 uuencode format so i've only tested with normal uuencode and base64'd uuencoded data. Thanks, Ryan On Fri, Sep 26, 2003 at 05:12:37AM -0700, p dont think wrote: > Ryan, > > Here is the patch previously posted for uuencode (supposedly x-uuencode > as well) on the web site. Can you please look over the difference > between this and your code? It might be nice to have both of these > taken care of in your plugin. > > Thanks, > > Paul > > > > --- mime.php Fri Sep 19 15:58:43 2003 > +++ mime.php.orig Mon Jun 30 05:15:29 2003 > @@ -535,19 +535,6 @@ > > } else if ($encoding == 'base64') { > $body = base64_decode($body); > - } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { > - $encode = $body; > - > $b64chars='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012345678 > 9+/A'; > - $encode = preg_replace("/^./m","",$encode); > - $encode = preg_replace("/\n/m","",$encode); > - for($i=0; $i<strlen($encode); $i++) { > - if ($encode[$i] == '`') > - $encode[$i] = ' '; > - $encode[$i] = $b64chars[ord($encode[$i])-32]; > - } > - while(strlen($encode) % 4) > - $encode .= "="; > - $body=base64_decode($encode); > } > > // All other encodings are returned raw. > > -- ************************* Ryan Linn Information Technology Systems Programmer NC State University rya...@nc... ************************* |
From: p d. t. <pdo...@an...> - 2003-09-26 20:18:24
|
> The change that I made in the decodeBody function was just to add the : > > + } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { > + $body = uudecode($body); > > part right before the else and then modified Seth's uudecode function so > that it could deal with the base64'd uuencoded data. Attached is what I > currently have. I haven't found a mailreader that I can test the base64 > uuencode format so i've only tested with normal uuencode and base64'd > uuencoded data. Uhhh, right, but the whole idea was to pull it out into a plugin hook that would allow other decoders to be added as necessary. Where are we miscommunicating? - paul |
From: Ryan P L. <rp...@un...> - 2003-09-26 21:04:21
|
Sorry, I misunderstood which patch you were referring to. The one that he posted to the list for the hook was fine. I didn't make any changes to that. I thought that you were refering to patch 809454 in the patch tracker. There were no changes that i made to the hook code he did. -Ryan On Fri, Sep 26, 2003 at 01:17:07PM -0700, p dont think wrote: > > Uhhh, right, but the whole idea was to pull it out into a plugin hook > that would allow other decoders to be added as necessary. Where are we > miscommunicating? > > - paul > > |
From: p d. t. <pdo...@an...> - 2003-09-26 23:56:42
|
> > > The change that I made in the decodeBody function was just to add > the : > > > > > > + } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { > > > + $body = uudecode($body); > > > > > > part right before the else and then modified Seth's uudecode function > > so > > > that it could deal with the base64'd uuencoded data. Attached is what > > I > > > currently have. I haven't found a mailreader that I can test the > > base64 > > > uuencode format so i've only tested with normal uuencode and base64'd > > > uuencoded data. > > > > On Fri, Sep 26, 2003 at 01:17:07PM -0700, p dont think wrote: > > > > Uhhh, right, but the whole idea was to pull it out into a plugin hook > > that would allow other decoders to be added as necessary. Where are we > > miscommunicating? > > > I misunderstood which patch you were referring to. The one that he > posted to the list for the hook was fine. I didn't make any changes to > that. I thought that you were refering to patch 809454 in the patch > tracker. There were no changes that i made to the hook code he did. > -Ryan But the code you listed above (let's all try not to top post ;>) is, as you said, the code for the decodeBody() function in functions/mime.php. If you changed it as you did above, that's how you can achieve the same thing as the new hook, without the need for the new hook. Are you telling us that: - the code snippet above was what you had done before you had the hook available and this is in fact no longer needed - that patch 809454 was submitted by Seth (there's no name on it) - that patch 809454 is what you adapted for your needs, and it is this code that should now be part of a plugin (which it looks like Seth has already taken care of) ? Thanks, paul |
From: Seth R. <se...@mi...> - 2003-09-26 14:45:22
|
For what it's worth, I was going to add the functionality to the get_uuencode plugin. It isn't that big a change to add support for x-uuencode as well. Seth. p dont think said: > Ryan, > > Here is the patch previously posted for uuencode (supposedly x-uuencode > as well) on the web site. Can you please look over the difference > between this and your code? It might be nice to have both of these > taken care of in your plugin. > > Thanks, > > Paul > > > > --- mime.php Fri Sep 19 15:58:43 2003 > +++ mime.php.orig Mon Jun 30 05:15:29 2003 > @@ -535,19 +535,6 @@ > > } else if ($encoding == 'base64') { > $body = base64_decode($body); > - } elseif ($encoding == 'x-uuencode' || $encoding == 'uuencode') { > - $encode = $body; > - > $b64chars='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz012345678 > 9+/A'; > - $encode = preg_replace("/^./m","",$encode); > - $encode = preg_replace("/\n/m","",$encode); > - for($i=0; $i<strlen($encode); $i++) { > - if ($encode[$i] == '`') > - $encode[$i] = ' '; > - $encode[$i] = $b64chars[ord($encode[$i])-32]; > - } > - while(strlen($encode) % 4) > - $encode .= "="; > - $body=base64_decode($encode); > } > > // All other encodings are returned raw. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139 > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > -- Seth Randall IT Support Specialist Missoula Federal Credit Union se...@mi... |
From: p d. t. <pdo...@an...> - 2003-09-26 20:20:49
|
> For what it's worth, I was going to add the functionality to the > get_uuencode plugin. It isn't that big a change to add support for > x-uuencode as well. sigh. Actually, I'd like to hear from you, Seth as to what exactly that plugin does. A quick look suggests that it uses the message body hook to decode uuencoded bodies (?), as well as add a link to the bottom of the message view to download it to the local machine (?). If you are already decoding on the fly, then there would be no need for the hook we've been discussing. Either way, it probably makes sense to wrap all this up into your plugin once we straighten things out. - paul |
From: Seth R. <se...@mi...> - 2003-09-26 20:31:22
|
My plugin didn't originally handle attachements. Only uuencoded text directly in the message body. Now it should handle both (assuming the attachment is of type x-uuencode). Seth. p dont think said: >> For what it's worth, I was going to add the functionality to the >> get_uuencode plugin. It isn't that big a change to add support for >> x-uuencode as well. > > sigh. > > Actually, I'd like to hear from you, Seth as to what exactly that plugin > does. A quick look suggests that it uses the message body hook to > decode uuencoded bodies (?), as well as add a link to the bottom of the > message view to download it to the local machine (?). If you are > already decoding on the fly, then there would be no need for the hook > we've been discussing. > > Either way, it probably makes sense to wrap all this up into your plugin > once we straighten things out. > > - paul > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139 > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > -- Seth Randall IT Support Specialist Missoula Federal Credit Union se...@mi... |
From: p d. t. <pdo...@an...> - 2003-09-26 23:41:28
|
> p dont think said: > >> For what it's worth, I was going to add the functionality to the > >> get_uuencode plugin. It isn't that big a change to add support for > >> x-uuencode as well. > > > > sigh. > > > > Actually, I'd like to hear from you, Seth as to what exactly that plugin > > does. A quick look suggests that it uses the message body hook to > > decode uuencoded bodies (?), as well as add a link to the bottom of the > > message view to download it to the local machine (?). If you are > > already decoding on the fly, then there would be no need for the hook > > we've been discussing. > > > > Either way, it probably makes sense to wrap all this up into your plugin > > once we straighten things out. > My plugin didn't originally handle attachements. Only uuencoded text > directly in the message body. Now it should handle both (assuming the > attachment is of type x-uuencode). > > Seth. So then what is the get_uuencode_link() functionality for? Does it place a link at the bottom of the message view for you to download the message body itself? What is the need for that? Thanks, paul |
From: Seth R. <se...@mi...> - 2003-09-26 23:46:50
|
If you have three uuencoded documents pasted directly into the message body, it will provide links for all three of them. Seth. p dont think said: >> p dont think said: >> >> For what it's worth, I was going to add the functionality to the >> >> get_uuencode plugin. It isn't that big a change to add support for >> >> x-uuencode as well. >> > >> > sigh. >> > >> > Actually, I'd like to hear from you, Seth as to what exactly that > plugin >> > does. A quick look suggests that it uses the message body hook to >> > decode uuencoded bodies (?), as well as add a link to the bottom of > the >> > message view to download it to the local machine (?). If you are >> > already decoding on the fly, then there would be no need for the > hook >> > we've been discussing. >> > >> > Either way, it probably makes sense to wrap all this up into your > plugin >> > once we straighten things out. > >> My plugin didn't originally handle attachements. Only uuencoded text >> directly in the message body. Now it should handle both (assuming the >> attachment is of type x-uuencode). >> >> Seth. > > So then what is the get_uuencode_link() functionality for? Does it > place a link at the bottom of the message view for you to download the > message body itself? What is the need for that? > > Thanks, > > paul > -- Seth Randall IT Support Specialist Missoula Federal Credit Union se...@mi... |
From: p d. t. <pdo...@an...> - 2003-09-27 00:57:21
|
> p dont think said: > >> My plugin didn't originally handle attachements. Only uuencoded text > directly in the message body. > > > > According to the plugin descriptions: "Download uuencoded files" > (short) "Creates a simple link that allows you do download a uuencoded > file." (long) > > > > That seems antithetical to what you are saying the plugin does (did). > > > >> Now it should handle both (assuming the > >> attachment is of type x-uuencode). > > > > So then the plugin description would now seem more applicable. Although > I would suggest reviewing and updating the whole description, so that > it's clear that the plugin helps properly decode messages (message > bodies) AND attachments (not the more ambiguous "file" in your current > description) that are uuencoded. > I've updated the description to be more accurate. The plugin actually now > works for both MIME attached files the use x-uuencode and it also works > for messages with the UUEncoded file as part of the actual message body. > That's why it uses the message body hook. > > Seth. Thanks for all your effort, Seth! - paul |
From: p d. t. <pdo...@an...> - 2003-09-26 23:44:54
|
> My plugin didn't originally handle attachements. Only uuencoded text > directly in the message body. According to the plugin descriptions: "Download uuencoded files" (short) "Creates a simple link that allows you do download a uuencoded file." (long) That seems antithetical to what you are saying the plugin does (did). > Now it should handle both (assuming the > attachment is of type x-uuencode). So then the plugin description would now seem more applicable. Although I would suggest reviewing and updating the whole description, so that it's clear that the plugin helps properly decode messages (message bodies) AND attachments (not the more ambiguous "file" in your current description) that are uuencoded. Thanks - paul |
From: Ryan P L. <rp...@un...> - 2003-09-26 21:13:09
|
Here was the main issue that lead to this entire discussion: If you have an attachment with an encoding style other than quoted or base64 squirrelmail throws you back something other than what you're expecting. There was no way to extend the encoding support within the code itself and there doesn't appear to be away to extend encoding (until this hook). So for instance, if I had a new encoding type ( I don't ) that was labeled "x-garbage" and I encoded something with it and sent it to a user, the user would see the download link at the bottom of SM and assume that when they hit DL that their attachment would come back out like it was sent. What would actually come out is whatever encoded data the person was sent. Under most browsers with an "open" button once you download, when you hit open its going to tell you that your file is corrupt or something else because your MS word document is actually still encoded. What the additional hook gives us is that we can handle the different encoding styles as they come out, expecially the extended (x-whatever) encoding schemes as different mailers come out with them, which should hopefully be rarely but it won't require changes to the core code. I'm glad that Seth added this functionality to his plugin because his plugin has great functionality, but without the hook there was no way for it to happen before (at least that I could find). I apologize for frustrating you trying to figure this out, I know that you have much more to do than deal with this. With the patch that Seth posted to the list along with the hook that he wrote as part of the "get_uuencode" attachment everthing will work great and SM will also be extensible in the future when other odd encoding types come up. Thanks to all for their help in this. On Fri, Sep 26, 2003 at 01:20:13PM -0700, p dont think wrote: > > For what it's worth, I was going to add the functionality to the > > get_uuencode plugin. It isn't that big a change to add support for > > x-uuencode as well. > > sigh. > > Actually, I'd like to hear from you, Seth as to what exactly that plugin > does. A quick look suggests that it uses the message body hook to > decode uuencoded bodies (?), as well as add a link to the bottom of the > message view to download it to the local machine (?). If you are > already decoding on the fly, then there would be no need for the hook > we've been discussing. > > Either way, it probably makes sense to wrap all this up into your plugin > once we straighten things out. > > - paul > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139 > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > -- ************************* Ryan Linn Information Technology Systems Programmer NC State University rya...@nc... ************************* |
From: p d. t. <pdo...@an...> - 2003-09-26 23:58:02
|
> Here was the main issue that lead to this entire discussion: If you have > an attachment with an encoding style other than quoted or base64 > squirrelmail throws you back something other than what you're expecting. > There was no way to extend the encoding support within the code itself and > there doesn't appear to be away to extend encoding (until this hook). So > for instance, if I had a new encoding type ( I don't ) that was labeled > "x-garbage" and I encoded something with it and sent it to a user, the > user would see the download link at the bottom of SM and assume that when > they hit DL that their attachment would come back out like it was sent. > What would actually come out is whatever encoded data the person was sent. > Under most browsers with an "open" button once you download, when you hit > open its going to tell you that your file is corrupt or something else > because your MS word document is actually still encoded. We are on the same page here. > What the additional hook gives us is that we can handle the different > encoding styles as they come out, expecially the extended (x-whatever) > encoding schemes as different mailers come out with them, which should > hopefully be rarely but it won't require changes to the core code. I'm > glad that Seth added this functionality to his plugin because his plugin > has great functionality, but without the hook there was no way for it to > happen before (at least that I could find). > > I apologize for frustrating you trying to figure this out, I know that > you have much more to do than deal with this. With the patch that Seth > posted to the list along with the hook that he wrote as part of the > "get_uuencode" attachment everthing will work great and SM will also be > extensible in the future when other odd encoding types come up. Thanks to > all for their help in this. The only reason for my frustration is that I'm trying to do too many things at once and not putting my whole mind into this. There is no reason for you to apologize. In fact, I really appreciate your willingness to help get this into SM; as do many people in the user community. Same goes for Seth. That said, part of the confusion for me (not having any uuencoded messages to work with) was due to the fact that the decodeBody() function in mime.php is also called when the message body itself is being decoded. The get_uuencode plugin seems to have been cleverly coded to make use of another hook, since there was no other way to do it, but what I'm now wondering is if the plugin shouldn't be reworked to use the new hook instead. In fact, I wonder if the message_body hook can be eliminated with some small changes to the new hook, since the two are very similar, and called close to one another... although they do ostensibly serve slightly different purposes. Thoughts? Thanks, Paul |
From: Seth R. <se...@mi...> - 2003-09-26 20:23:49
|
I've just uploaded a new version of the get_uuencode plugin with support for the new decoding patch. Seth. Seth Randall said: > For what it's worth, I was going to add the functionality to the > get_uuencode plugin. It isn't that big a change to add support for > x-uuencode as well. > > Seth. > p dont think said: >> Ryan, >> >> Here is the patch previously posted for uuencode (supposedly x-uuencode >> as well) on the web site. Can you please look over the difference >> between this and your code? It might be nice to have both of these >> taken care of in your plugin. >> >> Thanks, >> >> Paul >> >> >> >> > > -- Seth Randall IT Support Specialist Missoula Federal Credit Union se...@mi... |