CiviCRM Community Forums (archive)

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

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

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

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

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
$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:
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

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

CiviCRM 4.1.1

Its actually right in front of me. Emailprocessor::process calls
$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

[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

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

$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