SMTP EHLO sends [127.0.0.1] instead of server hostname (Symfony Mailer migration)

[XFConvert]

Affected version

2.3.9

Description:

After upgrading from XenForo 2.0.6 to 2.3.9, outgoing SMTP emails intermittently fail with 421 rejections from Google's SMTP relay (smtp-relay.gmail.com). The error message:

Expected response code "250" but got code "421", with message "421-4.7.0 Try again later, closing connection. (EHLO)"

The root cause is that Symfony Mailer's EsmtpTransport defaults to EHLO [127.0.0.1] when no local_domain is specified. The previous SwiftMailer implementation automatically used the server's hostname for the EHLO greeting, but the migration to Symfony Mailer in XenForo 2.3 does not set the local_domain option.

In src/XF/Mail/Mailer.php, the getTransportFromOption() method creates the SMTP transport via EsmtpTransportFactory::create() with a Dsn object, but does not pass a local_domain option. The Dsn constructor accepts options as its 6th parameter, but it is not used.

Google (and potentially other strict mail servers) reject EHLO [127.0.0.1] as it appears to come from a misconfigured server.

Workaround:

Adding the following line immediately after the transport is created (after line 553 of src/XF/Mail/Mailer.php in XF 2.3.9):

$transport->setLocalDomain('yourserver.yourdomain.com');

This resolves the issue, but the fix is overwritten on upgrade.

Suggested fix:

Either:
(a) Automatically set the local_domain from PHP's gethostname() when constructing the SMTP transport, similar to how SwiftMailer behaved, or
(b) Expose a local_domain / EHLO hostname field in Admin CP > Email Options, or
(c) Support a config.php option (e.g. $config['emailTransport']['localDomain']) that gets passed through to the Dsn options.

Option (a) would be the most seamless and backward-compatible, requiring no action from administrators.

 

[Kirby]

Interims workaround without patching

config.php

$c->extend('mailer.transport', function (\Symfony\Component\Mailer\Transport\TransportInterface $transport) {
    $transport->setLocalDomain('yourserver.yourdomain.com');

    return $transport;
});

 

[XFConvert]

Thank you Kirby! Much better workaround since config.php survives upgrades.

 

[smallwheels]

I am wondering a bit: This sounds like an issue with pretty massive effects for every forum that relies on the mailer built into XF. Still no response from the team @Chris D after days.

Is the fix by @Kirby recommended as a standard for everyone who uses the built in mailer of XF to deliver forum mails? How would one recognize if one suffers from the error? As I understand it sending fails early in the smtp connection, thus atm I don't know if there will be an entry in the email bounce log (I assume probably not and I've not seen this error in my bounce log yet).

 

[Kirby]

How would one recognize if one suffers from the error?

No emails would be sent and you would see the such errors in XenForo server error log.

I don't think that this is a significant issue, it has been this way since 2.3.0 and so far there were no reports for this.
It also somewhat depends on the SMTP provider used as [127.0.0.1] is technically compliant with RFC 5321 section 4.1.3 so IMHO Google should probably accept this as-is on a submission port with SMTP Auth.

Think of an end-user client like Outlook or Thunderbird on a NAT network submitting email to the provider SMTP server.
Such a client doesn't have a public hostname or IP address.

Do you use a submission port (usually 587 for STARTTLS or maybe 465 for SMTPS) @XFConvert?

 

[smallwheels]

It also somewhat depends on the SMTP provider used as [127.0.0.1] is technically compliant with RFC 5321 section 4.1.3 so IMHO Google should probably accept this as-is on a submission port with SMTP Auth.

Ah! Stupid me oversaw this bit:

Google's SMTP relay (smtp-relay.gmail.com).

I thought we were talking about mail delivery, not mail relaying. This also explains why it is probably not a huge issue (and clearly none for me as I atm do direct delivery w/o relay).

 

[XFConvert]

No emails would be sent and you would see the such errors in XenForo server error log.

I don't think that this is a significant issue, it has been this way since 2.3.0 and so far there were no reports for this.
It also somewhat depends on the SMTP provider used as [127.0.0.1] is technically compliant with RFC 5321 section 4.1.3 so IMHO Google should probably accept this as-is on a submission port with SMTP Auth.

Think of an end-user client like Outlook or Thunderbird on a NAT network submitting email to the provider SMTP server.
Such a client doesn't have a public hostname or IP address.

Do you use a submission port (usually 587 for STARTTLS or maybe 465 for SMTPS) @XFConvert?

Hi Kirby thank you for the reply. I apologize I just now saw your reply. Thanks for the input. Here is the answer to your question regarding the submission port. This is what I have set in the admincp:

Email transport method
Connection type: SMTP
Host: smtp-relay.gmail.com:465
Username: redacted
Use SSL/TLS: Yes