Delivery servers

The mta module distributes messages to its mtachild child modules. Each mtachild prepares messages before requesting an authorization from the statistics server, and sending them.

The steps are as follows:

  1. The mta selects eligible messages and assigns them an available mtachild.
  2. The mtachild loads all information required for building the message (content, personalization elements, attachments, images, etc.) and forwards the message to the Email Traffic Shaper.
  3. As soon as the email traffic shaper receives the statistics server’s authorization (smtp stat), the message is sent to the recipient.

Email server statistics and limitations

The statistics server maintains the following statistics for each email server which receives messages:

  • Number of point-in-time connections open,
  • Number of messages sent in the last hour,
  • Rate of successful/rejected connections,
  • Rate of connections to unreachable servers.

At the same time, the module loads a list of limitations for certain email servers:

  • Maximum number of simultaneous connections,
  • Maximum number of messages per hour,
  • Maximum number of messages per connection.

Managing IP addresses

The statistics server can combine several instances or several machines with the same public IP address. It is therefore not linked to a specific instance, but it does have to contact an instance to recover limitations per domain.

Delivery statistics are kept for each target MX and for each source IP. For example, if the targeted domain has 5 MX and the platform can use 3 different IP addresses, the server can manage up to 15 series of indicators for this domain.

The source IP address matches the public IP address, i.e. the address as it is seen by the remote email server. This IP address can be different from the address of the machine which hosts the mta, if an NAT router is provided. This is why the statistics server uses an identifier which matches the public IP (publicId). The association between the local address and this identifier is declared in the serverConf.xml configuration file. All the parameters available in the serverConf.xml are listed in this section.

Delivery output controlling

To deliver messages to email servers, the Email Traffic Shaper component requests a connection from the statistics server. Once the request is accepted, the connection is opened.

Before sending messages, the module requests ‘tokens’ from the server. These are generally sets of at least 10 tokens, which reduces the number of queries to the server.

The server saves all the statistics related to connections and deliveries. In case of rebooting, the information is temporarily lost: each client keeps a local copy of their sending statistics and returns them to the server on a regular basis (every 2 minutes). The server may then re-aggregate the data.

The following sections describe the processing of a message by the Email Traffic Shaper component.

Message delivery

When a message is sent, there are 3 possible results:

  1. Success: the message was sent successfully. The message is updated.

  2. Message Failed: the contacted server rejected the message for the chosen recipient. This result matches return codes 550 to 599, but exceptions can be defined.

  3. Session Failed (for 5.11 upward): if the mta receives an answer for this message, the message is abandoned (refer to Message abandonment). The message is sent to another path or set to pending if no other paths are available (refer to Message pending).

    NOTE
    A path is a connection between the Adobe Campaign mta and the target mta. The Adobe Campaign mta can choose from several start IPs and several target domain IPs.