Details
- Reviewers
amckinley - Maniphest Tasks
- T13164: Plans: 2018 Week 31 - 33 Bonus Content
- Commits
- rP690a460c8e8d: Allow mailers to be explicitly marked as inbound or outbound
- Added and ran unit tests.
- Went through some mail pathways locally, but I don't have every inbound/outbound configured so this isn't totally conclusive.
- Hit bin/mail send-test with a no-outbound mailer.
- I'll hold this until after the release cut so it can soak on secure for a bit.
Diff Detail
- Repository
- rP Phabricator
- Branch
- mailio
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 20530 Build 27882: Run Core Tests Build 27881: arc lint + arc unit
Event Timeline
What happens to an install that incorrectly configures these settings (all inbound disabled, all outbound disabled, etc)? Is it worth validating cluster.mailers and raising a setup issue?
What happens when you accidentally configure an inbound-only mailer as outbound (or the other way around, which might fail even more quietly)? I guess the logs/errors wouldn't be any harder to get to, and the debug process would be the same, so this probably isn't a big issue.
I'm tentatively thinking it's "legal" to configure this correctly and disable all mailers of one or both types explicitly, under the theory that this is sufficiently far out of the way that it's more likely you did it on purpose (e.g., you want to stop inbound or outbound mail while you fix or investigate something) than made a mistake. So I'm hesitant to raise a setup warning, since it feels like this is an OK configuration that you can legitimately end up in.
The inbound mailers are all configured individually anyway so you don't get any new/additional behavior by disabling all of them versus disabling only some of them.
For outbound, we'll currently void the mail with this message:
No mailers are configured.
Admittedly, that's not great for the "mailers are configured but none support outbound" state of the world. I'll special case that into "no mailers" and "no outbound mailers" messages just in case someone hits this.
- Tailor the error message for voided sends with no available outbound mailers.
This is a little finnicky because you can pass some custom list of $mailers to confuse things, but in actual cases which normal users will ever hit this should get things right and produce a more helpful message.