Should I expect email notifications when I'm @mentioned on a Maniphest task?


I’ve stumbled into a number of tasks since implementing Phabricator with my team where I was @mentioned, but I haven’t received any such email notifications.

Is this expected behavior? I tried googling and found but this tasks ultimate resolution feels like it’s more about the data that’s passed inside of emails, not necessarily who/when emails are sent generally. Or am I misreading this? Should I really be asking how I can modify the client to route these types of emails to my users?

  • Bug or feature?


You should expect to be notified about @mentions, unless you’ve muted the task, have your email settings disable these, or have a Herald rule to block them (or have a client rule to dump the emails).

If you navigate to /mail, you should be able to see the email there even if it was disabled, with explanation as to the fate of the email.


Yeah that’s what I thought too. Maybe the real problem is our emails are getting stuck in queues?


If they were just stuck in queue, I’d expect everything after them to also be stuck.
Each email sent is a separate daemon task; They don’t necessarily execute in the same order, but in normal cases all tasks get completed Very Soon after sending, unless the daemons are down, in which case no emails go out.

It’s possible that these emails fail with what the daemon thinks is a “temporary error”, so they back off and will be attempted again later. In that case, you can try executing them manually using ./bin/worker, and catch some log information.

It’s also possible that the tasks were somehow aborted/canceled/destroyed, but that would require a high level of abuse/misconfiguration to the daemon setup.


@avivey than you so much for the quick replies!

It seems like our users regularly get emails resulting from actions that they’ve taken, but @mentions and actions by other users seem to be staying in this queued state.


Okay, a little bit more information.

We use Google oAuth to create user accounts and login

When I view information about a queued message I do see an error in the metadata under “Status Details:”

Status Details [HTTP/400] { “message”: “‘to’ parameter is not a valid address. please check documentation” }


Sorry, just puking up info at this point.

We have our instance of Phabricator configured to send email using Mailgun.

Looks like this may be a Mailgun issue?



IIRC, this might mean either that the address is badly formatted (like, maybe it’s Foo Bar <> and mailgun doesn’t like it, OR it’s not whitelisted in the mailgun settings and you need to set something up on that end.

FWIW, I’ve tried using mailgun twice, and twice changed to something else (first Amazon, and now sendgrid which we already have an account with).


Amazing – I think I got it!

Essentially, the mail config setting metamta.placeholder-to-recipient didn’t seem to be working as advertised.

The description says:

If no value is set, messages with no To will have their CCs upgraded to To.

In reality I don’t think this was happening or maybe Mailgun just wasn’t recognizing it.

To address, I added a noreply@ address into the field to be added in cases where there is no to recipient. Seems to have done the trick!