-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use appropriate standard port when setting SSL/TLS #105
Comments
Thanks for the issue and the offer to send a PR. The fact that we use port 25 as the default is on me. I've been using 25 as default for too long already, but I 100% agree that we should follow the RFC and not personal "defaults". So yes, if you are willing to provide a PR, it's more than welcome. Otherwise I'll gladly take this. |
Since some people might rely on the current default, we should mark this change as BREAKING in the release notes, though. |
How about adding new methods with the newly described logic:
And deprecating the old ones? This way it wouldn't constitute a breaking change and code relying on the old behavior won't break. |
Sounds good to me. |
This change enables automatic use of ports 465 and 587 when SSL or TLS is configured. Fallback options to port 25 are also provided. Updates wneessen#105 {WIP}
I don't think this is a bad idea, quite a convenient one. I do think the spec may have been misread however for future reference. I read it as MUA's connecting to specific ports should assume and/or enforce specific TLS modes based on the port in question. In specific what I think was misread is that it's not implying the use of STARTTLS means port 587, but rather the use of port 587 implies the use of STARTTLS (similar for Implicit TLS). Looking at that I'd propose what I think you've already proposed:
I'd also separately (i.e. separate PR) propose:
|
Thanks for your inpuit James. Valid points indeed and I second the newly proposed changes. @muhlemmer Let me know if you want to take these as well or if I should take them |
Introduced default ports for SSL/TLS and STARTTLS connections in SMTP client. Also added fallback behavior, allowing the client to attempt connections on port 25 using plaintext if secured connections fail. Deprecated old methods and implemented new ones to enforce these changes effectively. This is a copy of the PR muhlemmer:enhance-default-tls-port by @muhlemmer. Since they unfortunately didn't reply in the PR anymore I cloned the PR. They will be fully attributed in the PR, though.
The update modifies the client's handling of port selection when configuring SSL/TLS connections. The clients' functions `WithSSLPort`, `WithTLSPortPolicy`, `SetTLSPortPolicy`, and `SetSSLPort` are revised to avoid overriding previously set ports. Additionally, the deprecation notes have been removed and replaced with notes on best-practice recommendations, referring the new *Port*() methods. This change revises #105 and takes the comments made in #181 into account.
Is your feature request related to a problem? Please describe.
When using SSL or STARTTLS, the default port 25 is always used, which is against best practices as described in RFC8314, section 3.3.
I'm willing to implement and send a PR if this enhancement is accepted.
Describe the solution you'd like
WithSSL()
to use the port default of 465, unlessWithPort()
is called;WithTLSPolicy()
withTLSMandatory
orTLSOpportunistic
to use port 587, and in case of the latter use fallback to port 25;Describe alternatives you've considered
Explicitly setting the port number with
WithPort(587)
works in my case. My mail server does not allow fallback to plain text SMTP on port 25. But if it where the case, I expect thatTLSOpportunistic
would not work as intended, as it will always try to use port 587, instead of falling back to 25.Additional context
To reproduce:
Or
Will result in connection failures to compliant hosts.
The above was inspired by the bulk mailer example, which doesn't seem to set an alternative port either.
The text was updated successfully, but these errors were encountered: