Email Enabled Lists and Inbound Email
Although they might not surface every where you want them to such as incoming emails on a straight "custom list" or list created from the custom list template. There are some extremely useful scenarios and if you know you want to do it, one of these lists might work for you. Once you've configured your server for inbound email you'll notice that on the following lists and maybe some I don't list you can enable including:
- Discussion Lists
- Picture Libraries
- Document Libraries
- Calendars
- Form Libraries
- Announcements
- Blogs
(Thanks Eben and April for bringing this important topic to the top of the list.)
Here's some suggestions/scenarios:
1) The best place to archive emails is on the discussion list, much better than the document libraries for most scenarios. Document libraries are really designed for e-mail attachments only (there are some options in the list/document library settings to manage what to do.) Discussion Boards integrate e-mail content into SharePoint providing rich support for threading and filtering.
2) Imagine putting your list as a member of your team discussion group (DL) and having it either show up on a discussion list, an annoucement list, or event list for calendar view.
3.) Form libraries can also be email enabled. Use InfoPath to make the submit button of the form e-mail the form to the form library, you can now submit forms from anywhere.
4.) Note you can also e-mail enable the announcement list and your blog. This makes it easy to post new announcements on your team home page or post blog posts to your blog.
What I don't recommend:
Don't put it on a high volume DL, you still have the limitations of the list views.
An attachment with a blank body may be rejected according to a user email and was reinfored by their call to support.
MS IT has been very cautious about their support for email enabled lists and specifically only supporting it on few isolated environments...
Why Not?
Email enabled lists create contact objects in AD, it takes careful coordination to create these contact objects and ensure the proper write access to a specific OU. Imagine 500,000 lists all with the ability to be email enabled. There are also some huge wildly popular DLs. That's a lot of freedom. If you're not ready to manage it, I agree with the mentality of start small, understand the implications. You don't need to turn on all the nobs, and start with everything enabled, but for some scenarios this feature alone is really the *killer* feature. When you create a site it doesn't automatically create these objects, so you don't have to worry about that, in fact most will never even know it's there. It would take some training to learn how best to take advantage of these features, but they are cool and very powerful. When you delete a site, it does clean up these objects, but what happens when a site is deleted without the API or when a database is simply removed down the road. That's right, unless the API is called properly you could end up with some contact orphans. Naming standards for these objects? No control really unless you build something. So there are some considerations to be aware of.
I did a post a while back on comparing Exchange public folders to email enabled lists. There isn't a 100% overlap, and that's what this post discusses. There are some great scenarios where more and more the scenarios can be moved to SharePoint, but I don't recommend blindly moving everything from email to SharePoint. If you're using your PF for a file server and team calendars, then there's likely something here for you.
TechNet has a couple resources on the topic:
- Plan incoming e-mail (Windows SharePoint Services)
- Configure incoming e-mail settings (Windows SharePoint Services)
Steve Smith wrote the paper that has been to as the nearly authoritative info on How to configure Incoming Email Enabled Libraries in MOSS2007. It's my favorite, and I refer people here whenever the topic comes up. It's true that email enabled lists is an option in WSS 3.0 not just MOSS 2007.
Want to compare it to another blog post, this SharePoint blogger Code and Stuff shares their configuration steps and testing validation.
This amusing email came in today from a SharePoint PM which shows how we're dogfooding and enjoying our own product. "Our product is cooler than I thought. The review list is actually subscribed to the “Windows SharePoint Services Specs” alias… so if you just send your mail to that list, it’ll get automatically added to the list. Wow ;) SharePoint rocks!"
