Docker-mailserver: Impossible to relay to port 465

[Yajo]

Context

I'm trying to use this container as a relay to other SMTP servers. Let's say Gmail. If I use port 465 to relay, it doesn't work.

Expected Behavior

Although the recommendation seems to be port 587, port 465 should work too.

Actual Behavior

Not working.

Possible Fix

Relay to [smtp.gmail.com]:587 instead.

Your Environment

• Amount of RAM available: 8G
• Mailserver version used: tvial/docker-mailserver@sha256:6791fac577bee0ede15bcea81dcafd40be153647a8859f562ac08dbe12c33e82
• Docker version used: 18.06.1-ce
• Environment settings relevant to the config:

yaml DEFAULT_RELAY_HOST: '[smtp.gmail.com]:465' DMS_DEBUG: 0 ENABLE_SRS: 1 MAIL_RELAY_PASS: **** ONE_DIR: 1 PERMIT_DOCKER: connected-networks POSTFIX_MESSAGE_SIZE_LIMIT: 52428800 RELAY_HOST: smtp.gmail.com RELAY_PASSWORD: **** RELAY_PORT: '465' RELAY_USER: ****@example.com SMTP_ONLY: 1 SRS_DOMAINNAME: example.com SRS_EXCLUDE_DOMAINS: example.com SRS_SENDER_CLASSES: envelope_sender,header_sender

• Any relevant stack traces ("Full trace" preferred):

It prints a lot of logs like these:

mar 13 10:59:32 server.example.net c50a483a8a8e[1077]: Mar 13 09:59:32 c50a483a8a8e postfix/smtp[3611]: SMTPS wrappermode (TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger) mar 13 10:59:42 server.example.net c50a483a8a8e[1077]: Mar 13 09:59:42 c50a483a8a8e postfix/smtp[3607]: 515E558039E: to=<[email protected]>, relay=smtp.gmail.com[74.125.193.109]:465, delay=455, delays=445/0.01/10/0, dsn=4.4.2, status=deferred (lost connection with smtp.gmail.com[74.125.193.109] while receiving the initial server greeting)

@Tecnativa TT22925

[erik-wramner]

Interesting, I didn't even know that we had that feature. Anyway, the logs seem to provide the answer:

SMTPS wrappermode (TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt"

The option is described in http://www.postfix.org/postconf.5.html and is needed when using the "legacy SMTPS protocol instead of using the STARTTLS command", i.e. with port 465.

So, set the required options in config/postfix-main.cf, re-create the container (docker-compose down and up) and see if it works!

[Yajo]

Oh I tested that a lot, but I was missing this part:

docker-compose down and up

I thought that the entrypoint reconfigured everything and restarting the container was enough.

Thanks, with that it works.

[Yajo]

So is that the official fix? Wouldn't it make sense to supply smtp_tls_wrappermode = yes by default? (The other parameter is already OK)

[erik-wramner]

Probably not, I would guess that it is more common to use STARTTLS as Postfix documents SMTPS as a legacy protocol. Unless there is a good reason we try to go with the upstream defaults, it helps people who have a Postfix background.

[polarathene]

I've been learning about SMTP lately and trying to get my head around the ports, security, and general setup.

Port 465 has a bit of history, 587 was defined earlier and 465 got fairly quickly revoked and treated as legacy due to some software having already implemented it, thus other software and services kept support for 465 around.

Port 465 also got reassigned for a new purpose, but now shares that again with the original implicit TLS usage since 2018 RFC. My understanding is that it's intended to phase 587 out and encourage 465 going forward, but likewise with the history 465 has had, it'll be a slow transition as 587 is extensively documented/advised as the preferred choice, and well supported and in use with much software today, along with the conflicting history that port 465 has which many of those with SMTP experience perhaps will take time before knowing about the 2018 RFC to bring port 465 back and encourage it's adoption.

I would guess that it is more common to use STARTTLS as Postfix documents SMTPS as a legacy protocol.

Sooo... documentation is likely outdated. SMTPS was a legacy protocol, but no longer is to be treated as such.

My understanding of port 587 is it's intended to cover the use case of port 25 for message submission(MSA, delivery to mailbox?) requiring authentication to avoid the spam open relay issue that port 25 exposes, which is now generally only intended to be treated for message transmission(MTA, relay server to server?). 587 supports plaintext with no encryption as fallback if the connection cannot negotiate the StartTLS handshake for secure transit.

Port 25 is thus advised to be closed from public internet and only used within your internal network(eg Docker networks, no mapping/exposure to the host/internet), unless you need to support MTA to MTA afaik? Instead we expose 587/465 publicly and a mail client like ThunderBird external to the server can send emails by authenticating username/password of an account, while any docker services on the same internal network to the SMTP container(running postfix) can avoid authentication and the existence of an actual account being setup(I'm unsure about that one) and just send e-mail with whatever address for the domain they choose(eg [email protected]).

For port 587 to mitigate vulnerabilities from downgrade attacks, either DANE(requiring DNSSEC) or MTA-STS(also defined in 2018 afaik) can be used to enforce only secure transit, so that no user/pass is leaked by a MitM attack. That does have a potential drawback of disregarding any connection that is unable to support TLS and only supports plaintext, although how likely you'd run into that being an issue is unclear to me.

Additionally MTA-STS/587 adds more work/effort to secure, plus is only compatible with software that supports StartTLS. Where that may become an issue is with reverse proxies(I'm not entirely sure if these have any real relevance with an SMTP service, I've heard they can cause issues with incoming IP address source affecting spam protection such as with SpamAssassin), nginx does have config support for SMTP ports handling StartTLS(no clue how that works with Postfix, especially with this project), but others like Traefik and Caddy do not.

Traefik can handle TLS over TCP though, and perhaps manage the LetsEncrypt cert request/renewals(unclear if the traefik router should use passthrough for TLS here, or terminate and map to a different port, like 443 to 80 with HTTPS). This should be a non-issue with port 465, but more hassle or not an option for reverse proxies with port 587, making it easier to just expose those ports separate from the reverse proxy.

---

TL;DR

Port 465 is relevant today and should not be discouraged.

• Since 2018, port 465 is no longer considered legacy, and is intended to encourage adoption of implicit TLS over explicit TLS(port 587 / StartTLS).
• Port 587 needs DANE or MTA-STS to match TLS enforcement for secure transit and avoid risk of exposing user auth details.
• If reverse proxy is involved, less hassle and/or better compatibility with port 465 vs 587(needs StartTLS support).

[polarathene]

RFC 8314(2018)

Section 3.3

Implicit TLS is the end-goal:

It is desirable to migrate core protocols used by MUA software to Implicit TLS over time, for consistency as well as for the additional reasons discussed in Appendix A.

Port 587 with STARTTLS is still relevant to support during this transition:

However, to maximize the use of encryption for submission, it is desirable to support both mechanisms for Message Submission over TLS for a transition period of several years. As a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period.

587 and 465 are equivalent in security provided the implementations on both ends are correct and TLS is enforced(Not always the case with 587):

Note that there is no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465 if the implementations are correct and if both the client and the server are configured to require successful negotiation of TLS prior to Message Submission.

Section 7.3

Port 465 was originally intended as secure/TLS version of Port 25 as an MTA/relay, but wasn't practical to deploy?:

Historically, port 465 was briefly registered as the "smtps" port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service.

Prior to being revoked, 465 was deployed and misused for secure message submission instead of transmission.

In hindsight, the "smtps" registration should have been renamed or reserved rather than revoked. Unfortunately, some widely deployed mail software interpreted "smtps" as "submissions" [RFC6409] and used that port for email submission by default when an end user requested security during account setup.

That alternative usage as a submission port became common place, and thus the port in 2018 is retained for implicit TLS message submission(MSA). Leveraging current software/service implementation for the port and avoiding further issues(see RFC for further reasoning on sticking with 465):

Although STARTTLS on port 587 has been deployed, it has not replaced the deployed use of Implicit TLS submission on port 465.

Appendix A

Supporting plaintext / cleartext operation is to become legacy, in favor of TLS only operation:

The desirable end state is that these protocols always use TLS, leaving no need for a separate port for cleartext operation except to support legacy clients while they continue to be used. The separate-port model for TLS is inherently simpler to implement, debug, and deploy.

Enables better load-balancer / Reverse Proxy support:

It also enables a "generic TLS load-balancer" that accepts secure client connections for arbitrary foo-over-TLS protocols and forwards them to a server that may or may not support TLS.

587 needs MTA-STS or DANE for TLS enforcement:

Although STARTTLS appears only slightly more complex than separate-port TLS, we again learned the lesson that complexity is the enemy of security in the form of the STARTTLS command injection vulnerability

[Yajo]

Wonderful insight. Then should we reopen this? :thinking:

[erik-wramner]

No. The current image does support the feature and I certainly don't want to change the default. It is aligned with upstream and it is what existing installations expect. Feel free to improve the documentation though.

[polarathene]

It is aligned with upstream and it is what existing installations expect.

Fair point with wanting to follow postfix upstream, but IETF standards would technically be further upstream/official, and what installations going forward should expect(lots of outdated information on port 465, even in 2020 articles being published, just because someone reads that and expects it to be truth, doesn't mean it is).

Wonderful insight. Then should we reopen this?

I'm not actually sure if I've grokked this specific issue/request. You mention relay, which port 465 was originally intended for as a secure version of the SMTP port 25 known as SMTPS, but it ended up being treated as a secure submissions port and that's what it's officially become since 2018.

Thus like with port 587, authentication is expected. Transmission between servers where no authentication is needed to relay, remains the job of port 25. STARTLS is valid for port 25 and there is no risk of leaking credentials here, other than the email content may be relayed in plaintext(which afaik can happen anywhere across a chain of relays to reach the destination SMTP server, so isn't really enforceable on your end alone?).

There is MTA-STS which providers like Google promote for enforcing secure transit and opting out of sending if the other party won't support TLS connections, or alternatively one could use DANE, but that has even lower adoption afaik. If you want to enforce secure transit/relay, then you'd likely want to setup MTA-STS.

So what is being discussed here exactly? Submission(current for 465) or Relay(legacy 465)? For submission, implicit TLS via port 465 seems far better to support vs port 587 due to unreliable conformance across parties/clients, and additional vulnerabilities you have to workaround by setting up MTA-STS/DANE afaik? Less headache/effort for 465 and I would personally prefer that for submission when possible.

Ideally this project would make 465 easy to use due to being easier to provide secure submission for users of the project. Many likely place trust in the maintainer(s) here to know better than them and provide sound advice in the documentation along with defaults. Not everyone can allocate enough time to get a more thorough understanding of best practices(which is another example of trusting upstream like postfix to know best and have up to date documentation, so one could easily say this should be brought up with them rather than handled here).

---

Some clients only submit email to port 465, while others only 587:

Usually mail clients like Thunderbird submit outgoing emails to SMTP server over port 587, encrypted with STARTTLS. However, some mail clients (particularly Microsoft Outlook) can only submit outgoing emails over port 465, the SMTPS port. By default, both iRedMail and Modoboa only enables submission over port 587.

Also points out that IETF since 2018 are promoting port 465 for message submission(client to server) and MTA-STS(additional effort) for message transmission(server to server, port 25):

Now IETF believes that the STARTTLS approach isn’t perfect and started promoting the use of implicit TLS. It published RFC 8314 in January 2018 to encourage the use of port 465 for email submission, and RFC 8461 in September 2018 to encourage the use of MTA-STS for secure SMTP. Port 465 is likely to be renamed as the submissions port.

Linked article above also covers guide on what needs to be done for postfix to enable/support port 465, if that's of interest.

A list of popular email providers/services and their default ports can be found here, both Google and Yahoo are listed with ports 587 and 465, though many of the others do support 465 too, so it's unclear why both are presented for those two big providers.

RFC 8461 - MTA-STS

Arrived a little later in 2018 after RFC 8314. Primary purpose seems more aimed towards MTA-to-MTA over port 25 in a secure manner(refusing transmission if TLS is not available), but still valid for other use cases of STARTTLS, although it'd seem IMAP/POP3 generally opt for the TLS only ports for security, and that it's being advised to do the same for submission with port 465 instead of 587.

Problem with STARTTLS(plaintext ports that can upgrade to secure, 25,587,110,143):

While this opportunistic encryption protocol by itself provides a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform downgrade or interception attacks.

MTA-STS and DANE can be deployed together, but care must be taken with the MTA-STS policy:

The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.

MTA-STS needs another DNS record(TXT):

The MTA-STS TXT record is a TXT record with the name "_mta-sts" at the Policy Domain. For the domain "example.com", this record would be "_mta-sts.example.com".

MTA-STS protects against two attacks(downgrade to plaintext, impersonation - redirecting mail to attackers server):

SMTP MTA-STS attempts to protect against an active attacker trying to intercept or tamper with mail between hosts that support STARTTLS.

---

Google provides a transparency report about encryption transit stats where their SMTP servers are involved. Inbound email encryption is at 94%, while outbound is at 85%(90% if you ignore some automated monthly ones that aren't using encryption).

Do take note of the support for encryption inbound/outbound section with email domains, red filter, shows aliexpress/alibaba, aol.com(via AWS), costco, yahoo japan and such as having 0%, so some big names would fail to transmit securely if you only supported 587 with MTA-STS or 465, as they'd only send plaintext it seems. Otherwise, for the bulk of relevant e-mail, you should be ok enforcing TLS.

---

TL;DR:

• More justification for 465 as a better choice vs 587.
• Unclear if this issue is requesting 465 to be used as a submission port(current purpose), or the legacy SMTPS transmission port(TLS version of port 25) which ended up being used as a submission port rather than relay afaik.
• I'm possibly misinformed somewhere, hopefully linked resources aren't.

[polarathene]

Since credentials are shown in the example config for relaying to gmail, I think this issue is describing your own server authenticating to gmail MTA like someone would with say ThunderBird to your own hosted MTA on 587/465 to submit mail to send/relay to a different mail host/MTA like gmail/outlook/yahoo?

Seems like a valid reason to prefer port 465. If that's not something docker-mailserver wants to support, perhaps having the documentation advise and link to an alternative docker image that does cater to that use case is ok?

Maybe one of these(if @Yajo would be kind to verify, or perhaps has a need with docker-mailserver that these don't cover?):

• vimagick/nullmailer - Has an example using port 465, might be viable?
• juanluisbaptiste/postfix - Postfix SMTP TLS Relay
• freinet/postfix-relay - Postfix SMTP Relay, mentions DKIM support
• turgon37/smtp-relay - Another Postfix SMTP relay, seems to have focus on applying some constraints/security?
• namshi/smtp - Regular SMTP server, 2nd SMTP server, Gmail/SES relay or generic relay/smarthost, most popular here at 10M+ pulls.
• bytemark/smtp - Exim SMTP server that can relay too, 500k+ pulls but hasn't been updated in 2 years..

Only one of those really makes it clear if port 465 is supported out of the box. The postfix ones might also need to get additional configuration to use 465 instead of 58. Meanwhile, docker-mailserver actually mentions port 465 on it's README:

465 SSL Client email submission

Note: Port 25 is only for receiving email from other mailservers and not for submitting email. You need to use port 465 or 587 for this.

There's nothing there about not supporting it for relay config like described here. The wiki relay host section has examples with ports 587,25,2525, but nothing on 465 or mention of it. As it's valid for Gmail, I guess something should be said there? Any reason for not having a way to toggle/enable the support? Does it require some additional dependencies / hassle to support? Or only a config change?

[polarathene]

Having gained a more thorough understanding of SMTP, the postfix docs on the smtpd_tls_wrappermode feature are now more clear to me.

Legacy SMTPS as referred to in the docs is correct. Although port 465 has become official and encouraged for use since 2018 with RFC8314 as has been discussed, it is specifically intended only for message submission now.

smtpd_tls_wrappermode appears to have originally been only intended for preferring implicit TLS via port 465 rather than STARTTLS on port 25, not 587. Note how there is no usage of credentials which is now required for 465(as does 587). It's become implicit TLS for port 587, rather than for port 25.

Thus 465 should not be used for relaying between MTA servers, that's still meant to be done via port 25 with STARTTLS and possibly MTA-STS to enforce TLS transit between the two MTA servers. 465 is legacy for that purpose.

As an MSA, port 465 is now valid, and this also allows for MTA clients that are submitting to an MTA server to relay the email. When available, it's the better choice to opt for afaik, less can go wrong? (less risk of incorrect deployment compared to 587)

If you need to support third-party clients while hosting a MTA server, then you may want to still support 587 without enforcing TLS for better compatibility of delivery, just like with port 25 for receiving mail if that 10% of inbound mail being unencrypted potentially covers emails that should be delivered from known businesses(it's also sort of mandated iirc that plaintext on 25 should be receivable when publicly exposed to internet).

---

TL;DR

| Port | MSA => MTA | MTA => MTA | Needs Auth | Secure |
|--------------|------------|------------|------------|---------|
| 25 | :confused: | :+1: | :-1: | :shrug: / :sunglasses: |
| 465 Legacy | :confused: | :+1: | :-1: | :+1: |
| 587 | :+1: | :-1: | :+1: | :shrug: / :sunglasses: |
| 465 RFC 8314 | :+1: | :-1: | :+1: | :+1: |

Legend:

• :+1: Yep
• :-1: Nope
• :confused: Possible, but prefer submission port for authenticating external access.
• :shrug: Needs STARTTLS. May not establish TLS connection, may leak credentials. Depends on config/implementation between both parties. More Info.
• :sunglasses: Secured by MTA-STS / DANE enforcing TLS. Should be as good as implicit TLS now.
• MSA => MTA - Your hosted server acting as a client to submit email(MSA) to another server(MTA) to handle delivery. MUA(email clients like Mutt, ThunderBird, webmail, etc) can substitute MSA here too.
• MTA => MTA - SMTP server to server, relaying to destination, no authentication in use? Most likely at a stage out of your control for ensuring security in transit if multiple relay hops.

Conclusion

smtp_tls_wrappermode=yes being applied to port 465 is encouraged, assuming it doesn't negatively impact anything else, eg ports 25 / 587 with STARTTLS should still work the same.

As it's no longer meant to be a TLS variant of port 25, it should require auth(SASL?) so that it functions as a submission port only like 587, I still don't know postfix configuration well enough to know if anything else needs to be done.

[polarathene]

@erik-wramner This projects DockerHub mentions support for port 465, and it is clear that it's about submission. That leaves me a bit confused what this issue is about.. Why would the port be supported and noted as a submission port, but going against spec by using(safe to assume?) STARTTLS on it?(which AFAIK, it never has been used that way)

The wiki SSL section shows some port mapping of 465 in docker-compose, some openssl test commands(no -starttls), but then several occurrences of mentioning port 465 as an imap TLS port for dovecot?? The wiki installation example section has another example of connecting to the SMTP host/server on port 465 with username/pass.

smtp_tls_wrappermode doesn't seem to be mentioned in various wiki pages. If this is required to actually use TLS properly on port 465 and according to spec, then it should be enabled when providing port 465(which I assume postfix is not providing this port configured upstream?). Should all documentation be stripped about port 465?

Perhaps I've misunderstood, and 465 is working fine until you want to use it with a relay host like in this issue? The postfix docs didn't seem to be describing the functionality as only applicable to relay hosts, and presumably is required to support MUA => MTA too? Something seems to be conflicting here..

[polarathene]

This same issue came up in Aug 2018, in which the response was to read the wiki on overriding the default postfix config, albeit that wasn't very informative/helpful to the user in that issue, who'd likely need a little bit better of an understanding, a good place to document a common use case is there. Although this doesn't appear to be valid for defining some config(eg smtps before it was added directly).

In this issue, erik advises to use the implicit TLS port for IMAP, unsure of STARTTLS support(which 143 may support, but can have same concerns/risks that 587 has). The user also wonders if they're advised to use implicit TLS for IMAP, should they use the same for SMTP, but received no response. Preferring implicit TLS where possible is easier to understand and should be sound advice?

In this issue, erik advises using 465 too, and the user responds that they were confused as the docs referred to 465 as for SSL, and 587 for TLS, which is fair as I also was a bit confused why SSL/TLS was being differentiated like that, another area where docs could improve for new users to reduce confusion.

Another issue with erik promoting port 465. The user seems to mix up port 25 with STARTTLS and port 465 legacy, which didn't require credentials to be supplied. They also cite mixed experience with mail clients, which is probably because some still treat 465 as legacy implicit TLS for port 25, while others have treated it as submission port requiring auth(or needs additional configuration for such, I'm not sure yet if that's something on mail clients, or if they only bother with auth when the MSA requests it).

In this issue, erik explains to a user why they can't use port 465 to connect to another MTA like gmail or qq. While the user seems to be mixing up port 465 with 25, erik clarifies 465 should receive auth but only communicates it as valid for MUA => MTA, not MSA => MTA (my terms might not be entirely correct there). Google has some additional requirements to setup, but can serve as a SMTP relay/smart host where port 465 can be used with auth for this purpose, thus you can end up with something like MUA(ThunderBird) => MSA(your server) => MTA(google server), where the user authenticates with user/pass to the MSA, and your MSA authenticates via different credentials afaik.

Here a related issue of a setup similar to the prior one, with MUA(java app) => MSA(docker-mailserver) => MTA(external third-party server). The MUA => MSA if on the same server could use port 25, or 587/465 if external, as should the relay MSA => MTA, which they've clarified has no relation to the MUA => MSA auth. Note the mention that TLS is enabled for relay host, although that option has since been replaced by smtp_tls_security_level but afaik is being set to STARTTLS in this project as it's only catered for 587.* Default is empty, so not following upstream here?* Thus port 465 could also be treated properly for relays?

Finally, support for port 465 by default isn't upstream, but docker-mailserver provides it for MUA => MTA since 2017, prior to RFC 8314 the following year, hence why support for relays may be missing? However, do note that in the commit, not only is smtp_tls_wrappermode enabled, but so is smtpd_sasl_auth_enable to enforce requiring auth. That acknowledges it as a submissions port. smtpd_tls_security_level=encrypt is not listed there, and reading of docs don't seem to state it as required for port 465(wrappermode kind of implies it? but I'm not certain).

Author of this project also states they prefer this project to support best practices over upstream btw:

the goal of this image is to include the best practices natively.

Right, well I think that concludes the investigation on this issue :stuck_out_tongue: Hopefully serves as useful to anyone else who starts learning about SMTP and gets confused about all this stuff when trying to understand security and usage. If I have time, I might see if I can improve the docs.

---

TL;DR

The current image does support the feature and I certainly don't want to change the default. It is aligned with upstream and it is what existing installations expect.

@erik-wramner that statement seems to be false given the above.

So is that the official fix? Wouldn't it make sense to supply smtp_tls_wrappermode=yes by default?

@Yajo It already appears to be enabled by default? I've yet to setup this container and verify, but rather than providing port 465 as a value, try smtps instead. At least, that seems to be how port 465 has been supported in this project.

[Yajo]

Well, my case is far simpler because I'm mostly using this image as a local relay for external public SMTP services. I just stopped relaying to port 465 and it all keeps working like a charm, and in fact I clearly advise my project users to not use that port.

However if I'd use this image to set up a public SMTP service myself, I'd certainly expect it to be clear about what ports to publish and why.

SMTP is very complex as can be seen here, and reading RFCs and postfix docs requires way more coffees than it should. The fact that this project provides sane defaults is a very big step forwards towards making the SMTP landscape more sysadmin-friendly, but indeed some short and readable docs on these subjects would help the world maybe even more than this project itself.

@polarathene Thank you very much for your investigation. :pray: Please don't stop here; please publish some easy-to-understand docs. This thread is great to understand, but most people will just go tl;dr when if they find this.

[polarathene]

SMTP is very complex as can be seen here, and reading RFCs and postfix docs requires way more coffees than it should.

Yeah, I didn't really want to go that far myself, but now that I need to support SMTP in production, it's important not to mess it up. Far too much vague or conflicting information out there :disappointed:

some short and readable docs on these subjects would help the world maybe even more than this project itself.

I'm looking at collating my own notes on the subject and contributing them to the wiki of this project. Should be valuable enough for others and hopefully reduce the need to go down the rabbit hole, or worse bailing on common topics to understand due to the effort.

Starting with this PR that better clarifies the ports and touches on some important notes to be aware of. Updating wiki to expand on that will take more time..

most people will just go tl;dr when if they find this.

I know :) you only end up in a thread like this when other avenues have failed, ideally no one needs to go as deep as I did or even end up viewing this thread.

---

Well, my case is far simpler because I'm mostly using this image as a local relay for external public SMTP services. I just stopped relaying to port 465 and it all keeps working like a charm, and in fact I clearly advise my project users to not use that port.

If you have the option to use port 465 to relay to a smart host(eg SendGrid), it's probably a better choice. Although as long as you trust them, you should be fine with whatever afaik, since you only have to worry about a specific connection between you and them, many to one(inbound emal to your server) or one to many(sending directly to each address yourself), where trusting third-parties to do things securely is a gamble, especially if no auth is required.

I see you use port 587 in your project, afaik that should be fine/safe in this scenario. I don't understand why you would advise against port 465 after viewing my responses here, other than any friction from needing to change config(which is fair, and this project should probably not require you to).

[Yajo]

other than any friction from needing to change config(which is fair, and this project should probably not require you to).

Yes, that's the reason.

[Yajo]

The current image does support the feature and I certainly don't want to change the default. It is aligned with upstream and it is what existing installations expect.

I'm thinking... couldn't we ping postfix devs, so they might consider updating their defaults? :thinking:

[polarathene]

couldn't we ping postfix devs

I looked into that while sharing my research here several days ago. They don't seem to have any public bug tracker or anything that I'm used to. Seemed like you had to send an email(not entirely surprised there..), they still use an old mailing list (which requires membership somehow) to communicate.

Anyway, the text you quoted about upstream doesn't really apply. I pointed this out earlier in the thread, the docs are about legacy usage of the port. This image has configured it as the docs describe but with the addition of requiring authentication, it's just mapped as smtps instead of port 465, again that follows the docs example.

The main docs that erik referred to setup the server to require an encrypted connection with implicit TLS for any port/connection afaik, and then relay that to port 465 of a relayhost. A little confusing, as I don't think smtp_tls_security_level=encrypt matters if you require smtp_tls_wrappermode=yes, the TLS docs they provide doesn't mention it being required, or shown in the example for smtps(465), it's not set for this image configuration either, only for smtp(25) and submission(587).

EDIT: Docs clear it up that smtp_tls_security_level is ignored when using smtp_tls_wrappermode=yes :wink:

I guess I somehow overlooked that :sweat_smile: