Support (offered by community volunteers) > Using IMAP2SOAP

uu-encoding message body_strings

(1/1)

fen:
A question related to: http://forum.civicrm.org/index.php/topic,2340.0.html (reply messages are "scrambled"):

When imap2soap.pl prepares the message body for sending to the CiviCRM $soapClient, it currently uses:

--- Code: ---my $body = SOAP::Data->type(string =>$imap->body_string($msg));

--- End code ---
If the body_string is MIME-encoded (as when international character sets are included) imap2soap.pl bombs out with

--- Code: ---Use of uninitialized value in concatenation (.) or string at ./imap2soap.pl line 146.
imap2soap: Fatal: SOAP: authenticate: , ()

--- End code ---
If I instead prepare the body_string with base46 as in

--- Code: ---my $body = SOAP::Data->type(base64 =>$imap->body_string($msg));

--- End code ---
it works fine.  Before I release this change to the wild, I'd like to know: will CiviCRM handle such encoded messages properly when the message is actually used (in my test cases, I don't handle replies)?

Thanks!
=Fen

Piotr Szotkowski:

--- Quote from: fen on November 17, 2008, 03:51:45 pm ---Before I release this change to the wild, I'd like to know: will CiviCRM handle such encoded messages properly when the message is actually used (in my test cases, I don't handle replies)?

--- End quote ---

As I replied to Fen previously, CiviMail cares about the body if the message in only two cases: replies and bounces.

Replies should be forwarded verbatim to the right address (configured when setting up a given mailing); there is currently an issue with how it works.

Bounces are scanned in hope of heuristically guessing the reason behind the bounce, but we assume most (all?) mailer daemons send plain (non-base64) emails when bouncing.

We’re open as for discussion on how CiviMail should work, of course.

fen:
imap2soap.pl was dying when sending an unencoded MIME body to CiviCRM via the SOAP channel.  I've installed and partially tested a fix (maybe a hack?) that fixes the problem on my systems, though I don't use the message body returned via the back-channel for anything, so I'm not sure this will work in all cases, and this is a known problem with some mailers (see e.g., http://issues.civicrm.org/jira/browse/CRM-2959).

Try the new version available from https://svn.civicactions.net/repos/civicrm/scripts/ and please post if you discover any issues.  There's a "Note:" at the top describing the change, which is on line #338.

fen:
I think that CiviCRM needs to be able to read and parse the envelope for information regarding bounces, etc. but I'm not sure if it should need to otherwise encode or decode messages sent to it - passing them through should be OK.  The "hack" above seems to work to the extent that CiviCRM can still determine the Bounce Type and Bounce Reason (from the headers?) and it no longer dies when encountering a MIME-encoded body with 8 or 16-bit characters, but I'm not sure if simply uu-encoding the entire message is a correct solution.

The new version (v3.11) of Mail::IMAPClient <http://search.cpan.org/dist/Mail-IMAPClient/> has a BodyStructure sub-class that could probably do the right thing, but I suspect that many existing Perl installations have not upgraded to this.  So maybe the current hack will work fine for these older systems?

In any case, the new SOAP-less PHP solution <http://civicrm.org/node/468> should do the right thing, so we need to figure this out...

Piotr Szotkowski:

--- Quote from: fen on November 18, 2008, 08:13:39 am ---I think that CiviCRM needs to be able to read and parse the envelope for information regarding bounces, etc. but I'm not sure if it should need to otherwise encode or decode messages sent to it - passing them through should be OK.

--- End quote ---

Exactly – CiviCRM is not interested in bodies in most cases at all, shouldn’t touch them when forwarding and being able to parse them for bounce reasons is not crucial (although good to have).


--- Quote from: fen on November 18, 2008, 08:13:39 am ---The "hack" above seems to work to the extent that CiviCRM can still determine the Bounce Type and Bounce Reason (from the headers?)

--- End quote ---

I haven’t run any tests, but I wouldn’t be surprised if the classes we use for handling mail were able to decode base64 on the fly.

Navigation

[0] Message Index