Mailing issueshttps://lab.civicrm.org/dev/mail/-/issues2022-06-11T14:55:13Zhttps://lab.civicrm.org/dev/mail/-/issues/67Mailing priority2022-06-11T14:55:13ZmfbMailing priorityOrganizations that send mailings to large lists, alongside more important messages sent to smaller lists, may need a mailing priority feature.
For example, a newsletter might go out to subscribers announcing a new campaign, while simult...Organizations that send mailings to large lists, alongside more important messages sent to smaller lists, may need a mailing priority feature.
For example, a newsletter might go out to subscribers announcing a new campaign, while simultaneously a press release is sent to press contacts. The latter would have higher priority.
CiviMail would send messages for mailings with a high priority before those with a lower priority.https://lab.civicrm.org/dev/mail/-/issues/66Core should provide bounce handling (and queueing) for transactional email2022-06-11T14:55:11ZmfbCore should provide bounce handling (and queueing) for transactional emailCurrently CiviCRM core does not provide bounce handling for transactional email. This can result in automated processes sending out a large volume of scheduled reminders, etc. (as well as user-triggered forms sending out subscription co...Currently CiviCRM core does not provide bounce handling for transactional email. This can result in automated processes sending out a large volume of scheduled reminders, etc. (as well as user-triggered forms sending out subscription confirmations, etc.) with only manual bounce handling by humans.
An extension exists to provide bounce handling and other features for transactional emails: https://civicrm.org/extensions/transactional-emails
Arguably, however, this feature should be provided by core itself, so all civi instances have bounce handling for any email message they send.
Assuming we continue the architecture where it is the CiviMail component that provides bounce handling, a solution could be that enabling CiviMail overrides how transactional email is sent, adding the extra bounce processing and other features.
Ideally, transactional email could also be queued by CiviMail, so failures are not fatal and delivery attempts can be retried. Currently, if you are over-quota or your mail delivery provider temporarily suspended your account, then you have real problems when doing some critical thing that sends a transactional email message.https://lab.civicrm.org/dev/mail/-/issues/51CiviMail: Provide transparency about (non)recipient details2022-06-11T14:54:19ZtottenCiviMail: Provide transparency about (non)recipient detailsTwo stories which are not-uncommon:
## Story 1
Someone starts using CiviMail. They spend a bunch of time arranging for the list of contacts (e.g. migrating from a previous system) and then go to send a mailing. They start composing a m...Two stories which are not-uncommon:
## Story 1
Someone starts using CiviMail. They spend a bunch of time arranging for the list of contacts (e.g. migrating from a previous system) and then go to send a mailing. They start composing a message and realize that the number of recipients is way off. What's going on? They start searching Google, Stackexchange, etc trying to understand why. Eventually, they learn that there are a half-dozen rules about who gets included or excluded from a mailing. (*Does the contact have an email address? Are they deceased? Have they opted-out of the specific mailing list? Have they opted-out of email generally? Have they had bounces? Does an extension - like GDPR - add more constraints?*) But they haven't solved the issue yet: now they need to figure out which criteria are affecting them, to what extent, and how to adapt.
And of course people have this problem - the "New Mailing" UX only presents the affirmative list of active recipients. It doesn't give any hint or detail about the omitted recipients.
![Screen_Shot_2019-09-03_at_12.58.40_PM](/uploads/5a4333487cef3b3df60c6ddc5bd76f65/Screen_Shot_2019-09-03_at_12.58.40_PM.png)
## Story 2
A new user composes an email blast and discovers this incredible drop-down button with a list of tokens. They start throwing in tokens like there's no tomorrow. The blast goes out, and recipients complain: "Why are you sending me these weird messages with skipped words?"
And, again, of course people have this problem - the "New Mailing" UX lets you choose tokens without knowing if your recipient-data is up to the job.
## Discussion
These two stories are thematically similar: in both cases, we have a long list of potential recipients, and we have obscure/hidden criteria which determines whether the mailing goes out successfully to the target audience.
In both cases, there needs to be more transparency - adding UI-elements/UX-mechanisms to communicate what's going on. For example, the data-table in the pop-up might be updated with more columns/icons/color-coding.
I've logged the issue because I think, at some point, there should be discussion around design/resourcing. I don't want to prejudge that by saying the UX mechanisms to resolve these two issues must or must-not be the same - they might be totally different, or they might be one data-table. Either way, I think it's good to have a record of the issue.
## Related Links
* https://chat.civicrm.org/civicrm/pl/nn5rjzwiz3fc78pgojmhubx89a
* https://civicrm.org/blog/simonparkervitiligosocietyorguk/solution-all-recipients-not-showing-up-for-sending-mass-email
* https://civicrm.stackexchange.com/questions/5086/civimail-does-not-send-to-a-whole-group
* https://civicrm.stackexchange.com/questions/6346/after-import-to-group-individuals-in-that-group-not-showing-up-as-recipients-to
* https://civicrm.stackexchange.com/questions/26320/contacts-visible-in-mailing-list-group-not-on-hold-or-otherwise-dnd-but-skippe
* https://civicrm.stackexchange.com/questions/18199/in-mailing-all-recipients-are-not-showing/18201#18201
* https://civicrm.org/extensions/zombie-check
https://lab.civicrm.org/dev/mail/-/issues/23Bounce processing doesn't catch pattern "user doesn't exist"2022-06-11T14:50:34ZDetlev SieberBounce processing doesn't catch pattern "user doesn't exist"CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
...CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
Some email providers throw the bounce pattern "user doesn't exist", which is not found, and therefore results in bounce_type "syntax". However, this bounce pattern should result in immediately switching the email address to "inactive".
Solution is:
> insert into civicrm_mailing_bounce_pattern (bounce_type_id, pattern) values (6, 'user doesn\'t exist');
5.9Monish DebMonish Deb