Disable plain ports (STARTTLS) and force TLS

SailReal

Hey all,

If I want to use TLS only (imaps, pop3s, smtps/submissions) and remove STARTTLS, is it enough in the mailcow.conf to remove the values for the appropriate ports?

SMTP_PORT=
SUBMISSION_PORT=
IMAP_PORT=
POP_PORT=

Is then also the autodiscover and autoconfig endpoint adjusted accordingly?

Also is there an SUBMISSIONS_PORT= property?

Thank you 🙂

esackbauer

No, leaving values empty would set them to their default values.
Autoconfig and autodiscover will only be adjusted if you configure the parameters that you have listed.

There is no security benefit in disabling non-TLS ports, and in case of SMTP port 25 that is not possible at all, you must have this open or you cannot receive mail.

SailReal

esackbauer There is no security benefit in disabling non-TLS ports

A security researcher reported this to us together with https://www.usenix.org/system/files/sec21-poddebniak.pdf …you don’t share the conclusions of this paper and what the mentioned security researcher recommended us to do?

set the implicit TLS only (i.e., port in 465, 993 or 995) and add encrypted SRV service records (i.e., imaps.tcp/pop3s.tcp/submissions.tcp).

tayyebi

esackbauer

But Spamhaus asked servers to disable their port 25. Which one is correct then?

Routers and firewalls should be configured with port 25 disabled and SMTP Authentication enabled.

Disabling port 25 will not stop mail software from working normally. The software for email clients, used to read and send email, operate on different ports (587 or 465), and such clients are able to access your ISP’s mail servers after being correctly configured with SMTP Authentication. From the user’s perspective there is no difference.

link to src

esackbauer

I recommend add a Web Application Firewall in front of mailcow, if you are concerned of security. It gives you more control about what is allowed and you are informed of possible attacks and can block those attacks. It depends of course on your exposure, and this should influence the overall solution.
Fiddling with a product like mailcow in a not supported way makes a solution less safe! Because some tweaks might not survive an update or may have consequences on other parts of the product having issues or even open up things that are not supposed to be open.
E.g. I am using Sophos Firewall, which not only reverse proxies https, but also is a SMTP MTA and scans IMAP traffic.

SailReal

Okay I see, thanks for your thoughts.

I just read from https://docs.mailcow.email/getstarted/prerequisite-dns/#the-advanced-dns-configuration that there is maybe a solution?

If you want to explicitly announce a service as not provided, give “.” as the target address (instead of “mail.example.org.”)

Is this DNS config also honored for the autodiscover and autoconfig endpoint?

esackbauer

SailReal Is this DNS config also honored for the autodiscover and autoconfig endpoint?

Autoconfig yes, it uses most of those SRV records
Autodiscover no. But Autodiscover is used for Activesync only, so that goes via https anyway.
I have not published SRV records for IMAP 143 and POP3 110.

SailReal

Okay, awesome and thank you.
Autodiscover already uses in my setup obviously only the TLS variant.

So setting

_imaps._tcp           SRV   0 1 993 mail.example.com
_smtps._tcp           SRV   0 1 465 mail.example.com
_submissions._tcp     SRV   0 1 465 mail.example.com

_submission._tcp      SRV  0 0 0   .
_imap._tcp            SRV  0 0 0   .
_pop3._tcp            SRV  0 0 0   .
_pop3s._tcp           SRV  0 0 0   .

should be completely fine (next to
_autodiscover._tcp and _sieve._tcp), right?

esackbauer

Don’t create entries with the ports you will not use, or you might get problems with your clients.

SailReal

esackbauer you might get problems with your clients

Could you please explain this a bit more so that I understand why I get problems when I disable the protocols I do not want to use via the DNS entry?

esackbauer

Your are not disabling by providing a SRV record, the opposite is the case, you are signalling the client software that there is a valid service.
The client software is assuming that there are meaningful SRV records and tries to connect to it to probe the ports.
Best case nothing happens and the clients switch to other ports, worst case is you get a bad battery life on the client device because of retries to a nonexistant DNS address.

SailReal

But on https://docs.mailcow.email/getstarted/prerequisite-dns/#the-advanced-dns-configuration you write

If you want to explicitly announce a service as not provided, give “.” as the target address (instead of “mail.example.org.”). Please refer to RFC 2782.

and also the https://www.rfc-editor.org/rfc/rfc6186#section-3.4 states it

Both IMAP and POP3 non-TLS service types
are marked as not available.

  _imap._tcp     SRV  0 0 0   .
  _imaps._tcp    SRV  0 1 993 imap.example.com.
  _pop3._tcp     SRV  0 0 0   .
  _pop3s._tcp    SRV 10 1 995 pop3.example.com.

but you say that the client ignores this fact and tries to connect anyway?

esackbauer

I am sorry, you are correct. Was not aware of that RFC.
So I guess its fine to use “.” for not provided services.

SailReal

Thanks for the confirmation, I’ll give it a try 🙂

SailReal

For the record, I forgot to add _smtp._tcp SRV 0 0 0 ., the full list is of my SRV records is now

_imaps._tcp           SRV   0 1 993 mail.example.com
_smtps._tcp           SRV   0 1 465 mail.example.com
_submissions._tcp     SRV   0 1 465 mail.example.com

_submission._tcp      SRV  0 0 0   .
_smtp._tcp            SRV  0 0 0   .
_imap._tcp            SRV  0 0 0   .
_pop3._tcp            SRV  0 0 0   .
_pop3s._tcp           SRV  0 0 0   .

but the sad thing is that as otherwise guessed in https://community.mailcow.email/d/3803-disable-plain-ports-starttls-and-force-tls/6 the autoconfig endpoint still publishes port 143 and 587 with STARTTLS

      <incomingServer type="imap">
         <hostname>mail.example.com</hostname>
         <port>993</port>
         <socketType>SSL</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </incomingServer>
      <incomingServer type="imap">
         <hostname>mail.example.com</hostname>
         <port>143</port>
         <socketType>STARTTLS</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </incomingServer>


      <outgoingServer type="smtp">
         <hostname>mail.example.com</hostname>
         <port>465</port>
         <socketType>SSL</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </outgoingServer>
      <outgoingServer type="smtp">
         <hostname>mail.example.com</hostname>
         <port>587</port>
         <socketType>STARTTLS</socketType>
         <username>%EMAILADDRESS%</username>
         <authentication>password-cleartext</authentication>
      </outgoingServer>

Hmm I don’t think I can modify this behavior by changing what is documented here https://docs.mailcow.email/manual-guides/u_e-autodiscover_config/ 🤔

SailReal

I’m wondering why

mailcow/mailcow-dockerizedblob/master/data/web/autodiscover.php#L164-L185

is different than

mailcow/mailcow-dockerizedblob/master/data/web/autoconfig.php#L35-L48 and mailcow/mailcow-dockerizedblob/master/data/web/autoconfig.php#L73-L86

Especially in mailcow/mailcow-dockerizedblob/master/data/web/autoconfig.php#L51 and mailcow/mailcow-dockerizedblob/master/data/web/autoconfig.php#L62 we even check if pop3/s is set but not imap/smtp … I’ll create an bug report for it.

mlcwuser

In the quoted passage you posted, they are talking about email clients and client networks.

The link you provided points to “Hacked website or CMS.” And yes, a normal web server—or really any kind of server other than a mail server—should not communicate directly over port 25. Instead, it should use port 465 or 587 with authentication to send email notifications.

An email server, however, does need to communicate over port 25 in order to exchange emails with other mail servers.

Port 25 → used specifically for email server-to-email server communication (this is how mail transfer agents deliver mail between mail servers).

Ports 587 and 465 → used for email client-to-email server communication (this is how your mail app submits outgoing mail to a mail server, with authentication).