-
Notifications
You must be signed in to change notification settings - Fork 78
[SECURITY] Option to enforce STARTTLS #23
Comments
+1 - would like to see this as well. |
@sfllaw Thanks for opening this issue. I take security very seriously and would love to see improvements in the way go-mail handles secure communication and authentication. With that in mind, I'm not sure if you've already seen this, but there is a I'm curious if you've encountered a case where STARTTLS was your only option? I'm concerned that an additional option will only add confusion and make a misconfiguration more likely. If anything, it may be a good idea for us to improve our documentation on what options are available for SSL/TLS negotiation. Edit: Clarifying that |
@ivy I have run into cases where the remote server doesn't support SMTPS, because the legacy 465 port is not open. I recommend we create a new |
@sfllaw Thanks for clarifying. I wasn't aware that SMTPS was a deprecated protocol, that changes everything. 😅 I'll review your PR shortly. |
A fix was merged in b93a540. |
Update Go versions / refresh linters
mail/smtp.go
Lines 98 to 105 in 1e5036a
This code only tries to upgrade to a TLS connection if the server reports that it supports the STARTTLS extension. If an attacker intercepts the SMTP connection and responds that the extension is unknown, then they can prevent TLS from being turned on.
It would be backwards incompatible to expect STARTTLS by default, but we can make an option that would enforce a STARTTLS connection.
Of course, if the connection is already protected by SSL, then STARTTLS is unnecessary.
The text was updated successfully, but these errors were encountered: