CiviCRM Community Forums (archive)

v3.4/4.0 introduced a preProcess rule to require a bounce processing mail account be configured in order to create a mailing. that rule is also present in the cronjob script.

i disagree with that inclusion. while bounce processing should be encouraged, I don't believe it should be required. CANSPAM does not require automated bounce processing -- it is just recommended to improve the likelihood of the email not being flagged as spam.

there are two scenarios where I see organizations not using it:

1) small organizations who want bounces to come back to their FROM email box for manual processing. if they are handling very small volumes, it may be to their benefit to receive the bounce directly to their inbox so they can follow up with the constituent or decide on another action.

2) alternate bounce processing. for example, I have one client using Sendgrid for SMTP delivery. Sendgrid requires that bounce processing happen through their system. implementers either use a push/event-based API or pull--based API script to retrieve bounces and update in CiviCRM. so we make no use of the CiviMail bounce processing directly -- everything is processed via API. the addition of these preProcess rules meant I had to modify files just to be able to send emails.

the rule present in the new mailing form isn't as big a deal, as it can be modified with an override. but the cronjob script threw us off, as the mailings were failing unexpectedly due to the rule. and that file is not overrideable.

anyway -- i think the spirit of the form rule is fine. but it shouldn't block use of civimail. in the new mailing form, we could add a non-fail notification. and I think the rule in the cronjob should be removed altogether.

it's Xavier's fault...
http://issues.civicrm.org/jira/browse/CRM-8267

@lcdweb: to cover both case, instead of a define NO_BOUNCE_ACCOUNT, having a BOUNCE_ACCOUNT= "whatever@willgetallthebounce.org" (that will be used for the sender), or BOUNCE_ACCOUNT=false (where you will use the sender email address to get the bounce.

What do you think?

X+

Hi,

I think warning is not enough. Not handling the bounce is clearly an inferior solution, that shouldn't be presented as a proper alternative, and we all know no one reads the warning anyway.

I think the proper bounce channel should either be installed, or properly and explicitely disabled. Don't have a strong opinion of where it should be explicitly disabled (UI or setting file). The later is probably easier to implement and slightly harder to use, two good reasons to go for it, but whatever is fine for me.

Two options exists as crappy solutions short of a real bounce VERP return channel:
- return to the sender (but that leads to other issues if the sender has a domain name with an SPF that doesn't include the civicrm server)
- return to a non verp mailbox (but that leads to another issue of bounces ending up in this mailbox that is never read)

@Brian, if you want to implement the second option, the mail header contains the same unique ID than in the VERP. I don't know how many mail servers keep that header when bouncing, but that's what we did on PHPList, and seems to work ok enough to be parsed most of the time. Ie. that might be a good solution to have a proper return channel even if you are using exchange.

X+

I think there is a bit of discrepancy / missing features in the conversation, to recap:

1. We need the default mailbox settings to set the VERP address of various headers

2. These settings are also used by the bounce processor

3. Allow the user to use the FROM address for various mail headers (along with the unique ID as needed) if the above is not set. We probably should figure out what settings make sense when smtp servers like sendgrid are used. This will require some amount of changes to the current release and probably a good candidate for 4.1. Not sure that those servers do with the various headers.

4. So far, not too many people have complained about this issue. So reminding / enforcing that they set good values for the default mailbox might not be a bad option, IMO

lobo

I am using Sendgrid with CiviCRM 4.1 and Dupal 7. Is there a way to have bounce processing handled by both sendgrid and civicrm? At the moment, all emails that go through sendgrids SMTP servers have their Return-Path set to sendgrid IP.

you can create a script that gets the bounce details from sendgrid via their API and then processes it in civi. that's really the only way to handle it. sendgrid has two API methods -- web api (which pulls the data upon request -- i.e. a cron script) and an event api (where they send data to a desired script as it happens). in our experience, the event api is much more full featured.

Sorry to resurrect this old thread but did this ever get resolved? i.e. not needing a smtp envelope? We're using Sendgrid with a few clients also and have recently run into problems due to this.