bug report: `SSL_TYPE=none` should not disable STARTTLS for outbound SMTP connections about docker-mailserver HOT 8 OPEN

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

To address your concern regarding the SSL_LEVEL=none configuration and its impact on smtp_tls_security_level and smtpd_tls_security_level, it's important to clarify the purpose and effect of these settings within the Docker Mailserver (DMS) context.

When SSL_LEVEL is set to none, it is typically used in scenarios where SSL/TLS is not required or desired, such as in internal networks or specific testing environments. However, your point about the potential need for STARTTLS even when SSL_LEVEL=none is set is valid, especially considering the increasing adoption of mandatory TLS for email transmission to enhance security.

The smtp_tls_security_level parameter controls the use of TLS for outgoing connections from your mail server to other mail servers. Setting it to none disables TLS for outgoing connections, which could indeed prevent your server from sending emails to servers that require TLS.

The smtpd_tls_security_level parameter controls the use of TLS for incoming connections to your mail server. Setting it to none disables TLS for incoming connections, which affects servers trying to deliver emails to your server with TLS.

Your observation suggests that there might be a need to differentiate the handling of incoming and outgoing TLS configurations when SSL_LEVEL=none is set. Specifically, it might be beneficial to allow smtp_tls_security_level to default to a more secure setting (like may or encrypt) that attempts to use TLS if available, without mandating it, thus not entirely disabling the capability for outgoing emails to use STARTTLS when possible.

This differentiation would ensure that, even in configurations where server certificates are not used or needed (e.g., when acting solely as an outgoing relay), the server can still participate in secure email transmission practices as required or preferred by other servers.

Given the context of your inquiry and the potential implications for email delivery security, it would be advisable to raise this concern as a feature request or discussion in the Docker Mailserver GitHub repository. This would allow the maintainers and community to evaluate the suggestion and consider adjustments to the handling of SSL_LEVEL=none in relation to smtp_tls_security_level and smtpd_tls_security_level.

For now, if you require STARTTLS for outgoing emails while having SSL_LEVEL=none, you might consider manually adjusting the smtp_tls_security_level in your configuration to a value that enables TLS for outgoing connections, bearing in mind the potential need to balance security requirements with your specific use case.

This comment was generated by Glime.

from docker-mailserver.

Why would someone not want opportunistic STARTTLS? I would argue someone could disable it via user-patches or the main.cfg overrides in the very unlikely scenario they don't want it.
And there are domains already requiring STARTTLS to receive mail at all, so the safe default is "smtp_tls_security_level=may" (which is postfix default).
I also fail to see a connection between SSL_LEVEL (used for server-certificate configuration) and simply using TLS for connections to other sites - having that disabled as well just because I don't want a server certificate is baffling to me.

from docker-mailserver.

If you're going to identify the line in source... at least read the relevant comments please 😑

This is not intended for anyone to use in production. IIRC it's mostly legacy for the test suite until it's updated to move away from that, if you use git blame you should find my PR that introduced the refactor (before this became the ssl.sh helper file) and I elaborate that I wanted a change where this would hard fail for users IIRC.

Perhaps my recall is a bit muddy, it is an option documented:

That said, I do agree with you that smtp_tls_security_level = may should be fine to leave as-is. I don't see any reason that would break the test suite or cause a problem for anyone using this (not that they should if they get that early startup warning though...).

I also fail to see a connection between SSL_LEVEL (used for server-certificate configuration) and simply using TLS for connections to other sites - having that disabled as well just because I don't want a server certificate is baffling to me.

The project received various contributions from others before I and other active maintainers got involved, just look at the issues to see a variety of concerns identified that need to be addressed.

I helped clean up this from what it once was, but I don't think I tampered with it too much beyond that. This feature is due for another refactor in future with breaking changes but we're all stretched for time, so if you'd like to contribute improvements that'd be greatly appreciated :)

from docker-mailserver.

Setting smtp_tls_security_level=none makes no sense, there's no reason nor need to disable it.

Please elaborate.

I actually think setting both to none makes sense! You can always patch smtp_tls_security_level via user-patches.sh.

from docker-mailserver.

Yes I read the docs and they don't apply to my use case, and those also don't explain why it disables not only "smtpd_tls_security_level" but also "smtp_security_level" (What can it break? Nothing comes to mind). Why would I want or need to have an SSL certificate when my setup uses docker-mailserver only as an outbound relay from a trusted server network? I have no need to verify the server, I have no need to authenticate the clients, so I don't need a certfificate, but I still like to authenticate servers out in the internet that do have a certificate and more importantly, without STARTTLS some of those servers just won't talk to me.

from docker-mailserver.

TL;DR: I'm open towards a PR changing the logic to only affect smtpd_ variant of the setting.

You raise valid concerns, but someone needs to have time to address them properly, there are plans to refactor that helper script quite a bit, making most options redundant for it.

Yes I read the docs and they don't apply to my use case, and those also don't explain why it disables not only "smtp_d__tls_security_level" but also "smtp_security_level" (What can it break? Nothing comes to mind)

I'm going to take a guess that this is just what was contributed at the time by someone, that it wasn't thought out much 🤷‍♂️

I've come across that sort of thing quite a few times. Some contributions are whatever worked for someone, and the review process wasn't as thorough, especially when it's for more niche or tricky topics that the reviewer did not have the time or interest to understand the scope well enough to question it.

When I refactored here, I probably just adapted what was already there in this case, and added some notes for context as it wasn't the main focus of what I was doing at the time.

Why would I want or need to have an SSL certificate when my setup uses docker-mailserver only as an outbound relay from a trusted server network?

You don't have to, but it's not particularly difficult to provide your own internal cert either. Some clients will happily use TLS without verifying too as TLS with mail traffic is often more relaxed than HTTPS.

I still like to authenticate servers out in the internet that do have a certificate and more importantly, without STARTTLS some of those servers just won't talk to me.

That's fair.

The docs are rather clear that they disable TLS when you use that option, and that's what they do. That option also omits a warning not to use it in production.

You could probably use the undocumented snakeoil option that we're using in our test suite. That won't verify successfully for any client that attempts to when connecting to DMS, but that doesn't sound like a concern that matters to you. Alternatively you can easily fix that with postfix-main.cf or user-patches.sh in the meantime.

I'm open towards a PR that changes the referenced sed to only adjust smtpd for that setting. I think the only time we're adjusting it above the may default is in relay.sh to enforce requiring TLS. As long as the test suite passes (and I don't know why it wouldn't), that can be approved and merged 👍

Just to confirm:

• You're also using SMTP_ONLY=1 right? No need for Dovecot, you're only using DMS as a null mailer/client?
  • If this were the case you are generally advised to have the clients submit mail on port 587/465 with authentication, or a bit less advised via a trusted subnet.
  • You can deliver to port 25 to relay. Which while you're probably fine doing so, like with the wider trust of a subnet to bypass security checks, you're not as secure against a compromise. It's minimal effort to have the clients use credentials IMO but that's your call 👍
• Do you have a reachable postmaster address and MX record set for somewhere else? It usually doesn't look good when you avoid this and some mail servers may consider you suspicious which can affect your delivery success too.
• You're not using our Relay Host feature at all right? Some still would with the setup you have which can also avoid the problem you've run into. I only mention this as some bugs/inconsistencies have since been fixed for this feature with the upcoming v14 release.

Offtopic: That glime response is really impressive! 😱

from docker-mailserver.

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment

from docker-mailserver.