Do not publish IMAP/SMTP in autoconfig.php if disabled via SRV record

[SailReal]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
• ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
• ... I have understood that answers are voluntary and community-driven, and not commercial support.
• ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

In https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/autodiscover.php#L164-L185 we only publish TLS ports. In https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/autoconfig.php#L35-L48 and https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/autoconfig.php#L73-L86 we publish TLS and plain ports.

In https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/autoconfig.php#L62 and https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/autoconfig.php#L51 we already check if POP3/s is enabled via SRV record so checking against SRV records wouldn't even be something new.

To address https://www.usenix.org/system/files/sec21-poddebniak.pdf I "disabled" plain ports via

_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 due to the code in autoconfig, they are still published for this endpoint only.

In the docs in https://docs.mailcow.email/getstarted/prerequisite-dns/#the-advanced-dns-configuration is stated

SRV records specify the server(s) for a specific protocol on your domain. 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.

Also the mentioned RFC https://www.rfc-editor.org/rfc/rfc6186#section-3.4 says

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

in

      _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.

I can also not fix it by adjusting something mentioned in https://docs.mailcow.email/manual-guides/u_e-autodiscover_config/

Please honor disabled SMTP and IMAP as well for the autoconfig endpoint.

Logs:

.

Steps to reproduce:

1. Disable imap and smtp via


_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   .

2. Check the autoconfig output e.g. via curl https://autoconfig.example.com/mail/config-v1.1.xml. It should not contain IMAP and SMTP on plain ports.

Full output of the xml

<?xml version="1.0"?><clientConfig version="1.1">
    <emailProvider id="mail.example.com">
      <domain>%EMAILDOMAIN%</domain>
      <displayName>A mailcow mail server</displayName>
      <displayShortName>mail server</displayShortName>

      <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>

      <enable visiturl="https://mail.example.com/admin.php">
         <instruction>If you didn't change the password given to you by the administrator or if you didn't change it in a long time, please consider doing that now.</instruction>
         <instruction lang="de">Sollten Sie das Ihnen durch den Administrator vergebene Passwort noch nicht geändert haben, empfehlen wir dies nun zu tun. Auch ein altes Passwort sollte aus Sicherheitsgründen geändert werden.</instruction>
      </enable>

    </emailProvider>

    <webMail>
      <loginPage url="https://mail.example.com/SOGo/" />
    </webMail>
</clientConfig>

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Not relevant

Server/VM specifications:

Not relevant

Is Apparmor, SELinux or similar active?

Not relevant

Virtualization technology:

Not relevant

Docker version:

Not relevant

docker-compose version or docker compose version:

Not relevant

mailcow version:

2024-06a

Reverse proxy:

Not relevant

Logs of git diff:

Not relevant

Logs of iptables -L -vn:

Not relevant

Logs of ip6tables -L -vn:

Not relevant

Logs of iptables -L -vn -t nat:

Not relevant

Logs of ip6tables -L -vn -t nat:

Not relevant

DNS check:

Not relevant

[mkuron]

Good find, I forgot IMAP and SMTP when I implemented the SRV record checking. Would you please submit a pull request to add that?

[SailReal]

Thanks for your fast response and yes, I can create a PR for it.

[SailReal]

@DerLinkman as we reverted 384e5a2 can you please reopen this issue?

Will create another PR to actually fix the issue as discussed in #5945 (comment) :)

[SailReal]

@DerLinkman this is still an issue, can you please reopen this ticket?