Page MenuHomePhabricator

Remove "metamta.domain" and "metamta.placeholder-to-recipient" config options

Authored by epriestley on Jan 2 2019, 2:06 PM.
Referenced Files
Unknown Object (File)
Mon, Aug 8, 12:49 AM
Unknown Object (File)
Fri, Aug 5, 4:51 PM
Unknown Object (File)
Fri, Jul 29, 8:31 AM
Unknown Object (File)
Thu, Jul 28, 12:44 AM
Unknown Object (File)
Jul 5 2022, 5:47 PM
Unknown Object (File)
Jul 5 2022, 8:11 AM
Unknown Object (File)
Jun 26 2022, 6:47 AM
Unknown Object (File)
Jun 25 2022, 1:12 PM



Ref T920. This simplifies mail configuration.

The "metamta.domain" option is only used to generate Thread-ID values, and we just need something that looks like a bit like a domain in order to make GMail happy. Just use the install domain. In most cases, this is almost certainly the configured value anyway. In some cases, this may cause a one-time threading break for existing threads; I'll call this out in the changelog.

The "metamta.placeholder-to-recipient" is used to put some null value in "To:" when a mail only has CCs. This is so that if you write a local client mail rule like "when I'm in CC, burn the message in a fire" it works even if all the "to" addresses have elected not to receive the mail. Instead: just send it to an unlikely address at our own domain.

I'll add some additional handling for the possiblity that we may receive this email ourselves in the next change, but it overlaps with T7477.

Test Plan

Grepped for these configuration values.

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable

Event Timeline

  • Pull fragments of upcoming inboound mail changes out of this diff.
amckinley added inline comments.

Are we worried about this potentially increasing the bounce rate and randomly killing our access to SendGrid/etc? I agree that this is an unlikely case to hit in any case so it probably won't matter.

This revision is now accepted and ready to land.Jan 3 2019, 1:29 AM

Are we worried about this potentially increasing the bounce rate and randomly killing our access to SendGrid/etc?

It's a valid address on Phacility, so it shouldn't bounce. (It will be, which is a valid routable address that ends up back in your inbound queue.) An upcoming diff also adds code to just drop mail to this address when we receive it, to make sure it also doesn't cause weirdness, although the existing X-Phabricator-Sent-This-Message header should normally prevent us from processing this mail. We'd only get mail without this header if users "Reply All" or do something similarly odd.

Actually, I should probably make this use metamta.reply-handler-domain when that is configured, to guarantee that it's a valid address.

Another argument here is that maybe this should use metamta.default-address, since that address already shows up in "From:" anyway, and has the same "Reply All" issues. In SAAS, it will be And maybe that should default to noreply@<the-inbound-domain> or to noreply@<the-web-domain> if not configured, instead of (which is probably fine, but technically sends mail to and could possibly interact negatively with other systems).

In any case, there's at least one followup coming to refine this behavior, and probably more than one, but the major change (drop this custom configuration in favor of automatically picking something reasonable) should stick.

I'm leaning toward:

  • Use metamta.default-address as the actual placeholder address.
  • Make metamta.default-address stop defaulting to
    • Instead, default to if metamta.reply-handler-domain is configured.
    • Default to if metamta.reply-handler-domain is not configured.
  • Add inbound queue code to handle mail to the metamta.default-address specially.

This should give us a little more consistency, and technically leaves this address configurable if you have a Norm O'Reply working at your company.

This revision was automatically updated to reflect the committed changes.