Page tree
Skip to end of metadata
Go to start of metadata

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



Note:

The SMTP incoming and delivery servers are BMC-managed infrastructure. Connectivity to external cloud and on premises infrastructure is prohibited.


This topic contains the following information:

Implementation options

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

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. This enablement can either be preferred or required. 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 delivery of encrypted messages.

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 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.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.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.

Outbound email security requirements:

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

  • The customer or third-party must take steps to trust BMC Helix SMTP servers to send email 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.

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.com) to the BMC Helix application receiving address (incoming@customerName.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.onbmc.com address.

Email whitelisting:

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 host name and IP address to use for proper whitelisting.

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 whitelist ‘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, that user traffic is no longer interrogated or having to wait while other traffic is interrogated. If you are seeing ARERR 9351, you need to add this exemption.

Multiple mailboxes to support multi-tenancy

If you require multiple mailboxes to support multi-tenancy, you can make use of the non-standard integration option. One mailbox is supplied with your subscription and additional mailboxes require the purchase of the non-standard integration offering. For more information about this option, see Additional storage, integration, and environment options.

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


Click the image to expand it.



Related topic

Inbound and outbound email integration

2 Comments

  1. Hi,I have realize we handle ITSM and BWF email differently during activation.The ITSM activation comes with a inbound and outbound email address configured, ready to use.When it comes to BWF, the onboarding team has to raise a request.Can we either align the activaition processes so both have mail configured, or document here which environments/services have email configured?ITSM, Innovation Suite, Multicloud Service Management, Business Workflows, Integration services, Chatbot etc ...

     

  2. Few queries on Mailbox integration for SaaS Customers


    One Email box from BMC can have multiple aliases created - Is this aliases considered as Multiple email integrations ?

    In that case SaaS customers need to purchase Non Standard integration options with the number of aliases or it is considered as Service/Change Requests without Commercials involved ?


    Clarity on this in the documentation will help Customers for planning the email integration..