Page MenuHomePhabricator

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

Authored by epriestley on Jan 2 2019, 2:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 23, 5:44 PM
Unknown Object (File)
Sat, Mar 23, 5:44 PM
Unknown Object (File)
Fri, Mar 22, 9:54 PM
Unknown Object (File)
Fri, Mar 22, 9:53 PM
Unknown Object (File)
Thu, Mar 21, 11:05 PM
Unknown Object (File)
Sun, Mar 10, 3:19 PM
Unknown Object (File)
Feb 3 2024, 8:36 PM
Unknown Object (File)
Jan 23 2024, 4:43 PM
Subscribers
None

Details

Summary

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

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

  • Pull fragments of upcoming inboound mail changes out of this diff.
amckinley added inline comments.
src/applications/metamta/storage/PhabricatorMetaMTAMail.php
1474

Are we worried about this potentially increasing the phacility.com 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 phacility.com 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 void-recipient@yourinstance.phacility.com, 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 noreply@yourinstance.phacility.com. And maybe that should default to noreply@<the-inbound-domain> or to noreply@<the-web-domain> if not configured, instead of noreply@phabricator.example.com (which is probably fine, but technically sends mail to example.com 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 noreply@phabricator.example.com.
    • Instead, default to noreply@your-inbound.domain.com if metamta.reply-handler-domain is configured.
    • Default to noreply@your-web.domain.com 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.