MTA

Description

AKMTA (Altcraft Mail Transfer Agent) is an email sender developed by the Altcraft team and included in the Altcraft Marketing Platform. Altcraft MTA allows you to flexibly configure the sending speed of messages and the behavior when receiving negative responses from email providers in order to maximize deliverability to subscribers.

Sending Rules Configuration

AKMTA supports the configuration of the following sending rules:

• ISPs — delivery through different email providers
• Strategies — sending strategies (speed)
• Retry rules — rules for retrying message delivery
• Lock rules — rules for blocking message delivery
• Bounce patterns — templates of ISP server responses
• Default rules — delivery scenarios

Additionally, to work with MTA you configure:

• Private key — DKIM or SSH key required to access the sending server.
• Pool — a set of resources needed to send emails from a specific domain. The pool allows you to simultaneously track sending statistics and perform SPF alignment.

For more details on configuring each element, see the corresponding articles:

Default rules

Retry rules

Lock rules

Bounce patterns

Strategies

Keys

ISPs

Pools

Caching DNS Server

Default Resolver Problem

Sending a large volume of messages can overload network resources, leading to delays and potential bottlenecks. One solution for optimizing message delivery is to implement a caching DNS server.

When the system initiates a DNS query to convert a domain name into an IP address, it usually relies on the default DNS resolver provided by the operating system or network. Although these resolvers are generally reliable, they may not be optimized for high-volume message delivery. High-volume sending often requires frequent DNS lookups to resolve recipient domain names. Default resolvers can inefficiently cache these query results or not cache them at all, leading to redundant requests for the same information. This inefficiency can result in increased latency, network overload, and a higher risk of service disruptions.

By storing previously resolved domain-to-IP mappings, DNS caching servers reduce the need for redundant queries. This not only speeds up the resolution process but also saves bandwidth and minimizes load on upstream DNS servers. Additionally, DNS caching servers can enhance security by verifying DNSSEC signatures and protecting against certain types of cyber threats, such as DNS spoofing.

Unbound Setup

Installation

Unbound must be installed on the sender servers:

sudo apt-get update
sudo apt-get install unbound

Configuration

The configuration file can have any name and must be located in the /etc/unbound/unbound.conf.d/ directory, for example /etc/unbound/unbound.conf.d/default.conf. You can delete the configuration file created during installation in that directory and create a new one, or modify it.

Example configuration:

server:
    # Send minimum amount of information to upstream servers to enhance
    # privacy. Only sends minimum required labels of the QNAME and sets
    # QTYPE to NS when possible.
    # See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
    # details.
    qname-minimisation: yes

    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

# Remote control config section.
remote-control:
    # Enable remote control with unbound-control(8) here.
    # set up the keys and certificates with unbound-control-setup.
    control-enable: yes

forward-zone:
    name: "."
    forward-addr: 1.1.1.1
    forward-addr: 1.0.0.1

After creating the configuration, check it, restart Unbound, and enable it on boot:

unbound-checkconf
sudo systemctl start unbound.service
sudo systemctl enable unbound.service

---

Detailed information about the Unbound server can be found in the official documentation.

AKMTA Log Components

AKMTA logs are text records that capture all events related to email delivery. These records are maintained to monitor the mail agent’s operation, analyze its performance, and troubleshoot delivery issues. Logs help administrators track how the system processes each sending step, identify negative responses from email providers, and promptly adjust settings to improve deliverability.

Each entry in the AKMTA logs contains structured information about the event, which helps quickly understand the current state and the processing history of each message.

AKMTA logs are written to syslog in the following format:

2024/10/28 12:16:31 '1|2|Gmail|18029cdf9235cc8d','10','1','Gmail','231.127.65.9','noreply@templating.net','templating.net','zxhcgvxhjx32423@gmail.com','116.69.16.162','gmail-smtp-in.l.google.com.','500 dial tcp 231.127.65.9:0->116.69.16.162:25: i/o timeout','undefined','DIAL','3','68','7','0','abcdefghIJklmnoP-123QrstuvwXYz','asikjbyrinnvjfikdig123-dfgretyhvvbvasdaa''<nil>'

• Event date and time: '2024/10/28 12:16:31'
• Local storage identifier: '1|2|Gmail|18029cdf9235cc8d'
• Template ID: '10'
• Sender (MTA) ID: '1'
• ISP name or domain: 'Gmail'
• Sender IP address: '231.127.65.9'
• Sender email address: 'noreply@templating.net'
• Sender domain: 'templating.net'
• Recipient email address: 'zxhcgvxhjx32423@gmail.com'
• MX connection IP: '116.69.16.162'
• MX server: 'gmail-smtp-in.l.google.com.'
• Server response: '500 dial tcp 231.127.65.9:0->116.69.16.162:25: i/o timeout'
• Status: 'undefined'
• Command sent before response: 'DIAL'
• Account ID: '3'
• Mailing ID: '68'
• Database ID: '7'
• Resource ID: '1'
• Full message ID: 'abcdefghIJklmnoP-123QrstuvwXYz'
• Email-safe message ID: 'asikjbyrinnvjfikdig123-dfgretyhvvbvasdaa'
• Additional error message if needed: '<nil>'

tip

For convenient and structured work with AKMTA logs, you can enable output in JSON format.

To do this, add the JSON_SYSLOG parameter to the main platform configuration file and restart the platform.