I have an incoming email issue in our SharePoint 2010 farm version 14.0.7106.5002 (Service Pack 2 with August Cumulative Update). When I send out an email to an incoming email-enabled document library with an InfoPath form (v. 2007), it makes it to the Drop folder but it just sits there. Eventutally it disappears from the folder after about 24 hours or so, but it never makes it to the document library. I have no idea where goes to. I confirmed that the incoming email timer job is running successfully every minute. When I send an email to the same document library with my Outlook, it makes it to the library immediately.

Any idea?

Where is the email originating from?

I found a cause of the problem. Seems to be a SharePoint bug. It only occurs when InfoPath library is set to "Open in the browser" in the Advanced Settings. To replicate:

1. Create an InforPath form (v2007) with the Data Connection Winzard so it can send out an email with a button click.

2. In SharePoint, create an InfoPath form library for the form you just created. Go to Library Settings > Advanced Settings > Opening Documents in the Browser > select Open in the browser. Leave all other settings to default.

3. From the library, click "Add document" to bring up the InfoPath form on browser (IE 9) and click the button to send the email.

4. The .eml file goes to the Drop folder, but it will stay there for about a day or two even though Incoming Email Timer job runs successfully every minute. After a day or two, it disppears from the folder and never makes it to the document library.

Cause:

The .eml file contains this entry (one line) that blocks the Timer job to pick up:

X-Mailer: Microsoft SharePoint Foundation 2010

There's no log entries anywhere (ULS, event logs, smtp logs) about this failure.

Resolution (manual):

Remove the line by hand. The Timer job will pick it up as soon it is removed/saved and deliver it to the document library.

Microsoft, please fix this.

It isn't a bug, it is intended to prevent message loops.

May not be a bug for preventing the message loops but it is for delivering the message to the library. I think at least it should log it somewhere when it occurs.

I'm wondering if Matt McDermott has an input...

The reason it is there is to prevent a message loop, as the scenario could be easily generated, e.g. Workflow emails Document Library where Workflow is present, creating a loop of Workflow -> Doc Lib -> Workflow -> Doc Lib, etc. which would cause a resource exhaustion eventually.

You can ask Microsoft for a DCR (Design Change Request), but I don't think this one would be reconsidered.

Additional possible solution for some people:

One of the patches in 2014 has introduced the same bug that is known in SP2013, where if the Sandbox quota is < 600 for a site collection containing email enabled lists/libraries, the incoming email doesn't work.

Just found this with help from MS Tech Support.  Teach me for not using quotas in dev/test.