Author Topic: Debug Civimail when it only _sometimes_ fails? (Read 1104 times)

pdowling · April 26, 2010, 07:12:01 pm

Frustrating!

Sent out a mailer to 223 people. 8 got put "on hold" with the dreaded "Unknown bounce type: Could not parse bounce email", Bounce Type "Invalid".

And the weird thing it is was right in the middle of the mailer (3rd block of 20 as I have it set to send 20 each cron job). After that third block, all the rest went through!

I'm using a gmail account as my outgoing, but it can't be hitting a send limit otherwise the problem would have happened at the end of the mailing.

How do you debug something like this!?!

xcf33 · April 28, 2010, 05:57:00 am

From my understanding

The Unknown bounce type can vary

The 8 recipients might have been bad emails (bad email domains)
Vacation or not in office messages (auto bounce)

Or simply forwarding rules (if sent from this address, forward it back)

CiviCRM employs a process to "Take a look in those returned email to your email handler" and try to take a determination from its available rules, if it can't find any rules from its bounce table, it will categorize them as "Unknown bounce type".

Something you could try is going into your email handler (the email account you have set up)

The failure message (bounce) should be in a folder (or in gmail: a label) called "processed" and you can take a look to find more specific reasons.

Hope it helps,

Cheers!

pdowling · May 08, 2010, 07:18:38 am

xcf33,

Thank you for answering. Let me clarify. I'm almost certain it is none of the things you refer to (bad emails, domains, vacation, etc.). Reason is within an hour of that mailing going out I took those 8 users off hold (manually!), put them in a temporary group, then send a new copy of the original mailing to that group. It was successful, no bouncebacks.

So clearly there was nothing wrong with those addresses. Also the fact that it was 8 consecutive addresses that all failed during one cron pass is suspicious.

What I think it happening is that the mail provider (I'm using a gmail account in this case for outgoing) must be failing or timing out in some way.

Civicrm should not be interpreting this as the email address is bad and therefore needs to be put on hold. It should rather report this as a fail, but not put these users on hold. It should then allow another mailing to be sent out to the folks who failed the first time.

Even better would be if it had some intelligent retry capability, but that could be tricky.

So what I'm asking is how can I quietly debug this situation so when it happens (which is infrequently), I can figure out exactly how it was failing in order to properly report this bug. Ideally I'd like a way to capture enough debugging information in a log file so on the rare occassion it happens I can access that log and possibly provide it to others to help solve this problem.

I've noticed _many_ folks on the forum posting about similar situations. And currently Civicrm doesn't give you an easy way to take these "failed email" holds off of users in bulk other than through raw SQL which is pretty dangerous.

Thanks...

Donald Lobo · May 08, 2010, 08:08:56 am

there are a few things that could be improved within the current civimail codebase. Contributions to do so would be great and appreciated by the community

1. Analyze the error message returned by gmail / other smtp providers with a "cap" on mailing limit, and write a bounce pattern and bounce type for it. This will ensure that CiviMail does not put it in the "hold" bucket

2. Write a nice form to allow people to "find and reset" various email addresses that are on hold. This can be done as an extension to advanced search or a custom search and a custom task

3. CiviMail makes the assumption that it is dealing with a robust SMTP server (i.e. one that returns the same result across successive calls). Servers that have a "cap" limit basically give you different answers on different calls (based on how much you have sent etc). Changing CiviMail to handle such server would be a good addition

lobo

pdowling · May 22, 2010, 03:18:36 pm

Dave,

My original post (and follow up post) was really asking what you posted as #1. Namely, how do I properly debug this situation?

I'm definitely interested in doing #2 and #3 and will do them to the best of my ability or provide debugging information to help others do them.

Peter

Donald Lobo · May 23, 2010, 04:26:52 pm

personally i would use a more predictable mail server (i.e. one that returns the same error whether sent this hour or next or tomorrow)

however if u dont have a choice, i would do the following:

1. figure out how to log all interaction between civicrm's smtp packages and the mail server (check the code in packages/Mail* and packages/Mail/smtp.php)

2. log both valid and invalid messages between the two

3. find the pattern and error messages received for all cases (invalid email, too many messages this hour etc)

4. once u have that, u'll need to modify civicrm's error checking code to as something other than hold. once u get to this stage, ping us on IRC and we can chat about it

I do suspect the above process will be time consuming

lobo

CiviCRM Community Forums (archive)

News:

Author Topic: Debug Civimail when it only _sometimes_ fails? (Read 1104 times)

pdowling

Debug Civimail when it only _sometimes_ fails?

xcf33

Re: Debug Civimail when it only _sometimes_ fails?

pdowling

Re: Debug Civimail when it only _sometimes_ fails?

Donald Lobo

Re: Debug Civimail when it only _sometimes_ fails?

pdowling

Re: Debug Civimail when it only _sometimes_ fails?

Donald Lobo

Re: Debug Civimail when it only _sometimes_ fails?