SharePoint Access Request e-mails are not delivered, but alerts work

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

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:

 

clipboard_image_11.png

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.

 

clipboard_image_12.png

 

 

Alert E-mail:

 

clipboard_image_13.png

 

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:

 

clipboard_image_14.png

 

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 .

 

clipboard_image_15.png

 

 

Then the filter to be category contains “e-mail”.

 

clipboard_image_16.png

 

 

Now reproduce the issue by asking a user to request access to a site.

 

clipboard_image_17.png

Looking at ULS, you may see the e-mail fails.

 

clipboard_image_18.png

 

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”.

 

Example:

 

clipboard_image_19.png

 

 

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.

 

  1. 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).

 

1.PNG

 

 

 

  1. 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.

 

2.PNG

 

 

  1. 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

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.