PowerMTA | fVckin

Intro

PowerMTA is an enterprise-grade infrastructure application for high-volume email built to address the challenges of digital messaging and integrated customer communications. PowerMTA provides unsurpassed reliability and delivery execution in a stable SMTP environment with granular connection controls. Superior message throughput, simplified set up and configuration and real-time analysis provide our clients with performance, deliverability, and manageability without any further investment in hardware.

PowerMTA (PMTA) is industrial strength software which consistently delivers hundreds of thousands of emails per hour. It is specifically designed for better performance, deliverability and manageability. With its extensive configuration capabilities and Virtual MTA technology, it allows granular control of sources, sending IPs, and domain policies.

In 2016 acquisition of Port25 by Message Systems (now SparkPost) was announced!

PowerMTA Features

Confuigure number of simultaneous connections
Configure number of messages per connection
Confugure number of delivery attempts per hour (throttling)
Configure retry period and bounce period
Authentication method
Ability to break connections of lower priority queues
New IP address warm-up feature to help build reputation
Ability to pause queues and delete or re-start
Delivers 10x more messages per hour than leading freeware alternatives and corporate mail systems
Strict compliance with Internet email protocols
Includes both outbound and inbound message processing
VirtualMTAs allowing you to segment your mail-streams as necessary. Each VMTA may have its own IP address and delivery policy configured by you.
Real-time reputation monitoring
Immediate notification of perceived blocks
Ability to implement new delivery policy for perceived blocks
Command line statistics and analysis utility
Web-based status monitoring
Data export of statistics log (XML, CSV, HTML, etc.)
API to statistics log (C, Java, Perl)
Data can be accessed in real-time or batch mode.
Statistics can also be retrieved on a “per job” or “Virtual MTA” basis.
Standard submission interface using SMTP
File-based submission using pickup directory
Proprietary submission interface through our API (C, C++, Java, Perl, .NET)
Data exports from delivery log (XML, CSV, HTML, etc.)
API to delivery log (C, Java, Perl)
Forwarding of inbound messages to file or via local pipe
Installation follows the common approaches used on each of the major platforms.
Text-file configuration tool comes pre-populated with common settings
Extensive control options allow you to tailor PowerMTA to your specific needs.
A command-line management tool is provided.

Built-in support for :

Domain Keys and DKIM
SenderID and SPF

Platforms where PMTA can be installed includes :

Microsoft Windows (2003/2008)
Linux RPM based (Red Hat, CentOS) and DEB based (Debian, Ubuntu)
Sun Solaris (Solaris 8 or later, SPARC)

What’s an ideal server!

Perfect System

Secure configuration based on Linux operating system
SSH access with full root access
SFTP access for easy file transfer
Webmail, POP3, IMAP and SMTP for postmaster, abuse, bounce, FBL, … emails
Automatic daily backups
Reverse DNS (rDNS) or PTR
Multi IP and domain/subdomain setup
Free SSL on all domains

Perfect Mail Server

Multi MTAs/SMTPs with smart queue (IP rotation)
Automatic bounce processing
Auto processing spam complaints with Feedback loops (FBL)
Valid DomainKeys Identified Mail (DKIM) records
Valid Sender Policy Framework (SPF) records
Domain-based Message Authentication, Reporting & Conformance (DMARC)
Automatic backoff rules in case of delivery problems
Custom ISP rules to ensure best delivery rates

Perfect Email Manager

Create and Manage Contact Lists
Create Email Campaigns
Stay Delegate with auto follow-ups
Spin the words within your email campaign(s) to avoid being spammed
Manage your lists with triggers for best conversions
Get best stats with split (A/B) tests
Keep your lists clean by filtering spam complaints and abusers
Mask your main domain with multiple remote domains
Use multiple MTA/SMTP for better emailing practice
Be informed when the reputation gets down
Create user groups and user accounts
Track real-time advanced statistics along with Geo Location

Perfect Monitoring

Server up time
SMTP up time
Blacklist

Commands

Five Essential PowerMTA Configuration Tips

When asked what are the best configurations to use with PowerMTA? The answer is different for every region of the world. Configuration settings in the US will be vastly different than those in Europe for example, so global settings are not as effective. In this blog post we’ll look at five essential PowerMTA configuration tips that will help make your sending infrastructure more efficient and reduce I/O clutter.

1. Utilize source directives to make sure your email headers are correct

ESPs and many high volume senders send email on behalf of other organizations and often feel they do not have full control over the email headers. This is not the case, and if best practices are not followed, email almost inherently will end up being routed to the junk folder. With PowerMTA™, you can add missing data or Message-ID headers. You can also hide internal sources in the “received header,” or completely disable adding the received header altogether. The latter is often used to make it look as if the email originated from the sender’s public IP. You also have granular rate limiting control of both the source IP and sending IP basis, as a result of an update last year.

2. Keeping a clean configuration by using parameter inheritance more wisely

For manageability of configurations, it is important to keep them DRY. DRY stands for Don’t Repeat Yourself, and, is an acronym used by software developers. For example, PowerMTA™ merges the settings from all matching sources, top to bottom. Thus you can often move common settings to the source that matches 0/0. Except for always-allow-relaying of course, which should only be allowed from specific sources, by removing settings with obvious default values, you can further reduce redundant configurations.

With domain directives, all matching domain entries are merged, giving preference to more specific entries, regardless of the order in the configuration. By using sensible default settings for the wildcard domain, you can reduce the configuration to only a few exceptions. For example, the following settings string reduces the need to set limits on “many” specific domains:

max-smtp-out 2 # enough for small domains, increase for common domains
max-msg-per-connection 100 # most ISPs accept 100 emails per session
max-errors-per-connection 10 # avoid disconnect due to long sequence of invalid recipients

3. Don’t waste resources on invalid email domains

If the local part of an email address does not exist, you’ll usually get an error message from the ISP. However, if the domain is not valid, you might run into repetitive errors such as failed DNS lookup, non-responsive servers, or servers that refuse to relay from a particular domain.

PowerMTA™ should be configured not to waste resources on these domains, and focus delivery of resources to valid domains. For example, use a rather low max-smtp-out for default domains, and increase this for important valid domains. A setting of 20 is enough to send millions per hour, and completely over the top for many domains. Furthermore, you can instruct PowerMTA to bounce email if an MX record is missing. Invalid domains caused by typos often have an “A “record without a proper mail server, causing these domains to languish in the queue until they timeout. You can also use a domain macro combined with black-holing to drop mail known for discontinued domains or domains with anonymous discardable accounts. In any event, the goal is to keep the configuration “lean” for invalid or less important domains.

4. Apply settings based on your own data and experience

We’ve talked about this before, but I’d like to reiterate here. PowerMTA™ has a long list of configuration directives that you can use straight out of the box. Directly copying settings from other sources or matching configurations from another sender environment is not useful, since you might end up with redundant configurations, or even applying settings that are not applicable in your sending environment. The best approach is to keep it as simple as possible, and add settings that you understand, and that are appropriate in your “own” environment.

Senders in the US require a different configuration than senders in Europe. Furthermore, the settings often depend on the volume, the type the emails and the reputation of the IPs. You can use data from PowerMTA’s accounting files to determine what are the most important domains in your case. By looking at the bounce reports, you can determine which errors should trigger the back-off mode for example.

5. Log transient errors to monitor throttling by ISPs

The PowerMTA accounting logs are often used to record deliveries or bounces. But by enabling logging of transient errors, you can get a wealth of information about the delivery, and how to optimize it. Large webmail providers, but also smaller ISPs, have limits on the number of messages they accept from a certain IP. When the limit is reached, they return a temporary error, which can be logged by PowerMTA. This information can be used to adjust the volume for IP seasoning (warm-up) or maximum rate of sending, or tune the configuration of the back-off mode.

For more comprehensive information on configuration settings, join our forum and don’t hesitate to ask detailed questions about your settings and more specifically about your sending environment.

Encrypting Inbound and Outbound Email Connections with PowerMTA

Encryption is becoming increasingly necessary when transferring data across the internet, and email is no different. In PowerMTA 4.5 and later there are several methods to encrypt both inbound and outbound connections. Here we’ll provide a quick overview of how they may be achieved. Keep in mind, this document only deals with encrypting the channel, not the content.

Outbound Opportunistic Encryption

To use outbound opportunistic encryption in PowerMTA, simply add the following to your configuration file:

<domain *>
use-starttls yes
require-starttls no
</domain>

With this, PowerMTA will check to see if the remote mail server supports encryption. If it does, an attempt will be made to create an encrypted channel over which to send mail. If the encryption fails, or if no encryption is offered, then the mail is sent using no encryption.

To verify if the mail was sent over an encrypted channel, it is necessary to add additional fields to the CSV accounting file. This can be done with the following configuration:

<acct-file logacct.csv>
    records d, b
    record-fields d *, dlvTlsProtocol, dlvTlsCipher
    record-fields b *, dlvTlsProtocol, dlvTlsCipher
</acct-file>

If encryption is used, the above configuration will record the protocol and cipher used to deliver the message over an encrypted channel.

Outbound Client Certificate

While the vast majority of outbound connections do not require a local certificate, there may be some B2B cases in which the remote mail server requires PowerMTA to use a given certificate for encrypting the channel between the two servers. This can be facilitated in PowerMTA with a setup similar to the following:

<domain super-secure-server.com>
    smtp-client-certificate /path/to/certificate.pem password
    use-starttls yes
    require-starttls yes
</domain>

In the above example, any messages sent to super-secure-server.com will sent over an encrypted channel using the certificate /path/to/certificate.pem (in most cases supplied by the administrator of the remote mail server). If the encryption fails, the messages will not be sent.

Inbound Encryption

Of course, outbound traffic is only half of the traffic on a PowerMTA server. It may be required to encrypt the traffic coming into a PowerMTA server as well. This can be done in PowerMTA on a per <source> basis. The setup would look similar to the following:

#
smtp-listener 1.2.3.4:465 tls=yes
smtp-server-tls-certificate /etc/pmta/smtp-cert.pem “YourPasswordHere” smtp-server-tls-ciphers “HIGH:MEDIUM:!ADH:@STRENGTH”

<source 0/0>    # matches all
    allow-starttls yes
    require-starttls-before-auth yes
    allow-unencrypted-plain-auth no
</source>
#

Creation of the certificate /etc/pmta/smtp-cert.pem follows standard OpenSSL practices, and if assistance is needed in getting the certificate created (please contact support@port25.com). An example of the contents of the certificate is as follows:

—–BEGIN CERTIFICATE—–
YOUR CERT HERE
—–END CERTIFICATE—–
—–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,EBA505536010547C

YOUR PRIVATE KEY HERE
—–END RSA PRIVATE KEY—–

With this configuration all traffic connecting to 1.2.3.4 on port 465 can attempt to use encryption for transmitting email into PowerMTA.

Inbound Certificate Chain Validation

PowerMTA 4.5 and later supports the ability to validate certificate chains.

What’s New – PowerMTA v4.5

PowerMTA from Port25 is an industrial-strength software for high-volume email delivery. Designed for performance, deliverability and manageability, PowerMTA is able to consistently deliver millions of emails per hour. With it’s extensive configuration capabilities and VirtualMTA technology it provides granular control of sources, sending IPs, and domain policies.

Port25 recently introduced PowerMTA v4.5 as a major new release of PowerMTA. It now includes a wide variety of new advanced features and functionalities that allow for greater flexibility and delivery control to help maximize overall performance and deliverability.

PowerMTA Management Console (PMC) v1.5 is also now available with support for all new PowerMTA v4.5 features. Other new features in the PMC include: IP based reporting, saved reports, configurable session timeouts, and advanced reporting filters including sets and regular expressions.

Key features included in the release:

Scheduled Delivery Control – PowerMTA now supports the ability to schedule deliveries via a header. This may be very useful for instances when it takes a long time to build a campaign, or if you need to adhere to strict delivery windows.
Precached domains support – To help optimize DNS usage during peak sending times, PowerMTA now offers the ability to precache predefined domain names to ensure the DNS name is always available.
IP Rate Limiting – IP rate limiting allows for controlling the number of attempted recipients on a per-hour, per-minute and per-second basis for each IP address for each domain/VirtualMTA. This is primarily used by sites that define multiple IPs in a single VirtualMTA, and that want to limit the attempted delivery rate for each IP address in the VirtualMTA to the respective domains. One can also specify the maximum number of connections to be opened for this domain during the specified time period per IP per domain/vmta.
Auto Cold VirtualMTA Rate Increase – PowerMTA now supports the ability to auto-increase cold VirtualMTA mail volumes with a list of daily limits. This makes it very easy to have a set it and forget it configuration for warming new IP addresses.
Address Suppression Lists – Addresses in the suppression list are rejected (or turned into bounces, depending on options) during submission. This is very useful for sites that do not have complete control of the list to which they are mailing.

Other Noteworthy Enhancements in PowerMTA v4.5:

Custom retry intervals
Enhanced job control (pause & resume)
Recipient events listing
Second DKIM signing support
Backoff reason insight
Time interval for bounce-upon-no-mx
Defer-queue option in SMTP pattern list
Disabling of accounting records per queue
Domain definitions in virtual-mta-pools
Reverse DNS check support on inbound connections
TLS information in accounting file fields
Pattern matching support on non-ASCII headers
Added inbound AUTH username to accounting field
Change recipient priority on-the-fly

PMTA 4.5: IP Based Rate Limiting

One of the noteworthy features in PowerMTA’s new v4.5 release is IP based Rate Limiting. The feature, enabled via the new per domain “source-ip-max-msg-rate” directive, is designed to give delivery engineers/admins additional control. IP based rate-limiting allows for throttling the number of attempted recipients on a per-hour, per-minute and per-second basis separately for each IP address for each domain/VirtualMTA. This feature will be primarily used by senders that define multiple IPs in a single VirtualMTA and that want to limit the attempted delivery rate for each IP address in the VirtualMTA to the respective domains.

In addition, IP connection rate limits can now also be controlled via the “source-ip-max-connect-rate” directive, which allows one to specify the maximum number of connections to be attempted during the specified time period per IP per domain/vmta.

Backoff Insight

In previous versions of PowerMTA the only method to know why a queue entered backoff mode was to check the log file or to setup the backoff-notify directive. Now PowerMTA will show the “error” that caused the queue to go into backoff mode in the individual queues of the web monitor as well as in these commands:

pmta show queues domain/vmta
pmta show topqueues domain/vmta

IP based rate-limiting and Backoff Insight, are just two features of the latest release of PowerMTA v4.5, which is available now for download.

IP Monitoring Service

Backoff Insight

pmta show queues domain/vmta
pmta show topqueues domain/vmta

IP based rate-limiting and Backoff Insight, are just two features of the latest release of PowerMTA v4.5, which is available now for download.

IP Monitoring Service

If you receive an alert from your IP based monitoring service, such as excessive bounces or complaints, one of the most critical elements to preserving your IP reputation is the ability to quickly throttle at the source IP. The best tool I’ve seen has recently just launched by Postmastery. They offer IP reputation monitoring based off of SNDS Status and Sender Score. They also cross-reference your IP to a database of blacklists. You’ll receive real-time notifications via email based off of any decreases in any of the metrics above. Notifications are sent on an “as needed” basis- you’re notified at the beginning of a potentially forming IP reputation issue. So, if there’s any decrease in IP reputation or a high number of complaints, you’ll know about it very quickly. There’s also a weekly email with a summary of all IPs being monitored and their current rep/status. Postmastery also has the ability to use SNDS API keys to aggregate data from that as well, showing complaints from SNDS domains.

RELEASE of PowerMTA V4.5r5

Port25, A Message Systems Company, has just released its latest version of PowerMTA v4.5r5 and PowerMTA Management Console v1.5r5. Highlighted below are the major features of this particular release.

SMTPUTF8 Support

Support for SMTPUTF8 is a specification whether one can submit internationalized email addresses per RFC6531, RFC6532, and RFC6533 to PowerMTA from the connecting IP address. When enabled or set to yes (or true), PowerMTA will list “SMTPUTF8” in the list of extended SMTP commands supported for the connecting IP, allowing the submitter to use internationalized email addresses in the SMTP envelope. Note that if the remote gateway for the domain does “not” advertize support for SMTPUTF8, PowerMTA will subsequently bounce the message(s) for the recipient out of the queue. If desired, SMTPUTF8 support can be disabled with the new per-<source> allow-smtputf8 directive.

UTF-8 is the dominant character encoding specification for the internet accounting for 87.1% of all Web pages as of June 2016. The Internet Mail Consortium (IMC) recommends that all email programs be able to display and create mail using UTF-8.

MX RollUp

MX Rollup List Allows one to define “rollup” queues based on the MX records of the recipient domain, in order to consolidate separate but related recipient domains into one queue. Messages moved into the roll up queue are handled as if they were one recipient domain with regards to rate limiting, connection caps, and other directives.

For example, since ‘msn.com’, ‘live.com’ and ‘outlook.com’ are all handled by the same exact MXs or Gateway, it makes sense to roll these up into a single queue (outlook.rollup for example) vs. being handled separately by PowerMTA. This feature works very well for the large mailbox providers that provide corporate hosting, for filtering/antispam cloud providers, or for large hosting providers in general that manage corporate email for tens or hundreds of thousands of various domains. To configure this feature, you need to define the MX record that maps to each rollup queue name along with the name of the rollup queue, which must end in “.rollup.” More than one MX can be mapped to the same rollup queue.

Additional Features include but not limited to:

Added support for internationalized domains to “pmta resolve”
Increased spool-max-recipients limit to ~16.8M and total-max-smtp-out to 10,000
Added ability to show per-recipient schedule in “pmta list”
Added support for pattern list header matching on Encoded-Words that include a language declaration, as specified by RFC2231

Related updates 2019

AOL and Yahoo merge could impact your email delivery and MTA

fIn 2018 AOL reported that AOL and Yahoo will come together under the OATH umbrella and merge with the Yahoo email infrastructure to serve both brands. This happened on 20 February 2018, and now all the AOL recipient domains’ MX, including the following, will point to
mx-aol.mail.gm0.yahoodns.net :

– aol.com
– verizon.net
– aol.co.uk
– aim.com
– netscape.net
– cs.com

Will your email delivery be affected? Based on some quick reviews, Postmastery engineers saw that senders who had bad delivery to AOL will now see improved delivery if they had good delivery to Yahoo. Senders who had bad delivery to Yahoo and good to AOL, will probably experience the reverse.

Register FBL on both providers

FBL complaints would still come to mailboxes which are still on AOL infrastructure. As soon as the mailboxes are moved to Yahoo, the FBL reports will come from Yahoo. It is therefore strongly recommended to register FBL on both providers. Please be advised that Yahoo provides FBL reports based on DKIM signing domain, while AOL sends FBL reports based on sending IP addresses.

BIMI – Brand Indicators for Message Identification (BIMI)

BIMI is the new open standard to visualize your brand in the recipient’s mailbox with an image.
The new standard makes use of DMARC, leading some to call BIMI “DMARC 2.0”. While almost all previous authentication and identification methods work in the background, BIMI is the first one that really tries to visualise and strengthen your brand right on the front-end. The mailbox provider will show your branded image within the user interface.
BIMI

What are the prerequisites for BIMI? In order to enable BIMI you have to make sure the following requirements are in place.

You need to have a DMARC record with a ‘quarantine’ or ‘reject’ policy.
You need to be recognised as bulk sender and have a good sender reputation.
You need a DNS record, the so-called BIMI Assertion Record. This record will contain the link to the image (SVG format) that is going to be used. This TXT record needs to be placed as (for example) default._bimi in the DNS of the sending domain. Usually this would be the From header. The value of the record looks like: v=BIMI1; l=https://www.example.com/images/logo.svg;

This should be enough for now. But it the future you may need to certificate the image. Otherwise anyone could publish someone else’s logo on their domain. The providers require the certificate to prove ownership of the domain name. The proof is held and secured (cryptographically) by third parties referred as Mark-Verifying Authorities.

Who is supporting BIMI? BIMI is currently only supported by OATH (Yahoo & AOL, they will identify domain brands automatically) and Verizon. But we recently heard at the CSA in Cologne, that Gmail has joined the working group. It is not yet clear whether they will actually support BIMI in their client.

Microsoft seems to be going in another direction and will not use the BIMI standard. Instead they are going to use so-called business profiles, see business.microsoft.com. It’s in beta testing at the moment and is publicly available for any consumer-facing business in the US.
And, will BIMI take off?

Gmail is not supporting BIMI and Microsoft is following a different strategy. Nevertheless it’s a good to start with BIMI tech-preparations and testing.