mirror of
https://github.com/vdukhovni/postfix
synced 2025-08-29 05:07:58 +00:00
postfix-3.1-20150201
This commit is contained in:
Wietse Venema
Viktor Dukhovni
parent
f65d68d976
commit
23f9de9fd0
@ -19672,7 +19672,7 @@ Apologies for any names omitted.
|
||||
posttls-finger/posttls-finger.c.
|
||||
|
||||
Feature: configurable TLS session-ticket cipher (default:
|
||||
tls_sesion_ticket_cipher = aes-128-cbc). Viktor Dukhovni
|
||||
tls_session_ticket_cipher = aes-128-cbc). Viktor Dukhovni
|
||||
and Wietse. Files: mantools/postlink, smtpd/smtpd.c,
|
||||
proto/postconf.proto, global/mail_params.h, tls/tls_misc.c,
|
||||
tls/tls_scache.h, tls/tls_server.c.
|
||||
@ -19693,7 +19693,7 @@ Apologies for any names omitted.
|
||||
|
||||
20140501
|
||||
|
||||
Cleanup: postcreen_dnsbl_timeout parameter. Files:
|
||||
Cleanup: postscreen_dnsbl_timeout parameter. Files:
|
||||
mantools/postlink, proto/postconf.proto, global/mail_params.h,
|
||||
postscreen/postscreen.c, postscreen/postscreen_dnsbl.c.
|
||||
|
||||
@ -20820,7 +20820,7 @@ Apologies for any names omitted.
|
||||
|
||||
20141126
|
||||
|
||||
Feature: "inline:{key=value, { key = text with comma/space}}
|
||||
Feature: "inline:{key=value, { key = text with comma/space}}"
|
||||
avoids the need to create a database for just a few entries.
|
||||
Files: util/dict_inline.[hc], mantools/postlink,
|
||||
proto/DATABASE_README.html. postconf/postconf.c (manpage),
|
||||
@ -21564,3 +21564,10 @@ Apologies for any names omitted.
|
||||
Cleanup: HTML entities in *roff manpage source. File:
|
||||
mantools/fixman, proto/postconf.proto, smtpd/smtpd.c,
|
||||
trivial-rewrite/trivial-rewrite.c.
|
||||
|
||||
20150201
|
||||
|
||||
Usability: in error messages, print the CAfile and CApath
|
||||
value in double quotes, to clue in people who specify quoted
|
||||
pathnames in main.cf. Viktor Dukhovni. Files: tls/tls_certkey.c
|
||||
and testing code in posttls-finger/posttls-finger.c.
|
||||
|
||||
@ -148,50 +148,50 @@ compiler. Here are a few examples:
|
||||
|
||||
and so on. In some cases, optimization is turned off automatically.
|
||||
|
||||
4.3 - Building with Postfix shared libraries and database plugins (Postfix >=
|
||||
3.0)
|
||||
4.3 - Building with Postfix dynamically-linked libraries and database plugins
|
||||
(Postfix >= 3.0)
|
||||
|
||||
Postfix shared-library and database plugin support exists for recent versions
|
||||
of Linux, FreeBSD and MacOS X. Shared-library builds may become the default at
|
||||
some point in the future.
|
||||
Postfix dynamically-linked library and database plugin support exists for
|
||||
recent versions of Linux, FreeBSD and MacOS X. Dynamically-linked library
|
||||
builds may become the default at some point in the future.
|
||||
|
||||
Overview of topics:
|
||||
|
||||
* 4.3.1 Turning on Postfix shared-library support
|
||||
* 4.3.1 Turning on Postfix dynamically-linked library support
|
||||
* 4.3.2 Turning on Postfix database-plugin support
|
||||
* 4.3.3 Customizing Postfix shared libraries and database plugins
|
||||
* 4.3.3 Customizing Postfix dynamically-linked libraries and database plugins
|
||||
* 4.4.4 Tips for distribution maintainers
|
||||
|
||||
Note: directories with Postfix shared libraries or database plugins should
|
||||
contain only postfix-related files. Postfix shared libraries and database
|
||||
plugins should not be installed in a "public" system directory such as /usr/lib
|
||||
or /usr/local/lib. Linking Postfix shared-library or database-plugin files into
|
||||
non-Postfix programs is not supported. Postfix shared libraries and database
|
||||
plugins implement a Postfix-internal API that changes without maintaining
|
||||
compatibility.
|
||||
Note: directories with Postfix dynamically-linked libraries or database plugins
|
||||
should contain only postfix-related files. Postfix dynamically-linked libraries
|
||||
and database plugins should not be installed in a "public" system directory
|
||||
such as /usr/lib or /usr/local/lib. Linking Postfix dynamically-linked library
|
||||
or database-plugin files into non-Postfix programs is not supported. Postfix
|
||||
dynamically-linked libraries and database plugins implement a Postfix-internal
|
||||
API that changes without maintaining compatibility.
|
||||
|
||||
4.3.1 Turning on Postfix shared-library support
|
||||
4.3.1 Turning on Postfix dynamically-linked library support
|
||||
|
||||
Postfix can be built with Postfix shared libraries (files typically named
|
||||
libpostfix-*.so). Postfix shared libraries add minor run-time overhead and
|
||||
result in significantly-smaller Postfix executable files.
|
||||
Postfix can be built with Postfix dynamically-linked libraries (files typically
|
||||
named libpostfix-*.so). Postfix dynamically-linked libraries add minor run-time
|
||||
overhead and result in significantly-smaller Postfix executable files.
|
||||
|
||||
Specify "shared=yes" on the "make makefiles" command line to build Postfix with
|
||||
shared-library support.
|
||||
dynamically-linked library support.
|
||||
|
||||
$ make makefiles shared=yes ...other arguments...
|
||||
$ make
|
||||
|
||||
(Specify "make makefiles shared=no" to explicitly disable Postfix shared-
|
||||
library support).
|
||||
(Specify "make makefiles shared=no" to explicitly disable Postfix dynamically-
|
||||
linked library support).
|
||||
|
||||
This installs shared libraries in $shlib_directory, typically /usr/lib/postfix
|
||||
or /usr/local/lib/postfix, with file names libpostfix-name.so, where the name
|
||||
is a source-code directory name such as "util" or "global".
|
||||
This installs dynamically-linked libraries in $shlib_directory, typically /usr/
|
||||
lib/postfix or /usr/local/lib/postfix, with file names libpostfix-name.so,
|
||||
where the name is a source-code directory name such as "util" or "global".
|
||||
|
||||
See section 4.3.3 "Customizing Postfix shared libraries and database plugins"
|
||||
below for how to customize the Postfix shared-library location, including
|
||||
support to upgrade a running mail system safely.
|
||||
See section 4.3.3 "Customizing Postfix dynamically-linked libraries and
|
||||
database plugins" below for how to customize the Postfix dynamically-linked
|
||||
library location, including support to upgrade a running mail system safely.
|
||||
|
||||
4.3.2 Turning on Postfix database-plugin support
|
||||
|
||||
@ -211,11 +211,11 @@ dynamicmaps feature.
|
||||
(Specify "make makefiles dynamicmaps=no" to explicitly disable Postfix
|
||||
database-plugin support).
|
||||
|
||||
This implicitly enables shared-library support, installs the configuration file
|
||||
dynamicmaps.cf in $meta_directory (usually, /etc/postfix or /usr/local/etc/
|
||||
postfix), and installs database plugins in $shlib_directory (see above).
|
||||
Database plugins are named postfix-type.so where the type is a database type
|
||||
such as "cdb" or "ldap".
|
||||
This implicitly enables dynamically-linked library support, installs the
|
||||
configuration file dynamicmaps.cf in $meta_directory (usually, /etc/postfix or
|
||||
/usr/local/etc/postfix), and installs database plugins in $shlib_directory (see
|
||||
above). Database plugins are named postfix-type.so where the type is a database
|
||||
type such as "cdb" or "ldap".
|
||||
|
||||
NOTE: The Postfix 3.0 build procedure expects that you specify database
|
||||
library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc.
|
||||
@ -232,23 +232,24 @@ such as "cdb" or "ldap".
|
||||
See the next section for how to customize the location and version of Postfix
|
||||
database plugins and the location of the file dynamicmaps.cf.
|
||||
|
||||
4.3.3 Customizing Postfix shared libraries and database plugins
|
||||
4.3.3 Customizing Postfix dynamically-linked libraries and database plugins
|
||||
|
||||
Customizing the location of Postfix shared libraries and database plugins
|
||||
Customizing the location of Postfix dynamically-linked libraries and database
|
||||
plugins
|
||||
|
||||
As a reminder, the directories with Postfix shared libraries or database
|
||||
plugins should contain only Postfix-related files. Linking these files into
|
||||
other programs is not supported.
|
||||
As a reminder, the directories with Postfix dynamically-linked libraries or
|
||||
database plugins should contain only Postfix-related files. Linking these files
|
||||
into other programs is not supported.
|
||||
|
||||
To override the default location of Postfix shared libraries and database
|
||||
plugins specify, for example:
|
||||
To override the default location of Postfix dynamically-linked libraries and
|
||||
database plugins specify, for example:
|
||||
|
||||
$ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
|
||||
|
||||
If you intend to upgrade Postfix without stopping the mail system, then you
|
||||
should append the Postfix release version to the shlib_directory pathname, to
|
||||
eliminate the possibility that programs will link with shared libraries or
|
||||
database plugins from the wrong Postfix version. For example:
|
||||
eliminate the possibility that programs will link with dynamically-linked
|
||||
libraries or database plugins from the wrong Postfix version. For example:
|
||||
|
||||
$ make makefiles shared=yes \
|
||||
shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
|
||||
@ -329,7 +330,7 @@ inconsistent results with different versions of the make(1) command.
|
||||
package without having to edit postfix-files or dynamicmaps.cf. Instead,
|
||||
you give that plugin its own configuration files dynamicmaps.cf.d and
|
||||
postfix-files.d, and you add or remove those configuration files along with
|
||||
the database plugin shared object.
|
||||
the database plugin dynamically-linked object.
|
||||
|
||||
* Each configuration file under the directory dynamicmaps.cf.d must have the
|
||||
same format as the configuration file dynamicmaps.cf. There is no
|
||||
|
||||
@ -148,50 +148,50 @@ compiler. Here are a few examples:
|
||||
|
||||
and so on. In some cases, optimization is turned off automatically.
|
||||
|
||||
44..33 -- BBuuiillddiinngg wwiitthh PPoossttffiixx sshhaarreedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss ((PPoossttffiixx >>==
|
||||
33..00))
|
||||
44..33 -- BBuuiillddiinngg wwiitthh PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
|
||||
((PPoossttffiixx >>== 33..00))
|
||||
|
||||
Postfix shared-library and database plugin support exists for recent versions
|
||||
of Linux, FreeBSD and MacOS X. Shared-library builds may become the default at
|
||||
some point in the future.
|
||||
Postfix dynamically-linked library and database plugin support exists for
|
||||
recent versions of Linux, FreeBSD and MacOS X. Dynamically-linked library
|
||||
builds may become the default at some point in the future.
|
||||
|
||||
Overview of topics:
|
||||
|
||||
* 4.3.1 Turning on Postfix shared-library support
|
||||
* 4.3.1 Turning on Postfix dynamically-linked library support
|
||||
* 4.3.2 Turning on Postfix database-plugin support
|
||||
* 4.3.3 Customizing Postfix shared libraries and database plugins
|
||||
* 4.3.3 Customizing Postfix dynamically-linked libraries and database plugins
|
||||
* 4.4.4 Tips for distribution maintainers
|
||||
|
||||
Note: directories with Postfix shared libraries or database plugins should
|
||||
contain only postfix-related files. Postfix shared libraries and database
|
||||
plugins should not be installed in a "public" system directory such as /usr/lib
|
||||
or /usr/local/lib. Linking Postfix shared-library or database-plugin files into
|
||||
non-Postfix programs is not supported. Postfix shared libraries and database
|
||||
plugins implement a Postfix-internal API that changes without maintaining
|
||||
compatibility.
|
||||
Note: directories with Postfix dynamically-linked libraries or database plugins
|
||||
should contain only postfix-related files. Postfix dynamically-linked libraries
|
||||
and database plugins should not be installed in a "public" system directory
|
||||
such as /usr/lib or /usr/local/lib. Linking Postfix dynamically-linked library
|
||||
or database-plugin files into non-Postfix programs is not supported. Postfix
|
||||
dynamically-linked libraries and database plugins implement a Postfix-internal
|
||||
API that changes without maintaining compatibility.
|
||||
|
||||
44..33..11 TTuurrnniinngg oonn PPoossttffiixx sshhaarreedd--lliibbrraarryy ssuuppppoorrtt
|
||||
44..33..11 TTuurrnniinngg oonn PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarryy ssuuppppoorrtt
|
||||
|
||||
Postfix can be built with Postfix shared libraries (files typically named
|
||||
libpostfix-*.so). Postfix shared libraries add minor run-time overhead and
|
||||
result in significantly-smaller Postfix executable files.
|
||||
Postfix can be built with Postfix dynamically-linked libraries (files typically
|
||||
named libpostfix-*.so). Postfix dynamically-linked libraries add minor run-time
|
||||
overhead and result in significantly-smaller Postfix executable files.
|
||||
|
||||
Specify "shared=yes" on the "make makefiles" command line to build Postfix with
|
||||
shared-library support.
|
||||
dynamically-linked library support.
|
||||
|
||||
$ make makefiles shared=yes ...other arguments...
|
||||
$ make
|
||||
|
||||
(Specify "make makefiles shared=no" to explicitly disable Postfix shared-
|
||||
library support).
|
||||
(Specify "make makefiles shared=no" to explicitly disable Postfix dynamically-
|
||||
linked library support).
|
||||
|
||||
This installs shared libraries in $shlib_directory, typically /usr/lib/postfix
|
||||
or /usr/local/lib/postfix, with file names libpostfix-name.so, where the name
|
||||
is a source-code directory name such as "util" or "global".
|
||||
This installs dynamically-linked libraries in $shlib_directory, typically /usr/
|
||||
lib/postfix or /usr/local/lib/postfix, with file names libpostfix-name.so,
|
||||
where the name is a source-code directory name such as "util" or "global".
|
||||
|
||||
See section 4.3.3 "Customizing Postfix shared libraries and database plugins"
|
||||
below for how to customize the Postfix shared-library location, including
|
||||
support to upgrade a running mail system safely.
|
||||
See section 4.3.3 "Customizing Postfix dynamically-linked libraries and
|
||||
database plugins" below for how to customize the Postfix dynamically-linked
|
||||
library location, including support to upgrade a running mail system safely.
|
||||
|
||||
44..33..22 TTuurrnniinngg oonn PPoossttffiixx ddaattaabbaassee--pplluuggiinn ssuuppppoorrtt
|
||||
|
||||
@ -211,11 +211,11 @@ dynamicmaps feature.
|
||||
(Specify "make makefiles dynamicmaps=no" to explicitly disable Postfix
|
||||
database-plugin support).
|
||||
|
||||
This implicitly enables shared-library support, installs the configuration file
|
||||
dynamicmaps.cf in $meta_directory (usually, /etc/postfix or /usr/local/etc/
|
||||
postfix), and installs database plugins in $shlib_directory (see above).
|
||||
Database plugins are named postfix-type.so where the type is a database type
|
||||
such as "cdb" or "ldap".
|
||||
This implicitly enables dynamically-linked library support, installs the
|
||||
configuration file dynamicmaps.cf in $meta_directory (usually, /etc/postfix or
|
||||
/usr/local/etc/postfix), and installs database plugins in $shlib_directory (see
|
||||
above). Database plugins are named postfix-type.so where the type is a database
|
||||
type such as "cdb" or "ldap".
|
||||
|
||||
NOTE: The Postfix 3.0 build procedure expects that you specify database
|
||||
library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc.
|
||||
@ -232,23 +232,24 @@ such as "cdb" or "ldap".
|
||||
See the next section for how to customize the location and version of Postfix
|
||||
database plugins and the location of the file dynamicmaps.cf.
|
||||
|
||||
44..33..33 CCuussttoommiizziinngg PPoossttffiixx sshhaarreedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
|
||||
44..33..33 CCuussttoommiizziinngg PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
|
||||
|
||||
CCuussttoommiizziinngg tthhee llooccaattiioonn ooff PPoossttffiixx sshhaarreedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
|
||||
CCuussttoommiizziinngg tthhee llooccaattiioonn ooff PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee
|
||||
pplluuggiinnss
|
||||
|
||||
As a reminder, the directories with Postfix shared libraries or database
|
||||
plugins should contain only Postfix-related files. Linking these files into
|
||||
other programs is not supported.
|
||||
As a reminder, the directories with Postfix dynamically-linked libraries or
|
||||
database plugins should contain only Postfix-related files. Linking these files
|
||||
into other programs is not supported.
|
||||
|
||||
To override the default location of Postfix shared libraries and database
|
||||
plugins specify, for example:
|
||||
To override the default location of Postfix dynamically-linked libraries and
|
||||
database plugins specify, for example:
|
||||
|
||||
$ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
|
||||
|
||||
If you intend to upgrade Postfix without stopping the mail system, then you
|
||||
should append the Postfix release version to the shlib_directory pathname, to
|
||||
eliminate the possibility that programs will link with shared libraries or
|
||||
database plugins from the wrong Postfix version. For example:
|
||||
eliminate the possibility that programs will link with dynamically-linked
|
||||
libraries or database plugins from the wrong Postfix version. For example:
|
||||
|
||||
$ make makefiles shared=yes \
|
||||
shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
|
||||
@ -329,7 +330,7 @@ inconsistent results with different versions of the make(1) command.
|
||||
package without having to edit postfix-files or dynamicmaps.cf. Instead,
|
||||
you give that plugin its own configuration files dynamicmaps.cf.d and
|
||||
postfix-files.d, and you add or remove those configuration files along with
|
||||
the database plugin shared object.
|
||||
the database plugin dynamically-linked object.
|
||||
|
||||
* Each configuration file under the directory dynamicmaps.cf.d must have the
|
||||
same format as the configuration file dynamicmaps.cf. There is no
|
||||
|
||||
@ -80,7 +80,8 @@ Note 1: syntactically valid NAME and HELO attribute-value elements can be up to
|
||||
255 characters long. The client must not send XCLIENT commands that exceed the
|
||||
512 character limit for SMTP commands. To avoid exceeding the limit the client
|
||||
should send the information in multiple XCLIENT commands; for example, send
|
||||
NAME and ADDR first, then HELO and PROTO.
|
||||
NAME and ADDR last, after HELO and PROTO. Once ADDR is sent, the client is
|
||||
usually no longer authorized to send XCLIENT commands.
|
||||
|
||||
Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified in upper case,
|
||||
lower case or mixed case.
|
||||
|
||||
@ -1,604 +1,17 @@
|
||||
This is the Postfix 3.0 (experimental) release.
|
||||
This is the Postfix 3.1 (experimental) release.
|
||||
|
||||
The stable Postfix release is called postfix-2.11.x where 2=major
|
||||
release number, 11=minor release number, x=patchlevel. The stable
|
||||
The stable Postfix release is called postfix-3.0.x where 3=major
|
||||
release number, 0=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-3.0-yyyymmdd where yyyymmdd is the release date (yyyy=year,
|
||||
postfix-3.1-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.10 or earlier, read RELEASE_NOTES-2.11
|
||||
If you upgrade from Postfix 2.11 or earlier, read RELEASE_NOTES-3.0
|
||||
before proceeding.
|
||||
|
||||
Notes for distribution maintainers
|
||||
----------------------------------
|
||||
|
||||
* New backwards-compatibility safety net.
|
||||
|
||||
With NEW Postfix installs, you MUST install a main.cf file with
|
||||
the setting "compatibility_level = 2". See conf/main.cf for an
|
||||
example.
|
||||
|
||||
With UPGRADES of existing Postfix systems, you MUST NOT change the
|
||||
main.cf compatibility_level setting (if any).
|
||||
|
||||
Several Postfix default settings have changed with Postfix 3.0.
|
||||
To avoid massive breakage, Postfix comes with a safety net that
|
||||
forces Postfix to keep running with backwards-compatible main.cf
|
||||
and master.cf default settings. This safety net depends on the
|
||||
main.cf compatibility_level setting (if any). Details are in
|
||||
COMPATIBILITY_README.
|
||||
|
||||
* New Postfix build system.
|
||||
|
||||
The Postfix build/install procedure has changed to support Postfix
|
||||
shared libraries and database plugins.
|
||||
|
||||
[Update 20140625: As a result of maintainer feedback, 1) the Postfix
|
||||
release version is no longer used as a filename suffix for Postfix
|
||||
shared libraries, database plugins or dynamicmaps.cf; 2) non-executable
|
||||
files have been moved away from $daemon_directory to $meta_directory
|
||||
(usually, /etc/postfix). The release notes below for 20140530 have
|
||||
been updated accordingly.]
|
||||
|
||||
To avoid massive frustration due to broken patches, PLEASE BUILD
|
||||
POSTFIX FIRST WITHOUT APPLYING ANY PATCHES. Follow the INSTALL
|
||||
instructions (see "Building with Postfix shared libraries and
|
||||
database plugins" below), and see how things work and what the
|
||||
shared libraries, database plugin, and configuration files look
|
||||
like. Only then, go ahead and perform your platform-specific
|
||||
customizations.
|
||||
|
||||
Maintainers may also benefit from the makedefs documentation
|
||||
(mantools/srctoman - makedefs | nroff -man | less) with information
|
||||
about build options that are not described in the INSTALL instructions.
|
||||
|
||||
Major changes with snapshot 20141224
|
||||
====================================
|
||||
|
||||
Compile-time argument typechecks of non-printf/scanf-like variadic
|
||||
function argument lists. This change produces no directly-visible
|
||||
result, but it makes Postfix code easier to maintain, and therefore
|
||||
makes new functionality easier to add.
|
||||
|
||||
Major changes with snapshot 20141207
|
||||
====================================
|
||||
|
||||
First stage in the cleanup of old crufty C that dates from the days
|
||||
of SunOS4, years before void * and size_t became unversally available.
|
||||
These cleanups will destroy lots of patches, but after 17 years the
|
||||
time has come.
|
||||
|
||||
The first-stage cleanup deprecates the use of "char *" for non-text
|
||||
purposes such as memory allocation and pointers to application
|
||||
context for call-back functions.
|
||||
|
||||
A second-stage cleanup will replace many integer types for counters
|
||||
and sizes with size_t or ssize_t equivalents. This will eliminate
|
||||
wasteful 64-32bit conversions on 64-bit systems.
|
||||
|
||||
Major changes with snapshot 20141128
|
||||
====================================
|
||||
|
||||
Support for DNS server reply filters in the Postfix SMTP client
|
||||
and server. This renders the result in standard zone file format:
|
||||
|
||||
name ttl class type preference value
|
||||
|
||||
The class field is always "IN", the preference field exists only
|
||||
for MX records, the names of hosts, domains, etc. end in ".", and
|
||||
those names are in ASCII form (xn--mumble form in the case of UTF8
|
||||
names).
|
||||
|
||||
When a match is found, the table lookup result specifies an action.
|
||||
By default, the table query and the action name are case-insensitive.
|
||||
Currently, only the IGNORE action is implemented.
|
||||
|
||||
For safety reasons, Postfix logs a warning or defers mail delivery
|
||||
when a filter removes all lookup results from a successful query.
|
||||
|
||||
The smtp_dns_reply_filter and lmtp_dns_reply_filter features are
|
||||
used only for Postfix SMTP client lookups of MX, A, and AAAAA records
|
||||
to locate a remote SMTP or LMTP server, including lookups that are
|
||||
made to implement the features reject_unverified_sender and
|
||||
reject_unverified_recipient.
|
||||
|
||||
The smtpd_dns_reply_filter feature is used only for Postfix SMTP
|
||||
server lookups of MX, A, AAAAA, and TXT records to implement the
|
||||
features reject_unknown_helo_hostname, reject_unknown_sender_domain,
|
||||
reject_unknown_recipient_domain, reject_rbl_*, and reject_rhsbl_*.
|
||||
|
||||
Implicit DNS lookups through nsswitch.conf or equivalent mechanisms
|
||||
are not filtered.
|
||||
|
||||
Major changes with snapshot 20141126
|
||||
====================================
|
||||
|
||||
Nullmx support (MX records with a null hostname). This change affects
|
||||
error messages only. The Postfix SMTP client already bounced mail
|
||||
for such domains, and the Postfix SMTP server already rejected such
|
||||
domains with reject_unknown_sender/recipient_domain. This introduces
|
||||
a new SMTP server configuration parameter nullmx_reject_code (default:
|
||||
556).
|
||||
|
||||
Major changes with snapshot 20141119
|
||||
====================================
|
||||
|
||||
Support for BCC actions in header/body_checks and milter_header_checks.
|
||||
There is no limit on the number of BCC actions that may be specified,
|
||||
other than the implicit limit due to finite storage. BCC support
|
||||
will not be implemented in Postfix delivery agents.
|
||||
|
||||
It works in the same way as always_bcc and sender/recipient_bcc_maps:
|
||||
there can be only one address per action, recipients are added with
|
||||
the NOTIFY=NONE delivery status notification option, and duplicate
|
||||
recipients are ignored (with the same delivery status notification
|
||||
options).
|
||||
|
||||
Major changes with snapshot 20141011
|
||||
====================================
|
||||
|
||||
Support to fall back to an unauthenticated TLS security level ("may"
|
||||
or "encrypt) when the Postfix SMTP client cannot establish the
|
||||
preferred authenticated TLS security level ("dane", "dane-only",
|
||||
"fingerprint", "verify", or "secure"). The fall-back levels may be
|
||||
specified globally with the smtp_tls_fallback_level parameter or
|
||||
in per-site TLS policies with the "fallback" attribute.
|
||||
|
||||
Fallback to unauthenticated TLS is logged, so that downgrade attacks
|
||||
are "tamper-evident". Fallback should be used only when testing,
|
||||
or temporarily when working around a known problem at a remote site.
|
||||
|
||||
Incompatible changes with snapshot 20141009
|
||||
===========================================
|
||||
|
||||
The default settings have changed for relay_domains (new: empty,
|
||||
old: $mydestination) and mynetworks_style (new: host, old: subnet).
|
||||
However the backwards-compatibility safety net will prevent these
|
||||
changes from taking effect, giving the system administrator the
|
||||
option to make an old default setting permanent in main.cf or to
|
||||
adopt the new default setting, before turning off backwards
|
||||
compatibility. See COMPATIBILITY_README for details.
|
||||
|
||||
With this the built-in compatibility level changes from 1 to 2.
|
||||
|
||||
Incompatible changes with snapshot 20141001
|
||||
===========================================
|
||||
|
||||
The default settings have changed for append_dot_mydomain (new: no.
|
||||
old: yes), master.cf chroot (new: n, old: y), and smtputf8 (new:
|
||||
yes, old: no).
|
||||
|
||||
A new backwards-compatibility safety net forces Postfix to run with
|
||||
backwards-compatible main.cf and master.cf default settings after
|
||||
an upgrade to a newer but incompatible Postfix version. See
|
||||
COMPATIBILITY_README for details.
|
||||
|
||||
While the backwards-compatible default settings are in effect,
|
||||
Postfix logs what services or what email would be affected by the
|
||||
incompatible change. Based on this the administrator can make some
|
||||
backwards-compatibility settings permanent in main.cf or master.cf,
|
||||
before turning off backwards compatibility.
|
||||
|
||||
See postconf.5.html#compatibility_level for details.
|
||||
|
||||
With this the built-in compatibility level changes from 0 to 1.
|
||||
|
||||
Major changes with snapshot 20140928
|
||||
====================================
|
||||
|
||||
Per-Milter settings
|
||||
-------------------
|
||||
Support for per-Milter settings that override main.cf parameters.
|
||||
For details see the section "Advanced policy client configuration"
|
||||
in the SMTPD_POLICY_README document.
|
||||
|
||||
Here is an example that uses both old and new syntax:
|
||||
|
||||
smtpd_milters = { inet:127.0.0.1:port1, default_action=accept, ... },
|
||||
inet:127.0.0.1:port2, ...
|
||||
|
||||
The per-milter settings are specified as attribute=value pairs
|
||||
separated by comma or space; specify { name = value } to allow
|
||||
spaces around the "=" or within an attribute value.
|
||||
|
||||
The supported attribute names are: command_timeout, connect_timeout,
|
||||
content_timeout, default_action, and protocol. These have the same
|
||||
names as the corresponding main.cf parameters, without the "milter_"
|
||||
prefix.
|
||||
|
||||
Per-policy service settings
|
||||
---------------------------
|
||||
Support for per-policy service settings that override main.cf
|
||||
parameters. For details see the section "Different settings for
|
||||
different Milter applications" in the MILTER_README document.
|
||||
|
||||
Here is an example that uses both old and new syntax:
|
||||
|
||||
smtpd_recipient_restrictions = ...
|
||||
check_policy_service { inet:127.0.0.1:port3, default_action=DUNNO }
|
||||
check_policy_service inet:127.0.0.1:port4
|
||||
...
|
||||
|
||||
The per-policy service settings are specified as attribute=value pairs
|
||||
separated by comma or space; specify { name = value } to allow
|
||||
spaces around the "=" or within an attribute value.
|
||||
|
||||
The supported attribute names are: default_action, max_idle, max_ttl,
|
||||
request_limit, retry_delay, timeout, try_limit. These have the same
|
||||
names as the corresponding main.cf parameters, without the
|
||||
"smtpd_policy_service_" prefix.
|
||||
|
||||
Whitespace in master.cf command-line arguments
|
||||
----------------------------------------------
|
||||
Support for whitespace in daemon command-line arguments. For details, see
|
||||
the "Command name + arguments" section in the master(5) manpage.
|
||||
Example:
|
||||
|
||||
smtpd -o { parameter = value containing whitespace } ...
|
||||
|
||||
The { ... } form is also available for non-option command-line
|
||||
arguments in master.cf, for example:
|
||||
|
||||
pipe ... argv=command { argument containing whitespace } ...
|
||||
|
||||
In both cases, whitespace immediately after "{" and before "}"
|
||||
is ignored.
|
||||
|
||||
Major changes with snapshot 20140921
|
||||
====================================
|
||||
|
||||
In preparation for configurable mail headers and logging, new main.cf
|
||||
support for if-then-else expressions:
|
||||
|
||||
${name?{text1}:{text2}}
|
||||
|
||||
and for logical expressions:
|
||||
|
||||
${{text1}=={text2}?{text3}:{text4}}
|
||||
${{text1}!={text2}?{text3}:{text4}}
|
||||
|
||||
Whitespace before and after {text} is ignored. This can help to
|
||||
make complex expressions more readable. See the postconf(5) manpage
|
||||
for further details.
|
||||
|
||||
The syntax of pipemap and randmap has improved. Postfix now uses
|
||||
pipemap:{map1, ..., mapN} and randmap:{result1, ..., resultN}.
|
||||
The old syntax was just too ugly.
|
||||
|
||||
It is expected that usability can be improved elsewhere in Postfix
|
||||
in a similar manner. For example,
|
||||
|
||||
- Milter clients and policy clients with non-default settings:
|
||||
smtpd_milters = {inet:host:port, timeout=xxx, default_action=yyy}, ...
|
||||
|
||||
- Parameter overrides in master.cf with commas and spaces:
|
||||
-o { parameter = value ... }
|
||||
|
||||
Major changes with snapshot 20140801
|
||||
====================================
|
||||
|
||||
The Postfix SMTP server now logs at the end of a session how many
|
||||
times an SMTP command was successfully invoked, followed by the
|
||||
total number of invocations if it is different.
|
||||
|
||||
This logging will often be enough to diagnose a problem without
|
||||
verbose logging or network sniffer.
|
||||
|
||||
Normal session, no TLS:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=1 data=1 quit=1
|
||||
|
||||
Normal session. with TLS:
|
||||
disconnect from name[addr] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1
|
||||
|
||||
All recipients rejected, no ESMTP command pipelining:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 quit=1
|
||||
|
||||
All recipients rejected, with ESMTP command pipelining:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1
|
||||
|
||||
Password guessing bot, hangs up without QUIT:
|
||||
disconnect from name[addr] ehlo=1 auth=0/1
|
||||
|
||||
Mis-configured client trying to use TLS wrappermode on port 587:
|
||||
disconnect from name[addr] unknown=0/1
|
||||
|
||||
Logfile analyzers can trigger on the presence of "/". It indicates
|
||||
that Postfix rejected at least one command.
|
||||
|
||||
Incompatible changes with snapshot 20140714
|
||||
===========================================
|
||||
|
||||
After upgrading Postfix, the "postfix reload" (or start/stop) is
|
||||
required. Several Postfix-internal protocols have been extended to
|
||||
support SMTPUTF8. Failure to reload or restart will result in mail
|
||||
staying queued and the logile will contain warning messages about
|
||||
unexpected attributes.
|
||||
|
||||
Major changes with snapshot 20140715
|
||||
====================================
|
||||
|
||||
Support for Email Address Internationalization (EAI) as defined in
|
||||
RFC 6531..6533. This supports UTF-8 in SMTP/LMTP sender addresses,
|
||||
recipient addresses, and message header values. The implementation
|
||||
is based on initial work by Arnt Gulbrandsen that was funded by
|
||||
CNNIC.
|
||||
|
||||
See SMTPUTF8_README for a description of Postfix SMTPUTF8 support.
|
||||
|
||||
Major changes with snapshot 20140703
|
||||
====================================
|
||||
|
||||
This release introduces three new configuration parameters that
|
||||
control error recovery for failed SMTPD policy requests.
|
||||
|
||||
* smtpd_policy_service_default_action (default: 451 4.3.5 Server
|
||||
configuration problem): The default action when an SMTPD policy
|
||||
service request fails.
|
||||
|
||||
* smtpd_policy_service_try_limit (default: 2): The maximal number
|
||||
of attempts to send an SMTPD policy service request before
|
||||
giving up. This must be a number greater than zero.
|
||||
|
||||
* smtpd_policy_service_retry_delay (default: 1s): The delay between
|
||||
attempts to resend a failed SMTPD policy service request. This
|
||||
must be a number greater than zero.
|
||||
|
||||
See postconf(5) for details and limitations.
|
||||
|
||||
Incompatible changes with snapshot 20140701
|
||||
===========================================
|
||||
|
||||
For clarity, the pipeline and random lookup tables are now called
|
||||
pipemap and randmap, respectively. The 20140618 text below has been
|
||||
updated accordingly. The old names remain supported for a while.
|
||||
|
||||
Incompatible changes with snapshot 20140625
|
||||
===========================================
|
||||
|
||||
For compliance with file system policies, some files have been moved
|
||||
from $daemon_directory to the directory specified with the new
|
||||
meta_directory configuration parameter which has the same default
|
||||
value as the config_directory parameter. This change affects
|
||||
non-executable files that are shared between multiple Postfix
|
||||
instances such as postfix-files, dynamicmaps.cf, and multi-instance
|
||||
template files.
|
||||
|
||||
For backwards compatibility with Postfix 2.6 .. 2.11, specify
|
||||
"meta_directory = $daemon_directory" in main.cf before installing
|
||||
or upgrading Postfix, or specify "meta_directory = /path/name" on
|
||||
the "make makefiles", "make install" or "make upgrade" command line.
|
||||
|
||||
Incompatible changes with snapshot 20140618
|
||||
===========================================
|
||||
|
||||
The pipe(8) delivery agent will now log a limited amount of command
|
||||
output upon successful delivery, and will report that output in
|
||||
"SUCCESS" delivery status reports. This is another good reason to
|
||||
disable inbound DSN requests at the Internet perimeter.
|
||||
|
||||
Major changes with snapshot 20140618
|
||||
====================================
|
||||
|
||||
This introduces several lookup tables with unusual properties.
|
||||
|
||||
randmap table
|
||||
------------
|
||||
|
||||
The "randmap" lookup table performs random selection. This may be
|
||||
used to implement load balancing, for example:
|
||||
|
||||
/etc/postfix/transport:
|
||||
# Deliver my own domain as usual.
|
||||
example.com :
|
||||
.example.com :
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps =
|
||||
# Deliver my own domain as usual.
|
||||
hash:/etc/postfix/transport
|
||||
# Deliver other domains via randomly-selected relayhosts
|
||||
randmap:!smtp:smtp0.example.com!smtp:smtp1.example.com
|
||||
|
||||
A variant of this can randomly select SMTP clients with different
|
||||
smtp_bind_address settings.
|
||||
|
||||
The first ASCII character after "randmap:" will be used as the
|
||||
separator between the results that follow (do not use space, ",",
|
||||
":" or non-ASCII).
|
||||
|
||||
Some future version may support the form randmap:/path/to/file,
|
||||
to load the list of random values, one per line, from a textfile.
|
||||
|
||||
To implement different weights, specify lookup results multiple
|
||||
times. For example, to choose smtp:smtp1.example.com twice as often
|
||||
as smtp:smtp0.example.com, specify smtp:smtp1.example.com twice.
|
||||
|
||||
pipemap table
|
||||
--------------
|
||||
|
||||
As the name suggests, the "pipemap" table implements a pipeline
|
||||
of lookup tables. The name of the table specifies the pipeline as
|
||||
a sequence of tables. For example, the following prevents SMTP mail
|
||||
to system accounts that have "nologin" as their login shell:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_recipient_maps =
|
||||
pipemap:!unix:passwd.byname!pcre:/etc/postfix/no-nologin.pcre
|
||||
alias_maps
|
||||
|
||||
/etc/postfix/no-nologin.pcre:
|
||||
!/nologin/ whatever
|
||||
|
||||
The first ASCII character after "pipemap:" will be used as the
|
||||
separator between the lookup tables that follow (do not use space,
|
||||
",", ":" or non-ASCII).
|
||||
|
||||
Each "pipemap:" query is given to the first table. Each table
|
||||
lookup result becomes the query for the next table in the pipeline,
|
||||
and the last table produces the final result. When any table lookup
|
||||
produces no result, the entire pipeline produces no result.
|
||||
|
||||
Some future version may support the form pipemap:/path/to/file,
|
||||
to load the list of lookup tables, one per line, from a textfile.
|
||||
|
||||
Incompatible changes with snapshot 20140530
|
||||
===========================================
|
||||
|
||||
The Postfix 3.0 build procedure expects that you specify database
|
||||
library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP,
|
||||
etc. With Postfix 3.0 and later, the old AUXLIBS variable still
|
||||
supports building a statically-loaded CDB etc. database client, but
|
||||
only the new AUXLIBS_CDB etc. variables support building a
|
||||
dynamically-loaded or statically-loaded CDB etc. database client.
|
||||
See CDB_README, LDAP_README, etc. for details.
|
||||
|
||||
Failure to follow this advice will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have
|
||||
database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
Major changes with snapshot 20140530
|
||||
====================================
|
||||
|
||||
Support to build Postfix with Postfix shared libraries, and with
|
||||
dynamically-loadable database clients. Postfix shared libraries
|
||||
introduce minor runtime overhead and result in smaller Postfix
|
||||
executable files. Dynamically-loadable database clients are useful
|
||||
when you distribute or install pre-compiled packages. Postfix 3.0
|
||||
supports dynamic loading for CDB, LDAP, LMDB, MYSQL, PCRE, PGSQL,
|
||||
SDBM, and SQLITE database clients.
|
||||
|
||||
This is based on Debian code by LaMont Jones, and based on a port
|
||||
by Viktor Dukhovni. Currently, support exists for recent versions
|
||||
of Linux, FreeBSD, MacOS X, and for the ancient Solaris 9.
|
||||
|
||||
To support Postfix shared libraries and dynamically-loadable database
|
||||
clients, the Postfix build procedure had to be changed (specifically,
|
||||
the files makedefs and Makefile.in, and the files postfix-install
|
||||
and post-install that install or update Postfix). These changes
|
||||
are introduced early in the annual Postfix development cycle to
|
||||
give down-stream maintainers sufficient time to prepare their build
|
||||
systems for the next stable Postfix release in 2015.
|
||||
|
||||
Building with Postfix shared libraries and database plugins
|
||||
-----------------------------------------------------------
|
||||
|
||||
Please see the INSTALL section "Building with Postfix shared libraries
|
||||
and database plugins" for fine-tuning details.
|
||||
|
||||
To build with Postfix shared libraries (files named libpostfix-*.so),
|
||||
use:
|
||||
|
||||
% make makefiles shared=yes ...other arguments...
|
||||
|
||||
To build with dynamicmaps.cf support and dynamically-loadable
|
||||
database clients (files named postfix-*.so), use:
|
||||
|
||||
% make makefiles dynamicmaps=yes ...other arguments...
|
||||
|
||||
This implicitly enables support for Postfix shared libraries. Postfix
|
||||
3.0 supports dynamic loading for CDB, LDAP, LMDB, MYSQL, PCRE,
|
||||
PGSQL, SDBM, and SQLITE database clients.
|
||||
|
||||
NOTE: The Postfix 3.0 build procedure expects that you specify
|
||||
database library dependencies with variables named AUXLIBS_CDB,
|
||||
AUXLIBS_LDAP, etc. With Postfix 3.0 and later, the old AUXLIBS
|
||||
variable still supports building a statically-loaded database client,
|
||||
but only the new AUXLIBS_CDB etc. variables support building a
|
||||
dynamically-loaded or statically-loaded CDB etc. database client.
|
||||
See CDB_README, LDAP_README, etc. for details.
|
||||
|
||||
Failure to follow this advice will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have
|
||||
database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
Differences with Debian
|
||||
-----------------------
|
||||
|
||||
Besides changes to the Postfix "build" system as described above,
|
||||
the user-visible changes with respect to Debian are:
|
||||
|
||||
- The new shlib_directory parameter specifies the location of the
|
||||
libpostfix-*.so shared-library files and the postfix-*.so database
|
||||
plugins. You can change the location of these files after Postfix
|
||||
is built. However, you may have to run ldconfig if you change the
|
||||
libpostfix-*.so location. No ldconfig is needed if you keep the
|
||||
libpostfix-*.so files in the compiled-in default $shlib_directory
|
||||
location.
|
||||
|
||||
- The new meta_directory parameter specifies the location of the
|
||||
file dynamicmaps.cf and some other non-executable files. The
|
||||
meta_directory parameter has the same default value as the
|
||||
config_directory parameter, so this is backwards compatible with
|
||||
Debian (but the default setting may be changed at compile time).
|
||||
|
||||
- Postfix supports the directory dynamicmaps.cf.d in addition to
|
||||
the file dynamicmaps.cf. Maintainers can use one configuration
|
||||
file per database plugin, which simplifies installation and
|
||||
removal of individual plugins.
|
||||
|
||||
- Likewise, Postfix supports the directory postfix-files.d in
|
||||
addition to the file postfix-files, Again, maintainers can use
|
||||
one configuration file per database plugin, which simplifies
|
||||
installation and removal of individual plugins.
|
||||
|
||||
Major changes with snapshot 20140321
|
||||
====================================
|
||||
|
||||
Delivery status filter support, to replace the delivery status codes
|
||||
and explanatory text of successful or unsuccessful deliveries by
|
||||
Postfix mail delivery agents.
|
||||
|
||||
This was originally implemented for sites that want to turn certain
|
||||
soft delivery errors into hard delivery errors, but it can also be
|
||||
used to censor out information from delivery confirmation reports.
|
||||
|
||||
This feature is implemented as a filter that replaces the three-number
|
||||
enhanced status code and descriptive text in Postfix delivery agent
|
||||
success, bounce, or defer messages. Note: this will not override
|
||||
"soft_bounce=yes", and this will not change a successful delivery
|
||||
status into an unsuccessful status or vice versa.
|
||||
|
||||
The first example turns specific soft TLS errors into hard
|
||||
errors, by overriding the first number in the enhanced status code.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
|
||||
|
||||
/etc/postfix/smtp_dsn_filter:
|
||||
/^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/ 5$1
|
||||
/^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/ 5$1
|
||||
|
||||
The second example removes the destination command name and file
|
||||
name from local(8) successful delivery reports, so that they will
|
||||
not be reported when a sender requests confirmation of delivery.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter
|
||||
|
||||
/etc/postfix/local_dsn_filter:
|
||||
/^(2\S+ delivered to file).+/ $1
|
||||
/^(2\S+ delivered to command).+/ $1
|
||||
|
||||
This feature is supported in the lmtp(8), local(8), pipe(8), smtp(8)
|
||||
and virtual(8) delivery agents. That is, all delivery agents that
|
||||
actually deliver mail.
|
||||
|
||||
The new main.cf parameters and default values are:
|
||||
|
||||
default_delivery_status_filter =
|
||||
lmtp_delivery_status_filter = $default_delivery_status_filter
|
||||
local_delivery_status_filter = $default_delivery_status_filter
|
||||
pipe_delivery_status_filter = $default_delivery_status_filter
|
||||
smtp_delivery_status_filter = $default_delivery_status_filter
|
||||
virtual_delivery_status_filter = $default_delivery_status_filter
|
||||
|
||||
See the postconf(5) manpage for more details.
|
||||
|
||||
614
postfix/RELEASE_NOTES-3.0
Normal file
614
postfix/RELEASE_NOTES-3.0
Normal file
@ -0,0 +1,614 @@
|
||||
The stable Postfix release is called postfix-3.0.x where 2=major
|
||||
release number, 0=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-3.1-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.10 or earlier, read RELEASE_NOTES-2.11
|
||||
before proceeding.
|
||||
|
||||
Notes for distribution maintainers
|
||||
----------------------------------
|
||||
|
||||
* New backwards-compatibility safety net.
|
||||
|
||||
With NEW Postfix installs, you MUST install a main.cf file with
|
||||
the setting "compatibility_level = 2". See conf/main.cf for an
|
||||
example.
|
||||
|
||||
With UPGRADES of existing Postfix systems, you MUST NOT change the
|
||||
main.cf compatibility_level setting, nor add this setting if it
|
||||
does not exist.
|
||||
|
||||
Several Postfix default settings have changed with Postfix 3.0. To
|
||||
avoid massive frustration with existing Postfix installations,
|
||||
Postfix 3.0 comes with a safety net that forces Postfix to keep
|
||||
running with backwards-compatible main.cf and master.cf default
|
||||
settings. This safety net depends on the main.cf compatibility_level
|
||||
setting (default: 0). Details are in COMPATIBILITY_README.
|
||||
|
||||
* New Postfix build system.
|
||||
|
||||
The Postfix build/install procedure has changed to support Postfix
|
||||
dynamically-linked libraries and database plugins. These must not
|
||||
be "shared" with non-Postfix programs, and therefore must not be
|
||||
installed in a public directory.
|
||||
|
||||
To avoid massive frustration due to broken patches, PLEASE BUILD
|
||||
POSTFIX FIRST WITHOUT APPLYING ANY PATCHES. Follow the INSTALL
|
||||
instructions (see "Building with Postfix dynamically-linked libraries
|
||||
and database plugins"), and see how things work and what the
|
||||
dynamically-linked libraries, database plugin, and configuration
|
||||
files look like. Then, go ahead and perform your platform-specific
|
||||
customizations. The INSTALL section "Tips for distribution maintainers"
|
||||
has further suggestions.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
|
||||
start/stop) is required. Several Postfix-internal protocols have
|
||||
been extended to support SMTPUTF8. Failure to reload or restart
|
||||
will result in mail staying queued and the logile will contain
|
||||
warning messages about unexpected attributes.
|
||||
|
||||
Major changes - default settings
|
||||
--------------------------------
|
||||
|
||||
[Incompat 20141009] The default settings have changed for relay_domains
|
||||
(new: empty, old: $mydestination) and mynetworks_style (new: host,
|
||||
old: subnet). However the backwards-compatibility safety net will
|
||||
prevent these changes from taking effect, giving the system
|
||||
administrator the option to make an old default setting permanent
|
||||
in main.cf or to adopt the new default setting, before turning off
|
||||
backwards compatibility. See COMPATIBILITY_README for details.
|
||||
|
||||
[Incompat 20141001] A new backwards-compatibility safety net forces
|
||||
Postfix to run with backwards-compatible main.cf and master.cf
|
||||
default settings after an upgrade to a newer but incompatible Postfix
|
||||
version. See COMPATIBILITY_README for details.
|
||||
|
||||
While the backwards-compatible default settings are in effect,
|
||||
Postfix logs what services or what email would be affected by the
|
||||
incompatible change. Based on this the administrator can make some
|
||||
backwards-compatibility settings permanent in main.cf or master.cf,
|
||||
before turning off backwards compatibility.
|
||||
|
||||
See postconf.5.html#compatibility_level for details.
|
||||
|
||||
[Incompat 20141001] The default settings
|
||||
have changed for append_dot_mydomain (new: no. old: yes), master.cf
|
||||
chroot (new: n, old: y), and smtputf8 (new: yes, old: no).
|
||||
|
||||
Major changes - access control
|
||||
------------------------------
|
||||
|
||||
[Feature 20141119] Support for BCC actions in header/body_checks
|
||||
and milter_header_checks. There is no limit on the number of BCC
|
||||
actions that may be specified, other than the implicit limit due
|
||||
to finite storage. BCC support will not be implemented in Postfix
|
||||
delivery agent header/body_checks.
|
||||
|
||||
It works in the same way as always_bcc and sender/recipient_bcc_maps:
|
||||
there can be only one address per action, recipients are added with
|
||||
the NOTIFY=NONE delivery status notification option, and duplicate
|
||||
recipients are ignored (with the same delivery status notification
|
||||
options).
|
||||
|
||||
[Incompat 20141009] The default settings have changed for relay_domains
|
||||
(new: empty, old: $mydestination) and mynetworks_style (new: host,
|
||||
old: subnet). However the backwards-compatibility safety net will
|
||||
prevent these changes from taking effect, giving the system
|
||||
administrator the option to make an old default setting permanent
|
||||
in main.cf or to adopt the new default setting, before turning off
|
||||
backwards compatibility. See COMPATIBILITY_README for details.
|
||||
|
||||
[Feature 20140618] New INFO action in access(5) tables, for consistency
|
||||
with header/body_checks.
|
||||
|
||||
[Feature 20140620] New check_xxx_a_access (for xxx in client,
|
||||
reverse_client, helo, sender, recipient) implements access control
|
||||
on all A and AAAA IP addresses for respectively the client hostname,
|
||||
helo parameter, sender domain or recipient domain. This complements
|
||||
the existing check_xxx_mx_access and check_xxx_ns_access features.
|
||||
|
||||
Major changes - address rewriting
|
||||
---------------------------------
|
||||
|
||||
[Incompat 20141001] The default settings have changed for
|
||||
append_dot_mydomain (new: no. old: yes), master.cf chroot (new:
|
||||
n, old: y), and smtputf8 (new: yes, old: no).
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Feature 20141227] The new smtp_address_verify_target parameter
|
||||
(default: rcpt) specifies what protocol stage decides if a recipient
|
||||
is valid. Specify "data" for servers that reject invalid recipients
|
||||
in response to the DATA command.
|
||||
|
||||
Major changes - database support
|
||||
--------------------------------
|
||||
|
||||
[Feature 20140512] Support for Berkeley DB version 6.
|
||||
|
||||
[Feature 20140618] The "randmap" lookup table performs random
|
||||
selection. This may be used to implement load balancing, for example:
|
||||
|
||||
/etc/postfix/transport:
|
||||
# Deliver my own domain as usual.
|
||||
example.com :
|
||||
.example.com :
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps =
|
||||
# Deliver my own domain as usual.
|
||||
hash:/etc/postfix/transport
|
||||
# Deliver other domains via randomly-selected relayhosts
|
||||
randmap:{smtp:smtp0.example.com, smtp:smtp1.example.com}
|
||||
|
||||
A variant of this can randomly select SMTP clients with different
|
||||
smtp_bind_address settings.
|
||||
|
||||
To implement different weights, specify lookup results multiple
|
||||
times. For example, to choose smtp:smtp1.example.com twice as often
|
||||
as smtp:smtp0.example.com, specify smtp:smtp1.example.com twice.
|
||||
|
||||
A future version may support randmap:/path/to/file to load a list
|
||||
of results from file.
|
||||
|
||||
[Feature 20140618] As the name suggests, the "pipemap" table
|
||||
implements a pipeline of lookup tables. The name of the table
|
||||
specifies the pipeline as a sequence of tables. For example, the
|
||||
following prevents SMTP mail to system accounts that have "nologin"
|
||||
as their login shell:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_recipient_maps =
|
||||
pipemap:{unix:passwd.byname, pcre:/etc/postfix/no-nologin.pcre}
|
||||
alias_maps
|
||||
|
||||
/etc/postfix/no-nologin.pcre:
|
||||
!/nologin/ whatever
|
||||
|
||||
Each "pipemap:" query is given to the first table. Each table
|
||||
lookup result becomes the query for the next table in the pipeline,
|
||||
and the last table produces the final result. When any table lookup
|
||||
produces no result, the entire pipeline produces no result.
|
||||
|
||||
A future version may support pipemap:/path/to/file to load a list
|
||||
of lookup tables from file.
|
||||
|
||||
[Feature 20140924] Support for unionmap, with the same syntax as
|
||||
pipemap. This sends a query to all tables, and non-empty results
|
||||
are concatenated, separated by comma.
|
||||
|
||||
[Feature 20131121] The "static" lookup table now supports whitespace
|
||||
when invoked as "static:{ text with whitespace }", so that it can
|
||||
be used, for example, at the end of smtpd_mumble_restrictions as
|
||||
"check_mumble_access static:{reject text...}".
|
||||
|
||||
[Feature 20141126] "inline:{key=value, { key = text with comma/space}}"
|
||||
avoids the need to create a database for just a few entries.
|
||||
|
||||
Major changes - delivery status notifications
|
||||
---------------------------------------------
|
||||
|
||||
[Feature 20140321] Delivery status filter support, to replace the
|
||||
delivery status codes and explanatory text of successful or
|
||||
unsuccessful deliveries by Postfix mail delivery agents.
|
||||
|
||||
This was originally implemented for sites that want to turn certain
|
||||
soft delivery errors into hard delivery errors, but it can also be
|
||||
used to censor out information from delivery confirmation reports.
|
||||
|
||||
This feature is implemented as a filter that replaces the three-number
|
||||
enhanced status code and descriptive text in Postfix delivery agent
|
||||
success, bounce, or defer messages. Note: this will not override
|
||||
"soft_bounce=yes", and this will not change a successful delivery
|
||||
status into an unsuccessful status or vice versa.
|
||||
|
||||
The first example turns specific soft TLS errors into hard
|
||||
errors, by overriding the first number in the enhanced status code.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
|
||||
|
||||
/etc/postfix/smtp_dsn_filter:
|
||||
/^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/ 5$1
|
||||
/^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/ 5$1
|
||||
|
||||
The second example removes the destination command name and file
|
||||
name from local(8) successful delivery reports, so that they will
|
||||
not be reported when a sender requests confirmation of delivery.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter
|
||||
|
||||
/etc/postfix/local_dsn_filter:
|
||||
/^(2\S+ delivered to file).+/ $1
|
||||
/^(2\S+ delivered to command).+/ $1
|
||||
|
||||
This feature is supported in the lmtp(8), local(8), pipe(8), smtp(8)
|
||||
and virtual(8) delivery agents. That is, all delivery agents that
|
||||
actually deliver mail. It will not be implemented in the error and
|
||||
retry pseudo-delivery agents.
|
||||
|
||||
The new main.cf parameters and default values are:
|
||||
|
||||
default_delivery_status_filter =
|
||||
lmtp_delivery_status_filter = $default_delivery_status_filter
|
||||
local_delivery_status_filter = $default_delivery_status_filter
|
||||
pipe_delivery_status_filter = $default_delivery_status_filter
|
||||
smtp_delivery_status_filter = $default_delivery_status_filter
|
||||
virtual_delivery_status_filter = $default_delivery_status_filter
|
||||
|
||||
See the postconf(5) manpage for more details.
|
||||
|
||||
[Incompat 20140618] The pipe(8) delivery agent will now log a limited
|
||||
amount of command output upon successful delivery, and will report
|
||||
that output in "SUCCESS" delivery status reports. This is another
|
||||
good reason to disable inbound DSN requests at the Internet perimeter.
|
||||
|
||||
[Feature 20140907] With "confirm_delay_cleared = yes", Postfix
|
||||
informs the sender when delayed mail leaves the queue (this is in
|
||||
addition to the delay_warning_time feature that warns when mail is
|
||||
still queued). This feature is disabled by default, because it can
|
||||
result in a sudden burst of notifications when the queue drains at
|
||||
the end of a prolonged network outage.
|
||||
|
||||
Major changes - dns
|
||||
-------------------
|
||||
|
||||
[Feature 20141128] Support for DNS server reply filters in the
|
||||
Postfix SMTP/LMTP client and SMTP server. This helps to work around
|
||||
mail delivery problems with sites that have incorrect DNS information.
|
||||
Note: this has no effect on the implicit DNS lookups that are made
|
||||
by nsswitch.conf or equivalent mechanisms.
|
||||
|
||||
This feature renders each lookup result as one line of text in
|
||||
standard zone-file format as shown below. The class field is always
|
||||
"IN", the preference field exists only for MX records, the names
|
||||
of hosts, domains, etc. end in ".", and those names are in ASCII
|
||||
form (xn--mumble form for internationalized domain names).
|
||||
|
||||
name ttl class type preference value
|
||||
---------------------------------------------------------
|
||||
postfix.org. 86400 IN MX 10 mail.cloud9.net.
|
||||
|
||||
Typically, one would match this text with a regexp: or pcre: table.
|
||||
When a match is found, the table lookup result specifies an action.
|
||||
By default, the table query and the action name are case-insensitive.
|
||||
Currently, only the IGNORE action is implemented.
|
||||
|
||||
For safety reasons, Postfix logs a warning or defers mail delivery
|
||||
when a DNS reply filter removes all lookup results from a successful
|
||||
query.
|
||||
|
||||
The Postfix SMTP/LMTP client uses the smtp_dns_reply_filter and
|
||||
lmtp_dns_reply_filter features only for Postfix SMTP client lookups
|
||||
of MX, A, and AAAAA records to locate a remote SMTP or LMTP server,
|
||||
including lookups that implement the features reject_unverified_sender
|
||||
and reject_unverified_recipient. The filters are not used for lookups
|
||||
made through nsswitch.conf and similar mechanisms.
|
||||
|
||||
The Postfix SMTP server uses the smtpd_dns_reply_filter feature
|
||||
only for Postfix SMTP server lookups of MX, A, AAAAA, and TXT records
|
||||
to implement the features reject_unknown_helo_hostname,
|
||||
reject_unknown_sender_domain, reject_unknown_recipient_domain,
|
||||
reject_rbl_*, and reject_rhsbl_*. The filter is not used for lookups
|
||||
made through nsswitch.conf and similar mechanisms, such as lookups
|
||||
of the remote SMTP client name.
|
||||
|
||||
[Feature 20141126] Nullmx support (MX records with a null hostname).
|
||||
This change affects error messages only. The Postfix SMTP client
|
||||
already bounced mail for such domains, and the Postfix SMTP server
|
||||
already rejected such domains with reject_unknown_sender/recipient_domain.
|
||||
This feature introduces a new SMTP server configuration parameter
|
||||
nullmx_reject_code (default: 556).
|
||||
|
||||
Major changes - dynamic linking
|
||||
-------------------------------
|
||||
|
||||
[Feature 20140530] Support to build Postfix with Postfix
|
||||
dynamically-linked libraries, and with dynamically-loadable database
|
||||
clients. These MUST NOT be used by non-Postfix programs. Postfix
|
||||
dynamically-linked libraries introduce minor runtime overhead and
|
||||
result in smaller Postfix executable files. Dynamically-loadable
|
||||
database clients are useful when you distribute or install pre-compiled
|
||||
packages. Postfix 3.0 supports dynamic loading for CDB, LDAP, LMDB,
|
||||
MYSQL, PCRE, PGSQL, SDBM, and SQLITE database clients.
|
||||
|
||||
This implementation is based on Debian code by LaMont Jones, initially
|
||||
ported by Viktor Dukhovni. Currently, support exists for recent
|
||||
versions of Linux, FreeBSD, MacOS X, and for the ancient Solaris 9.
|
||||
|
||||
To support Postfix dynamically-linked libraries and dynamically-loadable
|
||||
database clients, the Postfix build procedure had to be changed
|
||||
(specifically, the files makedefs and Makefile.in, and the files
|
||||
postfix-install and post-install that install or update Postfix).
|
||||
|
||||
[Incompat 20140530] The Postfix 3.0 build procedure expects that
|
||||
you specify database library dependencies with variables named
|
||||
AUXLIBS_CDB, AUXLIBS_LDAP, etc. With Postfix 3.0 and later, the
|
||||
old AUXLIBS variable still supports building a statically-loaded
|
||||
CDB etc. database client, but only the new AUXLIBS_CDB etc. variables
|
||||
support building a dynamically-loaded or statically-loaded CDB etc.
|
||||
database client. See CDB_README, LDAP_README, etc. for details.
|
||||
|
||||
Failure to follow this advice will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have
|
||||
database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
Major changes - future proofing
|
||||
-------------------------------
|
||||
|
||||
[Cleanup 20141224] The changes described here have no visible effect
|
||||
on Postfix behavior, but they make Postfix code easier to maintain,
|
||||
and therefore make new functionality easier to add.
|
||||
|
||||
* Compile-time argument typechecks of non-printf/scanf-like variadic
|
||||
function argument lists.
|
||||
|
||||
* Deprecating the use of "char *" for non-text purposes such as
|
||||
memory allocation and pointers to application context for call-back
|
||||
functions. This dates from long-past days before void * became
|
||||
universally available.
|
||||
|
||||
* Replace integer types for counters and sizes with size_t or ssize_t
|
||||
equivalents. This eliminates some wasteful 64<->32bit conversions
|
||||
on 64-bit systems.
|
||||
|
||||
Major changes - installation pathnames
|
||||
--------------------------------------
|
||||
|
||||
[Incompat 20140625] For compliance with file system policies, some
|
||||
non-executable files have been moved from $daemon_directory to the
|
||||
directory specified with the new meta_directory configuration
|
||||
parameter which has the same default value as the config_directory
|
||||
parameter. This change affects non-executable files that are shared
|
||||
between multiple Postfix instances such as postfix-files, dynamicmaps.cf,
|
||||
and multi-instance template files.
|
||||
|
||||
For backwards compatibility with Postfix 2.6 .. 2.11, specify
|
||||
"meta_directory = $daemon_directory" in main.cf before installing
|
||||
or upgrading Postfix, or specify "meta_directory = /path/name" on
|
||||
the "make makefiles", "make install" or "make upgrade" command line.
|
||||
|
||||
Major changes - milter
|
||||
----------------------
|
||||
|
||||
[Feature 20140928] Support for per-Milter settings that override
|
||||
main.cf parameters. For details see the section "Advanced policy
|
||||
client configuration" in the SMTPD_POLICY_README document.
|
||||
|
||||
Here is an example that uses both old and new syntax:
|
||||
|
||||
smtpd_milters = { inet:127.0.0.1:port1, default_action=accept, ... },
|
||||
inet:127.0.0.1:port2, ...
|
||||
|
||||
The supported attribute names are: command_timeout, connect_timeout,
|
||||
content_timeout, default_action, and protocol. These have the same
|
||||
names as the corresponding main.cf parameters, without the "milter_"
|
||||
prefix.
|
||||
|
||||
The per-milter settings are specified as attribute=value pairs
|
||||
separated by comma or space; specify { name = value } to allow
|
||||
spaces around the "=" or within an attribute value.
|
||||
|
||||
[Feature 20141018] DMARC compatibility: when a Milter inserts a
|
||||
header ABOVE Postfix's own Received: header, Postfix no longer
|
||||
exposes its own Received: header to Milters (violating protocol)
|
||||
and Postfix no longer hides the Milter-inserted header from Milters
|
||||
(wtf).
|
||||
|
||||
Major changes - parameter syntax
|
||||
--------------------------------
|
||||
|
||||
[Feature 20140921] In preparation for configurable mail headers and
|
||||
logging, new main.cf support for if-then-else expressions:
|
||||
|
||||
${name?{text1}:{text2}}
|
||||
|
||||
and for logical expressions:
|
||||
|
||||
${{text1}=={text2}?{text3}:{text4}}
|
||||
${{text1}!={text2}?{text3}:{text4}}
|
||||
|
||||
Whitespace before and after {text} is ignored. This can help to
|
||||
make complex expressions more readable. See the postconf(5) manpage
|
||||
for further details.
|
||||
|
||||
[Feature 20140928] Support for whitespace in daemon command-line
|
||||
arguments. For details, see the "Command name + arguments" section
|
||||
in the master(5) manpage. Example:
|
||||
|
||||
smtpd -o { parameter = value containing whitespace } ...
|
||||
|
||||
The { ... } form is also available for non-option command-line
|
||||
arguments in master.cf, for example:
|
||||
|
||||
pipe ... argv=command { argument containing whitespace } ...
|
||||
|
||||
In both cases, whitespace immediately after "{" and before "}"
|
||||
is ignored.
|
||||
|
||||
[Feature 20141005] Postfix import_environment and export_environment
|
||||
now allow "{ name=value }" to protect whitespace in attribute values.
|
||||
|
||||
[Feature 20141006] The new message_drop_header parameter replaces
|
||||
a hard-coded table that specifies what message headers the cleanup
|
||||
daemon will remove. The list of supported header names covers RFC
|
||||
5321, 5322, MIME RFCs, and some historical names.
|
||||
|
||||
Major changes - pipe daemon
|
||||
---------------------------
|
||||
|
||||
[Incompat 20140618] The pipe(8) delivery agent will now log a limited
|
||||
amount of command output upon successful delivery, and will report
|
||||
that output in "SUCCESS" delivery status reports. This is another
|
||||
good reason to disable inbound DSN requests at the Internet perimeter.
|
||||
|
||||
Major changes - policy client
|
||||
-----------------------------
|
||||
|
||||
[Feature 20140703] This release introduces three new configuration
|
||||
parameters that control error recovery for failed SMTPD policy
|
||||
requests.
|
||||
|
||||
* smtpd_policy_service_default_action (default: 451 4.3.5 Server
|
||||
configuration problem): The default action when an SMTPD policy
|
||||
service request fails.
|
||||
|
||||
* smtpd_policy_service_try_limit (default: 2): The maximal number
|
||||
of attempts to send an SMTPD policy service request before
|
||||
giving up. This must be a number greater than zero.
|
||||
|
||||
* smtpd_policy_service_retry_delay (default: 1s): The delay between
|
||||
attempts to resend a failed SMTPD policy service request. This
|
||||
must be a number greater than zero.
|
||||
|
||||
See postconf(5) for details and limitations.
|
||||
|
||||
[Feature 20140928] Support for per-policy service settings that
|
||||
override main.cf parameters. For details see the section "Different
|
||||
settings for different Milter applications" in the MILTER_README
|
||||
document.
|
||||
|
||||
Here is an example that uses both old and new syntax:
|
||||
|
||||
smtpd_recipient_restrictions = ...
|
||||
check_policy_service { inet:127.0.0.1:port3, default_action=DUNNO }
|
||||
check_policy_service inet:127.0.0.1:port4
|
||||
...
|
||||
|
||||
The per-policy service settings are specified as attribute=value pairs
|
||||
separated by comma or space; specify { name = value } to allow
|
||||
spaces around the "=" or within an attribute value.
|
||||
|
||||
The supported attribute names are: default_action, max_idle, max_ttl,
|
||||
request_limit, retry_delay, timeout, try_limit. These have the same
|
||||
names as the corresponding main.cf parameters, without the
|
||||
"smtpd_policy_service_" prefix.
|
||||
|
||||
[Feature 20140505] A client port attribute was added to the policy
|
||||
delegation protocol.
|
||||
|
||||
[Feature 20140630] New smtpd_policy_service_request_limit feature to
|
||||
limit the number of requests per Postfix SMTP server policy connection.
|
||||
This is a workaround to avoid error-recovery delays with policy
|
||||
servers that cannot maintain a persistent connection.
|
||||
|
||||
Major changes - postscreen
|
||||
--------------------------
|
||||
|
||||
[Feature 20140501] Configurable time limit (postscreen_dnsbl_timeout)
|
||||
for DNSBL or DNSWL lookups. This is separate from the timeouts in
|
||||
the dnsblog(8) daemon which are controlled by system resolver(3)
|
||||
routines.
|
||||
|
||||
Major changes - session fingerprint
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20140801] The Postfix SMTP server now logs at the end of
|
||||
a session how many times an SMTP command was successfully invoked,
|
||||
followed by the total number of invocations if some invocations
|
||||
were unsuccessful.
|
||||
|
||||
This logging will enough to diagnose many problems without using
|
||||
verbose logging or network sniffer.
|
||||
|
||||
Normal session, no TLS:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=1 data=1 quit=1
|
||||
|
||||
Normal session. with TLS:
|
||||
disconnect from name[addr] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1
|
||||
|
||||
All recipients rejected, no ESMTP command pipelining:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 quit=1
|
||||
|
||||
All recipients rejected, with ESMTP command pipelining:
|
||||
disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1
|
||||
|
||||
Password guessing bot, hangs up without QUIT:
|
||||
disconnect from name[addr] ehlo=1 auth=0/1
|
||||
|
||||
Mis-configured client trying to use TLS wrappermode on port 587:
|
||||
disconnect from name[addr] unknown=0/1
|
||||
|
||||
Logfile analyzers can trigger on the presence of "/". It indicates
|
||||
that Postfix rejected at least one command.
|
||||
|
||||
[Feature 20150118] As a late addition, the SMTP server now also
|
||||
logs the total number of commands (as "commands=x/y") even when the
|
||||
client did not send any commands. This helps logfile analyzers to
|
||||
recognize sessions without commands.
|
||||
|
||||
Major changes - smtp client
|
||||
---------------------------
|
||||
|
||||
[Feature 20141227] The new smtp_address_verify_target parameter
|
||||
(default: rcpt) determines what protocol stage decides if a recipient
|
||||
is valid. Specify "data" for servers that reject recipients after
|
||||
the DATA command.
|
||||
|
||||
Major changes - smtputf8
|
||||
------------------------
|
||||
|
||||
[Incompat 20141001] The default settings have changed for
|
||||
append_dot_mydomain (new: no, old: yes), master.cf chroot (new:
|
||||
n, old: y), and smtputf8 (new: yes, old: no).
|
||||
|
||||
[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
|
||||
start/stop) is required. Several Postfix-internal protocols have
|
||||
been extended to support SMTPUTF8. Failure to reload or restart
|
||||
will result in mail staying queued and the logile will contain
|
||||
warning messages about unexpected attributes.
|
||||
|
||||
[Feature 20140715] Support for Email Address Internationalization
|
||||
(EAI) as defined in RFC 6531..6533. This supports UTF-8 in SMTP/LMTP
|
||||
sender addresses, recipient addresses, and message header values.
|
||||
The implementation is based on initial work by Arnt Gulbrandsen
|
||||
that was funded by CNNIC.
|
||||
|
||||
See SMTPUTF8_README for a description of Postfix SMTPUTF8 support.
|
||||
|
||||
[Feature 20150112] UTF-8 Casefolding support for Postfix lookup
|
||||
tables and matchlists (mydestination, relay_domains, etc.). This
|
||||
is enabled only with "smtpuf8 = yes".
|
||||
|
||||
[Feature 20150112] With smtputf8_enable=yes, SMTP commands with
|
||||
UTF-8 syntax errors are rejected, table lookup results with invalid
|
||||
UTF-8 syntax are handled as configuration errors, and UTF-8 syntax
|
||||
errors in policy server replies result in execution of the policy
|
||||
server's default action.
|
||||
|
||||
Major changes - tls support
|
||||
---------------------------
|
||||
|
||||
(see "Major changes - delivery status notifications" above for
|
||||
turning 4XX soft errors into 5XX bounces when a remote SMTP server
|
||||
does not offer STARTTLS support).
|
||||
|
||||
[Feature 20140209] the Postfix SMTP client now also falls back to
|
||||
plaintext when TLS fails AFTER the TLS protocol handshake.
|
||||
|
||||
[Feature 20140218] The Postfix SMTP client now requires that a queue
|
||||
file is older than $minimal_backoff_time, before falling back from
|
||||
failed TLS to plaintext (both during or after the TLS handshake).
|
||||
|
||||
[Feature 20141021] Per IETF TLS WG consensus, the tls_session_ticket_cipher
|
||||
default setting was changed from aes-128-cbc to aes-256-cbc.
|
||||
|
||||
[Feature 20150116] TLS wrappermode support in the Postfix smtp(8)
|
||||
client (new smtp_tls_wrappermode parameter) and in posttls-finger(1)
|
||||
(new -w option). There still is life in that deprecated protocol,
|
||||
and people should not have to jump hoops with stunnel.
|
||||
@ -52,7 +52,6 @@ proxymap unix - - n - - proxymap
|
||||
proxywrite unix - - n - 1 proxymap
|
||||
smtp unix - - n - - smtp
|
||||
relay unix - - n - - smtp
|
||||
-o syslog_name=postfix/relay
|
||||
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
|
||||
showq unix n - n - - showq
|
||||
error unix - - n - - error
|
||||
|
||||
@ -229,49 +229,51 @@ $ make
|
||||
|
||||
<p> and so on. In some cases, optimization is turned off automatically. </p>
|
||||
|
||||
<h3>4.3 - Building with Postfix shared libraries and database plugins
|
||||
(Postfix ≥ 3.0) </h3>
|
||||
<h3>4.3 - Building with Postfix dynamically-linked libraries and
|
||||
database plugins (Postfix ≥ 3.0) </h3>
|
||||
|
||||
<p> Postfix shared-library and database plugin support exists for
|
||||
recent versions of Linux, FreeBSD and MacOS X. Shared-library builds
|
||||
may become the default at some point in the future. </p>
|
||||
<p> Postfix dynamically-linked library and database plugin support
|
||||
exists for recent versions of Linux, FreeBSD and MacOS X.
|
||||
Dynamically-linked library builds may become the default at some
|
||||
point in the future. </p>
|
||||
|
||||
<p> Overview of topics: </p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li><a href="#shared_enable">4.3.1 Turning on Postfix shared-library
|
||||
support</a>
|
||||
<li><a href="#shared_enable">4.3.1 Turning on Postfix dynamically-linked
|
||||
library support</a>
|
||||
|
||||
<li><a href="#dynamicmaps_enable">4.3.2 Turning on Postfix database-plugin
|
||||
support</a>
|
||||
|
||||
<li><a href="#shared_custom">4.3.3 Customizing Postfix shared
|
||||
<li><a href="#shared_custom">4.3.3 Customizing Postfix dynamically-linked
|
||||
libraries and database plugins</a>
|
||||
|
||||
<li><a href="#shared_tips">4.4.4 Tips for distribution maintainers</a>
|
||||
|
||||
</ul>
|
||||
|
||||
<p> Note: directories with Postfix shared libraries or database
|
||||
plugins should contain only postfix-related files. Postfix shared
|
||||
libraries and database plugins should not be installed in a "public"
|
||||
system directory such as /usr/lib or /usr/local/lib. Linking Postfix
|
||||
shared-library or database-plugin files into non-Postfix programs
|
||||
is not supported. Postfix shared libraries and database plugins
|
||||
implement a Postfix-internal API that changes without maintaining
|
||||
compatibility. </p>
|
||||
<p> Note: directories with Postfix dynamically-linked libraries
|
||||
or database plugins should contain only postfix-related files.
|
||||
Postfix dynamically-linked libraries and database plugins should
|
||||
not be installed in a "public" system directory such as /usr/lib
|
||||
or /usr/local/lib. Linking Postfix dynamically-linked library or
|
||||
database-plugin files into non-Postfix programs is not supported.
|
||||
Postfix dynamically-linked libraries and database plugins implement
|
||||
a Postfix-internal API that changes without maintaining compatibility.
|
||||
</p>
|
||||
|
||||
<h4><a name="shared_enable"> 4.3.1 Turning on Postfix shared-library
|
||||
support </a></h4>
|
||||
<h4><a name="shared_enable"> 4.3.1 Turning on Postfix dynamically-linked
|
||||
library support </a></h4>
|
||||
|
||||
<p> Postfix can be built with Postfix shared libraries (files
|
||||
typically named <tt>libpostfix-*.so</tt>). Postfix shared libraries
|
||||
add minor run-time overhead and result in significantly-smaller
|
||||
Postfix executable files. </p>
|
||||
<p> Postfix can be built with Postfix dynamically-linked libraries
|
||||
(files typically named <tt>libpostfix-*.so</tt>). Postfix
|
||||
dynamically-linked libraries add minor run-time overhead and result
|
||||
in significantly-smaller Postfix executable files. </p>
|
||||
|
||||
<p> Specify "shared=yes" on the "make makefiles" command line to
|
||||
build Postfix with shared-library support. </p>
|
||||
build Postfix with dynamically-linked library support. </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -281,17 +283,17 @@ $ make
|
||||
</blockquote>
|
||||
|
||||
<p> (Specify "make makefiles shared=no" to explicitly disable Postfix
|
||||
shared-library support). </p>
|
||||
dynamically-linked library support). </p>
|
||||
|
||||
<p> This installs shared libraries in $<a href="postconf.5.html#shlib_directory">shlib_directory</a>, typically
|
||||
/usr/lib/postfix or /usr/local/lib/postfix, with file names
|
||||
libpostfix-<i>name</i>.so, where the <i>name</i> is a source-code
|
||||
<p> This installs dynamically-linked libraries in $<a href="postconf.5.html#shlib_directory">shlib_directory</a>,
|
||||
typically /usr/lib/postfix or /usr/local/lib/postfix, with file
|
||||
names libpostfix-<i>name</i>.so, where the <i>name</i> is a source-code
|
||||
directory name such as "util" or "global". </p>
|
||||
|
||||
<p> See section 4.3.3 "Customizing Postfix shared libraries and
|
||||
database plugins" below for how to customize the Postfix shared-library
|
||||
location, including support to upgrade a running mail system safely.
|
||||
</p>
|
||||
<p> See section 4.3.3 "Customizing Postfix dynamically-linked
|
||||
libraries and database plugins" below for how to customize the
|
||||
Postfix dynamically-linked library location, including support to
|
||||
upgrade a running mail system safely. </p>
|
||||
|
||||
<h4><a name="dynamicmaps_enable"> 4.3.2 Turning on Postfix
|
||||
database-plugin support </a></h4>
|
||||
@ -318,12 +320,12 @@ $ make
|
||||
<p> (Specify "make makefiles dynamicmaps=no" to explicitly disable
|
||||
Postfix database-plugin support). </p>
|
||||
|
||||
<p> This implicitly enables shared-library support, installs the
|
||||
configuration file dynamicmaps.cf in $<a href="postconf.5.html#meta_directory">meta_directory</a> (usually,
|
||||
/etc/postfix or /usr/local/etc/postfix), and installs database
|
||||
plugins in $<a href="postconf.5.html#shlib_directory">shlib_directory</a> (see above). Database plugins are named
|
||||
postfix-<i>type</i>.so where the <i>type</i> is a database type
|
||||
such as "cdb" or "ldap". </p>
|
||||
<p> This implicitly enables dynamically-linked library support,
|
||||
installs the configuration file dynamicmaps.cf in $<a href="postconf.5.html#meta_directory">meta_directory</a>
|
||||
(usually, /etc/postfix or /usr/local/etc/postfix), and installs
|
||||
database plugins in $<a href="postconf.5.html#shlib_directory">shlib_directory</a> (see above). Database plugins
|
||||
are named postfix-<i>type</i>.so where the <i>type</i> is a database
|
||||
type such as "cdb" or "ldap". </p>
|
||||
|
||||
<blockquote>
|
||||
|
||||
@ -346,18 +348,19 @@ database client loading was meant to avoid. </p>
|
||||
version of Postfix database plugins and the location of the file
|
||||
dynamicmaps.cf. </p>
|
||||
|
||||
<h4><a name="shared_custom"> 4.3.3 Customizing Postfix shared
|
||||
<h4><a name="shared_custom"> 4.3.3 Customizing Postfix dynamically-linked
|
||||
libraries and database plugins </a></h4>
|
||||
|
||||
<h5> Customizing the location of Postfix shared libraries and
|
||||
database plugins </h5>
|
||||
<h5> Customizing the location of Postfix dynamically-linked libraries
|
||||
and database plugins </h5>
|
||||
|
||||
<p> As a reminder, the directories with Postfix shared libraries
|
||||
or database plugins should contain only Postfix-related files.
|
||||
Linking these files into other programs is not supported. </p>
|
||||
<p> As a reminder, the directories with Postfix dynamically-linked
|
||||
libraries or database plugins should contain only Postfix-related
|
||||
files. Linking these files into other programs is not supported.
|
||||
</p>
|
||||
|
||||
<p> To override the default location of Postfix shared libraries
|
||||
and database plugins specify, for example: </p>
|
||||
<p> To override the default location of Postfix dynamically-linked
|
||||
libraries and database plugins specify, for example: </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -368,8 +371,8 @@ $ make makefiles shared=yes <a href="postconf.5.html#shlib_directory">shlib_dire
|
||||
<p> If you intend to upgrade Postfix without stopping the mail
|
||||
system, then you should append the Postfix release version to the
|
||||
<a href="postconf.5.html#shlib_directory">shlib_directory</a> pathname, to eliminate the possibility that programs
|
||||
will link with shared libraries or database plugins from the wrong
|
||||
Postfix version. For example: </p>
|
||||
will link with dynamically-linked libraries or database plugins
|
||||
from the wrong Postfix version. For example: </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -481,7 +484,7 @@ or deinstall a database plugin package without having to edit
|
||||
postfix-files or dynamicmaps.cf. Instead, you give that plugin its
|
||||
own configuration files dynamicmaps.cf.d and postfix-files.d, and
|
||||
you add or remove those configuration files along with the database
|
||||
plugin shared object. </p>
|
||||
plugin dynamically-linked object. </p>
|
||||
|
||||
<li> <p> Each configuration file under the directory dynamicmaps.cf.d
|
||||
must have the same format as the configuration file dynamicmaps.cf.
|
||||
|
||||
@ -124,7 +124,8 @@ elements can be up to 255 characters long. The client must not send
|
||||
XCLIENT commands that exceed the 512 character limit for SMTP
|
||||
commands. To avoid exceeding the limit the client should send the
|
||||
information in multiple XCLIENT commands; for example, send NAME
|
||||
and ADDR first, then HELO and PROTO. </p>
|
||||
and ADDR last, after HELO and PROTO. Once ADDR is sent, the client
|
||||
is usually no longer authorized to send XCLIENT commands. </p>
|
||||
|
||||
<p> Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified
|
||||
in upper case, lower case or mixed case. </p>
|
||||
|
||||
@ -229,7 +229,7 @@ POSTCONF(1) POSTCONF(1)
|
||||
A non-shared, in-memory lookup table. Example: "<b><a href="DATABASE_README.html#types">inline</a>:{</b>
|
||||
<i>key</i><b>=</b><i>value</i><b>, {</b> <i>key</i> <b>=</b> <i>text with whitespace or comma</i> <b>}}</b>".
|
||||
Key-value pairs are separated by whitespace or comma;
|
||||
whitespace after "{" and before "}" is ignored. Inline
|
||||
whitespace after "<b>{</b>" and before "<b>}</b>" is ignored. Inline
|
||||
tables eliminate the need to create a database file for
|
||||
just a few fixed elements. See also the <i><a href="DATABASE_README.html#types">static</a>:</i> map
|
||||
type.
|
||||
@ -305,7 +305,7 @@ POSTCONF(1) POSTCONF(1)
|
||||
For example, <b><a href="DATABASE_README.html#types">static</a>:foobar</b> always returns the string <b>foo-</b>
|
||||
<b>bar</b> as lookup result. Specify "<b><a href="DATABASE_README.html#types">static</a>:{</b> <i>text with white-</i>
|
||||
<i>space</i> <b>}</b>" when the result contains whitespace; this form
|
||||
ignores whitespace after "{" and before "}". See also the
|
||||
ignores whitespace after "<b>{</b>" and before "<b>}</b>". See also the
|
||||
<i><a href="DATABASE_README.html#types">inline</a>:</i> map.
|
||||
|
||||
<b>tcp</b> (read-only)
|
||||
|
||||
@ -50,7 +50,9 @@
|
||||
# By default, EPOLL support is compiled in on platforms that
|
||||
# are known to support it.
|
||||
# .IP \fB-DNO_EAI\fR
|
||||
# Do not build with EAI (SMTPUTF8) support.
|
||||
# Do not build with EAI (SMTPUTF8) support. By default, EAI
|
||||
# support is compiled in when the "icuuc" library and header
|
||||
# files are found.
|
||||
# .IP \fB-DNO_INLINE\fR
|
||||
# Do not require support for C99 "inline" functions. Instead,
|
||||
# implement argument typechecks for non-printf/scanf-like
|
||||
|
||||
@ -256,7 +256,7 @@ with support for Berkeley DB databases.
|
||||
A non\-shared, in\-memory lookup table. Example: "\fBinline:{
|
||||
\fIkey\fB=\fIvalue\fB, { \fIkey\fB = \fItext with whitespace
|
||||
or comma\fB }}\fR". Key\-value pairs are separated by
|
||||
whitespace or comma; whitespace after "{" and before "}"
|
||||
whitespace or comma; whitespace after "\fB{\fR" and before "\fB}\fR"
|
||||
is ignored. Inline tables eliminate the need to create a
|
||||
database file for just a few fixed elements. See also the
|
||||
\fIstatic:\fR map type.
|
||||
@ -320,8 +320,8 @@ A table that always returns its name as lookup result. For
|
||||
example, \fBstatic:foobar\fR always returns the string
|
||||
\fBfoobar\fR as lookup result. Specify "\fBstatic:{ \fItext
|
||||
with whitespace\fB }\fR" when the result contains whitespace;
|
||||
this form ignores whitespace after "{" and before "}". See
|
||||
also the \fIinline:\fR map.
|
||||
this form ignores whitespace after "\fB{\fR" and before
|
||||
"\fB}\fR". See also the \fIinline:\fR map.
|
||||
.IP "\fBtcp\fR (read\-only)"
|
||||
TCP/IP client. The protocol is described in \fBtcp_table\fR(5).
|
||||
.IP "\fBtexthash\fR (read\-only)"
|
||||
|
||||
@ -229,49 +229,51 @@ $ make
|
||||
|
||||
<p> and so on. In some cases, optimization is turned off automatically. </p>
|
||||
|
||||
<h3>4.3 - Building with Postfix shared libraries and database plugins
|
||||
(Postfix ≥ 3.0) </h3>
|
||||
<h3>4.3 - Building with Postfix dynamically-linked libraries and
|
||||
database plugins (Postfix ≥ 3.0) </h3>
|
||||
|
||||
<p> Postfix shared-library and database plugin support exists for
|
||||
recent versions of Linux, FreeBSD and MacOS X. Shared-library builds
|
||||
may become the default at some point in the future. </p>
|
||||
<p> Postfix dynamically-linked library and database plugin support
|
||||
exists for recent versions of Linux, FreeBSD and MacOS X.
|
||||
Dynamically-linked library builds may become the default at some
|
||||
point in the future. </p>
|
||||
|
||||
<p> Overview of topics: </p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li><a href="#shared_enable">4.3.1 Turning on Postfix shared-library
|
||||
support</a>
|
||||
<li><a href="#shared_enable">4.3.1 Turning on Postfix dynamically-linked
|
||||
library support</a>
|
||||
|
||||
<li><a href="#dynamicmaps_enable">4.3.2 Turning on Postfix database-plugin
|
||||
support</a>
|
||||
|
||||
<li><a href="#shared_custom">4.3.3 Customizing Postfix shared
|
||||
<li><a href="#shared_custom">4.3.3 Customizing Postfix dynamically-linked
|
||||
libraries and database plugins</a>
|
||||
|
||||
<li><a href="#shared_tips">4.4.4 Tips for distribution maintainers</a>
|
||||
|
||||
</ul>
|
||||
|
||||
<p> Note: directories with Postfix shared libraries or database
|
||||
plugins should contain only postfix-related files. Postfix shared
|
||||
libraries and database plugins should not be installed in a "public"
|
||||
system directory such as /usr/lib or /usr/local/lib. Linking Postfix
|
||||
shared-library or database-plugin files into non-Postfix programs
|
||||
is not supported. Postfix shared libraries and database plugins
|
||||
implement a Postfix-internal API that changes without maintaining
|
||||
compatibility. </p>
|
||||
<p> Note: directories with Postfix dynamically-linked libraries
|
||||
or database plugins should contain only postfix-related files.
|
||||
Postfix dynamically-linked libraries and database plugins should
|
||||
not be installed in a "public" system directory such as /usr/lib
|
||||
or /usr/local/lib. Linking Postfix dynamically-linked library or
|
||||
database-plugin files into non-Postfix programs is not supported.
|
||||
Postfix dynamically-linked libraries and database plugins implement
|
||||
a Postfix-internal API that changes without maintaining compatibility.
|
||||
</p>
|
||||
|
||||
<h4><a name="shared_enable"> 4.3.1 Turning on Postfix shared-library
|
||||
support </a></h4>
|
||||
<h4><a name="shared_enable"> 4.3.1 Turning on Postfix dynamically-linked
|
||||
library support </a></h4>
|
||||
|
||||
<p> Postfix can be built with Postfix shared libraries (files
|
||||
typically named <tt>libpostfix-*.so</tt>). Postfix shared libraries
|
||||
add minor run-time overhead and result in significantly-smaller
|
||||
Postfix executable files. </p>
|
||||
<p> Postfix can be built with Postfix dynamically-linked libraries
|
||||
(files typically named <tt>libpostfix-*.so</tt>). Postfix
|
||||
dynamically-linked libraries add minor run-time overhead and result
|
||||
in significantly-smaller Postfix executable files. </p>
|
||||
|
||||
<p> Specify "shared=yes" on the "make makefiles" command line to
|
||||
build Postfix with shared-library support. </p>
|
||||
build Postfix with dynamically-linked library support. </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -281,17 +283,17 @@ $ make
|
||||
</blockquote>
|
||||
|
||||
<p> (Specify "make makefiles shared=no" to explicitly disable Postfix
|
||||
shared-library support). </p>
|
||||
dynamically-linked library support). </p>
|
||||
|
||||
<p> This installs shared libraries in $shlib_directory, typically
|
||||
/usr/lib/postfix or /usr/local/lib/postfix, with file names
|
||||
libpostfix-<i>name</i>.so, where the <i>name</i> is a source-code
|
||||
<p> This installs dynamically-linked libraries in $shlib_directory,
|
||||
typically /usr/lib/postfix or /usr/local/lib/postfix, with file
|
||||
names libpostfix-<i>name</i>.so, where the <i>name</i> is a source-code
|
||||
directory name such as "util" or "global". </p>
|
||||
|
||||
<p> See section 4.3.3 "Customizing Postfix shared libraries and
|
||||
database plugins" below for how to customize the Postfix shared-library
|
||||
location, including support to upgrade a running mail system safely.
|
||||
</p>
|
||||
<p> See section 4.3.3 "Customizing Postfix dynamically-linked
|
||||
libraries and database plugins" below for how to customize the
|
||||
Postfix dynamically-linked library location, including support to
|
||||
upgrade a running mail system safely. </p>
|
||||
|
||||
<h4><a name="dynamicmaps_enable"> 4.3.2 Turning on Postfix
|
||||
database-plugin support </a></h4>
|
||||
@ -318,12 +320,12 @@ $ make
|
||||
<p> (Specify "make makefiles dynamicmaps=no" to explicitly disable
|
||||
Postfix database-plugin support). </p>
|
||||
|
||||
<p> This implicitly enables shared-library support, installs the
|
||||
configuration file dynamicmaps.cf in $meta_directory (usually,
|
||||
/etc/postfix or /usr/local/etc/postfix), and installs database
|
||||
plugins in $shlib_directory (see above). Database plugins are named
|
||||
postfix-<i>type</i>.so where the <i>type</i> is a database type
|
||||
such as "cdb" or "ldap". </p>
|
||||
<p> This implicitly enables dynamically-linked library support,
|
||||
installs the configuration file dynamicmaps.cf in $meta_directory
|
||||
(usually, /etc/postfix or /usr/local/etc/postfix), and installs
|
||||
database plugins in $shlib_directory (see above). Database plugins
|
||||
are named postfix-<i>type</i>.so where the <i>type</i> is a database
|
||||
type such as "cdb" or "ldap". </p>
|
||||
|
||||
<blockquote>
|
||||
|
||||
@ -346,18 +348,19 @@ database client loading was meant to avoid. </p>
|
||||
version of Postfix database plugins and the location of the file
|
||||
dynamicmaps.cf. </p>
|
||||
|
||||
<h4><a name="shared_custom"> 4.3.3 Customizing Postfix shared
|
||||
<h4><a name="shared_custom"> 4.3.3 Customizing Postfix dynamically-linked
|
||||
libraries and database plugins </a></h4>
|
||||
|
||||
<h5> Customizing the location of Postfix shared libraries and
|
||||
database plugins </h5>
|
||||
<h5> Customizing the location of Postfix dynamically-linked libraries
|
||||
and database plugins </h5>
|
||||
|
||||
<p> As a reminder, the directories with Postfix shared libraries
|
||||
or database plugins should contain only Postfix-related files.
|
||||
Linking these files into other programs is not supported. </p>
|
||||
<p> As a reminder, the directories with Postfix dynamically-linked
|
||||
libraries or database plugins should contain only Postfix-related
|
||||
files. Linking these files into other programs is not supported.
|
||||
</p>
|
||||
|
||||
<p> To override the default location of Postfix shared libraries
|
||||
and database plugins specify, for example: </p>
|
||||
<p> To override the default location of Postfix dynamically-linked
|
||||
libraries and database plugins specify, for example: </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -368,8 +371,8 @@ $ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
|
||||
<p> If you intend to upgrade Postfix without stopping the mail
|
||||
system, then you should append the Postfix release version to the
|
||||
shlib_directory pathname, to eliminate the possibility that programs
|
||||
will link with shared libraries or database plugins from the wrong
|
||||
Postfix version. For example: </p>
|
||||
will link with dynamically-linked libraries or database plugins
|
||||
from the wrong Postfix version. For example: </p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
@ -481,7 +484,7 @@ or deinstall a database plugin package without having to edit
|
||||
postfix-files or dynamicmaps.cf. Instead, you give that plugin its
|
||||
own configuration files dynamicmaps.cf.d and postfix-files.d, and
|
||||
you add or remove those configuration files along with the database
|
||||
plugin shared object. </p>
|
||||
plugin dynamically-linked object. </p>
|
||||
|
||||
<li> <p> Each configuration file under the directory dynamicmaps.cf.d
|
||||
must have the same format as the configuration file dynamicmaps.cf.
|
||||
|
||||
@ -124,7 +124,8 @@ elements can be up to 255 characters long. The client must not send
|
||||
XCLIENT commands that exceed the 512 character limit for SMTP
|
||||
commands. To avoid exceeding the limit the client should send the
|
||||
information in multiple XCLIENT commands; for example, send NAME
|
||||
and ADDR first, then HELO and PROTO. </p>
|
||||
and ADDR last, after HELO and PROTO. Once ADDR is sent, the client
|
||||
is usually no longer authorized to send XCLIENT commands. </p>
|
||||
|
||||
<p> Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified
|
||||
in upper case, lower case or mixed case. </p>
|
||||
|
||||
@ -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 "20150129"
|
||||
#define MAIL_VERSION_NUMBER "3.0"
|
||||
#define MAIL_RELEASE_DATE "20150201"
|
||||
#define MAIL_VERSION_NUMBER "3.1"
|
||||
|
||||
#ifdef SNAPSHOT
|
||||
#define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE
|
||||
|
||||
@ -250,7 +250,7 @@
|
||||
/* A non-shared, in-memory lookup table. Example: "\fBinline:{
|
||||
/* \fIkey\fB=\fIvalue\fB, { \fIkey\fB = \fItext with whitespace
|
||||
/* or comma\fB }}\fR". Key-value pairs are separated by
|
||||
/* whitespace or comma; whitespace after "{" and before "}"
|
||||
/* whitespace or comma; whitespace after "\fB{\fR" and before "\fB}\fR"
|
||||
/* is ignored. Inline tables eliminate the need to create a
|
||||
/* database file for just a few fixed elements. See also the
|
||||
/* \fIstatic:\fR map type.
|
||||
@ -314,8 +314,8 @@
|
||||
/* example, \fBstatic:foobar\fR always returns the string
|
||||
/* \fBfoobar\fR as lookup result. Specify "\fBstatic:{ \fItext
|
||||
/* with whitespace\fB }\fR" when the result contains whitespace;
|
||||
/* this form ignores whitespace after "{" and before "}". See
|
||||
/* also the \fIinline:\fR map.
|
||||
/* this form ignores whitespace after "\fB{\fR" and before
|
||||
/* "\fB}\fR". See also the \fIinline:\fR map.
|
||||
/* .IP "\fBtcp\fR (read-only)"
|
||||
/* TCP/IP client. The protocol is described in \fBtcp_table\fR(5).
|
||||
/* .IP "\fBtexthash\fR (read-only)"
|
||||
|
||||
@ -115,6 +115,11 @@
|
||||
/* .IP "\fB-h \fIhost_lookup\fR (default: \fBdns\fR)"
|
||||
/* The hostname lookup methods used for the connection. See the
|
||||
/* documentation of smtp_host_lookup for syntax and semantics.
|
||||
/* .IP "\fB-k \fIcertfile\fR (default: none)\fR)"
|
||||
/* File with PEM-encoded TLS client certificate chain.
|
||||
/* .IP "\fB-K \fIkeyfile\fR (default: \fIcertfile\fR)\fR)"
|
||||
/* File with corresponding PEM-encoded TLS client private key,
|
||||
/* by default same as \fIcertfile\fR if one is specified.
|
||||
/* .IP "\fB-l \fIlevel\fR (default: \fBdane\fR or \fBsecure\fR)"
|
||||
/* The security level for the connection, default \fBdane\fR or
|
||||
/* \fBsecure\fR depending on whether DNSSEC is available. For syntax
|
||||
@ -436,6 +441,8 @@ typedef struct STATE {
|
||||
char *mdalg; /* fingerprint digest algorithm */
|
||||
char *CAfile; /* Trusted public CAs */
|
||||
char *CApath; /* Trusted public CAs */
|
||||
char *certfile; /* TLS client certificate file */
|
||||
char *keyfile; /* TLS client key file */
|
||||
ARGV *match; /* match arguments */
|
||||
int print_trust; /* -C option */
|
||||
BIO *tls_bio; /* BIO wrapper for stdout */
|
||||
@ -1528,6 +1535,8 @@ static void cleanup(STATE *state)
|
||||
myfree(state->mdalg);
|
||||
myfree(state->CApath);
|
||||
myfree(state->CAfile);
|
||||
myfree(state->certfile);
|
||||
myfree(state->keyfile);
|
||||
if (state->options.level)
|
||||
myfree(state->options.level);
|
||||
myfree(state->options.logopts);
|
||||
@ -1560,7 +1569,8 @@ static void usage(void)
|
||||
" destination [match ...]\n", var_procname,
|
||||
"[-acCfSvw] [-t conn_tmout] [-T cmd_tmout] [-L logopts]",
|
||||
"[-h host_lookup] [-l level] [-d mdalg] [-g grade] [-p protocols]",
|
||||
"[-A tafile] [-F CAfile.pem] [-P CApath/] [-m count] [-r delay]",
|
||||
"[-A tafile] [-F CAfile.pem] [-P CApath/] "
|
||||
"[-k certfile [-K keyfile]] [-m count] [-r delay]",
|
||||
"[-o name=value]");
|
||||
#else
|
||||
fprintf(stderr, "usage: %s [-acStTv] [-h host_lookup] [-o name=value] destination\n",
|
||||
@ -1585,8 +1595,8 @@ static void tls_init(STATE *state)
|
||||
log_level = state->options.logopts,
|
||||
verifydepth = DEF_SMTP_TLS_SCERT_VD,
|
||||
cache_type = "memory",
|
||||
cert_file = "",
|
||||
key_file = "",
|
||||
cert_file = state->certfile,
|
||||
key_file = state->keyfile,
|
||||
dcert_file = "",
|
||||
dkey_file = "",
|
||||
eccert_file = "",
|
||||
@ -1631,11 +1641,13 @@ static void parse_options(STATE *state, int argc, char *argv[])
|
||||
|
||||
#define OPTS "a:ch:o:St:T:v"
|
||||
#ifdef USE_TLS
|
||||
#define TLSOPTS "A:Cd:fF:g:l:L:m:p:P:r:w"
|
||||
#define TLSOPTS "A:Cd:fF:g:k:K:l:L:m:p:P:r:w"
|
||||
|
||||
state->mdalg = mystrdup("sha1");
|
||||
state->CApath = mystrdup("");
|
||||
state->CAfile = mystrdup("");
|
||||
state->certfile = mystrdup("");
|
||||
state->keyfile = mystrdup("");
|
||||
state->options.tas = argv_alloc(1);
|
||||
state->options.logopts = 0;
|
||||
state->level = TLS_LEV_DANE;
|
||||
@ -1696,6 +1708,22 @@ static void parse_options(STATE *state, int argc, char *argv[])
|
||||
myfree(state->grade);
|
||||
state->grade = mystrdup(optarg);
|
||||
break;
|
||||
case 'k':
|
||||
myfree(state->certfile);
|
||||
state->certfile = mystrdup(optarg);
|
||||
if (!*state->keyfile) {
|
||||
myfree(state->keyfile);
|
||||
state->keyfile = mystrdup(optarg);
|
||||
}
|
||||
break;
|
||||
case 'K':
|
||||
myfree(state->keyfile);
|
||||
state->keyfile = mystrdup(optarg);
|
||||
if (!*state->certfile) {
|
||||
myfree(state->certfile);
|
||||
state->certfile = mystrdup(optarg);
|
||||
}
|
||||
break;
|
||||
case 'l':
|
||||
if (state->options.level)
|
||||
myfree(state->options.level);
|
||||
|
||||
@ -4018,11 +4018,12 @@ static int xclient_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *argv)
|
||||
state->protocol = mystrdup(MAIL_PROTO_SMTP);
|
||||
}
|
||||
#ifdef USE_SASL_AUTH
|
||||
/* XXX What if they send the parameters via multiple commands? */
|
||||
if (got_login == 0)
|
||||
smtpd_sasl_auth_reset(state);
|
||||
else
|
||||
saved_username = mystrdup(state->sasl_username);
|
||||
if (smtpd_sasl_is_active(state)) {
|
||||
if (got_login)
|
||||
saved_username = mystrdup(state->sasl_username);
|
||||
smtpd_sasl_deactivate(state);
|
||||
if (state->tls_context == 0) /* TLS from XCLIENT proxy? */
|
||||
smtpd_sasl_activate(state, VAR_SMTPD_SASL_OPTS,
|
||||
@ -4030,10 +4031,10 @@ static int xclient_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *argv)
|
||||
else
|
||||
smtpd_sasl_activate(state, VAR_SMTPD_SASL_TLS_OPTS,
|
||||
var_smtpd_sasl_tls_opts);
|
||||
}
|
||||
if (got_login) {
|
||||
smtpd_sasl_auth_extern(state, saved_username, XCLIENT_CMD);
|
||||
myfree(saved_username);
|
||||
if (got_login) {
|
||||
smtpd_sasl_auth_extern(state, saved_username, XCLIENT_CMD);
|
||||
myfree(saved_username);
|
||||
}
|
||||
}
|
||||
#endif
|
||||
chat_reset(state, 0);
|
||||
|
||||
@ -88,16 +88,25 @@ int tls_set_ca_certificate_info(SSL_CTX *ctx, const char *CAfile,
|
||||
CAfile = 0;
|
||||
if (*CApath == 0)
|
||||
CApath = 0;
|
||||
|
||||
#define CA_PATH_FMT "%s%s%s"
|
||||
#define CA_PATH_ARGS(var, nextvar) \
|
||||
var ? #var "=\"" : "", \
|
||||
var ? var : "", \
|
||||
var ? (nextvar ? "\", " : "\"") : ""
|
||||
|
||||
if (CAfile || CApath) {
|
||||
if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
|
||||
msg_info("cannot load Certification Authority data: "
|
||||
"disabling TLS support");
|
||||
msg_info("cannot load Certification Authority data, "
|
||||
CA_PATH_FMT CA_PATH_FMT ": disabling TLS support",
|
||||
CA_PATH_ARGS(CAfile, CApath),
|
||||
CA_PATH_ARGS(CApath, 0));
|
||||
tls_print_errors();
|
||||
return (-1);
|
||||
}
|
||||
if (var_tls_append_def_CA && !SSL_CTX_set_default_verify_paths(ctx)) {
|
||||
msg_info("cannot set certificate verification paths: "
|
||||
"disabling TLS support");
|
||||
msg_info("cannot set default OpenSSL certificate verification "
|
||||
"paths: disabling TLS support");
|
||||
tls_print_errors();
|
||||
return (-1);
|
||||
}
|
||||
@ -120,13 +129,13 @@ static int set_cert_stuff(SSL_CTX *ctx, const char *cert_type,
|
||||
*/
|
||||
ERR_clear_error();
|
||||
if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) {
|
||||
msg_warn("cannot get %s certificate from file %s: "
|
||||
msg_warn("cannot get %s certificate from file \"%s\": "
|
||||
"disabling TLS support", cert_type, cert_file);
|
||||
tls_print_errors();
|
||||
return (0);
|
||||
}
|
||||
if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0) {
|
||||
msg_warn("cannot get %s private key from file %s: "
|
||||
msg_warn("cannot get %s private key from file \"%s\": "
|
||||
"disabling TLS support", cert_type, key_file);
|
||||
tls_print_errors();
|
||||
return (0);
|
||||
|
||||
@ -387,7 +387,7 @@ static dane_digest *add_digest(char *mdalg, int pref)
|
||||
&& ((md = EVP_get_digestbyname(dane_mdalg)) == 0
|
||||
|| (mdlen = EVP_MD_size(md)) <= 0
|
||||
|| mdlen > EVP_MAX_MD_SIZE)) {
|
||||
msg_warn("Unimplemented digest algoritm in %s: %s%s%s",
|
||||
msg_warn("Unimplemented digest algorithm in %s: %s%s%s",
|
||||
VAR_TLS_DANE_DIGESTS, mdalg,
|
||||
value ? "=" : "", value ? value : "");
|
||||
return (0);
|
||||
|
||||
@ -149,6 +149,7 @@ int strncasecmp_utf8x(int flags, const char *s1, const char *s2,
|
||||
}
|
||||
|
||||
#ifdef TEST
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <vstream.h>
|
||||
#include <vstring_vstream.h>
|
||||
@ -189,7 +190,7 @@ int main(int argc, char **argv)
|
||||
* Compare two substrings.
|
||||
*/
|
||||
else if (strcmp(args[0], "compare-len") == 0 && cmd->argc == 4
|
||||
&& (len = atoi(args[3])) > 0) {
|
||||
&& sscanf(args[3], "%d", &len) == 1 && len >= 0) {
|
||||
res = strncasecmp_utf8x(flags, args[1], args[2], len);
|
||||
vstream_printf("\"%.*s\" %s \"%.*s\"\n",
|
||||
len, args[1],
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user