FQDN for external SMTP host

ℹ️ Support
,
1

[Nextcloud version (eg, 20.0.5): 28.0.2
Operating system and version (eg, Ubuntu 20.04): Debian Bookworm
Apache or nginx version (eg, Apache 2.4.25): 2.4.57-2
PHP version (eg, 7.4): 8.2

The issue you are facing:

I am using an external SMTP host for sending mails. Where do I configure the FQDN for the host running the NC instance for the initial SMTP handshake (EHLO <fqdn>)? Regardless of what I configure in config.php (I tried mail_domain and some other variables), the Postfix logs on the SMTP server side always indicate localhost in the initial EHLO SMTP protocol handshake.

More than happy to provide more info if required.

2

Not sure, like this I’d guess it just takes a default setting from your OS:

hostname -f

3

Unfortunately this assumption is not correct as hostname -f was one of the first things I checked. Which turned out to be completely different that localhost.

4

For windows there is a configuration parameter in php.ini. Not sure how Debian sends out mails by default, for server that are only supposed to send mails, I often used msmtp (before ssmtp), where you can configure a few things and you have logging.

I’d check on your system, which program is sending out the mails (/usr/sbin/sendmail should link to it).

5

Exim4 is the default MTA in Debian. However, after a minimal installation, there is no mail functionality present, and neither the GNU Mailutils nor an MTA are installed by default, so you can install and use whatever you want, Exim4, Postfix, Sendmail etc…

6

Before this goes even further in the wrong direction: I am trying to connect to an external SMTP as outlined above.

As part of the initial protocol handshake, a FQDN has to be supplied per corresponding SMTP specification (EHLO primitive).

Where can I set this FQDN? I didn’t see this anywhere in the php.ini documentation.

7

I could be wrong, and others may chime in here, but afaik there is no configuration parameter in Nextcloud to change the FQDN in the EHLO message.

As a workaround you could use a local MTA on the Debian machine Nextcloud is installed on and send the notification emails via that, or you could just authenticate against the external smtp server via SMTPS (port 465) or STARTTLS (Port 587), in which case the integrated PHP-mailer of Nextcloud would behave like a normal email client.

8

i do the same (as many do)… and so my instance of NC and built-in mail just work as a client to that external server.

and hence you do identify with your login-credentials on that emailserver.

how did you setup your “server-setup” for emails? (the wording might be a bit misleading)

1 Like
9

SMTP server with STARTTLS. Which works as expected. Only the FQDN used by NC is always localhost. Which shouldn’t be used for the EHLO protocol part.

10

Are you sure that it is not the Postfix server that is stripping / replacing the EHLO?

Also, in this case Nextcloud is acting as an email client that authenticates itself to the SMTP server, like e.g. a desktop email client does, so there should be no need to provide its actual hostname and IP address to the mail server, or to the recipient of the email, or would you want to reveal the hostname and IP address of your desktop PC when sending an email from there?

11

I’m positive as I have access to the Postfix logs. As to the EHLO issue, please refer to smtp - Significance of 'localhost' in HELO localhost - Stack Overflow and other places where the implications of using localhost in an EHLO response is considered a bad idea and thus to be avoided.

12

Yes, but unforunately this is one of those things that’s not always possible, especially for email clients that are behind NAT, like your standard desktop email client, and in my case, this also applies to my Nextcloud server. I mean what IP address and domain name should you include in the EHLO, if your email client is sitting behind NAT on an Internet connection with a dynamic IP address?

Also, the last section in the StackOverflow post you linked to says…

I would usually recommend that you use a real MTA, and hand off your email to the MTA for ultimate delivery. That way you don’t have to reinvent the implementation of the SMTP protocol, which is surprisingly easy to get wrong.

…which is exactley what you’re already doing, and btw the fact that your authenticating against your MTA is already proof that you’re authorized to send email through that MTA.

See here: https://www.ietf.org/rfc/rfc2821.txt

See also:

Section 4.1.4 of https://www.ietf.org/rfc/rfc2821.txt

The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client’s
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.

An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.

EDIT:
I could be wrong, but this seems to date back to a time when all hosts (clients and servers) had public IP addresses and emails were often sent directly from the client to the recipient’s SMTP server, which is hardly ever the case nowadays. The usual email route today is: sending email client → sending MTA → receiving MTA → receiving client.

Also, there are other mechanicsms in place nowdays to determine the authenticity of an email message, which mostly apply to the sending MTA, so no sane email provider will reject your email based on the EHLO of the client from which the message originates from. Unless the client is sending the message directly to the receiving SMTP server, in which case it will usually be rejected anyway, but most likely not based on the EHLO either.

My conclusion from this is that if the EHLO is relevant for deliverability at all, it would be the EHLO sent by the sending MTA to the receiving MTA, and not the EHLO of the client or server where the message originally was created on.