Advanced Incoming Email Configuration In SharePoint 2013

When the SMTP service is running on another server besides SharePoint sever, you have to specify the location for it to retrieve the incoming email. The drop folder that you pick allows the program to know where to retrieve that incoming e-mail from. If you change the email drop folder, SharePoint 2013 is unable to determine those configuration changes on the remote e-mail server.

As a result, when an administrator configures the e-mail server to delivery email to a different folder, it can’t be detected by SharePoint 2013. This option is only available in advance mode. Therefore, you can’t specify an email drop folder. You will need to specify at least one safe email server.

Then you aren’t going to be able to retrieve the files from that new location. When you have incoming mail set in advanced mode, you have to make sure you have the right permissions in place on the email drop folder.

The administrators can specify which email server address will be displayed in the web pages when creating the incoming email address for a group, list, or site. Often, such a setting is used to provide a friendly email server address for users in the SharePoint Directory Management service.

There are several procedures that have to be completed if you wish to use SharePoint Directory Management Service. The typical steps involved include:

  • Create a new SharePoint group by the site collection administrator.
  • Selecting and creating a distribution list to share with the SharePoint group. An email address has to be assigned to that distribution list.
  • The administrator will add and remove users from this SharePoint group over time as needed.

The Management service will be stored in AD DS. The distribution lists are associated with a given SharePoint group, but the distribution list is offered to all members within a given group. The email addresses will be generated for discussion boards and calendars by default on team sites and then added to the distribution lists. Including the email addresses for calendars and discussion boards to the distribution lists, the emails and meeting invites can be sent to the distribution list and then archived on the team site.

Configuring the SharePoint Directory Management Service is necessary to create specific distribution groups and contacts in AD. In order for this to occur, you need to provide some information. The name of the AD container for the new distribution groups and contacts needs to be created in this format:

  • OU ContainernName
  • DC DomainName
  • DC TopLevelDomainName

It is necessary to name the SMTP server for incoming email if you aren’t going to accept the default SMTP server. To do this, you need to the following format:

If you decide you would like to allow users to create distribution groups in SharePoint sites, then you also need to choose if users can do all or some of the following actions:

  • Change the email address of a distribution group
  • Change the title and description of a group’s distribution
  • Create a new distribution group
  • Delete a distribution group

While configuring the SharePoint Directory Management Service for creating distribution groups and contacts, you will need to provide various types of information including:

  • URL of the remote directory management service
  • Name of the SMTP server for incoming email use
  • If you wish to accept messages only from users that have been authenticated
  • If you wish to allow users to be able to create distribution groups with SharePoint site



Server to Server Authentication In SharePoint 2013

The process of server-to-server authentication involves the validation of the request a server gets for resources. It is based on a trust relationship that is between the STS of the server that runs SharePoint 2013 and the STS of another sever that supports the OAuth server to server protocol. This is a trust relationship so a requesting sever can access the resources that are secured on the SharePoint sever. This is done on behalf of a specific user account. It is also subject to the permissions of a given sever and a given user.

For example, this occurs when a server running Exchange Server 2013 is able to request resources of a server that is running SharePoint 2013 for a specific user account. This is in contrast with app authentication which involves the app not having access to the user account credential information. The user can be signed into the server, making the resource request but it isn’t a requirement. It depends on the specific service and the request being made.

When a server is running SharePoint 2013, there is an attempt to access a resource on a server. The incoming access request has to be authenticated in order for the server to accept the incoming access request and data. With server-to-server authentication, there is verification that the server running SharePoint 2013 and the user that is accessing it in the representation are both trusted.

The token that is used for any server-to-server authentication is a server-to-server token rather than a logon token. This server-to-sever token has information about the server that requests access. It also has information about the user account that the server is acting on the behalf of. With on premises servers, this is an example of how that basic process will occur:

  1. A user opens a SharePoint web page that requires information from another server.
  2. SharePoint 2013 generates a server-to-server token.
  3. SharePoint 2013 sends the server-to-server token to the new sever.
  4. The other server has to validate the server-to-server token from SharePoint.
  5. The other server has to send a message to SharePoint 2013. This message indicates that the server-to-server token was valid.
  6. The service on the server running SharePoint 2013 accesses the data on the server.
  7. The service on the server running SharePoint 2013 renders the page for the user.

If both servers are running Office 365, this is an example of how that process will occur:

  1. The user opens a SharePoint web page that requires information from another server.
  2. SharePoint Online requests and obtains a server to server token from ACS.
  3. SharePoint Online sends the server to server token to the server for Office 365.
  4. The server for Office 365 verifies that the identity of the user is correct based on the ACS server to server token.
  5. The server for Office 365 sends a message to SharePoint Online to state that the token sent through server-to-server has been validated.
  6. SharePoint Online accesses the data from the server for Office 365.
  7. SharePoint Online renders the page for the user to access.