Pmta - This is the user guide - done reading through, not able to understand much - printed - printed

pmta show queues --maxitems=40 --sort=rcpt | grep
pmta show queues --paused=yes

netstat -ant | awk '$5 ~ /:25$/ {split($5,a,":"); print a[1]}' | wc -l

pmta list --maxitems=90000 --pause
pmta list [--queue=domain[/vmta]] [--orig=addr] [--rcpt=addr] [--jobId=id] [--envId=id] 
    [--maxitems=n] [--pause] 

pmta resolve --connect --dumppackets  --source=
pmta trace --logdata --logresolution --to-log

cat /var/log/pmta/log | grep 'accepted connection' | awk '{split($7,a,":"); print a[1]}' | sort | uniq -c | sort -nk1

pmtaacctfind --output csv acct
pmtaacctfind --output csv acct | grep
pmtaacctfind --delivered --to --output csv acct > out.csv
pmtaacctfind --delivered --to --output csv acct
pmtaacctfind --delivered --to --output csv acct
pmtaacctfind --iso-times --output csv /var/log/pmta/acct-20170322 > 11023.csv

pmta show settings domain[/vmta] 

pmta trace --logresolution --to-log

pmta show topdomains
pmta reset counters 

pmta stop outgoing*
pmta stop outgoing
pmta delete --queue=queueName
pmta delete –* 

pmta list --maxitems=90000 --pause | awk '$2 !~ / {print $0}' | awk '$2 ~ / {print $3}' | xargs -n 1 -t -i pmta delete --rcpt={}

total-max-smtp-out 200
total-max-smtp-in 250

How can we examine the content of a message in a queue/domain with using the web interface?

// Black hole:
      type smtp
    <domain *>
      type file
      file-format append-mbox
      file-destination /tmp/mbox

<virtual-mta discard>
    <domain *>
        type discard

    type pipe
    command "/download/express/express-6.3.3/bounceback -f $to"
    queue-priority 100

thread-reuse no
<source 0/0>                 # matches all
    log-connections yes
    log-commands    no       # WARNING: verbose!
    log-data        no       # WARNING: even more verbose!
    allow-mailmerge yes
    smtp-service yes            # don't allow SMTP service
    #check-domainkeys-inbound true
    #check-dkim-inbound true
    check-mfrom-inbound true
    #check-pra-inbound true
    pattern-list masteroptoutlist #110414MAC Added to implement a master opt-out list
pmta resolve [--tcp] [--connect] [--dumppackets] [--interactive] [--source=[host,]ip] domainname
pmta resolve --connect --dumppackets  --source=VMTA DOMAIN

The resolve command queries the DNS for mail routing information (MX and A records)  
for the  specified domain, displays that information, and optionally connects to  
the first available mailer. It is intended to facilitate tracking down connectivity problems 
to destination domains.  For example, if you notice that the queue is building up for a  
specific domain, you can run resolve against that domain to figure out what problems exist and 
what if anything can be done to fix the problem.  

If no options are specified, DNS resolution is attempted via UDP and any relevant  
information is displayed, however no attempt is made to connect to a mailer.  

--tcp: this tells PowerMTA to use TCP (rather than the default UDP) for querying the  
    name server(s) 
--connect: this option tells PowerMTA to attempt to connect to the first available mailer as 
    well, after querying and displaying the specified domain's DNS server for mail 
    routing information.  
--dumppackets: this option tells PowerMTA to print out an hexadecimal dump of any DNS  
    queries and responses exchanged with the name servers.  It is ignored unless the 
    output is in textual format.  
--interactive: this option allows the user to try various SMTP commands, to help diagnose 
--source: this option tells PowerMTA form which internal IP address or hostname to 

pmta schedule domain/vmta

Instructs the mailer to immediately open a connection to the specified domain and to 
attempt delivery of messages queued to it. This command would be used, for example, if 
one figured out and fixed connectivity problems to a site and wanted to bypass the  
normal retry interval from the configuration file.  If there are no entries in the queue for  
the domain specified, the PowerMTA's response says so and it does not connect to the  
domain.  A wildcard can also be specified in domain or vmta, allowing multiple domains/vmtas 
to be scheduled at once.  

pmta trace [--logdata] [--logresolution] [--to-log] domain/vmta

Instructs the mailer to open a connection to the specified domain and to attempt delivery 
of any messages queued to it. This command is similar to the schedule command, with the 
difference that it also automatically enables logging for the domain for the duration of 
one connection.  If the –to-log switch is used, it is a shortcut to enabling logging in 
the configuration  file, reloading the configuration, scheduling a call and undoing these 
changes when debugging is finished.  By default, only the SMTP commands and responses are 
logged. The result of this command is written to the logging file.  

show domains [--vmta=name] [--connected={yes|no}] [--maxitems=n] [--errors] 
    [--sort={name|rcpt|size}] [name] 

show queues [--connected={yes|no}] [--paused={yes|no}]  [--mode={normal|backoff}] 
    [--maxitems=n] [--errors] [--sort={name|rcpt|size}] [queue] [name]

--mode: displays only queues in the specified mode. The default is to display queues in all 

--paused={yes|no}: allows selecting only paused or running queues for display.  By default, 
    both are shown. 

queue: name of the queue(s) to display, in the format domain[/vmta]

How can we determine the version of PMTA server that we are using?

pmta show version

How can we show a list of queues that are paused?

pmta show queues --paused=yes

How can we pause a queue?

pmta pause queue queueOrDomainName

How can we resume a queue?

pmta resume queue queueOrDomainName

How can we extract data from the PMTA accounting CSV file?

Power MTA server produces a daily accounting log file that is a giant CSV file containing the delivery status of every email it sends. If you're sending a lot of email, these accounting files can be very big.

/usr/sbin/pmtaacctfind --iso-times --output csv /var/log/pmta/acct-20170322 > 11023.csv

How can we avoid the 'connection timed out' issue?

Occassionally, our mail service received a 'connection timed out' error message when it connect to PMTA. I think the problem happens when the PMTA server is handling a lot of bounced message. See

Where is the configuration file?


Where can we find the user guide?


What do we need to do when we receive the license file?

We need to save it as /etc/pmta/license before starting PMTA.

What are essential PMTA configuration tips?

  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. In an upcoming release slated for Fall of 2014, you will have granular rate limiting control of both the source IP and sending IP basis.
  2. Keeping a clean configuration by using parameter inheritance more wisely. For manageability of configurations, it is important to keep them DRY. 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.

How can we determine the most important domains?

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.

How can we log transient errors?

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.

How can we play well with Hotmail?

Windows Live Hotmail is famous for throttling senders based on IP reputation. PMTA offers a number of parameters for tuning email delivery to specific domains. The max-connection-rate and max-msg-rate parameters can be used to prevent the "421 SMTP" error message (rate throttled) from occurring. If we do not react to these errors and keep on pushing your mail, your reputation could become even worse.

  max-connect-rate 10/m
  max-msg-rate 1000/h

What is a domain-macro?

Delivery settings in PMTA are made within the context of a recipient domain, such as PMTA uses a separate mail queue for each unique combination of virtual MTA and recipient domain. But there are many other domains related to Windows Live Hotmail, such as,,,,,, etc. All these domains and many others are handled by the same mail servers ( to Luckily, PMTA offers domain-macro that can be used to make settings for a set of domains. For example:

domain-macro hotmail,,,,
max-connect-rate 10/m
max-msg-rate 1000/h

This effectively create separate queues for each domain using the same settings. But because there are more queues, the number of connections and message rate is increased with each queue. This is far from ideal, because the mail servers of Hotmail look at all the traffic from a sender IP, regardless of the recipient domain. What we want is a single queue in PMTA for all mail traffic going to Hotmail. For this, we have to resort to an undocumented feature of PMTA, the queue-to parameter. This allows us to place mails for a domain in the queue of another domain. The latter queue will send all mail to the mail servers that its name resolves to. We can use this to collect the mails for a list of domains in a single queue.

domain-macro hotmail,,,,

<domain $hotmail>
  queue-to hotmail.queue

<domain hotmail.queue>
  max-connect-rate 10/m
  max-msg-rate 1000/h

The route parameter is used to make the MX lookup more explicit, and allowing us to use a special, arbitrary name for the queue to make clear that it is a special queue for all mails to Hotmail.

Now, we are able to control the mail traffic going to Hotmail's servers much more accurately. However, there is one catch to this configuration, and that is that MX lookups of other domain than are hard-coded in your configuration. Chances may be slim, but if one of the domains listed in the domain-macro is moved to another set of MXs, all mails will bounce, because they are always routed to the MXs of Also, because of the list of domains that are queued to the special queue are hard-coded, there could be other domains that also resolved to Hotmail's servers.

We can further enhance this configuration by using smtp-pattern-list to detect the errors mentioned above, and automatically put the queue into back-off mode running at a slower pace. Refer to the PMTA user guide.

After analyzing the connection data during "exceeded the connection limit" errors, I concluded that it is not the connection rate that causes the errors. Instead, I found a correlation between the errors and the number of concurrent connections. This suggests that max-smtp-out should be used instead of max-connect-rate to prevent these errors. A value of 1 to 5 concurrent connection is a good limit for volumes between 1000 to 10000 per hour.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License