CiviCRM Community Forums (archive)

Hello,

I am attempting to configure CiviMail Return-Channel. I have configured and tested the outbound account. And I have setup an account for bounce processing. I have read a number of installation instructions including the book.civicrm.org and a number of forum discussions but I can't seem to resolve the latest issue I'm encountering.

I can send mass email mailings. And I receive them just fine. The correct email address is shown for the return path.

When I attempt to use an incorrect email (joh@example.com or john@exaple.com - replaced with my email addresses), I receive the bounce email in the return email account. And when I look at the contents of one of the returns, the code is 550. When I run Fetch Bounces, the email is correctly moved from Successful Deliveries to Bounces in the CiviMail Report and the Bounce Type is listed as Syntax, but the Bounce Reason is listed as: "We could not extract the mail body from this bounce message."

I've attempted this using an account on my server and then attempted it using an account on gmail, both with the same result.

Fetch Bounces does not have any errors:

Parameters parsed (and passed to API method):
a:1:{s:7:"version";i:3;}

Full message:
Finished execution of Fetch Bounces with result: Success (a:0:{})

No Civi errors.

exim_paniclog shows the following after Fetch bounce:
[5883] User 0 set for local_delivery transport is on the never_users list

Any help is appreciated.

Drupal 7
CiviCRM 4.4.x

Additional information:
The problem seems to be located in /civicrm/packages/ezc/Mail/src/parser/parts/text_parser.php - public function finish() - line 102:
       
        $this->text = ezcMailCharsetConverter::convertToUTF8( $this->text, $charset );

Prior to this the body text exists but once it is "converted," $this->text = bool(false).

The problems may be connected to the fact that Content-Type does not get set in /civicrm/packages/ezc/Mail/src/parser/parts/rfs822_parser.php - public function parseBody() - line 82, so it remains NULL.

This causes $charset in text_parser.php - public function finish() - line 79 to be set to "us-ascii". Whereas, when the Content-Type is set, in my case to "utf-8", in rfs822_parser.php, the Bounce Reason is set properly as well.

hey lottie:

great investigation and debugging. Can you continue with your experiments and:

a:figure out why the charset is not being set properly by ezc by following the code

OR

b: check with the ezc folks on their support channel

thanx

lobo

Sorry, i dont know this info right now. You'll need to check their website and see the support options they have

lobo

I think I'm getting somewhere.  The parser stuff uses iconv to convert.  It uses the iconv function of php.  Some implimentations of iconv doesn't do what is expected.  What I think is expected is it returns the converted text until it comes across a character it can't handle.  In our version and I'm guessing in lottie's as well, it returns nothing.

I've run across somethings that say

"Some PHP CMS's will default setlocale to 'C', this can be a problem.  use the "locale" command to find out a list..  $ locale -a"

On our server it comes back with C as the first item.  I'll have to play with setting it to something else.

Next the mail program is qmail.  Qmail doesn't bother to give the content-type in it's headers.  I think the standard is if nothing is given it's us-ascii, but then qmail appends the original message which is other types.  I think if the parser sees multipart in the top header it then looks for the different parts and parses for content_type.  Well qmail again doesn't set that so I'm guessing the parser never gets far enough down into the message to find the content type of the appended original message so it doesn't get set.  As far as processing the bounces, we don't care about the original message so when it stops on the utf-8 characters it can't convert, no one notices.  Well, unless it returns nothing like it does on our server.

I personally think that ezcomponents shouldn't default the content_type to us-ascii in text_parser.php if it doesn't find anything.  I think us-ascii is pretty much a subset of most other char sets.  It's eventually going to convert things to utf-8.   I believe they should set it to "unknown-8bit" which they do support in their iconv call.  If the charset is unkonwn-8bit, they set the char set to latin1 (ISO-8859-1), which if I understand correctly has a char or a substitution for all possible chars from whatever char set.  (BTW, changing the default works)

Oh, our server is running:
Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux. 
PHP 5.5.9-1ubuntu4.4
iconv implementation    glibc
iconv library version    2.19

Are you sure you have the same issue? I suggest you start a new topic and post the specific details. There are lots of different reasons for bounce rates to change.

Your case sounds like the opposite - in the past your 0% was probably a failure to process the bounces.