Incoming email from "SharePoint" does not get saved

Question

I have a process set up that would send an email confirmation to the user who submited an item using my InfoPath form. No problems there at all.

The problem I am having is with a document library I created in which I enabled incoming email settings. The settings are set to "Accept e-mail messages from any sender." It seems that if I personally send an email to the newly created email address, it stores it without any problems. However, the original email comes not from a person but from [email protected]. Is there a known problem where emails sent from that generic email address will not be stored into a document library?

I made a rule in my Outlook to forward emails to the new email address to store a copy of the original email. But why is it not acceping emails from [email protected]? Anyone?

For example, I recieved an email where "To" field has my email address and document library's email address. That email did not appear in the document library. If I hit "Reply all" and send that email, it appears in the document library. Mistery!

Answer 1

The first thing I would check is how you have security setup on the library. It sounds like it is configured to only accept requests from users with write access - thus a generic address not associated with a user will not get saved. To verify this go into the library settings and under communication section find the incoming email link. You will find the security setting in here. There are only two options, it's either those with write permissions or everyone.

If the above is already set to anonymous then next is to check and see if it is hitting your SMTP folder and SharePoint is picking it up. You can use Powershell or Telnet to generate test messages against your SMTP server to observe this behavior. This is a bit more advanced. Your drop off folder will be configured in your SMTP server settings. You can generate an email via Powershell with this:

Send-MailMessage -to "[email protected]" -from "[email protected]" -SmtpServer "<SMTP Server Address>" -Subject "test message" -Body "Test body"

1. If you are not seeing a message hit your drop folder you have a routing problem. This means your SMTP server never gets the message.
2. If it's making it into the drop folder but not getting picked up - you have configuration problem. Check to ensure SharePoint knows where the drop off folder is.
3. If you see it get picked up from the folder - then your problem goes back to the first item with the folder rules. Mail is being delivered and SharePoint is picking it up and processing it.

Answer 2

I'm answering this 7 years after the question was asked, but I had the same problem with SharePoint 2016 and wanted to add a couple of additional pieces of information to @Jesus_Shelby's excellent response...

1. If you are not seeing a message hit your drop folder you have a routing problem. This means your SMTP server never gets the message.

(nothing to add from what @Jesus_Shelby said)

2. If it's making it into the drop folder but not getting picked up - you have configuration problem. Check to ensure SharePoint knows where the drop off folder is.

Check the permissions on the Drop folder. In my case I needed to allow read/write access for the appropriate account. I think this would be the account that is running the SharePoint Timer service, but I am not sure. In my case it was a dev environment and I just gave "Everyone" Full Control on C:\inetpub\mailroot (the folder that contains the Drop folder). Looking at the ULS logs helped me realize that this was the problem as I saw an error there indicating:

A critical error occurred while processing the incoming e-mail file C:\inetpub\mailroot\Drop\112bee9301d746a200000001.eml. The error was: Access to the path '112bee9301d746a200000001.eml' is denied..

BTW, if you use ULS Viewer, creating a filter and setting Category = "E-Mail" helps filter things down to what you want to see.

Another reason it may stay in the drop folder is if the email address the email is going to does not match the email address for the incoming email setting on the library. You should see an error in the ULS logs if this is the case as well.

Errors occurred processing 1 message(s): Message ID:    The following aliases were unknown: <alias>

The alias part above is the first part of the email address it was sent to (the part before the @ sign).

3. If you see it get picked up from the folder - then your problem goes back to the first item with the folder rules. Mail is being delivered and SharePoint is picking it up and processing it.

The specific problem for me was that I needed to set "Save original e-mail?" to Yes. I was so caught up on "E-mail address" and "E-mail security policy" that I didn't think to look at this for a while. Clearly the others matter, but for me the "Save original e-mail?" mattered too. If the email has an attachment, the attachment will come through with this set to No. However, if there is no attachment it just does nothing (except to remove the message from the Drop folder). BTW, the Send-MailMessage PowerShell cmdlet does allow for sending one or more attachments.