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
