Thursday, 25 January 2018

SharePoint Issue (on-prem) - Document Library with incoming email

A - OBJECTIVE: 

We have a case in which emails cannot be sent from SharePoint 2010 Foundation to SharePoint 2013.

The issue can be described in several ways:

1. Document Library with incoming emails cannot receive emails.
2. Emails get stuck in the folder Drop at the server (under C:\inetpub\mailroot).
3. SharePoint cannot send emails to itself to prevent infinite loop.

B - PROBLEM:


Expected Result: In this particular case, we have 2 SharePoint environments (2010 Foundations & 2013 Enterprise) and we would like to send emails from SharePoint 2010 to the other. 

Scenario:
  • In the folder Drop of the mailroot, all emails dropped there can be processed, except those emails sent from SharePoint 2010.
  • The stuck emails were sent from an external SMTP IP address.
Some test cases have been done pertaining to email notification as follows:
  • Test 1 - SharePoint 2013 to SharePoint 2013: An simple workflow is created at another SharePoint 2013 site to send email to the expected SP2013 site. It works.
  • Test 2 - Manual Email: using a Powershell script to send an email from the SharePoint2010 server, we could receive emails properly at the SharePoint 2013 site.
# manually send emails from the SharePoint 2010 server
$fromemail = "sp2010@mydomain.com"
$users = "anthonynhn@mydomain.com","sp2013@mydomain.com" 
$SMTPserver = "202.12.34.567"
send-mailmessage -from $fromemail -to $users -subject "Manual Email Test" -BodyAsHTML -body "Message goes here" -priority High -smtpServer $SMTPserver


Troubleshooting:
  • Stuck emails were picked from the folder Drop and compared to successfully delivered emails in test 1 and test 2.
  • The issue is from the SharePoint site because the email can be delivered to the folder Drop, and we should look for the email header.
After comparing the files .eml , it turned out that the error is because of this line:





C - SOLUTION:

The issue is created by design to avoid an infinite loop in SharePoint, where you can find the code at SPEmailEngine.HandleEmailFile



string str4 = message.Headers["X-Mailer"];
if (!string.IsNullOrEmpty(str4) && string.Equals(str4, "Microsoft SharePoint Foundation 2010", StringComparison.OrdinalIgnoreCase))
{
    return null;
}

The solution is therefore to remove the X-Mailer line in the email header to intentionally bypass the emails:
  • Solution 1: to directly modify the email header at the network level (Ironport in my case).
  • Solution 2: to remove the problematic X-Mailer line soon after an .eml mail is sent to the folder Drop, following these steps thanks to this blog:

1. copy Smtpreg.vbs into the c:\inetpub\AdminScripts - smtpreg is available to download from MS.

2. create a vbs file from the script below and copy it to the AdminScripts folder (I named mine wss)

<SCRIPT LANGUAGE="VBScript">

Sub ISMTPOnArrival_OnArrival(ByVal iMsg, EventStatus )

if iMsg.Fields("urn:schemas:mailheader:x-mailer") = "Microsoft SharePoint Foundation 2010" then
iMsg.Fields.Delete("urn:schemas:mailheader:x-mailer")
iMsg.Fields.Update
end if

iMsg.DataSource.Save
EventStatus = 0
End Sub

3. run the following commands to register the script

cd c:\inetpub\adminscripts
cscript smtpreg.vbs /add 1 OnArrival DeleteMsg CDO.SS_SMTPOnArrivalSink "mail from=*"
cscript smtpreg.vbs /setprop 1 OnArrival DeleteMsg Sink ScriptName "c:\Inetpub\AdminScripts\wss.vbs"


D - REFERENCE: 

Some interesting articles pertaining to this matter:
  • An overview of incoming emails (SharePoint 2013): https://bernado-nguyen-hoan.com/2013/06/18/solving-sharepoint-2013-incoming-mails-stuck-in-drop-folder/
  • A solution to the above issue: http://sharepoint-uk.blogspot.com.au/2008/03/wss-emailing-itself-x-mailer-windows.html