Allowing Email Enabled SharePoint Lists & Libraries?
You can enable and configure e-mail support for the following types of lists and libraries in your sites:
• document libraries
• picture libraries
• form libraries
• announcements lists
• calendar lists
• blogs
• discussion boards
Concerns
People will turn on email enablement for their list or library and then start dumping into it.
Questions
Can we turn off this permission to all but a select few?
No, anyone with permissions to create a list can choose an e-mail address for the list when creating the list in an e-mail-enabled site.
To enable or configure incoming e-mail support for a list or library, you must have the Manage Lists permission on the list or library. The Manage Lists permission is granted by default to the Site name owners SharePoint group. This means that site owners will always have the option to email enable libraries/lists, and this can not just be trimmed out of permission levels. The actual permission reads: Manage Lists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list. You cannot turn “manage lists” off without denying the ability to even create a list, it is all together.
Will there be a naming standard for these items?
We could not enforce this easily as the instructions for creating the email address on the MS site reads: In the E-mail address box, type a unique name to use as part of the e-mail address for this library. This means that users can create whatever address that they want.
Are these items going to be listed in the Address Book (Active Directory)?
Question asked in Forum
Who's going to be sending email to these (internal (authenticated/group members) people (what email & AD domain?), external people (CentraComm, DMZ SMTP servers), automated systems, etc)?
When configuring the e-mail security settings on a particular list or library, you can choose to allow only users who can write to the list or any user to archive e-mail to the list. Archiving e-mail from all senders allows everyone (including unauthenticated users) to write to your list or library. Because of the potential security risk, you should give this option careful consideration.
Will there be email size limitations?
The same size limitations as the upload size maximum. Currently set at 1.5 Meg.
Will we have to worry about spam to these addresses?
Yes if we allow anyone to email allows unauthenticated users including Spammers to send email to the list.
What domain are we going to use, and how will mail be directed to it (Exchange Send Connectors, MX records)?
Exchange Send Connectors be used (more discussion at bottom)
What happens when a list is removed? Is the object in AD removed automatically?
SharePoint will update AD accordingly to delete the corresponding contact from AD
What kind of storage requirements are we expecting? How will this affect performance (Sharepoint & SQL)?
We cannot truly predict the storage requirements for SharePoint if we allow incoming email. Setting up site quotas would be the only way to monitor the situation, and putting quotas in place after the sites have already been created and used would be a tedious process.
What changes need to be made in AD in order for list emails to work well? Security? Structure?
To use the Microsoft SharePoint Directory Management Service on a farm or server, you must configure the Central Administration application pool identity account to have the Create, delete, and manage user accounts right to the container that you specify in Active Directory. The preferred way to do this is by delegating the right to the Central Administration application pool identity account. An Active Directory administrator must set up the organizational unit (OU) and delegate the Create, delete, and manage user accounts right to the container.
Create new Organizational Unit in Active Directory and grant permission for the SharePoint service account using delegate control option. http://blogs.msdn.com/selvagan/archive/2008/01/26/incoming-email-configuration-moss.aspx
What’s up with the MX records?
After you add the IIS SMTP service, it will default to accepting email for the NetBios server name or, if defined in the network card properties, the DNS domain name of the server.
To get the SharePoint incoming email features to work within your organizations' email infrastructure, you don't need to configure the Directory Management Service feature within MOSS (it is not included with WSS anyway) but you may have to make some changes to the IIS SMTP service and your DNS server so that mail can be routed to the SharePoint server rather than your normal email server.
For wssdemo.com, I had to add the wssdemo.com domain as an alias because the server was part of another domain, so that the SMTP service would accept email for this domain. I also had to create a DNS MX record for this domain that points to the IP address of the SMTP/WSS server.
This causes email sent to @wssdemo.com to be placed in the drop folder on the SMTP server (as defined in the properties of the Local Default domain).
Before you try and get the SharePoint email integration working, you should test that email sent to this domain arrives in the drop directory (default location is C:\Inetpub\mailroot\Drop). You can do this from Outlook Express or you can use the SMTPDiag utility which you can download from here http://www.wssdemo.com/redir.aspx?ID=918
You should specify this directory location in the "Central Administration > Operations > Incoming E-Mail Settings" screen if you select the advanced options. http://www.wssdemo.com/Pages/Email.aspx
Other Sources:
http://justgeeks.blogspot.com/2009/01/sharepoint-incoming-e-mail-overview.html
http://office.microsoft.com/en-us/sharepointserver/HA100823061033.aspx
http://technet.microsoft.com/en-us/library/cc287879.aspx
• document libraries
• picture libraries
• form libraries
• announcements lists
• calendar lists
• blogs
• discussion boards
Concerns
People will turn on email enablement for their list or library and then start dumping into it.
Questions
Can we turn off this permission to all but a select few?
No, anyone with permissions to create a list can choose an e-mail address for the list when creating the list in an e-mail-enabled site.
To enable or configure incoming e-mail support for a list or library, you must have the Manage Lists permission on the list or library. The Manage Lists permission is granted by default to the Site name owners SharePoint group. This means that site owners will always have the option to email enable libraries/lists, and this can not just be trimmed out of permission levels. The actual permission reads: Manage Lists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list. You cannot turn “manage lists” off without denying the ability to even create a list, it is all together.
Will there be a naming standard for these items?
We could not enforce this easily as the instructions for creating the email address on the MS site reads: In the E-mail address box, type a unique name to use as part of the e-mail address for this library. This means that users can create whatever address that they want.
Are these items going to be listed in the Address Book (Active Directory)?
Question asked in Forum
Who's going to be sending email to these (internal (authenticated/group members) people (what email & AD domain?), external people (CentraComm, DMZ SMTP servers), automated systems, etc)?
When configuring the e-mail security settings on a particular list or library, you can choose to allow only users who can write to the list or any user to archive e-mail to the list. Archiving e-mail from all senders allows everyone (including unauthenticated users) to write to your list or library. Because of the potential security risk, you should give this option careful consideration.
Will there be email size limitations?
The same size limitations as the upload size maximum. Currently set at 1.5 Meg.
Will we have to worry about spam to these addresses?
Yes if we allow anyone to email allows unauthenticated users including Spammers to send email to the list.
What domain are we going to use, and how will mail be directed to it (Exchange Send Connectors, MX records)?
Exchange Send Connectors be used (more discussion at bottom)
What happens when a list is removed? Is the object in AD removed automatically?
SharePoint will update AD accordingly to delete the corresponding contact from AD
What kind of storage requirements are we expecting? How will this affect performance (Sharepoint & SQL)?
We cannot truly predict the storage requirements for SharePoint if we allow incoming email. Setting up site quotas would be the only way to monitor the situation, and putting quotas in place after the sites have already been created and used would be a tedious process.
What changes need to be made in AD in order for list emails to work well? Security? Structure?
To use the Microsoft SharePoint Directory Management Service on a farm or server, you must configure the Central Administration application pool identity account to have the Create, delete, and manage user accounts right to the container that you specify in Active Directory. The preferred way to do this is by delegating the right to the Central Administration application pool identity account. An Active Directory administrator must set up the organizational unit (OU) and delegate the Create, delete, and manage user accounts right to the container.
Create new Organizational Unit in Active Directory and grant permission for the SharePoint service account using delegate control option. http://blogs.msdn.com/selvagan/archive/2008/01/26/incoming-email-configuration-moss.aspx
What’s up with the MX records?
After you add the IIS SMTP service, it will default to accepting email for the NetBios server name or, if defined in the network card properties, the DNS domain name of the server.
To get the SharePoint incoming email features to work within your organizations' email infrastructure, you don't need to configure the Directory Management Service feature within MOSS (it is not included with WSS anyway) but you may have to make some changes to the IIS SMTP service and your DNS server so that mail can be routed to the SharePoint server rather than your normal email server.
For wssdemo.com, I had to add the wssdemo.com domain as an alias because the server was part of another domain, so that the SMTP service would accept email for this domain. I also had to create a DNS MX record for this domain that points to the IP address of the SMTP/WSS server.
This causes email sent to @wssdemo.com to be placed in the drop folder on the SMTP server (as defined in the properties of the Local Default domain).
Before you try and get the SharePoint email integration working, you should test that email sent to this domain arrives in the drop directory (default location is C:\Inetpub\mailroot\Drop). You can do this from Outlook Express or you can use the SMTPDiag utility which you can download from here http://www.wssdemo.com/redir.aspx?ID=918
You should specify this directory location in the "Central Administration > Operations > Incoming E-Mail Settings" screen if you select the advanced options. http://www.wssdemo.com/Pages/Email.aspx
Other Sources:
http://justgeeks.blogspot.com/2009/01/sharepoint-incoming-e-mail-overview.html
http://office.microsoft.com/en-us/sharepointserver/HA100823061033.aspx
http://technet.microsoft.com/en-us/library/cc287879.aspx
posted by Libarra @ 10:27 AM
0 Comments:
Post a Comment
<< Home