FreeScout pod sends EHLO _, rejected by strict SMTP servers

[jj-lucas]

Hi,

I'm running the FreeScout pod and outgoing mail fails with certain SMTP relays. The pod appears to announce itself with a literal underscore in the SMTP handshake, which some servers reject as an invalid hostname.

Log from FreeScout's Send Test Email:

++ Starting Swift_SmtpTransport
<< 220 smtp1.lhr.stackcp.net ESMTP Wed, 05 Aug 2026 20:27:59 +0100

>> EHLO _

<< 501 Syntactically invalid EHLO argument(s)

>> HELO _

<< 501 Syntactically invalid HELO argument(s)

It retries with HELO and fails identically, so no mail is sent through that relay. Authentication is never attempted.

Why I think this is environment-specific

I deployed FreeScout version via Zenith Hosting, with identical SMTP settings and the same relay, and test emails send successfully. On that deployment the container announces a valid hostname rather than an underscore.

What I'd like to know

• Can the web server's server_name be set to a real hostname for my pod, rather than the nginx catch-all _?
• Is there an environment variable I can set myself to control this?
• If not, would you consider changing it in the FreeScout image, since it affects any user whose mail provider validates EHLO?

I have no shell access, so I can't change this myself, and the nginx config isn't on the persistent volume.

Happy to provide further logs or test against other relays if that helps.

Thanks

[m3nu]

Thanks for this report! I've confirmed this is something we can address in our image. This will land on PikaPods with the next scheduled update.

[m3nu]

Thanks for the detailed report — your diagnosis is right, and this is a bug in our image rather than anything on your side.

The chain is:

1. The image's nginx uses the catch-all server_name _; (inherited from our serversideup/php base) and passes that to PHP as SERVER_NAME.
2. FreeScout's SwiftMailer takes the EHLO/HELO argument straight from $_SERVER['SERVER_NAME'] (transport_deps.php), and its sanity check happens to accept an underscore.
3. So every send that happens inside a web request — including the Send Test Email button — announces EHLO _.

Same root cause as freescout-help-desk/freescout#5455 and nfrastack/container-freescout#257.

Two things worth knowing:

• There is no environment variable that changes this today, sorry — so it's fixed in the image instead. nginx now passes the request's hostname, i.e. your pod's own domain, and anything that isn't a valid hostname is dropped rather than passed on (SwiftMailer then falls back to [127.0.0.1]). Nothing for you to configure; keeping APP_URL set to your public URL is enough.
• Only synchronous sends are affected. Queued outgoing mail — normal replies, sent by the background worker — already announces the host from APP_URL, because FreeScout sets that itself for CLI processes. So if the test button is the only failure you've hit, sending through that relay may already be working; worth confirming from your side.

The fix is written and verified against a test build; it lands in the next published image. I'll comment here once that's out so you can restart your pod to pick it up.

[jj-lucas]

Hi @m3nu - thanks for looking into it.
I can confirm the part about this matter only affecting synchronous sends. As you point out, normal replies were being successfully sent :)

I'm new to PikaPods - could you tell me more or less when to expect the fix you mention to be rolled out? Would I have to do something on the PipaPods dashboard for it to be applied, or will the pod be automatically updated to the latest available image?

[m3nu]

We do updates every week on Monday. So will be out in the next days.