SMTP client fails due to missing automatic migration
Which migration code that you are talking about? What is the steps to reproduce the issue?
@sebastienros seemed to know what was missing on the dev branch - "we changed the smtp client that is used, didn't think it would cause a migration issue
on the dev branch at least"
Repro, start with a build prior to the smtp client change, configure & test smtp successfully, update nuget and smtp fails.
Error message: An error occurred while sending an email: 'An error occurred while attempting to establish an SSL or TLS connection. One possibility is that you are trying to connect to a port which does not support SSL/TLS. The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons: 1. The server is using a self-signed certificate which cannot be verified. 2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. 3. The certificate presented by the server is expired or invalid. See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions.'
we changed the smtp client that is used, didn't think it would cause a migration issue
on the dev branch at least
I am the one who made this change 😊 that is why I am interested on this
Thanks for the details explanation, seems I can't test this while it requires a certificate stuff, I will wait for @sebastienros because he knows the details as you mentioned
This might be a problem with the code, see this section:
https://github.com/jstedfast/MailKit/blob/master/FAQ.md#1-the-mail-server-does-not-support-ssl-on-the-specified-port
Can you give more information about the host you are connecting to?
smtp.office365.com
port 587
O365 user & pass
Just tested another project and the same account and settings work on earlier builds
Thanks I think I can try that, unless @hishamco does it too if he has an office365 account
Unfortunately I didn't have an account, but I think I can test this case if I'm using my Gmail account. Am I right?
we should also test gmail, right, I will test office and see what's missing.
Not sure if this is relevant, but I was doing some googling...
MailKit C# SmtpClient.Connect() to Office 365 generating exception
"Handshake failed due to an unexpected packet format
The solution is to connect to Office 365 like this instead:
smtpClient.Connect("smtp.office365.com", 587, SecureSocketOptions.StartTls);"
After a bit more searching I believe this is due to the authentication using ssl rather than TLS which is what O365 wants (even though their docs don't really mention it).
I'm assuming an option to select the authentication mode (SSL:true, TLS:SecureSocketOptions.StartTls) needs to be added to settings, but I don't know how to tackle this one..?
Gmail will be completely different since it require OAuth or a few tweaks to the gmail account (enable less secure apps, etc.)
@jonvee could you try this in the source code client.AuthenticationMechanisms.Remove("XOAUTH2") after connecting but before authenticating
I added client.AuthenticationMechanisms.Remove("XOAUTH2"); to line 137 in SmtpService.cs but that made no difference for O365, I'm not using Gmail so I'm not sure if that's what needed there or not.
Why not use use something like that await client.ConnectAsync(_options.Host, _options.Port, _options.EnableSsl ? SecureSocketOptions.Auto : SecureSocketOptions.None);
(i did not test it , i don't have an O365 account) , see https://github.com/jstedfast/MailKit/blob/e9dee7febf94b1e75b0db070e02c9b61115a830f/MailKit/Net/Smtp/SmtpClient.cs#L1340 it will use the protocol based on port. Later, if issues encountered, we could explicit add the secure protocol in settings.
more info : https://www.fastmail.com/help/technical/ssltlsstarttls.html
I'm not sure if that's correct or not, but the error is slightly different now:
"An error occurred while sending an email: 'An error occurred while attempting to establish an SSL or TLS connection. The SSL certificate presented by the server is not trusted by the system for one or more of the following reasons: 1. The server is using a self-signed certificate which cannot be verified. 2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. 3. The certificate presented by the server is expired or invalid. See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions.'"
So it may be that NOW it fails due to using a self-signed cert..?
I can't test a legit cert without putting it on a production domain, so I'm not sure how to test or even move forward.
@sebastienros Any suggestions?
If it is due to invalid ssl certificate, as the article explains, if you add this before client.ConnectAsync in OrchardCore.Email would fix your issue
client.ServerCertificateValidationCallback = (s,c,h,e) => true;
But it is not recommended, so it is better to test with smtp4dev or temp folder and go live with valid certs on SMTP server
If the error is talking about the cert on the SMTP server, then I misunderstood, I thought it was talking about the website/orchard cert. I'm sure O365 is using using a valid certs
I have not test it, but from my understanding, the client does not trust the certificate presented by the remote machine (as long as the STARTTLS option is used). If you can build from source and use the generated packages, you could test the SecureSocketOptions.Auto in conjuction with ServerCertificateValidationCallback mentioned previously in the thread.
Sadly I'm just getting my head around theming and templates so I'm not sure how to tackle this issue... I just brought it up on Gitter and filed it. I found some info from googling, but I really have no idea how to debug or test this module or its underlying features.
no worries, it will be fixed :)
@jonvee I just tested with an O365 account. If you set SSL to true, you instruct the smtp client to establish an SSL transport connection, which is not the case for office 365 and you receive the error message you mentioned. I unchecked the SSL option, and it worked - with the latest sources
Leaving SSL unchecked using latest beta3-71319 Nuget packages on a new app gives the same error... I'll try with a source clone now.
Same results :(
Works fine with last "stable beta" release & ssl checked (nuget beta3-71077, not dev)
Hi @jonvee , when you get some time could you please replace the smtpservice.cs in OrchardCore.Email.Services with the one in the zip file for test? Also enable the SSL flag in SMTP settings
If this works, i can send a PR
SmtpService.zip
Thanks @MichaelPetrinolis !!! Works great!
Cool, I will create a PR. The suggestion is to rename enablessl to auto configuration, and add another setting eg socket option which will default to none, and have possible values none, TLS, SSL and STARTTLS.
Awesome guys, thanks a lot
@MichaelPetrinolis @sebastienros
Since the merged changes, I'm seeing the same errors again.
@jonvee the difference between the dev version and the one in the zip is in these lines
client.ServerCertificateValidationCallback = (s, c, h, e) =>
{
_logger.LogInformation("SMTP Server's Certificate was invalid, will force it valid");
return true;
}; in the SendOnlineMessage function.
If this is the case, then the machine that runs OC and tries to send the email, does not accept the server's certificate. I suggest to check the clock of the machine, and the list of trusted roots certificates. It is not wise to override the certificate validation on production machines
Sorry for the delayed reply. This doesn't really make any sense to me. I should be able to use an office365 account without jumping through any hoops. It works in previous versions, it works on other apps and I just don't understand why there are any issues at all. I'm not using an SMTP relay, I'm authenticating a user, just like any mail app. Wish I new how to debug this, but I don't so until someone else demonstrates how to use an O365 account to send mail I can't even use the dev branch to test workflows, forms or user registrations.
I'm using it with latest changes and it seems to work with office 365.
@Skrypt can you take screenshots of your settigns for @jonvee ?
BTW "Locataire" for "Tenant" translation sounds weird to me.
C'est beau! Merci @agriffard
C'est une traduction parfaite, ça y'a pas de doute. Je suis probablement pas habitué au terme français.
"Tenant" pour moi me semble plus distinctif du fait que c'est une instance de site web... tandis que "Locataire" je me demande "Locataire de quoi" ? Et une location c'est comme un espace "emprunté" alors qu'ici c'est un espace bien déterminé et qui n'a pas de sens rapproché avec "Locataire". Bah... du coup je vais m'habituer ! Merci @agriffard 😄
Ya, those settings don't work, tried with multiple O365 accounts in completely disparate subscriptions.
Not sure which Root or Intermediate certificates are missing locally as I'm sure smtp.office365.com is using valid certs.
Should I try a complete reinstall of VS? I haven't upgraded to VS 2019 yet, should I?
My website is on Azure is it your case?
I'm testing locally...
I have few VMs running IIS in azure, but haven't actually tried deploying as an azure web app
Ok, that may be the issue. You need to test it on your server else the O365 server might refuse simply the email because of his spam policies.
That's not ideal for dev/testing but I'll try it now and let you know.
For dev/testing you should never really send emails ; that's why we added the local folder as an option.
The VMs running IIS in Azure should work since they should use trusted IP addresses.
@Skrypt you still want to know if your settings are correct before deploying.
The issue with spam detection is that there isn't much to do against it.
I can try locally if you want too. I will test it and report what I found here.
Worked for me from localhost.
At this point the only thing I can think of is that his internet provider is preventing the use of port 587. ~You could try port 993 which is the IMAP port~.
Unfortunately the best I can do is use a self-signed cert on a production server which yields the same results as locally. Without purchasing a domain and ssl for testing I can't do much more and I'm not about to do that for every project I'm working on.
It was working before ... so that weird that the new library can't get it to work. What kind of email address is that? outlook.com or a custom domain?
Seems odd that I have issues on a server in azure and locally, yet the beta 3 version from nuget (pre-mailkit) works great
sorry for mentioning it again, but some years ago i had faced an issue where the client pc did not accept the certificate as valid due to clock mismatch. The code @jonvee tested was ignoring server certification validation errors. If you are not running any fiddler with SSL decryption or something similar, could you double check the time of your local machine ? (the certificate is issued to smtp.office365.com which is valid)
Custom domains in Business E3 O365 subscriptions, not Outlook.com or hotmail
I'm thinking that maybe the domain name has been blocked from the Exchange 365 server since you tried a lot of times without success by using SSL instead of TLS previously. But then with Outlook or any other email software you should not be able to receive or send emails either.
The ultimate option would be to copy the old module, rename it, and use it. Then if we find more instances of this issue we might be able to find what's common between them.
I had to copy/paste the OrchardCore.Email module on top of my current website dev branch even after doing a merge of the dev branch. Maybe he needs to update the OrchardCore.Email module manually too.
If you don't mind I will remove my images 😉
Clocks on both local machine and servers in azure are synced to the internet and seem to be accurate.
@jonvee if you want to investigate more, try to telnet on port 587 from the machine that has the problem and use SMTP commands to send the mail
That would be a good test.
This is the first thing I was doing when I was teaching internet at uni.
Give me your password, I will try for you ;)
my password is : dontshare@123
i remember back in '93, telnet was a nice way to trick other students that received email from Bill Gates himself :) (on AIX)
Using powershell I can successfully send email with the following commands:
$msolcred = get-credential
Send-MailMessage –From [email protected] –To [email protected] –Subject “Test Email” –Body “Test SMTP Relay Service” -SmtpServer smtp.office365.com -Credential $msolcred -UseSsl -Port 587
When you are trying with Orchard Core is it from your website based code or from the Orchard Core dev latest? Maybe there is a difference between both. The other thing I would try is to launch the OC dev branch from your computer by command shell using "dotnet run" without involving anything else than .NET Core itself. No IIS or IISExpress.
All setup in VS, new web app, no custom anything just the latest (prerelease) from myget and selecting the blog recipe.
I'll try command based and see how that plays out
Can you use the source code and add this? https://github.com/jstedfast/MailKit/blob/master/FAQ.md#ProtocolLog
Connected to smtp://smtp.office365.com:587/?starttls=always
S: 220 MWHPR14CA0011.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 30 May 2019 15:27:30 +0000
C: EHLO [IPv6:::1]
S: 250-MWHPR14CA0011.outlook.office365.com Hello [xxxxxxx]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 SMTP server ready
That's all I get from the console log... Just ref'd mailkit.security and changed line 44 in SmtpService.cs to
using (var client = new SmtpClient(new MailKit.ProtocolLogger(Console.OpenStandardOutput())))
Launching from VS/IIS express there are no SSL browser errors, but when launching from console I immediately get a warning about the self-signed cert forcing me to click through the prompts to view the site. No idea if this is expected or even related.
@jonvee could you add the following code at line 130 (in SendOnlineMessage function)?
client.ServerCertificateValidationCallback = (s, c, h, e) =>
{
_logger.LogError($"SMTP Server's Certificate with subject {c.Subject} was invalid with policy errors {e}.");
return e == System.Net.Security.SslPolicyErrors.None;
};
If the certificate is invalid, will display the Subject and the SslPolicyErrors
fail: OrchardCore.Email.Services.SmtpService[0]
SMTP Server's Certificate with subject CN=outlook.com, O=Microsoft Corporation, L=Redmond, S=Washington, C=US was invalid with policy errors RemoteCertificateChainErrors.
could you add the following lines under _logger.LogError in order to get the chain status ?
`csharp
for (int i = 0; i < h.ChainStatus.Length - 1; i++)
{
_logger.LogError($"{i} = {h.ChainStatus[i].StatusInformation} : {h.ChainStatus[i].Status}");
}
So it can't validate the certificate chain?
This looks like a local environment issue.
yep
Related discussion on MailKit: https://github.com/jstedfast/MailKit/issues/307
With some code example to pass-through the validation errors, though this is not the solution. We might want to add an advanced setting though to allow untrusted certificates. Or display the actual issue when a Test message fails.
After much toiling and Googling, I've disabled Avast's outbound mail scanning on my dev machine and mail is now flowing. I haven't disabled this in production, but I suppose that's the best solution for now (not sure how/why Outlook and other apps are unaffected by this).
Should have thought about this earlier, but it was never an issue before.
What happens is the message is opened by Avast, then after scanning, signs the message with it's own certificate.
Tested with beta3-71653
I mentioned in https://github.com/OrchardCMS/OrchardCore/issues/3556#issuecomment-497081601 to check if anything interfere between your pc and smtp server, It would have saved you lot of time. the debug output of the PR for certificate pinning might also help you
I didn't even know I had that feature enabled... Must have been a default setting as I recently built my current workstation and that setting is kinda burried in the avast nonsense ui. Still curious why no other apps have this issue though.
for curiosity, when/if the #3735 is merged and you have time, enable the avast email scanning to see the errors from certificate validation....
Most helpful comment
Cool, I will create a PR. The suggestion is to rename enablessl to auto configuration, and add another setting eg socket option which will default to none, and have possible values none, TLS, SSL and STARTTLS.