From: Wietse Venema Date: Wed, 12 Dec 2007 05:00:00 +0000 (-0500) Subject: postfix-2.5-20071212 X-Git-Tag: v2.5.0-RC1~14 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=15d69fcc386515554501cc3346a27cfae26e8684;p=thirdparty%2Fpostfix.git postfix-2.5-20071212 --- diff --git a/postfix/HISTORY b/postfix/HISTORY index 2dc23c275..db0082a90 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -13952,3 +13952,18 @@ Apologies for any names omitted. 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. diff --git a/postfix/README_FILES/SCHEDULER_README b/postfix/README_FILES/SCHEDULER_README index 764f9061f..4d544248e 100644 --- a/postfix/README_FILES/SCHEDULER_README +++ b/postfix/README_FILES/SCHEDULER_README @@ -448,7 +448,7 @@ Postfix versions. PPrreeeemmppttiivvee sscchheedduulliinngg -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 @@ -541,7 +541,7 @@ from the resolved triple to the recipient entry which is appended 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 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 @@ -601,7 +601,7 @@ with, while the other one keeps the jobs always listed in the order of the 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, @@ -616,13 +616,13 @@ The nqmgr's answer is that we can artificially "inflate" the delivery time of 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 @@ -640,15 +640,15 @@ mail with say ten recipients. But there are no free slots anymore, so it can't 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 . @@ -657,7 +657,7 @@ Let's get back to the one hundred recipient example. We now know that we could 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? @@ -703,7 +703,7 @@ delivery slots. It might have already accumulated some, and perhaps even 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 @@ -742,15 +742,15 @@ nothing happens and the another preemption is attempted the next time. But 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 @@ -768,10 +768,9 @@ chapter couple more times. You shall clearly see the job list and the 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.] HHooww ddeessttiinnaattiioonn ccoonnccuurrrreennccyy lliimmiittss aaffffeecctt tthhee sscchheedduulliinngg aallggoorriitthhmm @@ -791,7 +790,7 @@ is, the delivery agent handling the delivery of the recipient entry for given 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. @@ -839,7 +838,7 @@ become normal job again at any time. This has several important implications: 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. @@ -931,9 +930,10 @@ The recipient limit complicates more things. First of all, the 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 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 @@ -988,10 +988,10 @@ Now how many recipients shall we read for the first time? This is 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 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. @@ -999,7 +999,7 @@ 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 @@ -1065,9 +1065,9 @@ core). 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 @@ -1076,7 +1076,7 @@ the remaining recipient slots from the normal pool and this extra pool. 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 diff --git a/postfix/README_FILES/SMTPD_POLICY_README b/postfix/README_FILES/SMTPD_POLICY_README index 8182b6e0a..fe7f1b49b 100644 --- a/postfix/README_FILES/SMTPD_POLICY_README +++ b/postfix/README_FILES/SMTPD_POLICY_README @@ -69,6 +69,8 @@ a delegated SMTPD access policy request: encryption_cipher=DHE-RSA-AES256-SHA encryption_keysize=256 etrn_domain= + PPoossttffiixx vveerrssiioonn 22..55 aanndd llaatteerr:: + stress= [empty line] Notes: @@ -129,6 +131,9 @@ 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. diff --git a/postfix/README_FILES/STRESS_README b/postfix/README_FILES/STRESS_README index b66be0224..bcd5ffc83 100644 --- a/postfix/README_FILES/STRESS_README +++ b/postfix/README_FILES/STRESS_README @@ -316,6 +316,9 @@ You can manually force stress-adaptive behavior on, by adding a "-o stress=yes" 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 @@ -326,8 +329,11 @@ the SMTP service. Issue "postfix reload" to make the change effective. 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 # ============================================================= diff --git a/postfix/README_FILES/TLS_README b/postfix/README_FILES/TLS_README index 3d6c6e021..7c5011927 100644 --- a/postfix/README_FILES/TLS_README +++ b/postfix/README_FILES/TLS_README @@ -587,6 +587,7 @@ Topics covered in this section: * Discovering servers that support TLS * Server certificate verification depth * Client-side cipher controls + * Client-side SMTPS support * Miscellaneous client controls TTLLSS ssuuppppoorrtt iinn tthhee LLMMTTPP ddeelliivveerryy aaggeenntt @@ -1544,6 +1545,62 @@ Example: smtp_tls_mandatory_exclude_ciphers = RC4, MD5 smtp_tls_exclude_ciphers = aNULL +CClliieenntt--ssiiddee SSMMTTPPSS ssuuppppoorrtt + +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. + +SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aann SSMMTTPPSS sseerrvveerr + +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. + +SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn vviiaa SSMMTTPPSS + +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. + MMiisscceellllaanneeoouuss cclliieenntt ccoonnttrroollss The smtp_starttls_timeout parameter limits the time of Postfix SMTP client diff --git a/postfix/README_FILES/XCLIENT_README b/postfix/README_FILES/XCLIENT_README index d3ca8daac..e524e82bf 100644 --- a/postfix/README_FILES/XCLIENT_README +++ b/postfix/README_FILES/XCLIENT_README @@ -4,7 +4,9 @@ PPoossttffiixx XXCCLLIIEENNTT HHoowwttoo PPuurrppoossee ooff tthhee XXCCLLIIEENNTT eexxtteennssiioonn ttoo SSMMTTPP -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 diff --git a/postfix/README_FILES/XFORWARD_README b/postfix/README_FILES/XFORWARD_README index bd0751273..a9ff30b55 100644 --- a/postfix/README_FILES/XFORWARD_README +++ b/postfix/README_FILES/XFORWARD_README @@ -4,7 +4,9 @@ PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP -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 diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES index 621020261..c87cf65cc 100644 --- a/postfix/RELEASE_NOTES +++ b/postfix/RELEASE_NOTES @@ -17,6 +17,15 @@ Incompatibility with Postfix 2.3 and earlier 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 ============================================== diff --git a/postfix/html/SCHEDULER_README.html b/postfix/html/SCHEDULER_README.html index e21fdf307..8f5f75680 100644 --- a/postfix/html/SCHEDULER_README.html +++ b/postfix/html/SCHEDULER_README.html @@ -221,35 +221,35 @@ Initialization: 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 @@ -644,7 +644,7 @@ activity

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 nqmgr, the name it was known by before it became the default queue manager) and the old queue manager @@ -796,7 +796,7 @@ from the resolved triple to the recipient entry which is appended 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 oqmgr.

@@ -846,7 +846,7 @@ do 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 @@ -906,7 +906,7 @@ the scheduler's job list only.

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 @@ -926,7 +926,7 @@ the delivery time of 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 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 @@ -965,7 +965,7 @@ hundred-recipient mail is delivered, which really sucks.

-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 nqmgr really use the free slots? @@ -978,7 +978,7 @@ 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 +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 . @@ -992,7 +992,7 @@ that we could 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... +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? @@ -1068,7 +1068,7 @@ and perhaps even 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 +job which may be delivered by less than that amount of slots is a valid candidate for preemption. How do we choose among them?

@@ -1132,12 +1132,12 @@ is attempted the next time. But 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 +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 +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 @@ -1148,7 +1148,7 @@ 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_discount and transport_delivery_slot_loan come from (they default to default_delivery_slot_discount and default_delivery_slot_loan, whose values are by default 50 and 3, respectively). The discount (resp. @@ -1174,8 +1174,8 @@ see the job list and the 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 +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.] @@ -1213,7 +1213,7 @@ in all further scheduler actions normally.

-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. @@ -1241,11 +1241,11 @@ blockers would be like this: 

-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
@@ -1304,7 +1304,7 @@ 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 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. @@ -1348,11 +1348,11 @@ If I illustrate the relations after the above mentioned examples 
                             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
@@ -1378,7 +1378,7 @@ as simple as this: 
-7--8--1--2--6--3--5--..   <- scheduler's job list order
+7--8--1--2--6--3--5--..   <- scheduler's job list order
@@ -1470,8 +1470,9 @@ The recipient limit complicates more things. First of all, the 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. @@ -1564,10 +1565,10 @@ Now how many recipients shall we read for the first time? This is 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 @@ -1581,7 +1582,7 @@ 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 transport has a pool of +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 @@ -1683,7 +1684,7 @@ slots as they have recipients in-core). 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 @@ -1700,7 +1701,7 @@ slots from the normal pool and this extra pool. 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:

diff --git a/postfix/html/SMTPD_POLICY_README.html b/postfix/html/SMTPD_POLICY_README.html index ee8d8cc79..08704aa8e 100644 --- a/postfix/html/SMTPD_POLICY_README.html +++ b/postfix/html/SMTPD_POLICY_README.html @@ -100,6 +100,8 @@ encryption_protocol=TLSv1/SSLv3 encryption_cipher=DHE-RSA-AES256-SHA encryption_keysize=256 etrn_domain= +Postfix version 2.5 and later: +stress= [empty line] @@ -178,6 +180,9 @@ etrn_domain= 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: diff --git a/postfix/html/STRESS_README.html b/postfix/html/STRESS_README.html index b63ebd23d..61a0e7032 100644 --- a/postfix/html/STRESS_README.html +++ b/postfix/html/STRESS_README.html @@ -420,6 +420,9 @@ a "-o stress=yes" command-line option in master.cf. 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:
@@ -434,9 +437,12 @@ reload" to make the change effective.

    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.

    +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.

    + +

    Note: setting the stress parameter in main.cf has no effect for +services that accept remote connections. 

    diff --git a/postfix/html/TLS_README.html b/postfix/html/TLS_README.html
index a32f13299..81965f443 100644
--- a/postfix/html/TLS_README.html
+++ b/postfix/html/TLS_README.html
@@ -857,6 +857,8 @@ key configuration 
 
 
  •  Client-side cipher controls 
 
+
  •  Client-side SMTPS support 
+
 
  •   Miscellaneous client controls 
 
 
@@ -2085,6 +2087,80 @@ little point in requesting them.
    • +

    Client-side SMTPS support

    + +

    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.

    + +

    Sending all remote mail to an SMTPS server

    + +

    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.

    + +

    Sending only mail for a specific destination via SMTPS

    + +

    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.

    +

    Miscellaneous client controls

    The smtp_starttls_timeout parameter limits the time of Postfix diff --git a/postfix/html/XCLIENT_README.html b/postfix/html/XCLIENT_README.html index c66093482..7b1f278ea 100644 --- a/postfix/html/XCLIENT_README.html +++ b/postfix/html/XCLIENT_README.html @@ -19,7 +19,10 @@

    Purpose of the XCLIENT extension to SMTP

    -

    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:

      diff --git a/postfix/html/XFORWARD_README.html b/postfix/html/XFORWARD_README.html index 10eaf96ee..656e0d8da 100644 --- a/postfix/html/XFORWARD_README.html +++ b/postfix/html/XFORWARD_README.html @@ -19,7 +19,10 @@

      Purpose of the XFORWARD extension to SMTP

      -

      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:

      The following is specific to SMTPD delegated policy requests: diff --git a/postfix/proto/STRESS_README.html b/postfix/proto/STRESS_README.html index a313a0d7e..9d29979d4 100644 --- a/postfix/proto/STRESS_README.html +++ b/postfix/proto/STRESS_README.html @@ -420,6 +420,9 @@ a "-o stress=yes" 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:
@@ -434,9 +437,12 @@ reload" to make the change effective.

      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.

      +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.

      + +

      Note: setting the stress parameter in main.cf has no effect for +services that accept remote connections. 

      diff --git a/postfix/proto/TLS_README.html b/postfix/proto/TLS_README.html
index fcd6c6bfc..5ee992597 100644
--- a/postfix/proto/TLS_README.html
+++ b/postfix/proto/TLS_README.html
@@ -857,6 +857,8 @@ key configuration 
 
 
    1.  Client-side cipher controls 
 
+
    2.  Client-side SMTPS support 
+
 
    3.   Miscellaneous client controls 
 
 
@@ -2085,6 +2087,80 @@ little point in requesting them.
      4. +

      Client-side SMTPS support

      + +

      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.

      + +

      Sending all remote mail to an SMTPS server

      + +

      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.

      + +

      Sending only mail for a specific destination via SMTPS

      + +

      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.

      +

      Miscellaneous client controls

      The smtp_starttls_timeout parameter limits the time of Postfix diff --git a/postfix/proto/XCLIENT_README.html b/postfix/proto/XCLIENT_README.html index cfa385285..97692c0db 100644 --- a/postfix/proto/XCLIENT_README.html +++ b/postfix/proto/XCLIENT_README.html @@ -19,7 +19,10 @@

      Purpose of the XCLIENT extension to SMTP

      -

      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:

        diff --git a/postfix/proto/XFORWARD_README.html b/postfix/proto/XFORWARD_README.html index 7af960cc0..46dcdac12 100644 --- a/postfix/proto/XFORWARD_README.html +++ b/postfix/proto/XFORWARD_README.html @@ -19,7 +19,10 @@

        Purpose of the XFORWARD extension to SMTP

        -

        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:

          diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto index 09d39dca3..9902af955 100644 --- a/postfix/proto/postconf.proto +++ b/postfix/proto/postconf.proto @@ -506,7 +506,8 @@ allow_mail_to_files = alias,forward,include %PARAM allow_min_user 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 @@ -514,6 +515,10 @@ 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.

          +

          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.

          + %PARAM allow_percent_hack yes

          @@ -11070,3 +11075,10 @@ the mail_owner account, and must not be shared with non-Postfix software.

          This feature is available in Postfix 2.5 and later.

          + +%PARAM stress + +

          This feature is documented in the STRESS_README document.

          + +

          This feature is available in Postfix 2.5 and later.

          + diff --git a/postfix/src/global/mail_params.h b/postfix/src/global/mail_params.h index 5cfaa1307..88fb115d4 100644 --- a/postfix/src/global/mail_params.h +++ b/postfix/src/global/mail_params.h @@ -2879,6 +2879,13 @@ extern bool var_conc_feedback_debug; #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 diff --git a/postfix/src/global/mail_proto.h b/postfix/src/global/mail_proto.h index 71b5779ef..4f92c15e5 100644 --- a/postfix/src/global/mail_proto.h +++ b/postfix/src/global/mail_proto.h @@ -128,6 +128,7 @@ extern char *mail_pathname(const char *, const char *); #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" diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h index fb91cb4e1..dc2237de6 100644 --- a/postfix/src/global/mail_version.h +++ b/postfix/src/global/mail_version.h @@ -20,7 +20,7 @@ * 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 diff --git a/postfix/src/oqmgr/qmgr.c b/postfix/src/oqmgr/qmgr.c index fcc95a2f5..875ae625f 100644 --- a/postfix/src/oqmgr/qmgr.c +++ b/postfix/src/oqmgr/qmgr.c @@ -153,8 +153,10 @@ /* 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 @@ -359,7 +361,6 @@ int var_transport_retry_time; 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 */ @@ -627,7 +628,6 @@ int main(int argc, char **argv) 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, diff --git a/postfix/src/oqmgr/qmgr_message.c b/postfix/src/oqmgr/qmgr_message.c index f5fdd4a03..a68cc9ea0 100644 --- a/postfix/src/oqmgr/qmgr_message.c +++ b/postfix/src/oqmgr/qmgr_message.c @@ -1010,22 +1010,6 @@ static void qmgr_message_resolve(QMGR_MESSAGE *message) "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 diff --git a/postfix/src/pipe/pipe.c b/postfix/src/pipe/pipe.c index e8fd4702e..1a699c126 100644 --- a/postfix/src/pipe/pipe.c +++ b/postfix/src/pipe/pipe.c @@ -257,6 +257,8 @@ /* .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 diff --git a/postfix/src/qmgr/qmgr.c b/postfix/src/qmgr/qmgr.c index 37fcc949b..99d0c6425 100644 --- a/postfix/src/qmgr/qmgr.c +++ b/postfix/src/qmgr/qmgr.c @@ -157,8 +157,10 @@ /* 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 @@ -420,7 +422,6 @@ int var_transport_retry_time; 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; @@ -702,7 +703,6 @@ int main(int argc, char **argv) 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, diff --git a/postfix/src/qmgr/qmgr_message.c b/postfix/src/qmgr/qmgr_message.c index 93cdc096d..f2ad51e7b 100644 --- a/postfix/src/qmgr/qmgr_message.c +++ b/postfix/src/qmgr/qmgr_message.c @@ -1069,22 +1069,6 @@ static void qmgr_message_resolve(QMGR_MESSAGE *message) "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 diff --git a/postfix/src/smtpd/smtpd.c b/postfix/src/smtpd/smtpd.c index 58a1f3b17..919af0ac9 100644 --- a/postfix/src/smtpd/smtpd.c +++ b/postfix/src/smtpd/smtpd.c @@ -1130,6 +1130,7 @@ char *var_milt_data_macros; char *var_milt_eod_macros; char *var_milt_unk_macros; bool var_smtpd_client_port_log; +char *var_stress; /* * Silly little macros. @@ -4729,6 +4730,7 @@ int main(int argc, char **argv) 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[] = { diff --git a/postfix/src/smtpd/smtpd_check.c b/postfix/src/smtpd/smtpd_check.c index ec9d7a911..81839bd39 100644 --- a/postfix/src/smtpd/smtpd_check.c +++ b/postfix/src/smtpd/smtpd_check.c @@ -2100,8 +2100,8 @@ static int check_table_result(SMTPD_STATE *state, const char *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)) { @@ -3366,6 +3366,7 @@ static int check_policy_service(SMTPD_STATE *state, const char *server, 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 ? diff --git a/postfix/src/trivial-rewrite/resolve.c b/postfix/src/trivial-rewrite/resolve.c index 92a3c173d..61f5bf7ea 100644 --- a/postfix/src/trivial-rewrite/resolve.c +++ b/postfix/src/trivial-rewrite/resolve.c @@ -509,7 +509,7 @@ static void resolve_addr(RES_CONTEXT *rp, char *sender, char *addr, */ 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)) @@ -630,6 +630,22 @@ static void resolve_addr(RES_CONTEXT *rp, char *sender, char *addr, } } + /* + * 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. */ diff --git a/postfix/src/trivial-rewrite/trivial-rewrite.c b/postfix/src/trivial-rewrite/trivial-rewrite.c index df27615a1..5ce2ca8b3 100644 --- a/postfix/src/trivial-rewrite/trivial-rewrite.c +++ b/postfix/src/trivial-rewrite/trivial-rewrite.c @@ -90,6 +90,11 @@ /* .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 @@ -322,6 +327,7 @@ char *var_remote_rwr_domain; 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. @@ -576,6 +582,7 @@ int main(int argc, char **argv) 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, }; diff --git a/postfix/src/util/vstream.c b/postfix/src/util/vstream.c index 361421fbc..970beba62 100644 --- a/postfix/src/util/vstream.c +++ b/postfix/src/util/vstream.c @@ -511,6 +511,7 @@ static void vstream_buf_init(VBUF *bp, int flags) 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"; @@ -526,10 +527,15 @@ static void vstream_buf_alloc(VBUF *bp, ssize_t len) 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 */ @@ -697,11 +703,8 @@ static int vstream_buf_get_ready(VBUF *bp) * 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,