Emailing SharePoint 2007 Lists and Libraries

Furthermore, there’s no way for the sender of a message to know whether it was successfully delivered to the correct SharePoint list—if, indeed, it was delivered at all—except by physically visiting the intended destination. The SMTP service initially receives the incoming email message, but the service isn’t tied to SharePoint in any way and therefore can’t validate that the email address points to a list or library.

The last aspect to mention at this stage is the security that you can set for incoming email. You can choose to accept mail based only on the permissions set on the list or library itself or to accept mail from any sender.

Directory Management Service
If you’ve sorted out your SMTP routing topology, you can now send items to SharePoint by entering the location’s email address in a message. However, raw email addresses aren’t necessarily user-friendly, so most email systems let you look up email addresses using common terms, such as first name and last name. WSS can leverage Active Directory (AD)—or a custom directory— for this very purpose via something called the Directory Management Service (DMS), a web service (SharepointEmailWS .asmx) that’s installed out of the box on a web front-end server and enabled at the farm level using the incoming-email settings. Let’s see how the DMS works and what problems it solves—and what problems it introduces to the mix.

The DMS creates Contact objects in AD to represent email-enabled lists and libraries. (It can also create distribution groups to represent the members of team sites, but that functionality is outside the scope of this article.) Your end users should be able to benefit from these entries with the same address look-up functionality and email distribution as with other email-enabled objects. I say should because enabling the DMS creates some problems you won’t have if you don’t use it. Note that the DMS isn’t mandatory for supporting incoming email.

Configuring the DMS is a matter of specifying an organizational unit (OU) in AD where the contacts will be created. Best practice is to create a MOSS-specific OU for easier all-around management. You need to provide the SharePoint Central Administration application pool account with write access to the OU, and therefore you’ll have to work with whoever’s in charge of your AD. You must also specify the name of the SMTP server for incoming mail— ultimately, this information finds its way onto the email addresses associated with the contacts that the DMS creates. Note that this address can be different from the Incoming E-Mail Server Display Address that you set during incoming-email configuration. The DMS-created address is the more user-friendly one that’s displayed through the SharePoint UI, and you might have to subsequently update the AD-created object with this address so that it’s a valid address to which mail can be routed. You can also indicate whether the AD Contact objects can receive mail only from authenticated users, which results in an Exchange-specific attribute being set on the Contact objects in AD. So, if you’re using a different email system, this setting won’t be applicable.

Using the GAL—or Not
Table 1 shows the main attributes the DMS sets on Contact objects in addition to standard system attributes. There are some limitations with these settings, however, not least the fact that in a pure Exchange 2007 environment, these settings are insufficient for a valid entry to appear in the Global Address List (GAL). Exchange 2003 and Exchange 2000 include an asynchronous component called the Recipient Update Service (RUS) that stamps AD objects with attributes such as proxyAddresses and showInAddressBook that Exchange relies on to identify recipients and route mail. This method of stamping addresses was removed from Exchange 2007; instead, all attributes are stamped at creation time— but only if you use Exchange Management Console (EMC) or Exchange Management Shell (EMS) to create your objects in the first place!

Therefore, to get your contacts correctly stamped in an environment that doesn’t have RUS, you need to modify them after they’re created. This process is discussed in the Exchange team’s blog entry, “Good bye RUS” (msexchangeteam.com/ archive/2006/10/02/429053.aspx). Essentially, you need to update all relevant address lists with the following EMS commands:

Get-EmailAddressPolicy |
  Update-EmailAddressPolicy
Get-AddressList | Update-AddressListGet-GlobalAddressList |
  Update-GlobalAddressList

The second limitation with the Contact objects is that they aren’t configured for attachments to be correctly sent to them. This problem is documented in the Microsoft article “Attachment is missing from an e-mail message that is sent to a Microsoft Windows SharePoint Services 3.0 document library” (support.microsoft.com/default .aspx?scid=kb;en-us;926891), which explains that you have to set the mAPIRecipient attribute to false and the internetEncoding attribute to 1310720 before attachments will be sent correctly to the Contact object. Note that if you aren’t using the DMS to enable GAL lookup, these problems don’t occur. Exchange doesn’t correctly deliver to the DMS-created contact because of these missing attributes.

The third problem is with the display name that gets created and ultimately finds its way into the GAL. This name is usually the primary way someone chooses an entry from the GAL. However, it’s highly likely that users have similar list and site names, which means that there’s little to differentiate entries in the GAL. Remember, Share- Point has nothing in the UI to prevent sites and lists having the same titles. Figure 2 shows an example of two team sites, both called Group Team Site and both having the out-of-the-box Team Discussion list mail-enabled. Which one should users choose? To pick the right one, they’d need to know the email address of the appropriate list—which would defeat the purpose of having a GAL entry in the first place. The existence of Contacts in the GAL could be a hindrance rather than a help.

The last problem I’d like to mention is the lack of governance. There’s no administrative control in SharePoint over what gets put into the GAL—if you decide to enable the DMS, it’s a free-for-all and chaos can certainly reign. Can you imagine if every team site email-enabled, say, three lists? How many entries in the GAL would that equate to in your organization? At my company, that would reach the million mark. And, given the design of the DMS, all those entries would be in the same OU in AD. I’m not sure I know any AD administrators who would happily open up their AD to the potential for such abuse.

Emailing Ease
Correctly configuring all the pieces so that email makes it to the intended list or library can be tricky, but the ability to email items into SharePoint is certainly a useful feature, and the way SharePoint handles incoming items works well. That said, make sure you communicate correct expectations about what the features are, how contacts will appear in the GAL, and so forth, so that everyone—end users, AD admins, Exchange admins—knows what to expect when you email-enable SharePoint. Good communication is especially important if you decide to use the DMS—but remember, the DMS isn’t mandatory.