Planning email integration with BMC Helix services

Some BMC Helix services offer an internet-based email integration for receiving messages (customer-initiated email updates in BMC Helix applications) and sending messages (BMC Helix application-initiated notifications). Email exchanges use standard Simple Mail Transfer Protocol (SMTP) transactions between your mail infrastructure and the BMC Helix mail infrastructure, as shown in the following figure:

Systems-level integration architecture

Related topics

Inbound and outbound email integration

Important

The SMTP incoming and delivery servers are BMC-managed infrastructure.

The only connectivity to external cloud allowed is Microsoft Exchange Web Services (EWS); other external connections are considered to be prohibited. For the avoidance of doubt, the external cloud and on premises infrastructure configuration, administrative settings, servers, logs, and your network environments are managed outside of BMC, therefore out of scope for BMC Support.

Custom headers are not supported.

Implementation options

For your email integration with BMC Helix services, you must make decisions about encryption settings and masquerading the BMC Helix mail address.

Inbound - BMC will host the public inbound mailbox, under the control of the Helix Service.

Outbound - When the Helix Service sends an email, the "From" address can be either our domain or a BMC customer's domain. BMC is also able to relay emails to a BMC customer-hosted mail server using a standard username and password protection.

Encryption

To guarantee message privacy as email messages transit the public internet mail infrastructure, BMC supports email encryption based on Transport Layer Security (TLS) and Secure Sockets Layer (SSL). The use of TLS and SSL encryption for messages from your infrastructure to BMC Helix services is under your control and is configurable within your mail infrastructure. No additional action is required from BMC SaaS Operations to enable encryption.

For messages sent from BMC Helix services to your mail domains, you can request that BMC enable encryption by indicating either preferred, required, or none. When preferred, the BMC Helix service attempts to use TLS and SSL encryption when available, but can still use unencrypted delivery if TLS and SSL are unavailable from your mail infrastructure. When required, BMC queues and does not deliver messages unless TLS and SSL encryption can be used. To use mail encryption, your mail infrastructure must support the standard SMTP STARTTLS protocol command for the delivery of encrypted messages. When none, encryption is not enabled.

For this decision, you select required, preferred, or none for each of your mail domains.

Note:

BMC can guarantee TLS and SSL encryption only to the mail exchange (MX) host defined in the internet DNS for the customer mail domains. If you use an intermediary for mail delivery, you must separately ensure encryption between mail hosts in their delivery architecture.

Masquerading

You are given an email receiving address (incoming@CustomerName-mail.onbmc.com). By default, BMC Helix applications also use this address as the apparent email "From" address for each message sent from the application to you. To enable masquerading, you supply an alternative email address such as helpdesk@CustomerName-mail.onbmc.com, to use as the apparent "From" address. When enabled, this alternative email address is seen as the apparent "From" address for all messages sent to you from the BMC Helix application.

You might also want to use masquerading for messages sent from your users to BMC Helix services. To enable this behavior, you must establish a redirect or transfer rule in your mail infrastructure to forward messages from the masquerade address (helpdesk@CustomerName-mail.onbmc.com) to the BMC Helix application receiving address (incoming@CustomerName-mail.onbmc.com). No additional setup is required to enable masquerading.

For this decision, you select an alternative apparent "From" address or the default incoming@CustomerName-mail.onbmc.com address.

When masquerading is used, you might be required to place the BMC Helix mail delivery server on the list of safe recipients. This action is required if your organization rejects mail messages from the internet where the "From" address is an internal company address, which is a common spam-avoidance filter. When requested, BMC SaaS Operations will provide the correct hostname and IP address to use for proper allowlisting.

Additionally, BMC recommends that customers using devices that interrogate traffic to/from the BMC Helix services (e.g., Bluecoat Proxy, Websense, Sophos UTM, Cisco SourceFire) be configured to allowlist ‘onbmc.com’ traffic through their proxies in order to optimize the user experience. Creating this exemption helps improve the performance as these devices basically serve as a traffic cop that will parse all traffic coming inbound and going outbound to the internet. By placing this exemption, user traffic is no longer interrogated or has to wait while other traffic is interrogated. If you are seeing ARERR 9351, you need to add this exemption.

For a list of external IPs required for allowlisting, see Public IPs for outgoing email servers.

Email alias

Administrators can create email aliases that forward all emails addressed to the alias to a specified account.

An email alias provides users the option to use different email addresses without having to manage multiple email accounts. Email alias makes communication simpler by letting users have multiple addresses for different purposes.

For example, you can use billing@ACME.com to handle invoices and hello@ACME.com to handle general inquiries. In this case, both addresses should point or forward the emails to the onbmc primary email account, that is, incoming@CustomerName-mail.onbmc.com.

Email security requirements

Sender Policy Framework (SPF)

SPF configuration is necessary to ensure that only authorized senders are authenticated on behalf of that domain. This setup will prevent forged emails and spam. With SPF configuration, your email server (where the domain is hosted) will identify the exact email server from where mails are sent. You will need to add the hostname or BMC's email server IP range in the SPF record of their domain.

Masquerading outbound emails with a sender address on behalf of the customer's domain or third-party network will only be allowed if the following conditions are met:

The customer or third party must take steps to trust the BMC Helix SMTP servers to send emails on their behalf. This includes adding our SMTP server public IP addresses to their published Sender Policy Framework (SPF) record.
The customer or third party must modify their email filters to accept the masqueraded email from BMC SMTP servers without flagging it as unsolicited.
The customer or third party must provide evidence showing the above steps have been addressed.

Once these conditions are met, BMC will approve the masquerading configuration and move forward with implementation.

In the illustration below, we show the process flow for publishing the SPF record (customer task) and sending the email (outbound from BMC):

DomainKeys Identified Mail (DKIM)

DKIM is used to validate the authenticity of the email that is being sent. It protects the domains from email spoofing, thus protecting the messages' integrity. Using public-key cryptography, DKIM validates the content of the email by generating two keys: one is public and registered with the ISP (where the domain is hosted), and the other is private, configured by BMC and retained on the outgoing mail server. Together these keys create a digital signature that verifies that the destination server has received the message unaltered.

DKIM uses two actions to verify your message:

The first action takes place on a server sending DKIM signed emails:

BMC will create the DKIM key pairs and provide the public key to you to add to your DNS. Your private key is kept secret and safe. When the sender sends an email to the recipient's email server, the DKIM signature is encrypted and attached to the mail header.
The second action takes place on the recipient server checking the DKIM signature:

The receiving email server extracts the DKIM signature from the header and compares it with DNS records. A matching signature means that the DKIM check passes and the email is delivered.

To request help with your SPF or DKIM request, submit a request to BMC Support. For additional information, see Inbound and outbound email integration.

Multiple mailboxes to support multi-tenancy

One mailbox for each environment is supplied with your subscription (ie. a mailbox for BMC Helix ITSM and a mailbox for BMC Helix Business Workflows service). If you require multiple mailboxes to support multi-tenancy or a similar use case, you must submit a Case on Support Central > Case Management and include the following details:

Company Name
Specify whether the mailbox should be added to BMC Helix ITSM or BMC Helix Business Workflows (especially if you have both subscription services)
Service URL

For additional mailbox requests with your BMC Helix ITSM and/or BMC Helix Business Workflows subscription service, please submit a Support Case. BMC Support holds the right to reach out should there be any concerns with your additional mailbox request.

BMC Helix-to-customer mail delivery pattern

The following figure shows the detailed mail delivery flow for messages originating in BMC Helix applications for delivery to a customer email address:

BMC Helix-to-customer delivery

Click the image to expand it.

Customer-to-BMC Helix mail delivery pattern

The following figure shows the detailed flow for messages from a customer to BMC Helix applications:

Customer-to-BMC Helix delivery