Increase usability of email domain configuration in CiviMail

[EvanDonovan]

Earlier today, I spent a few hours trying to get it so that our email action tokens (unsubscribe, opt-out, etc.) would go to a different domain than the one in the From: header for the emails that CiviMail sends out.

I needed to do this since we are preparing to switch our main email over to Google Apps for Your Domain, but that, of course, would not process the bounces, opt-outs, unsubscribes, etc. properly by routing them through Exim to the Perl script that we have handling our backchannel through the SOAP interface.

I spent a while considering hook_token & hook_tokenValues overrides, before digging into the actual code of CRM/Mailing/BAO/Mailing.php. That led me to the civicrm_mail_settings table. But even after finding that, it took me a while to realize I actually just needed to change Email Domain in CiviCRM Admin > Mail Accounts and that would change the VERP tokens, but without messing up the From Email Addresses, which I was happy with as they were.

I think that there are too many places in the CiviCRM Admin interface to specify email addresses & domains. When you have an existing CiviCRM install that works, and you need to change the address for the mail server to get the backchannel to work, it is unclear whether you should go to Configure: Domain Information; Configure: From Email Address; CiviMail: Mailer Settings; CiviMail: From Email Addresses; or CiviMail: Mail Accounts.

Part of the confusion is because CiviCRM core email settings & CiviMail email settings are different. Perhaps there should be a cross-link on the Domain Information page that shows up when CiviMail is enabled, so people know that they need to its configuration pages also. In addition, I like the checklist that exists for the core settings. Would it be possible to conditionally include links to the optional components' configuration on that page? (For example, the mail settings pertaining to CiviMail could appear below the other mail settings.)

As for the pages in the CiviMail component themselves, I think Mailer Settings & Mail Accounts should be merged into one form, called Mail Settings. The Mailer Settings options could appear at the top in a fieldgroup called Global Settings, and the Mail Accounts settings could show in a list called Mail Domains below (with the settings for each editable either inline, or on a separate page). If it is too difficult to merge the pages, there should at least be help text cross-referencing Mail Accounts from Mailer Settings and explaining why it is needed. I initially gravitated toward Mailer Settings, without knowing why I would need to touch Mail Accounts.

Also, it is confusing that CiviMail: From Email Addresses and Configure: From Email Addresses are links to the same page. It should probably only show up in the CiviMail section, since it is used with CiviMail. And it should say something like "the From email address settings do not affect the VERP addresses (which handle bounce-backs, opt-outs, etc.) unless the override option is set".

At dlobo's request, I have created this as a forum post rather than an issue in JIRA. I could copy it over there, if you are interested, though. Thanks.

[Piotr Szotkowski]

Thanks for the great suggestions regarding the CiviMail admin stuff! Revamping the CiviMail admin pages is on my list of things to do later this month; I was thinking much along the same lines – that we should remove the unused settings (the ones for the spool table), merge the remaining ones into (ideally) a single screen and decorate them with docs clearing up the relationship between the From: address, the VERP addresses and the mailboxes polled by the CiviMail Processor.

I needed to do this since we are preparing to switch our main email over to Google Apps for Your Domain, but that, of course, would not process the bounces, opt-outs, unsubscribes, etc. properly by routing them through Exim to the Perl script that we have handling our backchannel through the SOAP interface.

Have you considered using CiviMail Processor instead? Gmail supports the ‘+’ recipient delimiter in email addresses, so I assume Google Apps for Your Domain do  to; if so, you could have the VERP addresses be of the form civimail+b.1.23.4567…@example.com, which would make the bounces/replies/etc. land in a Google account and then be processed by CiviMail Processor.

[xavier]

We did go with a "normal" user through sending a mailing. This is complicated, and part of the complication is that things like VERP don't mean anything to normal users, and I'd argue that we offer too much options on things they don't understand.

A few things that I would love to be able to do from the admin for these settings:

Open tracking
Click through tracking
Override VERP
All the templates for the autoreply/forward... on step 2 (that are in all my config the single default one configured).

1) to have an option to set the default value (eg. Open tracking off, overrride VERP checked)
2) force them ie. hidden values, not displayed in the front office, to simplify the life of the users.

X+

[Donald Lobo]

At dlobo's request, I have created this as a forum post rather than an issue in JIRA. I could copy it over there, if you are interested, though.

can you please file an issue for this. we'll attempt to address it in 3.2

lobo

[EvanDonovan]

Piotr: Thanks for your input. As it turns out, there was no issue with Google Apps for Your Domain since we have CiviMail on urbanministry.org, which has mail.urbanministry.org as its mai server. Only techmission.org was switched to Google's SMTP & POP servers, so this was fine.

I am glad to hear that you are interested in working on this.

dlobo:

Filed http://issues.civicrm.org/jira/browse/CRM-5977