Voided email is still delievered?


Observed Behavior:
First, some facts that may be relevant.
My Phabricator instance uses bugs@companyname.com as the from address for emails.
This instance also has an existing account on it with the same email as the verified email associated with it.
I receive notifications for messages sent to this email.

Now, onto the actual problem. Today before work I managed to resolve two bugs in some software, pushed some changes to a repository, and got like 7 emails sent to the email above. I logged into the account associated with that email and changed the “Email Delivery” option to “Disable Email Notifications” (noting and liking that I still receive some “administrative” emails. This has a big warning that I like and actually want as the behavior: “If you disable Email Notifications , Phabricator will never send email to notify you about events. This preference overrides all your other settings.”

Several hours later, close a task, get an email to the address above even though it has Email delivery off.

I checked out phabricator.example.com/mail/details and saw the following:
This is an older message that predates recording delivery information, so none is available.
Effective Rule
This is an older message which predates routing rules.
Status Details
Message has no valid recipients: all To/CC are disabled, invalid, or configured not to receive this mail.

Expected Behavior:
Phabricator should not send task-related email to users with “Email Notifications” set to “Disable Email Notifications”

Phabricator Version:
e6331ca8efc1f60e38f9ca13dc292f9bb00ea104 (Mon, Feb 25) (branched from 701a9bc339b9d419326a62e85ef13666b08046cd on origin)
b4a302683b1aefbbb2ab9d1aaaf418b551b84b28 (Sat, Feb 23) (branched from 9581dd0f52726b10c923038c28d5fe2170f0d1b6 on origin)
813a26a2d09758f3c407a0c99c6761f11f62cb90 (Sat, Feb 23) (branched from 671ec8fb8f7aa74e9e825ca95fd96ce4bbf79160 on origin)
3.3 at /usr/bin/diff
2.1.4 at /usr/bin/git
Not Available
2.0.1 at /usr/bin/pygmentize
1.8.10 at /usr/bin/svn

Note that Phabricator connects to our company’s mail server via SMTP and it is not running on the same host (if that’s relevant).

Reproduction Steps:
Set email delivery to “disable email notifications” and do any action for which you would otherwise receive an email.


Okay, some clarifcation. I was apparently looking at the inbox (on /mail/) for the wrong account.

Looking at /mail/ while logged into the account that received the email, I don’t actually see the message I’m talking about in my inbox or outbox, yet I very definitely received it in the actual account’s inbox.

I’m going to look into this on my end a bit to verify I’m not just being forwarded email sent to other addresses or something.

edit: some things to note, I appear to be in the “to” field for this message. There’s another phabricator user "cc"d on it, and I’m not sure if delivery should have been to them (I’m unsure what they’re email preferences are)

I’m also a member of several projects that are also cc’d (not directly listed as CC email’s, but they show up under “X-Phabricator-Cc” headers.

I feel like none of this should actually be relevant if i have email notifications off, but would like any feedback you have as I continue checking for things on my end.


When an application asks Phabricator to deliver mail and the mail has no “To” recipient, but one or more “Cc” recipients after resolution of recipients, Phabricator puts a placeholder address in “To”. It must put some valid address (or, at least, something that looks like a valid address) in the “To” line because mail is generally not deliverable with no “To”. (It could move the “Cc” users to “To”, but humans who write client-side mail rules dislike this because it prevents them from routing the mail based on whether they are a “To” or a “Cc” recipient.)

Phabricator handles mail “sent to a user” and mail “sent to an address” differently. Preferences only affect mail “sent to a user”. In the case where we’re filling in “To”, we MUST provide a value, so it doesn’t matter what preferences are set anywhere – we can’t decline to provide a value.

If “metamta.default-address” is configured, it should not point at a real mailbox. The documentation for the option should now make this clear, and explain the consequences:

… this option should be configured to point at a valid mailbox which discards all mail sent to it. … If you point it at a real user mailbox, that user will get a lot of mail they don’t want.

This all sounds like expected behavior, and I don’t think there’s anything we can do to change any of it.


I just double checked metamta.default-address and it’s definitely the mailbox. That explains that account being in the ‘to’ field when there’s likely no other address there.

Thanks for the answer! Not really a bug I guess and the documentation makes that more clear.

edit: fwiw i just created a local rule that deletes all incoming mail so, no longer a problem :stuck_out_tongue:

closed #5