mir/postfix
2
0
Fork 0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-22 09:57:34 +00:00
Code Issues Releases Wiki Activity

postfix-2.8-20100203

Browse Source
This commit is contained in:
Wietse Venema 2010-02-03 00:00:00 -05:00 committed by Viktor Dukhovni
parent cee08cce6c
commit 49524057e9
42 changed files with 6248 additions and 2464 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
postfix/HISTORY
View File

@ -15675,3 +15675,37 @@ Apologies for any names omitted.
with Postfix 2.6 and earlier, or specify a non-empty next-hop
filter destination. Files: *qmgr/qmgr_message.c proto/access,
proto/header_checks, proto/postconf.proto, proto/FILTER_README.
20100120
Cleanup: detect illegal pipelining after HELO, EHLO. File:
smtpd/smtpd.c.
20100128
Documentation: streamlined the decriptions of protocol and
cipher tweaks. Victor Duchovni. Files: proto/TLS_README,
proto/postconf.proto.
20100131
Documentation: the address verification database is now
persistent by default. This, combined with the now default
stress-dependent configuration, improves the performance
limits and simplifies database maintenance. Files:
proto/ADDRESS_VERIFICATION_README, verify/verify.c.
Cleanup: undo the proxymap and trivial-rewrite max_idle=1s
override that was introduced with Postfix 2.3. It did not
help to retire long-lived proxymap or trivial-rewrite
processes on busy servers, and worsened performance on
low-traffic servers. The reduced ipc_ttl value (introduced
with Postfix 2.4) already solves the problem of retiring
long-lived proxymap or trivial-rewrite processes. Files:
proxymap/proxymap.c, trivial-rewrite/trivial-rewrite.c.
20100202
Documentation: major revision of SASL_README with many
details on how to configure Cyrus SASL internals. Patrick
Koetter. File: proto/SASL_README.html

95
postfix/README_FILES/ADDRESS_VERIFICATION_README
View File

@ -4,10 +4,10 @@ PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn
WWAARRNNIINNGG
The sender/recipient address verification feature described in this document is
suitable only for low-traffic sites. It performs poorly under high load;
excessive sender address verification activity may even cause your site to be
blacklisted by some providers. See the "Limitations" section below for details.
Recipient address verification may cause an increased load on down-stream
servers in the case of a dictionary attack or a flood of backscatter bounces.
Sender address verification may cause your site to be blacklisted by some
providers. See also the "Limitations" section below for more.
WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
@ -18,8 +18,8 @@ verified to be deliverable.
The technique has obvious uses to reject junk mail with an unreplyable sender
address.
The technique may also be useful to block mail for undeliverable recipients,
for example on a mail relay host that does not have a list of all the valid
The technique is also useful to block mail for undeliverable recipients, for
example on a mail relay host that does not have a list of all the valid
recipient addresses. This prevents undeliverable junk mail from entering the
queue, so that Postfix doesn't have to waste resources trying to send MAILER-
DAEMON messages back.
@ -47,18 +47,26 @@ the Postfix MTA itself, or it could be a remote MTA (SMTP interruptus). Probe
messages are like normal mail, except that they are never delivered, deferred
or bounced; probe messages are always discarded.
Postfix Postfix Address
Internet -> SMTP <-> verify <-> verification
server server database
| ^
probe delivery
messages status
v |
probe Postfix
message -> mail
queue
Postfix Postfix ->
Internet -> SMTP <-> verify
server server |
v
Postfix Postfix
queue -> delivery
agents
<- Postfix
probe <- delivery -> Local
status agents -> Remote
^
|
v
Address
verification
database
With Postfix address verification turned on, normal mail will suffer only a
short delay of up to 6 seconds while an address is being verified for the first
@ -77,7 +85,8 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi
address, without actually delivering mail to it. If the nearest MTA accepts
the address, then Postfix assumes that the address is deliverable. In
reality, mail for a remote address can bounce AFTER the nearest MTA accepts
the recipient address.
the recipient address, or AFTER the nearest MTA accepts the message
content.
* Some sites may blacklist you when you are probing them too often (a probe
is an SMTP session that does not deliver mail), or when you are probing
@ -95,30 +104,31 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi
* Postfix assumes that an address is undeliverable when the nearest MTA for
the address rejects the probe, regardless of the reason for rejection
(client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix
rejects mail when the sender's MTA rejects mail from your machine. This is
a good thing.
rejects an address when the nearest MTA for that address rejects mail from
your machine for any reason. This is not a limitation, but it is mentioned
here just in case people believe that it is a limitation.
* Unfortunately, some major sites such as YAHOO do not reject unknown
addresses in reply to the RCPT TO command, but report a delivery failure in
response to end of DATA after a message is transferred. Postfix address
verification does not work with such sites.
* Unfortunately, some sites do not reject unknown addresses in reply to the
RCPT TO command, but report a delivery failure in response to end of DATA
after a message is transferred. Postfix address verification does not work
with such sites.
* By default, Postfix probe messages have "double-bounce@$myorigin" as the
sender address (with Postfix versions before 2.5, the default is
* By default, Postfix probe messages have a sender address "double-
bounce@$myorigin" (with Postfix versions before 2.5, the default is
"postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does
not reject mail for this address.
You can change this into the null address ("address_verify_sender ="). This
is UNSAFE because address probes will fail with mis-configured sites that
reject MAIL FROM: <>, while probes from "postmaster@$myorigin" would
succeed.
You can change the probe sender address into the null address
("address_verify_sender ="). This is UNSAFE because address probes will
fail with mis-configured sites that reject MAIL FROM: <>, while probes from
"postmaster@$myorigin" would succeed.
RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn
As mentioned earlier, recipient address verification may be useful to block
mail for undeliverable recipients on a mail relay host that does not have a
list of all valid recipient addresses. This can help to prevent the mail queue
from filling up with MAILER-DAEMON messages.
As mentioned earlier, recipient address verification is useful to block mail
for undeliverable recipients on a mail relay host that does not have a list of
all valid recipient addresses. This can help to prevent the mail queue from
filling up with MAILER-DAEMON messages.
Recipient address verification is relatively straightforward and there are no
surprises. If a recipient probe fails, then Postfix rejects mail for the
@ -127,9 +137,10 @@ the recipient address. However, recipient address verification probes can
increase the load on down-stream MTAs when you're being flooded by backscatter
bounces, or when some spammer is mounting a dictionary attack.
By default, address verification results are not saved. To avoid probing the
same address repeatedly, you can store the result in a persistent database as
described later.
By default, address verification results are saved in a persistent database
(Postfix version 2.7 and later; with earlier versions, specify the database in
main.cf as described later). The persistent database helps to avoid probing the
same address repeatedly.
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
@ -177,11 +188,13 @@ verification for specific domains that often appear in forged email.
# Postfix 2.6 and later.
# unverified_sender_defer_code = 250
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "Caching" section below!
# Note 2: Avoid hash files here. Use btree instead.
address_verify_map = btree:/var/lib/postfix/verify
/etc/postfix/sender_access:
# Don't do this when you handle lots of email.
aol.com reject_unverified_sender
hotmail.com reject_unverified_sender
bigfoot.com reject_unverified_sender
@ -216,6 +229,7 @@ be blocked:
# Postfix 2.6 and later.
# unverified_sender_reject_reason = Address verification failed
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "Caching" section below!
# Note 2: Avoid hash files here. Use btree instead.
address_verify_map = btree:/var/lib/postfix/verify
@ -262,10 +276,11 @@ probe fails with some temporary error.
AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
To improve performance, the Postfix verify(8) daemon can save address
verification results to a persistent database. The address_verify_map (NOTE:
singular) configuration parameter specifies persistent storage for sender or
recipient address verification results. If you specify an empty value, all
address verification results are lost after "postfix reload" or "postfix stop".
verification results to a persistent database. This is enabled by default with
Postfix 2.7 and later. The address_verify_map (NOTE: singular) configuration
parameter specifies persistent storage for sender or recipient address
verification results. If you specify an empty value, all address verification
results are lost after "postfix reload" or "postfix stop".
/etc/postfix/main.cf:
# Default setting for Postfix 2.7 and later.

57
postfix/README_FILES/OVERVIEW
View File

@ -336,19 +336,60 @@ queues.
* The verify(8) server verifies that a sender or recipient address is
deliverable before the smtpd(8) server accepts it. The verify(8) server
injects probe messages into the Postfix queue and processes status updates
from delivery agents and/or queue manager. This process is described in the
ADDRESS_VERIFICATION_README document. The verify(8) service is available
with Postfix version 2.1 and later.
queries a cache with address verification results. If a result is not
found, the verify(8) server injects a probe message into the Postfix queue
and processes the status update from a delivery agent or queue manager.
This process is described in the ADDRESS_VERIFICATION_README document. The
verify(8) service is available with Postfix version 2.1 and later.
qmgr(8) Delivery
Network -> smtpd(8) <-> verify(8) -> cleanup(8) -> Postfix -> agents
probe Postfix
message -> mail
queue
Network -> smtpd(8) <-> verify(8) ->
\ | /
|
v
<- probe Postfix -> Local
status <- delivery -> Network
^ agents
|
v
Address
verification
cache
* The postscreen(8) server can be put "in front" of Postfix smtpd(8)
processes. Its purpose is to accept connections from the network and to
decide what SMTP clients are allowed to talk to Postfix. According to the
2008 MessageLabs annual report, 81% of all email was spam, and 90% of that
was sent by botnets. While postscreen(8) keeps the zombies away, more smtpd
(8) processes remain available for legitimate clients.
The postscreen(8) server is still evolving, and is likely to undergo
changes that break compatibility with earlier versions. For this reason the
postscreen(8) server is not installed with the stable Postfix release.
zombie
\
zombie - - smtpd(8)
\ /
<- <-
other --- postscreen(8)
/ \
other - - smtpd(8)
/
zombie
PPoossttffiixx ssuuppppoorrtt ccoommmmaannddss

1560
postfix/README_FILES/SASL_README
View File

File diff suppressed because it is too large Load Diff

162
postfix/README_FILES/SOHO_README
View File

@ -19,7 +19,7 @@ outside the scope of the Postfix documentation.
Selected topics from the SASL_README document:
o Enabling SASL authentication in the Postfix SMTP client
o Supporting multiple ISP accounts in the Postfix SMTP client
o Configuring Sender-Dependent SASL authentication
See the SASL_README and STANDARD_CONFIGURATION_README documents for further
information on these topics.
@ -149,128 +149,122 @@ canonical table.
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
virtual table.
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
Turn on client-side SASL authentication, and specify a table with per-host or
per-destination username and password information. The Postfix SMTP client
first searches the table for an entry with the remote SMTP server hostname; if
no entry is found, then the Postfix SMTP client searches the table for an entry
with the next-hop destination. Usually, that is the right-hand part of an email
address, but it can also be the information that is specified with the
relayhost parameter or with a transport(5) table.
This section shows a typical scenario where the Postfix SMTP client sends all
messages via a mail gateway server that requires SASL authentication. To make
the example more readable we introduce it in two parts.
/etc/postfix/main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_type = cyrus
relayhost = [mail.myisp.net]
relayhost = [mail.isp.example]
# Alternative form:
# relayhost = [mail.myisp.net]:submission
# relayhost = [mail.isp.example]:submission
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
* The smtp_sasl_auth_enable setting enables client-side authentication. We
will configure the client's username and password information in the second
part of the example.
* The relayhost setting forces the Postfix SMTP to send all remote messages
to the specified mail server instead of trying to deliver them directly to
their destination.
* In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
from looking up MX (mail exchanger) records for the enclosed name.
* The relayhost destination may also specify a non-default TCP port. For
example, the alternative form [mail.isp.example]:submission tells Postfix
to connect to TCP network port 587, which is reserved for email client
applications.
* The Postfix SMTP client is compatible with SMTP servers that use the non-
standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
requires no additional Postfix client configuration.
* The Postfix SMTP client does not support the obsolete "wrappermode"
protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a
solution that uses the stunnel command.
* With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
client to send username and password information to the mail gateway
server. As discussed in the next section, the Postfix SMTP client supports
multiple ISP accounts. For this reason the username and password are stored
in a table that contains one username/password combination for each mail
gateway server.
/etc/postfix/sasl_passwd:
[mail.myisp.net] username:password
[mail.myisp.net]:submission username:password
# destination credentials
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
Notes:
IImmppoorrttaanntt
* The "submission" destination port tells Postfix to send mail via TCP
network port 587, which is normally reserved for email clients. The default
is to send mail to the "smtp" destination port (TCP port 25), which is used
for receiving mail across the internet. If you use an explicit destination
port in main.cf, then you must use the same form also in the
Keep the SASL client password file in /etc/postfix, and make the file
read+write only for root to protect the username/password combinations
against other users. The Postfix SMTP client will still be able to read the
SASL client passwords. It opens the file as user root before it drops
privileges, and before entering an optional chroot jail.
* Use the postmap command whenever you change the /etc/postfix/sasl_passwd
file.
* If you specify the "[" and "]" in the relayhost destination, then you must
use the same form in the smtp_sasl_password_maps file.
* If you specify a non-default TCP Port (such as ":submission" or ":587") in
the relayhost destination, then you must use the same form in the
smtp_sasl_password_maps file.
* Postfix does not deliver mail via TCP port 465 (the obsolete "wrappermode"
protocol). See TLS_README for a solution that uses the "stunnel" command.
CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
* The "[" and "]" prevent Postfix from looking up the MX (mail exchanger)
records for the enclosed name. If you use this form in main.cf, then you
must use the same form also in the smtp_sasl_password_maps file.
Postfix supports different ISP accounts for different sender addresses (version
2.3 and later). This can be useful when one person uses the same machine for
work and for personal use, or when people with different ISP accounts share the
same Postfix server.
* The Postfix SMTP client opens the SASL client password file before entering
the optional chroot jail, so you can keep the file in /etc/postfix and set
permissions read / write only for root to keep the username:password
combinations away from other system users.
* Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
files. To find out what lookup tables Postfix supports, use the command
"ppoossttccoonnff --mm".
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
the sasl_passwd table.
Workarounds:
* Some remote SMTP servers support PLAIN or LOGIN authentication only. By
default, the Postfix SMTP client does not use authentication methods that
send plaintext passwords, and defers delivery with the following error
message: "Authentication failed: cannot SASL authenticate to server". To
enable plaintext authentication specify, for example:
/etc/postfix/main.cf:
smtp_sasl_security_options = noanonymous
* Some remote SMTP servers announce authentication mechanisms that don't
actually work. It is possible via the smtp_sasl_mechanism_filter parameter
to restrict the list of server mechanisms that the Postfix SMTP client will
take into consideration:
/etc/postfix/main.cf:
smtp_sasl_mechanism_filter = !gssapi, !external, static:all
In the above example, the Postfix SMTP client will decline to use
mechanisms that require special infrastructure such as Kerberos or TLS.
* The Postfix SMTP client is backwards compatible with SMTP servers that use
the non-standard "AUTH=method..." syntax in response to the EHLO command;
there is no Postfix client configuration needed to work around it.
SSuuppppoorrttiinngg mmuullttiippllee IISSPP aaccccoouunnttss iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt
Postfix version 2.3 supports multiple ISP accounts. This can be useful when one
person uses the same machine for work and for personal use, or when people with
different ISP accounts share the same Postfix server. To make this possible,
Postfix 2.3 supports per-sender SASL passwords and per-sender relay hosts. In
the example below, Postfix will search the SASL password file by sender before
it searches that same file by destination. Likewise, Postfix will search the
per-sender relayhost file, and use the default relayhost only as a final
resort.
To make this possible, Postfix supports per-sender SASL passwords and per-
sender relay hosts. In the example below, the Postfix SMTP client will search
the SASL password file by sender address before it searches that same file by
destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
per-sender relayhost file, and use the default relayhost setting only as a
final resort.
/etc/postfix/main.cf:
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = [mail.myisp.net]
relayhost = [mail.isp.example]
# Alternative form:
# relayhost = [mail.myisp.net]:submission
# relayhost = [mail.isp.example]:submission
/etc/postfix/sasl_passwd:
# Per-sender authentication; see also /etc/postfix/sender_relay.
user1@example.com username2:password2
user2@example.net username2:password2
# Login information for the default relayhost.
[mail.myisp.net] username:password
[mail.myisp.net]:submission username:password
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
/etc/postfix/sender_relay:
# Per-sender provider; see also /etc/postfix/sasl_passwd.
user1@example.com [mail.example.com]:submission
user2@example.net [mail.example.net]
Notes:
* If you are creative, then you can try to combine the two tables into one
single MySQL database, and configure different Postfix queries to extract
the appropriate information.
* Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
* Specify dbm instead of hash if your system uses dbm files instead of db
files. To find out what lookup tables Postfix supports, use the command
"ppoossttccoonnff --mm".
"postconf -m".
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
* Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
the sasl_passwd table.
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
* Execute the command "postmap /etc/postfix/sender_relay" whenever you change
the sender_relay table.

2
postfix/README_FILES/TLS_README
View File

@ -1659,7 +1659,7 @@ by the smtp_tls_mandatory_ciphers configuration parameter. This setting
controls the minimum acceptable SMTP client TLS cipher grade for use with
mandatory TLS encryption. The default value "medium" is suitable for most
destinations with which you may want to enforce TLS, and is beyond the reach of
today's crypt-analytic methods. See smtp_tls_policy_maps for information on how
today's cryptanalytic methods. See smtp_tls_policy_maps for information on how
to configure ciphers on a per-destination basis.
By default anonymous ciphers are allowed, and automatically disabled when

111
postfix/RELEASE_NOTES
View File

@ -1,60 +1,33 @@
The stable Postfix release is called postfix-2.6.x where 2=major
release number, 6=minor release number, x=patchlevel. The stable
The stable Postfix release is called postfix-2.7.x where 2=major
release number, 7=minor release number, x=patchlevel. The stable
release never changes except for patches that address bugs or
emergencies. Patches change the patchlevel and the release date.
New features are developed in snapshot releases. These are called
postfix-2.7-yyyymmdd where yyyymmdd is the release date (yyyy=year,
postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
mm=month, dd=day). Patches are never issued for snapshot releases;
instead, a new snapshot is released.
The mail_release_date configuration parameter (format: yyyymmdd)
specifies the release date of a stable release or snapshot release.
If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6
If you upgrade from Postfix 2.6 or earlier, read RELEASE_NOTES-2.7
before proceeding.
Incompatibility with snapshot 20100117
======================================
The meaning of an empty content filter next-hop destination has
changed. Postfix now uses the recipient domain, instead of using
$myhostname as in Postfix 2.6 and earlier. To get the old behavior
use "default_filter_nexthop = $myhostname", or specify a non-empty
next-hop content filter destination.
Major changes with snapshot 20100117
====================================
The FILTER action in access maps or header/body_checks now supports
sender reputation schemes that dynamically choose the SMTP source
IP address.
This is implemented by specifying FILTER actions with empty next-hop
destinations in access maps or header/body_checks, and by configuring
in master.cf one Postfix SMTP client for each SMTP source IP address,
where each client has its own "-o myhostname" and "-o smtp_bind_address"
settings.
Incompatibility with snapshot 20100101
======================================
The verify(8) service now uses a persistent cache by default
(address_verify_map = btree:$data_directory/verify_cache). To
disable, specify "address_verify_map =" in main.cf.
When periodic cache cleanup is enabled (the default), the postscreen(8)
and verify(8) servers now require that their cache databases support
the "delete" and "sequence" operations. To disable periodic cache
cleanup specify a zero xxx_cache_cleanup_interval value.
server now requires that the cache database supports the "delete"
and "sequence" operations. To disable periodic cache cleanup specify
a zero postscreen_cache_cleanup_interval value.
Major changes with snapshot 20100101
====================================
Periodic cache cleanup for the postscreen(8) and verify(8) cache
databases. The time between cache cleanup runs is controlled with
the address_verify_cache_cleanup_interval (default: 12h) and
postscreen_cache_cleanup_interval (default: 12h) parameters. Cache
Periodic cache cleanup for the postscreen(8) cache database. The
time between cache cleanup runs is controlled with the
postscreen_cache_cleanup_interval (default: 12h) parameter. Cache
cleanup increases the database access latency, so this should not
be run more often than necessary.
@ -70,52 +43,6 @@ The postscreen daemon now checks the permanent whitelist before
the permanent blacklist. This makes the whitelist easier to use
for its intended purpose, which is to receive mail.
Major changes with snapshot 20091209
====================================
sender_dependent_default_transport_maps, a per-sender override for
default_transport. It's original motivation is to use different
output channels (with different source IP addresses) for different
sender addresses, in order to keep their IP-based reputations
separate from each other.
The result value syntax is that of default_transport, not transport_maps.
Thus, sender_dependent_default_transport_maps does not support the
special transport_maps result value syntax for null transport, null
nexthop, or null email address.
This feature makes sender_dependent_relayhost_maps pretty much
redundant (though sender_dependent_relayhost_maps will often be
easier to use because that is the only thing people want to override).
Major changes with snapshot 20091109
====================================
Improved before-queue filter performance. With "smtpd_proxy_options
= speed_adjust", the Postfix SMTP server receives the entire message
before it connects to a before-queue content filter. This means you
can run more SMTP server processes with the same number of running
content filter processes, and thus, handle more mail. This feature
is off by default until it is proven to create no new problems.
This addresses a concern of people in Europe who want to reject all
bad mail with a before-queue filter. The alternative, an after-queue
filter, means they would have to discard bad mail (which is illegal)
or bounce bad mail (which violates good network citizenship).
NOTE 1: When this feature is turned on, a filter cannot selectively
reject recipients of a multi-recipient message. It is OK to reject
all recipients of the same multi-recipient message, as is deferring
or accepting all recipients of the same multi-recipient message.
NOTE 2: This feature increases the minimum amount of free queue
space by $message_size_limit. The extra space is needed to save the
message to a temporary file.
To keep the performance overhead low, the same temporary file is
reused with successive mail transactions (the file is of course
truncated before reuse, so there is no information leakage).
Incompatibility with snapshot 20091008
======================================
@ -202,21 +129,3 @@ without reporting sender and recipient information. In a future
implementation, the connection may instead be passed to a dummy
SMTP protocol engine that logs sender and recipient information
before dropping the connection.
Incompatibility with snapshot 20090606
======================================
The "postmulti -e destroy" command no longer attempts to remove
files that are created AFTER "postmulti -e create". It still works
as expected immediately after creating an instance by mistake.
Trying to automatically remove other files is too risky because
Postfix-owned directories are by design not trusted.
Major changes with snapshot 20090606
====================================
Support for header checks on Milter-generated message headers. This
can be used, for example, to control mail flow with Milter-generated
headers with indicators for badness or goodness. For details, see
the postconf(5) section for "milter_header_checks". Currently, all
header_checks features are implemented except PREPEND.

175
postfix/RELEASE_NOTES-2.7 Normal file
View File

@ -0,0 +1,175 @@
The stable Postfix release is called postfix-2.7.x where 2=major
release number, 7=minor release number, x=patchlevel. The stable
release never changes except for patches that address bugs or
emergencies. Patches change the patchlevel and the release date.
New features are developed in snapshot releases. These are called
postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
mm=month, dd=day). Patches are never issued for snapshot releases;
instead, a new snapshot is released.
The mail_release_date configuration parameter (format: yyyymmdd)
specifies the release date of a stable release or snapshot release.
If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6
before proceeding.
Major changes - performance
---------------------------
[Feature 20100101] Periodic cache cleanup for the verify(8) cache
database. The time between cache cleanup runs is controlled with
the address_verify_cache_cleanup_interval (default: 12h) parameter.
Cache cleanup increases the database access latency, so this should
not be run more often than necessary.
[Feature 20091109] Improved before-queue filter performance. With
"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
receives the entire message before it connects to a before-queue
content filter. This means you can run more SMTP server processes
with the same number of running content filter processes, and thus,
handle more mail. This feature is off by default until it is proven
to create no new problems.
This addresses a concern of people in Europe who want to reject all
bad mail with a before-queue filter. The alternative, an after-queue
filter, means they would have to discard bad mail (which is illegal)
or bounce bad mail (which violates good network citizenship).
NOTE 1: When this feature is turned on, a filter cannot selectively
reject recipients of a multi-recipient message. It is OK to reject
all recipients of the same multi-recipient message, as is deferring
or accepting all recipients of the same multi-recipient message.
NOTE 2: This feature increases the minimum amount of free queue
space by $message_size_limit. The extra space is needed to save the
message to a temporary file.
To keep the performance overhead low, the same temporary file is
reused with successive mail transactions (the file is of course
truncated before reuse, so there is no information leakage).
Major changes - sender reputation
---------------------------------
[Feature 20100117] The FILTER action in access maps or header/body_checks
now supports sender reputation schemes that dynamically choose the
SMTP source IP address. Typically, mail is split into classes, and
all mail in class X is sent out from an SMTP client IP address that
is reserved for class X.
This is implemented by specifying FILTER actions with empty next-hop
destinations in access maps or header/body_checks, and by configuring
in master.cf one Postfix SMTP client for each SMTP source IP address,
where each client has its own "-o myhostname" and "-o smtp_bind_address"
settings.
[Feature 20091209] sender_dependent_default_transport_maps, a
per-sender override for default_transport. The original motivation
is to use different output channels (with different source IP
addresses) for different sender addresses, in order to keep their
IP-based reputations separate from each other.
The result value syntax is that of default_transport, not transport_maps.
Thus, sender_dependent_default_transport_maps does not support the
special transport_maps result value syntax for null transport, null
nexthop, or null email address.
This feature makes sender_dependent_relayhost_maps pretty much
redundant (though sender_dependent_relayhost_maps will often be
easier to use because that is the only thing people want to override).
Major changes - address verification
------------------------------------
[Incompat 20100101] The verify(8) service now uses a persistent
cache by default (address_verify_map = btree:$data_directory/verify_cache).
To disable, specify "address_verify_map =" in main.cf.
When periodic cache cleanup is enabled (the default), the verify(8)
server now requires that the cache database supports the "delete"
and "sequence" operations. To disable periodic cache cleanup specify
a zero address_verify_cache_cleanup_interval value.
[Feature 20100101] Periodic cache cleanup for the verify(8) cache
database. The time between cache cleanup runs is controlled with
the address_verify_cache_cleanup_interval (default: 12h) parameter.
Cache cleanup increases the database access latency, so this should
not be run more often than necessary.
Major changes - content filter
------------------------------
[Incompat 20100117] The meaning of an empty filter next-hop destination
has changed (for example, "content_filter = foo:" or "FILTER foo:").
Postfix now uses the recipient domain, instead of using $myhostname
as in Postfix 2.6 and earlier. To restore the old behavior specify
"default_filter_nexthop = $myhostname", or specify a non-empty
next-hop content filter destination.
This compatibility option is not needed with SMTP-based content
filters, because these always have an explicit next-hop destination.
With pipe-based filters that specify no next-hop destination, the
compatibility option restores the FIFO order of deliveries. Without
the compatibility option, the delivery order for filters without
next-hop destination changes to round-robin domain selection.
[Feature 20100117] The FILTER action in access maps or header/body_checks
now supports sender reputation schemes that dynamically choose the
SMTP source IP address. Typically, mail is split into classes, and
all mail in class X is sent out from an SMTP client IP address that
is reserved for class X.
This is implemented by specifying FILTER actions with empty next-hop
destinations in access maps or header/body_checks, and by configuring
in master.cf one Postfix SMTP client for each SMTP source IP address,
where each client has its own "-o myhostname" and "-o smtp_bind_address"
settings.
[Feature 20091109] Improved before-queue filter performance. With
"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
receives the entire message before it connects to a before-queue
content filter. This means you can run more SMTP server processes
with the same number of running content filter processes, and thus,
handle more mail. This feature is off by default until it is proven
to create no new problems.
This addresses a concern of people in Europe who want to reject all
bad mail with a before-queue filter. The alternative, an after-queue
filter, means they would have to discard bad mail (which is illegal)
or bounce bad mail (which violates good network citizenship).
NOTE 1: When this feature is turned on, a filter cannot selectively
reject recipients of a multi-recipient message. It is OK to reject
all recipients of the same multi-recipient message, as is deferring
or accepting all recipients of the same multi-recipient message.
NOTE 2: This feature increases the minimum amount of free queue
space by $message_size_limit. The extra space is needed to save the
message to a temporary file.
To keep the performance overhead low, the same temporary file is
reused with successive mail transactions (the file is of course
truncated before reuse, so there is no information leakage).
Major changes - milter
----------------------
[Feature 20090606] Support for header checks on Milter-generated
message headers. This can be used, for example, to control mail
flow with Milter-generated headers that carry indicators for badness
or goodness. For details, see the postconf(5) section for
"milter_header_checks". Currently, all header_checks features are
implemented except PREPEND.
Major changes - multi-instance support
--------------------------------------
[Incompat 20090606] The "postmulti -e destroy" command no longer
attempts to remove files that are created AFTER "postmulti -e
create". It still works as expected immediately after creating an
instance by mistake. Trying to automatically remove other files
is too risky because Postfix-owned directories are by design not
trusted.

43
postfix/WISHLIST
View File

@ -2,20 +2,35 @@ Wish list:
Remove this file from the stable release.
Should the postscreen temporary cache remember hosts that
are listed in the permanent white/black lists, and be queried
first? Skipping white/black list lookups will speed up the
handling of "good" clients without a permanent whitelist
entry. Of course, this means that updates to the white/black
lists do not immediately take effect. Workarounds: 1) ignore
cached white/black list lookup results after "postfix
reload"; 2) use a short temporary cache TTL for clients on
the permanent black/white lists; 3) adjust the logging, for
example "WHITELISTED address (cached)" and "BLACKLISTED
address (cached)" to eliminate surprises. Comparing the
cache entry time with the white/blacklist file modification
time is not foolproof: for example, pcre or CIDR tables are
read only once.
The cleanup virtual alias expansion limit does not really
deliver on its promises. 1) It promises to truncate the
result without aborting delivery, which would be undesirable
anyway, but that is not what it does, so that is good. 2)
It keeps all the recipients from multi-recipient database
lookup, then terminates further recursion when the result
exceeds the expansion limit. This behavior achieves the
original goal that all things shall have a finite size (even
though but we don'really care how large they are) but may
result in surprises when recipients are listed in virtual
alias domains or need expansion for other reasons. In a
phone call with Victor, a reasonable way out is to set the
limit to some large number (100000) and abort delivery when
the result exceeds the limit.
Should the postscreen save permanent white/black list lookup
results int the temporary cache, and query the temporary
cache first? Skipping white/black list lookups will speed
up the handling of "good" clients without a permanent
whitelist entry. Of course, this means that updates to the
white/black lists do not immediately take effect. Workarounds:
1) use a shorter temporary cache TTL for clients on the
permanent black/white lists; 2) ignore cached white/black
list lookup results after "postfix reload"; 2) adjust the
logging, for example "WHITELISTED address (cached)" and
"BLACKLISTED address (cached)" to eliminate surprises.
Comparing the cache entry time with the white/blacklist
file modification time is not foolproof: for example, pcre
or CIDR tables are read only once.
It would be nice if the generic dict_cache(3) cache manager
could postpone process suicide until cache cleanup is

158
postfix/html/ADDRESS_VERIFICATION_README.html
View File

@ -19,12 +19,11 @@
<h2>WARNING </h2>
<p> The sender/recipient address verification feature described in this
document is suitable only for low-traffic sites. It performs poorly
under high load; excessive sender address verification activity may
even cause your site to be blacklisted by some
providers. See the "<a href="#limitations">Limitations</a>" section
below for details. </p>
<p> Recipient address verification may cause an increased load on
down-stream servers in the case of a dictionary attack or a flood
of backscatter bounces. Sender address verification may cause your
site to be blacklisted by some providers. See also the "<a
href="#limitations">Limitations</a>" section below for more. </p>
<h2><a name="summary">What Postfix address verification can do for you</a></h2>
@ -35,7 +34,7 @@ until the address has been verified to be deliverable. </p>
<p> The technique has obvious uses to reject junk mail
with an unreplyable sender address. </p>
<p> The technique may also be useful to block mail for undeliverable
<p> The technique is also useful to block mail for undeliverable
recipients, for example on a mail <a href="postconf.5.html#relayhost">relay host</a> that does not have a
list of all the valid recipient addresses. This prevents undeliverable
junk mail from entering the queue, so that Postfix doesn't have to
@ -86,74 +85,96 @@ always discarded. </p>
<blockquote>
<table>
<table border="0">
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Internet
<td rowspan="2" colspan="5" align="center" valign="middle">
&nbsp; </td>
<td rowspan="3" align="center" valign="bottom"> <tt> -&gt; </tt>
</td>
<td align="center" valign="middle"> <tt> -&gt; </tt> </td>
<td rowspan="3" align="center" valign="middle"> probe<br>
message </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a
href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td colspan="2" align="center" valign="middle"> <tt> &lt;-&gt;
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> mail<br> queue </td>
</tr>
<tr> </tr>
<tr>
<td rowspan="3" align="center" valign="middle"> Internet </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
<a href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> &lt;-&gt;
</tt> </td>
<td bgcolor="#f0f0ff" colspan="3" align="center" valign="middle">
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
<a href="verify.8.html">Postfix<br> verify<br> server</a>
</td>
<td colspan="2" align="center" valign="middle"> <tt> &lt;-&gt;
</tt> </td>
</tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Address<br>
verification<br> database </td>
<tr>
<td rowspan="1" colspan="3"> </td>
<td rowspan="1" align="center" valign="middle"> <tt> |</tt><br>
<tt> v</tt> </td>
</tr>
<tr>
<td colspan="3"> </td>
<td rowspan="3" align="center" valign="top"> <tt> &lt;- </tt>
</td>
<td> &nbsp; &nbsp; </td>
<td rowspan="3" align="center" valign="middle"> probe<br>
status </td>
<td colspan="2" align="right" valign="middle"> <tt> |</tt><br>
probe<br> messages<br> <tt> v </tt> </td>
<td rowspan="3" align="center" valign="middle"> <tt> &lt;- </tt>
</td>
<td> </td>
<td colspan="2" align="left" valign="middle"> ^<br> delivery<br>
status<br> <tt> | </tt> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> queue </td>
<td align="center" valign="middle"> <tt> -&gt; </tt> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> delivery<br> agents </td>
<td> </td>
<td rowspan="3" align="left" valign="middle"> <tt>-&gt;</tt>
Local<br> <tt>-&gt;</tt> Remote</td>
<td> </td>
</tr>
<tr>
<td rowspan="3" colspan="4" align="center" valign="middle">
&nbsp; </td>
<td rowspan="3" align="center" valign="middle"> <tt>
^</tt><br> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr> </tr>
<tr> <td colspan="4"> &nbsp; </td> </tr>
<tr>
<td colspan="4" align="center" valign="middle"> &nbsp; </td>
<td bgcolor="#f0f0ff" align="center" valign="middle">
Address<br> verification<br> database </td>
</tr>
@ -181,7 +202,8 @@ details. </p>
MTA for that address, without actually delivering mail to it. If
the nearest MTA accepts the address, then Postfix assumes that the
address is deliverable. In reality, mail for a remote address can
bounce AFTER the nearest MTA accepts the recipient address. </p>
bounce AFTER the nearest MTA accepts the recipient address, or AFTER
the nearest MTA accepts the message content. </p>
<li> <p> Some sites may blacklist you when you are probing them
too often (a probe is an SMTP session that does not deliver mail),
@ -200,21 +222,25 @@ mail routing and for possible limitations when you have to do this.
<li> <p> Postfix assumes that an address is undeliverable when the
nearest MTA for the address rejects the probe, regardless of the
reason for rejection (client rejected, HELO rejected, MAIL FROM
rejected, etc.). Thus, Postfix rejects mail when the sender's MTA
rejects mail from your machine. This is a good thing. </p>
rejected, etc.). Thus, Postfix rejects an address when the nearest
MTA for that address rejects mail from your machine for any reason.
This is not a limitation, but it is mentioned here just in case
people believe that it is a limitation. </p>
<li> <p> Unfortunately, some major sites such as YAHOO do not reject
<li> <p> Unfortunately, some sites do not reject
unknown addresses in reply to the RCPT TO command, but report a
delivery failure in response to end of DATA after a message is
transferred. Postfix address verification does not work with such
sites. </p>
<li> <p> By default, Postfix probe messages have "double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>"
as the sender address (with Postfix versions before 2.5, the default
<li> <p> By default, Postfix probe messages have a sender address
"double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>" (with Postfix versions before 2.5, the
default
is "postmaster@$<a href="postconf.5.html#myorigin">myorigin</a>"). This is SAFE because the Postfix SMTP
server does not reject mail for this address. </p>
<p> You can change this into the null address ("<a href="postconf.5.html#address_verify_sender">address_verify_sender</a>
<p> You can change the probe sender address into the null address
("<a href="postconf.5.html#address_verify_sender">address_verify_sender</a>
="). This is UNSAFE because address probes will fail with
mis-configured sites that reject MAIL FROM: &lt;&gt;, while
probes from "postmaster@$<a href="postconf.5.html#myorigin">myorigin</a>" would succeed. </p>
@ -223,7 +249,7 @@ probes from "postmaster@$<a href="postconf.5.html#myorigin">myorigin</a>" would
<h2><a name="recipient">Recipient address verification</a></h2>
<p> As mentioned earlier, recipient address verification may be
<p> As mentioned earlier, recipient address verification is
useful to block mail for undeliverable recipients on a mail relay
host that does not have a list of all valid recipient addresses.
This can help to prevent the mail queue from filling up with
@ -237,9 +263,11 @@ However, recipient address verification probes can increase the
load on down-stream MTAs when you're being flooded by backscatter
bounces, or when some spammer is mounting a dictionary attack. </p>
<p> By default, address verification results are not saved. To avoid
probing the same address repeatedly, you can store the result in a
<a href="#caching">persistent database</a> as described later. </p>
<p> By default, address verification results are saved in a <a
href="#caching">persistent database</a> (Postfix version 2.7 and
later; with earlier versions, specify the database in <a href="postconf.5.html">main.cf</a> as
described later). The persistent database helps to avoid probing
the same address repeatedly. </p>
<blockquote>
<pre>
@ -299,11 +327,13 @@ in forged email. </p>
# Postfix 2.6 and later.
# <a href="postconf.5.html#unverified_sender_defer_code">unverified_sender_defer_code</a> = 250
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
# Note 2: Avoid hash files here. Use btree instead.
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/lib/postfix/verify
/etc/postfix/sender_access:
# Don't do this when you handle lots of email.
aol.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
hotmail.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
bigfoot.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
@ -344,6 +374,7 @@ you can see what mail would be blocked: </p>
# Postfix 2.6 and later.
# <a href="postconf.5.html#unverified_sender_reject_reason">unverified_sender_reject_reason</a> = Address verification failed
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
# Note 2: Avoid hash files here. Use btree instead.
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/lib/postfix/verify
@ -403,7 +434,8 @@ sender address verification probe fails with some temporary error.
<h2><a name="caching">Address verification database</a></h2>
<p> To improve performance, the Postfix <a href="verify.8.html">verify(8)</a> daemon can save
address verification results to a persistent database. The
address verification results to a persistent database. This is
enabled by default with Postfix 2.7 and later. The
<a href="postconf.5.html#address_verify_map">address_verify_map</a> (NOTE: singular) configuration parameter specifies
persistent storage for sender or recipient address verification
results. If you specify an empty value, all address verification

125
postfix/html/OVERVIEW.html
View File

@ -651,31 +651,126 @@ align="center" bgcolor="#f0f0ff"> smtp<br> session<br> cache </td>
<li> <p> The <a href="verify.8.html">verify(8)</a> server verifies that a sender or recipient
address is deliverable before the <a href="smtpd.8.html">smtpd(8)</a> server accepts it. The
<a href="verify.8.html">verify(8)</a> server injects probe messages into the Postfix queue and
processes status updates from delivery agents and/or queue manager.
<a href="verify.8.html">verify(8)</a> server queries a cache with address verification results.
If a result is not found, the <a href="verify.8.html">verify(8)</a> server injects a probe
message into the Postfix queue and processes the status update from
a delivery agent or queue manager.
This process is described in the <a href="ADDRESS_VERIFICATION_README.html">ADDRESS_VERIFICATION_README</a>
document. The <a href="verify.8.html">verify(8)</a> service is available with Postfix version
2.1 and later. </p>
<table>
<tr> <td> Network </td> <td> <tt> -&gt; </tt> </td> <td align="center"
bgcolor="#f0f0ff"> <a href="smtpd.8.html">smtpd(8)</a> </td> <td> <tt> &lt;-&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> <a href="verify.8.html">verify(8)</a> </td> <td> <tt>
-&gt; </tt> </td> <td align="center" bgcolor="#f0f0ff"> <a href="cleanup.8.html">cleanup(8)</a>
</td> <td> <tt> -&gt; </tt> </td> <td align="center" bgcolor="#f0f0ff">
<a href="qmgr.8.html">qmgr(8)</a><br> Postfix <br>queue </td> <td> <tt> -&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> Delivery<br> agents</td>
<tr>
<td rowspan="2" colspan="5" align="center" valign="middle">
&nbsp; </td> <td rowspan="3" align="center" valign="bottom">
<tt> -&gt; </tt> </td> <td rowspan="3" align="center"
valign="middle"> probe<br> message </td> <td rowspan="3"
align="center" valign="middle"> <tt> -&gt; </tt> </td> <td
rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> mail<br> queue </td>
</tr>
<tr> <td colspan="5"> </td> <td align="right"> <table> <tr> <td>
\ </td> <td> </td> </tr> <tr> <td> </td> <td> \ </td> </tr> </table>
</td> <td align="center" valign="bottom"> <tt> &lt;- </tt> </td>
<td valign="bottom"> <tt> &lt;- </tt> </td> <td align="center">
<tt> |<br> v </tt> </td> <td align="center"> <table> <tr> <td>
</td> <td> / </td> </tr> <tr> <td> / </td> <td> </td> </tr> </table>
<tr> </tr>
<tr>
<td rowspan="3" align="center" valign="middle"> Network </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td> <td rowspan="3" bgcolor="#f0f0ff" align="center"
valign="middle"> <a href="smtpd.8.html">smtpd(8)</a> </td> <td rowspan="3" align="center"
valign="middle"> <tt> &lt;-&gt; </tt> </td> <td rowspan="3"
bgcolor="#f0f0ff" align="center" valign="middle"> <a href="verify.8.html">verify(8)</a>
</td>
</tr>
<tr>
<td rowspan="1" colspan="3"> </td> <td rowspan="1" align="center"
valign="middle"> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr>
<td rowspan="3" align="center" valign="top"> <tt> &lt;- </tt>
</td> <td rowspan="3" align="center" valign="middle"> probe<br>
status </td> <td rowspan="3" align="center" valign="middle">
<tt> &lt;- </tt> </td> <td rowspan="3" bgcolor="#f0f0ff"
align="center" valign="middle"> Postfix<br> delivery<br> agents
</td> <td rowspan="3" align="left" valign="middle"> <tt>-&gt;</tt>
Local<br> <tt>-&gt;</tt> Network</td>
</tr>
<tr>
<td rowspan="3" colspan="4" align="center" valign="middle">
&nbsp; </td> <td rowspan="3" align="center" valign="middle">
<tt> ^</tt><br> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr> </tr>
<tr> <td colspan="4"> &nbsp; </td> </tr>
<tr>
<td colspan="4" align="center" valign="middle"> &nbsp; </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Address<br>
verification<br> cache </td>
</tr>
</table>
<li> <p> The <a href="postscreen.8.html">postscreen(8)</a> server can be put "in front" of Postfix
<a href="smtpd.8.html">smtpd(8)</a> processes. Its purpose is to accept connections from the
network and to decide what SMTP clients are allowed to talk to
Postfix. According to the 2008 MessageLabs annual report, 81% of
all email was spam, and 90% of that was sent by botnets. While
<a href="postscreen.8.html">postscreen(8)</a> keeps the zombies away, more <a href="smtpd.8.html">smtpd(8)</a> processes remain
available for legitimate clients. </p>
<p> The <a href="postscreen.8.html">postscreen(8)</a> server is still evolving, and is likely to
undergo changes that break compatibility with earlier versions.
For this reason the <a href="postscreen.8.html">postscreen(8)</a> server is not installed with the
stable Postfix release. </p>
<table>
<tr> <td> zombie </td> </tr>
<tr> <td> </td> <td align="left"> <tt> \ </tt> </td> </tr>
<tr> <td> zombie </td> <td align="left"> <tt> - </tt> </td> <td>
</td> <td> </td> <td> </td> <td align="right"> <tt> - </tt> </td>
<td bgcolor="#f0f0ff" align="center"> <a href="smtpd.8.html">smtpd(8)</a> </td> </tr>
<tr> <td> </td> <td align="right"> <tt> \ </tt> </td> <td> </td>
<td align="left"> <tt> / </tt> </td> </tr>
<tr> <td bgcolor="#f0f0ff" align="center"> other </td> <td> <tt>
--- </tt> </td> <td bgcolor="#f0f0ff" align="center" valign="middle">
<a href="postscreen.8.html">postscreen(8)</a> </td> </tr>
<tr> <td> </td> <td align="right"> <tt> / </tt> </td> <td> </td>
<td align="right"> <tt> \ </tt> </td> </tr>
<tr> <td bgcolor="#f0f0ff" align="center"> other </td> <td align="left">
<tt> - </tt> </td> <td> </td> <td> </td> <td> </td> <td align="right">
<tt> - </tt> </td> <td bgcolor="#f0f0ff" align="center"> <a href="smtpd.8.html">smtpd(8)</a>
</td> </tr>
<tr> <td> </td> <td align="left"> <tt> / </tt> </td> </tr>
<tr> <td> zombie </td> </tr>
</table>
</ul>

2415
postfix/html/SASL_README.html
View File

File diff suppressed because it is too large Load Diff

232
postfix/html/SOHO_README.html
View File

@ -44,11 +44,11 @@ Internet hostname</a>
<ul>
<li><a href="#client_sasl">Enabling SASL authentication in the
<li><a href="#client_sasl_enable">Enabling SASL authentication in the
Postfix SMTP client</a></li>
<li><a href="#client_sasl_sender">Supporting multiple ISP accounts
in the Postfix SMTP client</a></li>
<li><a href="#client_sasl_sender">Configuring Sender-Dependent SASL
authentication </a></li>
</ul>
@ -214,124 +214,122 @@ whenever you change the canonical table. </p>
<p> Execute the command "<b>postmap /etc/postfix/virtual</b>"
whenever you change the virtual table. </p>
<h2><a name="client_sasl">Enabling SASL authentication in the
Postfix SMTP client</a></h2>
<h2><a name="client_sasl_enable">Enabling SASL authentication in the
Postfix SMTP/LMTP client</a></h2>
<p> Turn on client-side SASL authentication, and specify a table
with per-host or per-destination username and password information.
The Postfix SMTP client first searches the table for an entry with
the remote SMTP server hostname; if no entry is found, then the
Postfix SMTP client searches the table for
an entry with the next-hop destination. Usually, that is the
right-hand part of an email address, but it can also be the information
that is specified with the <a href="postconf.5.html#relayhost">relayhost</a> parameter or with a <a href="transport.5.html">transport(5)</a>
table. </p>
<p> This section shows a typical scenario where the Postfix SMTP
client sends all messages via a mail gateway server that requires
SASL authentication. To make the example more readable we introduce
it in two parts. </p>
<blockquote>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#smtp_sasl_auth_enable">smtp_sasl_auth_enable</a> = yes
<a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a> = hash:/etc/postfix/sasl_passwd
<a href="postconf.5.html#smtp_sasl_type">smtp_sasl_type</a> = cyrus
<a href="postconf.5.html#relayhost">relayhost</a> = [mail.myisp.net]
<a href="postconf.5.html#relayhost">relayhost</a> = [mail.isp.example]
# Alternative form:
# <a href="postconf.5.html#relayhost">relayhost</a> = [mail.myisp.net]:submission
/etc/postfix/sasl_passwd:
[mail.myisp.net] username:password
[mail.myisp.net]:submission username:password
# <a href="postconf.5.html#relayhost">relayhost</a> = [mail.isp.example]:submission
<a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a> = hash:/etc/postfix/sasl_passwd
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> The <code><a href="postconf.5.html#smtp_sasl_auth_enable">smtp_sasl_auth_enable</a></code> setting enables
client-side authentication. We will configure the client's username
and password information in the second part of the example. </p>
</li>
<li> <p> The <code><a href="postconf.5.html#relayhost">relayhost</a></code> setting forces the Postfix SMTP
to send all remote messages to the specified mail server instead
of trying to deliver them directly to their destination. </p> </li>
<li> <p> In the <code><a href="postconf.5.html#relayhost">relayhost</a></code> setting, the "<code>[</code>"
and "<code>]</code>" prevent the Postfix SMTP client from looking
up MX (mail exchanger) records for the enclosed name. </p> </li>
<li> <p> The <code><a href="postconf.5.html#relayhost">relayhost</a></code> destination may also specify a
non-default TCP port. For example, the alternative form
<code>[mail.isp.example]:submission</code> tells Postfix to connect
to TCP network port 587, which is reserved for email client
applications. </p> </li>
<li> <p> The Postfix SMTP client is compatible with SMTP servers
that use the non-standard "<code>AUTH=<em>method.</em>...</code>"
syntax in response to the EHLO command; this requires no additional
Postfix client configuration. </p> </li>
<li> <p> The Postfix SMTP client does not support the obsolete
"wrappermode" protocol, which uses TCP port <code>465</code> on the
SMTP server. See <a href="TLS_README.html">TLS_README</a> for a solution that uses the
<code>stunnel</code> command. </p> </li>
<li> <p> With the <code><a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a></code> parameter,
we configure the Postfix SMTP client to send username and password
information to the mail gateway server. As discussed in the next
section, the Postfix SMTP client supports multiple ISP accounts.
For this reason the username and password are stored in a table
that contains one username/password combination for each mail gateway
server. </p>
</ul>
<blockquote>
<pre>
/etc/postfix/sasl_passwd:
# destination credentials
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
</pre>
</blockquote>
<blockquote>
<strong>Important</strong>
<p> Keep the SASL client password file in <code>/etc/postfix</code>,
and make the file read+write only for <code>root</code> to protect
the username/password combinations against other users. The Postfix
SMTP client will still be able to read the SASL client passwords.
It opens the file as user <code>root</code> before it drops privileges,
and before entering an optional chroot jail. </p>
</blockquote>
<ul>
<li> <p> The "submission" destination port tells Postfix to send
mail via TCP network port 587, which is normally reserved for email
clients. The default is to send mail to the "smtp" destination port
(TCP port 25), which is used for receiving mail across the internet.
If you use an explicit destination port in <a href="postconf.5.html">main.cf</a>, then you must
use the same form also in the <a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a> file. </p>
<li> <p> Use the <code>postmap</code> command whenever you
change the <code>/etc/postfix/sasl_passwd</code> file. </p> </li>
<li> <p> Postfix does not deliver mail via TCP port 465 (the obsolete
"wrappermode" protocol). See <a href="TLS_README.html">TLS_README</a> for a solution that uses the
"stunnel" command. </p>
<li> <p> If you specify the "<code>[</code>" and "<code>]</code>"
in the <code><a href="postconf.5.html#relayhost">relayhost</a></code> destination, then you must use the
same form in the <code><a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a></code> file. </p>
</li>
<li> <p> The "[" and "]" prevent Postfix from looking up the MX
(mail exchanger) records for the enclosed name. If you use this
form in <a href="postconf.5.html">main.cf</a>, then you must use the same form also in the
<a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a> file. </p>
<li> <p> If you specify a non-default TCP Port (such as
"<code>:submission</code>" or "<code>:587</code>") in the
<code><a href="postconf.5.html#relayhost">relayhost</a></code> destination, then you must use the same form
in the <code><a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a></code> file. </p> </li>
<li> <p> The Postfix SMTP client opens the SASL client password
file before entering the optional chroot jail, so you can keep the
file in /etc/postfix and set permissions read / write only for root
to keep the username:password combinations away from other system
users. </p>
</ul>
<li> <p> Specify <b>dbm</b> instead of <b>hash</b> if your system
uses <b>dbm</b> files instead of <b>db</b> files. To find out what
lookup tables Postfix supports, use the command "<b>postconf -m</b>".
<h2><a name="client_sasl_sender">Configuring Sender-Dependent SASL
authentication</a></h2>
<p> Postfix supports different ISP accounts for different sender
addresses (version 2.3 and later). This can be useful when one
person uses the same machine for work and for personal use, or when
people with different ISP accounts share the same Postfix server.
</p>
<li> <p> Execute the command "<b>postmap /etc/postfix/sasl_passwd</b>"
whenever you change the sasl_passwd table. </p>
</ul>
<p> Workarounds: </p>
<ul>
<li> <p> Some remote SMTP servers support PLAIN or LOGIN authentication only.
By default, the Postfix SMTP client does not use authentication
methods that send plaintext passwords, and defers delivery with
the following error message: "Authentication failed: cannot SASL
authenticate to server". To enable plaintext authentication specify,
for example: </p>
<blockquote>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#smtp_sasl_security_options">smtp_sasl_security_options</a> = noanonymous
</pre>
</blockquote>
<li> <p> Some remote SMTP servers announce authentication mechanisms
that don't actually work. It is possible via the <a href="postconf.5.html#smtp_sasl_mechanism_filter">smtp_sasl_mechanism_filter</a>
parameter to restrict the list of server mechanisms that the Postfix
SMTP client will take into consideration: </p>
<blockquote>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#smtp_sasl_mechanism_filter">smtp_sasl_mechanism_filter</a> = !gssapi, !external, static:all
</pre>
</blockquote>
<p> In the above example, the Postfix SMTP client will decline to
use mechanisms
that require special infrastructure such as Kerberos or TLS. </p>
<li> <p> The Postfix SMTP client is backwards compatible with SMTP
servers that use the non-standard "AUTH=method..." syntax in response
to the EHLO command; there is no Postfix client configuration needed
to work around it. </p>
</ul>
<h2><a name="client_sasl_sender">Supporting multiple ISP accounts
in the Postfix SMTP client</a></h2>
<p> Postfix version 2.3 supports multiple ISP accounts. This can
be useful when one person uses the same machine for work and for
personal use, or when people with different ISP accounts share the
same Postfix server. To make this possible, Postfix 2.3 supports
per-sender SASL passwords and per-sender relay hosts. In the example
below, Postfix will search the SASL password file by sender before
it searches that same file by destination. Likewise, Postfix will
search the per-sender <a href="postconf.5.html#relayhost">relayhost</a> file, and use the default <a href="postconf.5.html#relayhost">relayhost</a>
only as a final resort. </p>
<p> To make this possible, Postfix supports per-sender SASL passwords
and per-sender relay hosts. In the example below, the Postfix SMTP
client will search the SASL password file by sender address before
it searches that same file by destination. Likewise, the Postfix
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> daemon will search the per-sender <a href="postconf.5.html#relayhost">relayhost</a> file,
and use the default <code><a href="postconf.5.html#relayhost">relayhost</a></code> setting only as a final
resort. </p>
<blockquote>
<pre>
@ -340,18 +338,27 @@ only as a final resort. </p>
<a href="postconf.5.html#sender_dependent_relayhost_maps">sender_dependent_relayhost_maps</a> = hash:/etc/postfix/sender_relay
<a href="postconf.5.html#smtp_sasl_auth_enable">smtp_sasl_auth_enable</a> = yes
<a href="postconf.5.html#smtp_sasl_password_maps">smtp_sasl_password_maps</a> = hash:/etc/postfix/sasl_passwd
<a href="postconf.5.html#relayhost">relayhost</a> = [mail.myisp.net]
<a href="postconf.5.html#relayhost">relayhost</a> = [mail.isp.example]
# Alternative form:
# <a href="postconf.5.html#relayhost">relayhost</a> = [mail.myisp.net]:submission
# <a href="postconf.5.html#relayhost">relayhost</a> = [mail.isp.example]:submission
</pre>
</blockquote>
<blockquote>
<pre>
/etc/postfix/sasl_passwd:
# Per-sender authentication; see also /etc/postfix/sender_relay.
user1@example.com username2:password2
user2@example.net username2:password2
# Login information for the default <a href="postconf.5.html#relayhost">relayhost</a>.
[mail.myisp.net] username:password
[mail.myisp.net]:submission username:password
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
</pre>
</blockquote>
<blockquote>
<pre>
/etc/postfix/sender_relay:
# Per-sender provider; see also /etc/postfix/sasl_passwd.
user1@example.com [mail.example.com]:submission
@ -359,23 +366,20 @@ only as a final resort. </p>
</pre>
</blockquote>
<p> Notes: </p>
<ul>
<li> <p> If you are creative, then you can try to combine the two
tables into one single MySQL database, and configure different
Postfix queries to extract the appropriate information. </p>
<li> <p> Specify <b>dbm</b> instead of <b>hash</b> if your system
uses <b>dbm</b> files instead of <b>db</b> files. To find out what
lookup tables Postfix supports, use the command "<b>postconf -m</b>".
</p>
<li> <p> Specify dbm instead of hash if your system uses dbm files
instead of db files. To find out what lookup tables Postfix supports,
use the command "postconf -m". </p>
<li> <p> Execute the command "<b>postmap /etc/postfix/sasl_passwd</b>"
<li> <p> Execute the command "postmap /etc/postfix/sasl_passwd"
whenever you change the sasl_passwd table. </p>
<li> <p> Execute the command "<b>postmap /etc/postfix/sender_relay</b>"
<li> <p> Execute the command "postmap /etc/postfix/sender_relay"
whenever you change the sender_relay table. </p>
</ul>

2
postfix/html/TLS_README.html
View File

@ -2237,7 +2237,7 @@ as specified by the <a href="postconf.5.html#smtp_tls_mandatory_ciphers">smtp_tl
parameter. This setting controls the minimum acceptable SMTP client
TLS cipher grade for use with mandatory TLS encryption. The default
value "medium" is suitable for most destinations with which you may
want to enforce TLS, and is beyond the reach of today's crypt-analytic
want to enforce TLS, and is beyond the reach of today's cryptanalytic
methods. See <a href="postconf.5.html#smtp_tls_policy_maps">smtp_tls_policy_maps</a> for information on how to configure
ciphers on a per-destination basis. </p>

8
postfix/html/pcre_table.5.html
View File

@ -80,10 +80,10 @@ PCRE_TABLE(5) PCRE_TABLE(5)
cal line.
Each pattern is a perl-like regular expression. The
expression delimiter can be any character, except white-
space or characters that have special meaning (tradition-
ally the forward slash is used). The regular expression
can contain whitespace.
expression delimiter can be any non-alphanumerical charac-
ter, except whitespace or characters that have special
meaning (traditionally the forward slash is used). The
regular expression can contain whitespace.
By default, matching is case-insensitive, and newlines are
not treated as special characters. The behavior is con-

175
postfix/html/postconf.5.html
View File

@ -2291,8 +2291,8 @@ domain.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in <a href="master.5.html">master.cf</a>.
The <i>:nexthop</i> part is optional. For more details see the
<a href="transport.5.html">transport(5)</a> manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -2615,7 +2615,7 @@ for <a href="showq.8.html">showq(8)</a> queue displays. </p>
</DD>
<DT><b><a name="empty_address_default_transport_maps_lookup_key">empty_address_default_transport_maps_lookup_key</a>
(default: <>)</b></DT><DD>
(default: &lt;&gt;)</b></DT><DD>
<p> The <a href="postconf.5.html#sender_dependent_default_transport_maps">sender_dependent_default_transport_maps</a> search string that
will be used instead of the null sender address. </p>
@ -4930,8 +4930,8 @@ which is just the name of a service that is defined the <a href="master.5.html">
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in <a href="master.5.html">master.cf</a>.
The <i>:nexthop</i> part is optional. For more details see the
<a href="transport.5.html">transport(5)</a> manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -6592,7 +6592,7 @@ elapsed, and report whether the client triggers a PREGREET or HANGUP
error, or whether the client is listed at the DNSBL sites specified
with the <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> parameter. Take the corresponding
action, or forward the connection to a real SMTP server process.
</p>
</dd>
<dt> drop </dt>
@ -6698,7 +6698,7 @@ parameter. Specify one of the following: </p>
<dt> continue </dt>
<dd> Forward the connection to a real SMTP server process. </p>
<dd> Forward the connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -6737,7 +6737,7 @@ parameter. Specify one of the following: </p>
elapsed. If the client is listed at the DNS blocklist domains
specified with the <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> parameter, execute the
action specified with the <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a> parameter, otherwise
forward the connection to a real SMTP server process. </p>
forward the connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -6802,7 +6802,7 @@ without sending data, within the time specified with the
<dd> Continue waiting until the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> time has
elapsed, and report whether the client is listed at the DNSBL sites
specified with the <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> parameter. Do not
forward the broken connection to a real SMTP server process. </p>
forward the broken connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -7690,8 +7690,8 @@ the <a href="transport.5.html">transport(5)</a> table.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in <a href="master.5.html">master.cf</a>.
The <i>:nexthop</i> part is optional. For more details see the
<a href="transport.5.html">transport(5)</a> manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -7812,10 +7812,10 @@ clients at all. </p>
(default: no)</b></DT><DD>
<p>
Whether or not a <a href="local.8.html">local(8)</a> recipient's home directory must exist
Require that a <a href="local.8.html">local(8)</a> recipient's home directory exists
before mail delivery is attempted. By default this test is disabled.
It can be useful for environments that import home directories to
the mail server (NOT RECOMMENDED).
the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED).
</p>
@ -9886,7 +9886,7 @@ loglevel 4 is strongly discouraged. </p>
use with
mandatory TLS encryption. The default value "medium" is suitable
for most destinations with which you may want to enforce TLS, and
is beyond the reach of today's crypt-analytic methods. See
is beyond the reach of today's cryptanalytic methods. See
<a href="postconf.5.html#smtp_tls_policy_maps">smtp_tls_policy_maps</a> for information on how to configure ciphers
on a per-destination basis. </p>
@ -9894,47 +9894,32 @@ on a per-destination basis. </p>
<dl>
<dt><b>export</b></dt>
<dd> Enable the mainstream "EXPORT" grade or better OpenSSL
ciphers. This is always used for opportunistic encryption. It is
<dd> Enable "EXPORT" grade or better OpenSSL
ciphers. This is the default for opportunistic encryption. It is
not recommended for mandatory encryption unless you must enforce TLS
with "crippled" peers. The underlying cipherlist is specified via the
<a href="postconf.5.html#tls_export_cipherlist">tls_export_cipherlist</a> configuration parameter, which you are strongly
encouraged to not change. The default value of <a href="postconf.5.html#tls_export_cipherlist">tls_export_cipherlist</a>
includes anonymous ciphers, but these are automatically filtered out if
the client is configured to verify server certificates. If you must
exclude anonymous ciphers also at the "encrypt" security level, set
"<a href="postconf.5.html#smtp_tls_mandatory_exclude_ciphers">smtp_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
encouraged to not change. </dd>
<dt><b>low</b></dt>
<dd> Enable the mainstream "LOW" grade or better OpenSSL ciphers. This
<dd> Enable "LOW" grade or better OpenSSL ciphers. This
setting is only appropriate for internal mail servers. The underlying
cipherlist is specified via the <a href="postconf.5.html#tls_low_cipherlist">tls_low_cipherlist</a> configuration
parameter, which you are strongly encouraged to not change. The default
value of <a href="postconf.5.html#tls_low_cipherlist">tls_low_cipherlist</a> includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "<a href="postconf.5.html#smtp_tls_mandatory_exclude_ciphers">smtp_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
parameter, which you are strongly encouraged to not change. </dd>
<dt><b>medium</b></dt>
<dd> Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers.
<dd> Enable "MEDIUM" grade or better OpenSSL ciphers.
The underlying cipherlist is specified via the <a href="postconf.5.html#tls_medium_cipherlist">tls_medium_cipherlist</a>
configuration parameter, which you are strongly encouraged to not change.
The default value of <a href="postconf.5.html#tls_medium_cipherlist">tls_medium_cipherlist</a> includes anonymous ciphers,
but these are automatically filtered out if the client is configured to
verify server certificates. If you must exclude anonymous ciphers also
at the "encrypt" security level, set "<a href="postconf.5.html#smtp_tls_mandatory_exclude_ciphers">smtp_tls_mandatory_exclude_ciphers</a>
= aNULL". </dd>
</dd>
<dt><b>high</b></dt>
<dd> Enable only the mainstream "HIGH" grade OpenSSL ciphers. This
setting is appropriate when all mandatory TLS destinations support
some of "HIGH" grade ciphers, this is not uncommon. The underlying
cipherlist is specified via the <a href="postconf.5.html#tls_high_cipherlist">tls_high_cipherlist</a> configuration
parameter, which you are strongly encouraged to not change. The default
value of <a href="postconf.5.html#tls_high_cipherlist">tls_high_cipherlist</a> includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "<a href="postconf.5.html#smtp_tls_mandatory_exclude_ciphers">smtp_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
<dd> Enable only "HIGH" grade OpenSSL ciphers. This setting may
be appropriate when all mandatory TLS destinations (e.g. when all
mail is routed to a suitably capable <a href="postconf.5.html#relayhost">relayhost</a>) support at least one
"HIGH" grade cipher. The underlying cipherlist is specified via the
<a href="postconf.5.html#tls_high_cipherlist">tls_high_cipherlist</a> configuration parameter, which you are strongly
encouraged to not change. </dd>
<dt><b>null</b></dt>
<dd> Enable only the "NULL" OpenSSL ciphers, these provide authentication
@ -9944,12 +9929,20 @@ in TLS servers). A plausible use-case is an LMTP server listening on a
UNIX-domain socket that is configured to support "NULL" ciphers. The
underlying cipherlist is specified via the <a href="postconf.5.html#tls_null_cipherlist">tls_null_cipherlist</a>
configuration parameter, which you are strongly encouraged to not
change. The default value of <a href="postconf.5.html#tls_null_cipherlist">tls_null_cipherlist</a> excludes anonymous
ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without
encryption or authentication). </dd>
change. </dd>
</dl>
<p> The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
Postfix SMTP client is configured to verify server certificates.
You are very unlikely to need to take any steps to exclude anonymous
ciphers, they are excluded automatically as necessary. If you must
exclude anonymous ciphers at the "may" or "encrypt" security levels,
when the Postfix SMTP client does not need or use peer certificates, set
"<a href="postconf.5.html#smtp_tls_exclude_ciphers">smtp_tls_exclude_ciphers</a> = aNULL". To exclude anonymous ciphers only when
TLS is enforced, set "<a href="postconf.5.html#smtp_tls_mandatory_exclude_ciphers">smtp_tls_mandatory_exclude_ciphers</a> = aNULL". </p>
<p> This feature is available in Postfix 2.3 and later. </p>
@ -10424,7 +10417,7 @@ Examples:
# Opportunistic TLS.
<a href="postconf.5.html#smtp_tls_security_level">smtp_tls_security_level</a> = may
# Postfix &ge; 2.6:
# Do not tweak opportunistic ciphers unless it is essential
# Do not tweak opportunistic ciphers or protocol unless it is essential
# to do so (if a security vulnerability is found in the SSL library that
# can be mitigated by disabling a particular protocol or raising the
# cipher grade from "export" to "low" or "medium").
@ -11978,7 +11971,7 @@ more of the following, separated by comma or whitespace. </p>
<dt><b>speed_adjust</b></dt>
<dd> Do not connect to a before-queue content filter until an entire
<dd> <p> Do not connect to a before-queue content filter until an entire
message has been received. This reduces the number of simultaneous
before-queue content filter processes. </p>
@ -12505,7 +12498,7 @@ the SASL plug-in implementation that is selected with
configuration file or rendezvous point. </p>
<p> This feature is available in Postfix 2.3 and later. In earlier
releases it was called <b>smtpd_sasl_application_name</b>. </p>
releases it was called <b><a href="postconf.5.html#smtpd_sasl_application_name">smtpd_sasl_application_name</a></b>. </p>
</DD>
@ -13435,65 +13428,46 @@ loglevel 4 is strongly discouraged. </p>
<DT><b><a name="smtpd_tls_mandatory_ciphers">smtpd_tls_mandatory_ciphers</a>
(default: medium)</b></DT><DD>
<p> The minimum TLS cipher grade that the Postfix SMTP server
will use with mandatory TLS encryption. Cipher types listed in
<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> or <a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> are
excluded from the base definition of the selected cipher grade. See
<a href="postconf.5.html#smtpd_tls_ciphers">smtpd_tls_ciphers</a> for cipher controls that apply to opportunistic
TLS. </p>
<p> The minimum TLS cipher grade that the Postfix SMTP server will
use with mandatory TLS encryption. The default grade ("medium") is
sufficiently strong that any benefit from globally restricting TLS
sessions to a more stringent grade is likely negligible, especially
given the fact that many implementations still do not offer any stronger
("high" grade) ciphers, while those that do, will always use "high"
grade ciphers. So insisting on "high" grade ciphers is generally
counter-productive. Allowing "export" or "low" ciphers is typically
not a good idea, as systems limited to just these are limited to
obsolete browsers. No known SMTP clients fail to support at least
one "medium" or "high" grade cipher. </p>
<p> The following cipher grades are supported: </p>
<dl>
<dt><b>export</b></dt>
<dd> Enable the mainstream "EXPORT" grade or better OpenSSL ciphers.
<dd> Enable "EXPORT" grade or stronger OpenSSL ciphers.
This is the most appropriate setting for public MX hosts, and is always
used with opportunistic TLS encryption. The underlying cipherlist
is specified via the <a href="postconf.5.html#tls_export_cipherlist">tls_export_cipherlist</a> configuration parameter,
which you are strongly encouraged to not change. The default value
of <a href="postconf.5.html#tls_export_cipherlist">tls_export_cipherlist</a> includes anonymous ciphers, but these are
automatically filtered out if the server is configured to ask for
client certificates. If you must always exclude anonymous ciphers,
set "<a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> = aNULL". To exclude anonymous ciphers
only when TLS is enforced, set "<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> =
aNULL". </dd>
which you are strongly encouraged to not change. </dd>
<dt><b>low</b></dt>
<dd> Enable the mainstream "LOW" grade or better OpenSSL ciphers. The
<dd> Enable "LOW" grade or stronger OpenSSL ciphers. The
underlying cipherlist is specified via the <a href="postconf.5.html#tls_low_cipherlist">tls_low_cipherlist</a>
configuration parameter, which you are strongly encouraged to
not change. The default value of <a href="postconf.5.html#tls_low_cipherlist">tls_low_cipherlist</a> includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "<a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
not change. </dd>
<dt><b>medium</b></dt>
<dd> Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These
are essentially the 128-bit or stronger ciphers. This is the default
minimum strength for mandatory TLS encryption. MSAs that enforce
TLS and have clients that do not support any "MEDIUM" or "HIGH"
grade ciphers, may need to configure a weaker ("low" or "export")
minimum cipher grade. The underlying cipherlist is specified via the
<a href="postconf.5.html#tls_medium_cipherlist">tls_medium_cipherlist</a> configuration parameter, which you are strongly
encouraged to not change. The default value of <a href="postconf.5.html#tls_medium_cipherlist">tls_medium_cipherlist</a>
includes anonymous ciphers, but these are automatically filtered out if
the server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "<a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
<dd> Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit
or longer symmetric bulk-encryption keys. This is the default minimum
strength for mandatory TLS encryption. The underlying cipherlist is
specified via the <a href="postconf.5.html#tls_medium_cipherlist">tls_medium_cipherlist</a> configuration parameter, which
you are strongly encouraged to not change. </dd>
<dt><b>high</b></dt>
<dd> Enable only the mainstream "HIGH" grade OpenSSL ciphers. The
<dd> Enable only "HIGH" grade OpenSSL ciphers. The
underlying cipherlist is specified via the <a href="postconf.5.html#tls_high_cipherlist">tls_high_cipherlist</a>
configuration parameter, which you are strongly encouraged to
not change. The default value of <a href="postconf.5.html#tls_high_cipherlist">tls_high_cipherlist</a> includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "<a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> = aNULL". </dd>
not change. </dd>
<dt><b>null</b></dt>
<dd> Enable only the "NULL" OpenSSL ciphers, these provide authentication
@ -13501,12 +13475,25 @@ without encryption. This setting is only appropriate in the rare
case that all clients are prepared to use NULL ciphers (not normally
enabled in TLS clients). The underlying cipherlist is specified via the
<a href="postconf.5.html#tls_null_cipherlist">tls_null_cipherlist</a> configuration parameter, which you are strongly
encouraged to not change. The default value of <a href="postconf.5.html#tls_null_cipherlist">tls_null_cipherlist</a>
excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer
data integrity without encryption or authentication). </dd>
encouraged to not change. </dd>
</dl>
<p> Cipher types listed in
<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> or <a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> are
excluded from the base definition of the selected cipher grade. See
<a href="postconf.5.html#smtpd_tls_ciphers">smtpd_tls_ciphers</a> for cipher controls that apply to opportunistic
TLS. </p>
<p> The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. You are very
unlikely to need to take any steps to exclude anonymous ciphers, they
are excluded automatically as required. If you must exclude anonymous
ciphers even when Postfix does not need or use peer certificates, set
"<a href="postconf.5.html#smtpd_tls_exclude_ciphers">smtpd_tls_exclude_ciphers</a> = aNULL". To exclude anonymous ciphers only
when TLS is enforced, set "<a href="postconf.5.html#smtpd_tls_mandatory_exclude_ciphers">smtpd_tls_mandatory_exclude_ciphers</a> = aNULL". </p>
<p> This feature is available in Postfix 2.3 and later. </p>
@ -15203,8 +15190,8 @@ This information can be overruled with the <a href="transport.5.html">transport(
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in <a href="master.5.html">master.cf</a>.
The <i>:nexthop</i> part is optional. For more details see the
<a href="transport.5.html">transport(5)</a> manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>

6
postfix/html/postqueue.1.html
View File

@ -60,10 +60,8 @@ POSTQUEUE(1) POSTQUEUE(1)
size, arrival time, sender, and the recipients that
still need to be delivered. If mail could not be
delivered upon the last attempt, the reason for
failure is shown. This mode of operation is imple-
mented by executing the <a href="postqueue.1.html"><b>postqueue</b>(1)</a> command. The
queue ID string is followed by an optional status
character:
failure is shown. The queue ID string is followed
by an optional status character:
<b>*</b> The message is in the <b>active</b> queue, i.e. the
message is selected for delivery.

8
postfix/html/regexp_table.5.html
View File

@ -85,10 +85,10 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
Solaris, and in <b>regex</b>(7) with Linux. Other systems may use
other document names.
The expression delimiter can be any character, except
whitespace or characters that have special meaning (tradi-
tionally the forward slash is used). The regular expres-
sion can contain whitespace.
The expression delimiter can be any non-alphanumerical
character, except whitespace or characters that have spe-
cial meaning (traditionally the forward slash is used).
The regular expression can contain whitespace.
By default, matching is case-insensitive, and newlines are
not treated as special characters. The behavior is con-

10
postfix/html/smtpd.8.html
View File

@ -105,10 +105,6 @@ SMTPD(8) SMTPD(8)
as if the local hostname were specified, instead of
rejecting the address as invalid.
<b><a href="postconf.5.html#smtpd_command_filter">smtpd_command_filter</a> (empty)</b>
A mechanism to transform commands from remote SMTP
clients.
<b><a href="postconf.5.html#smtpd_reject_unlisted_sender">smtpd_reject_unlisted_sender</a> (no)</b>
Request that the Postfix SMTP server rejects mail
from unknown sender addresses, even when no
@ -151,6 +147,12 @@ SMTPD(8) SMTPD(8)
An optional workaround for routers that break TCP
window scaling.
Available in Postfix version 2.7 and later:
<b><a href="postconf.5.html#smtpd_command_filter">smtpd_command_filter</a> (empty)</b>
A mechanism to transform commands from remote SMTP
clients.
<b>ADDRESS REWRITING CONTROLS</b>
See the <a href="ADDRESS_REWRITING_README.html">ADDRESS_REWRITING_README</a> document for a detailed
discussion of Postfix address rewriting.

22
postfix/html/verify.8.html
View File

@ -40,7 +40,7 @@ VERIFY(8) VERIFY(8)
<b>query</b> <i>address</i>
Look up the <i>status</i> and <i>text</i> for the specified
address. If the status is unknown, a probe is sent
<i>address</i>. If the status is unknown, a probe is sent
and an "in progress" status is returned.
<b>SECURITY</b>
@ -50,9 +50,9 @@ VERIFY(8) VERIFY(8)
low privilege.
The address verification server can be coerced to store
unlimited amounts of garbage. Limiting the cache size
trades one problem (disk space exhaustion) for another one
(poor response time to client requests).
unlimited amounts of garbage. Limiting the cache expiry
time trades one problem (disk space exhaustion) for
another one (poor response time to client requests).
With Postfix version 2.5 and later, the <a href="verify.8.html"><b>verify</b>(8)</a> server
no longer uses root privileges when opening the
@ -66,12 +66,12 @@ VERIFY(8) VERIFY(8)
Problems and transactions are logged to <b>syslogd</b>(8).
<b>BUGS</b>
The address verification service is suitable only for
sites that handle a low mail volume. Verification probes
add additional traffic to the mail queue and perform
poorly under high load. Servers may blacklist sites that
probe excessively, or that probe excessively for non-exis-
tent recipient addresses.
Address verification probe messages add additional traffic
to the mail queue. Recipient verification may cause an
increased load on down-stream servers in the case of a
dictionary attack or a flood of backscatter bounces.
Sender address verification may cause your site to be
blacklisted by some providers.
If the persistent database ever gets corrupted then the
world comes to an end and human intervention is needed.
@ -79,7 +79,7 @@ VERIFY(8) VERIFY(8)
<b>CONFIGURATION PARAMETERS</b>
Changes to <a href="postconf.5.html"><b>main.cf</b></a> are not picked up automatically, as
<a href="verify.8.html"><b>verify</b>(8)</a> processes are persistent. Use the command "<b>post-</b>
<a href="verify.8.html"><b>verify</b>(8)</a> processes are long-lived. Use the command "<b>post-</b>
<b>fix reload</b>" after a configuration change.
The text below provides only a parameter summary. See

3
postfix/man/man1/postqueue.1
View File

@ -54,8 +54,7 @@ by contacting the Postfix \fBshowq\fR(8) daemon.
Each queue entry shows the queue file ID, message
size, arrival time, sender, and the recipients that still need to
be delivered. If mail could not be delivered upon the last attempt,
the reason for failure is shown. This mode of operation is implemented
by executing the \fBpostqueue\fR(1) command. The queue ID string
the reason for failure is shown. The queue ID string
is followed by an optional status character:
.RS
.IP \fB*\fR

3
postfix/man/man5/pcre_table.5
View File

@ -76,7 +76,8 @@ A logical line starts with non-whitespace text. A line that
starts with whitespace continues a logical line.
.PP
Each pattern is a perl-like regular expression. The expression
delimiter can be any character, except whitespace or characters
delimiter can be any non-alphanumerical character, except
whitespace or characters
that have special meaning (traditionally the forward slash is used).
The regular expression can contain whitespace.

160
postfix/man/man5/postconf.5
View File

@ -1315,8 +1315,8 @@ domain.
.PP
Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR
is the name of a mail delivery transport defined in master.cf.
The \fI:nexthop\fR part is optional. For more details see the
\fBtransport\fR(5) manual page.
The \fI:nexthop\fR destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
.PP
Example:
.PP
@ -2718,8 +2718,8 @@ which is just the name of a service that is defined the master.cf file.
.PP
Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR
is the name of a mail delivery transport defined in master.cf.
The \fI:nexthop\fR part is optional. For more details see the
\fBtransport\fR(5) manual page.
The \fI:nexthop\fR destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
.PP
Beware: if you override the default local delivery agent then you
need to review the LOCAL_RECIPIENT_README document, otherwise the
@ -4331,8 +4331,8 @@ the \fBtransport\fR(5) table.
.PP
Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR
is the name of a mail delivery transport defined in master.cf.
The \fI:nexthop\fR part is optional. For more details see the
\fBtransport\fR(5) manual page.
The \fI:nexthop\fR destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
.PP
See also the relay domains address class in the ADDRESS_CLASS_README
file.
@ -4423,10 +4423,10 @@ remote_header_rewrite_domain =
.ft R
.in -4
.SH require_home_directory (default: no)
Whether or not a \fBlocal\fR(8) recipient's home directory must exist
Require that a \fBlocal\fR(8) recipient's home directory exists
before mail delivery is attempted. By default this test is disabled.
It can be useful for environments that import home directories to
the mail server (NOT RECOMMENDED).
the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED).
.SH resolve_dequoted_address (default: yes)
Resolve a recipient address safely instead of correctly, by
looking inside quotes.
@ -5800,50 +5800,34 @@ The minimum TLS cipher grade that the Postfix SMTP client will
use with
mandatory TLS encryption. The default value "medium" is suitable
for most destinations with which you may want to enforce TLS, and
is beyond the reach of today's crypt-analytic methods. See
is beyond the reach of today's cryptanalytic methods. See
smtp_tls_policy_maps for information on how to configure ciphers
on a per-destination basis.
.PP
The following cipher grades are supported:
.IP "\fBexport\fR"
Enable the mainstream "EXPORT" grade or better OpenSSL
ciphers. This is always used for opportunistic encryption. It is
Enable "EXPORT" grade or better OpenSSL
ciphers. This is the default for opportunistic encryption. It is
not recommended for mandatory encryption unless you must enforce TLS
with "crippled" peers. The underlying cipherlist is specified via the
tls_export_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_export_cipherlist
includes anonymous ciphers, but these are automatically filtered out if
the client is configured to verify server certificates. If you must
exclude anonymous ciphers also at the "encrypt" security level, set
"smtp_tls_mandatory_exclude_ciphers = aNULL".
encouraged to not change.
.IP "\fBlow\fR"
Enable the mainstream "LOW" grade or better OpenSSL ciphers. This
Enable "LOW" grade or better OpenSSL ciphers. This
setting is only appropriate for internal mail servers. The underlying
cipherlist is specified via the tls_low_cipherlist configuration
parameter, which you are strongly encouraged to not change. The default
value of tls_low_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
parameter, which you are strongly encouraged to not change.
.IP "\fBmedium\fR"
Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers.
Enable "MEDIUM" grade or better OpenSSL ciphers.
The underlying cipherlist is specified via the tls_medium_cipherlist
configuration parameter, which you are strongly encouraged to not change.
The default value of tls_medium_cipherlist includes anonymous ciphers,
but these are automatically filtered out if the client is configured to
verify server certificates. If you must exclude anonymous ciphers also
at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers
= aNULL".
.IP "\fBhigh\fR"
Enable only the mainstream "HIGH" grade OpenSSL ciphers. This
setting is appropriate when all mandatory TLS destinations support
some of "HIGH" grade ciphers, this is not uncommon. The underlying
cipherlist is specified via the tls_high_cipherlist configuration
parameter, which you are strongly encouraged to not change. The default
value of tls_high_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
Enable only "HIGH" grade OpenSSL ciphers. This setting may
be appropriate when all mandatory TLS destinations (e.g. when all
mail is routed to a suitably capable relayhost) support at least one
"HIGH" grade cipher. The underlying cipherlist is specified via the
tls_high_cipherlist configuration parameter, which you are strongly
encouraged to not change.
.IP "\fBnull\fR"
Enable only the "NULL" OpenSSL ciphers, these provide authentication
without encryption. This setting is only appropriate in the rare case
@ -5852,9 +5836,17 @@ in TLS servers). A plausible use-case is an LMTP server listening on a
UNIX-domain socket that is configured to support "NULL" ciphers. The
underlying cipherlist is specified via the tls_null_cipherlist
configuration parameter, which you are strongly encouraged to not
change. The default value of tls_null_cipherlist excludes anonymous
ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without
encryption or authentication).
change.
.PP
The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
Postfix SMTP client is configured to verify server certificates.
You are very unlikely to need to take any steps to exclude anonymous
ciphers, they are excluded automatically as necessary. If you must
exclude anonymous ciphers at the "may" or "encrypt" security levels,
when the Postfix SMTP client does not need or use peer certificates, set
"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when
TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
.PP
This feature is available in Postfix 2.3 and later.
.SH smtp_tls_mandatory_exclude_ciphers (default: empty)
@ -6285,7 +6277,7 @@ smtp_tls_security_level = none
# Opportunistic TLS.
smtp_tls_security_level = may
# Postfix >= 2.6:
# Do not tweak opportunistic ciphers unless it is essential
# Do not tweak opportunistic ciphers or protocol unless it is essential
# to do so (if a security vulnerability is found in the SSL library that
# can be mitigated by disabling a particular protocol or raising the
# cipher grade from "export" to "low" or "medium").
@ -8465,69 +8457,63 @@ loglevel 4 is strongly discouraged.
.PP
This feature is available in Postfix 2.2 and later.
.SH smtpd_tls_mandatory_ciphers (default: medium)
The minimum TLS cipher grade that the Postfix SMTP server
will use with mandatory TLS encryption. Cipher types listed in
smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are
excluded from the base definition of the selected cipher grade. See
smtpd_tls_ciphers for cipher controls that apply to opportunistic
TLS.
The minimum TLS cipher grade that the Postfix SMTP server will
use with mandatory TLS encryption. The default grade ("medium") is
sufficiently strong that any benefit from globally restricting TLS
sessions to a more stringent grade is likely negligible, especially
given the fact that many implementations still do not offer any stronger
("high" grade) ciphers, while those that do, will always use "high"
grade ciphers. So insisting on "high" grade ciphers is generally
counter-productive. Allowing "export" or "low" ciphers is typically
not a good idea, as systems limited to just these are limited to
obsolete browsers. No known SMTP clients fail to support at least
one "medium" or "high" grade cipher.
.PP
The following cipher grades are supported:
.IP "\fBexport\fR"
Enable the mainstream "EXPORT" grade or better OpenSSL ciphers.
Enable "EXPORT" grade or stronger OpenSSL ciphers.
This is the most appropriate setting for public MX hosts, and is always
used with opportunistic TLS encryption. The underlying cipherlist
is specified via the tls_export_cipherlist configuration parameter,
which you are strongly encouraged to not change. The default value
of tls_export_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the server is configured to ask for
client certificates. If you must always exclude anonymous ciphers,
set "smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers
only when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers =
aNULL".
which you are strongly encouraged to not change.
.IP "\fBlow\fR"
Enable the mainstream "LOW" grade or better OpenSSL ciphers. The
Enable "LOW" grade or stronger OpenSSL ciphers. The
underlying cipherlist is specified via the tls_low_cipherlist
configuration parameter, which you are strongly encouraged to
not change. The default value of tls_low_cipherlist includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL".
not change.
.IP "\fBmedium\fR"
Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These
are essentially the 128-bit or stronger ciphers. This is the default
minimum strength for mandatory TLS encryption. MSAs that enforce
TLS and have clients that do not support any "MEDIUM" or "HIGH"
grade ciphers, may need to configure a weaker ("low" or "export")
minimum cipher grade. The underlying cipherlist is specified via the
tls_medium_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_medium_cipherlist
includes anonymous ciphers, but these are automatically filtered out if
the server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL".
Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit
or longer symmetric bulk-encryption keys. This is the default minimum
strength for mandatory TLS encryption. The underlying cipherlist is
specified via the tls_medium_cipherlist configuration parameter, which
you are strongly encouraged to not change.
.IP "\fBhigh\fR"
Enable only the mainstream "HIGH" grade OpenSSL ciphers. The
Enable only "HIGH" grade OpenSSL ciphers. The
underlying cipherlist is specified via the tls_high_cipherlist
configuration parameter, which you are strongly encouraged to
not change. The default value of tls_high_cipherlist includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL".
not change.
.IP "\fBnull\fR"
Enable only the "NULL" OpenSSL ciphers, these provide authentication
without encryption. This setting is only appropriate in the rare
case that all clients are prepared to use NULL ciphers (not normally
enabled in TLS clients). The underlying cipherlist is specified via the
tls_null_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_null_cipherlist
excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer
data integrity without encryption or authentication).
encouraged to not change.
.PP
Cipher types listed in
smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are
excluded from the base definition of the selected cipher grade. See
smtpd_tls_ciphers for cipher controls that apply to opportunistic
TLS.
.PP
The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. You are very
unlikely to need to take any steps to exclude anonymous ciphers, they
are excluded automatically as required. If you must exclude anonymous
ciphers even when Postfix does not need or use peer certificates, set
"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only
when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL".
.PP
This feature is available in Postfix 2.3 and later.
.SH smtpd_tls_mandatory_exclude_ciphers (default: empty)
@ -9521,8 +9507,8 @@ This information can be overruled with the \fBtransport\fR(5) table.
.PP
Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR
is the name of a mail delivery transport defined in master.cf.
The \fI:nexthop\fR part is optional. For more details see the
\fBtransport\fR(5) manual page.
The \fI:nexthop\fR destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
.PP
This feature is available in Postfix 2.0 and later.
.SH virtual_uid_maps (default: empty)

3
postfix/man/man5/regexp_table.5
View File

@ -80,7 +80,8 @@ delimiters. The regular expression syntax is documented in
\fBre_format\fR(7) with 4.4BSD, in \fBregex\fR(5) with Solaris, and in
\fBregex\fR(7) with Linux. Other systems may use other document names.
The expression delimiter can be any character, except whitespace
The expression delimiter can be any non-alphanumerical
character, except whitespace
or characters that have special meaning (traditionally the forward
slash is used). The regular expression can contain whitespace.

6
postfix/man/man8/smtpd.8
View File

@ -108,8 +108,6 @@ Available in Postfix version 2.1 and later:
Resolve an address that ends in the "@" null domain as if the
local hostname were specified, instead of rejecting the address as
invalid.
.IP "\fBsmtpd_command_filter (empty)\fR"
A mechanism to transform commands from remote SMTP clients.
.IP "\fBsmtpd_reject_unlisted_sender (no)\fR"
Request that the Postfix SMTP server rejects mail from unknown
sender addresses, even when no explicit reject_unlisted_sender
@ -141,6 +139,10 @@ is empty).
Available in Postfix version 2.6 and later:
.IP "\fBtcp_windowsize (0)\fR"
An optional workaround for routers that break TCP window scaling.
.PP
Available in Postfix version 2.7 and later:
.IP "\fBsmtpd_command_filter (empty)\fR"
A mechanism to transform commands from remote SMTP clients.
.SH "ADDRESS REWRITING CONTROLS"
.na
.nf

20
postfix/man/man8/verify.8
View File

@ -36,7 +36,8 @@ The \fBverify\fR(8) server implements the following requests:
.IP "\fBupdate\fI address status text\fR"
Update the status and text of the specified address.
.IP "\fBquery\fI address\fR"
Look up the \fIstatus\fR and \fItext\fR for the specified address.
Look up the \fIstatus\fR and \fItext\fR for the specified
\fIaddress\fR.
If the status is unknown, a probe is sent and an "in progress"
status is returned.
.SH "SECURITY"
@ -49,7 +50,8 @@ not talk to the network, and it does not talk to local users.
The verify server can run chrooted at fixed low privilege.
The address verification server can be coerced to store
unlimited amounts of garbage. Limiting the cache size
unlimited amounts of garbage. Limiting the cache expiry
time
trades one problem (disk space exhaustion) for another
one (poor response time to client requests).
@ -67,11 +69,13 @@ Problems and transactions are logged to \fBsyslogd\fR(8).
.SH BUGS
.ad
.fi
The address verification service is suitable only for sites that
handle a low mail volume. Verification probes add additional
traffic to the mail queue and perform poorly under high load.
Servers may blacklist sites that probe excessively, or that
probe excessively for non-existent recipient addresses.
Address verification probe messages add additional traffic
to the mail queue.
Recipient verification may cause an increased load on
down-stream servers in the case of a dictionary attack or
a flood of backscatter bounces.
Sender address verification may cause your site to be
blacklisted by some providers.
If the persistent database ever gets corrupted then the world
comes to an end and human intervention is needed. This violates
@ -83,7 +87,7 @@ a basic Postfix principle.
.fi
Changes to \fBmain.cf\fR are not picked up automatically,
as \fBverify\fR(8)
processes are persistent. Use the command "\fBpostfix reload\fR" after
processes are long-lived. Use the command "\fBpostfix reload\fR" after
a configuration change.
The text below provides only a parameter summary. See

11
postfix/mantools/make_soho_readme
View File

@ -47,11 +47,11 @@ Internet hostname</a>
<ul>
<li><a href="#client_sasl">Enabling SASL authentication in the
<li><a href="#client_sasl_enable">Enabling SASL authentication in the
Postfix SMTP client</a></li>
<li><a href="#client_sasl_sender">Supporting multiple ISP accounts
in the Postfix SMTP client</a></li>
<li><a href="#client_sasl_sender">Configuring Sender-Dependent SASL
authentication </a></li>
</ul>
@ -72,8 +72,9 @@ sed -n '/^<h2><a name="fantasy">/,${
p
}' STANDARD_CONFIGURATION_README.html
sed -n '/^<h2><a name="client_sasl">/,${
/^<h2><a name="credits/q
sed -n '/^<h3><a name="client_sasl_enable"/,${
/^<h3><a name="client_sasl_policy"/q
s/h3>/h2>/g
p
}' SASL_README.html

1
postfix/mantools/postlink
View File

@ -523,6 +523,7 @@ while (<>) {
s;\bsmtpd_reject_unlisted_recip[-</bB>]*\n* *[<bB>]*ient\b;<a href="postconf.5.html#smtpd_reject_unlisted_recipient">$&</a>;g;
s;\bsmtpd_reject_unlisted_sender\b;<a href="postconf.5.html#smtpd_reject_unlisted_sender">$&</a>;g;
s;\bsmtpd_restriction_classes\b;<a href="postconf.5.html#smtpd_restriction_classes">$&</a>;g;
s;\bsmtpd_sasl_application_name\b;<a href="postconf.5.html#smtpd_sasl_application_name">$&</a>;g;
s;\bsmtpd_sasl_path\b;<a href="postconf.5.html#smtpd_sasl_path">$&</a>;g;
s;\bcyrus_sasl_config_path\b;<a href="postconf.5.html#cyrus_sasl_config_path">$&</a>;g;
s;\bsmtpd_sasl_auth_enable\b;<a href="postconf.5.html#smtpd_sasl_auth_enable">$&</a>;g;

158
postfix/proto/ADDRESS_VERIFICATION_README.html
View File

@ -19,12 +19,11 @@
<h2>WARNING </h2>
<p> The sender/recipient address verification feature described in this
document is suitable only for low-traffic sites. It performs poorly
under high load; excessive sender address verification activity may
even cause your site to be blacklisted by some
providers. See the "<a href="#limitations">Limitations</a>" section
below for details. </p>
<p> Recipient address verification may cause an increased load on
down-stream servers in the case of a dictionary attack or a flood
of backscatter bounces. Sender address verification may cause your
site to be blacklisted by some providers. See also the "<a
href="#limitations">Limitations</a>" section below for more. </p>
<h2><a name="summary">What Postfix address verification can do for you</a></h2>
@ -35,7 +34,7 @@ until the address has been verified to be deliverable. </p>
<p> The technique has obvious uses to reject junk mail
with an unreplyable sender address. </p>
<p> The technique may also be useful to block mail for undeliverable
<p> The technique is also useful to block mail for undeliverable
recipients, for example on a mail relay host that does not have a
list of all the valid recipient addresses. This prevents undeliverable
junk mail from entering the queue, so that Postfix doesn't have to
@ -86,74 +85,96 @@ always discarded. </p>
<blockquote>
<table>
<table border="0">
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Internet
<td rowspan="2" colspan="5" align="center" valign="middle">
&nbsp; </td>
<td rowspan="3" align="center" valign="bottom"> <tt> -&gt; </tt>
</td>
<td align="center" valign="middle"> <tt> -&gt; </tt> </td>
<td rowspan="3" align="center" valign="middle"> probe<br>
message </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a
href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td colspan="2" align="center" valign="middle"> <tt> &lt;-&gt;
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> mail<br> queue </td>
</tr>
<tr> </tr>
<tr>
<td rowspan="3" align="center" valign="middle"> Internet </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
<a href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> &lt;-&gt;
</tt> </td>
<td bgcolor="#f0f0ff" colspan="3" align="center" valign="middle">
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
<a href="verify.8.html">Postfix<br> verify<br> server</a>
</td>
<td colspan="2" align="center" valign="middle"> <tt> &lt;-&gt;
</tt> </td>
</tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Address<br>
verification<br> database </td>
<tr>
<td rowspan="1" colspan="3"> </td>
<td rowspan="1" align="center" valign="middle"> <tt> |</tt><br>
<tt> v</tt> </td>
</tr>
<tr>
<td colspan="3"> </td>
<td rowspan="3" align="center" valign="top"> <tt> &lt;- </tt>
</td>
<td> &nbsp; &nbsp; </td>
<td rowspan="3" align="center" valign="middle"> probe<br>
status </td>
<td colspan="2" align="right" valign="middle"> <tt> |</tt><br>
probe<br> messages<br> <tt> v </tt> </td>
<td rowspan="3" align="center" valign="middle"> <tt> &lt;- </tt>
</td>
<td> </td>
<td colspan="2" align="left" valign="middle"> ^<br> delivery<br>
status<br> <tt> | </tt> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> queue </td>
<td align="center" valign="middle"> <tt> -&gt; </tt> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> delivery<br> agents </td>
<td> </td>
<td rowspan="3" align="left" valign="middle"> <tt>-&gt;</tt>
Local<br> <tt>-&gt;</tt> Remote</td>
<td> </td>
</tr>
<tr>
<td rowspan="3" colspan="4" align="center" valign="middle">
&nbsp; </td>
<td rowspan="3" align="center" valign="middle"> <tt>
^</tt><br> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr> </tr>
<tr> <td colspan="4"> &nbsp; </td> </tr>
<tr>
<td colspan="4" align="center" valign="middle"> &nbsp; </td>
<td bgcolor="#f0f0ff" align="center" valign="middle">
Address<br> verification<br> database </td>
</tr>
@ -181,7 +202,8 @@ details. </p>
MTA for that address, without actually delivering mail to it. If
the nearest MTA accepts the address, then Postfix assumes that the
address is deliverable. In reality, mail for a remote address can
bounce AFTER the nearest MTA accepts the recipient address. </p>
bounce AFTER the nearest MTA accepts the recipient address, or AFTER
the nearest MTA accepts the message content. </p>
<li> <p> Some sites may blacklist you when you are probing them
too often (a probe is an SMTP session that does not deliver mail),
@ -200,21 +222,25 @@ mail routing and for possible limitations when you have to do this.
<li> <p> Postfix assumes that an address is undeliverable when the
nearest MTA for the address rejects the probe, regardless of the
reason for rejection (client rejected, HELO rejected, MAIL FROM
rejected, etc.). Thus, Postfix rejects mail when the sender's MTA
rejects mail from your machine. This is a good thing. </p>
rejected, etc.). Thus, Postfix rejects an address when the nearest
MTA for that address rejects mail from your machine for any reason.
This is not a limitation, but it is mentioned here just in case
people believe that it is a limitation. </p>
<li> <p> Unfortunately, some major sites such as YAHOO do not reject
<li> <p> Unfortunately, some sites do not reject
unknown addresses in reply to the RCPT TO command, but report a
delivery failure in response to end of DATA after a message is
transferred. Postfix address verification does not work with such
sites. </p>
<li> <p> By default, Postfix probe messages have "double-bounce@$myorigin"
as the sender address (with Postfix versions before 2.5, the default
<li> <p> By default, Postfix probe messages have a sender address
"double-bounce@$myorigin" (with Postfix versions before 2.5, the
default
is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP
server does not reject mail for this address. </p>
<p> You can change this into the null address ("address_verify_sender
<p> You can change the probe sender address into the null address
("address_verify_sender
="). This is UNSAFE because address probes will fail with
mis-configured sites that reject MAIL FROM: &lt;&gt;, while
probes from "postmaster@$myorigin" would succeed. </p>
@ -223,7 +249,7 @@ probes from "postmaster@$myorigin" would succeed. </p>
<h2><a name="recipient">Recipient address verification</a></h2>
<p> As mentioned earlier, recipient address verification may be
<p> As mentioned earlier, recipient address verification is
useful to block mail for undeliverable recipients on a mail relay
host that does not have a list of all valid recipient addresses.
This can help to prevent the mail queue from filling up with
@ -237,9 +263,11 @@ However, recipient address verification probes can increase the
load on down-stream MTAs when you're being flooded by backscatter
bounces, or when some spammer is mounting a dictionary attack. </p>
<p> By default, address verification results are not saved. To avoid
probing the same address repeatedly, you can store the result in a
<a href="#caching">persistent database</a> as described later. </p>
<p> By default, address verification results are saved in a <a
href="#caching">persistent database</a> (Postfix version 2.7 and
later; with earlier versions, specify the database in main.cf as
described later). The persistent database helps to avoid probing
the same address repeatedly. </p>
<blockquote>
<pre>
@ -299,11 +327,13 @@ in forged email. </p>
# Postfix 2.6 and later.
# unverified_sender_defer_code = 250
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
# Note 2: Avoid hash files here. Use btree instead.
address_verify_map = btree:/var/lib/postfix/verify
/etc/postfix/sender_access:
# Don't do this when you handle lots of email.
aol.com reject_unverified_sender
hotmail.com reject_unverified_sender
bigfoot.com reject_unverified_sender
@ -344,6 +374,7 @@ you can see what mail would be blocked: </p>
# Postfix 2.6 and later.
# unverified_sender_reject_reason = Address verification failed
# Default setting for Postfix 2.7 and later.
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
# Note 2: Avoid hash files here. Use btree instead.
address_verify_map = btree:/var/lib/postfix/verify
@ -403,7 +434,8 @@ sender address verification probe fails with some temporary error.
<h2><a name="caching">Address verification database</a></h2>
<p> To improve performance, the Postfix verify(8) daemon can save
address verification results to a persistent database. The
address verification results to a persistent database. This is
enabled by default with Postfix 2.7 and later. The
address_verify_map (NOTE: singular) configuration parameter specifies
persistent storage for sender or recipient address verification
results. If you specify an empty value, all address verification

125
postfix/proto/OVERVIEW.html
View File

@ -651,31 +651,126 @@ align="center" bgcolor="#f0f0ff"> smtp<br> session<br> cache </td>
<li> <p> The verify(8) server verifies that a sender or recipient
address is deliverable before the smtpd(8) server accepts it. The
verify(8) server injects probe messages into the Postfix queue and
processes status updates from delivery agents and/or queue manager.
verify(8) server queries a cache with address verification results.
If a result is not found, the verify(8) server injects a probe
message into the Postfix queue and processes the status update from
a delivery agent or queue manager.
This process is described in the ADDRESS_VERIFICATION_README
document. The verify(8) service is available with Postfix version
2.1 and later. </p>
<table>
<tr> <td> Network </td> <td> <tt> -&gt; </tt> </td> <td align="center"
bgcolor="#f0f0ff"> smtpd(8) </td> <td> <tt> &lt;-&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> verify(8) </td> <td> <tt>
-&gt; </tt> </td> <td align="center" bgcolor="#f0f0ff"> cleanup(8)
</td> <td> <tt> -&gt; </tt> </td> <td align="center" bgcolor="#f0f0ff">
qmgr(8)<br> Postfix <br>queue </td> <td> <tt> -&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> Delivery<br> agents</td>
<tr>
<td rowspan="2" colspan="5" align="center" valign="middle">
&nbsp; </td> <td rowspan="3" align="center" valign="bottom">
<tt> -&gt; </tt> </td> <td rowspan="3" align="center"
valign="middle"> probe<br> message </td> <td rowspan="3"
align="center" valign="middle"> <tt> -&gt; </tt> </td> <td
rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> mail<br> queue </td>
</tr>
<tr> <td colspan="5"> </td> <td align="right"> <table> <tr> <td>
\ </td> <td> </td> </tr> <tr> <td> </td> <td> \ </td> </tr> </table>
</td> <td align="center" valign="bottom"> <tt> &lt;- </tt> </td>
<td valign="bottom"> <tt> &lt;- </tt> </td> <td align="center">
<tt> |<br> v </tt> </td> <td align="center"> <table> <tr> <td>
</td> <td> / </td> </tr> <tr> <td> / </td> <td> </td> </tr> </table>
<tr> </tr>
<tr>
<td rowspan="3" align="center" valign="middle"> Network </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td> <td rowspan="3" bgcolor="#f0f0ff" align="center"
valign="middle"> smtpd(8) </td> <td rowspan="3" align="center"
valign="middle"> <tt> &lt;-&gt; </tt> </td> <td rowspan="3"
bgcolor="#f0f0ff" align="center" valign="middle"> verify(8)
</td>
</tr>
<tr>
<td rowspan="1" colspan="3"> </td> <td rowspan="1" align="center"
valign="middle"> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr>
<td rowspan="3" align="center" valign="top"> <tt> &lt;- </tt>
</td> <td rowspan="3" align="center" valign="middle"> probe<br>
status </td> <td rowspan="3" align="center" valign="middle">
<tt> &lt;- </tt> </td> <td rowspan="3" bgcolor="#f0f0ff"
align="center" valign="middle"> Postfix<br> delivery<br> agents
</td> <td rowspan="3" align="left" valign="middle"> <tt>-&gt;</tt>
Local<br> <tt>-&gt;</tt> Network</td>
</tr>
<tr>
<td rowspan="3" colspan="4" align="center" valign="middle">
&nbsp; </td> <td rowspan="3" align="center" valign="middle">
<tt> ^</tt><br> <tt> |</tt><br> <tt> v</tt> </td>
</tr>
<tr> </tr>
<tr> <td colspan="4"> &nbsp; </td> </tr>
<tr>
<td colspan="4" align="center" valign="middle"> &nbsp; </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Address<br>
verification<br> cache </td>
</tr>
</table>
<li> <p> The postscreen(8) server can be put "in front" of Postfix
smtpd(8) processes. Its purpose is to accept connections from the
network and to decide what SMTP clients are allowed to talk to
Postfix. According to the 2008 MessageLabs annual report, 81% of
all email was spam, and 90% of that was sent by botnets. While
postscreen(8) keeps the zombies away, more smtpd(8) processes remain
available for legitimate clients. </p>
<p> The postscreen(8) server is still evolving, and is likely to
undergo changes that break compatibility with earlier versions.
For this reason the postscreen(8) server is not installed with the
stable Postfix release. </p>
<table>
<tr> <td> zombie </td> </tr>
<tr> <td> </td> <td align="left"> <tt> \ </tt> </td> </tr>
<tr> <td> zombie </td> <td align="left"> <tt> - </tt> </td> <td>
</td> <td> </td> <td> </td> <td align="right"> <tt> - </tt> </td>
<td bgcolor="#f0f0ff" align="center"> smtpd(8) </td> </tr>
<tr> <td> </td> <td align="right"> <tt> \ </tt> </td> <td> </td>
<td align="left"> <tt> / </tt> </td> </tr>
<tr> <td bgcolor="#f0f0ff" align="center"> other </td> <td> <tt>
--- </tt> </td> <td bgcolor="#f0f0ff" align="center" valign="middle">
postscreen(8) </td> </tr>
<tr> <td> </td> <td align="right"> <tt> / </tt> </td> <td> </td>
<td align="right"> <tt> \ </tt> </td> </tr>
<tr> <td bgcolor="#f0f0ff" align="center"> other </td> <td align="left">
<tt> - </tt> </td> <td> </td> <td> </td> <td> </td> <td align="right">
<tt> - </tt> </td> <td bgcolor="#f0f0ff" align="center"> smtpd(8)
</td> </tr>
<tr> <td> </td> <td align="left"> <tt> / </tt> </td> </tr>
<tr> <td> zombie </td> </tr>
</table>
</ul>

2415
postfix/proto/SASL_README.html
View File

File diff suppressed because it is too large Load Diff

2
postfix/proto/TLS_README.html
View File

@ -2237,7 +2237,7 @@ as specified by the smtp_tls_mandatory_ciphers configuration
parameter. This setting controls the minimum acceptable SMTP client
TLS cipher grade for use with mandatory TLS encryption. The default
value "medium" is suitable for most destinations with which you may
want to enforce TLS, and is beyond the reach of today's crypt-analytic
want to enforce TLS, and is beyond the reach of today's cryptanalytic
methods. See smtp_tls_policy_maps for information on how to configure
ciphers on a per-destination basis. </p>

3
postfix/proto/pcre_table
View File

@ -66,7 +66,8 @@
# starts with whitespace continues a logical line.
# .PP
# Each pattern is a perl-like regular expression. The expression
# delimiter can be any character, except whitespace or characters
# delimiter can be any non-alphanumerical character, except
# whitespace or characters
# that have special meaning (traditionally the forward slash is used).
# The regular expression can contain whitespace.
#

173
postfix/proto/postconf.proto
View File

@ -1269,8 +1269,8 @@ domain.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in master.cf.
The <i>:nexthop</i> part is optional. For more details see the
transport(5) manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -2297,8 +2297,8 @@ which is just the name of a service that is defined the master.cf file.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in master.cf.
The <i>:nexthop</i> part is optional. For more details see the
transport(5) manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -3569,10 +3569,10 @@ relocated_maps = hash:/etc/postfix/relocated
%PARAM require_home_directory no
<p>
Whether or not a local(8) recipient's home directory must exist
Require that a local(8) recipient's home directory exists
before mail delivery is attempted. By default this test is disabled.
It can be useful for environments that import home directories to
the mail server (NOT RECOMMENDED).
the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED).
</p>
%PARAM resolve_dequoted_address yes
@ -5404,7 +5404,7 @@ more of the following, separated by comma or whitespace. </p>
<dt><b>speed_adjust</b></dt>
<dd> Do not connect to a before-queue content filter until an entire
<dd> <p> Do not connect to a before-queue content filter until an entire
message has been received. This reduces the number of simultaneous
before-queue content filter processes. </p>
@ -7609,8 +7609,8 @@ the transport(5) table.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in master.cf.
The <i>:nexthop</i> part is optional. For more details see the
transport(5) manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -8258,8 +8258,8 @@ This information can be overruled with the transport(5) table.
<p>
Specify a string of the form <i>transport:nexthop</i>, where <i>transport</i>
is the name of a mail delivery transport defined in master.cf.
The <i>:nexthop</i> part is optional. For more details see the
transport(5) manual page.
The <i>:nexthop</i> destination is optional; its syntax is documented
in the manual page of the corresponding delivery agent.
</p>
<p>
@ -10522,7 +10522,7 @@ smtp_tls_security_level = none
# Opportunistic TLS.
smtp_tls_security_level = may
# Postfix &ge; 2.6:
# Do not tweak opportunistic ciphers unless it is essential
# Do not tweak opportunistic ciphers or protocol unless it is essential
# to do so (if a security vulnerability is found in the SSL library that
# can be mitigated by disabling a particular protocol or raising the
# cipher grade from "export" to "low" or "medium").
@ -10769,65 +10769,46 @@ meanings. </p>
%PARAM smtpd_tls_mandatory_ciphers medium
<p> The minimum TLS cipher grade that the Postfix SMTP server
will use with mandatory TLS encryption. Cipher types listed in
smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are
excluded from the base definition of the selected cipher grade. See
smtpd_tls_ciphers for cipher controls that apply to opportunistic
TLS. </p>
<p> The minimum TLS cipher grade that the Postfix SMTP server will
use with mandatory TLS encryption. The default grade ("medium") is
sufficiently strong that any benefit from globally restricting TLS
sessions to a more stringent grade is likely negligible, especially
given the fact that many implementations still do not offer any stronger
("high" grade) ciphers, while those that do, will always use "high"
grade ciphers. So insisting on "high" grade ciphers is generally
counter-productive. Allowing "export" or "low" ciphers is typically
not a good idea, as systems limited to just these are limited to
obsolete browsers. No known SMTP clients fail to support at least
one "medium" or "high" grade cipher. </p>
<p> The following cipher grades are supported: </p>
<dl>
<dt><b>export</b></dt>
<dd> Enable the mainstream "EXPORT" grade or better OpenSSL ciphers.
<dd> Enable "EXPORT" grade or stronger OpenSSL ciphers.
This is the most appropriate setting for public MX hosts, and is always
used with opportunistic TLS encryption. The underlying cipherlist
is specified via the tls_export_cipherlist configuration parameter,
which you are strongly encouraged to not change. The default value
of tls_export_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the server is configured to ask for
client certificates. If you must always exclude anonymous ciphers,
set "smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers
only when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers =
aNULL". </dd>
which you are strongly encouraged to not change. </dd>
<dt><b>low</b></dt>
<dd> Enable the mainstream "LOW" grade or better OpenSSL ciphers. The
<dd> Enable "LOW" grade or stronger OpenSSL ciphers. The
underlying cipherlist is specified via the tls_low_cipherlist
configuration parameter, which you are strongly encouraged to
not change. The default value of tls_low_cipherlist includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL". </dd>
not change. </dd>
<dt><b>medium</b></dt>
<dd> Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These
are essentially the 128-bit or stronger ciphers. This is the default
minimum strength for mandatory TLS encryption. MSAs that enforce
TLS and have clients that do not support any "MEDIUM" or "HIGH"
grade ciphers, may need to configure a weaker ("low" or "export")
minimum cipher grade. The underlying cipherlist is specified via the
tls_medium_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_medium_cipherlist
includes anonymous ciphers, but these are automatically filtered out if
the server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL". </dd>
<dd> Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit
or longer symmetric bulk-encryption keys. This is the default minimum
strength for mandatory TLS encryption. The underlying cipherlist is
specified via the tls_medium_cipherlist configuration parameter, which
you are strongly encouraged to not change. </dd>
<dt><b>high</b></dt>
<dd> Enable only the mainstream "HIGH" grade OpenSSL ciphers. The
<dd> Enable only "HIGH" grade OpenSSL ciphers. The
underlying cipherlist is specified via the tls_high_cipherlist
configuration parameter, which you are strongly encouraged to
not change. The default value of tls_high_cipherlist includes
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. If you must
always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers =
aNULL". To exclude anonymous ciphers only when TLS is enforced, set
"smtpd_tls_mandatory_exclude_ciphers = aNULL". </dd>
not change. </dd>
<dt><b>null</b></dt>
<dd> Enable only the "NULL" OpenSSL ciphers, these provide authentication
@ -10835,12 +10816,25 @@ without encryption. This setting is only appropriate in the rare
case that all clients are prepared to use NULL ciphers (not normally
enabled in TLS clients). The underlying cipherlist is specified via the
tls_null_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_null_cipherlist
excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer
data integrity without encryption or authentication). </dd>
encouraged to not change. </dd>
</dl>
<p> Cipher types listed in
smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are
excluded from the base definition of the selected cipher grade. See
smtpd_tls_ciphers for cipher controls that apply to opportunistic
TLS. </p>
<p> The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
server is configured to ask for client certificates. You are very
unlikely to need to take any steps to exclude anonymous ciphers, they
are excluded automatically as required. If you must exclude anonymous
ciphers even when Postfix does not need or use peer certificates, set
"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only
when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL". </p>
<p> This feature is available in Postfix 2.3 and later. </p>
%PARAM smtpd_tls_exclude_ciphers
@ -10889,7 +10883,7 @@ works in addition to the exclusions listed with smtpd_tls_exclude_ciphers
use with
mandatory TLS encryption. The default value "medium" is suitable
for most destinations with which you may want to enforce TLS, and
is beyond the reach of today's crypt-analytic methods. See
is beyond the reach of today's cryptanalytic methods. See
smtp_tls_policy_maps for information on how to configure ciphers
on a per-destination basis. </p>
@ -10897,47 +10891,32 @@ on a per-destination basis. </p>
<dl>
<dt><b>export</b></dt>
<dd> Enable the mainstream "EXPORT" grade or better OpenSSL
ciphers. This is always used for opportunistic encryption. It is
<dd> Enable "EXPORT" grade or better OpenSSL
ciphers. This is the default for opportunistic encryption. It is
not recommended for mandatory encryption unless you must enforce TLS
with "crippled" peers. The underlying cipherlist is specified via the
tls_export_cipherlist configuration parameter, which you are strongly
encouraged to not change. The default value of tls_export_cipherlist
includes anonymous ciphers, but these are automatically filtered out if
the client is configured to verify server certificates. If you must
exclude anonymous ciphers also at the "encrypt" security level, set
"smtp_tls_mandatory_exclude_ciphers = aNULL". </dd>
encouraged to not change. </dd>
<dt><b>low</b></dt>
<dd> Enable the mainstream "LOW" grade or better OpenSSL ciphers. This
<dd> Enable "LOW" grade or better OpenSSL ciphers. This
setting is only appropriate for internal mail servers. The underlying
cipherlist is specified via the tls_low_cipherlist configuration
parameter, which you are strongly encouraged to not change. The default
value of tls_low_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL". </dd>
parameter, which you are strongly encouraged to not change. </dd>
<dt><b>medium</b></dt>
<dd> Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers.
<dd> Enable "MEDIUM" grade or better OpenSSL ciphers.
The underlying cipherlist is specified via the tls_medium_cipherlist
configuration parameter, which you are strongly encouraged to not change.
The default value of tls_medium_cipherlist includes anonymous ciphers,
but these are automatically filtered out if the client is configured to
verify server certificates. If you must exclude anonymous ciphers also
at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers
= aNULL". </dd>
</dd>
<dt><b>high</b></dt>
<dd> Enable only the mainstream "HIGH" grade OpenSSL ciphers. This
setting is appropriate when all mandatory TLS destinations support
some of "HIGH" grade ciphers, this is not uncommon. The underlying
cipherlist is specified via the tls_high_cipherlist configuration
parameter, which you are strongly encouraged to not change. The default
value of tls_high_cipherlist includes anonymous ciphers, but these are
automatically filtered out if the client is configured to verify server
certificates. If you must exclude anonymous ciphers also at the "encrypt"
security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL". </dd>
<dd> Enable only "HIGH" grade OpenSSL ciphers. This setting may
be appropriate when all mandatory TLS destinations (e.g. when all
mail is routed to a suitably capable relayhost) support at least one
"HIGH" grade cipher. The underlying cipherlist is specified via the
tls_high_cipherlist configuration parameter, which you are strongly
encouraged to not change. </dd>
<dt><b>null</b></dt>
<dd> Enable only the "NULL" OpenSSL ciphers, these provide authentication
@ -10947,12 +10926,20 @@ in TLS servers). A plausible use-case is an LMTP server listening on a
UNIX-domain socket that is configured to support "NULL" ciphers. The
underlying cipherlist is specified via the tls_null_cipherlist
configuration parameter, which you are strongly encouraged to not
change. The default value of tls_null_cipherlist excludes anonymous
ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without
encryption or authentication). </dd>
change. </dd>
</dl>
<p> The underlying cipherlists for grades other than "null" include
anonymous ciphers, but these are automatically filtered out if the
Postfix SMTP client is configured to verify server certificates.
You are very unlikely to need to take any steps to exclude anonymous
ciphers, they are excluded automatically as necessary. If you must
exclude anonymous ciphers at the "may" or "encrypt" security levels,
when the Postfix SMTP client does not need or use peer certificates, set
"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when
TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL". </p>
<p> This feature is available in Postfix 2.3 and later. </p>
%PARAM smtp_tls_exclude_ciphers
@ -12552,7 +12539,7 @@ parameter. Specify one of the following: </p>
<dt> continue </dt>
<dd> Forward the connection to a real SMTP server process. </p>
<dd> Forward the connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -12576,7 +12563,7 @@ parameter. Specify one of the following: </p>
elapsed. If the client is listed at the DNS blocklist domains
specified with the postscreen_dnsbl_sites parameter, execute the
action specified with the postscreen_dnsbl_action parameter, otherwise
forward the connection to a real SMTP server process. </p>
forward the connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -12604,7 +12591,7 @@ postscreen_greet_wait parameter. Specify one of the following:
<dd> Continue waiting until the postscreen_greet_wait time has
elapsed, and report whether the client is listed at the DNSBL sites
specified with the postscreen_dnsbl_sites parameter. Do not
forward the broken connection to a real SMTP server process. </p>
forward the broken connection to a real SMTP server process. </dd>
<dt> drop </dt>
@ -12660,7 +12647,7 @@ elapsed, and report whether the client triggers a PREGREET or HANGUP
error, or whether the client is listed at the DNSBL sites specified
with the postscreen_dnsbl_sites parameter. Take the corresponding
action, or forward the connection to a real SMTP server process.
</p>
</dd>
<dt> drop </dt>
@ -12800,7 +12787,7 @@ configuration parameter. See there for details. </p>
<p> This feature is available in Postfix 2.7 and later. </p>
%PARAM empty_address_default_transport_maps_lookup_key <>
%PARAM empty_address_default_transport_maps_lookup_key &lt;&gt;
<p> The sender_dependent_default_transport_maps search string that
will be used instead of the null sender address. </p>

3
postfix/proto/regexp_table
View File

@ -70,7 +70,8 @@
# \fBre_format\fR(7) with 4.4BSD, in \fBregex\fR(5) with Solaris, and in
# \fBregex\fR(7) with Linux. Other systems may use other document names.
#
# The expression delimiter can be any character, except whitespace
# The expression delimiter can be any non-alphanumerical
# character, except whitespace
# or characters that have special meaning (traditionally the forward
# slash is used). The regular expression can contain whitespace.
#

4
postfix/src/global/mail_version.h
View File

@ -20,8 +20,8 @@
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
#define MAIL_RELEASE_DATE "20100117"
#define MAIL_VERSION_NUMBER "2.7"
#define MAIL_RELEASE_DATE "20100203"
#define MAIL_VERSION_NUMBER "2.8"
#ifdef SNAPSHOT
# define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE

3
postfix/src/postqueue/postqueue.c
View File

@ -48,8 +48,7 @@
/* Each queue entry shows the queue file ID, message
/* size, arrival time, sender, and the recipients that still need to
/* be delivered. If mail could not be delivered upon the last attempt,
/* the reason for failure is shown. This mode of operation is implemented
/* by executing the \fBpostqueue\fR(1) command. The queue ID string
/* the reason for failure is shown. The queue ID string
/* is followed by an optional status character:
/* .RS
/* .IP \fB*\fR

6
postfix/src/proxymap/proxymap.c
View File

@ -593,12 +593,6 @@ static void post_jail_init(char *service_name, char **unused_argv)
}
myfree(saved_filter);
/*
* This process is called by clients that already enforce the max_idle
* time, so we don't have to do it another time.
*/
var_idle_limit = 1;
/*
* Never, ever, get killed by a master signal, as that could corrupt a
* persistent database when we're in the middle of an update.

10
postfix/src/smtpd/smtpd.c
View File

@ -92,8 +92,6 @@
/* Resolve an address that ends in the "@" null domain as if the
/* local hostname were specified, instead of rejecting the address as
/* invalid.
/* .IP "\fBsmtpd_command_filter (empty)\fR"
/* A mechanism to transform commands from remote SMTP clients.
/* .IP "\fBsmtpd_reject_unlisted_sender (no)\fR"
/* Request that the Postfix SMTP server rejects mail from unknown
/* sender addresses, even when no explicit reject_unlisted_sender
@ -125,6 +123,10 @@
/* Available in Postfix version 2.6 and later:
/* .IP "\fBtcp_windowsize (0)\fR"
/* An optional workaround for routers that break TCP window scaling.
/* .PP
/* Available in Postfix version 2.7 and later:
/* .IP "\fBsmtpd_command_filter (empty)\fR"
/* A mechanism to transform commands from remote SMTP clients.
/* ADDRESS REWRITING CONTROLS
/* .ad
/* .fi
@ -4150,8 +4152,8 @@ typedef struct SMTPD_CMD {
#define SMTPD_CMD_FLAG_LAST (1<<2) /* last in PIPELINING command group */
static SMTPD_CMD smtpd_cmd_table[] = {
SMTPD_CMD_HELO, helo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS,
SMTPD_CMD_EHLO, ehlo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS,
SMTPD_CMD_HELO, helo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS | SMTPD_CMD_FLAG_LAST,
SMTPD_CMD_EHLO, ehlo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS | SMTPD_CMD_FLAG_LAST,
#ifdef USE_TLS
SMTPD_CMD_STARTTLS, starttls_cmd, SMTPD_CMD_FLAG_PRE_TLS,
#endif

21
postfix/src/smtpd/smtpd_proxy.c
View File

@ -74,9 +74,10 @@
/* 2xx or 3xx proxy server response is replaced by a generic
/* error response to avoid support problems.
/* In case of error, smtpd_proxy_create() updates the
/* state->error_mask and state->err fields, and leaves the the
/* proxy handle in an unconnected state. Destroy the handle
/* after reporting the error reply in the proxy->buffer field.
/* state->error_mask and state->err fields, and leaves the
/* SMTPD_PROXY handle in an unconnected state. Destroy the
/* handle after reporting the error reply in the proxy->buffer
/* field.
/*
/* proxy->cmd() formats and either buffers up the command and
/* expected response until the entire message is received, or
@ -374,8 +375,8 @@ static int smtpd_proxy_connect(SMTPD_STATE *state)
* Send our own EHLO command. If this fails then we have a problem
* because the proxy should always accept our EHLO command. Make up our
* own response instead of passing back a negative EHLO reply: the proxy
* open is delayed to the point that the client expects a MAIL FROM or
* RCPT TO reply.
* open is delayed to the point that the remote SMTP client expects a
* MAIL FROM or RCPT TO reply.
*/
if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "EHLO %s",
proxy->ehlo_name)) {
@ -403,8 +404,8 @@ static int smtpd_proxy_connect(SMTPD_STATE *state)
* Send XFORWARD attributes. For robustness, explicitly specify what SMTP
* session attributes are known and unknown. Make up our own response
* instead of passing back a negative XFORWARD reply: the proxy open is
* delayed to the point that the client expects a MAIL FROM or RCPT TO
* reply.
* delayed to the point that the remote SMTP client expects a MAIL FROM
* or RCPT TO reply.
*/
if (server_xforward_features) {
buf = vstring_alloc(100);
@ -443,9 +444,9 @@ static int smtpd_proxy_connect(SMTPD_STATE *state)
}
/*
* Pass-through the client's MAIL FROM command. If this fails, then we
* have a problem because the proxy should always accept any MAIL FROM
* command that was accepted by us.
* Pass-through the remote SMTP client's MAIL FROM command. If this
* fails, then we have a problem because the proxy should always accept
* any MAIL FROM command that was accepted by us.
*/
if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "%s",
proxy->mail_from) != 0) {

6
postfix/src/trivial-rewrite/trivial-rewrite.c
View File

@ -565,12 +565,6 @@ static void post_jail_init(char *unused_name, char **unused_argv)
if (resolve_verify.transport_info)
transport_post_init(resolve_verify.transport_info);
check_table_stats(0, (char *) 0);
/*
* This process is called by clients that already enforce the max_idle
* time, so we don't have to do it another time.
*/
var_idle_limit = 1;
}
MAIL_VERSION_STAMP_DECLARE;

20
postfix/src/verify/verify.c
View File

@ -30,7 +30,8 @@
/* .IP "\fBupdate\fI address status text\fR"
/* Update the status and text of the specified address.
/* .IP "\fBquery\fI address\fR"
/* Look up the \fIstatus\fR and \fItext\fR for the specified address.
/* Look up the \fIstatus\fR and \fItext\fR for the specified
/* \fIaddress\fR.
/* If the status is unknown, a probe is sent and an "in progress"
/* status is returned.
/* SECURITY
@ -41,7 +42,8 @@
/* The verify server can run chrooted at fixed low privilege.
/*
/* The address verification server can be coerced to store
/* unlimited amounts of garbage. Limiting the cache size
/* unlimited amounts of garbage. Limiting the cache expiry
/* time
/* trades one problem (disk space exhaustion) for another
/* one (poor response time to client requests).
/*
@ -55,11 +57,13 @@
/* DIAGNOSTICS
/* Problems and transactions are logged to \fBsyslogd\fR(8).
/* BUGS
/* The address verification service is suitable only for sites that
/* handle a low mail volume. Verification probes add additional
/* traffic to the mail queue and perform poorly under high load.
/* Servers may blacklist sites that probe excessively, or that
/* probe excessively for non-existent recipient addresses.
/* Address verification probe messages add additional traffic
/* to the mail queue.
/* Recipient verification may cause an increased load on
/* down-stream servers in the case of a dictionary attack or
/* a flood of backscatter bounces.
/* Sender address verification may cause your site to be
/* blacklisted by some providers.
/*
/* If the persistent database ever gets corrupted then the world
/* comes to an end and human intervention is needed. This violates
@ -69,7 +73,7 @@
/* .fi
/* Changes to \fBmain.cf\fR are not picked up automatically,
/* as \fBverify\fR(8)
/* processes are persistent. Use the command "\fBpostfix reload\fR" after
/* processes are long-lived. Use the command "\fBpostfix reload\fR" after
/* a configuration change.
/*
/* The text below provides only a parameter summary. See