*************************************************

*******
PowerMTA v4.5 Release Notes
*******
*************************************************
1. General Notes
2. Important Changes
2.1 Deprecated "route" directive, in favor of the new "smtp-hosts"
2.2 PowerMTA binary accounting file no longer available
2.4 Java 6 or later required for Java API
2.5 Removed support for "cold-virtual-mta cidr hostname" syntax
2.6 Deprecated "auto-cold-virtual-mta"
2.7 ActivePerl 5.16 required for Perl submission API on Windows
3. Noteworthy Enhancements
3.1 Scheduled Delivery Control
3.2 Custom retry intervals
3.3 Enhanced job control (pause & resume)
3.4 Precached domains support
3.5 Recipient events listing
3.6 Second DKIM signing support
3.7 Backoff reason insight
3.8 Time interval for bounce-upon-no-mx
3.9 Defer-queue option in SMTP pattern list
3.10 Disabling of accounting records per queue
3.11 Domain definitions in virtual-mta-pools
3.12 Nested pattern-list support
3.13 Reverse DNS check support on inbound connections
3.14 TLS information in accounting file fields
3.15 Pattern matching support on non-ASCII headers
3.16 Address Suppression Lists
3.17 Added "rcvSmtpUser" to accounting field
4. New or enhanced command line commands
4.1 Added "PMTA PAUSE JOB JOBID"
4.2 Added "PMTA RESUME JOB JOBID"
4.3 Updated pmta show queues/topqueues/queue output
4.4 Added --no-rcpt-events switch for pmta show queues/topqueues/queue command
s
4.5 Added --retry-recipients option in trace command
4.6 Added --retry-recipients option in schedule command
4.7 Added --priority switch in pmta list command
4.8 Added show precache command
4.9 Added --older-than option to delete command
4.10 Enabled TLS trace by default in "pmta resolve --connect" command
4.11 Added "max-smtp-msg-rate" and "max-smtp-out" to "show settings" output
4.12 Added "rcvSmtpUser" to pmtastats and pmtaacctfind
4.13 Added "PMTA SET PRIORITY"
5. New Directives and directive enhancements
5.1 VirtualMTA Pool Directives
- <domain> directives now allowed
- cold-virtual-mta now allowed
- domain-key now allowed
- max-smtp-out now allowed
- max-smtp-msg-rate now allowed
- include-headers-from now allowed
5.2 Domain Directives
- backoff-max-smtp-out

disable-acct-records (d,b,t,tq) 'r' records cannot (yet) be disabled

UPDATED retry-after
UPDATED backoff-retry-after
UPDATED bounce-upon-no-mx
bcc-upon-delivery
max-cold-virtual-mta-msg
replace-smtp-421-service-response
source-ip-max-msg-rate
source-ip-max-connect-rate

5.3 Source Directives

- smtp-data-timeout (10m)
- smtp-command-timeout (10m)
- check-iprev-inbound
- trace-iprev-check
- reject-iprev-check-temperror
- reject-iprev-check-permerror
- reject-iprev-check-fail
- process-x-schedule
- retain-x-schedule
- retain-x-dkim-options
5.4 DNS Directives
- precached-domains-file
- precached-refresh-interval (5m)
- precached-max-domains (500)
5.5 Global Directives
- ip-connection-limit
5.6 Other Directives
- <address-list>
- <address-list> address-file
- <alias> *@domain
6.0 Other Enhancements
6.1 Acctfind to allow separating the header and arf tag or arf field name
6.2 Updated delivery behavior for transient errors on multiple MXs
6.4 Fixed <source> require-auth not being observed
6.5 Modified backoff-... directives that specify a limit
********************************************************************************
1. General Notes
********************************************************************************
PowerMTA v4.5 is a major new release of PowerMTA software, which follows the
previous v4.0 release. It 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.
Upgrading from v4.0 to v4.5 should be straightforward and mostly a matter of
running the installer. Note that PowerMTA v4.5 requires a v4.5 license
activation key (LAK), and that the v4.5 LAK will *only* work with v4.5 builds.
Please also note that, as described in Section 2. of this document, some
directives in v4.0 have become deprecated in v4.5 given new enhanced
functionality, so it is quite important to read this next section carefully.
As best practice dictates, Port25 always recommends backing up your PowerMTA
configuration file, mail spool, log and accounting files whenever upgrading
from one PowerMTA version to another.

Please contact Port25 Solutions at support@port25.com if there are any

questions regarding this process.
********************************************************************************
2. Important Changes
********************************************************************************
Enhancements to existing features sometimes require changes to existing
configuration directives. When this happens, the old directives become
"deprecated". Deprecated directives will still work as before, however they
will not enable the new enhancements or new functionality, and may eventually
be removed in a future release. With this, we always recommend to sites to
try and move off of the deprecated directives and reconfigure PowerMTA to use
the new directives at their earliest convenience, after upgrading.
=====================================================
2.1.
=====================================================
The "route" directive has been deprecated, in favor of the new "smtp-hosts"
directive. "smtp-hosts" accepts the same syntax as "route" and works
essentially the same way, with the following differences:
- if a single domain name is specified, it is interpreted as a host name.
No MX lookup will be performed in this case, but only A/AAAA (IP address).
- "smtp-hosts" accepts "lookup-mx:X", where X is a domain name, to instruct
PowerMTA to look up domain name's MX like it used to do when a single
name was specified in "route".
=====================================================
2.2.
=====================================================
The binary accounting file is no longer available. If accounting files are
needed, the CSV accounting file must be used.
=====================================================
2.3.
=====================================================
Java 6 or later is now required for use of the Java submission API.
=====================================================
2.4.
=====================================================
Removed support for "cold-virtual-mta cidr hostname" syntax which has been
deprecated since 3.5.
=====================================================
2.5.
=====================================================
deprecated "auto-cold-virtual-mta" in favor of explicitly defined cold VirtualMT
As
=====================================================
2.6.
=====================================================
Due to limitations on compiler support on newer ActivePerl builds, the
Perl submission API currently requires ActivePerl 5.16. We're working
on a new version of this API that will be more version agnostic.

********************************************************************************
3. Noteworthy Enhancements
********************************************************************************
=====================================================
3.1. 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 there is a need to have a campaign go out very quickly (e.g. flash sales).
The format is:
x-schedule: <start time - 1>/<end time - 1>, <start time - 2>/<end time -2>
Here is an example:
x-schedule: 2015-05-29 17:01:11 / 2015-05-29 17:30:11, 2015-05-30 17:01:11 / 201
5-05-30 17:30:11
As many times as you want are allowed, as long as you fold the header so each
line is not longer than 1000 characters.
The bounce-after does not apply to such recipients. The schedule
overrides the bounce-after and the message is bounce when there are no more
schedules to try. In addition, if the queue is in retry mode when the
messages are injected, the message delivery will not start at the window start
time, but rather message delivery attempts will start when the queue come out
of retry mode.
For strict adherence to the schedule start time for large campaigns like flash
sales it is required to set the same jobID for all recipients of the given
campaign. For best results, customers should ideally use the same schedule
for all the recipients in a job, and not mix scheduled and unscheduled
recipients in a job. Messages with the combination of Scheduled Delivery
Control and a jobID will use the start time defined by the first message for
the job injected into the queue.
For example, if the first recipient in the queue for jobID 123 has a start
time of 12pm, and the second recipient injected into the queue for the same
jobID has a start time of 11am, the 12pm start time will be used for both
recipients. Likewise, if the first recipient in the queue for jobID 123 has a
start time of 11am, and the second recipient injected into the queue for the
same jobID has a start time of 12pm, the 11am start time will be used for both
recipients.
=====================================================
3.2. Custom retry intervals
=====================================================
retry-after and backoff-retry-after now take a time interval in addition to
the static, defined time. This allows for adding up to 30 different retry
periods. This may be useful for domains in which the likelihood of messages
being delivered decreases over time. The last defined interval is used until
the message bounces. The interval resets on a restart of the PowerMTA
server. An Example usage would be:
<domain example.com>
retry-after 10m,10m,10m,10m,10m,10m,30m,30m,30m,30m,1h,1h,2h,2h,4h,4h,10h
</domain>
In the above example the domain would be tried every 10 minutes for the 6
tries, every 30m for the next 4 tries, every hour for the 2 tries, every 4

hours for the next two tries, and finally, every 10 hours until the message is
bounced.
=====================================================
3.3. Enhanced job control (pause & resume)
=====================================================
When using a Job ID, it may become necessary during the course of a mailing
to pause the job. Instances of when this would be needed might be to make
sure the injected job was setup correctly, or that it is using the correct
VirtualMTAs. The command to pause a job would be:
pmta pause job Campaign1234
And to resume the job:
pmta resume job Campaign1234
In the above example, Campaign1234 would be the Job ID that needs to be paused.
=====================================================
3.4 Precached domains support
=====================================================
For senders that have DNS server issues when loading large amounts of domains
into PowerMTA in a short period of time, or when maintaining large amounts of
domains with short a short DNS TTL, PowerMTA now offers the ability to
precache a given subset of the DNS names to ensure the DNS name is always
available. This feature is enabled by use of the new, global <dns> tag.
<dns>
precached-domains-file C:\pmta\precached-domains.txt
precached-max-domains 500
precached-refresh-interval 5m
</dns>
The above defined file would look something like the following:
hotmail.com
yahoo.com
aol.com
gmail.com
PowerMTA would only precache the first 500 domains in the file, refreshing the
DNS for these domains every 5 minutes. Use of this directive may overtax a
DNS, and may result in being banned from using a public DNS server like
Google or OpenDNS. It is highly recommended to use a dedicated, in-house DNS
server when using this feature.
=====================================================
3.5 Recipient events listing
=====================================================
To aid in real-time queue diagnostics, PowerMTA now shows the last 50 recipient
delivery, bounce, and deferred events. This data is available by default
in the output of the following commands in addition to being displayed on
the individual queue detail page in the web monitor:
pmta show queues
pmta show topqueues
pmta show queue domain[/vmta]
The information is held in memory and is flushed when all recipients
are delivered for the queue.

=====================================================
3.6 Second DKIM signing support
=====================================================
PowerMTA now officially supports double DKIM signing a message. This is a
direct requirement of gmail when using their feedback loop. All of the
existing dkim-* directives now support the prefix "second", and which are used
for the second signature (bottom most one) for the message.
We use the same domain-key directives for both signatures. Here is the list
of new directives used for the second DKIM signature:
second-dkim-add-body-limit
second-dkim-add-timestamp
second-dkim-algorithm
second-dkim-body-canon
second-dkim-expire-after
second-dkim-headers
second-dkim-headers-canon
second-dkim-identity
second-dkim-sign
These new directives are used just like their equivalent dkim-* directives.
A configuration example is below which sends messages with both a customer
signature and ESP signature, which are only to be applied to messages in
virtualMTA 12345. The customer signature is based on the domain of the
From: header (customerdomain.com) while the ESP signature is based on the
second-dkim-identity option defined (espdomain.com). PowerMTA would include
gmail's required Feedback-ID header in both signatures for messages to gmail
only.
<virtual-mta 12345>
domain-key esp,espdomain.com,c:\pmta\keys\esp.espdomain.com.pem
domain-key
customer,customerdomain.com,c:\pmta\keys\customer.customerdomain.com.pem
<domain gmail.com>
dkim-headers Feedback-ID
second-dkim-headers Feedback-ID
</domain>
<domain *>
dkim-sign yes
second-dkim-sign yes
second-dkim-identity @espdomain.com
</domain>
</virtual-mta>
Note: The x-dkim-options header method is not supported for the second
signature, but still can be used for the first signature.
PowerMTA will still deliver the message if due to message attributes and
configuration settings, there are no signatures to be applied, only one
signature to be applied or both signatures are to be applied.
=====================================================
3.7 Backoff reason 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
pmta show topqueues
=====================================================
3.8 Time interval for bounce-upon-no-mx
=====================================================
When using the bounce-upon-no-mx setting it may be a good idea to try the
domain a few times before actually bouncing the message in the event that the
domain in question isn't simply having DNS issues. To facilitate this, the
bounce-upon-no-mx directive now takes a time interval to wait before bouncing a
given domain. An example would be:
<domain example.com>
bounce-upon-no-mx 1h
</domain>
In the above example, PowerMTA would try the given domain for 1h before
bouncing the message if an A record existed, but no MX existed.
=====================================================
3.9 Defer-queue option in SMTP pattern list
=====================================================
When a queue goes in backoff mode, it does not automatically get put into retry
mode
as well. Not all SMTP errors will have PowerMTA putting the queue into retry mo
de
immediately vs., for example, having PowerMTA reconnect on the next MX. Since i
t may
be desirable to have the queue put into retry mode immediately for certain error
s,
a new defer-queue option was added in SMTP pattern lists.
This option gives you full control in forcing the queue into retry mode immediat
ely
if desired, on a per SMTP response basis. A sample definition would look like;
<smtp-pattern-list deliveryActions>
reply /resources temporarily unavailable/ defer-queue
</smtp-pattern-list>
The defer-queue action is mutually exclusive to bounce-queue & skip-mx actions
and only one of the three actions can be specified for a pattern.
=====================================================
3.10 Disabling of accounting records per queue
=====================================================
There may be certain queues in which accounting records are not required. This
could be because PowerMTA is simply relaying to another PowerMTA or corporate
mail server in which the accounting records are not needed for tracking. The
records that can be turned off are 'bounce','delivery','transient', and
'transient-queue (d,b,t,tq)
<domain example.com>
disable-acct-records d,b,t,tq
</domain>
=====================================================
3.11 Domain definitions in virtual-mta-pools
=====================================================

To reduce the clutter of the PowerMTA configuration file, it is no longer

required to define the same <domain> directives in all the VirtualMTAs that
comprise a <virtual-mta-pool>. PowerMTA now supports the ability to define
<domain> directives inside a <virtual-mta-pool>, which will then be inherited
by all VirtualMTAs in the pool. <domain> settings in the individual
<virtual-mta> will override those defined in the <virtual-mta-pool>.
=====================================================
3.12 Nested pattern-list support
=====================================================
In some cases it may be better to use a <pattern-list> to select another
<pattern-list> instead of selecting a VirtualMTA directly. This can be
accomplished in PowerMTA with the new "call-to" option defined within a
pattern.
Assuming a message has the following header:
x-custom-header: abc123
and you wanted to use that header and content to select another pattern to then
select
the correct virtualMTA. The following would be defined in PowerMTA's config fil
e;
#
<pattern-list specialSelector1>
mail-from /newsletters/ virtual-mta=vmta1
</pattern-list>
<pattern-list selections>
header x-custom-header /abc123/ call-to: specialSelector1
</pattern-list>
<source 0/0>
pattern-list selections
</source>
#
In the above example, <pattern-list selections> would match the x-custom-header:
header,
and then select <pattern-list specialSelector1> to then apply next to the messag
e,
given the "call-to:" definition. If the SMTP MAIL FROM address for this message
included "newsletters", PowerMTA would then use VirtualMTA vmta1 for the message
.
=====================================================
3.13 Reverse DNS check support on inbound connections
=====================================================
To assist in blocking potentially unwanted email from being received by
PowerMTA, it now offers the ability to preform a DNS PTR check on the IP
address of the connecting server to see if the EHLO used matches the DNS PTR
of the given IP. PowerMTA now takes the following boolean <source> directives
to facilitate this functionality:
<source 0/0>
check-iprev-inbound true
trace-iprev-check false
reject-iprev-check-temperror false

reject-iprev-check-permerror true
reject-iprev-check-fail true
</source>
=====================================================
3.14 TLS information in accounting file fields
=====================================================
With the mailing industry moving more to a secure and encrypted sending model,
it is necessary to track if a given message was delivered over a secure socket,
and if so, what protocol and cipher were used. To this end, users can now
choose to have PowerMTA add this information into the CSV accounting
file by defining the fields dlvTlsProtocol & dlvTlsCipher in the record-fields
directive. For example;
<acct-file log\acct.csv>
records d, b
record-fields d *, dlvTlsProtocol, dlvTlsCipher
record-fields b *, dlvTlsProtocol, dlvTlsCipher
</acct-file>
=====================================================
3.15 Pattern matching support on non-ASCII headers
=====================================================
RFC 2047, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text", allows for non-ASCII characters to be
used in headers. In the event that these characters are needed to be used in
a header that is also used for pattern matching, PowerMTA now has the ability
to pattern match on these characters.
=============================================
3.16 Address Suppression Lists
=============================================
Lists can be defined with the new global "<address-list listName>" tag and one
or more can be referenced within a <source> with the new "suppression-lists"
directive. Addresses in the suppression list are rejected (or turned into
bounces, depending on options) during submission. Multiple suppression lists
may be used.
#
<address-list suppression1>
address foo
# local part
address foo@bar.com
# email address
address /foo/
# pattern
</address-list>
<address-list suppression2>
domain foo.com
address-file /etc/pmta/addresses
</address-list>

# domain
# email addresses or local parts, 1/line

<source 0/0>
suppression-lists suppression1,suppression2
</source>
#
If the <source> directive accept-invalid-recipients is set to "no", then the mes
sage is rejected at the
time of submission (i.e., while processing the RCPT command).
If the <source> directive accept-invalid-recipients is set to "yes", then the me
ssage is queued and

later bounced with generation of a bounce record with details such as:
dsnStatus: 5.7.1 (delivery not authorized)
dsnDiag: smtp;550 5.7.1 recipient is in suppression list "a1": <foo@bar.com>
For BSMTP pickup files, If XACK is set to "on", then the message is rejected
while the file is picked up (i.e., while processing the RCPT command). This is
logged in the PowerMTA log file just like any other pickup submission error.
If XACK is set to "off", then the file is picked up and the message is later
bounced with a bounce record that looks similar to SMTP submission case above.
For non-BSMTP pickup files, the message is rejected while the file is picked
up (i.e., when processing the x-receiver header). This is logged in the
PowerMTA log file just like any other pickup submission error. There is no
mechanism currently to submit the message successfully and/or to get a bounce
record in this case.
=============================================
3.17 Added "rcvSmtpUser" to accounting field
=============================================
Added "rcvSmtpUser" accounting field to delivery, bounce, and transient
records, indicating the authenticated SMTP user at the time the email
was received.
********************************************************************************
4. New command summary
********************************************************************************
=====================================================
4.1 Added "PMTA PAUSE JOB JOBID"
=====================================================
The command PMTA PAUSE now supports the ability to pause a job. It may become
necessary during the course of a mailing to pause the job. Instances of when
this would be needed might be to make sure the injected job was setup
correctly, or that it is using the correct VirtualMTAs. The command would look
similar to the following:
pmta pause job Campaign1234
job paused.
=====================================================
4.2 Added "PMTA RESUME JOB JOBID"
=====================================================
After a job has been paused, it may be required to resume the job. This is
done with the following command:
pmta resume job Campaign1234
job resumed.
=====================================================
4.3 Updated pmta show queues/topqueues/queue output
=====================================================
The pmta show queues/topqueues/queue commands have been updated to include the
last 50 recipient events including deliveries, bounces, and transient errors
(listed as deferred). The command would be something similar to:
pmta show queues
With the output of the command looking similar to:
queue
#rcpt kbytes conn st
retry last error
--------------- ----- ------ ---- -- -------- ----------

example.com/vmta10

0.1

15:37:07

Recipient Events (deliveries:2, bounces:1, deferred:1)

------------------------------------------------------delivered | 2015-05-07 15:35:07 | 10.25.25.235 | jsmith@example.com | jobid1 |
[192.168.0.48] (x.x.x.x) | smtp;250 DATA ok
bounced | 2015-05-07 15:35:07 | 10.25.25.235 | jdoe@example.com | | [192.16
8.0.48] (x.x.x.x) | smtp;550 5.0.0 (undefined status);smtp;554 5.7.1 This messag
e has been blocked
delivered | 2015-05-07 15:32:07 | 10.25.25.235 | example@example.com | jobid1
| [192.168.0.48] (x.x.x.x) | smtp;250 DATA ok
deferred | 2015-05-07 15:23:28 | 10.25.25.235 | ec@example.com | jobid8 | [19
2.168.0.48] (x.x.x.x) | smtp;450 4.0.0 (undefined status);smtp;451 Tempfail (bad
rep), try again later
This feature is enabled in the command output by default. To turn off the
listing of the events in the command output, use the --no-rcpt-events switch.
=====================================================
4.4 Added --no-rcpt-events switch for pmta show queues/topqueues/queue commands
=====================================================
Turns off showing the last 50 recipient events to prevent unwanted data from
being returned. This may be useful if parsing the output of the command via
an automated script.
pmta show queues --no-rcpt-events
=====================================================
4.5 Added --retry-recipients option in trace command
=====================================================
This switch forces PowerMTA to attempt to deliver any messages in a given
queue for which the trace command is being run. This may be useful if the
queue seems to be in a stuck state and a user wants to force trying of those
recipients while seeing debugging information.
pmta trace --retry-recipients example.com/vmta1
=====================================================
4.6 Added --retry-recipients option in schedule command
=====================================================
If this switch is used when running the pmta schedule command, it forces
PowerMTA to not only schedule the queue for immediate delivery, but also cause
all the recipients of the queue that are in Await Retry bucket to become
available for retry immediately.
pmta schedule --retry-recipients example.com/vmta
=====================================================
4.7 Added --priority switch in pmta list command
=====================================================
Use of the --priority switch not only shows the individual recipients in the
queue, but also shows the priority for the given recipient. This can be
useful if needing to verify priorities for individual recipients.
pmta list --queue=example.com/vmta1 --priority
=====================================================
4.8 Added show precached
=====================================================
The new command "pmta show precache" shows the domains that are currently in

the precached for quick DNS retrieval.

pmta show precache
=====================================================
4.9 Added --older-than option to delete command
=====================================================
The command option --older-than deletes all the recipients in the given queue
that are older than the given from the current time. The syntax for the time
interval is same as the syntax used to specify bounce-after in the
configuration file.
pmta delete --queue=foo.com --older-than=1d
Note that using zero implies a check for recipients older than the current
time, which would mean all the recipients in the queue should bounce.
pmta delete --queue=foo.com --older-than=0
=====================================================
4.10 Enabled TLS trace by default in "pmta resolve --connect" command
=====================================================
If the remote mail server advertises support for STARTTLS, PowerMTA will now
switch to using that method to connect as soon as it is discovered when using
the pmta resolve --connect command.
pmta resolve --connect port25.com
Querying 8.8.8.8 over UDP about MX port25.com
Read response from 8.8.8.8
answers:
ttl=3600
port25.com. 3600 IN MX 100 mail.port25.com.
additionals:
mail.port25.com. 3600 IN A 69.63.149.30
mail.port25.com. 3600 IN AAAA 2002:453f:951e::1
dns.port25.com. 3600 IN A 69.63.149.30
dns2.port25.com. 3600 IN A 96.244.219.19
status = StatusOk
pref host name
IP addresses
---- --------------- -----------100 mail.port25.com 69.63.149.30
connecting from localhost (0.0.0.0) to mail.port25.com (69.63.149.30)
connected from 192.168.0.150:34625
>>> 220 mail.port25.com ESMTP service ready
<<< EHLO localhost
>>> 250-mail.port25.com says hello
>>> 250-STARTTLS
>>> 250-ENHANCEDSTATUSCODES
>>> 250-PIPELINING
>>> 250-CHUNKING
>>> 250-8BITMIME
>>> 250-XACK
>>> 250-XMRG
>>> 250-SIZE 54525952
>>> 250-VERP
>>> 250 DSN
<<< STARTTLS
>>> 220 2.0.0 ready to start TLS
TLSv1.2 connected with 256-bit DHE-RSA-AES256-GCM-SHA384

Cert: /C=US/ST=MD/L=Ellicott City/O=Port25 Solutions, Inc./CN=mail.port25.com; i

ssuer=/C=US/ST=MD/L=Ellicott City/O=Port25 Solutions, Inc./CN=mail.port25.com; v
erified=no
<<< EHLO localhost
>>> 250-mail.port25.com says hello
>>> 250-ENHANCEDSTATUSCODES
>>> 250-PIPELINING
>>> 250-CHUNKING
>>> 250-8BITMIME
>>> 250-AUTH CRAM-MD5 PLAIN LOGIN
>>> 250-AUTH=CRAM-MD5 PLAIN LOGIN
>>> 250-XACK
>>> 250-XMRG
>>> 250-SIZE 54525952
>>> 250-VERP
>>> 250 DSN
<<< QUIT
>>> 221 2.0.0 mail.port25.com says goodbye
closed mail.port25.com (69.63.149.30) in=505 out=48
=====================================================
4.11 Added "max-smtp-msg-rate" and "max-smtp-out" to "show settings" output
=====================================================
Added virtual MTA's "max-smtp-msg-rate" and "max-smtp-out" to "show settings"
command output, as well as to the settings displayed in a queue's detail in
the web monitor, since these are often needed to understand queue behavior.
pmta show settings yahoo.com/vmta1
Virtual MTA Settings
-------------------max-smtp-msg-rate unlimited
max-smtp-out unlimited
Queue Settings
-------------type smtp
...
=====================================================
4.12 Added "rcvSmtpUser" to pmtastats and pmtaacctfind
=====================================================
Added "rcvSmtpUser" to pmtastats and pmtaacctfind to facilitate reporting on
the field. Field is a global option taking the value of the user being queried.
=====================================================
4.13 Added "PMTA SET PRIORITY"
=====================================================
PowerMTA now allows setting the priority of a queue or recipient at the
command line. This can be useful if it is found that a given message or
group of messages needs to have a higher or lower priority. The priority
would be set similar to the following:
pmta set priority --rcpt=ceo@example.com 100
pmta set priority --queue=yahoo.com/vmta1 100
********************************************************************************
5. New Directives and directive enhancements
********************************************************************************
=====================================================

5.1 VirtualMTA Pool Directives

=====================================================
<domain> directives are now allowed to be defined in a <virtual-mta-pool>,
which will then be inherited by all VirtualMTAs in the pool. <domain> settings
in the individual <virtual-mta> will override those in defined in the
<virtual-mta-pool>. Also, "cold-virtual-mta", "domain-key", "max-smtp-out",
"max-smtp-msg-rate", and "include-headers-from" are allowed. The directives
are interpreted as an additional inheritance layer between global and the
VirtualMTA and applied to all VirtualMTAs in the pool. It is an error to
specify the same directive in more than one pool to which a VirtualMTA
belongs. Specifying "cold-virtual-mta", "domain-key" and
"include-headers-from" thus inserts items between any per-vmta and global
items, whereas specifying "max-smtp-out" and "max-smtp-msg-rate" provide
defaults for those per-vmta settings.
=====================================================
5.2 Domain Directives
=====================================================
"backoff-max-smtp-out"
Specifies the maximum number of simultaneous connections PowerMTA will make
for this domain/virtualMTA while the queue is in backoff mode. The actual
number of connections opened is determined by PowerMTA depending on a
variety of parameters, including the number of recipients in the queue for
this domain compared to the total number of recipients in the queue. Note
that depending on the SMTP error received back, PowerMTA may not immediately
break all active outbound connections to the domain that returned the error,
so that there may be a short period of time that while the queue is listed
in backoff mode, there are more active connections than what is configured
in this directive. Once these connections break however, more will not be
opened by PowerMTA in order to adhere to the configured limit.
"disable-acct-records (d,b,t,tq) 'r' records cannot (yet) be disabled"
Allows one to disable the creation of one or more than one type of
accounting file record on a per queue (domain / virtualMTA) basis. For
example, there are times when a user wants PowerMTA to discard certain
messages without creating an accounting file record for these messages when
discarded. By default, PowerMTA would create a "d" (delivered ) record for
this, since it was delivered to discard, however the creation of a delivered
record can be disabled with this option.
"retry-after"
Specifies the retry interval or intervals for the domain/virtualMTA once the
domain/virtualMTA is put in retry mode. The directive is a time interval(s),
takes a single interval or comma separated list of intervals, with each
having a number along with "d" for days, "h" for hours, "m" for minutes,
or "s" for seconds, with no spaces between the parameters.
"backoff-retry-after"
Specifies the retry interval or intervals for the domain/virtualMTA once it
is put in retry mode, when the queue is in backoff mode. The directive is a
time interval(s), takes a single interval or comma separated list of
intervals, with each having a number along with "d" for days, "h" for hours,
"m" for minutes, or "s" for seconds, with no spaces between the parameters.
"bounce-upon-no-mx"
When set to yes, it specifies that PowerMTA should immediately bounce all
messages for a domain that has no MX records in their DNS. When a time
interval is defined instead, for example, 30m, it defines the time interval
to bounce messages from the queue if the last DNS query resulted in no MX
records being returned. Defining a time interval allows for more tolerance

in dealing with domains that do not have MX records, since some sites still
accept email on their A records. Note that this applies only to cases where
a MX lookup is performed. It does not include cases where an IP list is
specified in the "route" directive (unless it contains only a domain name,
in which case a MX lookup is performed on the domain).
"smtp-tls-allow-tlsv1.1"
Controls whether TLSv1.1 protocol is allowed. Defaults
to true
"smtp-tls-allow-tlsv1.2"
Controls whether TLSv1.2 protocol is allowed. Defaults
to true
"bcc-upon-delivery"
Automatically BCC emails delivered to specific domains with the given address.
A null string with "" may be used to override an inherited setting.
"max-cold-virtual-mta-msg"
Added support for specifying cold Virtual MTA warm-up progressions in
"max-cold-virtual-mta-msg" as comma-separated lists of daily limits.
<domain yahoo.com>
max-cold-virtual-mta-msg 1/day,2/day,3/day,4/day
</domain>
In the example above, all cold vmtas will have 1 as their first day's limit
for yahoo.com, 2 as the limit for second day to yahoo.com and so on. There
is no restriction on the number of per-day limits that can be configured.
The last limit value will continue to be used as the per-day limit after all
the preceding limits have been used.
"replace-smtp-421-service-response"
When enabled, this replaces the SMTP response after the 421 code and after
any enhanced status code with "service unavailable", thus preventing any
email addresses, etc. that may be included in that response from being used
in bounces. The original message is still passed in for pattern matching, so
that these continue to work normally. Defaults to false.
"source-ip-max-msg-rate"
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. 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.
"source-ip-max-connect-rate"
Specifies the maximum number of connections to be opened for this domain
during the specified time period per IP per domain/vmta.
=====================================================
5.3 Source Directives
=====================================================
"smtp-data-timeout"
Specifies the amount of time that PowerMTA will wait for data from the
remote end during data reception phase (after DATA/BDAT command) of the
message. Applies to inbound connections only.
"smtp-command-timeout"
Specifies the amount of time that PowerMTA will wait for data to be sent
from a remote end during inbound SMTP command exchanges.

"check-iprev-inbound"
Determines if PowerMTA performs and inbound DNS PTR check on the IP and EHLO
hostname used for the connection.
"trace-iprev-check"
If enabled, preforms a DNS resolution trace of the lookup for debugging
purposes
"reject-iprev-check-temperror"
If the DNS PTR check returns a temp error, instructs PowerMTA to reject or
accept the message
"reject-iprev-check-permerror"
If the DNS PTR check returns a permanent error, instructs PowerMTA to reject
or accept the message
"reject-iprev-check-fail"
If the DNS PTR check returns a failure, instructs PowerMTA to reject or
accept the message
"process-x-schedule"
Specifies whether PowerMTA should process the x-schedule header if included
in the message. If set to true and one such header is included, PowerMTA
will respect the schedule defined in the header, and only attempt to deliver
messages per the schedule. If set to false, PowerMTA will ignore this
header and attempt to deliver normally, without any time based schedule.
"retain-x-schedule"
Specifies whether PowerMTA should leave the x-schedule header in the message
when messages are delivered (when using PowerMTA's Schedule Delivery Control
feature). While this option is generally used in conjunction with the
process x-schedule header option, they are completely independent of each
other. Both can be set to false for example, which has PowerMTA ignoring
the header with regards to processing however still removing the header
before delivery.
"retain-x-dkim-options"
Specifies whether PowerMTA should retain the x-dkim-options header when
sending a message to a remote mail server.
=====================================================
5.4 DNS Directives
=====================================================
"precached-domains-file"
Specifies the name of a text file containing a list of domains, one domain
per line, that you want PowerMTA to always have current DNS information for
in its DNS cache, regardless of whether recipients are in the queue for the
domain or not. Typically PowerMTA would look up domain routing information
in DNS when recipients are submitted into PowerMTA for a domain (assuming
recipients are not currently queued for the domain already). Depending on
the DNS infrastructure and how many other domains are in the queue, this may
cause some slight delay in the immediate delivery attempts for these
recipients. Having DNS routing information precached in PowerMTA for
certain key domains before submission minimizes any delay that may take
place due to this required DNS resolution.
"precached-refresh-interval"
Defines the time frame in which the DNS records for all pre-cached domains
are refreshed (looked back up in DNS). Similar to a DNS record's TTL (time

to live), however it manually sets the time interval to refresh, and which
overrides the actual records' TTL in DNS. The regular TTL records for
pre-cached domains are ignored.
"precached-max-domains"
Specifies the maximum number of domains that can be pre-cached. This number
cannot exceed the number of domains defined in the "precached-domains-file".
Defining a very large number will result in lots of frequent DNS queries, so
a scalable DNS infrastructure is required.
=====================================================
5.5 Global Directives
=====================================================
"ip-connection-limit"
The directive is only permitted in global scope. The syntax for the directive
is similar to mx-connection-limit directive, except that it is uses IP
addresses/CIDR notation.For example, "ip-connection-limit 10.0.0.0/8 5". Any
remote IP addresses(the A records for the remote MX) which map to 10.0.0.0/8
subnet will be subject to the limit of 5 simultaneous connections at any point
in time.
=====================================================
5.6 Other Directives
=====================================================
"<address-list>"
<address-list> (such as those used to specify which addresses to check for
FBL and bounce processing, or for suppression lists) now support exact email
addresses, when specified with 'address' without the "//" regular expression
syntax.
"address-file"
extended address lists with new "address-file" directive, which includes into
the list all addresses in the file, one per line.
"<alias>"
Added support for '*@domain' syntax to email aliases, allowing all email for
a certain domain to be forwarded.
********************************************************************************
6. Other enhancements
********************************************************************************
=====================================================
6.1 Acctfind to allow separating the header and arf tag or arf field name
=====================================================
Extended acctfind to to allow separating the header and arf tag or arf field
name with '-' in addition to ':', to avoid common typos as this is the syntax
used in accounting files.
=====================================================
6.2 Updated delivery behavior for transient errors on multiple MXs
=====================================================
Modified delivery strategy to no longer attempt all recipients that receive a
transient response on all MXes before returning them to the queue. This
should yield faster delivery rates, as it avoids wasting time on attempts
that are likely to fail.
=====================================================
6.3 Fixed <source> require-auth not being observed
=====================================================
Fixed <source> require-auth not being observed if the authentication fails

because a configuration named for the user doesn't exist (after the
credentials were successfuly verified).
=====================================================
6.4 Modified backoff-... directives that specify a limit
=====================================================
Modified backoff-... directives that specify a limit to default to their
non-backoff equivalents value (i.e., unless set or inherited), so that a
queue doesn't accidentally behave more aggressively in backoff mode.