15

I want a document library to recieve email and store it so followed the steps outlined here: http://sharepointgeorge.com/2010/configuring-incoming-email-sharepoint-2010/

I seem to be a bit stuck. The mail's being delivered to the machine and it's appearing as .eml files in the drop folder, so SMTP and delivery is OK.

I assume Sharepoint's supposed to pick up the file, stick it in a library and delete it, but it doesn't, the mail file just sits there.

Nothing in the logs, obviously.

I haven't set this up before, how often does the timer service come about and pick up the mail?

11
  • I had this same issue. Im not sure why but it is a security issue. the timer was using moss service account. We changed it to use moss admin account and it started working. Hope this helps
    – user4048
    Commented Jul 8, 2011 at 20:46
  • No!!! The Timer Jobs run under the Farm account, sharepoint is counting on this in a lot of places (i.e. data access to the config db etc.). Pretty much all off sharepoint's automated actions use this account / service/ You should change the account back to the original value! Just grant access to the drop folder / smtp server forthe original account!
    – Colin
    Commented Jul 8, 2011 at 22:28
  • We did grant access to the drop folder but still no luck. this wasn't the first time we changed the account to admin. There were issues all over with basic functionality that should work out of the box but for some reason the service account just wouldnt behave. Im an intern still learning sharepoint, I understand that by changing the account to admin you may be opening yourself up to hackers. If I change the account back to service, how would you recommend getting this to work? Is it permission levels or something? again we tried granting access to the drop folder but no go. Thanks
    – user4048
    Commented Jul 8, 2011 at 23:28
  • See this hope it helps combined-knowledge.com/Downloads/2007/…
    – naijacoder
    Commented Oct 5, 2011 at 6:44
  • 1
    Try this powershell Get-SPServiceInstance | ? {$_.Typename -eq "Microsoft SharePoint Foundation Incoming E-Mail"} What is the result? Commented Jul 15, 2014 at 8:30

19 Answers 19

6

On a multi-server farm, be sure the "Microsoft SharePoint Foundation Incoming E-Mail" service is running on the same server you're using for the SMTP service, presumably one of your front end servers. Check this in Central Admin-System Settings-Manage Services on Server and cycle through your servers on the top-right. In my case the above mentioned service was running by default on my APP server and I had to stop it and switch it on on my FE server.

4
  • Yes, yes yes. Checked that. In this case it was a single app-server farm, and all services were running.
    – Dan
    Commented Nov 16, 2012 at 18:45
  • Hats off, by the way, that this question still draws responses. Love the stack!
    – Dan
    Commented Nov 16, 2012 at 18:46
  • For multi-servers restart the "Micrsoft SharePoint Foundation Incoming E-mail" service on all WFE servers. I couldnt figure this issue out for a few hours before I simply restarted the services and IT WORKED! Commented Apr 9, 2014 at 12:26
  • This helped me. Configured everything for our test farm and it worked. For some reason the service did not run on our productive farm. Thanks!
    – AM2FTW
    Commented Jun 12, 2018 at 11:08
6

Couple of things to check:

  • Make sure "Microsoft SharePoint Foundation Incoming E-Mail" timer job is running on the server where SMTP confgiured.
  • From Central admin, Incoming email setting > advance setting, make sure drop folder path added here.
  • Make sure Timer Services having the correct permission on drop folder.
4
  • I go check this. Commented Jul 1, 2014 at 11:20
  • I checked the second and third. I can't found timer job, how I do this? Commented Jul 1, 2014 at 12:04
  • I found! All is ok. Any other idea? Commented Jul 1, 2014 at 12:13
  • Timer Service (First bullet point) has to be startet in the Central Administration >Application Management > Manage services on server
    – lex
    Commented Mar 15, 2017 at 12:13
5

I had same problem, after all I changed in Configure Incoming E-Mail Settings->Settings mode to -> ADVANCED and specified E-mail drop folder Path :c:\inetpub\mailroot\drop. I hope this answer will help somebody :) .

1
  • This setting did the trick for me. Appreciate it.
    – Ken
    Commented Oct 18, 2012 at 17:30
3

The guide mentions there being a delay between sending your email and seeing the document show up. I assume it is a timer job that performs the email pickup tasks. Is the SharePoint timer service running? It is called SharePoint 2010 Timer

If the service IS running, are you able to see your job running in central admin? No jobs should be running right now if the Timer service is stopped.

1
  • Yes, timer service is running and the mail pickup is scheduled to run each 5 minutes. I can trigger the job manually as well. However, there's no history of the job ever being run, which makes me think that it's failing somewhere along the line. But I can't find a record in ULS or the Windows logs.
    – Dan
    Commented Jun 8, 2011 at 2:49
3

If nothing above has helped, then I would check whether your application pool and timer service accounts have permissions to the drop folder. Probably they don't. Some time ago it was the cause of the issue in my case.

To configure this permissions do the following:

  • Verify that you have the following administrative credentials: You must be a member of the Administrators group on the computer that contains the e-mail drop folder.

  • In Windows Explorer, right-click the drop folder, click Properties, and then click the Security tab.

  • On the Security tab, under the Group or user names box, click the Edit button.

  • In the Permissions for Windows Explorer dialog box, click the Add button.
  • In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type the name of the timer service or application pool identity account for the Web application, and then click OK.
  • In the Permissions for User or Group box, next to Modify, select Allow. Click OK.

If it doesn't help, try to follow this article: Configure incoming e-mail (SharePoint Foundation 2010)

3
  • Had already occurred and not solved. Commented Jul 9, 2014 at 14:08
  • Then I would try to follow the article from the start for another library. Probably, at first there were issues with permissions while creating contact in AD for the lib and after fixing it, some inconsistency remains and it doesn't work. If you follow the article for another lib you can exclude this potential issue.
    – MikhailSP
    Commented Jul 14, 2014 at 8:18
  • Of course, you can skip the part regarding setting up SMTP server as it seems it works well.
    – MikhailSP
    Commented Jul 14, 2014 at 8:23
2

The timer job that picks up mail runs about every 5 minutes or so, so you should not see the email sit there for long. If it does just sit there, and the Timer service is running, then the problem may be that SharePoint does not recognize the TO address as an email-enabled document library.

Make sure that you have configured the incoming email domain to correctly match the mail domain of the SMTP service, and that you don't have any typos in the email address compared with the incoming email address name on the target library.

3
  • Email is being delivered fine and the address of the list is correct. The Timer Service is running but when I checked the job definition (Microsoft SharePoint Foundation Incoming E-mail) there's no history of the job being run. What's up with that?
    – Dan
    Commented May 25, 2011 at 3:56
  • Try running the timer job manually with the "Run Now". Has the timer job been disabled? Commented May 25, 2011 at 22:29
  • Tried that, it still doesn't pick up the mail and it doesn't leave a record in the history. Can't find anything in the logs either.
    – Dan
    Commented May 30, 2011 at 6:43
2
+25

If you have more than one APP Server, check whether the drop folder is on the same server where the timer is running, else you have to share the folder and add the path in Central Admin.

Reference : http://bernado-nguyen-hoan.com/2013/06/18/solving-sharepoint-2013-incoming-mails-stuck-in-drop-folder/

3
  • I have one App Server. Commented Jul 9, 2014 at 14:07
  • I think it should be issue with permissions on the folder. Have you tried to give read permission to Timer Service Account. Try changing Service accounts if one doesn't work for some reason.
    – Sudhakar
    Commented Jul 9, 2014 at 14:09
  • Yeah, give 'Everyone' Full control on the drop folder to see if that is the issue. Then scale back Commented Jul 10, 2014 at 21:17
2

I came across the same issue on SharePoint 2013. As strange as it sounds, but solution was to change the value of Sandboxed Solutions resource Quota from 0 to something else. enter image description here

1

Have you configured IIS 6.0? For configuring IIS 6.0 You can refer this link:

http://weblogs.asp.net/jeffwids/archive/2010/08/16/configuring-incoming-email-for-sharepoint-2010-foundations.aspx

1

Check if there're an X-Sender and X-Receiver headers in your emails - they are required. These headers is automatically added if you use the SMTP service in Windows. Anyway there must be a error in the SharePoint log regarding your emails - what does it say?

1

As I was taking too long to resolve this error, I created another SharePoint farm and the error did not persist. It seems that the machine name (vfesharepoint2013) was very large and we think the netBios was lost because of this.

Thanks fo all.

0

This worked for me after spending countless hours searching!! http://blogs.msdn.com/b/george_bethanis/archive/2012/05/25/sps2010-cannot-send-incoming-emails-to-lists-libraries.aspx?CommentPosted=true#commentmessage

2
  • 1
    Welcome to SharePoint.SE! While this post may answer the question, we prefer more details such as "why". Please edit your post with additional details. See How to Answer for general guidelines.
    – Kit Menke
    Commented Jul 31, 2012 at 20:53
  • Yeah, link's dead
    – kitsu.eb
    Commented Oct 12, 2020 at 17:58
0

In addition to other solutions provided here, this solution may fix your issue. Specially if you send an email to the document library and receive a delivery failure message similar to below

Delivery has failed to these recipients or groups:

[email protected]
Your message was not delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.




Diagnostic information for administrators:

Generating server: smtp1.contoso.com

[email protected]
#< #5.7.1 smtp;550 5.7.1 Unable to relay for [email protected]> #SMTP#

Original message headers:
...

By default when you install the SMTP service on the SharePoint server, the domain is the fully qualified named of the server. ex: SPSrv01.contoso.com

enter image description here

Rename this domain name to the Incoming E-Mail Server Display Address (this can be found in the Central Administration website, under Configure Incoming E-Mail Settings.

enter image description here

enter image description here

0

I had the exact same problem of some incoming mails for a list A being stuck in the drop folder while incoming mails for another particular list B were delivered just fine.

The following article helped me: This worked for me after spending countless hours searching!! http://blogs.msdn.com/b/george_bethanis/archive/2012/05/25/sps2010-cannot-send-incoming-emails-to-lists-libraries.aspx?CommentPosted=true#commentmessage

And indeed, both A and B were in different site collections. While B had a limit site storage defined, A had not. Upon specifying a limit storage under Current quota template, for the site collection of A, it started working immediatly. As described in the above article.

0

FYI Just finished debugging this with MS Tech Support. Turned out that if you have Sandbox quotas turned on for a site collection that contains email enabled lists/libraries, the quota needs to be at least 600. Note: having the quota set to 0 doesn't work. We're not even using sandbox solutions, but this still needs to be set...

This is a known bug in SP2013 (recently introduced I think) and between us we confirmed that it's also a bug in SP2010, introduced by one of last years patches.

0

This thread has become a good source of troubleshooting incoming email issue. :-)

Restarting "SharePoint Timer Service" (SPTimerV4) on all Servers where "Microsoft SharePoint Foundation Incoming E-Mail" service is enabled resolved the issue in my case.

Hope this helps someone!

0

For me this blogpost was the solution:

https://www.vioreliftode.com/index.php/sharepoint-incoming-e-mails-stuck-in-drop-folder/

This bug is fixed in May 2015 CU for SP2010 and April 2015 CU for SP 2013.

0

Go to the intended server. Run-> inetmgr6 -> SMTP service must be in started state.

Next step is to check the location of maildrop folder. The mails should start moving. If it does, functionality is working.

In my case, even after doing the above step it was not working. After restarting the sharepoint timer service in all the nodes, functionality started working.Also, make sure the below option is enabled in Doc library setting,

Save Original email --> Yes

Hope this helps

0

I couldn't comment on Denis Boico's answer above, so I'll add it here:

I had same problem, after all I changed in Configure Incoming E-Mail Settings->Settings >mode to -> ADVANCED and specified E-mail drop folder Path :c:\inetpub\mailroot\drop. I >hope this answer will help somebody :)

Denis Boico

This ALMOST worked for me. My problem was on a SharePoint Foundation 2013 farm with four WFE/APP servers. Only one was configured for incoming email (not the server hosting CA). I had to go into the Advanced Settings as Denis said, however I had to use the UNC for the drop folder, e.g. \WFE1\c$\inetpub\mailroot\drop. Once I did that, the mail started flowing immediately. Hope this helps someone else with this problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.