Documentation: updated nqgmr preemptive scheduler documentation
by Patrik Rak. File: proto/SCHEDULER_README.html.
+
+20071211
+
+ Bugfix: memory leak when the first write on a bi-directional
+ VSTREAM fails. File: util/vstream.c.
+
+20071212
+
+ Feature: "stress=" or "stress=yes" attribute in the SMTPD
+ policy delegation protocol. File: smtp/smtpd_check.c.
+
+ Cleanup: allow_min_user now rejects recipients (and senders)
+ starting with '-' at SMTP session time. To make this possible
+ the feature was moved from qmgr(8) to trivial-rewrite(8).
+ Files: *qmgr/qmgr_message.c, trivial-rewrite/resolve.c.
P\bPr\bre\bee\bem\bmp\bpt\bti\biv\bve\be s\bsc\bch\bhe\bed\bdu\bul\bli\bin\bng\bg
-This document attempts to describe the new queue manager and its preeemptive
+This document attempts to describe the new queue manager and its preemptive
scheduler algorithm. Note that the document was originally written to describe
the changes between the new queue manager (in this text referred to as nqmgr,
the name it was known by before it became the default queue manager) and the
queue entry list and the peer entry list. The addresses for same nexthop are
batched in the entries up to recipient_concurrency limit for that transport.
This happens in qmgr_assign() and apart from that it operates with job and peer
-structures is basically the same as in oqmgr.
+structures it is basically the same as in oqmgr.
When the job is instantiated, it is enqueued on the transport's job list based
on the time its message was picked up by nqmgr. For first batch of recipients
enqueue time and is used for recipient pool management we will discuss later.
For now, we will deal with the scheduler's job list only.
-So, we have the job list, which is first ordered by the time the job's messages
+So, we have the job list, which is first ordered by the time the jobs' messages
were enqueued, oldest messages first, the most recently picked one at the end.
For now, let's assume that there are no destination concurrency problems.
Without preemption, we pick some entry of the first (oldest) job on the queue,
that first job by some constant for free - it is basically the same trick you
might remember as "accumulation of potential" from the amortized complexity
lessons. For example, instead of delivering the entries of the first job on the
-job list every time an delivery agent becomes available, we can do it only
-every second time. If you view the moments the delivery agent becomes available
-on a timeline as "delivery slots", then instead of using every delivery slot
-for the first job, we can use only every other slot, and still the overall
-delivery efficiency of the first job remains the same. So the delivery 11112222
-becomes 1.1.1.1.2.2.2.2 (1 and 2 are the imaginary job numbers, . denotes the
-free slot). Now what do we do with free slots?
+job list every time a delivery agent becomes available, we can do it only every
+second time. If you view the moments the delivery agent becomes available on a
+timeline as "delivery slots", then instead of using every delivery slot for the
+first job, we can use only every other slot, and still the overall delivery
+efficiency of the first job remains the same. So the delivery 11112222 becomes
+1.1.1.1.2.2.2.2 (1 and 2 are the imaginary job numbers, . denotes the free
+slot). Now what do we do with free slots?
As you might have guessed, we will use them for sneaking the mail with little
recipients in. For example, if we have one four-recipient mail followed by four
slip by, not even if it had just only one recipients. It will be stuck until
the hundred-recipient mail is delivered, which really sucks.
-So, it becomes obvious that while the inflating the message to get free slots
-is great idea, one has to be really careful of how the free slots are assigned,
+So, it becomes obvious that while inflating the message to get free slots is
+great idea, one has to be really careful of how the free slots are assigned,
otherwise one might corner himself. So, how does nqmgr really use the free
slots?
The key idea is that one does not have to generate the free slots in a uniform
way. The delivery sequence 111...1 is no worse than 1.1.1.1, in fact, it is
even better as some entries are in the first case selected earlier than in the
-second case, and none is selected later! So it is possible to first to
+second case, and none is selected later! So it is possible to first
"accumulate" the free delivery slots and then use them all at once. It is even
possible to accumulate some, then use them, then accumulate some more and use
them again, as in 11..1.1 .
first accumulate one hundred free slots, and only after then to preempt the
first job and sneak the one hundred recipient mail in. Applying the algorithm
recursively, we see the hundred recipient job can accumulate ten free delivery
-slots, and then we could preempt it and sneak in the ten recipient mail... Wait
+slots, and then we could preempt it and sneak in the ten-recipient mail... Wait
wait wait! Could we? Aren't we overinflating the original one thousand
recipient mail?
already used some when it was preempted before (remember a job can be preempted
several times). In either case, we know how many are accumulated and how many
are left to deliver, so we know how many it may yet accumulate at maximum.
-Every other job which may be delivered by less than that amount of slots is an
+Every other job which may be delivered by less than that amount of slots is a
valid candidate for preemption. How do we choose among them?
The answer is - the one with maximum enqueue_time/recipient_entry_count. That
that's not the complete truth.
The truth is that it turns out that it is not really necessary to wait until
-the jobs counter accumulates all the delivery slots in advance. Say we have ten
-recipient mail followed by two two-recipient mails. If the preemption happened
-when enough delivery slot accumulate (assuming slot cost 2), the delivery
-sequence becomes 11112211113311. Now what would we get if we would wait only
-for 50% of the necessary slots to accumulate and we promise we would wait for
-the remaining 50% later, after the we get back to the preempted job? If we use
-such slot loan, the delivery sequence becomes 11221111331111. As we can see, it
-makes it no considerably worse for the delivery of the ten-recipient mail, but
-it allows the small messages to be delivered sooner.
+the jobs counter accumulates all the delivery slots in advance. Say we have
+ten-recipient mail followed by two two-recipient mails. If the preemption
+happened when enough delivery slot accumulate (assuming slot cost 2), the
+delivery sequence becomes 11112211113311. Now what would we get if we would
+wait only for 50% of the necessary slots to accumulate and we promise we would
+wait for the remaining 50% later, after we get back to the preempted job? If we
+use such slot loan, the delivery sequence becomes 11221111331111. As we can
+see, it makes it no considerably worse for the delivery of the ten-recipient
+mail, but it allows the small messages to be delivered sooner.
The concept of these slot loans is where the transport_delivery_slot_discount
and transport_delivery_slot_loan come from (they default to
preemption happening at its head, in ideal delivery conditions. The feeling of
understanding shall last until you start wondering what happens if some of the
jobs are blocked, which you might eventually figure out correctly from what had
-been said already. But I would be surprised if you mental image of the
-scheduler's functionality it is not completely shattered once you start
-wondering how it works when not all recipients may be read in-core. More on
-that later.]
+been said already. But I would be surprised if your mental image of the
+scheduler's functionality is not completely shattered once you start wondering
+how it works when not all recipients may be read in-core. More on that later.]
H\bHo\bow\bw d\bde\bes\bst\bti\bin\bna\bat\bti\bio\bon\bn c\bco\bon\bnc\bcu\bur\brr\bre\ben\bnc\bcy\by l\bli\bim\bmi\bit\bts\bs a\baf\bff\bfe\bec\bct\bt t\bth\bhe\be s\bsc\bch\bhe\bed\bdu\bul\bli\bin\bng\bg a\bal\blg\bgo\bor\bri\bit\bth\bhm\bm
destination successfully finishes), the job's blocker status is removed and the
job again participates in all further scheduler actions normally.
-So the summary is that the user's don't really have to be concerned about the
+So the summary is that the users don't really have to be concerned about the
interaction of the destination limits and scheduling algorithm. It works well
on its own and there are no knobs they would need to control it.
2. The idea of the preemption stack at the head of the job list is gone. That
is, it must be possible to preempt any job on the job list. For example, if
the jobs 7, 4, 1 and 2 in the example above become all blocked, job 3
- becomes the current job. And of course we do not want the preemption be
+ becomes the current job. And of course we do not want the preemption to be
affected by the fact that there are some blocked jobs or not. Therefore, if
it turns out that job 3 might be preempted by job 6, the implementation
shall make it possible.
code must support reading the recipients in batches, which among other things
means accessing the queue file several times and continuing where the last
recipient batch ended. This is invoked by the scheduler whenever the current
-job runs out of in-core recipients and more are required. It is also done any
-time when all in-core recipients of the message are dealt with (which may also
-mean they were deferred) but there are still more in the queue file.
+job has space for more recipients, subject to transport's refill_limit and
+refill_delay parameters. It is also done any time when all in-core recipients
+of the message are dealt with (which may also mean they were deferred) but
+there are still more in the queue file.
The second complication is that with some recipients left unread in the queue
file, the scheduler can't operate with exact counts of recipient entries. With
qmgr_message_recipient_minimum and qmgr_message_recipient_limit values control.
The qmgr_message_recipient_minimum value specifies how many recipients of each
message we will read for the first time, no matter what. It is necessary to
-read at least one recipients before we can assign the message to a transport
-and create the first job. However, reading only qmgr_message_recipient_minimum
-recipients even if there are only few messages with few messages in-core would
-be wasteful. Therefore if there is less than qmgr_message_recipient_limit
+read at least one recipient before we can assign the message to a transport and
+create the first job. However, reading only qmgr_message_recipient_minimum
+recipients even if there are only few messages with few recipients in-core
+would be wasteful. Therefore if there is less than qmgr_message_recipient_limit
recipients in-core so far, the first batch of recipients may be larger than
qmgr_message_recipient_minimum - as large as is required to reach the
qmgr_message_recipient_limit limit.
Once the first batch of recipients was read in core and the message jobs were
created, the size of the subsequent recipient batches (if any - of course it's
best when all recipients are read in one batch) is based solely on the position
-of the message jobs on their corresponding transport's job lists. Each
+of the message jobs on their corresponding transports' job lists. Each
transport has a pool of transport_recipient_limit recipient slots which it can
distribute among its jobs (how this is done is described later). The subsequent
recipient batch may be as large as the sum of all recipient slots of all jobs
Things work fine in such state for most of the time, because the current job is
either completely read in-core or has as much recipient slots as there are, but
-there is one situation which we still have to take care specially. Imagine if
-the current job is preempted by some unread job from the job list and there are
-no more recipient slots available, so this new current job could read only
+there is one situation which we still have to take care of specially. Imagine
+if the current job is preempted by some unread job from the job list and there
+are no more recipient slots available, so this new current job could read only
batches of qmgr_message_recipient_minimum recipients at a time. This would
really degrade performance. For this reason, each transport has extra pool of
transport_extra_recipient_limit recipient slots, dedicated exactly for this
And that's it. It sure does sound pretty complicated, but fortunately most
people don't really have to care how exactly it works as long as it works.
-Perhaps the only important things to know for most people ire the following
+Perhaps the only important things to know for most people are the following
upper bound formulas:
Each transport has at maximum
encryption_cipher=DHE-RSA-AES256-SHA
encryption_keysize=256
etrn_domain=
+ P\bPo\bos\bst\btf\bfi\bix\bx v\bve\ber\brs\bsi\bio\bon\bn 2\b2.\b.5\b5 a\ban\bnd\bd l\bla\bat\bte\ber\br:\b:
+ stress=
[empty line]
Notes:
* The "etrn_domain" attribute is defined only in the context of the ETRN
command, and specifies the ETRN command parameter.
+ * The "stress" attribute is either empty or "yes". See the STRESS_README
+ document for further information.
+
The following is specific to SMTPD delegated policy requests:
* Protocol names are ESMTP or SMTP.
command-line option in master.cf. This can be useful for testing overrides on
the SMTP service. Issue "postfix reload" to make the change effective.
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
+
1 /etc/postfix/master.cf:
2 # =============================================================
3 # service type private unpriv chroot wakeup maxproc command
8 -o . . .
To permanently force stress-adaptive behavior off with a specific service,
-specify "-o stress=" on its command line. This may be desirable for the
-"submission" service. Issue "postfix reload" to make the change effective.
+specify "-o stress=" on its master.cf command line. This may be desirable for
+the "submission" service. Issue "postfix reload" to make the change effective.
+
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
1 /etc/postfix/master.cf:
2 # =============================================================
* Discovering servers that support TLS
* Server certificate verification depth
* Client-side cipher controls
+ * Client-side SMTPS support
* Miscellaneous client controls
T\bTL\bLS\bS s\bsu\bup\bpp\bpo\bor\brt\bt i\bin\bn t\bth\bhe\be L\bLM\bMT\bTP\bP d\bde\bel\bli\biv\bve\ber\bry\by a\bag\bge\ben\bnt\bt
smtp_tls_mandatory_exclude_ciphers = RC4, MD5
smtp_tls_exclude_ciphers = aNULL
+C\bCl\bli\bie\ben\bnt\bt-\b-s\bsi\bid\bde\be S\bSM\bMT\bTP\bPS\bS s\bsu\bup\bpp\bpo\bor\brt\bt
+
+Although the Postfix SMTP client by itself doesn't support TLS wrapper mode, it
+is relatively easy to forward a connection through the stunnel program if
+Postfix needs to deliver mail to some legacy system that doesn't support
+STARTTLS. Use one of the following two examples, to send only some remote mail,
+or to send all remote mail, to an SMTPS server.
+
+S\bSe\ben\bnd\bdi\bin\bng\bg a\bal\bll\bl r\bre\bem\bmo\bot\bte\be m\bma\bai\bil\bl t\bto\bo a\ban\bn S\bSM\bMT\bTP\bPS\bS s\bse\ber\brv\bve\ber\br
+
+The first example uses SMTPS to send all remote mail to a provider's mail
+server called "mail.example.com".
+
+A minimal stunnel.conf file is sufficient to set up a tunnel from local port
+11125 to the remote destination "mail.example.com" and port "smtps". Postfix
+will later use this tunnel to connect to the remote server.
+
+ /path/to/stunnel.conf:
+ [smtp-tls-wrapper]
+ accept = 11125
+ client = yes
+ connect = mail.example.com:smtps
+
+To test this tunnel, use:
+
+ $ telnet localhost 11125
+
+This should produce the greeting from the remote SMTP server at
+mail.example.com.
+
+On the Postfix side, the relayhost feature sends all remote mail through the
+local stunnel listener on port 11125:
+
+ /etc/postfix/main.cf:
+ relayhost = [127.0.0.1]:11125
+
+Use "postfix reload" to make the change effective.
+
+S\bSe\ben\bnd\bdi\bin\bng\bg o\bon\bnl\bly\by m\bma\bai\bil\bl f\bfo\bor\br a\ba s\bsp\bpe\bec\bci\bif\bfi\bic\bc d\bde\bes\bst\bti\bin\bna\bat\bti\bio\bon\bn v\bvi\bia\ba S\bSM\bMT\bTP\bPS\bS
+
+The second example will use SMTPS to send only mail for "example.com" via
+SMTPS. It uses the same stunnel configuration file as the first example, so it
+won't be repeated here.
+
+This time, the Postfix side uses a transport map to direct only mail for
+"example.com" through the tunnel:
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ /etc/postfix/transport:
+ example.com relay:[127.0.0.1]:11125
+
+Use "postmap hash:/etc/postfix/transport" and "postfix reload" to make the
+change effective.
+
M\bMi\bis\bsc\bce\bel\bll\bla\ban\bne\beo\bou\bus\bs c\bcl\bli\bie\ben\bnt\bt c\bco\bon\bnt\btr\bro\bol\bls\bs
The smtp_starttls_timeout parameter limits the time of Postfix SMTP client
P\bPu\bur\brp\bpo\bos\bse\be o\bof\bf t\bth\bhe\be X\bXC\bCL\bLI\bIE\bEN\bNT\bT e\bex\bxt\bte\ben\bns\bsi\bio\bon\bn t\bto\bo S\bSM\bMT\bTP\bP
-The XCLIENT command targets the following problems:
+When an SMTP server announces support for the XCLIENT command, an SMTP client
+may send information that overrides one or more client-related session
+attributes. The XCLIENT command targets the following problems:
1. Access control tests. SMTP server access rules are difficult to verify when
decisions can be triggered only by remote clients. In order to facilitate
P\bPu\bur\brp\bpo\bos\bse\be o\bof\bf t\bth\bhe\be X\bXF\bFO\bOR\bRW\bWA\bAR\bRD\bD e\bex\bxt\bte\ben\bns\bsi\bio\bon\bn t\bto\bo S\bSM\bMT\bTP\bP
-The XFORWARD command targets the following problem:
+When an SMTP server announces support for the XFORWARD command, an SMTP client
+may send information that overrides one or more client-related logging
+attributes. The XFORWARD command targets the following problem:
* Logging after SMTP-based content filter. With the deployment of Internet-
>MTA1->filter->MTA2 style content filter applications, the logging of
If you upgrade from Postfix 2.3 or earlier, read RELEASE_NOTES-2.4
before proceeding.
+Incompatibility with Postfix snapshot 20071212
+==============================================
+
+The allow_min_user feature now applies to both sender and recipient
+addresses in SMTP commands. With earlier Postfix versions, only
+recipients were subject to the allow_min_user feature, and the
+restriction took effect at mail delivery time, causing mail to be
+bounced later instead of being rejected immediately.
+
Incompatibility with Postfix snapshot 20071206
==============================================
After success:
fail_cohorts = 0
- Be prepared for feedback > hysteresis, or rounding error
+ Be prepared for feedback > hysteresis, or rounding error
success += g(concurrency)
while (success >= 1) Hysteresis 1
concurrency += 1 Hysteresis 1
failure = 0
success -= 1 Hysteresis 1
Be prepared for overshoot
- if (concurrency > concurrency limit)
+ if (concurrency > concurrency limit)
concurrency = concurrency limit
Safety:
Don't apply positive feedback unless
- concurrency < busy_refcount + init_dest_concurrency
+ concurrency < busy_refcount + init_dest_concurrency
otherwise negative feedback effect could be delayed
After failure:
- if (concurrency > 0)
+ if (concurrency > 0)
fail_cohorts += 1.0 / concurrency
- if (fail_cohorts > cohort_failure_limit)
+ if (fail_cohorts > cohort_failure_limit)
concurrency = 0
- if (concurrency > 0)
- Be prepared for feedback > hysteresis, rounding errors
+ if (concurrency > 0)
+ Be prepared for feedback > hysteresis, rounding errors
failure -= f(concurrency)
- while (failure < 0)
+ while (failure < 0)
concurrency -= 1 Hysteresis 1
failure += 1 Hysteresis 1
success = 0
Be prepared for overshoot
- if (concurrency < 1)
+ if (concurrency < 1)
concurrency = 1
</pre>
<p>
This document attempts to describe the new queue manager and its
-preeemptive scheduler algorithm. Note that the document was originally
+preemptive scheduler algorithm. Note that the document was originally
written to describe the changes between the new queue manager (in
this text referred to as <tt>nqmgr</tt>, the name it was known by
before it became the default queue manager) and the old queue manager
to both the queue entry list and the peer entry list. The addresses
for same nexthop are batched in the entries up to recipient_concurrency
limit for that transport. This happens in qmgr_assign() and apart
-from that it operates with job and peer structures is basically the
+from that it operates with job and peer structures it is basically the
same as in <tt>oqmgr</tt>.
</p>
foreach transport's job (in the order of the transport's job list)
do
foreach job's peer (round-robin-by-destination)
- if peer->queue->concurrency < peer->queue->window
+ if peer->queue->concurrency < peer->queue->window
return next peer entry.
done
done
<p>
So, we have the job list, which is first ordered by the time the
-job's messages were enqueued, oldest messages first, the most recently
+jobs' messages were enqueued, oldest messages first, the most recently
picked one at the end. For now, let's assume that there are no
destination concurrency problems. Without preemption, we pick some
entry of the first (oldest) job on the queue, assign it to delivery
is basically the same trick you might remember as "accumulation of
potential" from the amortized complexity lessons. For example,
instead of delivering the entries of the first job on the job list
-every time an delivery agent becomes available, we can do it only
+every time a delivery agent becomes available, we can do it only
every second time. If you view the moments the delivery agent becomes
available on a timeline as "delivery slots", then instead of using
every delivery slot for the first job, we can use only every other
<p>
-So, it becomes obvious that while the inflating the message to get
+So, it becomes obvious that while inflating the message to get
free slots is great idea, one has to be really careful of how the
free slots are assigned, otherwise one might corner himself. So,
how does <tt>nqmgr</tt> really use the free slots?
in a uniform way. The delivery sequence <tt>111...1</tt> is no
worse than <tt>1.1.1.1</tt>, in fact, it is even better as some
entries are in the first case selected earlier than in the second
-case, and none is selected later! So it is possible to first to
+case, and none is selected later! So it is possible to first
"accumulate" the free delivery slots and then use them all at once.
It is even possible to accumulate some, then use them, then accumulate
some more and use them again, as in <tt>11..1.1</tt> .
after then to preempt the first job and sneak the one hundred
recipient mail in. Applying the algorithm recursively, we see the
hundred recipient job can accumulate ten free delivery slots, and
-then we could preempt it and sneak in the ten recipient mail...
+then we could preempt it and sneak in the ten-recipient mail...
Wait wait wait! Could we? Aren't we overinflating the original one
thousand recipient mail?
(remember a job can be preempted several times). In either case,
we know how many are accumulated and how many are left to deliver,
so we know how many it may yet accumulate at maximum. Every other
-job which may be delivered by less than that amount of slots is an
+job which may be delivered by less than that amount of slots is a
valid candidate for preemption. How do we choose among them?
</p>
The truth is that it turns out that it is not really necessary to
wait until the jobs counter accumulates all the delivery slots in
-advance. Say we have ten recipient mail followed by two two-recipient
+advance. Say we have ten-recipient mail followed by two two-recipient
mails. If the preemption happened when enough delivery slot accumulate
(assuming slot cost 2), the delivery sequence becomes
<tt>11112211113311</tt>. Now what would we get if we would wait
only for 50% of the necessary slots to accumulate and we promise
-we would wait for the remaining 50% later, after the we get back
+we would wait for the remaining 50% later, after we get back
to the preempted job? If we use such slot loan, the delivery sequence
becomes <tt>11221111331111</tt>. As we can see, it makes it no
considerably worse for the delivery of the ten-recipient mail, but
<p>
The concept of these slot loans is where the
-<a href="postconf.5.html#transport_delivery_slot_discount"><a href="postconf.5.html#transport_delivery_slot_discount"><i>transport</i>_delivery_slot_discount</a></a> and
+<a href="postconf.5.html#transport_delivery_slot_discount"><i>transport</i>_delivery_slot_discount</a> and
<a href="postconf.5.html#transport_delivery_slot_loan"><i>transport</i>_delivery_slot_loan</a> come from (they default to
<a href="postconf.5.html#default_delivery_slot_discount">default_delivery_slot_discount</a> and <a href="postconf.5.html#default_delivery_slot_loan">default_delivery_slot_loan</a>, whose
values are by default 50 and 3, respectively). The discount (resp.
delivery conditions. The feeling of understanding shall last until
you start wondering what happens if some of the jobs are blocked,
which you might eventually figure out correctly from what had been
-said already. But I would be surprised if you mental image of the
-scheduler's functionality it is not completely shattered once you
+said already. But I would be surprised if your mental image of the
+scheduler's functionality is not completely shattered once you
start wondering how it works when not all recipients may be read
in-core. More on that later.]
<p>
-So the summary is that the user's don't really have to be concerned
+So the summary is that the users don't really have to be concerned
about the interaction of the destination limits and scheduling
algorithm. It works well on its own and there are no knobs they
would need to control it.
<blockquote>
<pre>
-first job-> 1--2--3--5--6--8--... <- job list
+first job-> 1--2--3--5--6--8--... <- job list
on job list |
- 4 <- preemption stack
+ 4 <- preemption stack
|
-current job-> 7
+current job-> 7
</pre>
</blockquote>
gone. That is, it must be possible to preempt any job on the job
list. For example, if the jobs 7, 4, 1 and 2 in the example above
become all blocked, job 3 becomes the current job. And of course
-we do not want the preemption be affected by the fact that there
+we do not want the preemption to be affected by the fact that there
are some blocked jobs or not. Therefore, if it turns out that job
3 might be preempted by job 6, the implementation shall make it
possible.
<pre>
v- parent
-adoptive parent -> 1--2--3--5--... <- "stack" level 0
+adoptive parent -> 1--2--3--5--... <- "stack" level 0
| |
-parent gone -> ? 6 <- "stack" level 1
+parent gone -> ? 6 <- "stack" level 1
/ \
-children -> 7 8 ^- child <- "stack" level 2
+children -> 7 8 ^- child <- "stack" level 2
^- siblings
</pre>
<blockquote>
<pre>
-7--8--1--2--6--3--5--.. <- scheduler's job list order
+7--8--1--2--6--3--5--.. <- scheduler's job list order
</pre>
</blockquote>
message reading code must support reading the recipients in batches,
which among other things means accessing the queue file several
times and continuing where the last recipient batch ended. This is
-invoked by the scheduler whenever the current job runs out of in-core
-recipients and more are required. It is also done any time when all
+invoked by the scheduler whenever the current job has space for more
+recipients, subject to transport's refill_limit and refill_delay parameters.
+It is also done any time when all
in-core recipients of the message are dealt with (which may also
mean they were deferred) but there are still more in the queue file.
what <a href="postconf.5.html#qmgr_message_recipient_minimum">qmgr_message_recipient_minimum</a> and <a href="postconf.5.html#qmgr_message_recipient_limit">qmgr_message_recipient_limit</a>
values control. The <a href="postconf.5.html#qmgr_message_recipient_minimum">qmgr_message_recipient_minimum</a> value specifies
how many recipients of each message we will read for the first time,
-no matter what. It is necessary to read at least one recipients
+no matter what. It is necessary to read at least one recipient
before we can assign the message to a transport and create the first
job. However, reading only <a href="postconf.5.html#qmgr_message_recipient_minimum">qmgr_message_recipient_minimum</a> recipients
-even if there are only few messages with few messages in-core would
+even if there are only few messages with few recipients in-core would
be wasteful. Therefore if there is less than <a href="postconf.5.html#qmgr_message_recipient_limit">qmgr_message_recipient_limit</a>
recipients in-core so far, the first batch of recipients may be
larger than <a href="postconf.5.html#qmgr_message_recipient_minimum">qmgr_message_recipient_minimum</a> - as large as is required
jobs were created, the size of the subsequent recipient batches (if
any - of course it's best when all recipients are read in one batch)
is based solely on the position of the message jobs on their
-corresponding transport's job lists. Each transport has a pool of
+corresponding transports' job lists. Each transport has a pool of
<a href="postconf.5.html#transport_recipient_limit"><i>transport</i>_recipient_limit</a> recipient slots which it can
distribute among its jobs (how this is done is described later).
The subsequent recipient batch may be as large as the sum of all
Things work fine in such state for most of the time, because the
current job is either completely read in-core or has as much recipient
slots as there are, but there is one situation which we still have
-to take care specially. Imagine if the current job is preempted
+to take care of specially. Imagine if the current job is preempted
by some unread job from the job list and there are no more recipient
slots available, so this new current job could read only batches
of <a href="postconf.5.html#qmgr_message_recipient_minimum">qmgr_message_recipient_minimum</a> recipients at a time. This would
And that's it. It sure does sound pretty complicated, but fortunately
most people don't really have to care how exactly it works as long
as it works. Perhaps the only important things to know for most
-people ire the following upper bound formulas:
+people are the following upper bound formulas:
</p>
encryption_cipher=DHE-RSA-AES256-SHA
encryption_keysize=256
etrn_domain=
+<b>Postfix version 2.5 and later:</b>
+stress=
[empty line]
</pre>
</blockquote>
context of the ETRN command, and specifies the ETRN command
parameter. </p>
+ <li> <p> The "stress" attribute is either empty or "yes". See
+ the <a href="STRESS_README.html">STRESS_README</a> document for further information. </p>
+
</ul>
<p> The following is specific to SMTPD delegated policy requests:
useful for testing overrides on the SMTP service. Issue "postfix
reload" to make the change effective. </p>
+<p> Note: setting the stress parameter in <a href="postconf.5.html">main.cf</a> has no effect for
+services that accept remote connections. </p>
+
<blockquote>
<pre>
1 /etc/postfix/<a href="master.5.html">master.cf</a>:
</blockquote>
<p> To permanently force stress-adaptive behavior off with a specific
-service, specify "-o stress=" on its command line. This may be
-desirable for the "submission" service. Issue "postfix reload" to
-make the change effective. </p>
+service, specify "-o stress=" on its <a href="master.5.html">master.cf</a> command line. This
+may be desirable for the "submission" service. Issue "postfix reload"
+to make the change effective. </p>
+
+<p> Note: setting the stress parameter in <a href="postconf.5.html">main.cf</a> has no effect for
+services that accept remote connections. </p>
<blockquote>
<pre>
<li> <a href="#client_cipher">Client-side cipher controls </a>
+<li> <a href="#client_smtps">Client-side SMTPS support </a>
+
<li> <a href="#client_misc"> Miscellaneous client controls </a>
</ul>
</pre>
</blockquote>
+<h3> <a name="client_smtps">Client-side SMTPS support </a> </h3>
+
+<p> Although the Postfix SMTP client by itself doesn't support TLS
+wrapper mode, it is relatively easy to forward a connection through
+the stunnel program if Postfix needs to deliver mail to some legacy
+system that doesn't support STARTTLS. Use one of the following two
+examples, to send only some remote mail, or to send all remote mail,
+to an SMTPS server. </p>
+
+<h4> Sending all remote mail to an SMTPS server </h4>
+
+<p> The first example uses SMTPS to send all remote mail to a
+provider's mail server called "mail.example.com". </p>
+
+<p> A minimal stunnel.conf file is sufficient to set up a tunnel
+from local port 11125 to the remote destination "mail.example.com"
+and port "smtps". Postfix will later use this tunnel to connect to
+the remote server. </p>
+
+<blockquote>
+<pre>
+/path/to/stunnel.conf:
+ [smtp-tls-wrapper]
+ accept = 11125
+ client = yes
+ connect = mail.example.com:smtps
+</pre>
+</blockquote>
+
+<p> To test this tunnel, use: </p>
+
+<blockquote>
+<pre>
+$ telnet localhost 11125
+</pre>
+</blockquote>
+
+<p> This should produce the greeting from the remote SMTP server
+at mail.example.com. </p>
+
+<p> On the Postfix side, the <a href="postconf.5.html#relayhost">relayhost</a> feature sends all remote
+mail through the local stunnel listener on port 11125: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/<a href="postconf.5.html">main.cf</a>:
+ <a href="postconf.5.html#relayhost">relayhost</a> = [127.0.0.1]:11125
+</pre>
+</blockquote>
+
+<p> Use "postfix reload" to make the change effective. </p>
+
+<h4> Sending only mail for a specific destination via SMTPS </h4>
+
+<p> The second example will use SMTPS to send only mail for
+"example.com" via SMTPS. It uses the same stunnel configuration
+file as the first example, so it won't be repeated here. </p>
+
+<p> This time, the Postfix side uses a transport map to direct only
+mail for "example.com" through the tunnel: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/<a href="postconf.5.html">main.cf</a>:
+ <a href="postconf.5.html#transport_maps">transport_maps</a> = hash:/etc/postfix/transport
+
+/etc/postfix/transport:
+ example.com relay:[127.0.0.1]:11125
+</pre>
+</blockquote>
+
+<p> Use "postmap hash:/etc/postfix/transport" and "postfix reload"
+to make the change effective. </p>
+
<h3> <a name="client_misc"> Miscellaneous client controls </a> </h3>
<p> The <a href="postconf.5.html#smtp_starttls_timeout">smtp_starttls_timeout</a> parameter limits the time of Postfix
<h2>Purpose of the XCLIENT extension to SMTP</h2>
-<p> The XCLIENT command targets the following problems: </p>
+<p> When an SMTP server announces support for the XCLIENT command,
+an SMTP client may send information that overrides one or more
+client-related session attributes. The XCLIENT command targets the
+following problems: </p>
<ol>
<h2>Purpose of the XFORWARD extension to SMTP</h2>
-<p> The XFORWARD command targets the following problem: </p>
+<p> When an SMTP server announces support for the XFORWARD command,
+an SMTP client may send information that overrides one or more
+client-related logging attributes. The XFORWARD command targets
+the following problem: </p>
<ul>
<b>ter.cf</b> entry.
<b>COMPATIBILITY CONTROLS</b>
+ Available before Postfix version 2.5:
+
<b><a href="postconf.5.html#allow_min_user">allow_min_user</a> (no)</b>
- Allow a recipient address to have `-' as the first
- character.
+ Allow a sender or recipient address to have `-' as
+ the first character.
<b>ACTIVE QUEUE CONTROLS</b>
<b><a href="postconf.5.html#qmgr_clog_warn_time">qmgr_clog_warn_time</a> (300s)</b>
This information is modified by the <b>hqu</b>
flags for quoting and case folding.
+ This feature is available in Postfix 2.5 and
+ later.
+
<b>${recipient</b>}
This macro expands to the complete recipient
address.
- A command-line argument that contains
+ A command-line argument that contains
<b>${recipient</b>} expands to as many command-line
arguments as there are recipients.
- This information is modified by the <b>hqu</b>
+ This information is modified by the <b>hqu</b>
flags for quoting and case folding.
<b>${sasl_method</b>}
- This macro expands to the SASL authentica-
- tion mechanism used during the reception of
- the message. An empty string is passed if
- the message has been received without SASL
+ This macro expands to the SASL authentica-
+ tion mechanism used during the reception of
+ the message. An empty string is passed if
+ the message has been received without SASL
authentication.
- This is available in Postfix 2.2 and later.
+ This is available in Postfix 2.2 and later.
<b>${sasl_sender</b>}
- This macro expands to the SASL sender name
- (i.e.
the original submitter as per <a href="http://tools.ietf.org/html/rfc4954">RFC</a>
- <a href="http://tools.ietf.org/html/rfc4954">4954</a>) used during the reception of the mes-
+ This macro expands to the SASL sender name
+ (i.e.
the original submitter as per <a href="http://tools.ietf.org/html/rfc4954">RFC</a>
+ <a href="http://tools.ietf.org/html/rfc4954">4954</a>) used during the reception of the mes-
sage.
- This is available in Postfix 2.2 and later.
+ This is available in Postfix 2.2 and later.
<b>${sasl_username</b>}
- This macro expands to the SASL user name
+ This macro expands to the SASL user name
used during the reception of the message. An
- empty string is passed if the message has
+ empty string is passed if the message has
been received without SASL authentication.
- This is available in Postfix 2.2 and later.
+ This is available in Postfix 2.2 and later.
<b>${sender</b>}
- This macro expands to the envelope sender
+ This macro expands to the envelope sender
address. By default, the null sender address
- expands to MAILER-DAEMON; this can be
- changed with the <b>null_sender</b> attribute, as
+ expands to MAILER-DAEMON; this can be
+ changed with the <b>null_sender</b> attribute, as
described above.
- This information is modified by the <b>q</b> flag
+ This information is modified by the <b>q</b> flag
for quoting.
<b>${size</b>}
- This macro expands to Postfix's idea of the
- message size, which is an approximation of
+ This macro expands to Postfix's idea of the
+ message size, which is an approximation of
the size of the message as delivered.
<b>${user</b>}
This macro expands to the username part of a
- recipient address. For example, with an
+ recipient address. For example, with an
address <i>user+foo@domain</i> the username part is
<i>user</i>.
- A command-line argument that contains
- <b>${user</b>} expands into as many command-line
+ A command-line argument that contains
+ <b>${user</b>} expands into as many command-line
arguments as there are recipients.
- This information is modified by the <b>u</b> flag
+ This information is modified by the <b>u</b> flag
for case folding.
<b>STANDARDS</b>
<a href="http://tools.ietf.org/html/rfc3463">RFC 3463</a> (Enhanced status codes)
<b>DIAGNOSTICS</b>
- Command exit status codes are expected to follow the con-
- ventions defined in <<b>sysexits.h</b>>. Exit status 0 means
+ Command exit status codes are expected to follow the con-
+ ventions defined in <<b>sysexits.h</b>>. Exit status 0 means
normal successful completion.
- Postfix version 2.3 and later support <a href="http://tools.ietf.org/html/rfc3463">RFC 3463</a>-style
- enhanced status codes. If a command terminates with a
- non-zero exit status, and the command output begins with
+ Postfix version 2.3 and later support <a href="http://tools.ietf.org/html/rfc3463">RFC 3463</a>-style
+ enhanced status codes. If a command terminates with a
+ non-zero exit status, and the command output begins with
an enhanced status code, this status code takes precedence
over the non-zero exit status.
- Problems and transactions are logged to <b>syslogd</b>(8). Cor-
- rupted message files are marked so that the queue manager
+ Problems and transactions are logged to <b>syslogd</b>(8). Cor-
+ rupted message files are marked so that the queue manager
can move them to the <b>corrupt</b> queue for further inspection.
<b>SECURITY</b>
- This program needs a dual personality 1) to access the
- private Postfix queue and IPC mechanisms, and 2) to exe-
+ This program needs a dual personality 1) to access the
+ private Postfix queue and IPC mechanisms, and 2) to exe-
cute external commands as the specified user. It is there-
fore security sensitive.
<b>CONFIGURATION PARAMETERS</b>
- Changes
to <a href="postconf.5.html"><b>main.cf</b></a> are picked up automatically as <a href="pipe.8.html"><b>pipe</b>(8)</a>
- processes run for only a limited amount of time. Use the
+ Changes
to <a href="postconf.5.html"><b>main.cf</b></a> are picked up automatically as <a href="pipe.8.html"><b>pipe</b>(8)</a>
+ processes run for only a limited amount of time. Use the
command "<b>postfix reload</b>" to speed up a change.
- The text below provides only a parameter summary. See
+ The text below provides only a parameter summary. See
<a href="postconf.5.html"><b>postconf</b>(5)</a> for more details including examples.
<b>RESOURCE AND RATE CONTROLS</b>
- In the text below, <i>transport</i> is the first field in a <b>mas-</b>
+ In the text below, <i>transport</i> is the first field in a <b>mas-</b>
<b>ter.cf</b> entry.
<b><a href="postconf.5.html#transport_destination_concurrency_limit"><i>transport</i>_destination_concurrency_limit</a> ($<a href="postconf.5.html#default_destination_concurrency_limit">default_destina</a>-</b>
<b><a href="postconf.5.html#default_destination_concurrency_limit">tion_concurrency_limit</a>)</b>
Limit the number of parallel deliveries to the same
- destination, for delivery via the named <i>transport</i>.
+ destination, for delivery via the named <i>transport</i>.
The limit is enforced by the Postfix queue manager.
<b><a href="postconf.5.html#transport_destination_recipient_limit"><i>transport</i>_destination_recipient_limit</a> ($<a href="postconf.5.html#default_destination_recipient_limit">default_destina</a>-</b>
<b><a href="postconf.5.html#default_destination_recipient_limit">tion_recipient_limit</a>)</b>
- Limit the number of recipients per message deliv-
- ery, for delivery via the named <i>transport</i>. The
+ Limit the number of recipients per message deliv-
+ ery, for delivery via the named <i>transport</i>. The
limit is enforced by the Postfix queue manager.
<b><a href="postconf.5.html#transport_time_limit"><i>transport</i>_time_limit</a> ($<a href="postconf.5.html#command_time_limit">command_time_limit</a>)</b>
- Limit the time for delivery to external command,
+ Limit the time for delivery to external command,
for delivery via the named <i>transport</i>. The limit is
enforced by the pipe delivery agent.
- Postfix 2.4 and later support a suffix that speci-
- fies the time unit: s (seconds), m (minutes), h
+ Postfix 2.4 and later support a suffix that speci-
+ fies the time unit: s (seconds), m (minutes), h
(hours), d (days), w (weeks). The default time unit
is seconds.
<b>MISCELLANEOUS CONTROLS</b>
<b><a href="postconf.5.html#config_directory">config_directory</a> (see 'postconf -d' output)</b>
- The default location of the Postfix <a href="postconf.5.html">main.cf</a> and
+ The default location of the Postfix <a href="postconf.5.html">main.cf</a> and
<a href="master.5.html">master.cf</a> configuration files.
<b><a href="postconf.5.html#daemon_timeout">daemon_timeout</a> (18000s)</b>
- How much time a Postfix daemon process may take to
- handle a request before it is terminated by a
+ How much time a Postfix daemon process may take to
+ handle a request before it is terminated by a
built-in watchdog timer.
<b><a href="postconf.5.html#delay_logging_resolution_limit">delay_logging_resolution_limit</a> (2)</b>
- The maximal number of digits after the decimal
+ The maximal number of digits after the decimal
point when logging sub-second delay values.
<b><a href="postconf.5.html#export_environment">export_environment</a> (see 'postconf -d' output)</b>
- The list of environment variables that a Postfix
+ The list of environment variables that a Postfix
process will export to non-Postfix processes.
<b><a href="postconf.5.html#ipc_timeout">ipc_timeout</a> (3600s)</b>
and most Postfix daemon processes.
<b><a href="postconf.5.html#max_idle">max_idle</a> (100s)</b>
- The maximum amount of time that an idle Postfix
- daemon process waits for an incoming connection
+ The maximum amount of time that an idle Postfix
+ daemon process waits for an incoming connection
before terminating voluntarily.
<b><a href="postconf.5.html#max_use">max_use</a> (100)</b>
- The maximal number of incoming connections that a
- Postfix daemon process will service before termi-
+ The maximal number of incoming connections that a
+ Postfix daemon process will service before termi-
nating voluntarily.
<b><a href="postconf.5.html#process_id">process_id</a> (read-only)</b>
- The process ID of a Postfix command or daemon
+ The process ID of a Postfix command or daemon
process.
<b><a href="postconf.5.html#process_name">process_name</a> (read-only)</b>
- The process name of a Postfix command or daemon
+ The process name of a Postfix command or daemon
process.
<b><a href="postconf.5.html#queue_directory">queue_directory</a> (see 'postconf -d' output)</b>
- The location of the Postfix top-level queue direc-
+ The location of the Postfix top-level queue direc-
tory.
<b><a href="postconf.5.html#recipient_delimiter">recipient_delimiter</a> (empty)</b>
The syslog facility of Postfix logging.
<b><a href="postconf.5.html#syslog_name">syslog_name</a> (postfix)</b>
- The mail system name that is prepended to the
- process name in syslog records, so that "smtpd"
+ The mail system name that is prepended to the
+ process name in syslog records, so that "smtpd"
becomes, for example, "postfix/smtpd".
<b>SEE ALSO</b>
syslogd(8), system logging
<b>LICENSE</b>
- The Secure Mailer license must be distributed with this
+ The Secure Mailer license must be distributed with this
software.
<b>AUTHOR(S)</b>
(default: no)</b></DT><DD>
<p>
-Allow a recipient address to have `-' as the first character. By
+Allow a sender or recipient address to have `-' as the first
+character. By
default, this is not allowed, to avoid accidents with software that
passes email addresses via the command line. Such software
would not be able to distinguish a malicious address from a
inserting a "--" option terminator into the command line, this is
difficult to enforce consistently and globally. </p>
+<p> As of Postfix version 2.5, this feature is implemented by
+<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a>. With earlier versions this feature was implemented
+by <a href="qmgr.8.html">qmgr(8)</a> and was limited to recipient addresses only. </p>
+
</DD>
another preemption can take place later.
</p>
-<p> Use <a href="postconf.5.html#transport_delivery_slot_discount"><a href="postconf.5.html#transport_delivery_slot_discount"><i>transport</i>_delivery_slot_discount</a></a> to specify a
+<p> Use <a href="postconf.5.html#transport_delivery_slot_discount"><i>transport</i>_delivery_slot_discount</a> to specify a
transport-specific override, where <i>transport</i> is the <a href="master.5.html">master.cf</a>
name of the message delivery transport.
</p>
</p>
+</DD>
+
+<DT><b><a name="stress">stress</a>
+(default: empty)</b></DT><DD>
+
+<p> This feature is documented in the <a href="STRESS_README.html">STRESS_README</a> document. </p>
+
+<p> This feature is available in Postfix 2.5 and later. </p>
+
+
</DD>
<DT><b><a name="strict_7bit_headers">strict_7bit_headers</a>
<b>ter.cf</b> entry.
<b>COMPATIBILITY CONTROLS</b>
+ Available before Postfix version 2.5:
+
<b><a href="postconf.5.html#allow_min_user">allow_min_user</a> (no)</b>
- Allow a recipient address to have `-' as the first
- character.
+ Allow a sender or recipient address to have `-' as
+ the first character.
<b>ACTIVE QUEUE CONTROLS</b>
<b><a href="postconf.5.html#qmgr_clog_warn_time">qmgr_clog_warn_time</a> (300s)</b>
The default value for transport-specific _deliv-
ery_slot_discount settings.
- <b><a href="postconf.5.html#transport_delivery_slot_discount"><
a href="postconf.5.html#transport_delivery_slot_discount"><i>transport</i>_delivery_slot_discount</a></a> ($<a href="postconf.5.html#default_delivery_slot_discount">default_deliv</a>-</b>
+ <b><a href="postconf.5.html#transport_delivery_slot_discount"><
i>transport</i>_delivery_slot_discount</a> ($<a href="postconf.5.html#default_delivery_slot_discount">default_deliv</a>-</b>
<b><a href="postconf.5.html#default_delivery_slot_discount">ery_slot_discount</a>)</b>
Idem, for delivery via the named message <i>transport</i>.
Resolve "user@ipaddress" as "user@[ipaddress]",
instead of rejecting the address as invalid.
+ Available with Postfix version 2.5 and later:
+
+ <b><a href="postconf.5.html#allow_min_user">allow_min_user</a> (no)</b>
+ Allow a sender or recipient address to have `-' as
+ the first character.
+
<b>ADDRESS REWRITING CONTROLS</b>
<b><a href="postconf.5.html#myorigin">myorigin</a> ($<a href="postconf.5.html#myhostname">myhostname</a>)</b>
The domain name that locally-posted mail appears to
- come from, and that locally posted mail is deliv-
+ come from, and that locally posted mail is deliv-
ered to.
<b><a href="postconf.5.html#allow_percent_hack">allow_percent_hack</a> (yes)</b>
- Enable the rewriting of the form "user%domain" to
+ Enable the rewriting of the form "user%domain" to
"user@domain".
<b><a href="postconf.5.html#append_at_myorigin">append_at_myorigin</a> (yes)</b>
- With locally submitted mail, append the string
- "@$<a href="postconf.5.html#myorigin">myorigin</a>" to mail addresses without domain
+ With locally submitted mail, append the string
+ "@$<a href="postconf.5.html#myorigin">myorigin</a>" to mail addresses without domain
information.
<b><a href="postconf.5.html#append_dot_mydomain">append_dot_mydomain</a> (yes)</b>
- With locally submitted mail, append the string
- ".$<a href="postconf.5.html#mydomain">mydomain</a>" to addresses that have no ".domain"
+ With locally submitted mail, append the string
+ ".$<a href="postconf.5.html#mydomain">mydomain</a>" to addresses that have no ".domain"
information.
<b><a href="postconf.5.html#recipient_delimiter">recipient_delimiter</a> (empty)</b>
sions (user+foo).
<b><a href="postconf.5.html#swap_bangpath">swap_bangpath</a> (yes)</b>
- Enable the rewriting of "site!user" into
+ Enable the rewriting of "site!user" into
"user@site".
Available in Postfix 2.2 and later:
<b><a href="postconf.5.html#remote_header_rewrite_domain">remote_header_rewrite_domain</a> (empty)</b>
- Don't rewrite message headers from remote clients
+ Don't rewrite message headers from remote clients
at all when this parameter is empty; otherwise, re-
- write message headers and append the specified
+ write message headers and append the specified
domain name to incomplete addresses.
<b>ROUTING CONTROLS</b>
- The following is applicable to Postfix version 2.0 and
- later.
Earlier versions do not have support for: <a href="postconf.5.html#virtual_transport">vir</a>-
- <a href="postconf.5.html#virtual_transport">tual_transport</a>,
<a href="postconf.5.html#relay_transport">relay_transport</a>, <a href="postconf.5.html#virtual_alias_domains">virtual_alias_domains</a>,
+ The following is applicable to Postfix version 2.0 and
+ later.
Earlier versions do not have support for: <a href="postconf.5.html#virtual_transport">vir</a>-
+ <a href="postconf.5.html#virtual_transport">tual_transport</a>,
<a href="postconf.5.html#relay_transport">relay_transport</a>, <a href="postconf.5.html#virtual_alias_domains">virtual_alias_domains</a>,
<a href="postconf.5.html#virtual_mailbox_domains">virtual_mailbox_domains</a> or <a href="postconf.5.html#proxy_interfaces">proxy_interfaces</a>.
<b><a href="postconf.5.html#local_transport">local_transport</a> (<a href="local.8.html">local</a>:$<a href="postconf.5.html#myhostname">myhostname</a>)</b>
- The default mail delivery transport and next-hop
- destination for final delivery to domains listed
- with <a href="postconf.5.html#mydestination">mydestination</a>, and for [ipaddress] destina-
- tions
that match $<a href="postconf.5.html#inet_interfaces">inet_interfaces</a> or $<a href="postconf.5.html#proxy_interfaces">proxy_inter</a>-
+ The default mail delivery transport and next-hop
+ destination for final delivery to domains listed
+ with <a href="postconf.5.html#mydestination">mydestination</a>, and for [ipaddress] destina-
+ tions
that match $<a href="postconf.5.html#inet_interfaces">inet_interfaces</a> or $<a href="postconf.5.html#proxy_interfaces">proxy_inter</a>-
<a href="postconf.5.html#proxy_interfaces">faces</a>.
<b><a href="postconf.5.html#virtual_transport">virtual_transport</a> (virtual)</b>
- The default mail delivery transport and next-hop
- destination for final delivery to domains listed
+ The default mail delivery transport and next-hop
+ destination for final delivery to domains listed
with $<a href="postconf.5.html#virtual_mailbox_domains">virtual_mailbox_domains</a>.
<b><a href="postconf.5.html#relay_transport">relay_transport</a> (relay)</b>
- The default mail delivery transport and next-hop
- destination for remote delivery to domains listed
+ The default mail delivery transport and next-hop
+ destination for remote delivery to domains listed
with $<a href="postconf.5.html#relay_domains">relay_domains</a>.
<b><a href="postconf.5.html#default_transport">default_transport</a> (smtp)</b>
- The default mail delivery transport and next-hop
- destination for destinations that do not match
+ The default mail delivery transport and next-hop
+ destination for destinations that do not match
$<a href="postconf.5.html#mydestination">mydestination</a>, $<a href="postconf.5.html#inet_interfaces">inet_interfaces</a>, $<a href="postconf.5.html#proxy_interfaces">proxy_inter</a>-
<a href="postconf.5.html#proxy_interfaces">faces</a>, $<a href="postconf.5.html#virtual_alias_domains">virtual_alias_domains</a>, $<a href="postconf.5.html#virtual_mailbox_domains">virtual_mail-
box_domains</a>, or $<a href="postconf.5.html#relay_domains">relay_domains</a>.
- <b><a href="postconf.5.html#parent_domain_matches_subdomains">parent_domain_matches_subdomains</a> (see 'postconf -d' out-</b>
+ <b><a href="postconf.5.html#parent_domain_matches_subdomains">parent_domain_matches_subdomains</a> (see 'postconf -d' out-</b>
<b>put)</b>
What Postfix features match subdomains of
"domain.tld" automatically, instead of requiring an
explicit ".domain.tld" pattern.
<b><a href="postconf.5.html#relayhost">relayhost</a> (empty)</b>
- The next-hop destination of non-local mail; over-
+ The next-hop destination of non-local mail; over-
rides non-<a href="ADDRESS_CLASS_README.html#local_domain_class">local domains</a> in recipient addresses.
<b><a href="postconf.5.html#transport_maps">transport_maps</a> (empty)</b>
Optional lookup tables with mappings from recipient
- address to (message delivery transport, next-hop
+ address to (message delivery transport, next-hop
destination).
Available in Postfix version 2.3 and later:
<b><a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a> (empty)</b>
- A
sender-dependent override for the global <a href="postconf.5.html#relayhost">relay</a>-
+ A
sender-dependent override for the global <a href="postconf.5.html#relayhost">relay</a>-
<a href="postconf.5.html#relayhost">host</a> parameter setting.
Available in Postfix version 2.5 and later:
<b><a href="postconf.5.html#empty_address_relayhost_maps_lookup_key">empty_address_relayhost_maps_lookup_key</a> (</b><><b>)</b>
- The <a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a> search string
- that will be used instead of the null sender
+ The <a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a> search string
+ that will be used instead of the null sender
address.
<b>ADDRESS VERIFICATION CONTROLS</b>
- Postfix version 2.1 introduces sender and recipient
- address verification. This feature is implemented by
- sending probe email messages that are not actually deliv-
- ered. By default, address verification probes use the
- same route as regular mail. To override specific aspects
- of message routing for address verification probes, spec-
+ Postfix version 2.1 introduces sender and recipient
+ address verification. This feature is implemented by
+ sending probe email messages that are not actually deliv-
+ ered. By default, address verification probes use the
+ same route as regular mail. To override specific aspects
+ of message routing for address verification probes, spec-
ify one or more of the following:
<b><a href="postconf.5.html#address_verify_local_transport">address_verify_local_transport</a> ($<a href="postconf.5.html#local_transport">local_transport</a>)</b>
address verification probes.
<b><a href="postconf.5.html#address_verify_virtual_transport">address_verify_virtual_transport</a> ($<a href="postconf.5.html#virtual_transport">virtual_transport</a>)</b>
- Overrides the <a href="postconf.5.html#virtual_transport">virtual_transport</a> parameter setting
+ Overrides the <a href="postconf.5.html#virtual_transport">virtual_transport</a> parameter setting
for address verification probes.
<b><a href="postconf.5.html#address_verify_relay_transport">address_verify_relay_transport</a> ($<a href="postconf.5.html#relay_transport">relay_transport</a>)</b>
address verification probes.
<b><a href="postconf.5.html#address_verify_default_transport">address_verify_default_transport</a> ($<a href="postconf.5.html#default_transport">default_transport</a>)</b>
- Overrides the <a href="postconf.5.html#default_transport">default_transport</a> parameter setting
+ Overrides the <a href="postconf.5.html#default_transport">default_transport</a> parameter setting
for address verification probes.
<b><a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> ($<a href="postconf.5.html#relayhost">relayhost</a>)</b>
- Overrides the <a href="postconf.5.html#relayhost">relayhost</a> parameter setting for
+ Overrides the <a href="postconf.5.html#relayhost">relayhost</a> parameter setting for
address verification probes.
<b><a href="postconf.5.html#address_verify_transport_maps">address_verify_transport_maps</a> ($<a href="postconf.5.html#transport_maps">transport_maps</a>)</b>
- Overrides the <a href="postconf.5.html#transport_maps">transport_maps</a> parameter setting for
+ Overrides the <a href="postconf.5.html#transport_maps">transport_maps</a> parameter setting for
address verification probes.
Available in Postfix version 2.3 and later:
<b><a href="postconf.5.html#address_verify_sender_dependent_relayhost_maps">address_verify_sender_dependent_relayhost_maps</a></b>
<b>($<a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a>)</b>
Overrides the <a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a>
- parameter setting for address verification probes.
+ parameter setting for address verification probes.
<b>MISCELLANEOUS CONTROLS</b>
<b><a href="postconf.5.html#config_directory">config_directory</a> (see 'postconf -d' output)</b>
- The default location of the Postfix <a href="postconf.5.html">main.cf</a> and
+ The default location of the Postfix <a href="postconf.5.html">main.cf</a> and
<a href="master.5.html">master.cf</a> configuration files.
<b><a href="postconf.5.html#daemon_timeout">daemon_timeout</a> (18000s)</b>
- How much time a Postfix daemon process may take to
- handle a request before it is terminated by a
+ How much time a Postfix daemon process may take to
+ handle a request before it is terminated by a
built-in watchdog timer.
<b><a href="postconf.5.html#empty_address_recipient">empty_address_recipient</a> (MAILER-DAEMON)</b>
- The recipient of mail addressed to the null
+ The recipient of mail addressed to the null
address.
<b><a href="postconf.5.html#ipc_timeout">ipc_timeout</a> (3600s)</b>
over an internal communication channel.
<b><a href="postconf.5.html#max_idle">max_idle</a> (100s)</b>
- The maximum amount of time that an idle Postfix
- daemon process waits for an incoming connection
+ The maximum amount of time that an idle Postfix
+ daemon process waits for an incoming connection
before terminating voluntarily.
<b><a href="postconf.5.html#max_use">max_use</a> (100)</b>
- The maximal number of incoming connections that a
- Postfix daemon process will service before termi-
+ The maximal number of incoming connections that a
+ Postfix daemon process will service before termi-
nating voluntarily.
<b><a href="postconf.5.html#relocated_maps">relocated_maps</a> (empty)</b>
for users or domains that no longer exist.
<b><a href="postconf.5.html#process_id">process_id</a> (read-only)</b>
- The process ID of a Postfix command or daemon
+ The process ID of a Postfix command or daemon
process.
<b><a href="postconf.5.html#process_name">process_name</a> (read-only)</b>
- The process name of a Postfix command or daemon
+ The process name of a Postfix command or daemon
process.
<b><a href="postconf.5.html#queue_directory">queue_directory</a> (see 'postconf -d' output)</b>
- The location of the Postfix top-level queue direc-
+ The location of the Postfix top-level queue direc-
tory.
<b><a href="postconf.5.html#show_user_unknown_table_name">show_user_unknown_table_name</a> (yes)</b>
- Display the name of the recipient table in the
+ Display the name of the recipient table in the
"User unknown" responses.
<b><a href="postconf.5.html#syslog_facility">syslog_facility</a> (mail)</b>
The syslog facility of Postfix logging.
<b><a href="postconf.5.html#syslog_name">syslog_name</a> (postfix)</b>
- The mail system name that is prepended to the
- process name in syslog records, so that "smtpd"
+ The mail system name that is prepended to the
+ process name in syslog records, so that "smtpd"
becomes, for example, "postfix/smtpd".
Available in Postfix version 2.0 and later:
<b><a href="postconf.5.html#helpful_warnings">helpful_warnings</a> (yes)</b>
- Log warnings about problematic configuration set-
+ Log warnings about problematic configuration set-
tings, and provide helpful suggestions.
<b>SEE ALSO</b>
<a href="ADDRESS_VERIFICATION_README.html">ADDRESS_VERIFICATION_README</a>, Postfix address verification
<b>LICENSE</b>
- The Secure Mailer license must be distributed with this
+ The Secure Mailer license must be distributed with this
software.
<b>AUTHOR(S)</b>
.ad
.ft R
.SH allow_min_user (default: no)
-Allow a recipient address to have `-' as the first character. By
+Allow a sender or recipient address to have `-' as the first
+character. By
default, this is not allowed, to avoid accidents with software that
passes email addresses via the command line. Such software
would not be able to distinguish a malicious address from a
bona fide command-line option. Although this can be prevented by
inserting a "--" option terminator into the command line, this is
difficult to enforce consistently and globally.
+.PP
+As of Postfix version 2.5, this feature is implemented by
+\fBtrivial-rewrite\fR(8). With earlier versions this feature was implemented
+by \fBqmgr\fR(8) and was limited to recipient addresses only.
.SH allow_percent_hack (default: yes)
Enable the rewriting of the form "user%domain" to "user@domain".
This is enabled by default.
.PP
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
The default time unit is s (seconds).
+.SH stress (default: empty)
+This feature is documented in the STRESS_README document.
+.PP
+This feature is available in Postfix 2.5 and later.
.SH strict_7bit_headers (default: no)
Reject mail with 8-bit text in message headers. This blocks mail
from poorly written applications.
.nf
.ad
.fi
+Available before Postfix version 2.5:
.IP "\fBallow_min_user (no)\fR"
-Allow a recipient address to have `-' as the first character.
+Allow a sender or recipient address to have `-' as the first
+character.
.SH "ACTIVE QUEUE CONTROLS"
.na
.nf
.sp
This information is modified by the \fBhqu\fR flags for quoting
and case folding.
+.sp
+This feature is available in Postfix 2.5 and later.
.IP \fB${\fBrecipient\fR}\fR
This macro expands to the complete recipient address.
.sp
.nf
.ad
.fi
+Available before Postfix version 2.5:
.IP "\fBallow_min_user (no)\fR"
-Allow a recipient address to have `-' as the first character.
+Allow a sender or recipient address to have `-' as the first
+character.
.SH "ACTIVE QUEUE CONTROLS"
.na
.nf
.IP "\fBresolve_numeric_domain (no)\fR"
Resolve "user@ipaddress" as "user@[ipaddress]", instead of
rejecting the address as invalid.
+.PP
+Available with Postfix version 2.5 and later:
+.IP "\fBallow_min_user (no)\fR"
+Allow a sender or recipient address to have `-' as the first
+character.
.SH "ADDRESS REWRITING CONTROLS"
.na
.nf
s;(<i>transport</i>)(<b>)?(_recipient_refill_delay)\b;$2<a href="postconf.5.html#transport_recipient_refill_delay">$1$3</a>;g;
s;(<i>transport</i>)(<b>)?(_recipient_refill_limit)\b;$2<a href="postconf.5.html#transport_recipient_refill_limit">$1$3</a>;g;
s;(<i>transport</i>)(<b>)?(_time_limit)\b;$2<a href="postconf.5.html#transport_time_limit">$1$3</a>;g;
- s;(<i>transport</i>)(<b>)?(_delivery_slot_discount)\b;$2<a href="postconf.5.html#transport_delivery_slot_discount">$1$3</a>;g;
s;(<i>transport</i>)(<b>)?(_delivery_rate_delay)\b;$2<a href="postconf.5.html#transport_delivery_rate_delay">$1$3</a>;g;
# Undo hyperlinks of manual pages with the same name as parameters.
# Glue manual/parameter/restriction hyperlinks without line breaks.
s/(<a href="[^"]*">)([<bB>]*[-a-zA-Z0-9._]*[<bB>]*)<\/a>\1/$1$2/g;
+ # One more time:
s/(<a href="[^"]*">)([<bB>]*[-a-zA-Z0-9._]*[<bB>]*)<\/a>\1/$1$2/g;
# Hyperlink phrases not in headers.
After success:
fail_cohorts = 0
- Be prepared for feedback > hysteresis, or rounding error
+ Be prepared for feedback > hysteresis, or rounding error
success += g(concurrency)
while (success >= 1) Hysteresis 1
concurrency += 1 Hysteresis 1
failure = 0
success -= 1 Hysteresis 1
Be prepared for overshoot
- if (concurrency > concurrency limit)
+ if (concurrency > concurrency limit)
concurrency = concurrency limit
Safety:
Don't apply positive feedback unless
- concurrency < busy_refcount + init_dest_concurrency
+ concurrency < busy_refcount + init_dest_concurrency
otherwise negative feedback effect could be delayed
After failure:
- if (concurrency > 0)
+ if (concurrency > 0)
fail_cohorts += 1.0 / concurrency
- if (fail_cohorts > cohort_failure_limit)
+ if (fail_cohorts > cohort_failure_limit)
concurrency = 0
- if (concurrency > 0)
- Be prepared for feedback > hysteresis, rounding errors
+ if (concurrency > 0)
+ Be prepared for feedback > hysteresis, rounding errors
failure -= f(concurrency)
- while (failure < 0)
+ while (failure < 0)
concurrency -= 1 Hysteresis 1
failure += 1 Hysteresis 1
success = 0
Be prepared for overshoot
- if (concurrency < 1)
+ if (concurrency < 1)
concurrency = 1
</pre>
<p>
This document attempts to describe the new queue manager and its
-preeemptive scheduler algorithm. Note that the document was originally
+preemptive scheduler algorithm. Note that the document was originally
written to describe the changes between the new queue manager (in
this text referred to as <tt>nqmgr</tt>, the name it was known by
before it became the default queue manager) and the old queue manager
to both the queue entry list and the peer entry list. The addresses
for same nexthop are batched in the entries up to recipient_concurrency
limit for that transport. This happens in qmgr_assign() and apart
-from that it operates with job and peer structures is basically the
+from that it operates with job and peer structures it is basically the
same as in <tt>oqmgr</tt>.
</p>
foreach transport's job (in the order of the transport's job list)
do
foreach job's peer (round-robin-by-destination)
- if peer->queue->concurrency < peer->queue->window
+ if peer->queue->concurrency < peer->queue->window
return next peer entry.
done
done
<p>
So, we have the job list, which is first ordered by the time the
-job's messages were enqueued, oldest messages first, the most recently
+jobs' messages were enqueued, oldest messages first, the most recently
picked one at the end. For now, let's assume that there are no
destination concurrency problems. Without preemption, we pick some
entry of the first (oldest) job on the queue, assign it to delivery
is basically the same trick you might remember as "accumulation of
potential" from the amortized complexity lessons. For example,
instead of delivering the entries of the first job on the job list
-every time an delivery agent becomes available, we can do it only
+every time a delivery agent becomes available, we can do it only
every second time. If you view the moments the delivery agent becomes
available on a timeline as "delivery slots", then instead of using
every delivery slot for the first job, we can use only every other
<p>
-So, it becomes obvious that while the inflating the message to get
+So, it becomes obvious that while inflating the message to get
free slots is great idea, one has to be really careful of how the
free slots are assigned, otherwise one might corner himself. So,
how does <tt>nqmgr</tt> really use the free slots?
in a uniform way. The delivery sequence <tt>111...1</tt> is no
worse than <tt>1.1.1.1</tt>, in fact, it is even better as some
entries are in the first case selected earlier than in the second
-case, and none is selected later! So it is possible to first to
+case, and none is selected later! So it is possible to first
"accumulate" the free delivery slots and then use them all at once.
It is even possible to accumulate some, then use them, then accumulate
some more and use them again, as in <tt>11..1.1</tt> .
after then to preempt the first job and sneak the one hundred
recipient mail in. Applying the algorithm recursively, we see the
hundred recipient job can accumulate ten free delivery slots, and
-then we could preempt it and sneak in the ten recipient mail...
+then we could preempt it and sneak in the ten-recipient mail...
Wait wait wait! Could we? Aren't we overinflating the original one
thousand recipient mail?
(remember a job can be preempted several times). In either case,
we know how many are accumulated and how many are left to deliver,
so we know how many it may yet accumulate at maximum. Every other
-job which may be delivered by less than that amount of slots is an
+job which may be delivered by less than that amount of slots is a
valid candidate for preemption. How do we choose among them?
</p>
The truth is that it turns out that it is not really necessary to
wait until the jobs counter accumulates all the delivery slots in
-advance. Say we have ten recipient mail followed by two two-recipient
+advance. Say we have ten-recipient mail followed by two two-recipient
mails. If the preemption happened when enough delivery slot accumulate
(assuming slot cost 2), the delivery sequence becomes
<tt>11112211113311</tt>. Now what would we get if we would wait
only for 50% of the necessary slots to accumulate and we promise
-we would wait for the remaining 50% later, after the we get back
+we would wait for the remaining 50% later, after we get back
to the preempted job? If we use such slot loan, the delivery sequence
becomes <tt>11221111331111</tt>. As we can see, it makes it no
considerably worse for the delivery of the ten-recipient mail, but
delivery conditions. The feeling of understanding shall last until
you start wondering what happens if some of the jobs are blocked,
which you might eventually figure out correctly from what had been
-said already. But I would be surprised if you mental image of the
-scheduler's functionality it is not completely shattered once you
+said already. But I would be surprised if your mental image of the
+scheduler's functionality is not completely shattered once you
start wondering how it works when not all recipients may be read
in-core. More on that later.]
<p>
-So the summary is that the user's don't really have to be concerned
+So the summary is that the users don't really have to be concerned
about the interaction of the destination limits and scheduling
algorithm. It works well on its own and there are no knobs they
would need to control it.
<blockquote>
<pre>
-first job-> 1--2--3--5--6--8--... <- job list
+first job-> 1--2--3--5--6--8--... <- job list
on job list |
- 4 <- preemption stack
+ 4 <- preemption stack
|
-current job-> 7
+current job-> 7
</pre>
</blockquote>
gone. That is, it must be possible to preempt any job on the job
list. For example, if the jobs 7, 4, 1 and 2 in the example above
become all blocked, job 3 becomes the current job. And of course
-we do not want the preemption be affected by the fact that there
+we do not want the preemption to be affected by the fact that there
are some blocked jobs or not. Therefore, if it turns out that job
3 might be preempted by job 6, the implementation shall make it
possible.
<pre>
v- parent
-adoptive parent -> 1--2--3--5--... <- "stack" level 0
+adoptive parent -> 1--2--3--5--... <- "stack" level 0
| |
-parent gone -> ? 6 <- "stack" level 1
+parent gone -> ? 6 <- "stack" level 1
/ \
-children -> 7 8 ^- child <- "stack" level 2
+children -> 7 8 ^- child <- "stack" level 2
^- siblings
</pre>
<blockquote>
<pre>
-7--8--1--2--6--3--5--.. <- scheduler's job list order
+7--8--1--2--6--3--5--.. <- scheduler's job list order
</pre>
</blockquote>
message reading code must support reading the recipients in batches,
which among other things means accessing the queue file several
times and continuing where the last recipient batch ended. This is
-invoked by the scheduler whenever the current job runs out of in-core
-recipients and more are required. It is also done any time when all
+invoked by the scheduler whenever the current job has space for more
+recipients, subject to transport's refill_limit and refill_delay parameters.
+It is also done any time when all
in-core recipients of the message are dealt with (which may also
mean they were deferred) but there are still more in the queue file.
what qmgr_message_recipient_minimum and qmgr_message_recipient_limit
values control. The qmgr_message_recipient_minimum value specifies
how many recipients of each message we will read for the first time,
-no matter what. It is necessary to read at least one recipients
+no matter what. It is necessary to read at least one recipient
before we can assign the message to a transport and create the first
job. However, reading only qmgr_message_recipient_minimum recipients
-even if there are only few messages with few messages in-core would
+even if there are only few messages with few recipients in-core would
be wasteful. Therefore if there is less than qmgr_message_recipient_limit
recipients in-core so far, the first batch of recipients may be
larger than qmgr_message_recipient_minimum - as large as is required
jobs were created, the size of the subsequent recipient batches (if
any - of course it's best when all recipients are read in one batch)
is based solely on the position of the message jobs on their
-corresponding transport's job lists. Each transport has a pool of
+corresponding transports' job lists. Each transport has a pool of
<i>transport</i>_recipient_limit recipient slots which it can
distribute among its jobs (how this is done is described later).
The subsequent recipient batch may be as large as the sum of all
Things work fine in such state for most of the time, because the
current job is either completely read in-core or has as much recipient
slots as there are, but there is one situation which we still have
-to take care specially. Imagine if the current job is preempted
+to take care of specially. Imagine if the current job is preempted
by some unread job from the job list and there are no more recipient
slots available, so this new current job could read only batches
of qmgr_message_recipient_minimum recipients at a time. This would
And that's it. It sure does sound pretty complicated, but fortunately
most people don't really have to care how exactly it works as long
as it works. Perhaps the only important things to know for most
-people ire the following upper bound formulas:
+people are the following upper bound formulas:
</p>
encryption_cipher=DHE-RSA-AES256-SHA
encryption_keysize=256
etrn_domain=
+<b>Postfix version 2.5 and later:</b>
+stress=
[empty line]
</pre>
</blockquote>
context of the ETRN command, and specifies the ETRN command
parameter. </p>
+ <li> <p> The "stress" attribute is either empty or "yes". See
+ the STRESS_README document for further information. </p>
+
</ul>
<p> The following is specific to SMTPD delegated policy requests:
useful for testing overrides on the SMTP service. Issue "postfix
reload" to make the change effective. </p>
+<p> Note: setting the stress parameter in main.cf has no effect for
+services that accept remote connections. </p>
+
<blockquote>
<pre>
1 /etc/postfix/master.cf:
</blockquote>
<p> To permanently force stress-adaptive behavior off with a specific
-service, specify "-o stress=" on its command line. This may be
-desirable for the "submission" service. Issue "postfix reload" to
-make the change effective. </p>
+service, specify "-o stress=" on its master.cf command line. This
+may be desirable for the "submission" service. Issue "postfix reload"
+to make the change effective. </p>
+
+<p> Note: setting the stress parameter in main.cf has no effect for
+services that accept remote connections. </p>
<blockquote>
<pre>
<li> <a href="#client_cipher">Client-side cipher controls </a>
+<li> <a href="#client_smtps">Client-side SMTPS support </a>
+
<li> <a href="#client_misc"> Miscellaneous client controls </a>
</ul>
</pre>
</blockquote>
+<h3> <a name="client_smtps">Client-side SMTPS support </a> </h3>
+
+<p> Although the Postfix SMTP client by itself doesn't support TLS
+wrapper mode, it is relatively easy to forward a connection through
+the stunnel program if Postfix needs to deliver mail to some legacy
+system that doesn't support STARTTLS. Use one of the following two
+examples, to send only some remote mail, or to send all remote mail,
+to an SMTPS server. </p>
+
+<h4> Sending all remote mail to an SMTPS server </h4>
+
+<p> The first example uses SMTPS to send all remote mail to a
+provider's mail server called "mail.example.com". </p>
+
+<p> A minimal stunnel.conf file is sufficient to set up a tunnel
+from local port 11125 to the remote destination "mail.example.com"
+and port "smtps". Postfix will later use this tunnel to connect to
+the remote server. </p>
+
+<blockquote>
+<pre>
+/path/to/stunnel.conf:
+ [smtp-tls-wrapper]
+ accept = 11125
+ client = yes
+ connect = mail.example.com:smtps
+</pre>
+</blockquote>
+
+<p> To test this tunnel, use: </p>
+
+<blockquote>
+<pre>
+$ telnet localhost 11125
+</pre>
+</blockquote>
+
+<p> This should produce the greeting from the remote SMTP server
+at mail.example.com. </p>
+
+<p> On the Postfix side, the relayhost feature sends all remote
+mail through the local stunnel listener on port 11125: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ relayhost = [127.0.0.1]:11125
+</pre>
+</blockquote>
+
+<p> Use "postfix reload" to make the change effective. </p>
+
+<h4> Sending only mail for a specific destination via SMTPS </h4>
+
+<p> The second example will use SMTPS to send only mail for
+"example.com" via SMTPS. It uses the same stunnel configuration
+file as the first example, so it won't be repeated here. </p>
+
+<p> This time, the Postfix side uses a transport map to direct only
+mail for "example.com" through the tunnel: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+/etc/postfix/transport:
+ example.com relay:[127.0.0.1]:11125
+</pre>
+</blockquote>
+
+<p> Use "postmap hash:/etc/postfix/transport" and "postfix reload"
+to make the change effective. </p>
+
<h3> <a name="client_misc"> Miscellaneous client controls </a> </h3>
<p> The smtp_starttls_timeout parameter limits the time of Postfix
<h2>Purpose of the XCLIENT extension to SMTP</h2>
-<p> The XCLIENT command targets the following problems: </p>
+<p> When an SMTP server announces support for the XCLIENT command,
+an SMTP client may send information that overrides one or more
+client-related session attributes. The XCLIENT command targets the
+following problems: </p>
<ol>
<h2>Purpose of the XFORWARD extension to SMTP</h2>
-<p> The XFORWARD command targets the following problem: </p>
+<p> When an SMTP server announces support for the XFORWARD command,
+an SMTP client may send information that overrides one or more
+client-related logging attributes. The XFORWARD command targets
+the following problem: </p>
<ul>
%PARAM allow_min_user no
<p>
-Allow a recipient address to have `-' as the first character. By
+Allow a sender or recipient address to have `-' as the first
+character. By
default, this is not allowed, to avoid accidents with software that
passes email addresses via the command line. Such software
would not be able to distinguish a malicious address from a
inserting a "--" option terminator into the command line, this is
difficult to enforce consistently and globally. </p>
+<p> As of Postfix version 2.5, this feature is implemented by
+trivial-rewrite(8). With earlier versions this feature was implemented
+by qmgr(8) and was limited to recipient addresses only. </p>
+
%PARAM allow_percent_hack yes
<p>
software. </p>
<p> This feature is available in Postfix 2.5 and later. </p>
+
+%PARAM stress
+
+<p> This feature is documented in the STRESS_README document. </p>
+
+<p> This feature is available in Postfix 2.5 and later. </p>
+
#define DEF_DEST_RATE_DELAY "0s"
extern int var_dest_rate_delay;
+ /*
+ * Stress handling.
+ */
+#define VAR_STRESS "stress"
+#define DEF_STRESS ""
+extern char *var_stress;
+
/* LICENSE
/* .ad
/* .fi
#define MAIL_ATTR_SASL_SENDER "sasl_sender"
#define MAIL_ATTR_ETRN_DOMAIN "etrn_domain"
#define MAIL_ATTR_DUMMY "dummy"
+#define MAIL_ATTR_STRESS "stress"
#define MAIL_ATTR_RWR_CONTEXT "rewrite_context"
#define MAIL_ATTR_RWR_LOCAL "local"
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20071208"
+#define MAIL_RELEASE_DATE "20071212"
#define MAIL_VERSION_NUMBER "2.5"
#ifdef SNAPSHOT
/* COMPATIBILITY CONTROLS
/* .ad
/* .fi
+/* Available before Postfix version 2.5:
/* .IP "\fBallow_min_user (no)\fR"
-/* Allow a recipient address to have `-' as the first character.
+/* Allow a sender or recipient address to have `-' as the first
+/* character.
/* ACTIVE QUEUE CONTROLS
/* .ad
/* .fi
int var_dest_con_limit;
int var_dest_rcpt_limit;
char *var_defer_xports;
-bool var_allow_min_user;
int var_qmgr_fudge;
int var_local_rcpt_lim; /* XXX */
int var_local_con_lim; /* XXX */
0,
};
static CONFIG_BOOL_TABLE bool_table[] = {
- VAR_ALLOW_MIN_USER, DEF_ALLOW_MIN_USER, &var_allow_min_user,
VAR_VERP_BOUNCE_OFF, DEF_VERP_BOUNCE_OFF, &var_verp_bounce_off,
VAR_CONC_FDBACK_DEBUG, DEF_CONC_FDBACK_DEBUG, &var_conc_feedback_debug,
0,
"5.1.3 null recipient address");
}
- /*
- * Bounce recipient addresses that start with `-'. External commands
- * may misinterpret such addresses as command-line options.
- *
- * In theory I could say people should always carefully set up their
- * master.cf pipe mailer entries with `--' before the first
- * non-option argument, but mistakes will happen regardless.
- *
- * Therefore the protection is put in place here, in the queue manager,
- * where it cannot be bypassed.
- */
- if (var_allow_min_user == 0 && recipient->address[0] == '-') {
- QMGR_REDIRECT(&reply, MAIL_SERVICE_ERROR,
- "5.1.3 bad address syntax");
- }
-
/*
* Discard mail to the local double bounce address here, so this
* system can run without a local delivery agent. They'd still have
/* .sp
/* This information is modified by the \fBhqu\fR flags for quoting
/* and case folding.
+/* .sp
+/* This feature is available in Postfix 2.5 and later.
/* .IP \fB${\fBrecipient\fR}\fR
/* This macro expands to the complete recipient address.
/* .sp
/* COMPATIBILITY CONTROLS
/* .ad
/* .fi
+/* Available before Postfix version 2.5:
/* .IP "\fBallow_min_user (no)\fR"
-/* Allow a recipient address to have `-' as the first character.
+/* Allow a sender or recipient address to have `-' as the first
+/* character.
/* ACTIVE QUEUE CONTROLS
/* .ad
/* .fi
int var_dest_con_limit;
int var_dest_rcpt_limit;
char *var_defer_xports;
-bool var_allow_min_user;
int var_local_con_lim;
int var_local_rcpt_lim;
int var_proc_limit;
0,
};
static CONFIG_BOOL_TABLE bool_table[] = {
- VAR_ALLOW_MIN_USER, DEF_ALLOW_MIN_USER, &var_allow_min_user,
VAR_VERP_BOUNCE_OFF, DEF_VERP_BOUNCE_OFF, &var_verp_bounce_off,
VAR_CONC_FDBACK_DEBUG, DEF_CONC_FDBACK_DEBUG, &var_conc_feedback_debug,
0,
"5.1.3 null recipient address");
}
- /*
- * Bounce recipient addresses that start with `-'. External commands
- * may misinterpret such addresses as command-line options.
- *
- * In theory I could say people should always carefully set up their
- * master.cf pipe mailer entries with `--' before the first
- * non-option argument, but mistakes will happen regardless.
- *
- * Therefore the protection is put in place here, in the queue manager,
- * where it cannot be bypassed.
- */
- if (var_allow_min_user == 0 && recipient->address[0] == '-') {
- QMGR_REDIRECT(&reply, MAIL_SERVICE_ERROR,
- "5.1.3 bad address syntax");
- }
-
/*
* Discard mail to the local double bounce address here, so this
* system can run without a local delivery agent. They'd still have
char *var_milt_eod_macros;
char *var_milt_unk_macros;
bool var_smtpd_client_port_log;
+char *var_stress;
/*
* Silly little macros.
VAR_MILT_DEF_ACTION, DEF_MILT_DEF_ACTION, &var_milt_def_action, 1, 0,
VAR_MILT_DAEMON_NAME, DEF_MILT_DAEMON_NAME, &var_milt_daemon_name, 1, 0,
VAR_MILT_V, DEF_MILT_V, &var_milt_v, 1, 0,
+ VAR_STRESS, DEF_STRESS, &var_stress, 0, 0,
0,
};
static CONFIG_RAW_TABLE raw_table[] = {
}
/*
- * BCC means deliver to designated recipient. But we may still
- * change our mind, and reject/discard the message for other reasons.
+ * BCC means deliver to designated recipient. But we may still change our
+ * mind, and reject/discard the message for other reasons.
*/
#ifdef SNAPSHOT
if (STREQUAL(value, "BCC", cmd_len)) {
state->act_size : state->msg_size),
ATTR_TYPE_STR, MAIL_ATTR_ETRN_DOMAIN,
state->etrn_name ? state->etrn_name : "",
+ ATTR_TYPE_STR, MAIL_ATTR_STRESS, var_stress,
#ifdef USE_SASL_AUTH
ATTR_TYPE_STR, MAIL_ATTR_SASL_METHOD,
var_smtpd_sasl_enable && state->sasl_method ?
*/
if (rp->snd_relay_info
&& (relay = mail_addr_find(rp->snd_relay_info, *sender ?
- sender : var_null_relay_maps_key,
+ sender : var_null_relay_maps_key,
(char **) 0)) != 0)
vstring_strcpy(nexthop, relay);
else if (*RES_PARAM_VALUE(rp->relayhost))
}
}
+ /*
+ * Bounce recipient addresses that start with `-'. External commands may
+ * misinterpret such addresses as command-line options.
+ *
+ * In theory I could say people should always carefully set up their
+ * master.cf pipe mailer entries with `--' before the first non-option
+ * argument, but mistakes will happen regardless.
+ *
+ * Therefore the protection is put in place here, where it cannot be
+ * bypassed.
+ */
+ if (var_allow_min_user == 0 && STR(nextrcpt)[0] == '-') {
+ *flags |= RESOLVE_FLAG_ERROR;
+ FREE_MEMORY_AND_RETURN;
+ }
+
/*
* Clean up.
*/
/* .IP "\fBresolve_numeric_domain (no)\fR"
/* Resolve "user@ipaddress" as "user@[ipaddress]", instead of
/* rejecting the address as invalid.
+/* .PP
+/* Available with Postfix version 2.5 and later:
+/* .IP "\fBallow_min_user (no)\fR"
+/* Allow a sender or recipient address to have `-' as the first
+/* character.
/* ADDRESS REWRITING CONTROLS
/* .ad
/* .fi
char *var_snd_relay_maps;
char *var_null_relay_maps_key;
int var_resolve_num_dom;
+bool var_allow_min_user;
/*
* Shadow personality for address verification.
VAR_SHOW_UNK_RCPT_TABLE, DEF_SHOW_UNK_RCPT_TABLE, &var_show_unk_rcpt_table,
VAR_RESOLVE_NULLDOM, DEF_RESOLVE_NULLDOM, &var_resolve_nulldom,
VAR_RESOLVE_NUM_DOM, DEF_RESOLVE_NUM_DOM, &var_resolve_num_dom,
+ VAR_ALLOW_MIN_USER, DEF_ALLOW_MIN_USER, &var_allow_min_user,
0,
};
static void vstream_buf_alloc(VBUF *bp, ssize_t len)
{
+ VSTREAM *stream = VBUF_TO_APPL(bp, VSTREAM, buf);
ssize_t used = bp->ptr - bp->data;
const char *myname = "vstream_buf_alloc";
bp->data = (unsigned char *)
(bp->data ? myrealloc((char *) bp->data, len) : mymalloc(len));
bp->len = len;
- if (bp->flags & VSTREAM_FLAG_READ)
+ if (bp->flags & VSTREAM_FLAG_READ) {
bp->ptr = bp->data + used;
- else
+ if (bp->flags & VSTREAM_FLAG_DOUBLE)
+ VSTREAM_SAVE_STATE(stream, read_buf, read_fd);
+ } else {
VSTREAM_BUF_AT_OFFSET(bp, used);
+ if (bp->flags & VSTREAM_FLAG_DOUBLE)
+ VSTREAM_SAVE_STATE(stream, write_buf, write_fd);
+ }
}
/* vstream_buf_wipe - reset buffer to initial state */
* allocation gives the application a chance to override the default
* buffering policy.
*/
- if (bp->data == 0) {
+ if (bp->data == 0)
vstream_buf_alloc(bp, VSTREAM_BUFSIZE);
- if (bp->flags & VSTREAM_FLAG_DOUBLE)
- VSTREAM_SAVE_STATE(stream, read_buf, read_fd);
- }
/*
* If the stream is double-buffered and the write buffer is not empty,
projects / thirdparty / postfix.git / commitdiff
