How the Product Works with MS Exchange EWS¶
Revenue Inbox is designed to run concurrently with other processes engaging a mail server’s Exchange Web Services (EWS) and provides the customers with the necessary controls regulating EWS access by Revenue Inbox.
The EWS access control tools are:¶
Different deployment options¶
Revenue Inbox supports Multi-Tenant, Single-Tenant, and On-Premise scenarios.
- These scenarios imply various levels of data and configuration isolation between tenants: logical isolation for Multi-tenant instances, physical isolation for Single-tenant instances, of full customer control for On-premise deployments.
- As a best use practice, Multi-tenant deployment is recommended as the most cost-efficient one for an average customer, also providing a solid level of security. Other options should be considered if specific security requirements prohibit Multi-tenant operation in your Org.
IP Address restrictions: Revenue Inbox operates via a fixed set of IP addresses¶
The customers using corporate firewall IP address restrictions for Salesforce or MS Exchange servers connection need to allow-list specific IP addresses used by Revenue Inbox.
Such whitelisting is complementary, it does not block any existing server traffic.
See more details on configuring IP restrictions and the list of IP addresses used in Multi-tenant environments here.
For Single-tenant configurations a specific list is communicated during Revenue Inbox deployment.
As a best practice, such configuration should be added over the current customer configuration, to prevent interfering with existing traffic.
Filtering Revenue Inbox EWS traffic Revenue Inbox¶
Filtering can be configured to use a pre-set UserAgent header on every EWS call made to the customer’s MS Exchange server. Such configuration allows traffic filtering on multiple levels:
On MS Exchange / Office 365 side: using MS Exchange controls, as documented here.
- This configuration control allows additive listing of allow-listed applications, and if used by in a customer’s Org it may be extended to include traffic from/to Revenue Inbox.
By a stateful firewall which can block HTTPS traffic.
- As in the above case, a custom rule can be built based on an added UserAgent HTTP header to allow Revenue Inbox-originated EWS traffic pass through, in addition to any other allowed traffic.
The value of the UserAgent header for all EWS traffic can be set as requested by a customer.
As a best practice, customers who already implemented EWS traffic filtering using one of the above approaches should consider extending their configuration to allow Revenue Inbox EWS traffic.
Allow EWS Access only for a certain list of mailboxes¶
- If EWS are not used in any other way in a customer’s configuration, then only specific mail accounts which need EWS access may be enabled to access them, in particular an Impersonating account set up for Revenue Inbox.
- Refer to this Microsoft article for details on enabling EWS access.
- Note that certain Revenue Inbox functions may be not supported for this configuration (e.g. the Add-In will not be available, refer to this article for more information), contact our CSM team for details.
In terms of best practices, the recommended path is as follows
- Choose the Revenue Inbox deployment model that suits your Org’s needs.
- Decide whether Revenue Inbox IP address filtering shall be configured in your Org.
- Decide whether Revenue Inbox EWS traffic filtering shall be configured in your Org.
- Decide which user authentication model shall be used in your organization: whether the end users will sign in to MS Exchange or Office 365 themselves, whether Exchange Impersonation and Service accounts will be used, and whether the RI Outlook Add-In will be used; depending on that EWS access may be allowed only for a Service account authenticating a list of end users.