Bounce mails received, but not being processed

[pike67]

Hi

I set up a bounce email address under CiviMail:accounts, it uses VERP style addressing. When testing, the bounces arrive in that account. If I run the bounce cron job, they are removed and the cron jobs log reads

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

But that is all it does. It does not

• increase the failure rate of a send out mailing (result stays '100%' even if 2 out of 3 bounce)
• mark the contact on hold or anything
• create folders or files in drupal's sites/default/files/custom (should it?)

Any suggestions on how to debug this ?

I'm attaching one of the bounce mails picked up from the bounce account,
just before the cron job deleted it.

thanks!
*-pike

[Donald Lobo]

1. i dont think the script creates folders in the custom directory. in imap it creates folders in the imap directory

2. You might want to add some debugging code to the file:

CRM/Utils/Mail/EmailProcessor.php

lobo

[pike67]

Hi Lobo

Thanks for your response.
Indeed, it created IMAP folders CiviMail/ignored and CiviMail/processed.
All the bounce mails are in processed. One test mail is in processedignored.

Any hint on what I should be debugging for, or how to view/log debugging - in what point of the process is the file called ?

thanks,
*-pike

[Donald Lobo]

you'll need to edit that file and add debuggign statements. You can move the same mail from the processed to the main folder and trace the steps that civi takes

the bounce processing code is in the _process function

lobo

[pike67]

OK .. tough. I added debugging just before the switch($action) to see if its anyway marked as a bounce('b'). i added

Code: [Select]

CRM_Core_Error::debug( 'pike', array(
  'action'=> $action,
   'job_id' => $job,
   'event_queue_id' => $queue,
   'hash'       => $hash,
    'text' => $mail->body->text,
    'match' => $match
),true,true );

when putting plain-text bounces in the inbox, and calling 'execute now', this barfs stuff to my screen (woohee), saying

Code: [Select]

Array
(
    [action] => b
    [job_id] => 103
    [event_queue_id] => 20461
    [hash] => db5eabebfd719703
    [text] => Hi. This is the qmail-send program at...[snip]
    [match] => myprocessor-b.103.20461.db5eabebfd719703@mydomain.nl

$action = 'b', thats good.
$mail is a ezcMail Object, and it has $mail->body->text.

The switch block will end in a call

Code: [Select]

$params = array(
       'job_id'         => $job,
       'event_queue_id' => $queue,
       'hash'           => $hash,
       'body'           => $text,
       'version'        => 3
);
$result = civicrm_api('Mailing', 'event_bounce', $params);

Thats all good.

after dispatching the event, it will mark the mail as processed, which is what i see happening in the mailbox.
So thats all good.

But nothing is happening:

Code: [Select]

Intended Recipients 3
Successful Deliveries 3 (100.00%)

So, the bug is in the api. Do I need to dig deeper or does this ring a bell with anyone ?

desperate,
*-pike

[Donald Lobo]

i'd see the query logs and see if there is an update/insert on the mailing_event_bounce table. if not, i'd start debugging the api which i suspect just sends u to the bao object that does the work

lobo

[pike67]

thanks

mailing_event_bounce is basicly empty. there are 6 bounces in may with bounce_reason 'mail() returned failure'.

so we're going down the api :-(

is the TAO of DAO and BAO documented somewhere ? I have no clue.

*-pike

[Donald Lobo]

what version of civi? colemanw fixed a few bugs with the mailing api in 4.4.1 (or .2).

lobo

[pike67]

CiviCRM 4.1.1

Its actually right in front of me. Emailprocessor::process calls

Code: [Select]

$params = array( 'job_id'         => $job,
       'event_queue_id' => $queue,
       'hash'           => $hash,
       'body'           => $text,
        'version'        => 3
);
$result = civicrm_api('Mailing', 'event_bounce', $params);

and $result is

Code: [Select]

[result] => Array
        (
            [is_error] => 1
            [error_message] => Mandatory key(s) missing from params array: time_stamp
        )

he's right ... now what ? I can toss in a random number :-)
Why did this happen ?
Is something using the wrong api ?

strange,
*-pike

[Donald Lobo]

4.1.1 OR 4.4.1?

4.1.1 is fairly old

lobo

[pike67]

4.1.1

4.1.1 is fairly old

Yeah, I know, we installed it almost a full year ago :-D
Time flies, according to the CiviCRM roadmap, 4.3 is almost out:
http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Roadmap

I'd hate to do an update .. or at least i'd rather know what was wrong
before i decided an update is the ultimate solution. But I can imagine
its not all that interesting for you to think about, then.

Its the DAO (?) that sets the requirement (CRM/Mailing/Event/DAO/Bounce.php).
But its the  BAO(?) that creates the bounce, and the BAO sets the time_stamp right after creating it

Code: [Select]

$bounce = new CRM_Mailing_Event_BAO_Bounce();
 $bounce->time_stamp = date('YmdHis');


What would be the code that actually checks the requirement and spawns the error,
do you know ? Because oddly enough, the BAO 'create' will always return true.

thanks,
*-pike