This is the fourth post in a guest series I’m doing here on Email Management in SharePoint. The third post was Myth #2.
Emailing a post to a blog … very cool or archiving an Exchange Discussion List to a SharePoint list … super cool … but be careful. Email-enabled self service lists can easily get out of control. Microsoft IT, which loves to use nearly every feature of SharePoint, decided against using email-enabled lists.
Email-enabled lists can be a significant IT resource drain. Without the proper planning and management, AD objects will be created with archiving and no lifecycle. Contact account naming standards are another reason. IT doesn’t want to see random contacts in AD.
Everyone wants to have the document library called “docs” and everyone wants to have the discussion list called “discussion”. If you have a process or even a workflow to get requests and manage these requests, you can better manage who needs them, when they are needed and for how long. So, my recommendation here is to know what you’re doing. Otherwise, it’s very easy to end up with a mess.
Like Public Folders, email-enabled lists can also pose security risks if not managed properly. Fortunately, they are more often secured to the context of the team so they are not as much of an exposure.
List scalability can pose problems with email-enabled lists. You don’t want to send all data from all users to one list. Put content in context in different site collections, sites, folders, as it relates to the context of the group, team, or project.
Most SharePoint environments don’t need the email-enabled functionality and the oversight it requires. Those that decide to use it should plan to set-up specific content objects and point the lists at them. Steve Smith’s document called “How to configure Incoming Email Enabled Libraries in MOSS2007 RTM using Exchange 2003 in an Active Directory Domain” explains in detail how to set-up email enabled lists. Don’t be surprised if it’s more complex to set-up than initially thought. I recommend setting it up in a preproduction environment first and learning how it works, then exercising administrative tasks and troubleshooting tasks around maintenance of the list, inbound SMTP, and AD contact objects.
In summary, I’d suggest you get answers to the following questions before implementing email-enabled SharePoint lists:
- Are those contact objects in a separate OU?
- How do you know if the inbound SMTP stops working?
- Can anyone send to the list?
- Does the item show up the way you expect it to, or are just attachments showing up?
- Does the metadata look like you expect it to?
The answers will help you better understand the nature of these special lists and help you better take advantage of this functionality, if you decide to use it.
Truth: Use with caution: To be successful, email-enabled lists require management & oversight to scale past a few thousand items.