Emailing SharePoint 2007 Lists and Libraries

Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 let users contribute content to lists and libraries via email. This ability adds to existing methods such as uploading through the browser and offers end users more flexibility in the way they contribute to team sites. Email is an especially useful way of contributing SharePoint content for the road warrior who might not always have a direct connection to the network.

Microsoft SharePoint Portal Server 2003 let you email documents into document libraries via an Exchange Server mail-enabled public folder—a cumbersome, circuitous method. WSS 3.0 and MOSS 2007 improve the process with the ability to send messages directly into many types of lists and libraries without relying on Exchange public folders. This is a welcome development, but there are some implementation issues that could trip you up along the way. In this article, I show you how emailing works with SharePoint 2007 and highlight some problems you should be aware of. SharePoint also supports outgoing email for notification of various events, but that’s outside the scope of this article.

Basic Architecture
First, I’d like to make it clear that SharePoint is not an SMTP engine, and it doesn’t care what messaging system you use; Exchange (or any other specific messaging system) isn’t required to be able to email items into SharePoint lists and libraries. Essentially, SharePoint monitors a folder location looking for correctly formatted SMTP messages. SharePoint doesn’t care how those messages arrive in the folder—it just opens them up and tries to associate each message with a list or library somewhere in the SharePoint farm. It doesn’t return delivery failures nor does it process requests for read or delivery receipts—which is what I mean by it not being an SMTP engine in itself.

In a typical environment, the folder that SharePoint monitors is the drop folder of the SMTP service running on web front-end servers within the farm. The general messaging infrastructure is configured such that SharePoint-bound messages are routed to the SMTP service. How this routing is achieved differs in each organization, but typically SharePoint is identified using its own SMTP namespace, and a combination of mail exchanger (MX) records and messaging connectors route traffic appropriately.

If an item in the monitored folder can be successfully parsed as an SMTP message, SharePoint uses the To address to look up the destination list or library in the current farm. Depending on various configuration options—such as who is allowed to send mail to a particular list and the type of list it is—the email and attachments are added to that list; they become normal list items and therefore benefit from core SharePoint services such as search and views.

Configuring Incoming-Email Settings
For this emailing structure to be successful, you have to configure how and where the web front-end servers monitor the drop folder, how to match incoming email addresses to lists and libraries, and how to control who is allowed to do what via email. The first step is to enable processing for incoming email at the farm level through the Operations tab in SharePoint Central Administration. With incoming mail enabled, SharePoint starts a background timer job called Windows SharePoint Services Incoming E-Mail that runs every minute on all web front-end servers to poll the drop folder for new messages. As with all timer jobs, this job is controlled by the Windows SharePoint Services Timer service; if the Timer service isn’t running, incoming email won’t be processed.

The incoming-email job runs by default on all front-end servers, but the configuration for the drop folder is set farmwide. Therefore, all web front-end servers in a farm that run the incoming-email service must have a drop folder in the same location. So, if the drop folder is configured as C:\Drop, all web front-end servers must have a C:\Drop folder and your mail routing topology must ensure that incoming messages get deposited in this folder.

You should enable the Windows SMTP service on your front-end servers to receive email from other SMTP servers— for example, so you can send messages from Exchange 2007 directly into WSS. The automatic configuration mode on the Configure Incoming E-Mail Settings page in Central Administration meets the needs of most organizations. However, if you’re not using the Windows SMTP service and want to populate a drop folder via some other mechanism, you’ll need to manually configure the settings using the advanced mode, which reveals configuration settings for the drop folder in the UI. Note that using the advanced mode disables the ability to specify safe SMTP servers.

In the automatic mode, you can indicate that all incoming mail is acceptable or you can specify a list of IP addresses that equate to those SMTP servers you’re happy to process mail from. Your choice depends on your overall SMTP routing topology. For example, you might have one central SMTP server that all mail passes through and you want this server to be the only one from which you’re willing to process mail. The incoming-email service analyzes the Received header inside each message it picks up from the drop folder to determine whether to accept the message.

If you’re not using the automatic mode, you have to ensure that the account used to run the Windows SharePoint Services Timer service has modify permissions on the specified drop folder so that it can delete messages after processing them. Failing to do so results in messages being delivered multiple times.

The last piece of configuration for this stage is to indicate which SMTP domain your WSS farm processes mail for. For example, with an email address of mi6@wss.spyrus .com, the SMTP domain is wss.spysrus .com. In this example, any email-enabled list or library would have an address of something@wss.spysrus.com. The challenge from an infrastructure point of view is to ensure that every email message addressed to wss.spysrus.com finds its way to a web front-end server with the incoming email service enabled. You could do this many different ways, but it most likely involves setting up MX records in DNS and connectors from other internal mail systems. For example, in Exchange 2007 you could set up a Send connector that handles the wss .spysrus.com namespace and indicate that you want to forward all messages for that address space to a smart host—the smart host being your web front-end server.

Enabling Delivery to a List or Library
After email is configured at the farm level, site administrators can email-enable individual lists and libraries. Not all list types can be enabled for email, but for those that can, you’ll see an Incoming email settings option under the Communications section when viewing the settings for the list. The settings available depend on the list type—for example, a document library asks you what you want to do with attachments and a blog list lets you choose whether the incoming item is published immediately. Figure 1 shows the settings available for a document library.

Every list you mail-enable needs to have an email address that’s unique across the entire farm. But the site administrator can choose only the user part of the address, which SharePoint stores in the AllLists table within the content database associated with the site collection. The domain part of the address is configured at the farm level.

This naming method for email addresses probably isn’t practical for most organizations. Why? First, SharePoint offers no governance on names, so it’s a first-come, first-served situation for picking the user part of the name. And people will most likely choose common names for common lists—for example, what would you want the email address for your Announcements list to be? Announcements@domain.com? But so does everyone with a SharePoint site in the farm, and there’s no way to check what other email addresses are currently in use other than by trial and error—SharePoint blocks you when you try to create a name that already exists. So this leads to end-user frustration. SharePoint also provides no way to validate that the email address conforms to corporate policies for formatting or the use of invalid or inappropriate names.

Continue on Page 2