November 18, 2024 at 9:38 am
Hi all
We've got 3 servers with the same setup for dbmail.
They use the same account (just with a different display name as replies are ignored) and every was working perfectly until this weekend.
I've now only got 1 server out of the 3 that is correctly sending emails automatically.
Server1 is running SQL2012
Server2 is running SQL2016
Server3 is running SQL2022 (this is the only server that's sending emails correctly)
This is the error message we're getting:-
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 3 (2023-11-15T05:59:30). Exception Message: 1) Exception Information =================== Exception Type: Microsoft.SqlServer.Management.SqlIMail.MailFramework.Exceptions.BaseMailFrameworkException Message: Cannot send mails to mail server. (The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.0 Must issue a STARTTLS command first) Data: System.Collections.ListDictionaryInternal TargetSite: Void Send(Microsoft.SqlServer.Management.SqlIMail.MailFramework.Framework.IMessage) HelpLink: NULL Source: DatabaseMailProtocols HResult: -2146232832 StackTrace Information =================== at Microsoft.SqlServer.Management.SqlIMail.MailFramework.Smtp.SmtpMailSender.Send(IMessage msg) at Microsoft.SqlServer.Management.SqlIMail.Server.Controller.ProfileMailSender.SendMailToAccount(Account a, IMessageSender ms, OutMailItem si) 2) Exception Information =================== Exception Type: System.Net.Mail.SmtpException StatusCode: MustIssueStartTlsFirst Message: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.0 Must issue a STARTTLS command first Data: System.Collections.ListDictionaryInternal TargetSite: Void CheckResponse(System.Net.Mail.SmtpStatusCode, System.String) HelpLink: NULL Source: System HResult: -2146233088 StackTrace Information =================== at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response) at System.Net.Mail.MailCommand.Send(SmtpConnection conn, Byte[] command, MailAddress from, Boolean allowUnicode) at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, SmtpFailedRecipientException& exception) at System.Net.Mail.SmtpClient.Send(MailMessage message) at Microsoft.SqlServer.Management.SqlIMail.MailFramework.Smtp.SmtpMailSender.Send(IMessage msg). )
I've checked the setups on each machine and confirmed they are identical (except the display name as noted). I've made sure the SSL box is ticked on all 3 and the correct port number has been entered.
I've changed the password on the sending account (just in case it had expired) and updated it on all three machines. The SQL2022 box is still the only one that's sending emails.
ETA:-
According tot he DBMail logs, we're getting this error:-
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 10 (2024-11-18T09:19:48). Exception Message: Cannot send mails to mail server. (A call to SSPI failed, see inner exception.). )
Anyone any ideas where I go next?
TIA
Richard
November 19, 2024 at 8:24 am
Could it be that the 2022 box is using TLS 1.2+ and the others are using a lower (and now invalid) version?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
November 19, 2024 at 9:14 am
@phil - thanks for that.
Now just got to figure out how to check what each box is using.
November 19, 2024 at 4:23 pm
Are you sending via O365? SQL 2016 and below don't have DotNet set to use strong ciphers, and O365 says you need it.
There's a few things you need to change in DotNet 3.5 and the DotNet 4 registry keys to use strong ciphers, then reboot the server for it to take affect.
November 20, 2024 at 6:11 am
After doing some digging, it appears to be a TLS issue.
The working server was working on TLS1.2, while one of the non-working servers was on SSL/TLS (not TLS1.2).
I haven't had chance to check the other non-working server yet.
I've updated the TLS version on one of the non-working servers but it looks like I need to restart the SQLServer service for it to take effect.
Just working on getting authorisation to do that.
If that work, I'll post the full sequence of what I did in case it can help someone else.
Richard
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply