Page MenuHomePhabricator

one-mail-per-recipient not honored for some reason
Closed, DuplicatePublic

Description

Not sure where to file this. We recently upgraded our Phabricator install to 36e2d02d6ec5db26f4dfc813a4f02238d18cc8a5 and after doing so we noticed that Phab started sending out emails to each person in CC individually instead of sending one email to everyone.

I investigated this issue a bit and it seems that there is either a bug of some sort or a mis-configuration in our install. I have metamta.one-mail-per-recipient set to "Send Mail To All Recipients" which seems to describe the behavior I desire.

Any hints on where to go from here would be very helpful! Thanks

Event Timeline

carlsverre raised the priority of this task from to Needs Triage.
carlsverre updated the task description. (Show Details)
carlsverre added a subscriber: carlsverre.

When the option is set we'll just bypass policies when generating mail. I'll slap a giant warning on the setting and lock it down, but I think there isn't really an alternative (other than removing it, but installs might reasonably want to choose better mailing list support over policy correctness, and the policy violation is usually not large).

We haven't made any changes here recently and I haven't seen other reports about this being broken, but I'll be rewriting this code in connection with T6367 anyway.

Thanks for the feedback guys! I am fine with policy violations, what I am trying to do is get Phabricator to start sending a single email per action and just have it include all of the recipients in the single email (as To x,y,z and CC mailing list a, b, c). Is that not what this option should allow me to configure? If it should be doing what I expect are there other things I can look at to diagnose why the expected behavior is not happening?

Thanks for the help!

Is that not what this option should allow me to configure?

That is what the option should allow you to configure.

If it should be doing what I expect are there other things I can look at to diagnose why the expected behavior is not happening?

Not really.

To clarify: this will be obsoleted by T6367, which I'm working on right now, so I'm not specifically going to try to reproduce or resolve it ahead of that. The difference between a separate fix and a fix via T6367 is probably a matter of hours.

Sounds good! I will watch for T6367 landing. Thanks :)