For an Email Service Provider, the 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 a 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 Figure#18.3.1, this article discusses the step-by-step process of creating the ESP Sending Server.
a) Server Name
This is the mandatory field and needs to be filled with the 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.
b) SMTP Host
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.
c) SMTP Port
Port25 is largely known as the default SMTP port, but some ISPs have 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.
d) Server IP
The main IP address of the sending server, for SSH/HTTP access.
e) PowerMTA HTTP Port
Mumara is highly optimized to utilize the PowerMTA resources, for the best configuration of the sending server. This field is part of PowerMTA web-based monitor directives and needs a 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.
f) SSH Port
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 the default port. In the case of a changed port, you need to specify the correct SSH port in this field. However, if the port isn't changed, the default port will then work successfully.
g) Server Username
Provide the username for the ESP sending server. It cannot be a non-root user; a particular user must have root access.
h) Server Password
The password associated with the username mentioned in the field above.
i) Deliver Local DNS
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 the 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.
j) PMTA Log Path
The field is already filled with a 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.
k) PMTA Log Rotation
Log rotation gives you an ability to prevent log file size from growing too large, and PMTA automatically rotates both logging and accounting files. This field needs to be filled with the number of days you want to keep the most current logging file maintained/saved. For example, if this date is set to “7d”, the application will just retain the logging files for the most current 7 days, and keep replacing the older files with the most current ones.
l) Spool Path
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.
m) PMTA Acct Path
As mentioned earlier in the case of the 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.
n) PMTA Acct Rotation
Rotation gives you an ability to prevent acct file size from growing too large, and PMTA automatically rotates both logging and accounting files. This field needs to be filled with the number of days you want to keep the most current acct file maintained/saved. For example, if this date is set to “7d”, the application will just retain the acct files for the most current 7 days, and keep replacing the older files with the most current ones.
o) PMTA Diag Path
Diag files are also like accounting files in . CSV format and offer information on the remote status and delayed status notification. The field is filled with the default path for the Diag file that you can change according to the desired location path.
p) PMTA Diag Rotation
Rotation gives you an ability to prevent diag file size from growing too large. This field needs to be filled with the number of days you want to keep the most current diag file maintained/saved. For example, if this date is set to “7d”, the application will just retain the diag files for the most current 7 days, and keep replacing the older files with the most current ones.
q) DKIM Fallback Domain
The structure to implement the email authentications is a 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 the case of client/user accounts in the 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 the 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.
r) SPF Domain URL
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 a 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 an 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.
s) IP List for Admin Access
Security measures 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.
t) Number of Accounts Allowed
With this field, you will be offered 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.