Page MenuHomePhabricator

Set mail sender name as "<User> via <Configurable name>".
Closed, InvalidPublic


When "metamta.can-send-as-user" option is turned off. The sender name will be set to the user name (for example, "Eric Liu"), and the sender email will be set to "metamta.default-address" (for example, ""). This might cause some confusion on the recipient side: both emails from the users and phabricator might have the same name. For example, I have two "Eric Liu" in my inbox: one is for my own email address, and another one is phabricator's email address.

I think it would make recipient's life easier by appending a string like "via Phabricator" to the sender name when the email is actually sent from phabricator's email address.

Event Timeline

ioeric renamed this task from Set mail from name as to Set mail from name as "<User> via <Configurable name>"..Nov 25 2016, 12:03 PM
ioeric renamed this task from Set mail from name as "<User> via <Configurable name>". to Set mail sender name as "<User> via <Configurable name>"..
ioeric created this task.
ioeric updated the task description. (Show Details)

This request doesn't describe a root problem (see Describing Root Problems), but we can only accept feature requests which completely describe root problems. See Contributing Feature Requests for more.

In particular, it doesn't have enough information to let us consider workarounds or different solutions to whatever the issue is, or offer similar but simpler solutions which may be good enough even if they aren't complete. It also doesn't have enough information for us to generalize the problem and consider larger solutions which can solve this problem and other problems at the same time. There is only enough information to solve it in exactly one way, by implementing the requested feature exactly.

We don't accept feature requests like this for many reasons, but a major reason is that we can not maintain them. If we do not know why we implemented a feature, we can not reason about it in the future when the product changes or other users ask us for related features. If we implement this feature exactly as described today without any understanding of why we're doing it and someone files a request to change the behavior tomorrow, we can't know if the change is harmless or completely breaks the feature for you. If you describe a problem you want to solve instead, we can reason about whether whether future changes disrupt Phabricator's ability to solve that problem.

See also T8227 for discussion of why features which require new configuration options face a very high barrier to reaching the upstream.

To move forward, completely describe the problem you're facing. Otherwise, we'll close this request in a few days (but you can always file a new request later).

Sorry about that. I have added more details to the description.

Please read and follow the guidelines in Contributing Feature Requests and Describing Root Problems. These are required for any request. Specifically this request still omits a root problem and seems to be just a design / ux suggestion. Given we have thousands of tasks and 2 developers, we don't take feature requests that don't have a root problem, we'd never be able to prioritize them.

Likewise if this only might cause confusion, but has not actually caused confusion yet, it's a hypothetical problem (see Hypotheticals). We don't accept requests to address hypothetical problems because they often never actually occur.

Phabricator has worked like this for many years with no reports of actual confusion, so what information we have available suggests this is not actually confusing in practice, or at least that very few users are confused. If this is only confusing to, say, 1 in 20,000 users, we might make the product worse overall by implementing an option for it. If you imagine a version of Phabricator with 20,000 setup options to address 20,000 rare issues experienced by only a tiny number of users, it would clearly be worse than what we have today.

If this is actually significantly confusing in practice, the particular nature of the confusion is important: for example, are users actually confused about who is sending them mail? Or is a system, like a mail client's address book, confused about sender identity? A deeper understanding of the actual problem will allow us to consider solutions like T1837, or rewriting mail to be more clear, or improving documentation around client-side mail routing rules, or whatever else.

We haven't received more information about this in a few days, so I'm going to close it. Feel free to file a new request in the future, we just prefer not to keep requests open if they're outside of our control to move forward with.

If you do file a new request, please include a complete description of the actual problem you or other users are experiencing. You can include suggestions on how you think we might be able to fix it, too, but it's critical that the entire problem is clearly explained.

We don't solve hypothetical problems (since it's impossible for us to know if we fixed them or be confident that the software complexity we've introduced is worthwhile), and we don't implement features without understanding the problems they address (since we can't maintain them, or reason about how they should change in the future, or be confident that they're the best solutions we can come up with).

Sorry for not getting back sooner.

I agree that this is just a (minor) UI issue, and I can easily modify in my local branch to enable this. If you think this is not something that worth upstream, I'm happy to close this and implement workaround in my local branch.

Set mail sender as custom name to edit file externals/phpmailer/class.phpmailer.php, change $this->FromName = $name; to $this->FromName = 'CodeReview';.