Problem/Motivation
1) User interface
While working on issue #2348119 , it was noticed that the core MailManager->mail() , when encountering a problem with passing the mail on to the mail server, logs the error and then uses drupal_set_message() to tell the visitor about it.
It already returns an array that contains the outcome of the attempt, which can be then handled by the caller.
This causes problems for modules that want to provide better errors to the user ( e.g. in the case of the contact module, which mail failed instead of all of them individually ).
The first idea was to extend the class when wanting to override this behavior, but that leads to duplicating the entire function minus a line.
2) Running from cron
A common setup is to use crontab to schedule drush cron via drush. If drush detects any error messages from messenger()->addError, prints them and returns an error to the shell. Depending on the exact config, this might trigger cron to send an emergency mail. So a single email failing to send is being given the same level of urgency as a major problem such as the overnight backup failing.
Simplenews module sends emails in bulk to newsletter subscribers using cron. There appears to be no way for the module to avoid this unwarranted highly-visible false alarm without a change to core.
Further context
For the default PHP mailer, a successful result means "nothing more than the message being accepted at php-level, which still doesn't guarantee it to be delivered". Hence an error result typically indicates a fairly serious general problem.
Alternative mail-sending plug-in implementations can return an error much more easily. In particular Swiftmailer sending over SMTP does so for a bad email address. On a busy site with lots of subscribers, such errors are likely to occur daily.
Proposed resolution
Specify that a parameter with key '_error_message' has the special meaning to specify translatable markup to use as an error message if needed.
Remaining tasks
Write a CR
- calling code can supply an error message
- MailManager implementations should follow the new param
User interface changes
User will see less (and hopefully more targeted and specific to the action at hand) messages.
API changes
Specify that a parameter with key '_error_message' has the special meaning to specify translatable markup to use as an error message if needed.