CiviCRM Community Forums (archive)

I've seen various posts on tracking bounces, but none seem to be directly applicable - I'm hoping somebody can help!

CiviMail seems to be sending OK - I just sent out an email with over 13,000 recipients... with 0 bounces - which is impossible.

I do see message failures in the catchall account, so evidently the system isn't tracking them. Here are my settings:

Outbound email: SMTP - OK

Mail accounts:

Name: default
Server: [xx.xx.xxx.xxx]
Username: [username]
Password: [password]
Localpart: <blank>
Email Domain: [domain]
Return-Path <blank>
Protocol: POP3
Source <blank>
Use SSL?: <unchecked>
Default option: <checked>

To double check, I just sent out a test mass-email with one of the recipients being notarealperson@thisisafakedomain.com and the system reports it as a successful delivery.

Running the /bin/CiviMailProcessor.php?name=username&pass=password&key=key script just takes me back to the Civi dashboard.

Could this be a return channel thing?

I'd also like to mention here that the cron job to send mail is poorly documented:

wget -O - -q -t 1  --post-data='name=mailuser&pass=mailuser&key=1234' http://www.example.org...
should be more like:

wget -O - -q -t 1  --post-data='name=[username]&pass=[password]&key=1234' http://www.example.org...
The first is, at best, confusing - the second one works.

Any help would be greatly appreciated... thanks!

subscribing. i have seen similar behavior in the past and will be diving in to troubleshoot on 3.1 what's going on with my server. this seems like a good thread to be posting results to.

Can you check whether CiviMail Processor actually accesses that account to begin with?

Thanks for taking the time, Piotr. Unfortunately, running the EmailProcessor script just takes me to the dashboard.

Can you check your SMTP server’s logs to see whether it actually believes it delivered that email?

Not sure exactly where to look, but viewing Exim stats show the two valid emails and not the "fake" one (3 total in the test mailing), so the system doesn't show the fake message as being successfully delivered, as far as I can tell.

...it should be the complete path to the page, eg example.org:/sites/all/modules/civicrm/bin/EmailProcessor.php?...

Try to get it first working from your browser before going wget.

I just truncated the URL for purposes of brevity in the post; I am, indeed running the command with the full URL from the browser. Just takes me to the dashboard page.

System tracks opens and click-throughs - it's just the bounce that's not working. Thank you all, will keep checking in...

If you get redirected to the dashboard, likely means you don't reach the right EmailProcessor page.

Gosh - you're right. Running the processor script to the proper location produces the following error message:

connecting to xx.xx.xxx.xxx and authenticating as [catchall_username]@[domain].com
Fatal error: Ignoring exception from ezcMailPop3Transport::__destruct() while an exception is already active (Uncaught ezcMailTransportException in /home/[domain]/public_html/sites/all/modules/civicrm/packages/ezc/Mail/src/transports/transport_connection.php on line 217) in /home/[domain]/public_html/sites/all/modules/civicrm/CRM/Mailing/MailStore.php on line 86

Thanks, Xavier.

I see the same issue in the following thread, which looks like it's yet to be resolved: http://forum.civicrm.org/index.php?topic=11481.0

I've tried all possible authentication combinations - with or without the @[domain]. Same result.

At least being able to run the processing script (duh) makes me feel like I'm making some progress here... Thanks...

Try reading the mailbox with thunderbird (or any mail client), at least you'll be sure the params are correct.

Thanks for the tip, Xavier. In my case, I needed to use the catchall (base) username, without the @domain and the IP as the server. (Things were originally set this way, but using an email client made it much easier to verify.)

I now see all the activity when I address the processor - a long string ending with the error message as listed above, and the bogus email still reports as being delivered - so the bounce reporting is still not working.

So I think I've now eliminated all the other possibilities aside from a bug.

Any ideas? Thanks much!

Quote from: bcobin on April 02, 2010, 05:07:44 am

I now see all the activity when I address the processor - a long string ending with the error message as listed above

This looks like CiviMail Processor wasn’t really able to access that account – I assume there aren’t any informations about any emails being processed and that error is the first output?

Quote

and the bogus email still reports as being delivered - so the bounce reporting is still not working.

This is because the bounce is not actually being processed. Can you see whether the bounce about the addressee not being a working email address is actually in the polled account?

Actually, that's not the case. The processor output is too long to post here, so I'm attaching it as a text file.

I had to edit the text file to get it down below 32k, but it repeats the same pattern. It certainly looks like the processor is connecting. And I've pasted the bounce message from the email account below the processor output, so you can see that the bounce is, indeed, being processed by the host.

The string looks entirely too long for a simple test with three recipients, so perhaps this is referencing the 13,000+ email that was sent with the account set improperly? Perhaps the process needs to be cleared?

Looking at the output, I can't tell what's going on - maybe you can? Thanks so much for looking into this, Piotr - massively appreciated!

Hi,

Looks like it's working, but that you have loads of emails. Try deleting them with thunderbird before, if they are there by mistake.

X+

No, bounces are not working - Civi still reports the test batch of three I send out with the bogus email as having been successfully delivered to all of them, despite the fact that the bad email is properly reported to the host email account.

So I believe we've verified that everything is set properly, yet bounces are still not being properly reported.

Again, note the error message below - perhaps therein lies a clue? I'd say that, particularly for large email lists, not properly reporting bounces is a pretty big deal... thanks for looking into this!

connecting to xx.xx.xxx.xxx and authenticating as [catchall_username]@[domain].com
Fatal error: Ignoring exception from ezcMailPop3Transport::__destruct() while an exception is already active (Uncaught ezcMailTransportException in /home/[domain]/public_html/sites/all/modules/civicrm/packages/ezc/Mail/src/transports/transport_connection.php on line 217) in /home/[domain]/public_html/sites/all/modules/civicrm/CRM/Mailing/MailStore.php on line 86

Drum roll, please....

Success! 

Bounce is now reporting and email is put on hold. Thank you SO much, Xavier and Piotr. Brilliant.

Hopefully this will help others who might be running into difficulties - marvelous to have this resolved! Thanks to all for your patience...