For an Email Service Provider, configuration of the sending infrastructure always holds key importance. An Email Service Providers is required to ensure smooth flow of email messages, high volume email delivery, practical way out for the categorization of non-delivery reports, processing of bounced messages, and implementation of an infrastructure capable of limiting the possibility of relaying the spam messages. So this always looks very technical stuff to configure sending servers for an ESP.
But with Mumara, you don’t need to be a server geek to configure your sending infrastructure; it remarkably covers all the technical details in a few simple steps. The current scope of Mumara ESP Edition only supports working with PowerMTA servers. It is one of the best blends of an email gateway and a front end management application that eventually lets you experience the pro features of PowerMTA.
Start the process of creating new sending server for your ESP infrastructure by clicking “Create Sending Server” under ESP setup. Some fields are already filled with default values and some sample entries that you can change according to your preferred settings. Followed by the Figure#18.3.1, this article discusses the step by step process of creating the ESP Sending Server.
This is the mandatory field and needs to be filled with a name of the sending server. While you select sending server for adding IPs, assigning IPs, or when viewing the table of currently available sending servers, the name helps to identify this server entry for easy selection.
In order to appropriately configure your outgoing email server, you need to fill this field with the correct path to your SMTP server. The SMTP host typically looks like smtp.yourdomain.com, or it can also be one of the IPs that can lead to the remote server where PowerMTA is installed, or even localhost if PowerMTA is installed to the local server where Mumara is also hosted.
Port25 is largely known as default SMTP port, but some ISPs has this default behavior to block port25. Therefore, Mumara allows to write more than one preferred ports in this field by separating with a comma, it can be port25 only, or altogether with alternative opening ports like 2525, 2526 (SSL), and 587. Example comma separated entry for multiple SMTP ports would be like 25, 2525, 2526.
Main IP address of the sending server, for SSH/HTTP access.
Mumara is highly optimized to utilize the PowerMTA resources, for the best configuration of the sending server. This field is the part of PowerMTA web-based monitor directives and needs port of PowerMTA web monitor. It is filled with 8080 by default but can be changed as there isn't any standard port for this. 8080 is also referred to as caching server port, and it can readily be occupied by some other software, therefore, you can specify the appropriate port for a web-based monitor in this field.
22 is the default SSH port, but one might have changed the default SSH port to some other port for several reasons, like to slightly tighten the security and preventing automated attempts with default port. In the case of changed port, you need to specify the correct SSH port in this field. However, if the port isn't changed, default port will then work successfully.
Provide the username for the ESP sending server. It cannot be a non-root user; a particular user must have root access.
The password associated with the username mentioned in the field above.
DSN refers to delivery status notifications that most commonly fall into the bounce report category. By default, PowerMTA is set to generate a DSN message and send it to the mentioned address of the Mail From domain, before it conclusively creates bounce details in the accounting file.
The simple dropdown, however, offers you the ability to Change the PowerMTA directive in regard to Deliver Local DNS. If you would select this option as “No” equals to “False” in PowerMTA, no DNS will then be generated. But selecting this option as "No" (False in PowerMTA) will not affect PowerMTA default behavior of writing the bounced details in accounting file, it will still be written, however, only the DSN will not be generated. This offers you the option to stop low priority queues, and optimize your environment for efficient sending.
Before we move on to setup the path to PMTA log and PMTA Acct file in their respective fields, let’s precisely learn more about both the files. PowerMTA efficiently maintains two separate files, one is the logging and the other is accounting files.
The log file records the error message that may occur during execution, information on the connection traces, startup and shutdown logs. Generally, the logs offer the first place to look when an error occurs. Additional to the logging files, the details about the processed emails are saved in the accounting file separately.
The field is already filled with default path to maintain the PowerMTA log files; however, if this default installation path leads to the low spaced partition on your server, you can conveniently change the path. It practically lowers down the risk of low disk space in case of excessive log files.
Log rotation gives you an ability to prevent log files size from growing too large, and PMTA automatically rotates both logging and accounting files. This field needs to be filled with number of days you want to keep the most current logging file maintained/saved. For example, if this date is set to “7d”, application will just retain the logging files for most current 7 days, and keep replacing the older files with the most current ones.
Path to the Spool files for storing queued messages, the default location appears in the field that can be changed to the desired location for your spool files, by specifying its path. The new spool requires to reload to activate while deactivating a spool requires restarting PowerMTA.
As mentioned earlier in case of PowerMTA Log Path, the primary benefit of this field would be that you can change the path to keep the accounting files on your desired destination, based on your disk space/ server partitions.
Rotation gives you an ability to prevent acct files size from growing too large, and PMTA automatically rotates both logging and accounting files. This field needs to be filled with number of days you want to keep the most current acct file maintained/saved. For example, if this date is set to “7d”, application will just retain the acct files for most current 7 days, and keep replacing the older files with the most current ones.
Diag files are also like accounting files in .CSV format and offer information on remote status and delayed status notification. The field is filled with the default path for Diag file that you can change according to the desired location path.
Rotation gives you an ability to prevent diag files size from growing too large. This field needs to be filled with number of days you want to keep the most current diag file maintained/saved. For example, if this date is set to “7d”, application will just retain the diag files for most current 7 days, and keep replacing the older files with the most current ones.
The structure to implement the email authentications is the complex situation in an ESP environment. The deployment of the DKIM structure by utilizing PowerMTA configuration resources reduces the risk of DKIM failure.
Sometimes the primary DKIM fails, doesn't match or doesn't even exist, in this case, the dkim-fallback-identity works as an alternative. It happens mostly in case of client/user accounts in ESP environment, the client accounts that don't select to send as White Label Senders, they would end up with DKIM failure or no matching key found.
The DKIM Fallback Domain would most probably the ESP primary domain in most of the cases, and this domain has to be setup with proper structure of DKIM in PowerMTA configuration and public key in the DNS, fill this "DKIM Fallback Domain" field with that particular domain. So if the primary DKIM fails, PowerMTA conveniently switches to dkim-identify-fallback automatically.
Sender policy framework or simply SPF is a method devised to curb the forgery of email by authenticating the sender domain. Implementation of the SPF helps to recognize which server is authorized to send an email on behalf of particular domain. The ultimate gain of implementing the SPF record into the DNS is that it prevents spamming, and discourages forgery of the email.
For example, client.com is the client of an ESP called espdomain.com. The client needs to create a SPF record into the DNS of client.com, which should identify that the mail server of the ESP (espdomain.com) is authorized to send on behalf of client.com (client.com). The email client of the recipient will check the SPF to establish the authenticity of the server as a legitimate sender.
Specify the particular domain in this field that the clients of the ESP will use in the SPF record entry, to authorize sending on behalf of their domain.
Security measure to ensure that no one except for these mentioned IP addresses will be able to open the PMTA web-monitor and view sending logs. Provide the comma-separated list of IP addresses for the admin users’ access.
With this field, you will be offered with the ability to limit the number of client accounts allowed for this particular server.
Click "Submit" to save configuration or "Reset" to remove your preferences and revert the default values.