Author Topic: "Unknown bounce type: Could not parse bounce email" (Read 37673 times)

bcobin · September 11, 2010, 05:34:49 pm

I may have spoken too soon - I just heard from the same client, whose email list is now down to 3,000 from over 15,000, even after the code change.

These look to be almost entirely "unknown bounce type." Yuck.

Bad news...

xavier · September 11, 2010, 09:46:59 pm

have you tried switching to mali()) instead of smtp?
mail doesn;t report warnings, only errors. You get the real errors later in the bounce processor.

X+

bcobin · September 12, 2010, 07:02:37 am

Thanks for the suggestion, Xavier, but I don't see how that would address the problem, which seems to be:

1. Messages that aren't delivered immediately are reported as "unknown bounce type," even if the message is subsequently delivered.

2. Once the message is bounced, the recipient is improperly put "On Hold," and needs to be manually reactivated to receive future emails.

Insofar as the bounce processor is taking the action, I don't see how changing the sending method would affect this behavior - although I am not the expert here.

This means that the client's mailing list can get whittled down to almost nothing after a few mailings. In my case (a political committee that's promoting dozens of campaigns) this is pretty catastrophic.

xavier · September 12, 2010, 09:10:27 am

Quote from: bcobin on September 12, 2010, 07:02:37 am

Thanks for the suggestion, Xavier, but I don't see how that would address the problem, which seems to be:

1. Messages that aren't delivered immediately are reported as "unknown bounce type," even if the message is subsequently delivered.

According to the rest of the thread, it isn't identified (wrongly) as a bounce by the bounce processor but by the smtp server, right when civimail tries to send it.

switching to mail() will go through a route that doesn't deal with the smtp messages, and hence solve the problem.

X+

bcobin · September 13, 2010, 08:42:14 am

Thanks, Xavier - that seems to help; I'm only getting about half the bounces now (20% as opposed to over 50%). There are definitely some bad emails in the client list, but I don't think it's anywhere near 20%.

About 70% of the bounces are "Unknown bounce type: could not parse bounce email."

The "invalid bounce type" addresses at first glance look to be, like, 80%+ AOL addresses - could this be a clue?

I'd say we're getting closer here, and being to easily take the addresses off hold is a big help, but I fear we're still not nearly ready for prime time here.

Thanks for your help - anxiously waiting for the next episode in the story...

xavier · September 13, 2010, 09:29:31 am

AOL still exists ? Haven't seen one of their CD for quite a while

Could you paste here a bounce from aol (replace the name of the user with xxxx@aol.com).

Piotr, have you heard about a specific issue with aol ?

X+

bcobin · September 13, 2010, 10:35:50 am

Here's the response from the host (Imageleet, whom I highly recommend, BTW):

Quote

We have checked logs and here are many error messages from aol.com which consist of invalid email address and later defer, for example
[name]@aol.com R=dk_lookuphost T=dk_remote_smtp defer (-53): retry time not reached for any host

Later there are 421 DYN:T1 error from aol which means they have temporarily rate limited your VPS Ip due to too many incoming mails within short period of time without getting whitelisted.

Here is the error
2010-09-13 10:20:04 1OvApA-0001UG-K8 SMTP error from remote mail server after initial connection: host mailin-01.mx.aol.com [64.12.222.197]: 421 4.7.1 : (DYN:T1)

Please provide us example email address for which CiviMail say "Unknown bounce type: unable to parse bounce email" and we will check the logs what was the original error from SMTP server.

I've supplied them with two bounces, (only one of which is AOL) and I shall report back.

bcobin · September 13, 2010, 12:00:50 pm

Here's more information from the host on the two bounced messages I sent them:

Quote

First address rejected the mail because your VPS IP has been added by barracudacentral.org RBL due to spam, i have send them the request to remove the IP from RBL. If they do not remove the IP within 12 hours then we will change mailserver IP to secondary IP on your VPS.
Here is the SMTP error in logs
2010-09-13 09:47:01 1OvAJ4-0001ZE-Tv ** [name]@[domain].com R=dk_lookuphost T=dk_remote_smtp: SMTP error from remote mail server after RCPT TO:<[name]@[domain].com>: host [domain].com [xx.xx.xx.xxx]: 550 found in b.barracudacentral.org

second email address [name]@aol.com does not exist according to aol, aol.com is giving 550 5.1.1 which means user/mailbox does not exist

Here is the SMTP error
2010-09-13 09:36:51 1OvA9K-0002x5-NI ** [name]@aol.com R=dk_lookuphost T=dk_remote_smtp: SMTP error from remote mail server after RCPT TO:<[name]@aol.com>: host mailin-04.mx.aol.com [205.188.103.2]: 550 5.1.1 <[name]@aol.com>: Recipient address rejected: aol.com

You should make sure list is clean and all user are valid as this might also be the reason barracudacentral.org blocked the IP. Script don't appear to be identifying the above SMTP errors properly.

Of course, the "Unknown bounce type" reporting issue has made it difficult if not impossible to identify bad email addresses - the real bad news is the speculation that repeatedly sending to bad email addresses may result in blacklisting.

Input here has been terrific - let us hope we can get this resolved soon.... thanks much!

sanook · October 14, 2010, 11:23:49 am

I am having this same issue. Running civicrm 3.2.2 i have tried playing with the mailer settings... but limited success there.

would be great to get this resolved.... is there any quick fix for this... like changing civimail so that any "unknown bounce types" don't place folks on hold!

bcobin · October 21, 2010, 02:04:39 pm

I'm still dealing with this issue and I took a look at the manual (nicely done!) to double check things - the first thing I notice is that the manual specifies running the EmailProcessor.php scrip for bounce processing; I've been using the CiviMailProcessor.php script per a post I found on the forum some time back.

Have I been using the wrong script? If so, could that explain why I'm getting all these bounces? Help most gratefully appreciated - as always!

Piotr Szotkowski · November 05, 2010, 05:19:56 am

Quote from: bcobin on October 21, 2010, 02:04:39 pm

I'm still dealing with this issue

With any new addresses or with the two that your hosting reports about above? (The first is blacklisting you and the other does not exist, so I assume with other addresses…)

Quote

the manual specifies running the EmailProcessor.php scrip for bounce processing; I've been using the CiviMailProcessor.php script per a post I found on the forum some time back.

Email Processor is basically CiviMail Processor with some stuff added for activities; we plan to simplify this (in 3.3, if I remember correctly) and just keep Email Processor, hence the reference in the book.

Do you have any new details on the bounces that are generated? (I think we fixed another CiviMail issue in 3.2.4, so testing that might be a good idea.)

bcobin · November 05, 2010, 06:46:43 am

Thanks, Piotr - I sent out a 46,000+ email on Tuesday, about 20% were bounces, most of which are "unknown bounce type." All bounced email contacts were put on hold.

More distressing is that it looks like some emails reported to have been successfully delivered were not received - this was using SMTP.

Still not soup yet - will continue digging deeper on my end.

Oh - one other thing (don't want to cross-post, but you seem to be on top of this) see:

http://forum.civicrm.org/index.php/topic,16397.0.html

The pager doesn't work on mailing reports - insofar as there are no sent mailings on the demo site, this can't be verified here, but I can confirm on two sites. The only way to see anything other than the first page is to hit "next," which is not practical for large mailings. This is pretty major.

Thanks, Piotr!

xavier · November 05, 2010, 07:11:41 am

What's the smtp log saying about this sending ?

Quote from: bcobin on November 05, 2010, 06:46:43 am

More distressing is that it looks like some emails reported to have been successfully delivered were not received - this was using SMTP.

bcobin · November 05, 2010, 07:25:53 am

Quote

What's the smtp log saying about this sending ?

I don't have access to the SMTP server logs and my host has already been helping out heavily with this. Before I bug them again, I want to verify that the problem isn't on the receiving end. I will report back as soon as I know, which should be soon - thanks!

bcobin · November 07, 2010, 08:29:14 am

I'm still waiting on confirmation that the emails in question weren't received, but in the meantime, I've just sent an email to one of my clients, which I've excerpted below. Please tell me if this is an accurate description of what's going on (or what's not going on!) - thanks!

Quote

First off, bounce processing has to do with messages back to the email server are handled. This is done by reading the messages in the inbox to which the user's email server will reply and taking the appropriate action based on the message.

Civi for [client] has been updated and bounce processing is now running correctly - however, the Civi bounce processing as it currently stands is problematic. When an email is not delivered immediately, the address is put "On Hold" and the user will not receive further emails unless and until their status is changed.

There are various reasons why an email may not be delivered immediately (system congestion, spam blocking software, full mailbox, etc.) and the user's email system will usually try to redeliver the message for up to 7 days.

Here's the rub: there's seems to be no processing in Civi that properly handles messages that are initially delayed, but subsequently successfully delivered. Therefore, the addresses remain on hold until they're manually removed. There are several consequences to this; first off, your mailing reports are not accurate (more emails end up being delivered than he system reports) and there is also the possibility of "bad behavior" here in that once these addresses are taken off hold and new messages are sent, repeated messages to email addresses that no longer exist can be seen by the target host as an indication of spam.

Email addresses where the user opts out are given a different status, that of "No Bulk Email," so there are no worries there - the "solution" for the moment would be to "Unhold" the "On Hold" email addresses after each mailing, but that's not optimal behavior.

CiviCRM Community Forums (archive)

News:

Author Topic: "Unknown bounce type: Could not parse bounce email" (Read 37673 times)

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

xavier

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

xavier

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

xavier

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

sanook

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

Piotr Szotkowski

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

xavier

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"

bcobin

Re: "Unknown bounce type: Could not parse bounce email"