Problem Summary
I recently worked on a few cases where SharePoint “Access Request” e-mails are not delivered, but “Alert” e-mails work. Since Alert e-mail are working, we know that outgoing e-mail is configured properly. However, when users request access to a new site, the access request email would never make it to the site admin entered in the “Access Request Settings”.
Example:
Cause
Before getting into the cause, let’s talk about the difference between a normal alert e-mail and an “Access Request” e-mails.
A normal Alert e-mail will be sent from the SharePoint Admin account configured in the outgoing e-mail settings.
Alert E-mail:
However, an “Access Request” e-mail will be sent from the user making the request. So in this case, the SharePoint Application Pool account will attempt to impersonate the sender, so when the e-mail arrives in the Access Request Admin’s inbox, they will know who is requesting access by the e-mail sender.
Access Request E-Mail:
So now we know the different between “Alert” e-mails and “Access Request” e-mails, let’s get into why “Access Request” e-mails are not being delivered.
This issue is most likely caused by configuration of the Exchange Receive Connector. Before SharePoint 2019, SMTP authentication was not supported by SharePoint. So, SharePoint could only deliver e-mail without authentication. Any attempt to authenticate during the SMTP session would end with a failure.
If you are reading this you probably have an issue with “Access Request” e-mails, so let’s look at the ULS logs to determine what’s going on.
If you know which WFE is attempting to send the alert e-mail you can look at the logs in real-time using ULSViewer .
Then the filter to be category contains “e-mail”.
Now reproduce the issue by asking a user to request access to a site.
Looking at ULS, you may see the e-mail fails.
Let’s look closer at the exception:
Failed attempt 3 sending mail to recipients: mike@contoso.com. Mail Subject: User1 wants to access ‘Team Site’. Error: SmtpException while sending email: System.Net.Mail.SmtpException: Mailbox unavailable. The server response was: 5.7.60 SMTP; Client does not have permissions to send as this sender
at System.Net.Mail.DataStopCommand.CheckResponse(SmtpStatusCode statusCode, String serverResponse)
at System.Net.Mail.DataStopCommand.Send(SmtpConnection conn)
at System.Net.ClosableStream.Close()
at System.Net.Mail.SmtpClient.Send(MailMessage message)
at Microsoft.SharePoint.Email.SPSmtpClient.Send(MailMessage msg)
at Microsoft.SharePoint.Email.SPSmtpClient.TrySend(MailMessage msg)
We are seeing an SMTP error “5.7.60” ( I have also seen 5.7.1 for this issue) , which states 2 things, “Mailbox Unavailable” and “Client does not have permissions to send as this sender”.
So why is SharePoint trying to use authentication when it’s not supported? Good question! This seems to only effect SharePoint 2013.
However, during an e-mail impersonation attempt from SharePoint 2013, SharePoint will attempt use NTLM and authenticate as a user if offered by the e-mail server may fail after specifying “From”.
In summary, the failure is occurring because the impersonator (SharePoint Application Pool Account) does not have an Exchange Mailbox or does not have “send as” rights for the impersonated user (The person making the access request).
Resolution
This issue can be resolved a few ways.
-
Disable “Integrated Windows Authentication” from the default receive connector, so NTLM is not offered as a supported Authentication type. This will force SharePoint send the mail anonymously (as intended).
-
Disable the “Exchange Users” permission group from the default receive connector, this will cause the user Authentication to fail and SharePoint will fall back to anonymous.
- Create an Exchange mailbox for the Application Pool Account that hosts the SharePoint site and ensure that account is given “Send as” rights to all mailboxes.
Summary
In summary, SharePoint 2013 will use NTLM if offered and fail when attempting to impersonate a user due to a lack of “Send As” permissions. Most of the time this is due to the fact that the Application Pool Account does not have a Mailbox hosted in the Exchange Server or does not have “send as” rights.
More Information
See the following documents for more information:
Plan outgoing email for a SharePoint Server farm
https://docs.microsoft.com/en-us/sharepoint/administration/outgoing-email-planning
Configure outgoing email for a SharePoint Server farm
https://docs.microsoft.com/en-us/sharepoint/administration/outgoing-email-configuration