Dnn.platform: TimeOut when testing host SMTP parameters on SSL

[edisfera]

Description of bug

Using SMTP connection on port 465 with SSL and testing the specified parameters always results to a Timeout if target host only supports implicit SSL.

Steps to reproduce

Just try using the following parameters and test to see a timeout:
host: smtps.aruba.it:465
enable ssl: on
smtp username: set at any value, test will never get to the point of using it
smpt password: set at any value, test will never get to the point of using it
smtp authentication: basic

Current behavior

Test hangs until a timeout occurs.

Expected behavior

A proper connection and a successfull send of the test email.

Error information

Test will add the following error messate to the EventLog:
AbsoluteURL:/API/PersonaBar/ServerSettingsSmtpHost/SendTestEmail
DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke
ExceptionGUID:c74b358f-b88b-49cc-87e1-2132543fb65a
AssemblyVersion:
PortalId:-1
UserId:-1
TabId:-1
RawUrl:
Referrer:
UserAgent:
ExceptionHash:YtkkCJ66Rwp9mcQRpSQZr7zQ+MI=
Message:The operation has timed out.
StackTrace:
at System.Net.Mail.SmtpClient.Send(MailMessage message)
at DotNetNuke.Services.Mail.Mail.SendMailInternal(MailMessage mailMessage, String subject, String body, MailPriority priority, MailFormat bodyFormat, Encoding bodyEncoding, IEnumerable`1 attachments, String smtpServer, String smtpAuthentication, String smtpUsername, String smtpPassword, Boolean smtpEnableSSL)
InnerMessage:
InnerStackTrace:
Source:System
FileName:
FileLineNumber:0
FileColumnNumber:0
Method:
Server Name: XXXXXX

Additional context

The timeout error is caused by this library: System.Net.Mail. According to this post (http://www.systemnetmail.com/faq/5.3.aspx) this library only supports explicit SSL, that is it expects port 25 to be open so that it can send a start TLS on it and switch to port 465 then after. If port 25 is not open, the library times out.
This is not a bug of DNN in itself, but because it is using a System DLL that does not support implicit SSL (directly starting with encryption), it makes impossible to use it with providers like Aruba (in Italy one of the biggest providers of internet services and cloud solutions) that expects the use of implicit SMTP on their SMTP service.

Affected version

• [ X] 10.00.00 alpha build
• [ X] 09.06.01 release candidate
• [ X] 09.06.00 latest supported release

[valadas]

host: smpts.aruba.it:465

Could it just be a wrong host here (smpts instead of smtps) ?

[edisfera]

Hi valadas sorry that was just a typo... I edited the original post to fix the error

[edisfera]

As I said is a limitation of the library... In my modules that send emails through Aruba services (or to be more generic that do not support implicit SSL) I have used the MiailKit library to sort out this limitation of the System.Net.Mail.

[valadas]

@edisfera Ok cool, it was just something that I noticed and though maybe that would be it :)

[thabaum]

I have seen issues in the past as well similar to this one. Is it a hosted email server? any reason the submission port is closed?

[edisfera]

It is not a hosted email server, is more a SaaS for the email as it could be Outlook.com or Gmail.com. The provider decided not to implement the explicit SSL (being port 25 keept open to send start TLS on it in order to switch to encription on port 465). If you check the link I put in my post it appears that not supporting implicit SSL in System.Net.Mail was a choice of the developer as the specification allow for both methods. However if the endpoint decides to implement the other one method there is no way to circumvent it other than choose a different dll to connect to it. If the module is developed by myself than I can choose to adopt another dll as I did indeed. But if I need the DNN Platform to connect to a service that only accept implicit SSL, I cannot change the core to use a different dll to make it work unless this is addressed by the developement team of the core that decide to use a dll that allow for implicit or explicit SSL.

[valadas]

The core is open source, pull requests are welcome if you are a developer.

[thabaum]

Have you tested this since the last PR I submitted that was included in 9.6.2. I changed the email accounts used for testing. This issue had been bugging me for decade that is why it sounded familiar.

I was logged in as host noticed the old behavior so I checked on it a bit further and found the logic I had included was only in the administrator users and not used for host. I have not had a good testing environment so I believe I wanted to be sure the Administrators testing would work ok first for everyone without being a regression issue.

A host user was not using the same test SMTP logic as an administrator due to there being a separate SMTP controller file for administrators and host. I had corrected the logic in 9.6.2 for the Host smtp controller if this makes any sense you may want to give it a test and see if it is still an issue.

I just want to check this is still an issue because it would make SMTP fail for me and was very frustrating for like I said a very very long time. I think this bug issue had been getting submitted by users since back in 2004.

[thabaum]

@edisfera can you please test again using the latest release, thank you.

[edisfera]

@thabaum I did a fresh install of 9.6.2. I then filled out the SMTP parameters in Settings -> Servers as specified at the beginning of this Ticket and pressed the Test SMTP Settings button. Result is the same, the issue is still there. I am afraid that to solve this issue (that only happens with smtp servers that support only implicit SSL to establish a connection with a client) the only viable solution is to get rid of the Net.Mail.SmtpClient DLL and use an alternative one that supports both implicit and explicit SSL. In the past I had a similar issue with a module of ours where we were using the SmptClient and we were enable to connect to an smtp server (namely Zimbra) until we replaced the DLL with another one (we used MailKit, but ofcourse there are many others out on the internet). If I can help you with anything else, just let me know.

[valadas]

@dnnsoftware/approvers opinions on changing this library from a dependencies/maintenance perspective ? Any .net recommendations regarding mail.

[bdukes]

AFAIK MailKit is the library that's typically recommended. That said, it would be nice to make email sent via a provider, so that folks who use a mail service like SendGrid can send email using their API instead of just over SMTP, if they want. But I'd accept an upgrade to MailKit by itself, if that change came in.

[valadas]

Oh yeah, a mail provider would be awesome, I am thinking about testing too 😁 Would be nice to just have mail dumped in a folder on staging and dev sites for instance...

[mitchelsellers]

I would REALLY like to see this swapped over to a provider model as I think that would be a huge improvement

[david-poindexter]

Agreed 💯

[meetmandeep]

We'll start dev on moving it to provider model.

Do we have consensus to move to MailKit or should we just keep core functionality for now and move to provider model and then implement MailKit at a later date?

[bdukes]

:+1: from me for MailKit

[mitchelsellers]

I'll second the mailkit thumbs up

[david-poindexter]

MailKit

[meetmandeep]

I've submitted a pull request for CoreMailProvider with existing functionality for now. I'll follow up with another pull request migrating from System.Net.Mail to MailKit.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[donker]

Move to MailKit is under way.