Dnn.Platform: [Bug]: Unable to make SSL connection to SMTP server
Is there an existing issue for this?
- I have searched the existing issues
What happened?
Created a test DNN v9.13.00 website. Attempted to set up an SSL connection to the SMTP server. Tested SMTP connection. Got failure message. See Current Behavior below.
Steps to reproduce?
- Created DNN v9.13.00 website on my workstation using NVQuickSite.
- Set up SMTP connection with the following settings: +++++++ SMTP server: strontium.namespro.ca SMTP port: 465 SMTP SSL: On Username: (my userid)@basilthetortoise.com Password: (my password) +++++++
- Clicked on “Save” then “Test SMTP Settings”. Connection failed with a “There is a problem with the configuration of your SMTP Server…” error message (see Current Behavior below).
Current Behavior
Expected Behavior
Used an online SMTP test service to make sure that the SMTP server was operating properly and there was no error in the credentials. The output is below:
Connected to smtps://strontium.namespro.ca:465/ << 220 outbound.strontium.namespro.ca ESMTP MailEnable Service, Version: 10.29-10.29- ready at 10/08/23 13:08:12
EHLO [172.31.11.248] << 250-strontium.namespro.ca [54.212.131.181], this server offers 4 extensions << 250-AUTH CRAM-MD5 PLAIN LOGIN << 250-SIZE 40960000 << 250-HELP << 250 AUTH=LOGIN AUTH CRAM-MD5 << 334 PDYxNjYwLjQzMzc1MDQ2OEBuYW1lc3Byby13aDI5Pg== bnA2MDUxM0BiYXNpbHRoZXRvcnRvaXNlLmNvbSAzNTdmMGU5YWNkZDI3ZmIyMTE5NjZmZGI3Y2Q4MjQwMg== << 235 Authenticated CRAM-MD5 MAIL FROM:np60513@basilthetortoise.com SIZE=576 << 250 Requested mail action okay, completed RCPT TO:steve.karpik@outlook.com << 250 Requested mail action okay, completed DATA << 354 Start mail input; end with <CRLF>.<CRLF> From: np60513@basilthetortoise.com Date: Sun, 08 Oct 2023 19:08:09 퍍 Subject: SMTP test from strontium.namespro.ca Message-Id: 22F42BMX6LU4.72FL4XX3TPWL2@WIN-AUIR3RRGP88 To: steve.karpik@outlook.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=“=-wg/fb0gvPkmBW78cwmOnxQ==”
–=-wg/fb0gvPkmBW78cwmOnxQ== Content-Type: text/plain; charset=utf-8
Test message –=-wg/fb0gvPkmBW78cwmOnxQ== Content-Type: text/html; charset=utf-8 Content-Id: 22F42BMX6LU4.NUO6X6245L1Y@WIN-AUIR3RRGP88
Test message –=-wg/fb0gvPkmBW78cwmOnxQ==– . << 250 Requested mail action okay, completed
Relevant log output
none
Anything else?
nothing
Affected Versions
9.13.0 (latest release)
What browsers are you seeing the problem on?
Microsoft Edge
Code of Conduct
- I agree to follow this project’s Code of Conduct
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 27 (15 by maintainers)
I think the simple solution here might be the middle ground between what we have now, and what I posted earlier which is closer to what @jeremy-farrance has posted.
For example two options
The second option is only there if you have selected “Use SSL” and we would need to provide good help text. We could also go with “Reject Untrusted Certificates” or similar to flip it to the negative side of things.
Given the risk of what can happen without the verification, it should be noted that it is not recommended to disable this unless it is being done for a trusted/known reason. The primary thing that could be caught by this is a Man In the Middle type attack where downstream the communications are redirected, as well as expired or untrusted SSL certificates.
Yes! That is much cleaner
Sounds good to me. I was thinking of wording like “Allow Invalid Certificate”
@mitchelsellers - I agree that my solution leaves much to be desired from a security perspective. The dilemma for me is that if we stick with the status quo, DNN websites that use shared hosting and have less than optimal SSL certs would not be able to use SSL at all but would have to use an unsecured option. Your solution gives the DNN user an option if they are going to degrade security but it might be hard for people to wrap their heads around.
I am hoping that someone can come up with something better than I propose. However, the fact that my solution comes directly from the MailKIt documentation makes me think that this is not an uncommon situation and the workaround is rather unsatisfactory.
Maybe we need some way of telling the user that the SMTP server has a name mismatch and asking whether they want to continue. I run into this with FileZilla (an FTP program). Often I make connections where the ftp server has a different name than my website URL but it is the URL for the webhost and I proceed because it all looks sensible.
I agree that we’d need to provide an option for whether to ignore the certificate validation (does the core implementation ignore the certificate automatically?).
I would tend to think that we leave the protocols set to the default, unless someone has a specific case where they need to override that.
@jeremy-farrance and @mitchelsellers - I suspect that both of you are pointing in the direction of a solution. I will join the Open Coding session on Discord this Friday that @david-poindexter mentioned above. This problem with SSL SMTP presents an excellent opportunity for me to learn how to debug and solve this sort of problem.
@skarpik I strongly suspect a TLS issue as noted by @jeremy-farrance
Given that this is a new host, is it possible they have a firewall rule that is preventing communication as well?
You may also want to try port 587 instead per guidance here (https://stackoverflow.com/questions/20228644/smtpexception-unable-to-read-data-from-the-transport-connection-net-io-connect)