Disable void-recipient in metamta smtp mailer


#1

Hello,
I just upgraded my Phabricator instance and also needed to switch to the metamta smtp mailer (before I used the PhabricatorMailImplementationPHPMailerAdapter). Now I get a lot of complaining mails of our smtp server because of the void-recipient.
Is it somehow possible to disable this behavior? I mean that if there is no recipient in the to section leave it empty?

Thx,
Hannes


#2

Yup, I came here with the same problem. It seems this was changed recently, and is now un-configurable. IIRC, if you had previously not set the “metamta.placeholder-to-recipient” configuration variable, it upgraded the CC to To, so no placeholder recipient was used. This behavior is gone, I guess?


#3

This change was a bit of a shock to us as well. In particular, we use an external domain for our email that is different from our Phabricator URL, so our admins were getting a lot of void-recipient@phabricator.ourdomain.com bouncebacks from Amazon SES because the subdomain we’re using for Phabricator doesn’t have an MX record and the server doesn’t handle inbound mail (by choice). We’ve temporarily patched back in the ‘upgrade-CC-to-To’ behaviour to get those bounceback messages to stop.

I’d rather liked the upgrading-CC approach to the blank To field problem, but am curious how the suggestions in that diff will work out.

If you run the mail server as well you could accept all inbound messages to void-recipient@domain and filter them to /dev/null to stop the bounces, but the instructions for doing so will depend on what your server is using for mail processing (sendmail? postfix?).


#4

This issue should be fixed once https://secure.phabricator.com/D19953 lands. D19942 probably should not have been landed without D19953 as well. Sorry for the inconvenience.


#5

@jmc Do you have that patch handy?


#6

I’d replaced line 1024 to 1027 in src/applications/metamta/storage/PhabricatorMetaMTAMail.php with something along these lines, cribbed from the old version of the diff that removed this behaviour:

if (!$add_to) {
   $add_to = $add_cc;
   $add_cc = array();
}

Likely will end up patching D19953 onto our install sooner rather than later, though, see how that goes :slight_smile:


#7

The remainder of these changes have landed in master and will promote to stable tomorrow.

Briefly, we now use metamta.default-address as the “placeholder” address in the “To” line for mail which only has “CC” users. You should configure this as some valid, deliverable address which does not bounce, because it is also used as the “From” address for at least some email, and users might “Reply” or “Reply All” to it. Ideally, this address should just accept mail that is sent to it and throw it away.

(We use a “placeholder” address so that users may write client-side mail rules which care about whether they were “To” or “CC” recipients and have them behave consistently.)

If you do not configure metamta.default-address, it will default to noreply@<meta.reply-handler-domain> if that option is set, or noreply@<phabriator.base-uri> if it is not.


#8

Also, if you do have metamta.reply-handler-domain configured, the default address should become a “void” address (which simply discards mail sent to it) automatically (with one caveat, but I’ll likely get a fix in for that today). My expectation is that if you configure metamta.reply-handler-domain, everything else will now “just work”.


#9

See https://secure.phabricator.com/D19987.