One of the two primary editions of Mumara is the ESP (Email Service Provider Edition). The ESP edition of Mumara helps setting up complete structure of an email service provider. In email marketing industry, an email service provider service/company is the one that offers email services to the clients, using their preconfigured email platform. ESPs can further be categorized according to their platform and service spectrum, like some of them offers transactional mailing solution, while the others deal with promotional emailing and newsletters, but in general, an ESP (Email Service Provider) is the one that offers email services.
The essential of the ESP environment is its ability to seamlessly manage multiple levels of configuration, IPs infrastructure, SMTPs, classifying client’s email stream, management of accounting logs, collection, categorization and processing of client’s bounce emails, with addition to other details and even the minute ones are required being well-tuned. Mumara ESP is comprehensive platform that deals with all ins and outs of an ESP infrastructure. But for this article, leaving the other details of Mumara ESP aside, the entire focus will remain on the Mumara ESP setup of PowerMTA server.
The current scope of Mumara ESP only supports configuring email relay using PowerMTA, being market leader commercial MTA application, most topline ESPs use PowerMTA. So it is like a necessary thing for the current ESP edition users to setup their sending environments using PowerMTA. Mumara may open for more options in the future, but at present, PowerMTA is the only one. Mumara offers the ability to take you one step ahead of the basic PowerMTA configuration, it includes number of useful tools to actively monitor and manage your ESP environment.
Remote Bounce Processing
The built-in web monitor of PowerMTA offers valuable summary of mailer activity, and information in regard to different queues. During the setup of “Sending Server”, Mumara ESP offers the field to define PowerMTA HTTP port, this value added connection between Mumara and PowerMTA web monitor helps performing several beneficial actions.
Bounce categorization and processing for the client accounts is the crucial part of an ESP, several had hard times configuring their system for appropriate categorization and effective processing of bounced emails. Connecting Mumara with the PowerMTA web monitor will help setting up your system to process the bounce emails directly from accounting logs maintained in PowerMTA web monitor. It gives a rapid way of processing well categorized bounced patterns.
Change Default File Paths
PowerMTA maintains different kind of files for the active monitoring and management of the email stream, files that may contain reporting data, or used to store queued messages. PowerMTA automatically stores these files on default set destinations. But due to the large volume of sending in an ESP environment, some of the files size may exceed, like the files that stored queued messages or the acct files.
The best way to minimize the risk of possible delivery errors, or getting into the low disk space issue, is to change the storage path of the files that may consume good amount of space on a low partitioned disk space. During the configuration PowerMTA Sending Server, Mumara offers the ability to change paths to store these files, from default location to some other partition with more space.
The function supported by the PowerMTA rotation directive will help keeping the most current data available by automatically rotating the files. Mumara offers the simple fields to set rotation period for log rotation, acct file rotation and diag file rotation. The rotation period defined in the field ensure that after the specified days, older most file will be replaced with the latest one, and no file will cross the rotation days limit. That’s how rotation saves files from getting too long.
Stop Low Priority Queues (Deliver Local DSN)
For the ESP environment powered by the blend of Mumara Email and PowerMTA, it isn’t compulsory to process bounces from the bounce to email account, as bounce can more effectively be categorized and processed remotely from files maintained by PowerMTA web monitor.
When an email is bounced back in PowerMTA, following its default behavior PowerMTA writes its detail in the accounting file, as well as generates a DSN (Delivery Status Notification) and tries to deliver it to specific address (Bounce to Email) of Mail From domain. When the application is processing the bounce directly from PowerMTA files, it gives the freedom to stop generating and delivering of the local DNS to Mail From domain.
So using this PowerMTA directive to stop generating and delivering the local DSNs will eventually stop the low priority queues and eventually improves the speed of high priority queues.
Alternative DKIM if Primary Fails (DKIM Fallback Domain)
The structure and implementation of the important authentication DKIM turns out to be somewhat complex situation for an ESP. The client’s DKIM sometime doesn’t match or fails to pass. DKIM Fallback identity offers a practical way out to cope with this failure. During the configuration of the sending server within Mumara, a field to announce the fallback domain is provided, so that if client’s primary DKIM fails to pass or ends up with no matching key, application automatically switches to the DKIM identify fallback. It ensures that no emails are blocked due to DKIM failure.