Adding upstream version 3.10.2.
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
This commit is contained in:
parent
b6c197c021
commit
75cf244379
GPG key ID:
BCC918A2ABD66424
2325 changed files with 583315 additions and 0 deletions
445
.indent.pro
vendored
Normal file
445
.indent.pro
vendored
Normal file
|
|
@ -0,0 +1,445 @@
|
|||
-TABOUNCE_STATE
|
||||
-TADDR_MATCH_LIST
|
||||
-TADDR_PATTERN
|
||||
-TALIAS_TOKEN
|
||||
-TANVIL_CLNT
|
||||
-TANVIL_LOCAL
|
||||
-TANVIL_MAX
|
||||
-TANVIL_REMOTE
|
||||
-TANVIL_REQ_TABLE
|
||||
-TARGV
|
||||
-TASN1_INTEGER
|
||||
-TASN1_OBJECT
|
||||
-TATTR_CLNT
|
||||
-TATTR_OVER_INT
|
||||
-TATTR_OVER_STR
|
||||
-TATTR_OVER_TIME
|
||||
-TATTR_TABLE
|
||||
-TAUTHORITY_KEYID
|
||||
-TAUTO_CLNT
|
||||
-TBH_TABLE
|
||||
-TBINATTR
|
||||
-TBINATTR_INFO
|
||||
-TBINHASH
|
||||
-TBINHASH_INFO
|
||||
-TBIO
|
||||
-TBOUNCE_INFO
|
||||
-TBOUNCE_LOG
|
||||
-TBOUNCE_LOG_DSN_BUF
|
||||
-TBOUNCE_LOG_FORGE
|
||||
-TBOUNCE_LOG_RCPT_BUF
|
||||
-TBOUNCE_STAT
|
||||
-TBOUNCE_STR_PARAMETER
|
||||
-TBOUNCE_TEMPLATE
|
||||
-TBOUNCE_TEMPLATES
|
||||
-TBOUNCE_TIME_DIVISOR
|
||||
-TBOUNCE_TIME_PARAMETER
|
||||
-TBYTE_MASK
|
||||
-TCFG_PARSER
|
||||
-TCIDR_MATCH
|
||||
-TCLEANUP_REGION
|
||||
-TCLEANUP_STATE
|
||||
-TCLEANUP_STAT_DETAIL
|
||||
-TCLIENT_LIST
|
||||
-TCLNT_STREAM
|
||||
-TCONFIG_BOOL_FN_TABLE
|
||||
-TCONFIG_BOOL_TABLE
|
||||
-TCONFIG_INT_FN_TABLE
|
||||
-TCONFIG_INT_TABLE
|
||||
-TCONFIG_LONG_FN_TABLE
|
||||
-TCONFIG_LONG_TABLE
|
||||
-TCONFIG_NBOOL_FN_TABLE
|
||||
-TCONFIG_NBOOL_TABLE
|
||||
-TCONFIG_NCODE_TABLE
|
||||
-TCONFIG_NINT_FN_TABLE
|
||||
-TCONFIG_NINT_TABLE
|
||||
-TCONFIG_RAW_FN_TABLE
|
||||
-TCONFIG_RAW_TABLE
|
||||
-TCONFIG_STR_FN_TABLE
|
||||
-TCONFIG_STR_TABLE
|
||||
-TCONFIG_TIME_FN_TABLE
|
||||
-TCONFIG_TIME_TABLE
|
||||
-TCONST_CHAR_STAR
|
||||
-TCRYPTO_EX_DATA
|
||||
-TCTABLE
|
||||
-TCTABLE_ENTRY
|
||||
-TDB_COMMON_CTX
|
||||
-TDELIVERED_HDR_INFO
|
||||
-TDELIVER_ATTR
|
||||
-TDELIVER_REQUEST
|
||||
-TDELTA_TIME
|
||||
-TDICT
|
||||
-TDICT_CACHE
|
||||
-TDICT_CACHE_SREQ
|
||||
-TDICT_CACHE_SREQ_INFO
|
||||
-TDICT_CACHE_TEST
|
||||
-TDICT_CDBM
|
||||
-TDICT_CDBQ
|
||||
-TDICT_CIDR
|
||||
-TDICT_CIDR_ENTRY
|
||||
-TDICT_DB
|
||||
-TDICT_DBM
|
||||
-TDICT_DEBUG
|
||||
-TDICT_ENV
|
||||
-TDICT_FAIL
|
||||
-TDICT_FINAL_WRAPPER
|
||||
-TDICT_HT
|
||||
-TDICT_INLINE
|
||||
-TDICT_LDAP
|
||||
-TDICT_LMDB
|
||||
-TDICT_MC
|
||||
-TDICT_MONGODB
|
||||
-TDICT_MYSQL
|
||||
-TDICT_NI
|
||||
-TDICT_NIS
|
||||
-TDICT_NISPLUS
|
||||
-TDICT_NODE
|
||||
-TDICT_OPEN_EXTEND_FN
|
||||
-TDICT_OPEN_FN
|
||||
-TDICT_OPEN_INFO
|
||||
-TDICT_OWNER
|
||||
-TDICT_PCRE
|
||||
-TDICT_PCRE_ENGINE
|
||||
-TDICT_PCRE_EXPAND_CONTEXT
|
||||
-TDICT_PCRE_IF_RULE
|
||||
-TDICT_PCRE_MATCH_RULE
|
||||
-TDICT_PCRE_PRESCAN_CONTEXT
|
||||
-TDICT_PCRE_REGEXP
|
||||
-TDICT_PCRE_RULE
|
||||
-TDICT_PGSQL
|
||||
-TDICT_PIPE
|
||||
-TDICT_PROXY
|
||||
-TDICT_RAND
|
||||
-TDICT_RANDOM
|
||||
-TDICT_REGEXP
|
||||
-TDICT_REGEXP_EXPAND_CONTEXT
|
||||
-TDICT_REGEXP_IF_RULE
|
||||
-TDICT_REGEXP_MATCH_RULE
|
||||
-TDICT_REGEXP_PATTERN
|
||||
-TDICT_REGEXP_PRESCAN_CONTEXT
|
||||
-TDICT_REGEXP_RULE
|
||||
-TDICT_SDBM
|
||||
-TDICT_SOCKMAP
|
||||
-TDICT_SOCKMAP_REFC_HANDLE
|
||||
-TDICT_SQLITE
|
||||
-TDICT_STATIC
|
||||
-TDICT_SURROGATE
|
||||
-TDICT_TCP
|
||||
-TDICT_TEXT
|
||||
-TDICT_THASH
|
||||
-TDICT_UNION
|
||||
-TDICT_UNIX
|
||||
-TDICT_UTF8_BACKUP
|
||||
-TDICT_WRAPPER
|
||||
-TDNS_FIXED
|
||||
-TDNS_REPLY
|
||||
-TDNS_RR
|
||||
-TDOMAIN_LIST
|
||||
-TDSN
|
||||
-TDSN_BUF
|
||||
-TDSN_FILTER
|
||||
-TDSN_SPLIT
|
||||
-TDSN_STAT
|
||||
-TDYMAP_INFO
|
||||
-TEC_GROUP
|
||||
-TEC_KEY
|
||||
-TEDIT_FILE
|
||||
-TEVENT_MASK
|
||||
-TEVP_CIPHER_CTX
|
||||
-TEVP_MAC_CTX
|
||||
-TEVP_MD
|
||||
-TEVP_MD_CTX
|
||||
-TEVP_PKEY
|
||||
-TEXPAND_ATTR
|
||||
-TFILE
|
||||
-TFORWARD_INFO
|
||||
-THBC_ACTION_CALL_BACKS
|
||||
-THBC_CALL_BACKS
|
||||
-THBC_CHECKS
|
||||
-THBC_MAP_INFO
|
||||
-THBC_OUTPUT_CALL_BACKS
|
||||
-THBC_TEST_CONTEXT
|
||||
-THEADER_OPTS
|
||||
-THEADER_TOKEN
|
||||
-THMAC_CTX
|
||||
-THOST
|
||||
-THTABLE
|
||||
-THTABLE_INFO
|
||||
-TINET_ADDR_LIST
|
||||
-TINET_ADDR_SIZES
|
||||
-TINET_PROTO_INFO
|
||||
-TINSTANCE
|
||||
-TINST_SELECTION
|
||||
-TINT32_TYPE
|
||||
-TINTV
|
||||
-TINT_TABLE
|
||||
-TJMP_BUF_WRAPPER
|
||||
-TLDAP
|
||||
-TLDAPMessage
|
||||
-TLDAPURLDesc
|
||||
-TLDAP_CONN
|
||||
-TLIB_DP
|
||||
-TLIB_FN
|
||||
-TLMTP_ATTR
|
||||
-TLMTP_RESP
|
||||
-TLMTP_SESSION
|
||||
-TLMTP_STATE
|
||||
-TLOCAL_EXP
|
||||
-TLOCAL_STATE
|
||||
-TLOGIN_SENDER_MATCH
|
||||
-TLOGWRITER
|
||||
-TLONG_NAME_MASK
|
||||
-TMAC_EXP_CONTEXT
|
||||
-TMAC_EXP_OP_INFO
|
||||
-TMAC_HEAD
|
||||
-TMAC_PARSE
|
||||
-TMAIL_ADDR_FORMATTER
|
||||
-TMAIL_ADDR_MAP_TEST
|
||||
-TMAIL_PRINT
|
||||
-TMAIL_SCAN
|
||||
-TMAIL_STREAM
|
||||
-TMAIL_VERSION
|
||||
-TMAI_HOSTADDR_STR
|
||||
-TMAI_HOSTNAME_STR
|
||||
-TMAI_SERVNAME_STR
|
||||
-TMAI_SERVPORT_STR
|
||||
-TMAPS
|
||||
-TMAP_SEARCH
|
||||
-TMASTER_INT_WATCH
|
||||
-TMASTER_PROC
|
||||
-TMASTER_SERV
|
||||
-TMASTER_STATUS
|
||||
-TMASTER_STR_WATCH
|
||||
-TMATCH_LIST
|
||||
-TMATCH_OPS
|
||||
-TMBLOCK
|
||||
-TMBOX
|
||||
-TMDB_env
|
||||
-TMDB_txn
|
||||
-TMDB_val
|
||||
-TMILTER
|
||||
-TMILTER8
|
||||
-TMILTERS
|
||||
-TMILTER_MACROS
|
||||
-TMILTER_MSG_CONTEXT
|
||||
-TMIME_ENCODING
|
||||
-TMIME_INFO
|
||||
-TMIME_STACK
|
||||
-TMIME_STATE
|
||||
-TMIME_STATE_DETAIL
|
||||
-TMIME_TOKEN
|
||||
-TMKMAP
|
||||
-TMKMAP_DB
|
||||
-TMKMAP_DBM
|
||||
-TMKMAP_OPEN_EXTEND_FN
|
||||
-TMKMAP_OPEN_FN
|
||||
-TMKMAP_OPEN_INFO
|
||||
-TMKMAP_SDBM
|
||||
-TMSG_STATS
|
||||
-TMULTI_SERVER
|
||||
-TMVECT
|
||||
-TMYSQL
|
||||
-TMYSQL_NAME
|
||||
-TMYSQL_RES
|
||||
-TNAMADR_LIST
|
||||
-TNAME_ASSIGNMENT
|
||||
-TNAME_CODE
|
||||
-TNAME_MASK
|
||||
-TNBBIO
|
||||
-TNVTABLE_INFO
|
||||
-TOPTIONS
|
||||
-TPCF_DBMS_INFO
|
||||
-TPCF_DEPR_PARAM_INFO
|
||||
-TPCF_EVAL_CTX
|
||||
-TPCF_MASTER_EDIT_REQ
|
||||
-TPCF_MASTER_ENT
|
||||
-TPCF_MASTER_FLD_REQ
|
||||
-TPCF_PARAM_CTX
|
||||
-TPCF_PARAM_NODE
|
||||
-TPCF_PARAM_TABLE
|
||||
-TPCF_SERVICE_DEF
|
||||
-TPCF_SERVICE_PATTERN
|
||||
-TPCF_STRING_NV
|
||||
-TPEER_NAME
|
||||
-TPGSQL_NAME
|
||||
-TPICKUP_INFO
|
||||
-TPIPE_ATTR
|
||||
-TPIPE_PARAMS
|
||||
-TPIPE_STATE
|
||||
-TPLMYSQL
|
||||
-TPLPGSQL
|
||||
-TPOSTMAP_KEY_STATE
|
||||
-TPOST_MAIL_FCLOSE_STATE
|
||||
-TPOST_MAIL_STATE
|
||||
-TPRIVATE_STR_TABLE
|
||||
-TPSC_CALL_BACK_ENTRY
|
||||
-TPSC_CLIENT_INFO
|
||||
-TPSC_DNSBL_HEAD
|
||||
-TPSC_DNSBL_SCORE
|
||||
-TPSC_DNSBL_SITE
|
||||
-TPSC_ENDPT_LOOKUP_INFO
|
||||
-TPSC_HAPROXY_STATE
|
||||
-TPSC_SMTPD_COMMAND
|
||||
-TPSC_STARTTLS
|
||||
-TPSC_STATE
|
||||
-TQMGR_ENTRY
|
||||
-TQMGR_FEEDBACK
|
||||
-TQMGR_JOB
|
||||
-TQMGR_MESSAGE
|
||||
-TQMGR_PEER
|
||||
-TQMGR_QUEUE
|
||||
-TQMGR_RCPT
|
||||
-TQMGR_RCPT_LIST
|
||||
-TQMGR_RECIPIENT
|
||||
-TQMGR_SCAN
|
||||
-TQMGR_TRANSPORT
|
||||
-TQMQPD_STATE
|
||||
-TRCPT_BUF
|
||||
-TRECIPIENT
|
||||
-TRECIPIENT_LIST
|
||||
-TREC_TYPE_NAME
|
||||
-TRESOLVE_REPLY
|
||||
-TRESPONSE
|
||||
-TREST_TABLE
|
||||
-TRES_CONTEXT
|
||||
-TRING
|
||||
-TRWR_CONTEXT
|
||||
-TSCACHE
|
||||
-TSCACHE_CLNT
|
||||
-TSCACHE_MULTI
|
||||
-TSCACHE_MULTI_DEST
|
||||
-TSCACHE_MULTI_ENDP
|
||||
-TSCACHE_MULTI_HEAD
|
||||
-TSCACHE_SINGLE
|
||||
-TSCACHE_SINGLE_DEST
|
||||
-TSCACHE_SINGLE_ENDP
|
||||
-TSCACHE_SIZE
|
||||
-TSCAN_DIR
|
||||
-TSCAN_INFO
|
||||
-TSCAN_OBJ
|
||||
-TSENDER_LOGIN_MATCH
|
||||
-TSERVER_AC
|
||||
-TSESSION
|
||||
-TSHARED_PATH
|
||||
-TSINGLE_SERVER
|
||||
-TSINK_COMMAND
|
||||
-TSINK_STATE
|
||||
-TSLMDB
|
||||
-TSMFICTX
|
||||
-TSMTPD_CMD
|
||||
-TSMTPD_DEFER
|
||||
-TSMTPD_ENDPT_LOOKUP_INFO
|
||||
-TSMTPD_POLICY_CLNT
|
||||
-TSMTPD_PROXY
|
||||
-TSMTPD_RBL_EXPAND_CONTEXT
|
||||
-TSMTPD_RBL_STATE
|
||||
-TSMTPD_RCPTMAP_ST
|
||||
-TSMTPD_STATE
|
||||
-TSMTPD_TOKEN
|
||||
-TSMTPD_XFORWARD_ATTR
|
||||
-TSMTP_ADDR
|
||||
-TSMTP_CLI_ATTR
|
||||
-TSMTP_CMD
|
||||
-TSMTP_ITERATOR
|
||||
-TSMTP_RESP
|
||||
-TSMTP_SASL_AUTH_CACHE
|
||||
-TSMTP_SESSION
|
||||
-TSMTP_STATE
|
||||
-TSMTP_TLS_POLICY
|
||||
-TSMTP_TLS_SESS
|
||||
-TSMTP_TLS_SITE_POLICY
|
||||
-TSM_STATE
|
||||
-TSOCKADDR_SIZE
|
||||
-TSPAWN_ATTR
|
||||
-TSSL
|
||||
-TSSL_CTX
|
||||
-TSSL_SESSION
|
||||
-TSTATE
|
||||
-TSTRING_LIST
|
||||
-TSTRING_TABLE
|
||||
-TSYS_EXITS_DETAIL
|
||||
-TTEST_CASE
|
||||
-TTLSMGR_SCACHE
|
||||
-TTLSP_STATE
|
||||
-TTLSRPT_WRAPPER
|
||||
-TTLS_APPL_STATE
|
||||
-TTLS_CERTS
|
||||
-TTLS_CLIENT_INIT_PROPS
|
||||
-TTLS_CLIENT_PARAMS
|
||||
-TTLS_CLIENT_START_PROPS
|
||||
-TTLS_DANE
|
||||
-TTLS_PKEYS
|
||||
-TTLS_PRNG_SEED_INFO
|
||||
-TTLS_PRNG_SRC
|
||||
-TTLS_ROLE
|
||||
-TTLS_SCACHE
|
||||
-TTLS_SCACHE_ENTRY
|
||||
-TTLS_SERVER_INIT_PROPS
|
||||
-TTLS_SERVER_START_PROPS
|
||||
-TTLS_SESS_STATE
|
||||
-TTLS_TICKET_KEY
|
||||
-TTLS_TLSA
|
||||
-TTLS_USAGE
|
||||
-TTLS_VINFO
|
||||
-TTLScontext_t
|
||||
-TTOK822
|
||||
-TTRANSPORT_INFO
|
||||
-TTRIGGER_SERVER
|
||||
-TUSER_ATTR
|
||||
-TVBUF
|
||||
-TVSTREAM
|
||||
-TVSTREAM_POPEN_ARGS
|
||||
-TVSTRING
|
||||
-TWAIT_STATUS_T
|
||||
-TWATCHDOG
|
||||
-TWATCH_FD
|
||||
-TX509
|
||||
-TX509V3_CTX
|
||||
-TX509_EXTENSION
|
||||
-TX509_NAME
|
||||
-TX509_STORE_CTX
|
||||
-TXSASL_CLIENT
|
||||
-TXSASL_CLIENT_CREATE_ARGS
|
||||
-TXSASL_CLIENT_IMPL
|
||||
-TXSASL_CLIENT_IMPL_INFO
|
||||
-TXSASL_CYRUS_CB
|
||||
-TXSASL_CYRUS_CLIENT
|
||||
-TXSASL_CYRUS_ERROR_INFO
|
||||
-TXSASL_CYRUS_SERVER
|
||||
-TXSASL_DCSRV_MECH
|
||||
-TXSASL_DOVECOT_SERVER
|
||||
-TXSASL_DOVECOT_SERVER_IMPL
|
||||
-TXSASL_DOVECOT_SERVER_MECHS
|
||||
-TXSASL_SERVER
|
||||
-TXSASL_SERVER_CREATE_ARGS
|
||||
-TXSASL_SERVER_IMPL
|
||||
-TXSASL_SERVER_IMPL_INFO
|
||||
-Tbind_props
|
||||
-Tbson_iter_t
|
||||
-Tcipher_probe_t
|
||||
-Td2i_X509_t
|
||||
-Tdane_digest
|
||||
-Tdane_mtype
|
||||
-Tfilter_ctx
|
||||
-Tgeneral_name_stack_t
|
||||
-Tiana_digest
|
||||
-Toff_t
|
||||
-Tpem_load_state_t
|
||||
-Tregex_t
|
||||
-Tregmatch_t
|
||||
-Tsasl_conn_t
|
||||
-Tsasl_secret_t
|
||||
-Tsfsistat
|
||||
-Tsigset_t
|
||||
-Tsize_t
|
||||
-Tsockaddr
|
||||
-Tsockaddr_storage
|
||||
-Tssize_t
|
||||
-Tssl_cipher_stack_t
|
||||
-Tssl_comp_stack_t
|
||||
-Ttime_t
|
||||
-Ttlsa_filter
|
||||
-Tuint16_t
|
||||
-Tuint32_t
|
||||
-Tuint8_t
|
||||
-Tx509_stack_t
|
||||
25
.printfck
Normal file
25
.printfck
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
been_here_xt 2 0
|
||||
bounce_append 5 0
|
||||
cleanup_out_format 1 0
|
||||
defer_append 5 0
|
||||
mail_command 1 0
|
||||
mail_print 1 0
|
||||
msg_error 0 0
|
||||
msg_fatal 0 0
|
||||
msg_info 0 0
|
||||
msg_panic 0 0
|
||||
msg_warn 0 0
|
||||
opened 4 0
|
||||
post_mail_fprintf 1 0
|
||||
qmgr_message_bounce 2 0
|
||||
rec_fprintf 2 0
|
||||
sent 4 0
|
||||
smtp_cmd 1 0
|
||||
smtp_mesg_fail 2 0
|
||||
smtp_printf 1 0
|
||||
smtp_rcpt_fail 3 0
|
||||
smtp_site_fail 2 0
|
||||
udp_syslog 1 0
|
||||
vstream_fprintf 1 0
|
||||
vstream_printf 0 0
|
||||
vstring_sprintf 1 0
|
||||
184
AAAREADME
Normal file
184
AAAREADME
Normal file
|
|
@ -0,0 +1,184 @@
|
|||
Purpose of this document
|
||||
========================
|
||||
|
||||
This document provides a road map of the Postfix mail system source
|
||||
code distribution. I suggest that you
|
||||
|
||||
- take a few minutes to read this file,
|
||||
|
||||
- review the RELEASE_NOTES file for incompatible changes,
|
||||
|
||||
- and then proceed with the INSTALL instructions.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This is the public release of the Postfix mail system. Thank you
|
||||
for your interest in this project. Send me a postcard if you like
|
||||
it. My postal address is below.
|
||||
|
||||
You must read the LICENSE file, if you didn't do so already. A copy
|
||||
of the LICENSE must be distributed with every original, modified,
|
||||
complete, source, or binary copy of this software or parts thereof.
|
||||
I suggest that you keep a copy of the file in /etc/postfix/LICENSE.
|
||||
|
||||
Purpose of the Postfix mail system
|
||||
==================================
|
||||
|
||||
Postfix aims to be an alternative to the widely-used sendmail
|
||||
program.
|
||||
|
||||
Although IBM supported the Postfix development, it abstains from
|
||||
control over its evolution. The goal is to have Postfix installed
|
||||
on as many systems as possible. To this end, the software is given
|
||||
away with no strings attached to it, so that it can evolve with
|
||||
input from and under control by its users.
|
||||
|
||||
In other words, IBM releases Postfix only once. I will be around
|
||||
to guide its development for a limited time.
|
||||
|
||||
On-line resources devoted to the Postfix mail system
|
||||
====================================================
|
||||
|
||||
Web sites:
|
||||
|
||||
https://www.postfix.org/ current release information
|
||||
|
||||
Mail addresses (PLEASE send questions to the mailing list)
|
||||
|
||||
postfix-users@postfix.org Postfix users mailing list
|
||||
|
||||
In order to subscribe to the mailing list, see https://www.postfix.org/.
|
||||
|
||||
Acknowledgments
|
||||
===============
|
||||
|
||||
This release could not have happened without the input from a team
|
||||
of competent alpha testers. Their names appear in numerous places
|
||||
in the HISTORY file. I appreciate the input from my colleagues at
|
||||
the IBM Global Security Analysis Laboratory: Paul Karger, Dave
|
||||
Safford, Douglas Schales, and Leendert van Doorn. I also appreciate
|
||||
the support by Charles Palmer under whose leadership I began this
|
||||
project, and who had the privilege to name the software, twice.
|
||||
|
||||
Postcards
|
||||
=========
|
||||
|
||||
If you wish to express your appreciation for the Postfix software,
|
||||
you are welcome to send a postcard to:
|
||||
|
||||
Wietse Venema
|
||||
Google
|
||||
111 8th Avenue, 4th floor
|
||||
New York, NY 10011
|
||||
USA
|
||||
|
||||
Roadmap of the Postfix source distribution
|
||||
==========================================
|
||||
|
||||
The RELEASE_NOTES file describes new features, and lists incompatible
|
||||
changes with respect to previous Postfix versions.
|
||||
|
||||
The INSTALL file provides a step-by-step guide for building and
|
||||
installing Postfix on many popular UNIX platforms.
|
||||
|
||||
The COMPATIBILITY file lists features that Postfix does or does
|
||||
not yet implement, and how well it works with other software.
|
||||
|
||||
The HISTORY file gives a detailed log of changes to the software.
|
||||
|
||||
Point your browser at html/index.html for Postfix documentation
|
||||
and for hyperlinked versions of Postfix manual pages. Expect
|
||||
to see updated versions on-line at https://www.postfix.org/
|
||||
|
||||
Point your MANPATH environment variable at the `man' directory (use
|
||||
an absolute path) for UNIX-style on-line manual pages. These pages
|
||||
are also available through the HTML interface, which allows you to
|
||||
navigate faster.
|
||||
|
||||
The PORTING file discusses how to go about porting Postfix to other
|
||||
UNIX platforms.
|
||||
|
||||
Documentation:
|
||||
|
||||
README_FILES/ Instructions for specific Postfix features
|
||||
html/ HTML format
|
||||
man/ UNIX on-line manual page format
|
||||
|
||||
Example files:
|
||||
|
||||
conf/ configuration files, run-time scripts
|
||||
examples/ chroot environments, virtual domains
|
||||
|
||||
Library routines:
|
||||
|
||||
src/dns/ DNS client library
|
||||
src/global/ Postfix-specific support routines
|
||||
src/milter/ Postfix Milter (mail filter) client
|
||||
src/tls/ TLS client and server support
|
||||
src/util/ General-purpose support routines
|
||||
src/xsasl/ SASL plug-in API
|
||||
|
||||
Command-line utilities:
|
||||
|
||||
src/postalias/ Alias database management
|
||||
src/postcat/ List Postfix queue file
|
||||
src/postconf/ Configuration utility
|
||||
src/postdrop/ Postfix mail submission program
|
||||
src/postfix/ Postfix administrative interface
|
||||
src/postkick/ Postfix IPC for shell scripts
|
||||
src/postlock/ Postfix locking for shell scripts
|
||||
src/postlog/ Postfix logging for shell scripts
|
||||
src/postmap/ Postfix lookup table management
|
||||
src/postmulti/ Postfix multi-instance manager
|
||||
src/postqueue/ Postfix queue control program
|
||||
src/postsuper/ Postfix house keeping program
|
||||
src/sendmail/ Sendmail compatibility interface
|
||||
|
||||
Postfix daemons:
|
||||
|
||||
src/anvil/ Connection count/rate limiter
|
||||
src/bounce/ Bounce or defer mail
|
||||
src/cleanup/ Canonicalize and enqueue mail
|
||||
src/discard/ Trivial discard mailer
|
||||
src/dnsblog/ DNS agent for postscreen
|
||||
src/error/ Trivial error mailer
|
||||
src/flush/ Support for ETRN, sendmail -qI, sendmail -qR
|
||||
src/local/ Local delivery
|
||||
src/master/ Postfix resident superserver
|
||||
src/oqmgr/ Old queue manager
|
||||
src/pickup/ Local pickup
|
||||
src/pipe/ Pipe delivery
|
||||
src/postlogd/ Syslog alternative, logs to file or stdout
|
||||
src/postscreen/ Zombie blocker
|
||||
src/proxymap/ Table lookup proxy agent
|
||||
src/qmgr/ Queue manager
|
||||
src/qmqpd/ QMQPD server
|
||||
src/scache/ Postfix SMTP session cache
|
||||
src/showq/ List Postfix queue status
|
||||
src/smtp/ SMTP and LMTP client
|
||||
src/smtpd/ SMTP server
|
||||
src/spawn/ Run non-Postfix server
|
||||
src/tlsmgr/ TLS session keys and random pool
|
||||
src/tlsproxy/ TLS proxy for postscreen and outbound connection reuse
|
||||
src/trivial-rewrite/ Address rewriting and resolving
|
||||
src/verify/ address verification service
|
||||
src/virtual/ virtual mailbox-only delivery agent
|
||||
|
||||
Test programs:
|
||||
|
||||
src/fsstone/ Measure file system overhead
|
||||
src/posttls-finger/ Postfix SMTP/LMTP TLS probe utility
|
||||
src/smtpstone/ SMTP and QMQP server torture test
|
||||
|
||||
Miscellaneous:
|
||||
|
||||
auxiliary/ Auxiliary software etc.
|
||||
bin/ Postfix command executables
|
||||
conf/ Configuration files, run-time scripts
|
||||
include/ Include files
|
||||
implementation-notes/ Background information
|
||||
lib/ Object libraries
|
||||
libexec/ Postfix daemon executables
|
||||
mantools/ Documentation utilities
|
||||
proto/ Documentation source
|
||||
73
COMPATIBILITY
Normal file
73
COMPATIBILITY
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
.forward yes (empty files; can enable/disable mail to /file or |command)
|
||||
/usr/mail yes (compile time option)
|
||||
/usr/spool/mail yes (compile time option)
|
||||
/var/mail yes (compile time option)
|
||||
/var/spool/mail yes (compile time option)
|
||||
:include: yes (mail to /file and |command is off by default)
|
||||
address probing yes (optional persistent database)
|
||||
aliases yes (can enable/disable mail to /file or |command)
|
||||
bare newlines yes (but will send CRLF)
|
||||
blacklisting yes (client name/addr; helo hostname; mail from; rcpt to)
|
||||
connection caching yes (SMTP shared cache; LMTP shared cache)
|
||||
content filter yes (before and after queue, internal and external)
|
||||
db tables yes (compile time option)
|
||||
dbm tables yes (compile time option)
|
||||
delivered-to yes (configurable with prepend_delivered_header)
|
||||
dsn yes
|
||||
enhanced status codes yes
|
||||
errors-to: no (removed with Postfix 2.2)
|
||||
esmtp yes
|
||||
etrn support yes (per-destination log for authorized destinations only)
|
||||
fcntl locking yes (runtime configurable)
|
||||
flock locking yes (runtime configurable)
|
||||
genericstable yes (Postfix 2.2 generic(5) table)
|
||||
greylist yes (delegated policy script)
|
||||
home mailbox yes
|
||||
ident lookup no
|
||||
ipv6 yes (compatibility for ipv4-only systems)
|
||||
ldap tables yes (contributed)
|
||||
lmtp support yes (client only)
|
||||
luser relay yes
|
||||
m4 config no
|
||||
mail to command yes (configurable for .forward, aliases, :include:)
|
||||
mail to file yes (configurable for .forward, aliases, :include:)
|
||||
maildir yes (in home, system mailspool, /file/name/ alias)
|
||||
mailertable yes (it's called transport)
|
||||
mailq yes
|
||||
majordomo yes (edit approve script to delete /^delivered-to:/i)
|
||||
milter yes (except body replacement)
|
||||
mime yes (including 8bit to quoted-printable conversion)
|
||||
mysql tables yes (contributed)
|
||||
netinfo tables yes (contributed)
|
||||
newaliases yes (main alias database only)
|
||||
nis tables yes
|
||||
nis+ tables yes (contributed)
|
||||
no <> in smtp yes (most common address forms)
|
||||
pgsql tables yes (contributed)
|
||||
pipeline option yes (SMTP server and client; LMTP client)
|
||||
pop/imap no
|
||||
qmqp server yes (with verp support)
|
||||
rbl support yes
|
||||
return-receipt: no (use DSN NOTIFY=SUCCESS)
|
||||
rhsbl support yes
|
||||
sasl support yes (compile time option)
|
||||
sendmail -bt no
|
||||
sendmail -bv yes (sends delivery report via email)
|
||||
sendmail -q yes
|
||||
sendmail -qRxxx yes (for domains specified in fast_flush_domains)
|
||||
sendmail -qSxxx no
|
||||
sendmail -qtime ignored
|
||||
sendmail -v yes (sends delivery report via email)
|
||||
sendmail.cf no (uses table-driven address rewriting)
|
||||
size option yes, server and client
|
||||
smarthost yes (specify relayhost in main.cf)
|
||||
spf yes (delegated policy script)
|
||||
starttls yes (compile time option)
|
||||
tcp wrapper no (use built-in blacklist facility)
|
||||
user+extension yes (also: .forward+extension)
|
||||
user-extension yes (also: .forward-extension)
|
||||
user.lock yes (runtime configurable)
|
||||
uucp support yes (sends user@domain recipients)
|
||||
verp support yes (delimiters are configurable)
|
||||
virtual domains yes (via local delivery agent and via dedicated delivery agent)
|
||||
year 2000 safe yes
|
||||
35
COPYRIGHT
Normal file
35
COPYRIGHT
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
Included for the use of the fix_strcasecmp.c module which works
|
||||
around a Solaris problem.
|
||||
|
||||
/*
|
||||
* Copyright (c) 1987, 1993
|
||||
* The Regents of the University of California. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
* 3. All advertising materials mentioning features or use of this software
|
||||
* must display the following acknowledgement:
|
||||
* This product includes software developed by the University of
|
||||
* California, Berkeley and its contributors.
|
||||
* 4. Neither the name of the University nor the names of its contributors
|
||||
* may be used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
* SUCH DAMAGE.
|
||||
*/
|
||||
483
IPv6-ChangeLog
Normal file
483
IPv6-ChangeLog
Normal file
|
|
@ -0,0 +1,483 @@
|
|||
ChangeLog for Dean Strik's IPv6 patch for Postfix. The patch is based on
|
||||
PLD's patch, which in turn seems to be based on KAME's. For more information:
|
||||
|
||||
http://www.ipnet6.org/postfix/
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Version 1.25 Postfix release 2.1.3
|
||||
Postfix release 2.0.20
|
||||
Postfix snapshot 2.2-20040616
|
||||
|
||||
Bugfix: Misplaced myfree() caused a small memory leak. Reported
|
||||
by Christian von Roques.
|
||||
File: util/match_ops.c
|
||||
|
||||
Removed the colon (:) from the characters XFORWARD replaces by
|
||||
a question mark (IPv6 addresses looked like 2001?610?1108?5010??1
|
||||
in logging). Reported by Philipp Morger.
|
||||
File: smtpd/smtpd.c
|
||||
|
||||
Version 1.24 Postfix release 2.1.1
|
||||
Postfix release 2.0.20
|
||||
Postfix snapshot 2.0.19-20040312
|
||||
Postfix snapshot 2.2-20040504
|
||||
|
||||
Bugfix: Prefixlen non-null host portion validation (in CIDR maps
|
||||
for example) yielded incorrect results sometimes because signed
|
||||
arithmetic was used instead of unsigned.
|
||||
File: util/match_ops.c
|
||||
|
||||
Patch correction: The TLS+IPv6 patch for Postfix 2.1.0 missed
|
||||
the master.cf update (used for new installations). Added it
|
||||
back.
|
||||
|
||||
Version 1.23 Postfix release 2.1.0
|
||||
Postfix release 2.0.20
|
||||
Postfix snapshot 2.0.19-20040312
|
||||
|
||||
Patch fixes: Several code fixes to make the patch compile
|
||||
and work correctly when compiled without IPv6 support.
|
||||
|
||||
Bugfix (Solaris only?): address family length was not updated
|
||||
which could cause client hostname validation errors.
|
||||
File: smtpd/smtpd_peer.c
|
||||
|
||||
Portability: added support for Darwin 7.3+. This may need
|
||||
some further testing.
|
||||
|
||||
Cleanup: Restructure and redocument interface address
|
||||
retrieval functions. (This reduced the number of preprocessor
|
||||
statements from 99 to 93 ;)
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Cleanup: make several explicit casts to have compilers shut
|
||||
their pie holes about uninteresting things.
|
||||
|
||||
Version 1.22 Postfix release 2.0.19
|
||||
Postfix snapshot 2.0.19-20040312
|
||||
|
||||
Feature: Support "inet_interfaces = IPv4:all" and
|
||||
"inet_interfaces = IPv6:all", to restrict postfix to use
|
||||
either IPv4-only or IPv6-only. A more complete implementation
|
||||
will be part of a future patch. (Slightly modified) patch by
|
||||
Michal Ludvig, SuSE.
|
||||
Files: util/interfaces_to_af.[ch], util/inet_addr_local.c,
|
||||
global/own_inet_addr.c, global/wildcard_inet_addr.[ch],
|
||||
master/master_ent.ch
|
||||
|
||||
Bugfix: In Postfix snapshots, a #define was misplaced with
|
||||
the effect that IPv6 subnets were not included in auto-
|
||||
generated $mynetworks (i.e., mynetworks not defined in main.cf,
|
||||
when also mynetworks_style=subnet) on Linux 2.x systems.
|
||||
File: utils/sys_defs.h
|
||||
|
||||
Version 1.21a Postfix snapshots 2.0.18-2004{0122,0205,0209}
|
||||
2.0.19-20040312
|
||||
|
||||
TLS/snapshot version: Update TLS patch to 0.8.18-20040122.
|
||||
Performed as a total repatch. 0.8.18 is cleaner with tls_*
|
||||
variables if TLS is not actually compiled in.
|
||||
|
||||
Version 1.21 Postfix releases 2.0.18 - 2.0.19
|
||||
Postfix snapshot 2.0.16-20031231
|
||||
|
||||
Bugfix: The SMTP client could fail to setup a connection,
|
||||
erroring with a bogus "getaddrinfo(...): hostname nor servname
|
||||
provided" warning, because the wrong address was selected.
|
||||
File: smtp/smtp_connect.c
|
||||
|
||||
Safety: in dynamically growing data structures, update the
|
||||
length info after (instead of before) updating the data size.
|
||||
File: util/inet_addr_list.c
|
||||
|
||||
Version 1.20 Postfix release 2.0.16
|
||||
Postfix snapshot 2.0.16-20031207
|
||||
|
||||
Bugfix: The SMTP client would abort when binding to specific
|
||||
IPv6 addresses.
|
||||
File: smtp/smtp_connect.c
|
||||
|
||||
Synchronisation/bugfix: LMTP source address binding is identical
|
||||
to the SMTP source binding setup, avoiding the need for
|
||||
lmtp_bind_address(6) if inet_interfaces is set to a single
|
||||
host for an address family.
|
||||
File: lmtp/lmtp_connect.c
|
||||
|
||||
Version 1.19 Postfix release 2.0.16
|
||||
Postfix snapshot 2.0.16-20031207
|
||||
|
||||
Bugfix: Synchronisation of TLS patches in snapshots of 1.18[ab]
|
||||
was not complete, causing a crash of smtpd if used with the new
|
||||
proxy agent.
|
||||
File: smtpd/smtpd.c
|
||||
|
||||
Bugfix: SMTP source address binding based on a single hostname
|
||||
in inet_interfaces did not work since the code counted IPv4 and
|
||||
IPv6 addresses instead of only the used address family. Fixed,
|
||||
thereby no longer requiring exact specification of
|
||||
smtp_bind_address(6) in this case.
|
||||
File: smtp/smtp_connect.c
|
||||
|
||||
Bugfix: The QMQP sink server did not compile correctly. This
|
||||
program, part of smtpstone tools, is not compiled or installed
|
||||
by default.
|
||||
File: smtpstone/qmqp-sink.c
|
||||
|
||||
Bugfix: NI_WITHSCOPEID was not correctly defined everywhere,
|
||||
which could result in EAI_BADFLAGS. Changed location of
|
||||
definition to correct it.
|
||||
Files: util/sys_defs.h, util/inet_addr_list.h
|
||||
|
||||
Version 1.18b Postfix snapshot 2.0.16-20030921
|
||||
|
||||
IPv6 support: Added IPv6-enabled code to the new snapshot
|
||||
check_*_{ns,mx}_access restrictions.
|
||||
File: smtpd/smtpd_check.c
|
||||
|
||||
Version 1.18a Postfix release 2.0.16
|
||||
|
||||
Update (TLS patches): Updated Lutz Jaenicke's TLS patch to
|
||||
version 0.8.16. See pfixtls/ChangeLog for details.
|
||||
Diff contributed by Tuomo Soini.
|
||||
|
||||
The TLS+IPv6 patch now contains the original TLS patch
|
||||
documentation from Lutz Jaenicke.
|
||||
|
||||
Version 1.18 Postfix releases 2.0.14 - 2.0.15
|
||||
Postfix snapshot 2.0.14-20030812
|
||||
|
||||
Bugfix: Perform actual hostname verification in the SMTP
|
||||
and QMTP servers. This was never supported in the IPv6
|
||||
patch. Reported by Wolfgang S. Rupprecht.
|
||||
Files: smtpd/smtpd_peer.c, qmqpd/qmqpd_peer.c
|
||||
|
||||
IPv6 address ranges using address/prefixlength (e.g. in
|
||||
mynetworks and access maps) should be written as
|
||||
[ipv6:addr:ess]/plen (e.g. [fec0:10:20::]/48). The old
|
||||
supported syntax, [ipv6:addr:ess/plen] is deprecated and
|
||||
support will be removed in a later version.
|
||||
Thanks to Dr. Peter Bieringer and Pekka Savola for discussion.
|
||||
Files: util/match_ops.c, global/mynetworks.c
|
||||
|
||||
Explicitly prefer IPv6 over IPv4 addresses when delivering
|
||||
to a host when MX lookups are disabled when SMTP address
|
||||
randomization is on (default).
|
||||
File: smtp/smtp_addr.c
|
||||
|
||||
Compliance: write IPv6 address literals in mail headers
|
||||
as [IPv6:addr] instead of [addr] as per RFC 2821:4.1.3
|
||||
tagging requirement, for example [IPv6:fec0:10:20::1].
|
||||
Pointed out by Dr. Peter Bieringer.
|
||||
Files: smtpd/smtpd{,_peer,_state}.c, smtpd/smtpd.h
|
||||
|
||||
Version 1.17 Postfix release 2.0.13, 2.0.14
|
||||
Postfix snapshot 2.0.13-20030706, 2.0.14-20030812
|
||||
|
||||
Bugfix: Two memory allocation/deallocation bugs were
|
||||
introduced in patch 1.16. The impact of these bugs could
|
||||
be 'arbitrary' memory corruption.
|
||||
File: util/match_ops.c
|
||||
|
||||
Version 1.16 Postfix release 2.0.13
|
||||
Postfix snapshot 2.0.13-20030706
|
||||
|
||||
Cleanup: rewrote match_ops.c. This rewrite is partly based on
|
||||
patch by Takahiro Igarashi. The rewrite enables some better
|
||||
handling of scoped addresses, and drops all GPL code from the
|
||||
patch, easying license considerations. Also, allowed for
|
||||
use of this code by the CIDR maps.
|
||||
Files: util/match_ops.[ch]
|
||||
|
||||
Bugfix: correctly relay for scoped unicast addresses when
|
||||
applicable. Until now, while Postfix was able to recognize
|
||||
scoped addresses, it was not able to see e.g. fe80::10%fxp0
|
||||
as local in mynetworks validation. KAME-only code.
|
||||
(I've never heard of people using scoped addresses (think
|
||||
link-local addresses) for mail relaying though...)
|
||||
Files: util/inet_addr_list.[ch]
|
||||
|
||||
Feature (snapshot only): rewrote CIDR maps code to support
|
||||
IPv6 addresses, using new match_ops code. Allow the use
|
||||
of [::/0] since it allows one to easily disable further
|
||||
checks for IPv6 addresses.
|
||||
File: util/dict_cidr.c
|
||||
|
||||
Consistency: require IPv6 addresses in inet_interfaces to
|
||||
be enclosed in square brackets.
|
||||
File: util/inet_addr_host.c
|
||||
|
||||
Bugfix: (Linux2-only) A #define was misspelled. This could
|
||||
lead to Postfix being unable to read the system's local IPv6
|
||||
addresses (e.g. when using inet_interfaces).
|
||||
Spotted by Jochen Friedrich.
|
||||
File: util/sys_defs.h
|
||||
|
||||
Cleanup: require non-null host portion in CIDR /
|
||||
prefixlength notations for IPv6 (was IPv4-only).
|
||||
|
||||
Version 1.15a Postfix release 2.0.13
|
||||
|
||||
Update (TLS patches): Updated Lutz Jaenicke's TLS patch
|
||||
to version 0.8.15. This version introduces new options
|
||||
for managing SASL mechanisms. More information at:
|
||||
http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
|
||||
Diff contributed by Tuomo Soini.
|
||||
|
||||
Version 1.15 Postfix release 2.0.12, 2.0.13
|
||||
Postfix snapshot 2.0.12-20030621
|
||||
|
||||
Bugfix (TLS-snapshots only): a change in Postfix snapshot
|
||||
2.0.11-20030609 broke initialisation of TLS in smtpd,
|
||||
causing TLS to both be unadvertised and unaccepted.
|
||||
This was fixed again by reordering initialisation.
|
||||
File: smtpd/smtpd.c
|
||||
|
||||
Update (TLS patches): Updated Lutz Jaenicke's TLS patch
|
||||
to version 0.8.14. This version introduces a few fixes and
|
||||
uses USE_SSL instead of HAS_SSL. More information at:
|
||||
http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
|
||||
Diff contributed by Tuomo Soini.
|
||||
|
||||
Bugfix (Postfix releases only - this was already added to
|
||||
the snapshots in patch 1.14). KAME derived systems only.
|
||||
Correctly decode scoped addresses, including network
|
||||
interface specifiers.
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Version 1.14 Postfix releases 2.0.9, 2.0.10, 2.0.11, 2.0.12
|
||||
Postfix snapshots 2.0.9-20030424, 2.0.10-20030521,
|
||||
2.0.11-20030609, 2.0.12-20030611
|
||||
|
||||
Patch change: made the patch available as an IPv6-only
|
||||
patch (i.e., without the TLS code). This on popular
|
||||
request by users and packagers.
|
||||
A TLS+IPv6 version is still available of course.
|
||||
|
||||
Bugfix: correctly decode scoped addresses from now on
|
||||
(KAME derived systems only). I think the original code
|
||||
was written by Itojun, so I'm rather puzzled that it
|
||||
didn't work...
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Bugfix/portability: Recent KAME snapshots return both
|
||||
TCP and SCTP address information on getaddrinfo() if
|
||||
no protocol was specified. This causes the socket counts
|
||||
to be wrong, confusing child processes.
|
||||
Merged patch by JINMEI Tatuya of KAME to fix this.
|
||||
Files: master/master.h, master/master_{ent,conf}.[ch],
|
||||
util/inet_listen.c
|
||||
|
||||
Documentation: added an IPV6_README file to the patch.
|
||||
This file contains the primary documentation. Also,
|
||||
added a sample-ipv6.cf to describe the (currently few)
|
||||
IPv6 related main.cf parameters.
|
||||
|
||||
Bugfix: the netmask structures for the *unsupported*
|
||||
platforms (boldly assume /64) were added to the wrong
|
||||
list (addresses instead of masks). This bug did not affect
|
||||
any supported platform though.
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Portability: added support for HP/Compaq Tru64Unix V5.1
|
||||
and later. (compiled with CompaqCC only).
|
||||
Thanks to Sten Spans for providing root access to an
|
||||
IPv6-connected Tru64 testing machine.
|
||||
|
||||
Version 1.13 Postfix releases 2.0.4 - 2.0.9
|
||||
Postfix snapshots 2.0.3-20030126 - 2.0.7-20030319
|
||||
|
||||
Bugfix: Due to a missing storage pointer, DNS lookup
|
||||
results in the permit_mx_backups code were not processed,
|
||||
and smtpd would likely crash.
|
||||
Thanks to Wouter de Jong for reporting the crashes.
|
||||
File: smtpd/smtpd_check.c
|
||||
|
||||
Incompatible change: The addresses given to the parameters
|
||||
smtp_bind_address6 and lmtp_bind_address6 now need to be
|
||||
enclosed in square brackets for consistency.
|
||||
Files: [ls]mtp/[ls]mtp_connect.c
|
||||
|
||||
Version 1.12 Postfix releases 2.0.2, 2.0.3
|
||||
Postfix snapshots 2.0.2-20030115, 2.0.3-20030126
|
||||
|
||||
Bugfix/workaround (Solaris): A simplified comparison
|
||||
function for Solaris' qsort() function, would result
|
||||
in corruption of network addresses in the SMTP client.
|
||||
Fixed. Reported with possible fix by Edvard Tuinder.
|
||||
File: smtp/smtp_addr.c
|
||||
|
||||
Version 1.11 Postfix releases 2.0.0.x, 2.0.1, 2.0.2
|
||||
Postfix snapshots 2.0.0-20030105, 2.0.1-20030112
|
||||
2.0.2-20030115
|
||||
|
||||
Bugfix (Solaris): Properly initialize lifconf structure
|
||||
when requesting host interface addresses. If you get
|
||||
warnings about SIOCGLIFCONF with earlier versions,
|
||||
please upgrade.
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Patch fix: fixed compilation errors in case the patch is
|
||||
applied but built without IPv6 support (i.e., on unsupported
|
||||
platforms).
|
||||
|
||||
Version 1.10 Postfix snapshots 1.1.12-200212{19,21}
|
||||
Postfix releases 2.0.0, 2.0.0.{1,2}
|
||||
Postfix snapshots 2.0.0-20021223 - 2.0.0-20030101
|
||||
|
||||
'Bugfix': don't show spurious warnings on Linux systems
|
||||
about missing /proc/net/if_inet6 unless verbose mode
|
||||
is enabled.
|
||||
File: util/inet_addr_local.c
|
||||
|
||||
Bugfix: If unable to create a socket for a specific adress
|
||||
in the SMTP client (e.g., when trying to create an IPv6
|
||||
connection while the local host has no configured IPv6
|
||||
addresses), then stop the attempt.
|
||||
File: smtp/smtp_connect.c
|
||||
|
||||
Small bugfix: never query DNS for <localpart@[domain.tld]>.
|
||||
This syntax now correctly generates an error immediately.
|
||||
File: global/resolve_local.c
|
||||
|
||||
Updated TLS patch to 0.8.12-1.1.12-20021219-0.9.6h, fixing
|
||||
a bug with "sendmail -bs".
|
||||
|
||||
Version 1.9 Postfix version 1.1.11-20021115
|
||||
Postfix version 1.1.12-2002{1124,1209-1213}
|
||||
|
||||
Bugfix: with getifaddrs() code (*BSD, linux-USAGI), IPv4
|
||||
netmasks were set to /32 effectively. Work around broken
|
||||
netmask data structures (*BSD only perhaps).
|
||||
|
||||
Bugfix: same data corruption in another place created
|
||||
entirely wrong IPv4 netmasks. Work around broken
|
||||
SIOCGIFNETMASK structure.
|
||||
|
||||
New code was added for correct IPv6 netmasks. The original
|
||||
code did not contain IPv6 netmask support at all!
|
||||
For Solaris, use SIOCGLIF*; Linux: /proc/net/if_inet6.
|
||||
Getifaddrs() support is used otherwise. This should cover
|
||||
all supported systems. Other systems also work, prefix
|
||||
length is always set to /64 then.
|
||||
|
||||
Since there are no classes (context: Class A, class B etc
|
||||
networks) with IPv6, default to IPv6 subnet style if the
|
||||
mynetworks style is 'class'. I recommend against this style
|
||||
anyway.
|
||||
|
||||
Added support to display IPv6 nets mynetworks output.
|
||||
|
||||
Version 1.8 Postfix version 1.1.11-200211{01,15}
|
||||
|
||||
An earlier author of the patch made a typo in the GAI_STRERROR()
|
||||
macro, resulting in bogus error messages when checking for
|
||||
PTR records. Fixed.
|
||||
|
||||
IPv4-mapped addresses in the smtpd are converted to true IPv4
|
||||
addresses just after the connection has been made. This means
|
||||
that all IPv4-mapped addresses are now logged as true IPv4
|
||||
addresses. Hence beside RBL checks, also access maps now treat
|
||||
IPv4-mapped addresses as native IPv4. Note that ::ffff:...
|
||||
entries in your access tables will no longer work.
|
||||
|
||||
You can now specify IPv6 'parent' networks in your access maps,
|
||||
e.g. to reject all mail from 3ffe:200:... nodes, add the line
|
||||
3ffe:200 REJECT
|
||||
Use of trailing colons is discouraged because postmap will
|
||||
warn about it possibly being an alias...
|
||||
NOTE: I'll soon obsolete this again in favor of the more
|
||||
common address/len notation. This was just so trivial to add
|
||||
that it didn't hurt and I needed it :)
|
||||
|
||||
For easy reference, the version of the TLS/IPv6 patch can be
|
||||
dynamically queried using the tls_ipv6_version variable.
|
||||
This gives the short version (like, "1.8").
|
||||
|
||||
The service bind address for 'inet' sockets in master.cf (e.g.,
|
||||
smtpd), must be enclosed in square brackets '[..]' for IPv6
|
||||
addresses. The old style (without brackets) still works but is
|
||||
unsupported and may be removed in the future. Example
|
||||
[::1]:smtp inet n - n - - smtpd
|
||||
|
||||
Version 1.7 Postfix version 1.1.11-20021029 - 1.1.11-20021101
|
||||
|
||||
Postfix' SMTP client performs randomization of MX addresses
|
||||
when sending mail. This however could result in A records
|
||||
being used before AAAA records. This has been corrected.
|
||||
|
||||
Note that from Postfix version 1.1.11-20021029 on, there is
|
||||
a proxy_interfaces parameter. This has of course not been
|
||||
ported to IPv6 addresses...
|
||||
|
||||
Version 1.6 Postfix version 1.1.11-20020928
|
||||
|
||||
Added IPv6 support for backup_mx_networks feature; also the
|
||||
behaviour when DNS lookups fail when checking whether the
|
||||
local host is an MX for a domain conforms to the IPv4 case:
|
||||
defer rather than allow.
|
||||
|
||||
Version 1.5 Postfix version 1.1.11-20020917
|
||||
|
||||
I introduced two bugs when I rewrote my older LMTP IPv6 patch.
|
||||
These bugs effectively rendered LMTP useless. Now fixed.
|
||||
Bugs spotted by Kaj Niemi.
|
||||
|
||||
Now supports Solaris 8 and 9. Due to lack of testing equipment,
|
||||
this has been only tested in production on Solaris 9, both
|
||||
with gcc and the Sun Workshop Compiler.
|
||||
|
||||
Version 1.4 Postfix version 1.1.11-20020822 - 1.1.11-20020917
|
||||
|
||||
OpenBSD (>=200003) and FreeBSD release 4 and up now use
|
||||
getifaddrs(). This makes for cleaner code. The old code
|
||||
seems to be bug-ridden anyway.
|
||||
|
||||
Got rid of some compiler warnings. Should be cleaner on
|
||||
Alpha as well now. Thanks to Sten Spans for providing me
|
||||
access to an Alpha running FreeBSD4.
|
||||
|
||||
Fixed an old bug in smtpd memory alloation if you compiled
|
||||
without IPv6 support (the wrong buffer size was used. This
|
||||
was harmless for IPv6-enabled compiles since the sizes were
|
||||
equal then).
|
||||
|
||||
Added ChangeLog to the patch (as IPv6-ChangeLog) (this
|
||||
was absent in 1.3 contrary to docs).
|
||||
|
||||
Version 1.3 Postfix version 1.1.11-20020613 - 1.1.11-20020718
|
||||
|
||||
FYI: In postfix version 1.1.11-20020718, DNS lookups for
|
||||
AAAA can be done natively. The code matches the code in
|
||||
the patch (though the #ifdef changed from INET6 to T_AAAA).
|
||||
This change causes the patch for 1.1.11-20020718 to be a
|
||||
bit smaller.
|
||||
|
||||
Version 1.2 Postfix version 1.1.11-20020613
|
||||
|
||||
Added IPv6 support for the LMTP client.
|
||||
|
||||
Added lmtp_bind_address and lmtp_bind_address6 parameters,
|
||||
similar to those for smtp.
|
||||
|
||||
Added IPv6 support for the QMQP server.
|
||||
|
||||
Version 1.1 Postfix version 1.1.11-20020602 - 1.1.11-20020613
|
||||
|
||||
Added parameter smtp_bind_address6. By using this parameter,
|
||||
it is possible to bind to an IPv6 address, independently of
|
||||
IPv4 address binding.
|
||||
|
||||
Lutz fixed a bug in his TLS patch regarding SASL. Incorporated.
|
||||
|
||||
Version 1.0.x Postfix version 1.1.8-20020505 - 1.1.11-20020602
|
||||
|
||||
Patch derived from PLD's IPv6 patch for Postfix, revision 1.10
|
||||
which applied to early Postfix snapshots 1.1.x. Updated this
|
||||
patch to apply to 1.1.8-20020505.
|
||||
|
||||
Added compile-time checks for SS_LEN. Some Linux installations,
|
||||
and maybe other systems, do define SA_LEN, but not SS_LEN.
|
||||
|
||||
Several updates of postfix snapshots.
|
||||
|
||||
508
LICENSE
Normal file
508
LICENSE
Normal file
|
|
@ -0,0 +1,508 @@
|
|||
LICENSE - SECURE MAILER
|
||||
|
||||
This software is dual-licensed under both the Eclipse Public License
|
||||
version 2.0 and the IBM Public License version 1.0, for those who
|
||||
are more comfortable continuing with that license. Recipients can
|
||||
choose to take the software under the license of their choice.
|
||||
|
||||
The remainder of this text contains a copy of each license.
|
||||
|
||||
Eclipse Public License - v 2.0
|
||||
|
||||
THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
|
||||
PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION
|
||||
OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
|
||||
|
||||
1. DEFINITIONS
|
||||
|
||||
"Contribution" means:
|
||||
|
||||
a) in the case of the initial Contributor, the initial content
|
||||
Distributed under this Agreement, and
|
||||
|
||||
b) in the case of each subsequent Contributor:
|
||||
i) changes to the Program, and
|
||||
ii) additions to the Program;
|
||||
where such changes and/or additions to the Program originate from
|
||||
and are Distributed by that particular Contributor. A Contribution
|
||||
"originates" from a Contributor if it was added to the Program by
|
||||
such Contributor itself or anyone acting on such Contributor's behalf.
|
||||
Contributions do not include changes or additions to the Program that
|
||||
are not Modified Works.
|
||||
|
||||
"Contributor" means any person or entity that Distributes the Program.
|
||||
|
||||
"Licensed Patents" mean patent claims licensable by a Contributor which
|
||||
are necessarily infringed by the use or sale of its Contribution alone
|
||||
or when combined with the Program.
|
||||
|
||||
"Program" means the Contributions Distributed in accordance with this
|
||||
Agreement.
|
||||
|
||||
"Recipient" means anyone who receives the Program under this Agreement
|
||||
or any Secondary License (as applicable), including Contributors.
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source Code or other
|
||||
form, that is based on (or derived from) the Program and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship.
|
||||
|
||||
"Modified Works" shall mean any work in Source Code or other form that
|
||||
results from an addition to, deletion from, or modification of the
|
||||
contents of the Program, including, for purposes of clarity any new file
|
||||
in Source Code form that contains any contents of the Program. Modified
|
||||
Works shall not include works that contain only declarations,
|
||||
interfaces, types, classes, structures, or files of the Program solely
|
||||
in each case in order to link to, bind by name, or subclass the Program
|
||||
or Modified Works thereof.
|
||||
|
||||
"Distribute" means the acts of a) distributing or b) making available
|
||||
in any manner that enables the transfer of a copy.
|
||||
|
||||
"Source Code" means the form of a Program preferred for making
|
||||
modifications, including but not limited to software source code,
|
||||
documentation source, and configuration files.
|
||||
|
||||
"Secondary License" means either the GNU General Public License,
|
||||
Version 2.0, or any later versions of that license, including any
|
||||
exceptions or additional permissions as identified by the initial
|
||||
Contributor.
|
||||
|
||||
2. GRANT OF RIGHTS
|
||||
|
||||
a) Subject to the terms of this Agreement, each Contributor hereby
|
||||
grants Recipient a non-exclusive, worldwide, royalty-free copyright
|
||||
license to reproduce, prepare Derivative Works of, publicly display,
|
||||
publicly perform, Distribute and sublicense the Contribution of such
|
||||
Contributor, if any, and such Derivative Works.
|
||||
|
||||
b) Subject to the terms of this Agreement, each Contributor hereby
|
||||
grants Recipient a non-exclusive, worldwide, royalty-free patent
|
||||
license under Licensed Patents to make, use, sell, offer to sell,
|
||||
import and otherwise transfer the Contribution of such Contributor,
|
||||
if any, in Source Code or other form. This patent license shall
|
||||
apply to the combination of the Contribution and the Program if, at
|
||||
the time the Contribution is added by the Contributor, such addition
|
||||
of the Contribution causes such combination to be covered by the
|
||||
Licensed Patents. The patent license shall not apply to any other
|
||||
combinations which include the Contribution. No hardware per se is
|
||||
licensed hereunder.
|
||||
|
||||
c) Recipient understands that although each Contributor grants the
|
||||
licenses to its Contributions set forth herein, no assurances are
|
||||
provided by any Contributor that the Program does not infringe the
|
||||
patent or other intellectual property rights of any other entity.
|
||||
Each Contributor disclaims any liability to Recipient for claims
|
||||
brought by any other entity based on infringement of intellectual
|
||||
property rights or otherwise. As a condition to exercising the
|
||||
rights and licenses granted hereunder, each Recipient hereby
|
||||
assumes sole responsibility to secure any other intellectual
|
||||
property rights needed, if any. For example, if a third party
|
||||
patent license is required to allow Recipient to Distribute the
|
||||
Program, it is Recipient's responsibility to acquire that license
|
||||
before distributing the Program.
|
||||
|
||||
d) Each Contributor represents that to its knowledge it has
|
||||
sufficient copyright rights in its Contribution, if any, to grant
|
||||
the copyright license set forth in this Agreement.
|
||||
|
||||
e) Notwithstanding the terms of any Secondary License, no
|
||||
Contributor makes additional grants to any Recipient (other than
|
||||
those set forth in this Agreement) as a result of such Recipient's
|
||||
receipt of the Program under the terms of a Secondary License
|
||||
(if permitted under the terms of Section 3).
|
||||
|
||||
3. REQUIREMENTS
|
||||
|
||||
3.1 If a Contributor Distributes the Program in any form, then:
|
||||
|
||||
a) the Program must also be made available as Source Code, in
|
||||
accordance with section 3.2, and the Contributor must accompany
|
||||
the Program with a statement that the Source Code for the Program
|
||||
is available under this Agreement, and informs Recipients how to
|
||||
obtain it in a reasonable manner on or through a medium customarily
|
||||
used for software exchange; and
|
||||
|
||||
b) the Contributor may Distribute the Program under a license
|
||||
different than this Agreement, provided that such license:
|
||||
i) effectively disclaims on behalf of all other Contributors all
|
||||
warranties and conditions, express and implied, including
|
||||
warranties or conditions of title and non-infringement, and
|
||||
implied warranties or conditions of merchantability and fitness
|
||||
for a particular purpose;
|
||||
|
||||
ii) effectively excludes on behalf of all other Contributors all
|
||||
liability for damages, including direct, indirect, special,
|
||||
incidental and consequential damages, such as lost profits;
|
||||
|
||||
iii) does not attempt to limit or alter the recipients' rights
|
||||
in the Source Code under section 3.2; and
|
||||
|
||||
iv) requires any subsequent distribution of the Program by any
|
||||
party to be under a license that satisfies the requirements
|
||||
of this section 3.
|
||||
|
||||
3.2 When the Program is Distributed as Source Code:
|
||||
|
||||
a) it must be made available under this Agreement, or if the
|
||||
Program (i) is combined with other material in a separate file or
|
||||
files made available under a Secondary License, and (ii) the initial
|
||||
Contributor attached to the Source Code the notice described in
|
||||
Exhibit A of this Agreement, then the Program may be made available
|
||||
under the terms of such Secondary Licenses, and
|
||||
|
||||
b) a copy of this Agreement must be included with each copy of
|
||||
the Program.
|
||||
|
||||
3.3 Contributors may not remove or alter any copyright, patent,
|
||||
trademark, attribution notices, disclaimers of warranty, or limitations
|
||||
of liability ("notices") contained within the Program from any copy of
|
||||
the Program which they Distribute, provided that Contributors may add
|
||||
their own appropriate notices.
|
||||
|
||||
4. COMMERCIAL DISTRIBUTION
|
||||
|
||||
Commercial distributors of software may accept certain responsibilities
|
||||
with respect to end users, business partners and the like. While this
|
||||
license is intended to facilitate the commercial use of the Program,
|
||||
the Contributor who includes the Program in a commercial product
|
||||
offering should do so in a manner which does not create potential
|
||||
liability for other Contributors. Therefore, if a Contributor includes
|
||||
the Program in a commercial product offering, such Contributor
|
||||
("Commercial Contributor") hereby agrees to defend and indemnify every
|
||||
other Contributor ("Indemnified Contributor") against any losses,
|
||||
damages and costs (collectively "Losses") arising from claims, lawsuits
|
||||
and other legal actions brought by a third party against the Indemnified
|
||||
Contributor to the extent caused by the acts or omissions of such
|
||||
Commercial Contributor in connection with its distribution of the Program
|
||||
in a commercial product offering. The obligations in this section do not
|
||||
apply to any claims or Losses relating to any actual or alleged
|
||||
intellectual property infringement. In order to qualify, an Indemnified
|
||||
Contributor must: a) promptly notify the Commercial Contributor in
|
||||
writing of such claim, and b) allow the Commercial Contributor to control,
|
||||
and cooperate with the Commercial Contributor in, the defense and any
|
||||
related settlement negotiations. The Indemnified Contributor may
|
||||
participate in any such claim at its own expense.
|
||||
|
||||
For example, a Contributor might include the Program in a commercial
|
||||
product offering, Product X. That Contributor is then a Commercial
|
||||
Contributor. If that Commercial Contributor then makes performance
|
||||
claims, or offers warranties related to Product X, those performance
|
||||
claims and warranties are such Commercial Contributor's responsibility
|
||||
alone. Under this section, the Commercial Contributor would have to
|
||||
defend claims against the other Contributors related to those performance
|
||||
claims and warranties, and if a court requires any other Contributor to
|
||||
pay any damages as a result, the Commercial Contributor must pay
|
||||
those damages.
|
||||
|
||||
5. NO WARRANTY
|
||||
|
||||
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
|
||||
PERMITTED BY APPLICABLE LAW, THE PROGRAM IS PROVIDED ON AN "AS IS"
|
||||
BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR
|
||||
IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF
|
||||
TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
|
||||
PURPOSE. Each Recipient is solely responsible for determining the
|
||||
appropriateness of using and distributing the Program and assumes all
|
||||
risks associated with its exercise of rights under this Agreement,
|
||||
including but not limited to the risks and costs of program errors,
|
||||
compliance with applicable laws, damage to or loss of data, programs
|
||||
or equipment, and unavailability or interruption of operations.
|
||||
|
||||
6. DISCLAIMER OF LIABILITY
|
||||
|
||||
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
|
||||
PERMITTED BY APPLICABLE LAW, NEITHER RECIPIENT NOR ANY CONTRIBUTORS
|
||||
SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST
|
||||
PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
||||
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
||||
ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE
|
||||
EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
7. GENERAL
|
||||
|
||||
If any provision of this Agreement is invalid or unenforceable under
|
||||
applicable law, it shall not affect the validity or enforceability of
|
||||
the remainder of the terms of this Agreement, and without further
|
||||
action by the parties hereto, such provision shall be reformed to the
|
||||
minimum extent necessary to make such provision valid and enforceable.
|
||||
|
||||
If Recipient institutes patent litigation against any entity
|
||||
(including a cross-claim or counterclaim in a lawsuit) alleging that the
|
||||
Program itself (excluding combinations of the Program with other software
|
||||
or hardware) infringes such Recipient's patent(s), then such Recipient's
|
||||
rights granted under Section 2(b) shall terminate as of the date such
|
||||
litigation is filed.
|
||||
|
||||
All Recipient's rights under this Agreement shall terminate if it
|
||||
fails to comply with any of the material terms or conditions of this
|
||||
Agreement and does not cure such failure in a reasonable period of
|
||||
time after becoming aware of such noncompliance. If all Recipient's
|
||||
rights under this Agreement terminate, Recipient agrees to cease use
|
||||
and distribution of the Program as soon as reasonably practicable.
|
||||
However, Recipient's obligations under this Agreement and any licenses
|
||||
granted by Recipient relating to the Program shall continue and survive.
|
||||
|
||||
Everyone is permitted to copy and distribute copies of this Agreement,
|
||||
but in order to avoid inconsistency the Agreement is copyrighted and
|
||||
may only be modified in the following manner. The Agreement Steward
|
||||
reserves the right to publish new versions (including revisions) of
|
||||
this Agreement from time to time. No one other than the Agreement
|
||||
Steward has the right to modify this Agreement. The Eclipse Foundation
|
||||
is the initial Agreement Steward. The Eclipse Foundation may assign the
|
||||
responsibility to serve as the Agreement Steward to a suitable separate
|
||||
entity. Each new version of the Agreement will be given a distinguishing
|
||||
version number. The Program (including Contributions) may always be
|
||||
Distributed subject to the version of the Agreement under which it was
|
||||
received. In addition, after a new version of the Agreement is published,
|
||||
Contributor may elect to Distribute the Program (including its
|
||||
Contributions) under the new version.
|
||||
|
||||
Except as expressly stated in Sections 2(a) and 2(b) above, Recipient
|
||||
receives no rights or licenses to the intellectual property of any
|
||||
Contributor under this Agreement, whether expressly, by implication,
|
||||
estoppel or otherwise. All rights in the Program not expressly granted
|
||||
under this Agreement are reserved. Nothing in this Agreement is intended
|
||||
to be enforceable by any entity that is not a Contributor or Recipient.
|
||||
No third-party beneficiary rights are created under this Agreement.
|
||||
|
||||
Exhibit A - Form of Secondary Licenses Notice
|
||||
|
||||
"This Source Code may also be made available under the following
|
||||
Secondary Licenses when the conditions for such availability set forth
|
||||
in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
|
||||
version(s), and exceptions or additional permissions here}."
|
||||
|
||||
Simply including a copy of this Agreement, including this Exhibit A
|
||||
is not sufficient to license the Source Code under Secondary Licenses.
|
||||
|
||||
If it is not possible or desirable to put the notice in a particular
|
||||
file, then You may include the notice in a location (such as a LICENSE
|
||||
file in a relevant directory) where a recipient would be likely to
|
||||
look for such a notice.
|
||||
|
||||
You may add additional accurate notices of copyright ownership.
|
||||
|
||||
IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER
|
||||
|
||||
THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS IBM PUBLIC
|
||||
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE
|
||||
PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
|
||||
|
||||
1. DEFINITIONS
|
||||
|
||||
"Contribution" means:
|
||||
a) in the case of International Business Machines Corporation ("IBM"),
|
||||
the Original Program, and
|
||||
b) in the case of each Contributor,
|
||||
i) changes to the Program, and
|
||||
ii) additions to the Program;
|
||||
where such changes and/or additions to the Program originate
|
||||
from and are distributed by that particular Contributor.
|
||||
A Contribution 'originates' from a Contributor if it was added
|
||||
to the Program by such Contributor itself or anyone acting on
|
||||
such Contributor's behalf.
|
||||
Contributions do not include additions to the Program which:
|
||||
(i) are separate modules of software distributed in conjunction
|
||||
with the Program under their own license agreement, and
|
||||
(ii) are not derivative works of the Program.
|
||||
|
||||
"Contributor" means IBM and any other entity that distributes the Program.
|
||||
|
||||
"Licensed Patents " mean patent claims licensable by a Contributor which
|
||||
are necessarily infringed by the use or sale of its Contribution alone
|
||||
or when combined with the Program.
|
||||
|
||||
"Original Program" means the original version of the software accompanying
|
||||
this Agreement as released by IBM, including source code, object code
|
||||
and documentation, if any.
|
||||
|
||||
"Program" means the Original Program and Contributions.
|
||||
|
||||
"Recipient" means anyone who receives the Program under this Agreement,
|
||||
including all Contributors.
|
||||
|
||||
2. GRANT OF RIGHTS
|
||||
|
||||
a) Subject to the terms of this Agreement, each Contributor hereby
|
||||
grants Recipient a non-exclusive, worldwide, royalty-free copyright
|
||||
license to reproduce, prepare derivative works of, publicly display,
|
||||
publicly perform, distribute and sublicense the Contribution of such
|
||||
Contributor, if any, and such derivative works, in source code and
|
||||
object code form.
|
||||
|
||||
b) Subject to the terms of this Agreement, each Contributor hereby
|
||||
grants Recipient a non-exclusive, worldwide, royalty-free patent
|
||||
license under Licensed Patents to make, use, sell, offer to sell,
|
||||
import and otherwise transfer the Contribution of such Contributor,
|
||||
if any, in source code and object code form. This patent license
|
||||
shall apply to the combination of the Contribution and the Program
|
||||
if, at the time the Contribution is added by the Contributor, such
|
||||
addition of the Contribution causes such combination to be covered
|
||||
by the Licensed Patents. The patent license shall not apply to any
|
||||
other combinations which include the Contribution. No hardware per
|
||||
se is licensed hereunder.
|
||||
|
||||
c) Recipient understands that although each Contributor grants the
|
||||
licenses to its Contributions set forth herein, no assurances are
|
||||
provided by any Contributor that the Program does not infringe the
|
||||
patent or other intellectual property rights of any other entity.
|
||||
Each Contributor disclaims any liability to Recipient for claims
|
||||
brought by any other entity based on infringement of intellectual
|
||||
property rights or otherwise. As a condition to exercising the rights
|
||||
and licenses granted hereunder, each Recipient hereby assumes sole
|
||||
responsibility to secure any other intellectual property rights
|
||||
needed, if any. For example, if a third party patent license
|
||||
is required to allow Recipient to distribute the Program, it is
|
||||
Recipient's responsibility to acquire that license before distributing
|
||||
the Program.
|
||||
|
||||
d) Each Contributor represents that to its knowledge it has sufficient
|
||||
copyright rights in its Contribution, if any, to grant the copyright
|
||||
license set forth in this Agreement.
|
||||
|
||||
3. REQUIREMENTS
|
||||
|
||||
A Contributor may choose to distribute the Program in object code form
|
||||
under its own license agreement, provided that:
|
||||
a) it complies with the terms and conditions of this Agreement; and
|
||||
b) its license agreement:
|
||||
i) effectively disclaims on behalf of all Contributors all
|
||||
warranties and conditions, express and implied, including
|
||||
warranties or conditions of title and non-infringement, and
|
||||
implied warranties or conditions of merchantability and fitness
|
||||
for a particular purpose;
|
||||
ii) effectively excludes on behalf of all Contributors all
|
||||
liability for damages, including direct, indirect, special,
|
||||
incidental and consequential damages, such as lost profits;
|
||||
iii) states that any provisions which differ from this Agreement
|
||||
are offered by that Contributor alone and not by any other
|
||||
party; and
|
||||
iv) states that source code for the Program is available from
|
||||
such Contributor, and informs licensees how to obtain it in a
|
||||
reasonable manner on or through a medium customarily used for
|
||||
software exchange.
|
||||
|
||||
When the Program is made available in source code form:
|
||||
a) it must be made available under this Agreement; and
|
||||
b) a copy of this Agreement must be included with each copy of the
|
||||
Program.
|
||||
|
||||
Each Contributor must include the following in a conspicuous location
|
||||
in the Program:
|
||||
|
||||
Copyright (c) 1997,1998,1999, International Business Machines
|
||||
Corporation and others. All Rights Reserved.
|
||||
|
||||
In addition, each Contributor must identify itself as the originator of
|
||||
its Contribution, if any, in a manner that reasonably allows subsequent
|
||||
Recipients to identify the originator of the Contribution.
|
||||
|
||||
4. COMMERCIAL DISTRIBUTION
|
||||
|
||||
Commercial distributors of software may accept certain responsibilities
|
||||
with respect to end users, business partners and the like. While this
|
||||
license is intended to facilitate the commercial use of the Program, the
|
||||
Contributor who includes the Program in a commercial product offering
|
||||
should do so in a manner which does not create potential liability for
|
||||
other Contributors. Therefore, if a Contributor includes the Program in
|
||||
a commercial product offering, such Contributor ("Commercial Contributor")
|
||||
hereby agrees to defend and indemnify every other Contributor
|
||||
("Indemnified Contributor") against any losses, damages and costs
|
||||
(collectively "Losses") arising from claims, lawsuits and other legal
|
||||
actions brought by a third party against the Indemnified Contributor to
|
||||
the extent caused by the acts or omissions of such Commercial Contributor
|
||||
in connection with its distribution of the Program in a commercial
|
||||
product offering. The obligations in this section do not apply to any
|
||||
claims or Losses relating to any actual or alleged intellectual property
|
||||
infringement. In order to qualify, an Indemnified Contributor must:
|
||||
a) promptly notify the Commercial Contributor in writing of such claim,
|
||||
and
|
||||
b) allow the Commercial Contributor to control, and cooperate with
|
||||
the Commercial Contributor in, the defense and any related
|
||||
settlement negotiations. The Indemnified Contributor may
|
||||
participate in any such claim at its own expense.
|
||||
|
||||
For example, a Contributor might include the Program in a commercial
|
||||
product offering, Product X. That Contributor is then a Commercial
|
||||
Contributor. If that Commercial Contributor then makes performance
|
||||
claims, or offers warranties related to Product X, those performance
|
||||
claims and warranties are such Commercial Contributor's responsibility
|
||||
alone. Under this section, the Commercial Contributor would have to
|
||||
defend claims against the other Contributors related to those performance
|
||||
claims and warranties, and if a court requires any other Contributor to
|
||||
pay any damages as a result, the Commercial Contributor must pay those
|
||||
damages.
|
||||
|
||||
5. NO WARRANTY
|
||||
|
||||
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED
|
||||
ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER
|
||||
EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR
|
||||
CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
|
||||
PARTICULAR PURPOSE. Each Recipient is solely responsible for determining
|
||||
the appropriateness of using and distributing the Program and assumes
|
||||
all risks associated with its exercise of rights under this Agreement,
|
||||
including but not limited to the risks and costs of program errors,
|
||||
compliance with applicable laws, damage to or loss of data, programs or
|
||||
equipment, and unavailability or interruption of operations.
|
||||
|
||||
6. DISCLAIMER OF LIABILITY
|
||||
|
||||
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR
|
||||
ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
|
||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
|
||||
WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
|
||||
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
||||
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION
|
||||
OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF
|
||||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
7. GENERAL
|
||||
|
||||
If any provision of this Agreement is invalid or unenforceable under
|
||||
applicable law, it shall not affect the validity or enforceability of
|
||||
the remainder of the terms of this Agreement, and without further action
|
||||
by the parties hereto, such provision shall be reformed to the minimum
|
||||
extent necessary to make such provision valid and enforceable.
|
||||
|
||||
If Recipient institutes patent litigation against a Contributor with
|
||||
respect to a patent applicable to software (including a cross-claim or
|
||||
counterclaim in a lawsuit), then any patent licenses granted by that
|
||||
Contributor to such Recipient under this Agreement shall terminate
|
||||
as of the date such litigation is filed. In addition, If Recipient
|
||||
institutes patent litigation against any entity (including a cross-claim
|
||||
or counterclaim in a lawsuit) alleging that the Program itself (excluding
|
||||
combinations of the Program with other software or hardware) infringes
|
||||
such Recipient's patent(s), then such Recipient's rights granted under
|
||||
Section 2(b) shall terminate as of the date such litigation is filed.
|
||||
|
||||
All Recipient's rights under this Agreement shall terminate if it fails
|
||||
to comply with any of the material terms or conditions of this Agreement
|
||||
and does not cure such failure in a reasonable period of time after
|
||||
becoming aware of such noncompliance. If all Recipient's rights under
|
||||
this Agreement terminate, Recipient agrees to cease use and distribution
|
||||
of the Program as soon as reasonably practicable. However, Recipient's
|
||||
obligations under this Agreement and any licenses granted by Recipient
|
||||
relating to the Program shall continue and survive.
|
||||
|
||||
IBM may publish new versions (including revisions) of this Agreement
|
||||
from time to time. Each new version of the Agreement will be given a
|
||||
distinguishing version number. The Program (including Contributions)
|
||||
may always be distributed subject to the version of the Agreement under
|
||||
which it was received. In addition, after a new version of the Agreement
|
||||
is published, Contributor may elect to distribute the Program (including
|
||||
its Contributions) under the new version. No one other than IBM has the
|
||||
right to modify this Agreement. Except as expressly stated in Sections
|
||||
2(a) and 2(b) above, Recipient receives no rights or licenses to the
|
||||
intellectual property of any Contributor under this Agreement, whether
|
||||
expressly, by implication, estoppel or otherwise. All rights in the
|
||||
Program not expressly granted under this Agreement are reserved.
|
||||
|
||||
This Agreement is governed by the laws of the State of New York and the
|
||||
intellectual property laws of the United States of America. No party to
|
||||
this Agreement will bring a legal action under this Agreement more than
|
||||
one year after the cause of action arose. Each party waives its rights
|
||||
to a jury trial in any resulting litigation.
|
||||
22
Makefile
Normal file
22
Makefile
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Usage:
|
||||
# make makefiles [name=value]...
|
||||
#
|
||||
# See makedefs for a description of available options.
|
||||
# Examples:
|
||||
#
|
||||
# make makefiles
|
||||
# make makefiles CC="purify cc"
|
||||
# make makefiles CC=cc OPT=
|
||||
#
|
||||
SHELL = /bin/sh
|
||||
|
||||
default: update
|
||||
|
||||
update depend clean tidy depend_update: Makefiles
|
||||
$(MAKE) MAKELEVEL= $@
|
||||
|
||||
install upgrade:
|
||||
@echo Please review the INSTALL instructions first.
|
||||
|
||||
makefiles Makefiles:
|
||||
$(MAKE) -f Makefile.in MAKELEVEL= Makefiles
|
||||
239
Makefile.in
Normal file
239
Makefile.in
Normal file
|
|
@ -0,0 +1,239 @@
|
|||
# To test with valgrind:
|
||||
# make -i tests NORANDOMIZE="" VALGRIND="valgrind --tool=memcheck --log-file=/some/where.%p"
|
||||
SHELL = /bin/sh
|
||||
WARN = -Wmissing-prototypes -Wformat -Wno-comment -fno-common
|
||||
OPTS = 'WARN=$(WARN)'
|
||||
DIRS = src/util src/global src/dns src/tls src/xsasl src/master src/milter \
|
||||
src/postfix src/fsstone src/smtpstone \
|
||||
src/sendmail src/error src/pickup src/cleanup src/smtpd src/local \
|
||||
src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce \
|
||||
src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop \
|
||||
src/postkick src/postlock src/postlog src/postmap src/postqueue \
|
||||
src/postsuper src/qmqpd src/spawn src/flush src/verify \
|
||||
src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr \
|
||||
src/postmulti src/postscreen src/dnsblog src/tlsproxy \
|
||||
src/posttls-finger src/postlogd
|
||||
MANDIRS = proto man html
|
||||
LIBEXEC = libexec/post-install libexec/postfix-script libexec/postfix-wrapper \
|
||||
libexec/postmulti-script libexec/postfix-tls-script
|
||||
PLUGINS = meta/dynamicmaps.cf
|
||||
META = meta/main.cf.proto meta/master.cf.proto meta/postfix-files \
|
||||
meta/makedefs.out $(PLUGINS)
|
||||
EXPAND = sed -e "s;\$${LIB_PREFIX};$(LIB_PREFIX);" \
|
||||
-e "s;\$${LIB_SUFFIX};$(LIB_SUFFIX);"
|
||||
SHLIB_DIR_OVERRIDE = \
|
||||
$${shlib_directory:-`$(SHLIB_ENV) bin/postconf -dhx shlib_directory`}
|
||||
|
||||
default: update
|
||||
|
||||
# While generating the top-level Makefile, we must get the PLUGIN_LD
|
||||
# setting directly from the latest makedefs.out result.
|
||||
|
||||
makefiles Makefiles conf/makedefs.out:
|
||||
(echo "# Do not edit -- this file documents how Postfix was built for your machine."; $(SHELL) makedefs) >makedefs.tmp
|
||||
set +e; if cmp makedefs.tmp conf/makedefs.out; then rm makedefs.tmp; \
|
||||
else mv makedefs.tmp conf/makedefs.out; fi >/dev/null 2>/dev/null
|
||||
set -e; for i in $(DIRS); do \
|
||||
(set -e; echo "[$$i]"; cd $$i; rm -f Makefile; \
|
||||
$(MAKE) -f Makefile.in Makefile MAKELEVEL=) || exit 1; \
|
||||
done
|
||||
@set -- `grep '^PLUGIN_LD' conf/makedefs.out`; \
|
||||
rm -f Makefile; (cat conf/makedefs.out; \
|
||||
case "$$3" in \
|
||||
""|":") grep -v '^PLUGINS' Makefile.in;; \
|
||||
*) cat Makefile.in;; \
|
||||
esac) >Makefile
|
||||
|
||||
update tests root_tests:
|
||||
set -e; for i in $(DIRS); do \
|
||||
(set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
|
||||
done
|
||||
|
||||
update: $(META) $(LIBEXEC)
|
||||
|
||||
libexec/post-install: conf/post-install
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
# Censor out build directory information.
|
||||
|
||||
meta/makedefs.out: conf/makedefs.out
|
||||
grep -v SHLIB_ENV $? > $@
|
||||
|
||||
meta/postfix-files: conf/postfix-files conf/makedefs.out Makefile
|
||||
rm -f $@
|
||||
(if [ "${SHLIB_DIR}" = "no" -o "${SHLIB_DIR}" = "" ]; then \
|
||||
sed -e '/^\$$shlib_directory/d' \
|
||||
-e '/dynamicmaps.cf/d' conf/postfix-files; \
|
||||
elif [ "${PLUGIN_LD}" = ":" -o "${PLUGIN_LD}" = "" ]; then \
|
||||
sed -e '/dynamicmaps.cf/d' \
|
||||
-e '/^\$$shlib_directory\/\$${LIB_PREFIX}/d' \
|
||||
conf/postfix-files | $(EXPAND); \
|
||||
else \
|
||||
$(EXPAND) conf/postfix-files | awk -F: ' \
|
||||
BEGIN { \
|
||||
count = split("'"$(DEFINED_MAP_TYPES)"'", names, " "); \
|
||||
for (n = 1; n <= count; n++) \
|
||||
have["$$shlib_directory/$(LIB_PREFIX)" names[n] \
|
||||
"$(LIB_SUFFIX)"] = 1; } \
|
||||
/^[$$]shlib_directory.$(LIB_PREFIX)/ { \
|
||||
if (have[$$1]) print; next } \
|
||||
{ print } \
|
||||
'; \
|
||||
fi) | case "$(MAKE_FIX)" in \
|
||||
*) cat;; \
|
||||
esac > $@
|
||||
|
||||
libexec/postfix-script: conf/postfix-script
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
libexec/postfix-tls-script: conf/postfix-tls-script
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
libexec/postfix-wrapper: conf/postfix-wrapper
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
meta/main.cf.proto: conf/main.cf
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
meta/master.cf.proto: conf/master.cf
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
libexec/postmulti-script: conf/postmulti-script
|
||||
rm -f $@ && ln -f $? $@
|
||||
|
||||
meta/dynamicmaps.cf: conf/dynamicmaps.cf Makefile
|
||||
rm -f $@ && $(EXPAND) conf/dynamicmaps.cf | $(AWK) ' \
|
||||
BEGIN { split("'"$(DEFINED_MAP_TYPES)"'", map_types); \
|
||||
for (n in map_types) has_type[map_types[n]] = n } \
|
||||
/^#/ { print } \
|
||||
/^[a-z]/ { if (has_type[$$1]) print } \
|
||||
' >$@
|
||||
|
||||
manpages:
|
||||
set -e; for i in $(MANDIRS); do \
|
||||
(set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
|
||||
done </dev/null
|
||||
|
||||
# Some checks require a bin/postconf executable.
|
||||
pre-release-checks: typo-check double-check missing-proxy-read-maps-check \
|
||||
postlink-check postfix-files-check \
|
||||
postconf-unimplemented-check postconf-undocumented-check \
|
||||
check-table-proto check-see-postconf-d-output \
|
||||
check-snapshot-nonprod
|
||||
|
||||
postfix-files-check:
|
||||
mantools/check-postfix-files | diff /dev/null -
|
||||
|
||||
postlink-check:
|
||||
$(SHLIB_ENV) mantools/check-postlink | diff /dev/null -
|
||||
|
||||
postconf-undocumented-check:
|
||||
$(SHLIB_ENV) mantools/check-postconf-undocumented | diff /dev/null -
|
||||
|
||||
postconf-unimplemented-check:
|
||||
$(SHLIB_ENV) mantools/check-postconf-unimplemented | diff /dev/null -
|
||||
|
||||
missing-proxy-read-maps-check:
|
||||
$(SHLIB_ENV) mantools/missing-proxy-read-maps | diff /dev/null -
|
||||
|
||||
typo-check: spell-cc spell-install-proto-text spell-proto-html \
|
||||
check-spell-history
|
||||
|
||||
double-check: double-cc double-install-proto-text double-proto-html \
|
||||
check-double-history
|
||||
|
||||
spell-cc:
|
||||
mantools/check-spell-cc | diff /dev/null -
|
||||
|
||||
spell-install-proto-text:
|
||||
mantools/check-spell-install-proto-text | diff /dev/null -
|
||||
|
||||
spell-proto-html:
|
||||
mantools/check-spell-proto-html | diff /dev/null -
|
||||
|
||||
double-cc:
|
||||
mantools/check-double-cc | diff /dev/null -
|
||||
|
||||
double-install-proto-text:
|
||||
mantools/check-double-install-proto-text | diff /dev/null -
|
||||
|
||||
double-proto-html:
|
||||
mantools/check-double-proto-html | diff /dev/null -
|
||||
|
||||
check-spell-history:
|
||||
mantools/check-spell-history | diff /dev/null -
|
||||
|
||||
check-double-history:
|
||||
mantools/check-double-history | diff /dev/null -
|
||||
|
||||
check-table-proto:
|
||||
mantools/check-table-proto | diff /dev/null -
|
||||
|
||||
check-see-postconf-d-output:
|
||||
mantools/check-see-postconf-d-output | diff /dev/null -
|
||||
|
||||
check-snapshot-nonprod:
|
||||
mantools/check-snapshot-nonprod
|
||||
|
||||
# The build-time shlib_directory setting must take precedence over
|
||||
# the installed main.cf settings, otherwise we can't update an
|
||||
# installed system from dynamicmaps=yes<->dynamicmaps=no or from
|
||||
# shared=yes<->shared=no.
|
||||
|
||||
install: update
|
||||
SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
|
||||
$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
|
||||
postfix-install $(POSTFIX_INSTALL_OPTS)
|
||||
|
||||
package: update
|
||||
SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
|
||||
$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
|
||||
postfix-install -package $(POSTFIX_INSTALL_OPTS)
|
||||
|
||||
upgrade: update
|
||||
SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
|
||||
$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
|
||||
postfix-install -non-interactive $(POSTFIX_INSTALL_OPTS)
|
||||
|
||||
|
||||
non-interactive-package: update
|
||||
SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
|
||||
$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
|
||||
postfix-install -non-interactive -package $(POSTFIX_INSTALL_OPTS)
|
||||
|
||||
depend clean:
|
||||
set -e; for i in $(DIRS); do \
|
||||
(set -e; echo "[$$i]"; cd $$i; $(MAKE) $@) || exit 1; \
|
||||
done
|
||||
|
||||
depend_update:
|
||||
set -e; for i in $(DIRS); do \
|
||||
(set -e; echo "[$$i]"; cd $$i; $(MAKE) depend && $(MAKE) $(OPTS) update) \
|
||||
|| exit 1; \
|
||||
done
|
||||
|
||||
tidy: clean
|
||||
rm -f Makefile */Makefile src/*/Makefile
|
||||
cp -p Makefile.init Makefile
|
||||
rm -f README_FILES/RELEASE_NOTES
|
||||
ln -s ../RELEASE_NOTES README_FILES
|
||||
rm -f bin/[!CRS]* lib/[!CRS]* include/[!CRS]* libexec/[!CRS]* \
|
||||
src/*/libpostfix-*.so src/*/libpostfix-*.dylib \
|
||||
src/*/postfix-*.so src/*/postfix-*.dylib \
|
||||
junk */junk */*/junk \
|
||||
*core */*core */*/*core \
|
||||
.nfs* */.nfs* */*/.nfs* \
|
||||
.pure */.pure */*/.pure \
|
||||
*.out */*.out */*/*.out \
|
||||
*.tmp */*.tmp */*/*.tmp \
|
||||
*.a */*.a */*/*.a \
|
||||
*~ */*~ */*/*~ \
|
||||
*- */*- */*/*- \
|
||||
*.orig */*.orig */*/*.orig \
|
||||
*.bak */*.bak */*/*.bak \
|
||||
make.err */make.err */*/make.err \
|
||||
*.gmon */*.gmon */*/*.gmon \
|
||||
conf/main.cf.default conf/bounce.cf.default meta/*
|
||||
find . -type s -print | xargs rm -f
|
||||
find . -type d -print | xargs chmod 755
|
||||
find . -type f -print | xargs chmod a+r
|
||||
22
Makefile.init
Normal file
22
Makefile.init
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Usage:
|
||||
# make makefiles [name=value]...
|
||||
#
|
||||
# See makedefs for a description of available options.
|
||||
# Examples:
|
||||
#
|
||||
# make makefiles
|
||||
# make makefiles CC="purify cc"
|
||||
# make makefiles CC=cc OPT=
|
||||
#
|
||||
SHELL = /bin/sh
|
||||
|
||||
default: update
|
||||
|
||||
update depend clean tidy depend_update: Makefiles
|
||||
$(MAKE) MAKELEVEL= $@
|
||||
|
||||
install upgrade:
|
||||
@echo Please review the INSTALL instructions first.
|
||||
|
||||
makefiles Makefiles:
|
||||
$(MAKE) -f Makefile.in MAKELEVEL= Makefiles
|
||||
24
PORTING
Normal file
24
PORTING
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
In order to port software to a new platform:
|
||||
|
||||
- Choose a SYSTEMTYPE name for the new system. You must use a name
|
||||
that includes at least the major version of the operating system
|
||||
(such as SUNOS4 or LINUX2), so that different releases of the same
|
||||
system can be supported without confusion.
|
||||
|
||||
- Add a case statement to the "makedefs" shell script in the source
|
||||
code top-level directory that recognizes the new system reliably,
|
||||
and that emits the right system-specific information. Be sure to
|
||||
make the code robust against user PATH settings; if the system
|
||||
offers multiple UNIX flavors (e.g. BSD and SYSV) be sure to build
|
||||
for the native flavor, instead of the emulated one.
|
||||
|
||||
- Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h
|
||||
include file. You may have to invent new feature macro names.
|
||||
Please choose sensible feature macro names such as HAS_DBM or
|
||||
FIONREAD_IN_SYS_FILIO_H.
|
||||
|
||||
I strongly recommend against using "#ifdef SYSTEMTYPE" in individual
|
||||
source files. While this may look like the quickest solution, it
|
||||
will create a mess when newer versions of the same SYSTEMTYPE need
|
||||
to be supported. You're likely to end up placing "#ifdef" sections
|
||||
all over the source code again.
|
||||
89
README_FILES/AAAREADME
Normal file
89
README_FILES/AAAREADME
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
PPoossttffiixx DDooccuummeennttaattiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
GGeenneerraall ccoonnffiigguurraattiioonn
|
||||
|
||||
* BASIC_CONFIGURATION_README: Basic configuration
|
||||
* SOHO_README: Small/home office hints and tips
|
||||
* STANDARD_CONFIGURATION_README: Standard configuration examples
|
||||
* ADDRESS_REWRITING_README: Address rewriting
|
||||
* VIRTUAL_README: Virtual domain hosting
|
||||
* SASL_README: SASL Authentication
|
||||
* TLS_README: TLS Encryption and authentication
|
||||
* FORWARD_SECRECY_README: TLS Forward Secrecy
|
||||
* TLSRPT_README: TLSRPT Protocol Support
|
||||
* IPV6_README: IP Version 6 Support
|
||||
* SMTPUTF8_README: SMTPUTF8 Support
|
||||
* MAILLOG_README: Postfix logging to file or stdout
|
||||
* COMPATIBILITY_README: Backwards-Compatibility Safety Net
|
||||
* DEPRECATION_README: Deprecated features and alternatives
|
||||
* INSTALL: Installation from source code
|
||||
|
||||
PPrroobblleemm ssoollvviinngg
|
||||
|
||||
* QSHAPE_README: Bottleneck analysis
|
||||
* STRESS_README: Stress-dependent configuration
|
||||
* TUNING_README: Performance tuning
|
||||
* DEBUG_README: Debugging strategies
|
||||
|
||||
CCoonntteenntt iinnssppeeccttiioonn
|
||||
|
||||
* CONTENT_INSPECTION_README: Content inspection overview
|
||||
* BACKSCATTER_README: Stopping backscatter mail
|
||||
* BUILTIN_FILTER_README: Built-in content inspection
|
||||
|
||||
* FILTER_README: After-queue content filter
|
||||
* SMTPD_PROXY_README: Before-queue content filter
|
||||
* MILTER_README: Before-queue Milter applications
|
||||
|
||||
SSMMTTPP RReellaayy aanndd aacccceessss ccoonnttrrooll
|
||||
|
||||
* SMTPD_ACCESS_README: Relay/access control overview
|
||||
* SMTPD_POLICY_README: Access policy delegation
|
||||
* ADDRESS_VERIFICATION_README: Address verification
|
||||
* RESTRICTION_CLASS_README: Per-client/user/etc. access
|
||||
* POSTSCREEN_README: SMTP connection triage
|
||||
* ETRN_README: ETRN Support
|
||||
* UUCP_README: LAN connected via UUCP
|
||||
|
||||
LLooookkuupp ttaabblleess ((ddaattaabbaasseess))
|
||||
|
||||
* DATABASE_README: Lookup table overview
|
||||
* DB_README: Berkeley DB Howto
|
||||
* CDB_README: CDB Howto
|
||||
* LDAP_README: LDAP Howto
|
||||
* LMDB_README: LMDB Howto
|
||||
* MEMCACHE_README: Memcache Howto
|
||||
* MONGODB_README: MongoDB Howto
|
||||
* MYSQL_README: MySQL Howto
|
||||
* PCRE_README: PCRE Howto
|
||||
* PGSQL_README: PostgreSQL Howto
|
||||
* SQLITE_README: SQLite Howto
|
||||
|
||||
MMaaiilliinngg lliisstt ssuuppppoorrtt
|
||||
|
||||
* VERP_README: VERP Support
|
||||
|
||||
SSppeecciiffiicc eennvviirroonnmmeennttss
|
||||
|
||||
* LINUX_README: Linux issues
|
||||
* NFS_README: NFS issues
|
||||
|
||||
OOtthheerr mmaaiill ddeelliivveerryy aaggeennttss
|
||||
|
||||
* MAILDROP_README: Maildrop
|
||||
|
||||
OOtthheerr ttooppiiccss
|
||||
|
||||
* OVERVIEW: Architecture overview
|
||||
* postconf(5): All main.cf parameters
|
||||
* LOCAL_RECIPIENT_README: Rejecting Unknown Local Recipients
|
||||
* ADDRESS_CLASS_README: Address Classes
|
||||
* CONNECTION_CACHE_README: Connection cache howto
|
||||
* DSN_README: Postfix DSN support
|
||||
* BDAT_README: Postfix BDAT (CHUNKING) support
|
||||
* PACKAGE_README: Guidelines for Package Builders
|
||||
* SCHEDULER_README: Queue Scheduler
|
||||
* XCLIENT_README: XCLIENT Command
|
||||
* XFORWARD_README: XFORWARD Command
|
||||
|
||||
210
README_FILES/ADDRESS_CLASS_README
Normal file
210
README_FILES/ADDRESS_CLASS_README
Normal file
|
|
@ -0,0 +1,210 @@
|
|||
PPoossttffiixx AAddddrreessss CCllaasssseess
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix version 2.0 introduces the concept of address classes. This is a way of
|
||||
grouping recipient addresses by their delivery method. The idea comes from
|
||||
discussions with Victor Duchovni. Although address classes introduced a few
|
||||
incompatibilities they also made it possible to improve the handling of hosted
|
||||
domains and of unknown recipients.
|
||||
|
||||
This document provides information on the following topics:
|
||||
|
||||
* What are address classes good for?
|
||||
* What address classes does Postfix implement?
|
||||
* Improvements compared to Postfix 1.1
|
||||
* Incompatibilities with Postfix 1.1
|
||||
|
||||
WWhhaatt aarree aaddddrreessss ccllaasssseess ggoooodd ffoorr??
|
||||
|
||||
Why should you care about address classes? This is how Postfix decides what
|
||||
mail to accept, and how to deliver it. In other words, address classes are very
|
||||
important for the operation of Postfix.
|
||||
|
||||
An address class is defined by three items.
|
||||
|
||||
* The list of domains that are a member of that address class.
|
||||
|
||||
Examples: all local domains, or all relay domains.
|
||||
|
||||
* The default delivery transport for domains in that address class.
|
||||
|
||||
Examples: local_transport or relay_transport (these point to services
|
||||
defined in master.cf).
|
||||
|
||||
Benefit: this avoids the need for explicit routing information in transport
|
||||
maps.
|
||||
|
||||
* The list of valid recipient addresses for that address class.
|
||||
|
||||
Benefit: the Postfix SMTP server rejects an invalid recipient with "User
|
||||
unknown in <name of address class> table", and avoids sending a MAILER-
|
||||
DAEMON message with backscatter spam.
|
||||
|
||||
WWhhaatt aaddddrreessss ccllaasssseess ddooeess PPoossttffiixx iimmpplleemmeenntt??
|
||||
|
||||
Initially the list of address classes is hard coded, but this is meant to
|
||||
become extensible. The summary below describes the main purpose of each class,
|
||||
and what the relevant configuration parameters are.
|
||||
|
||||
The local domain class.
|
||||
|
||||
* Purpose: final delivery for traditional UNIX system accounts and
|
||||
traditional Sendmail-style aliases. This is typically used for the
|
||||
canonical domains of the machine (for example, $myhostname, $mydomain). For
|
||||
a discussion of the difference between canonical domains, hosted domains
|
||||
and other domains, see the VIRTUAL_README file.
|
||||
|
||||
* Domain names are listed with the mydestination parameter. This domain class
|
||||
also includes mail for user@[ipaddress] when the IP address is listed with
|
||||
the inet_interfaces or proxy_interfaces parameters.
|
||||
|
||||
* Valid recipient addresses for those domains are listed with the
|
||||
local_recipient_maps parameter, as described in LOCAL_RECIPIENT_README. The
|
||||
Postfix SMTP server rejects invalid recipients with "User unknown in local
|
||||
recipient table". If the local_recipient_maps parameter value is empty,
|
||||
then the Postfix SMTP server accepts any address in the local domain class.
|
||||
|
||||
* The mail delivery transport is specified with the local_transport
|
||||
parameter. The default value is llooccaall::$$mmyyhhoossttnnaammee for delivery with the
|
||||
local(8) delivery agent.
|
||||
|
||||
The virtual alias domain class.
|
||||
|
||||
* Purpose: hosted domains where each recipient address is aliased to an
|
||||
address in a different domain class, for example, a local UNIX system
|
||||
account or a remote address. A virtual alias example is given in the
|
||||
VIRTUAL_README file.
|
||||
|
||||
* Domain names are listed in virtual_alias_domains. The default value is
|
||||
$virtual_alias_maps for Postfix 1.1 compatibility.
|
||||
|
||||
* Valid recipient addresses for those domains are listed with the
|
||||
virtual_alias_maps parameter. The Postfix SMTP server rejects invalid
|
||||
recipients with "User unknown in virtual alias table". The default value is
|
||||
$virtual_maps for Postfix 1.1 compatibility.
|
||||
|
||||
Note: for historical reasons, virtual_alias_maps apply to recipients in
|
||||
all domain classes, not only the virtual alias domain class.
|
||||
|
||||
* There is no configurable mail delivery transport. Every address must be
|
||||
aliased to an address in some other domain class.
|
||||
|
||||
The virtual mailbox domain class.
|
||||
|
||||
* Purpose: final delivery for hosted domains where each recipient address can
|
||||
have its own mailbox, and where users do not need to have a UNIX system
|
||||
account. A virtual mailbox example is given in the VIRTUAL_README file.
|
||||
|
||||
* Domain names are listed with the virtual_mailbox_domains parameter. The
|
||||
default value is $virtual_mailbox_maps for Postfix 1.1 compatibility.
|
||||
|
||||
* Valid recipient addresses for those domains are listed with the
|
||||
virtual_mailbox_maps parameter. The Postfix SMTP server rejects invalid
|
||||
recipients with "User unknown in virtual mailbox table". If this parameter
|
||||
value is empty, the Postfix SMTP server accepts all recipients for domains
|
||||
listed in $virtual_mailbox_domains.
|
||||
|
||||
* The mail delivery transport is specified with the virtual_transport
|
||||
parameter. The default value is vviirrttuuaall for delivery with the virtual(8)
|
||||
delivery agent.
|
||||
|
||||
The relay domain class.
|
||||
|
||||
* Purpose: mail forwarding to remote destinations that list your system as
|
||||
primary or backup MX host. For a discussion of the basic configuration
|
||||
details, see the BASIC_CONFIGURATION_README document. For a discussion of
|
||||
the difference between canonical domains, hosted domains and other domains,
|
||||
see the VIRTUAL_README file.
|
||||
|
||||
* Domain names are listed with the relay_domains parameter.
|
||||
|
||||
* Valid recipient addresses for those domains are listed with the
|
||||
relay_recipient_maps parameter. The Postfix SMTP server rejects invalid
|
||||
recipients with "User unknown in relay recipient table". If this parameter
|
||||
value is empty, the Postfix SMTP server accepts all recipients for domains
|
||||
listed with the relay_domains parameter.
|
||||
|
||||
* The mail delivery transport is specified with the relay_transport
|
||||
parameter. The default value is rreellaayy which is a clone of the smtp(8)
|
||||
delivery agent.
|
||||
|
||||
The default domain class.
|
||||
|
||||
* Purpose: mail forwarding to the Internet on behalf of authorized clients.
|
||||
For a discussion of the basic configuration details, see the
|
||||
BASIC_CONFIGURATION_README file. For a discussion of the difference between
|
||||
canonical domains, hosted domains and other domains, see the VIRTUAL_README
|
||||
file.
|
||||
|
||||
* This class has no destination domain table.
|
||||
|
||||
* This class has no valid recipient address table.
|
||||
|
||||
* The mail delivery transport is specified with the default_transport
|
||||
parameter. The default value is ssmmttpp for delivery with the smtp(8) delivery
|
||||
agent.
|
||||
|
||||
IImmpprroovveemmeennttss ccoommppaarreedd ttoo PPoossttffiixx 11..11
|
||||
|
||||
Postfix 2.0 address classes made the following improvements possible over
|
||||
earlier Postfix versions:
|
||||
|
||||
* You no longer need to specify all the virtual(8) mailbox domains in the
|
||||
Postfix transport map. The virtual(8) delivery agent has become a first-
|
||||
class citizen just like local(8) or smtp(8).
|
||||
|
||||
* On mail gateway systems, address classes provide separation of inbound mail
|
||||
relay traffic ($relay_transport) from outbound traffic
|
||||
($default_transport). This eliminates a problem where inbound mail
|
||||
deliveries could become resource starved in the presence of a high volume
|
||||
of outbound mail.
|
||||
|
||||
* The SMTP server rejects unknown recipients in a more consistent manner than
|
||||
was possible with Postfix version 1. This is needed to keep undeliverable
|
||||
mail (and bounced undeliverable mail) out of the mail queue. This is
|
||||
controlled by the smtpd_reject_unlisted_recipient configuration parameter.
|
||||
|
||||
* As of Postfix version 2.1, the SMTP server can also reject unknown sender
|
||||
addresses (i.e. addresses that it would reject as an unknown recipient
|
||||
addresses). Sender "egress filtering" can help to slow down an email worm
|
||||
explosion. This is controlled by the smtpd_reject_unlisted_sender
|
||||
configuration parameter.
|
||||
|
||||
IInnccoommppaattiibbiilliittiieess wwiitthh PPoossttffiixx 11..11
|
||||
|
||||
Postfix 2.0 address classes introduce a few incompatible changes in documented
|
||||
behavior. In order to ease the transitions, new parameters have default values
|
||||
that are backwards compatible.
|
||||
|
||||
* The virtual_maps parameter is replaced by virtual_alias_maps (for address
|
||||
lookups) and by virtual_alias_domains (for the names of what were formerly
|
||||
called "Postfix-style virtual domains").
|
||||
|
||||
For backwards compatibility with Postfix version 1.1, the new
|
||||
virtual_alias_maps parameter defaults to $virtual_maps, and the new
|
||||
virtual_alias_domains parameter defaults to $virtual_alias_maps.
|
||||
|
||||
* The virtual_mailbox_maps parameter now has a companion parameter called
|
||||
virtual_mailbox_domains (for the names of domains served by the virtual
|
||||
delivery agent). The virtual_mailbox_maps parameter is now used for address
|
||||
lookups only.
|
||||
|
||||
For backwards compatibility with Postfix version 1.1, the new
|
||||
virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
|
||||
|
||||
* Introduction of the relay_recipient_maps parameter. The Postfix SMTP server
|
||||
can use this to block mail for relay recipients that don't exist. This list
|
||||
is empty by default, which means accept any recipient.
|
||||
|
||||
* The local_recipient_maps feature is now turned on by default. The Postfix
|
||||
SMTP server uses this to reject mail for unknown local recipients. See the
|
||||
LOCAL_RECIPIENT_README file hints and tips.
|
||||
|
||||
* Introduction of the relay delivery transport in master.cf. This helps to
|
||||
avoid mail delivery scheduling problems on inbound mail relays when there
|
||||
is a lot of outbound mail, but may require that you update your
|
||||
"defer_transports" setting.
|
||||
|
||||
877
README_FILES/ADDRESS_REWRITING_README
Normal file
877
README_FILES/ADDRESS_REWRITING_README
Normal file
|
|
@ -0,0 +1,877 @@
|
|||
PPoossttffiixx AAddddrreessss RReewwrriittiinngg
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPoossttffiixx aaddddrreessss rreewwrriittiinngg ppuurrppoossee
|
||||
|
||||
Address rewriting is at the heart of the Postfix mail system. Postfix rewrites
|
||||
addresses for many different purposes. Some are merely cosmetic, and some are
|
||||
necessary to deliver correctly formatted mail to the correct destination.
|
||||
Examples of address rewriting in Postfix are:
|
||||
|
||||
* Transform an incomplete address into a complete address. For example,
|
||||
transform "username" into "username@example.com", or transform
|
||||
"username@hostname" into "username@hostname.example.com".
|
||||
|
||||
* Replace an address by an equivalent address. For example, replace
|
||||
"username@example.com" by "firstname.lastname@example.com" when sending
|
||||
mail, and do the reverse transformation when receiving mail.
|
||||
|
||||
* Replace an internal address by an external address. For example, replace
|
||||
"username@localdomain.local" by "isp-account@isp.example" when sending mail
|
||||
from a home computer to the Internet.
|
||||
|
||||
* Replace an address by multiple addresses. For example, replace the address
|
||||
of an alias by the addresses listed under that alias.
|
||||
|
||||
* Determine how and where to deliver mail for a specific address. For
|
||||
example, deliver mail for "username@example.com" with the smtp(8) delivery
|
||||
agent, to the hosts that are listed in the DNS as the mail servers for the
|
||||
domain "example.com".
|
||||
|
||||
Although Postfix currently has no address rewriting language, it can do
|
||||
surprisingly powerful address manipulation via table lookup. Postfix typically
|
||||
uses lookup tables with fixed strings to map one address to one or multiple
|
||||
addresses, and typically uses regular expressions to map multiple addresses to
|
||||
one or multiple addresses. Fixed-string lookup tables may be in the form of
|
||||
local files, or in the form of NIS, LDAP or SQL databases. The DATABASE_README
|
||||
document gives an introduction to Postfix lookup tables.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* To rewrite message headers or not, or to label as invalid
|
||||
* Postfix address rewriting overview
|
||||
* Address rewriting when mail is received
|
||||
|
||||
o Rewrite addresses to standard form
|
||||
o Canonical address mapping
|
||||
o Address masquerading
|
||||
o Automatic BCC recipients
|
||||
o Virtual aliasing
|
||||
|
||||
* Address rewriting when mail is delivered
|
||||
|
||||
o Resolve address to (transport, next-hop destination)
|
||||
o Relocated users table
|
||||
|
||||
* Address rewriting with remote delivery
|
||||
|
||||
o Generic mapping for outgoing SMTP mail
|
||||
|
||||
* Address rewriting with local delivery
|
||||
|
||||
o Local alias database
|
||||
o Local per-user .forward files
|
||||
o Local catch-all address
|
||||
|
||||
* Debugging your address manipulations
|
||||
|
||||
TToo rreewwrriittee mmeessssaaggee hheeaaddeerrss oorr nnoott,, oorr ttoo llaabbeell aass iinnvvaalliidd
|
||||
|
||||
Postfix versions 2.1 and earlier always rewrite message header addresses, and
|
||||
append Postfix's own domain information to addresses that Postfix considers
|
||||
incomplete. While rewriting message header addresses is OK for mail with a
|
||||
local origin, it is undesirable for remote mail:
|
||||
|
||||
* Message header address rewriting is frowned upon by mail standards,
|
||||
* Appending Postfix's own domain produces incorrect results with some
|
||||
incomplete addresses,
|
||||
* Appending Postfix's own domain sometimes creates the appearance that spam
|
||||
is sent by local users.
|
||||
|
||||
Postfix versions 2.2 give you the option to either not rewrite message headers
|
||||
from remote SMTP clients at all, or to label incomplete addresses in such
|
||||
message headers as invalid. Here is how it works:
|
||||
|
||||
* Postfix always rewrites message headers from local SMTP clients and from
|
||||
the Postfix sendmail command, and appends its own domain to incomplete
|
||||
addresses. The local_header_rewrite_clients parameter controls what SMTP
|
||||
clients Postfix considers local (by default, only local network interface
|
||||
addresses).
|
||||
* Postfix never rewrites message header addresses from remote SMTP clients
|
||||
when the remote_header_rewrite_domain parameter value is empty (the default
|
||||
setting).
|
||||
* Otherwise, Postfix rewrites message headers from remote SMTP clients, and
|
||||
appends the remote_header_rewrite_domain value to incomplete addresses.
|
||||
This feature can be used to append a reserved domain such as
|
||||
"domain.invalid", so that incomplete addresses cannot be mistaken for local
|
||||
addresses.
|
||||
|
||||
PPoossttffiixx aaddddrreessss rreewwrriittiinngg oovveerrvviieeww
|
||||
|
||||
The figure below zooms in on those parts of Postfix that are most involved with
|
||||
address rewriting activity. See the OVERVIEW document for an overview of the
|
||||
complete Postfix architecture. Names followed by a number are Postfix daemon
|
||||
programs, while unnumbered names represent Postfix queues or internal sources
|
||||
of mail messages.
|
||||
|
||||
trivial- trivial-
|
||||
rewrite(8) rewrite(8)
|
||||
(std form) (resolve)
|
||||
|
||||
^ | ^ |
|
||||
| v | v
|
||||
|
||||
smtpd(8) smtp(8)
|
||||
|
||||
qmqpd(8) >- cleanup(8) -> incoming -> active -> qmgr(8) -< lmtp(8)
|
||||
|
||||
pickup(8) local(8)
|
||||
|
||||
^ ^ |
|
||||
| | v
|
||||
|
||||
bounces
|
||||
forwarding deferred
|
||||
notices
|
||||
|
||||
The table below summarizes all Postfix address manipulations. If you're reading
|
||||
this document for the first time, skip forward to "Address rewriting when mail
|
||||
is received". Once you've finished reading the remainder of this document, the
|
||||
table will help you to quickly find what you need.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|AAddddrreessss |SSccooppee |DDaaeemmoonn |TTuurrnn--oonn ccoonnttrroollss |TTuurrnn--ooffff ccoonnttrroollss |
|
||||
|mmaanniippuullaattiioonn| | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Rewrite | |trivial-|append_at_myorigin, | |
|
||||
|addresses to|all mail|rewrite |append_dot_mydomain, swap_bangpath, |local_header_rewrite_clients,|
|
||||
|standard | |(8) |allow_percent_hack |remote_header_rewrite_domain |
|
||||
|form | | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Canonical | |cleanup | |receive_override_options, |
|
||||
|address |all mail|(8) |canonical_maps |local_header_rewrite_clients,|
|
||||
|mapping | | | |remote_header_rewrite_domain |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Address | |cleanup | |receive_override_options, |
|
||||
|masquerading|all mail|(8) |masquerade_domains |local_header_rewrite_clients,|
|
||||
| | | | |remote_header_rewrite_domain |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Automatic | |cleanup |always_bcc, sender_bcc_maps, | |
|
||||
|BCC |new mail|(8) |recipient_bcc_maps |receive_override_options |
|
||||
|recipients | | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Virtual |all mail|cleanup |virtual_alias_maps |receive_override_options |
|
||||
|aliasing | |(8) | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Resolve | | |local_transport, virtual_transport, | |
|
||||
|address to | |trivial-|relay_transport, default_transport, | |
|
||||
|(transport, |all mail|rewrite |relayhost, |content_filter |
|
||||
|next-hop | |(8) |sender_dependent_relayhost_maps, | |
|
||||
|destination)| | |sender_dependent_default_transport_maps| |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Relocated | |trivial-| | |
|
||||
|users table |all mail|rewrite |relocated_maps |none |
|
||||
| | |(8) | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Generic |outgoing| | | |
|
||||
|mapping |SMTP |smtp(8) |smtp_generic_maps |none |
|
||||
|table |mail | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local alias |local | | | |
|
||||
|database |mail |local(8)|alias_maps |none |
|
||||
| |only | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local per- |local | | | |
|
||||
|user |mail |local(8)|forward_path |none |
|
||||
|.forward |only | | | |
|
||||
|files | | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local catch-|local | | | |
|
||||
|all address |mail |local(8)|luser_relay |none |
|
||||
| |only | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss rreecceeiivveedd
|
||||
|
||||
The cleanup(8) server receives mail from outside of Postfix as well as mail
|
||||
from internal sources such as forwarded mail, undeliverable mail that is
|
||||
bounced to the sender, and postmaster notifications about problems with the
|
||||
mail system.
|
||||
|
||||
The cleanup(8) server transforms the sender, recipients and message content
|
||||
into a standard form before writing it to an incoming queue file. The server
|
||||
cleans up sender and recipient addresses in message headers and in the
|
||||
envelope, adds missing message headers such as From: or Date: that are required
|
||||
by mail standards, and removes message headers such as Bcc: that should not be
|
||||
present. The cleanup(8) server delegates the more complex address manipulations
|
||||
to the trivial-rewrite(8) server as described later in this document.
|
||||
|
||||
Address manipulations at this stage are:
|
||||
|
||||
* Rewrite addresses to standard form
|
||||
* Canonical address mapping
|
||||
* Address masquerading
|
||||
* Automatic BCC recipients
|
||||
* Virtual aliasing
|
||||
|
||||
RReewwrriittee aaddddrreesssseess ttoo ssttaannddaarrdd ffoorrmm
|
||||
|
||||
Before the cleanup(8) daemon runs an address through any address mapping lookup
|
||||
table, it first rewrites the address to the standard
|
||||
"user@fully.qualified.domain" form, by sending the address to the trivial-
|
||||
rewrite(8) daemon. The purpose of rewriting to standard form is to reduce the
|
||||
number of entries needed in lookup tables.
|
||||
|
||||
The Postfix trivial-rewrite(8) daemon implements the following hard-coded
|
||||
address manipulations:
|
||||
|
||||
Rewrite "@hosta,@hostb:user@site" to "user@site"
|
||||
In case you wonder what this is, the address form above is called a
|
||||
route address, and specifies that mail for "user@site" be delivered via
|
||||
"hosta" and "hostb". Usage of this form has been deprecated for a long
|
||||
time. Postfix has no ability to handle route addresses, other than to
|
||||
strip off the route part.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter, or if the
|
||||
remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
Rewrite "site!user" to "user@site"
|
||||
This feature is controlled by the boolean swap_bangpath parameter
|
||||
(default: yes). The purpose is to rewrite UUCP-style addresses to
|
||||
domain style. This is useful only when you receive mail via UUCP, but
|
||||
it probably does not hurt otherwise.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter, or if the
|
||||
remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
Rewrite "user%domain" to "user@domain"
|
||||
This feature is controlled by the boolean allow_percent_hack parameter
|
||||
(default: yes). Typically, this is used in order to deal with
|
||||
monstrosities such as "user%domain@otherdomain".
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter, or if the
|
||||
remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
Rewrite "user" to "user@$myorigin"
|
||||
This feature is controlled by the boolean append_at_myorigin parameter
|
||||
(default: yes). You should never turn off this feature, because a lot
|
||||
of Postfix components expect that all addresses have the form
|
||||
"user@domain".
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter; otherwise they append the
|
||||
domain name specified with the remote_header_rewrite_domain
|
||||
configuration parameter, if one is specified. To get the behavior
|
||||
before Postfix 2.2, specify "local_header_rewrite_clients = static:
|
||||
all".
|
||||
|
||||
If your machine is not the main machine for $myorigin and you wish to
|
||||
have some users delivered locally without going via that main machine,
|
||||
make an entry in the virtual alias table that redirects
|
||||
"user@$myorigin" to "user@$myhostname". See also the "delivering some
|
||||
users locally" section in the STANDARD_CONFIGURATION_README document.
|
||||
|
||||
Rewrite "user@host" to "user@host.$mydomain"
|
||||
This feature is controlled by the boolean append_dot_mydomain parameter
|
||||
(default: Postfix ≥ 3.0: no, Postfix < 3.0: yes). The purpose is to
|
||||
get consistent treatment of different forms of the same hostname.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter; otherwise they append the
|
||||
domain name specified with the remote_header_rewrite_domain
|
||||
configuration parameter, if one is specified. To get the behavior
|
||||
before Postfix 2.2, specify "local_header_rewrite_clients = static:
|
||||
all".
|
||||
|
||||
Some will argue that rewriting "host" to "host.domain" is bad. That is
|
||||
why it can be turned off. Others like the convenience of having
|
||||
Postfix's own domain appended automatically.
|
||||
|
||||
Rewrite "user@site." to "user@site" (without the trailing dot).
|
||||
A single trailing dot is silently removed. However, an address that
|
||||
ends in multiple dots will be rejected as an invalid address.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from
|
||||
remote SMTP clients only if the client matches the
|
||||
local_header_rewrite_clients parameter, or if the
|
||||
remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
CCaannoonniiccaall aaddddrreessss mmaappppiinngg
|
||||
|
||||
The cleanup(8) daemon uses the canonical(5) tables to rewrite addresses in
|
||||
message envelopes and in message headers. By default all header and envelope
|
||||
addresses are rewritten; this is controlled with the canonical_classes
|
||||
configuration parameter.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
|
||||
clients only if the client matches the local_header_rewrite_clients parameter,
|
||||
or if the remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
Address rewriting is done for local and remote addresses. The mapping is useful
|
||||
to replace login names by "Firstname.Lastname" style addresses, or to clean up
|
||||
invalid domains in mail addresses produced by legacy mail systems.
|
||||
|
||||
Canonical mapping is disabled by default. To enable, edit the canonical_maps
|
||||
parameter in the main.cf file and specify one or more lookup tables, separated
|
||||
by whitespace or commas.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
canonical_maps = hash:/etc/postfix/canonical
|
||||
|
||||
/etc/postfix/canonical:
|
||||
wietse Wietse.Venema
|
||||
|
||||
For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
|
||||
or pgsql: are sufficient. For dynamic mappings you can use regular expression
|
||||
tables. This requires that you become intimately familiar with the ideas
|
||||
expressed in regexp_table(5), pcre_table(5) and canonical(5).
|
||||
|
||||
In addition to the canonical maps which are applied to both sender and
|
||||
recipient addresses, you can specify canonical maps that are applied only to
|
||||
sender addresses or to recipient addresses.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
sender_canonical_maps = hash:/etc/postfix/sender_canonical
|
||||
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
|
||||
|
||||
The sender and recipient canonical maps are applied before the common canonical
|
||||
maps. The sender_canonical_classes and recipient_canonical_classes parameters
|
||||
control what addresses are subject to sender_canonical_maps and
|
||||
recipient_canonical_maps mappings, respectively.
|
||||
|
||||
Sender-specific rewriting is useful when you want to rewrite ugly sender
|
||||
addresses to pretty ones, and still want to be able to send mail to the those
|
||||
ugly address without creating a mailer loop.
|
||||
|
||||
Canonical mapping can be turned off selectively for mail received by smtpd(8),
|
||||
qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
|
||||
This feature is available in Postfix version 2.1 and later.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
Note: do not specify whitespace around the "=" here.
|
||||
|
||||
AAddddrreessss mmaassqquueerraaddiinngg
|
||||
|
||||
Address masquerading is a method to hide hosts inside a domain behind their
|
||||
mail gateway, and to make it appear as if the mail comes from the gateway
|
||||
itself, instead of from individual machines.
|
||||
|
||||
NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
|
||||
clients only if the client matches the local_header_rewrite_clients parameter,
|
||||
or if the remote_header_rewrite_domain configuration parameter specifies a non-
|
||||
empty value. To get the behavior before Postfix 2.2, specify
|
||||
"local_header_rewrite_clients = static:all".
|
||||
|
||||
Address masquerading is disabled by default, and is implemented by the cleanup
|
||||
(8) server. To enable, edit the masquerade_domains parameter in the main.cf
|
||||
file and specify one or more domain names separated by whitespace or commas.
|
||||
When Postfix tries to masquerade a domain, it processes the list from left to
|
||||
right, and processing stops at the first match.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
masquerade_domains = foo.example.com example.com
|
||||
|
||||
strips "any.thing.foo.example.com" to "foo.example.com", but strips
|
||||
"any.thing.else.example.com" to "example.com".
|
||||
|
||||
A domain name prefixed with "!" means do not masquerade this domain or its
|
||||
subdomains:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
masquerade_domains = !foo.example.com example.com
|
||||
|
||||
does not change "any.thing.foo.example.com" and "foo.example.com", but strips
|
||||
"any.thing.else.example.com" to "example.com".
|
||||
|
||||
The masquerade_exceptions configuration parameter specifies what user names
|
||||
should not be subjected to address masquerading. Specify one or more user names
|
||||
separated by whitespace or commas.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
masquerade_exceptions = root
|
||||
|
||||
By default, Postfix makes no exceptions.
|
||||
|
||||
Subtle point: by default, address masquerading is applied only to message
|
||||
headers and to envelope sender addresses, but not to envelope recipients. This
|
||||
allows you to use address masquerading on a mail gateway machine, while still
|
||||
being able to forward mail from outside to users on individual machines.
|
||||
|
||||
In order to subject envelope recipient addresses to masquerading, too, specify
|
||||
(Postfix version 1.1 and later):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
masquerade_classes = envelope_sender, envelope_recipient,
|
||||
header_sender, header_recipient
|
||||
|
||||
If you rewrite the envelope recipient like this, Postfix will no longer be able
|
||||
to send mail to individual machines.
|
||||
|
||||
Address masquerading can be turned off selectively for mail received by smtpd
|
||||
(8), qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf
|
||||
file. This feature is available in Postfix version 2.1 and later.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
Note: do not specify whitespace around the "=" here.
|
||||
|
||||
AAuuttoommaattiicc BBCCCC rreecciippiieennttss
|
||||
|
||||
After applying the canonical and masquerade mappings, the cleanup(8) daemon can
|
||||
generate optional BCC (blind carbon-copy) recipients. Postfix provides three
|
||||
mechanisms:
|
||||
|
||||
always_bcc = address
|
||||
Deliver a copy of all mail to the specified address. In Postfix
|
||||
versions before 2.1, this feature is implemented by smtpd(8), qmqpd(8),
|
||||
or pickup(8).
|
||||
sender_bcc_maps = type:table
|
||||
Search the specified "type:table" lookup table with the envelope sender
|
||||
address for an automatic BCC address. This feature is available in
|
||||
Postfix 2.1 and later.
|
||||
recipient_bcc_maps = type:table
|
||||
Search the specified "type:table" lookup table with the envelope
|
||||
recipient address for an automatic BCC address. This feature is
|
||||
available in Postfix 2.1 and later.
|
||||
|
||||
Note: automatic BCC recipients are produced only for new mail. To avoid mailer
|
||||
loops, automatic BCC recipients are not generated for mail that Postfix
|
||||
forwards internally, nor for mail that Postfix generates itself.
|
||||
|
||||
Automatic BCC recipients (including always_bcc) can be turned off selectively
|
||||
for mail received by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf
|
||||
settings in the master.cf file. This feature is available in Postfix version
|
||||
2.1 and later.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
Note: do not specify whitespace around the "=" here.
|
||||
|
||||
VViirrttuuaall aalliiaassiinngg
|
||||
|
||||
Before writing the recipients to the queue file, the cleanup(8) daemon uses the
|
||||
optional virtual(5) alias tables to redirect mail for recipients. The mapping
|
||||
affects only envelope recipient addresses; it has no effect on message headers
|
||||
or envelope sender addresses. Virtual alias lookups are useful to redirect mail
|
||||
for virtual alias domains to real user mailboxes, and to redirect mail for
|
||||
domains that no longer exist. Virtual alias lookups can also be used to
|
||||
transform " Firstname.Lastname " back into UNIX login names, although it seems
|
||||
that local aliases may be a more appropriate vehicle. See the VIRTUAL_README
|
||||
document for an overview of methods to host virtual domains with Postfix.
|
||||
|
||||
Note: virtual aliasing (virtual_alias_maps) applies to all recipients: local
|
||||
(8), virtual, and remote. This is unlike local aliasing (alias_maps) which
|
||||
applies only to local(8) recipients.
|
||||
|
||||
Virtual aliasing is disabled by default. To enable, edit the virtual_alias_maps
|
||||
parameter in the main.cf file and specify one or more lookup tables, separated
|
||||
by whitespace or commas.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
|
||||
/etc/postfix/virtual:
|
||||
Wietse.Venema wietse
|
||||
|
||||
Addresses found in virtual alias maps are subjected to another iteration of
|
||||
virtual aliasing, but are not subjected to canonical mapping, in order to avoid
|
||||
loops.
|
||||
|
||||
For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
|
||||
or pgsql: are sufficient. For dynamic mappings you can use regular expression
|
||||
tables. This requires that you become intimately familiar with the ideas
|
||||
expressed in regexp_table(5), pcre_table(5) and virtual(5).
|
||||
|
||||
Virtual aliasing can be turned off selectively for mail received by smtpd(8),
|
||||
qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
|
||||
This feature is available in Postfix version 2.1 and later.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
Note: do not specify whitespace around the "=" here.
|
||||
|
||||
At this point the message is ready to be stored into the Postfix incoming
|
||||
queue.
|
||||
|
||||
AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss ddeelliivveerreedd
|
||||
|
||||
The Postfix queue manager sorts mail according to its destination and gives it
|
||||
to Postfix delivery agents such as local(8), smtp(8), or lmtp(8). Just like the
|
||||
cleanup(8) server, the Postfix queue manager delegates the more complex address
|
||||
manipulations to the trivial-rewrite(8) server.
|
||||
|
||||
Address manipulations at this stage are:
|
||||
|
||||
* Resolve address to (transport, next-hop destination)
|
||||
* Relocated users table
|
||||
|
||||
Each Postfix delivery agent tries to deliver the mail to its destination, while
|
||||
encapsulating the sender, recipients, and message content according to the
|
||||
rules of the SMTP, LMTP, etc. protocol. When mail cannot be delivered, it is
|
||||
either returned to the sender or moved to the deferred queue and tried again
|
||||
later.
|
||||
|
||||
Address manipulations when mail is delivered via the smtp(8) delivery agent:
|
||||
|
||||
* Generic mapping for outgoing SMTP mail
|
||||
|
||||
Address manipulations when mail is delivered via the local(8) delivery agent:
|
||||
|
||||
* Local alias database
|
||||
* Local per-user .forward files
|
||||
* Local catch-all address
|
||||
|
||||
The remainder of this document presents each address manipulation step in more
|
||||
detail, with specific examples or with pointers to documentation with examples.
|
||||
|
||||
RReessoollvvee aaddddrreessss ttoo ((ttrraannssppoorrtt,, nneexxtt--hhoopp ddeessttiinnaattiioonn))
|
||||
|
||||
The Postfix qmgr(8) queue manager selects new mail from the incoming queue or
|
||||
old mail from the deferred queue. First it looks for overrides:
|
||||
|
||||
* The REDIRECT action in access(5), header_checks(5) or body_checks(5)
|
||||
overrides all recipients of the message, and overrides a content_filter
|
||||
setting, and FILTER action in access(5), header_checks(5) or body_checks
|
||||
(5). The REDIRECT action was implemented as a short-cut to retaliate for
|
||||
abuse.
|
||||
|
||||
* A content_filter setting and FILTER action in access(5), header_checks(5)
|
||||
or body_checks(5) provide their own (transport, next-hop destination)
|
||||
information. This bypasses all the steps that are described in the
|
||||
remainder of this section.
|
||||
|
||||
When there is no content filter override, the qmgr(8) queue manager asks the
|
||||
trivial-rewrite(8) address rewriting and resolving daemon for each recipient
|
||||
how to deliver it (which message delivery transport) and where to deliver it
|
||||
(what next-hop destination).
|
||||
|
||||
As of version 2.0, Postfix distinguishes four major domain classes. Each class
|
||||
has its own list of recipient domain names, and each class has its own delivery
|
||||
method, as shown in the table below. See the ADDRESS_CLASS_README document for
|
||||
the fine details. Postfix versions before 2.0 only distinguish between local
|
||||
delivery and everything else.
|
||||
|
||||
Note that the table does not match recipients against virtual_alias_domains.
|
||||
The reason is that all valid recipients in a virtual alias domain must be
|
||||
aliased to an address in a different domain. All other recipients in a virtual
|
||||
alias domain are by definition undeliverable, and do not need to be considered
|
||||
here.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|DDoommaaiinn ccllaassss |RReecciippiieenntt ddoommaaiinn mmaattcchh |DDeelliivveerryy mmeetthhoodd |AAvvaaiillaabbiilliittyy|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| |mydestination, | | |
|
||||
|Local |inet_interfaces, |local_transport |Postfix 1.0 |
|
||||
| |proxy_interfaces | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Virtual mailbox|virtual_mailbox_domains|virtual_transport|Postfix 2.0 |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Relay |relay_domains |relay_transport |Postfix 2.0 |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Default |none |default_transport|Postfix 1.0 |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
The delivery methods in the above table may include a next-hop destination in
|
||||
addition to a delivery transport. This may override the next-hop destination
|
||||
that is by default taken from the recipient domain.
|
||||
|
||||
Over time, features have been added to override the above transport and/or
|
||||
next-hop destination information. The following table lists where a transport
|
||||
or next-hop destination may be taken from, depending on the recipient domain
|
||||
class.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|DDoommaaiinn |TTrraannssppoorrtt ssoouurrcceess ((iinn oorrddeerr ooff |NNeexxtt hhoopp ssoouurrcceess ((iinn oorrddeerr ooff ddeesscceennddiinngg|
|
||||
|ccllaassss |ddeesscceennddiinngg pprreecceeddeennccee)) |pprreecceeddeennccee)) |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local |transport_maps, local_transport |transport_maps, local_transport, |
|
||||
| | |recipient domain |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Virtual|transport_maps, virtual_transport |transport_maps, virtual_transport, |
|
||||
|mailbox| |recipient domain |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |transport_maps, relay_transport, |
|
||||
|Relay |transport_maps, relay_transport |sender_dependent_relayhost_maps, |
|
||||
| | |relayhost, recipient domain |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |transport_maps, |
|
||||
| |transport_maps, |sender_dependent_default_transport_maps,|
|
||||
|Default|sender_dependent_default_transport_maps,|default_transport, |
|
||||
| |default_transport |sender_dependent_relayhost_maps, |
|
||||
| | |relayhost, recipient domain |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
RReellooccaatteedd uusseerrss ttaabbllee
|
||||
|
||||
Next, the trivial-rewrite(8) address rewriting and resolving daemon runs each
|
||||
recipient through the relocated(5) database. This table provides information on
|
||||
how to reach users that no longer have an account, or what to do with mail for
|
||||
entire domains that no longer exist. When mail is sent to an address that is
|
||||
listed in this table, the message is returned to the sender with an informative
|
||||
message.
|
||||
|
||||
The relocated(5) database is searched after transport(5) table lookups, in
|
||||
anticipation of transport(5) tables that can replace one recipient address by a
|
||||
different one.
|
||||
|
||||
Lookups of relocated users are disabled by default. To enable, edit the
|
||||
relocated_maps parameter in the main.cf file and specify one or more lookup
|
||||
tables, separated by whitespace or commas.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relocated_maps = hash:/etc/postfix/relocated
|
||||
|
||||
/etc/postfix/relocated:
|
||||
username@example.com otheruser@elsewhere.tld
|
||||
|
||||
As of Postfix version 2, mail for a relocated user will be rejected by the SMTP
|
||||
server with the reason "user has moved to otheruser@elsewhere.tld". Older
|
||||
Postfix versions will receive the mail first, and then return it to the sender
|
||||
as undeliverable, with the same reason.
|
||||
|
||||
GGeenneerriicc mmaappppiinngg ffoorr oouuttggooiinngg SSMMTTPP mmaaiill
|
||||
|
||||
Some hosts have no valid Internet domain name, and instead use a name such as
|
||||
localdomain.local. This can be a problem when you want to send mail over the
|
||||
Internet, because many mail servers reject mail addresses with invalid domain
|
||||
names.
|
||||
|
||||
With the smtp_generic_maps parameter you can specify generic(5) lookup tables
|
||||
that replace local mail addresses by valid Internet addresses when mail leaves
|
||||
the machine via SMTP. The generic(5) mapping replaces envelope and header
|
||||
addresses, and is non-recursive. It does not happen when you send mail between
|
||||
addresses on the local machine.
|
||||
|
||||
This feature is available in Postfix version 2.2 and later.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_generic_maps = hash:/etc/postfix/generic
|
||||
|
||||
/etc/postfix/generic:
|
||||
his@localdomain.local hisaccount@hisisp.example
|
||||
her@localdomain.local heraccount@herisp.example
|
||||
@localdomain.local hisaccount+local@hisisp.example
|
||||
|
||||
When mail is sent to a remote host via SMTP, this replaces
|
||||
his@localdomain.local by his ISP mail address, replaces her@localdomain.local
|
||||
by her ISP mail address, and replaces other local addresses by his ISP account,
|
||||
with an address extension of +local (this example assumes that the ISP supports
|
||||
"+" style address extensions).
|
||||
|
||||
LLooccaall aalliiaass ddaattaabbaassee
|
||||
|
||||
When mail is to be delivered locally, the local(8) delivery agent runs each
|
||||
local recipient name through the aliases(5) database. The mapping does not
|
||||
affect addresses in message headers. Local aliases are typically used to
|
||||
implement distribution lists, or to direct mail for standard aliases such as
|
||||
postmaster to real people. The table can also be used to map
|
||||
"Firstname.Lastname" addresses to login names.
|
||||
|
||||
Note: local aliasing (alias_maps) applies only to local(8) recipients. This is
|
||||
unlike virtual aliasing (virtual_alias_maps) which applies to all recipients:
|
||||
local(8), virtual, and remote.
|
||||
|
||||
Alias lookups are enabled by default. The default configuration depends on the
|
||||
operating system environment, but it is typically one of the following:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
alias_maps = hash:/etc/aliases
|
||||
alias_maps = dbm:/etc/aliases, nis:mail.aliases
|
||||
|
||||
The pathname of the alias database file is controlled with the alias_database
|
||||
configuration parameter. The value is system dependent. Usually it is one of
|
||||
the following:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
alias_database = hash:/etc/aliases (4.4BSD, LINUX)
|
||||
alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
|
||||
alias_database = dbm:/etc/mail/aliases (SYSV4)
|
||||
|
||||
An aliases(5) file can specify that mail should be delivered to a local file,
|
||||
or to a command that receives the message in the standard input stream. For
|
||||
security reasons, deliveries to command and file destinations are performed
|
||||
with the rights of the alias database owner. A default userid, default_privs,
|
||||
is used for deliveries to commands or files in "root"-owned aliases.
|
||||
|
||||
LLooccaall ppeerr--uusseerr ..ffoorrwwaarrdd ffiilleess
|
||||
|
||||
With delivery via the local(8) delivery agent, users can control their own mail
|
||||
delivery by specifying destinations in a file called .forward in their home
|
||||
directories. The syntax of these files is the same as with the local aliases(5)
|
||||
file, except that the left-hand side of the alias (lookup key and colon) are
|
||||
not present.
|
||||
|
||||
LLooccaall ccaattcchh--aallll aaddddrreessss
|
||||
|
||||
When the local(8) delivery agent finds that a message recipient does not exist,
|
||||
the message is normally returned to the sender ("user unknown"). Sometimes it
|
||||
is desirable to forward mail for non-existing recipients to another machine.
|
||||
For this purpose you can specify an alternative destination with the
|
||||
luser_relay configuration parameter.
|
||||
|
||||
Alternatively, mail for non-existent recipients can be delegated to an entirely
|
||||
different message transport, as specified with the fallback_transport
|
||||
configuration parameter. For details, see the local(8) delivery agent
|
||||
documentation.
|
||||
|
||||
Note: if you use the luser_relay feature in order to receive mail for non-UNIX
|
||||
accounts, then you must specify:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_recipient_maps =
|
||||
|
||||
(i.e. empty) in the main.cf file, otherwise the Postfix SMTP server will reject
|
||||
mail for non-UNIX accounts with "User unknown in local recipient table". See
|
||||
the LOCAL_RECIPIENT_README file for more information on this.
|
||||
|
||||
luser_relay can specify one address. It is subjected to "$name" expansions.
|
||||
Examples:
|
||||
|
||||
$user@other.host
|
||||
The bare username, without address extension, is prepended to
|
||||
"@other.host". For example, mail for "username+foo" is sent to
|
||||
"username@other.host".
|
||||
|
||||
$local@other.host
|
||||
The entire original recipient localpart, including address extension,
|
||||
is prepended to "@other.host". For example, mail for "username+foo" is
|
||||
sent to "username+foo@other.host".
|
||||
|
||||
sysadmin+$user
|
||||
The bare username, without address extension, is appended to
|
||||
"sysadmin". For example, mail for "username+foo" is sent to
|
||||
"sysadmin+username".
|
||||
|
||||
sysadmin+$local
|
||||
The entire original recipient localpart, including address extension,
|
||||
is appended to "sysadmin". For example, mail for "username+foo" is sent
|
||||
to "sysadmin+username+foo".
|
||||
|
||||
DDeebbuuggggiinngg yyoouurr aaddddrreessss mmaanniippuullaattiioonnss
|
||||
|
||||
Postfix version 2.1 and later can produce mail delivery reports for debugging
|
||||
purposes. These reports not only show sender/recipient addresses after address
|
||||
rewriting and alias expansion or forwarding, they also show information about
|
||||
delivery to mailbox, delivery to non-Postfix command, responses from remote
|
||||
SMTP servers, and so on.
|
||||
|
||||
Postfix can produce two types of mail delivery reports for debugging:
|
||||
|
||||
* What-if: report what would happen, but do not actually deliver mail. This
|
||||
mode of operation is requested with:
|
||||
|
||||
$ //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
|
||||
Mail Delivery Status Report will be mailed to <your login name>.
|
||||
|
||||
* What happened: deliver mail and report successes and/or failures, including
|
||||
replies from remote SMTP servers. This mode of operation is requested with:
|
||||
|
||||
$ //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
|
||||
Mail Delivery Status Report will be mailed to <your login name>.
|
||||
|
||||
These reports contain information that is generated by Postfix delivery agents.
|
||||
Since these run as daemon processes and do not interact with users directly,
|
||||
the result is sent as mail to the sender of the test message. The format of
|
||||
these reports is practically identical to that of ordinary non-delivery
|
||||
notifications.
|
||||
|
||||
As an example, below is the delivery report that is produced with the command
|
||||
"sendmail -bv postfix-users@postfix.org". The first part of the report contains
|
||||
human-readable text. In this case, mail would be delivered via mail.cloud9.net,
|
||||
and the SMTP server replies with "250 Ok". Other reports may show delivery to
|
||||
mailbox, or delivery to non-Postfix command.
|
||||
|
||||
Content-Description: Notification
|
||||
Content-Type: text/plain
|
||||
|
||||
This is the mail system at host spike.porcupine.org.
|
||||
|
||||
Enclosed is the mail delivery report that you requested.
|
||||
|
||||
The mail system
|
||||
|
||||
<postfix-users@postfix.org>: delivery via mail.cloud9.net[168.100.1.4]: 250
|
||||
2.1.5 Ok
|
||||
|
||||
The second part of the report is in machine-readable form, and includes the
|
||||
following information:
|
||||
|
||||
* The envelope sender address (wietse@porcupine.org).
|
||||
* The envelope recipient address (postfix-users@postfix.org). If the
|
||||
recipient address was changed by Postfix then Postfix also includes the
|
||||
original recipient address.
|
||||
* The delivery status.
|
||||
|
||||
Some details depend on Postfix version. The example below is for Postfix
|
||||
version 2.3 and later.
|
||||
|
||||
Content-Description: Delivery report
|
||||
Content-Type: message/delivery-status
|
||||
|
||||
Reporting-MTA: dns; spike.porcupine.org
|
||||
X-Postfix-Queue-ID: 84863BC0E5
|
||||
X-Postfix-Sender: rfc822; wietse@porcupine.org
|
||||
Arrival-Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
|
||||
|
||||
Final-Recipient: rfc822; postfix-users@postfix.org
|
||||
Action: deliverable
|
||||
Status: 2.1.5
|
||||
Remote-MTA: dns; mail.cloud9.net
|
||||
Diagnostic-Code: smtp; 250 2.1.5 Ok
|
||||
|
||||
The third part of the report contains the message that Postfix would have
|
||||
delivered, including From: and To: message headers, so that you can see any
|
||||
effects of address rewriting on those. Mail submitted with "sendmail -bv" has
|
||||
no body content so none is shown in the example below.
|
||||
|
||||
Content-Description: Message
|
||||
Content-Type: message/rfc822
|
||||
|
||||
Received: by spike.porcupine.org (Postfix, from userid 1001)
|
||||
id 84863BC0E5; Sun, 26 Nov 2006 17:01:01 -0500 (EST)
|
||||
Subject: probe
|
||||
To: postfix-users@postfix.org
|
||||
Message-Id: <20061126220101.84863BC0E5@spike.porcupine.org>
|
||||
Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
|
||||
From: wietse@porcupine.org (Wietse Venema)
|
||||
|
||||
451
README_FILES/ADDRESS_VERIFICATION_README
Normal file
451
README_FILES/ADDRESS_VERIFICATION_README
Normal file
|
|
@ -0,0 +1,451 @@
|
|||
PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
WWAARRNNIINNGG
|
||||
|
||||
Recipient address verification may cause an increased load on down-stream
|
||||
servers in the case of a dictionary attack or a flood of backscatter bounces.
|
||||
Sender address verification may cause your site to be denylisted by some
|
||||
providers. See also the "Limitations" section below for more.
|
||||
|
||||
WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
|
||||
|
||||
Address verification is a feature that allows the Postfix SMTP server to block
|
||||
a sender (MAIL FROM) or recipient (RCPT TO) address until the address has been
|
||||
verified to be deliverable.
|
||||
|
||||
The technique has obvious uses to reject junk mail with an unreplyable sender
|
||||
address.
|
||||
|
||||
The technique is also useful to block mail for undeliverable recipients, for
|
||||
example on a mail relay host that does not have a list of all the valid
|
||||
recipient addresses. This prevents undeliverable junk mail from entering the
|
||||
queue, so that Postfix doesn't have to waste resources trying to send MAILER-
|
||||
DAEMON messages back.
|
||||
|
||||
This feature is available in Postfix version 2.1 and later.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* How address verification works
|
||||
* Limitations of address verification
|
||||
* Recipient address verification
|
||||
* Sender address verification for mail from frequently forged domains
|
||||
* Sender address verification for all email
|
||||
* Address verification database
|
||||
* Managing the address verification database
|
||||
* Controlling the routing of address verification probes
|
||||
* Forced probe routing examples
|
||||
* Limitations of forced probe routing
|
||||
|
||||
HHooww aaddddrreessss vveerriiffiiccaattiioonn wwoorrkkss
|
||||
|
||||
A Postfix MTA verifies a sender or recipient address by probing the preferred
|
||||
MTAs for that address, without actually delivering mail. The preferred MTAs
|
||||
could include the Postfix MTA itself, or some remote MTAs (SMTP interruptus).
|
||||
Probe messages are like normal mail, except that they are never delivered,
|
||||
deferred or bounced; probe messages are always discarded.
|
||||
|
||||
probe Postfix
|
||||
message -> mail
|
||||
Postfix Postfix -> queue
|
||||
Internet -> SMTP <-> verify
|
||||
server server |
|
||||
v
|
||||
|
||||
<- Postfix
|
||||
probe <- delivery -> Local
|
||||
status agents -> Remote
|
||||
^
|
||||
|
|
||||
v
|
||||
|
||||
Address
|
||||
verification
|
||||
database
|
||||
|
||||
With Postfix address verification turned on, normal mail will suffer only a
|
||||
short delay of up to 6 seconds while an address is being verified for the first
|
||||
time. Once an address status is known, the status is cached and Postfix replies
|
||||
immediately.
|
||||
|
||||
When verification takes too long the Postfix SMTP server defers the sender or
|
||||
recipient address with a 450 reply. Normal mail clients will connect again
|
||||
after some delay. The address verification delay is configurable with the
|
||||
main.cf address_verify_poll_count and address_verify_poll_delay parameters. See
|
||||
postconf(5) for details.
|
||||
|
||||
LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffiiccaattiioonn
|
||||
|
||||
* Postfix assumes that a remote SMTP server will reject unknown addresses in
|
||||
reply to the RCPT TO command. However, some sites report this in reply to
|
||||
the DATA command. For such sites you may configure a workaround with the
|
||||
smtp_address_verify_target parameter (Postfix 3.0 and later).
|
||||
|
||||
* When verifying a remote address, Postfix probes the preferred MTAs for that
|
||||
address, without actually delivering mail. If a preferred MTA accepts the
|
||||
address, then Postfix assumes that the address is deliverable. In reality,
|
||||
mail for a remote address can bounce AFTER a preferred MTA accepts the
|
||||
recipient address, or AFTER a preferred MTA accepts the message content.
|
||||
|
||||
* Some sites may denylist you when you are probing them too often (a probe is
|
||||
an SMTP session that does not deliver mail), or when you are probing them
|
||||
too often for a non-existent address. This is one reason why you should use
|
||||
sender address verification sparingly, if at all, when your site receives
|
||||
lots of email.
|
||||
|
||||
* Normally, address verification probe messages follow the same path as
|
||||
regular mail. However, some sites send mail to the Internet via an
|
||||
intermediate relayhost; this breaks address verification. See below,
|
||||
section "Controlling the routing of address verification probes", for how
|
||||
to override mail routing and for possible limitations when you have to do
|
||||
this.
|
||||
|
||||
* Postfix assumes that an address is undeliverable when a preferred MTA for
|
||||
the address rejects the probe, regardless of the reason for rejection
|
||||
(client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix
|
||||
rejects an address when a preferred MTA for that address rejects mail from
|
||||
your machine for any reason. This is not a limitation, but it is mentioned
|
||||
here just in case people believe that it is a limitation.
|
||||
|
||||
* Unfortunately, some sites do not reject unknown addresses in reply to the
|
||||
RCPT TO or DATA command, but instead report a delivery failure in response
|
||||
to end of DATA after a message is transferred. Postfix address verification
|
||||
does not work with such sites.
|
||||
|
||||
* By default, Postfix probe messages have a sender address "double-
|
||||
bounce@$myorigin" (with Postfix versions before 2.5, the default is
|
||||
"postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does
|
||||
not reject mail for this address.
|
||||
|
||||
You can change the probe sender address into the null address
|
||||
("address_verify_sender ="). This is UNSAFE because address probes will
|
||||
fail with mis-configured sites that reject MAIL FROM: <>, while probes from
|
||||
"double-bounce@$myorigin" would succeed.
|
||||
|
||||
* The downside of using a non-empty sender address is that the address may
|
||||
end up on spammer mailing lists. Although Postfix always discards mail to
|
||||
the double-bounce address, this still results in wasted network bandwidth
|
||||
and server capacity. To defeat address harvesting, Postfix 2.9 and later
|
||||
support time-dependent sender addresses when you specify a non-zero
|
||||
address_verify_sender_ttl value.
|
||||
|
||||
RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn
|
||||
|
||||
As mentioned earlier, recipient address verification is useful to block mail
|
||||
for undeliverable recipients on a mail relay host that does not have a list of
|
||||
all valid recipient addresses. This can help to prevent the mail queue from
|
||||
filling up with MAILER-DAEMON messages.
|
||||
|
||||
Recipient address verification is relatively straightforward and there are no
|
||||
surprises. If a recipient probe fails, then Postfix rejects mail for the
|
||||
recipient address. If a recipient probe succeeds, then Postfix accepts mail for
|
||||
the recipient address. However, recipient address verification probes can
|
||||
increase the load on down-stream MTAs when you're being flooded by backscatter
|
||||
bounces, or when some spammer is mounting a dictionary attack.
|
||||
|
||||
By default, address verification results are saved in a persistent database
|
||||
(Postfix version 2.7 and later; with earlier versions, specify the database in
|
||||
main.cf as described later). The persistent database helps to avoid probing the
|
||||
same address repeatedly.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks
|
||||
# reject_unauth_destination is not needed here if the mail
|
||||
# relay policy is specified under smtpd_relay_restrictions
|
||||
# (available with Postfix 2.10 and later).
|
||||
reject_unauth_destination
|
||||
...
|
||||
reject_unknown_recipient_domain
|
||||
reject_unverified_recipient
|
||||
...
|
||||
# Postfix 2.6 and later privacy feature.
|
||||
# unverified_recipient_reject_reason = Address lookup failed
|
||||
|
||||
# Postfix 3.2 and earlier workaround.
|
||||
# Do not set enable_original_recipient=no. This prevents Postfix
|
||||
# from saving the recipient address verification result under
|
||||
# the original address, when the address verification probe
|
||||
# message goes through address aliasing or canonical mapping.
|
||||
|
||||
The "reject_unknown_recipient_domain" restriction blocks mail for non-existent
|
||||
domains. Putting this before "reject_unverified_recipient" avoids the overhead
|
||||
of generating unnecessary probe messages.
|
||||
|
||||
The unverified_recipient_reject_code parameter (default 450) specifies the
|
||||
numerical Postfix SMTP server reply code when a recipient address is known to
|
||||
bounce. Change this setting into 550 when you trust Postfix's judgments.
|
||||
|
||||
The following features are available in Postfix 2.6 and later.
|
||||
|
||||
The unverified_recipient_defer_code parameter (default 450) specifies the
|
||||
numerical Postfix SMTP server reply code when a recipient address probe fails
|
||||
with some temporary error. Some sites insist on changing this into 250. NOTE:
|
||||
This change turns MX servers into backscatter sources when the load is high.
|
||||
|
||||
The unverified_recipient_reject_reason parameter (default: empty) specifies
|
||||
fixed text that Postfix will send to remote SMTP clients, instead of sending
|
||||
actual address verification details. Do not specify the SMTP status code or
|
||||
enhanced status code.
|
||||
|
||||
The unverified_recipient_tempfail_action parameter (default: defer_if_permit)
|
||||
specifies the Postfix SMTP server action when a recipient address verification
|
||||
probe fails with some temporary error.
|
||||
|
||||
SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
|
||||
|
||||
Only for very small sites, it is relatively safe to turn on sender address
|
||||
verification for specific domains that often appear in forged email.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_sender_restrictions = hash:/etc/postfix/sender_access
|
||||
unverified_sender_reject_code = 550
|
||||
# Postfix 2.6 and later.
|
||||
# unverified_sender_defer_code = 250
|
||||
|
||||
# Default setting for Postfix 2.7 and later.
|
||||
# Note 1: Be sure to read the "Caching" section below!
|
||||
# Note 2: Avoid hash files here. Use btree or lmdb instead.
|
||||
address_verify_map = btree:/var/lib/postfix/verify
|
||||
|
||||
# Postfix 3.2 and earlier workaround.
|
||||
# Do not set enable_original_recipient=no. This prevents Postfix
|
||||
# from saving the sender address verification result under the
|
||||
# original address, when the address verification probe message
|
||||
# goes through address aliasing or canonical mapping.
|
||||
|
||||
/etc/postfix/sender_access:
|
||||
# Don't do this when you handle lots of email.
|
||||
aol.com reject_unverified_sender
|
||||
hotmail.com reject_unverified_sender
|
||||
bigfoot.com reject_unverified_sender
|
||||
... etcetera ...
|
||||
|
||||
At some point in cyberspace/time, a list of frequently forged MAIL FROM domains
|
||||
was archived at https://web.archive.org/web/20080526153208/http://
|
||||
www.monkeys.com/anti-spam/filtering/sender-domain-validate.in.
|
||||
|
||||
NOTE: One of the first things you might want to do is to turn on sender address
|
||||
verification for all your own domains.
|
||||
|
||||
SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr aallll eemmaaiill
|
||||
|
||||
Unfortunately, sender address verification cannot simply be turned on for all
|
||||
email - you are likely to lose legitimate mail from mis-configured systems. You
|
||||
almost certainly will have to set up allow lists for specific addresses, or
|
||||
even for entire domains.
|
||||
|
||||
To find out how sender address verification would affect your mail, specify
|
||||
"warn_if_reject reject_unverified_sender" so that you can see what mail would
|
||||
be blocked:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_sender_restrictions =
|
||||
permit_mynetworks
|
||||
...
|
||||
check_sender_access hash:/etc/postfix/sender_access
|
||||
reject_unknown_sender_domain
|
||||
warn_if_reject reject_unverified_sender
|
||||
...
|
||||
# Postfix 2.6 and later.
|
||||
# unverified_sender_reject_reason = Address verification failed
|
||||
|
||||
# Default setting for Postfix 2.7 and later.
|
||||
# Note 1: Be sure to read the "Caching" section below!
|
||||
# Note 2: Avoid hash files here. Use btree or lmdb instead.
|
||||
address_verify_map = btree:/var/lib/postfix/verify
|
||||
|
||||
This is also a good way to populate your cache with address verification
|
||||
results before you start to actually reject mail.
|
||||
|
||||
The sender_access restriction is needed to allowlist domains or addresses that
|
||||
are known to be OK. Although Postfix will not mark a known-to-be-good address
|
||||
as bad after a probe fails, it is better to be safe than sorry.
|
||||
|
||||
NOTE: You will have to allowlist sites such as securityfocus.com and other
|
||||
sites that operate mailing lists that use a different sender address for each
|
||||
posting (VERP). Such addresses pollute the address verification cache quickly,
|
||||
and generate unnecessary sender verification probes.
|
||||
|
||||
/etc/postfix/sender_access
|
||||
securityfocus.com OK
|
||||
...
|
||||
|
||||
The "reject_unknown_sender_domain" restriction blocks mail from non-existent
|
||||
domains. Putting this before "reject_unverified_sender" avoids the overhead of
|
||||
generating unnecessary probe messages.
|
||||
|
||||
The unverified_sender_reject_code parameter (default 450) specifies the
|
||||
numerical Postfix server reply code when a sender address is known to bounce.
|
||||
Change this setting into 550 when you trust Postfix's judgments.
|
||||
|
||||
The following features are available in Postfix 2.6 and later.
|
||||
|
||||
The unverified_sender_defer_code parameter (default 450) specifies the
|
||||
numerical Postfix SMTP server reply code when a sender address verification
|
||||
probe fails with some temporary error. Specify a valid 2xx or 4xx code.
|
||||
|
||||
The unverified_sender_reject_reason parameter (default: empty) specifies fixed
|
||||
text that Postfix will send to remote SMTP clients, instead of sending actual
|
||||
address verification details. Do not specify the SMTP status code or enhanced
|
||||
status code.
|
||||
|
||||
The unverified_sender_tempfail_action parameter (default: defer_if_permit)
|
||||
specifies the Postfix SMTP server action when a sender address verification
|
||||
probe fails with some temporary error.
|
||||
|
||||
AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
|
||||
|
||||
To improve performance, the Postfix verify(8) daemon can save address
|
||||
verification results to a persistent database. This is enabled by default with
|
||||
Postfix 2.7 and later. The address_verify_map (NOTE: singular) configuration
|
||||
parameter specifies persistent storage for sender or recipient address
|
||||
verification results. If you specify an empty value, all address verification
|
||||
results are lost after "postfix reload" or "postfix stop".
|
||||
|
||||
# Example 1: Default setting for Postfix 2.7 and later.
|
||||
# Note: avoid hash files here. Use btree or lmdb instead.
|
||||
/etc/postfix/main.cf:
|
||||
address_verify_map = btree:$data_directory/verify_cache
|
||||
|
||||
# Example 2: Shared persistent lmdb: cache (Postfix 2.11 or later).
|
||||
# Disable automatic cache cleanup in all Postfix instances except
|
||||
# for one instance that will be responsible for cache cleanup.
|
||||
/etc/postfix/main.cf:
|
||||
address_verify_map = lmdb:$data_directory/verify_cache
|
||||
# address_verify_cache_cleanup_interval = 0
|
||||
|
||||
# Example 3: Shared persistent btree: cache (Postfix 2.9 or later).
|
||||
# Disable automatic cache cleanup in all Postfix instances except
|
||||
# for one instance that will be responsible for cache cleanup.
|
||||
/etc/postfix/main.cf:
|
||||
address_verify_map = proxy:btree:$data_directory/verify_cache
|
||||
# address_verify_cache_cleanup_interval = 0
|
||||
|
||||
# Example 4: Shared memory cache (requires Postfix 2.9 or later).
|
||||
# Disable automatic cache cleanup in all Postfix instances.
|
||||
# See memcache_table(5) for details.
|
||||
/etc/postfix/main.cf:
|
||||
address_verify_map = memcache:/etc/postfix/verify-memcache.cf
|
||||
address_verify_cache_cleanup_interval = 0
|
||||
|
||||
# Example 5: Default setting for Postfix 2.6 and earlier.
|
||||
# This uses non-persistent storage only.
|
||||
/etc/postfix/main.cf:
|
||||
address_verify_map =
|
||||
|
||||
NOTE 1: The database file should be stored under a Postfix-owned directory,
|
||||
such as $data_directory.
|
||||
|
||||
As of version 2.5, Postfix no longer uses root privileges when opening this
|
||||
file. To maintain backwards compatibility, an attempt to open the file
|
||||
under a non-Postfix directory is redirected to the Postfix-owned
|
||||
data_directory, and a warning is logged. If you wish to continue using a
|
||||
pre-existing database file, change its file ownership to the account
|
||||
specified with the mail_owner parameter, and either move the file to the
|
||||
data_directory, or move it to some other Postfix-owned directory.
|
||||
|
||||
NOTE 2: Do not put this file in a file system that may run out of space. When
|
||||
the address verification table gets corrupted the world comes to an end and YOU
|
||||
will have to MANUALLY fix things as described in the next section. Meanwhile,
|
||||
you will not receive mail via SMTP.
|
||||
|
||||
NOTE 3: The verify(8) daemon will create a new database when none exists. It
|
||||
will open or create the file before entering the chroot jail.
|
||||
|
||||
MMaannaaggiinngg tthhee aaddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
|
||||
|
||||
The verify(8) manual page describes parameters that control how long address
|
||||
verification results are cached before they need to be refreshed, and how long
|
||||
results can remain "unrefreshed" before they expire. Postfix uses different
|
||||
controls for positive results (address was accepted) and for negative results
|
||||
(address was rejected, or address verification failed for some other reason).
|
||||
|
||||
The verify(8) daemon will periodically remove expired entries from the address
|
||||
verification database, and log the number of entries retained and dropped
|
||||
(Postfix versions 2.7 and later). A cleanup run is logged as "partial" when the
|
||||
daemon terminates early because of "postfix reload, "postfix stop", or because
|
||||
the daemon received no requests for $max_idle seconds. Postfix versions 2.6 and
|
||||
earlier do not implement automatic address verification database cleanup.
|
||||
There, the database is managed manually as described next.
|
||||
|
||||
When the address verification database file becomes too big, or when it becomes
|
||||
corrupted, the solution is to manually rename or delete (NOT: truncate) the
|
||||
file and run "postfix reload". The verify(8) daemon will then create a new
|
||||
database file.
|
||||
|
||||
CCoonnttrroolllliinngg tthhee rroouuttiinngg ooff aaddddrreessss vveerriiffiiccaattiioonn pprroobbeess
|
||||
|
||||
By default, Postfix sends address verification probe messages via the same
|
||||
route as regular mail, because that normally produces the most accurate result.
|
||||
It's no good to verify a local address by connecting to your own SMTP port;
|
||||
that just triggers all kinds of mailer loop alarms. The same is true for any
|
||||
destination that your machine is best MX host for: hidden domains, virtual
|
||||
domains, etc.
|
||||
|
||||
However, some sites have a complex infrastructure where mail is not sent
|
||||
directly to the Internet, but is instead given to an intermediate relayhost.
|
||||
This is a problem for address verification, because remote Internet addresses
|
||||
can be verified only when Postfix can access remote destinations directly.
|
||||
|
||||
For this reason, Postfix allows you to override the routing parameters when it
|
||||
delivers an address verification probe message.
|
||||
|
||||
First, the address_verify_relayhost parameter allows you to override the
|
||||
relayhost setting, and the address_verify_transport_maps parameter allows you
|
||||
to override the transport_maps setting. The
|
||||
address_verify_sender_dependent_relayhost_maps parameter does the same for
|
||||
sender-dependent relayhost selection.
|
||||
|
||||
Second, each address class is given its own address verification version of the
|
||||
message delivery transport, as shown in the table below. Address classes are
|
||||
defined in the ADDRESS_CLASS_README file.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|DDoommaaiinn lliisstt |RReegguullaarr ttrraannssppoorrtt|VVeerriiffyy ttrraannssppoorrtt |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|mydestination |local_transport |address_verify_local_transport |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|virtual_alias_domains |(not applicable) |(not applicable) |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|virtual_mailbox_domains|virtual_transport|address_verify_virtual_transport|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|relay_domains |relay_transport |address_verify_relay_transport |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|(not applicable) |default_transport|address_verify_default_transport|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
By default, the parameters that control delivery of address probes have the
|
||||
same value as the parameters that control normal mail delivery.
|
||||
|
||||
FFoorrcceedd pprroobbee rroouuttiinngg eexxaammpplleess
|
||||
|
||||
In a typical scenario one would override the relayhost setting for address
|
||||
verification probes and leave everything else alone:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = $mydomain
|
||||
address_verify_relayhost =
|
||||
...
|
||||
|
||||
Sites behind a network address translation box might have to use a different
|
||||
SMTP client that sends the correct hostname information:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = $mydomain
|
||||
address_verify_relayhost =
|
||||
address_verify_default_transport = direct_smtp
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
direct_smtp .. .. .. .. .. .. .. .. .. smtp
|
||||
-o smtp_helo_name=nat.box.tld
|
||||
|
||||
LLiimmiittaattiioonnss ooff ffoorrcceedd pprroobbee rroouuttiinngg
|
||||
|
||||
Inconsistencies can happen when probe messages don't follow the same path as
|
||||
regular mail. For example, a message can be accepted when it follows the
|
||||
regular route while an otherwise identical probe message is rejected when it
|
||||
follows the forced route. The opposite can happen, too, but is less likely.
|
||||
|
||||
281
README_FILES/BACKSCATTER_README
Normal file
281
README_FILES/BACKSCATTER_README
Normal file
|
|
@ -0,0 +1,281 @@
|
|||
PPoossttffiixx BBaacckkssccaatttteerr HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document describes features that require Postfix version 2.0 or later.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* What is backscatter mail?
|
||||
* How do I block backscatter mail to random recipient addresses?
|
||||
* How do I block backscatter mail to real recipient addresses?
|
||||
|
||||
o Blocking backscatter mail with forged mail server information
|
||||
o Blocking backscatter mail with forged sender information
|
||||
o Blocking backscatter mail with other forged information
|
||||
o Blocking backscatter mail from virus scanners
|
||||
|
||||
The examples use Perl Compatible Regular Expressions (Postfix pcre: tables),
|
||||
but also provide a translation to POSIX regular expressions (Postfix regexp:
|
||||
tables). PCRE is preferred primarily because the implementation is often
|
||||
faster.
|
||||
|
||||
WWhhaatt iiss bbaacckkssccaatttteerr mmaaiill??
|
||||
|
||||
When a spammer or worm sends mail with forged sender addresses, innocent sites
|
||||
are flooded with undeliverable mail notifications. This is called backscatter
|
||||
mail. With Postfix, you know that you're a backscatter victim when your logfile
|
||||
goes on and on like this:
|
||||
|
||||
Dec 4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
|
||||
RCPT from xxxxxxx[x.x.x.x]: 550 5.1.1 <yyyyyy@your.domain.here>:
|
||||
Recipient address rejected: User unknown; from=<>
|
||||
to=<yyyyyy@your.domain.here> proto=ESMTP helo=<zzzzzz>
|
||||
|
||||
What you see are lots of "user unknown" errors with "from=<>". These are error
|
||||
reports from MAILER-DAEMONs elsewhere on the Internet, about email that was
|
||||
sent with a false sender address in your domain.
|
||||
|
||||
HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rraannddoomm rreecciippiieenntt aaddddrreesssseess??
|
||||
|
||||
If your machine receives backscatter mail to random addresses, configure
|
||||
Postfix to reject all mail for non-existent recipients as described in the
|
||||
LOCAL_RECIPIENT_README and STANDARD_CONFIGURATION_README documentation.
|
||||
|
||||
If your machine runs Postfix 2.0 and earlier, disable the "pause before reject"
|
||||
feature in the SMTP server. If your system is under stress then it should not
|
||||
waste time.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Not needed with Postfix 2.1 and later.
|
||||
smtpd_error_sleep_time = 0
|
||||
|
||||
# Not needed with Postfix 2.4 and later.
|
||||
unknown_local_recipient_reject_code = 550
|
||||
|
||||
HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rreeaall rreecciippiieenntt aaddddrreesssseess??
|
||||
|
||||
When backscatter mail passes the "unknown recipient" barrier, there still is no
|
||||
need to despair. Many mail systems are kind enough to attach the message
|
||||
headers of the undeliverable mail in the non-delivery notification. These
|
||||
message headers contain information that you can use to recognize and block
|
||||
forged mail.
|
||||
|
||||
BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ffoorrggeedd mmaaiill sseerrvveerr iinnffoorrmmaattiioonn
|
||||
|
||||
Although my email address is "wietse@porcupine.org", all my mail systems
|
||||
announce themselves with the SMTP HELO command as "hostname.porcupine.org".
|
||||
Thus, if returned mail has a Received: message header like this:
|
||||
|
||||
Received: from porcupine.org ...
|
||||
|
||||
Then I know that this is almost certainly forged mail (almost; see next section
|
||||
for the fly in the ointment). Mail that is really sent by my systems looks like
|
||||
this:
|
||||
|
||||
Received: from hostname.porcupine.org ...
|
||||
|
||||
For the same reason the following message headers are very likely to be the
|
||||
result of forgery:
|
||||
|
||||
Received: from host.example.com ([1.2.3.4] helo=porcupine.org) ...
|
||||
Received: from [1.2.3.4] (port=12345 helo=porcupine.org) ...
|
||||
Received: from host.example.com (HELO porcupine.org) ...
|
||||
Received: from host.example.com (EHLO porcupine.org) ...
|
||||
|
||||
Some forgeries show up in the way that a mail server reports itself in
|
||||
Received: message headers. Keeping in mind that all my systems have a mail
|
||||
server name of hostname.porcupine.org, the following is definitely a forgery:
|
||||
|
||||
Received: by porcupine.org ...
|
||||
Received: from host.example.com ( ... ) by porcupine.org ...
|
||||
|
||||
Another frequent sign of forgery is the Message-ID: header. My systems produce
|
||||
a Message-ID: of <stuff@hostname.porcupine.org>. The following are forgeries,
|
||||
especially the first one:
|
||||
|
||||
Message-ID: <1cb479435d8eb9.2beb1.qmail@porcupine.org>
|
||||
Message-ID: <yulszqocfzsficvzzju@porcupine.org>
|
||||
|
||||
To block such backscatter I use header_checks and body_checks patterns like
|
||||
this:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
header_checks = pcre:/etc/postfix/header_checks
|
||||
body_checks = pcre:/etc/postfix/body_checks
|
||||
|
||||
/etc/postfix/header_checks:
|
||||
# Do not indent the patterns between "if" and "endif".
|
||||
if /^Received:/
|
||||
/^Received: +from +(porcupine\.org) +/
|
||||
reject forged client name in Received: header: $1
|
||||
/^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
|
||||
(porcupine\.org)\)/
|
||||
reject forged client name in Received: header: $2
|
||||
/^Received:.* +by +(porcupine\.org)\b/
|
||||
reject forged mail server name in Received: header: $1
|
||||
endif
|
||||
/^Message-ID:.* <!&!/ DUNNO
|
||||
/^Message-ID:.*@(porcupine\.org)/
|
||||
reject forged domain name in Message-ID: header: $1
|
||||
|
||||
/etc/postfix/body_checks:
|
||||
# Do not indent the patterns between "if" and "endif".
|
||||
if /^[> ]*Received:/
|
||||
/^[> ]*Received: +from +(porcupine\.org) /
|
||||
reject forged client name in Received: header: $1
|
||||
/^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
|
||||
(porcupine\.org)\)/
|
||||
reject forged client name in Received: header: $2
|
||||
/^[> ]*Received:.* +by +(porcupine\.org)\b/
|
||||
reject forged mail server name in Received: header: $1
|
||||
endif
|
||||
/^[> ]*Message-ID:.* <!&!/ DUNNO
|
||||
/^[> ]*Message-ID:.*@(porcupine\.org)/
|
||||
reject forged domain name in Message-ID: header: $1
|
||||
|
||||
Notes:
|
||||
|
||||
* The example uses pcre: tables mainly for speed; with minor modifications,
|
||||
you can use regexp: tables as explained below.
|
||||
|
||||
* The example is simplified for educational purposes. In reality my patterns
|
||||
list multiple domain names, as "(domain|domain|...)".
|
||||
|
||||
* The "\." matches "." literally. Without the "\", the "." would match any
|
||||
character.
|
||||
|
||||
* The "\(" and "\)" match "(" and ")" literally. Without the "\", the "(" and
|
||||
")" would be grouping operators.
|
||||
|
||||
* The "\b" is used here to match the end of a word. If you use regexp:
|
||||
tables, specify "[[:>:]]" (on some systems you should specify "\>" instead;
|
||||
for details see your system documentation).
|
||||
|
||||
* The "if /pattern/" and "endif" eliminate unnecessary matching attempts. DO
|
||||
NOT indent lines starting with /pattern/ between the "if" and "endif"!
|
||||
|
||||
* The two "Message-ID:.* <!&!" rules are workarounds for some versions of
|
||||
Outlook express, as described in the caveats section below.
|
||||
|
||||
CCaavveeaattss
|
||||
|
||||
* Netscape Messenger (and reportedly, Mozilla) sends a HELO name that is
|
||||
identical to the sender address domain part. If you have such clients then
|
||||
the above patterns would block legitimate email.
|
||||
|
||||
My network has only one such machine, and to prevent its mail from being
|
||||
blocked I have configured it to send mail as user@hostname.porcupine.org.
|
||||
On the Postfix server, a canonical mapping translates this temporary
|
||||
address into user@porcupine.org.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
canonical_maps = hash:/etc/postfix/canonical
|
||||
|
||||
/etc/postfix/canonical:
|
||||
@hostname.porcupine.org @porcupine.org
|
||||
|
||||
This is of course practical only when you have very few systems that send
|
||||
HELO commands like this, and when you never have to send mail to a user on
|
||||
such a host.
|
||||
|
||||
An alternative would be to remove the hostname from
|
||||
"hostname.porcupine.org" with address masquerading, as described in the
|
||||
ADDRESS_REWRITING_README document.
|
||||
|
||||
* Reportedly, Outlook 2003 (perhaps Outlook Express, and other versions as
|
||||
well) present substantially different Message-ID headers depending upon
|
||||
whether or not a DSN is requested (via Options "Request a delivery receipt
|
||||
for this message").
|
||||
|
||||
When a DSN is requested, Outlook 2003 uses a Message-ID string that ends in
|
||||
the sender's domain name:
|
||||
|
||||
Message-ID: <!&! ...very long string... ==@example.com>
|
||||
|
||||
where example.com is the domain name part of the email address specified in
|
||||
Outlook's account settings for the user. Since many users configure their
|
||||
email addresses as username@example.com, messages with DSN turned on will
|
||||
trigger the REJECT action in the previous section.
|
||||
|
||||
If you have such clients then you can exclude their Message-ID strings with
|
||||
the two "Message-ID:.* <!&!" patterns that are shown in the previous
|
||||
section. Otherwise you will not be able to use the two backscatter rules to
|
||||
stop forged Message ID strings. Of course this workaround may break the
|
||||
next time Outlook is changed.
|
||||
|
||||
BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ffoorrggeedd sseennddeerr iinnffoorrmmaattiioonn
|
||||
|
||||
Like many people I still have a few email addresses in domains that I used in
|
||||
the past. Mail for those addresses is forwarded to my current address. Most of
|
||||
the backscatter mail that I get claims to be sent from these addresses. Such
|
||||
mail is obviously forged and is very easy to stop.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
header_checks = pcre:/etc/postfix/header_checks
|
||||
body_checks = pcre:/etc/postfix/body_checks
|
||||
|
||||
/etc/postfix/header_checks:
|
||||
/^(From|Return-Path):.*\b(user@domain\.tld)\b/
|
||||
reject forged sender address in $1: header: $2
|
||||
|
||||
/etc/postfix/body_checks:
|
||||
/^[> ]*(From|Return-Path):.*\b(user@domain\.tld)\b/
|
||||
reject forged sender address in $1: header: $2
|
||||
|
||||
Notes:
|
||||
|
||||
* The example uses pcre: tables mainly for speed; with minor modifications,
|
||||
you can use regexp: tables as explained below.
|
||||
|
||||
* The example is simplified for educational purposes. In reality, my patterns
|
||||
list multiple email addresses as "(user1@domain1\.tld|user2@domain2\.tld)".
|
||||
|
||||
* The two "\b" as used in "\b(user@domain\.tld)\b" match the beginning and
|
||||
end of a word, respectively. If you use regexp: tables, specify "[[:<:]]
|
||||
and [[:>:]]" (on some systems you should specify "\< and \>" instead; for
|
||||
details see your system documentation).
|
||||
|
||||
* The "\." matches "." literally. Without the "\", the "." would match any
|
||||
character.
|
||||
|
||||
BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ootthheerr ffoorrggeedd iinnffoorrmmaattiioonn
|
||||
|
||||
Another sign of forgery can be found in the IP address that is recorded in
|
||||
Received: headers next to your HELO host or domain name. This information must
|
||||
be used with care, though. Some mail servers are behind a network address
|
||||
translator and never see the true client IP address.
|
||||
|
||||
BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill ffrroomm vviirruuss ssccaannnneerrss
|
||||
|
||||
With all the easily recognizable forgeries eliminated, there is one category of
|
||||
backscatter mail that remains, and that is notifications from virus scanner
|
||||
software. Unfortunately, some virus scanning software doesn't know that viruses
|
||||
forge sender addresses. To make matters worse, the software also doesn't know
|
||||
how to report a mail delivery problem, so that we cannot use the above
|
||||
techniques to recognize forgeries.
|
||||
|
||||
Recognizing virus scanner mail is an error prone process, because there is a
|
||||
lot of variation in report formats. The following is only a small example of
|
||||
message header patterns. For a large collection of header and body patterns
|
||||
that recognize virus notification email, see https://web.archive.org/web/
|
||||
20100317123907/http://std.dkuug.dk/keld/virus/ or https://www.t29.dk/
|
||||
antiantivirus.txt.
|
||||
|
||||
/etc/postfix/header_checks:
|
||||
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification
|
||||
/^Content-Disposition:.*VIRUS1_DETECTED_AND_REMOVED/
|
||||
DISCARD virus notification
|
||||
/^Content-Disposition:.*VirusWarning.txt/ DISCARD virus notification
|
||||
|
||||
Note: these documents haven't been updated since 2004, so they are useful only
|
||||
as a starting point.
|
||||
|
||||
A plea to virus or spam scanner operators: please do not make the problem worse
|
||||
by sending return mail to forged sender addresses. You're only harassing
|
||||
innocent people. If you must return mail to the purported sender, please return
|
||||
the full message headers, so that the sender can filter out the obvious
|
||||
forgeries.
|
||||
|
||||
489
README_FILES/BASIC_CONFIGURATION_README
Normal file
489
README_FILES/BASIC_CONFIGURATION_README
Normal file
|
|
@ -0,0 +1,489 @@
|
|||
PPoossttffiixx BBaassiicc CCoonnffiigguurraattiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix has several hundred configuration parameters that are controlled via
|
||||
the main.cf file. Fortunately, all parameters have sensible default values. In
|
||||
many cases, you need to configure only two or three parameters before you can
|
||||
start to play with the mail system. Here's a quick introduction to the syntax:
|
||||
|
||||
* Postfix configuration files
|
||||
|
||||
The text below assumes that you already have Postfix installed on the system,
|
||||
either by compiling the source code yourself (as described in the INSTALL file)
|
||||
or by installing an already compiled version.
|
||||
|
||||
This document covers basic Postfix configuration. Information about how to
|
||||
configure Postfix for specific applications such as mailhub, firewall or dial-
|
||||
up client can be found in the STANDARD_CONFIGURATION_README file. But don't go
|
||||
there until you already have covered the material presented below.
|
||||
|
||||
The first parameters of interest specify the machine's identity and role in the
|
||||
network.
|
||||
|
||||
* What domain name to use in outbound mail
|
||||
|
||||
* What domains to receive mail for
|
||||
|
||||
* What clients to relay mail from
|
||||
|
||||
* What destinations to relay mail to
|
||||
|
||||
* What delivery method: direct or indirect
|
||||
|
||||
The default values for many other configuration parameters are derived from
|
||||
just these.
|
||||
|
||||
The next parameter of interest controls the amount of mail sent to the local
|
||||
postmaster:
|
||||
|
||||
* What trouble to report to the postmaster
|
||||
|
||||
Be sure to set the following correctly if you're behind a proxy or network
|
||||
address translator, and you are running a backup MX host for some other domain:
|
||||
|
||||
* Proxy/NAT external network addresses
|
||||
|
||||
Postfix daemon processes run in the background, and log problems and normal
|
||||
activity to the syslog daemon. Here are a few things that you need to be aware
|
||||
of:
|
||||
|
||||
* What you need to know about Postfix logging
|
||||
|
||||
If your machine has unusual security requirements you may want to run Postfix
|
||||
daemon processes inside a chroot environment.
|
||||
|
||||
* Running Postfix daemon processes chrooted
|
||||
|
||||
If you run Postfix on a virtual network interface, or if your machine runs
|
||||
other mailers on virtual interfaces, you'll have to look at the other
|
||||
parameters listed here as well:
|
||||
|
||||
* My own hostname
|
||||
|
||||
* My own domain name
|
||||
|
||||
* My own network addresses
|
||||
|
||||
PPoossttffiixx ccoonnffiigguurraattiioonn ffiilleess
|
||||
|
||||
By default, Postfix configuration files are in /etc/postfix. The two most
|
||||
important files are main.cf and master.cf; these files must be owned by root.
|
||||
Giving someone else write permission to main.cf or master.cf (or to their
|
||||
parent directories) means giving root privileges to that person.
|
||||
|
||||
In /etc/postfix/main.cf you will have to set up a minimal number of
|
||||
configuration parameters. Postfix configuration parameters resemble shell
|
||||
variables, with two important differences: the first one is that Postfix does
|
||||
not know about quotes like the UNIX shell does.
|
||||
|
||||
You specify a configuration parameter as:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
parameter = value
|
||||
|
||||
and you use it by putting a "$" character in front of its name:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
other_parameter = $parameter
|
||||
|
||||
You can use $parameter before it is given a value (that is the second main
|
||||
difference with UNIX shell variables). The Postfix configuration language uses
|
||||
lazy evaluation, and does not look at a parameter value until it is needed at
|
||||
runtime.
|
||||
|
||||
Postfix uses database files for access control, address rewriting and other
|
||||
purposes. The DATABASE_README file gives an introduction to how Postfix works
|
||||
with Berkeley DB, LDAP or SQL and other types. Here is a common example of how
|
||||
Postfix invokes a database:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
|
||||
Whenever you make a change to the main.cf or master.cf file, execute the
|
||||
following command as root in order to refresh a running mail system:
|
||||
|
||||
# postfix reload
|
||||
|
||||
WWhhaatt ddoommaaiinn nnaammee ttoo uussee iinn oouuttbboouunndd mmaaiill
|
||||
|
||||
The myorigin parameter specifies the domain that appears in mail that is posted
|
||||
on this machine. The default is to use the local machine name, $myhostname,
|
||||
which defaults to the name of the machine. Unless you are running a really
|
||||
small site, you probably want to change that into $mydomain, which defaults to
|
||||
the parent domain of the machine name.
|
||||
|
||||
For the sake of consistency between sender and recipient addresses, myorigin
|
||||
also specifies the domain name that is appended to an unqualified recipient
|
||||
address.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
myorigin = $myhostname (default: send mail as "user@$myhostname")
|
||||
myorigin = $mydomain (probably desirable: "user@$mydomain")
|
||||
|
||||
WWhhaatt ddoommaaiinnss ttoo rreecceeiivvee mmaaiill ffoorr
|
||||
|
||||
The mydestination parameter specifies what domains this machine will deliver
|
||||
locally, instead of forwarding to another machine. The default is to receive
|
||||
mail for the machine itself. See the VIRTUAL_README file for how to configure
|
||||
Postfix for hosted domains.
|
||||
|
||||
You can specify zero or more domain names, "/file/name" patterns and/or "type:
|
||||
table" lookup tables (such as hash:, btree:, nis:, ldap:, or mysql:), separated
|
||||
by whitespace and/or commas. A "/file/name" pattern is replaced by its
|
||||
contents; "type:table" requests that a table lookup is done and merely tests
|
||||
for existence: the lookup result is ignored.
|
||||
|
||||
IMPORTANT: If your machine is a mail server for its entire domain, you must
|
||||
list $mydomain as well.
|
||||
|
||||
Example 1: default setting.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mydestination = $myhostname localhost.$mydomain localhost
|
||||
|
||||
Example 2: domain-wide mail server.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mydestination = $myhostname localhost.$mydomain localhost $mydomain
|
||||
|
||||
Example 3: host with multiple DNS A records.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mydestination = $myhostname localhost.$mydomain localhost
|
||||
www.$mydomain ftp.$mydomain
|
||||
|
||||
Caution: in order to avoid mail delivery loops, you must list all hostnames of
|
||||
the machine, including $myhostname, and localhost.$mydomain.
|
||||
|
||||
WWhhaatt cclliieennttss ttoo rreellaayy mmaaiill ffrroomm
|
||||
|
||||
By default, Postfix will forward mail from clients in authorized network blocks
|
||||
to any destination. Authorized networks are defined with the mynetworks
|
||||
configuration parameter. The current default is to authorize the local machine
|
||||
only. Prior to Postfix 3.0, the default was to authorize all clients in the IP
|
||||
subnetworks that the local machine is attached to.
|
||||
|
||||
Postfix can also be configured to relay mail from "mobile" clients that send
|
||||
mail from outside an authorized network block. This is explained in the
|
||||
SASL_README and TLS_README documents.
|
||||
|
||||
IMPORTANT: If your machine is connected to a wide area network then the
|
||||
"mynetworks_style = subnet" setting may be too friendly.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mynetworks_style = subnet (not safe on a wide area network)
|
||||
mynetworks_style = host (authorize local machine only)
|
||||
mynetworks = 127.0.0.0/8 (authorize local machine only)
|
||||
mynetworks = 127.0.0.0/8 168.100.189.2/32 (authorize local machine)
|
||||
mynetworks = 127.0.0.0/8 168.100.189.2/28 (authorize local networks)
|
||||
|
||||
You can specify the trusted networks in the main.cf file, or you can let
|
||||
Postfix do the work for you. The default is to let Postfix do the work. The
|
||||
result depends on the mynetworks_style parameter value.
|
||||
|
||||
* Specify "mynetworks_style = host" (the default when compatibility_level >=
|
||||
2) when Postfix should forward mail from only the local machine.
|
||||
|
||||
* Specify "mynetworks_style = subnet" (the default when compatibility_level <
|
||||
2) when Postfix should forward mail from SMTP clients in the same IP
|
||||
subnetworks as the local machine. On Linux, this works correctly only with
|
||||
interfaces specified with the "ifconfig" or "ip" command.
|
||||
|
||||
* Specify "mynetworks_style = class" when Postfix should forward mail from
|
||||
SMTP clients in the same IP class A/B/C networks as the local machine.
|
||||
Don't do this with a dialup site - it would cause Postfix to "trust" your
|
||||
entire provider's network. Instead, specify an explicit mynetworks list by
|
||||
hand, as described below.
|
||||
|
||||
Alternatively, you can specify the mynetworks list by hand, in which case
|
||||
Postfix ignores the mynetworks_style setting. To specify the list of trusted
|
||||
networks by hand, specify network blocks in CIDR (network/mask) notation, for
|
||||
example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mynetworks = 168.100.189.0/28, 127.0.0.0/8
|
||||
|
||||
You can also specify the absolute pathname of a pattern file instead of listing
|
||||
the patterns in the main.cf file.
|
||||
|
||||
WWhhaatt ddeessttiinnaattiioonnss ttoo rreellaayy mmaaiill ttoo
|
||||
|
||||
By default, Postfix will forward mail from strangers (clients outside
|
||||
authorized networks) to authorized remote destinations only. Authorized remote
|
||||
destinations are defined with the relay_domains configuration parameter. The
|
||||
default is to authorize all domains (and subdomains) of the domains listed with
|
||||
the mydestination parameter.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relay_domains = $mydestination (default)
|
||||
relay_domains = (safe: never forward mail from strangers)
|
||||
relay_domains = $mydomain (forward mail to my domain and subdomains)
|
||||
|
||||
WWhhaatt ddeelliivveerryy mmeetthhoodd:: ddiirreecctt oorr iinnddiirreecctt
|
||||
|
||||
By default, Postfix tries to deliver mail directly to the Internet. Depending
|
||||
on your local conditions this may not be possible or desirable. For example,
|
||||
your system may be turned off outside office hours, it may be behind a
|
||||
firewall, or it may be connected via a provider who does not allow direct mail
|
||||
to the Internet. In those cases you need to configure Postfix to deliver mail
|
||||
indirectly via a relay host.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = (default: direct delivery to Internet)
|
||||
relayhost = $mydomain (deliver via local mailhub)
|
||||
relayhost = [mail.$mydomain] (deliver via local mailhub)
|
||||
relayhost = [mail.isp.tld] (deliver via provider mailhub)
|
||||
|
||||
The form enclosed with [] eliminates DNS MX lookups. Don't worry if you don't
|
||||
know what that means. Just be sure to specify the [] around the mailhub
|
||||
hostname that your ISP gave to you, otherwise mail may be mis-delivered.
|
||||
|
||||
The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
|
||||
and/or dial-up networks.
|
||||
|
||||
WWhhaatt ttrroouubbllee ttoo rreeppoorrtt ttoo tthhee ppoossttmmaasstteerr
|
||||
|
||||
You should set up a postmaster alias in the aliases(5) table that directs mail
|
||||
to a human person. The postmaster address is required to exist, so that people
|
||||
can report mail delivery problems. While you're updating the aliases(5) table,
|
||||
be sure to direct mail for the super-user to a human person too.
|
||||
|
||||
/etc/aliases:
|
||||
postmaster: you
|
||||
root: you
|
||||
|
||||
Execute the command "newaliases" after changing the aliases file. Instead of /
|
||||
etc/aliases, your alias file may be located elsewhere. Use the command
|
||||
"postconf alias_maps" to find out.
|
||||
|
||||
The Postfix system reports problems to the postmaster alias. You may not be
|
||||
interested in all types of trouble reports, so this reporting mechanism is
|
||||
configurable. The default is to report only serious problems (resource,
|
||||
software) to postmaster:
|
||||
|
||||
Default setting:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
notify_classes = resource, software
|
||||
|
||||
The meaning of the classes is as follows:
|
||||
|
||||
bounce
|
||||
Inform the postmaster of undeliverable mail. Either send the postmaster
|
||||
a copy of undeliverable mail that is returned to the sender, or send a
|
||||
transcript of the SMTP session when Postfix rejected mail. For privacy
|
||||
reasons, the postmaster copy of undeliverable mail is truncated after
|
||||
the original message headers. This implies "2bounce" (see below). See
|
||||
also the luser_relay feature. The notification is sent to the address
|
||||
specified with the bounce_notice_recipient configuration parameter
|
||||
(default: postmaster).
|
||||
2bounce
|
||||
When Postfix is unable to return undeliverable mail to the sender, send
|
||||
it to the postmaster instead (without truncating the message after the
|
||||
primary headers). The notification is sent to the address specified
|
||||
with the 2bounce_notice_recipient configuration parameter (default:
|
||||
postmaster).
|
||||
delay
|
||||
Inform the postmaster of delayed mail. In this case, the postmaster
|
||||
receives message headers only. The notification is sent to the address
|
||||
specified with the delay_notice_recipient configuration parameter
|
||||
(default: postmaster).
|
||||
policy
|
||||
Inform the postmaster of client requests that were rejected because of
|
||||
(UCE) policy restrictions. The postmaster receives a transcript of the
|
||||
SMTP session. The notification is sent to the address specified with
|
||||
the error_notice_recipient configuration parameter (default:
|
||||
postmaster).
|
||||
protocol
|
||||
Inform the postmaster of protocol errors (client or server side) or
|
||||
attempts by a client to execute unimplemented commands. The postmaster
|
||||
receives a transcript of the SMTP session. The notification is sent to
|
||||
the address specified with the error_notice_recipient configuration
|
||||
parameter (default: postmaster).
|
||||
resource
|
||||
Inform the postmaster of mail not delivered due to resource problems
|
||||
(for example, queue file write errors). The notification is sent to the
|
||||
address specified with the error_notice_recipient configuration
|
||||
parameter (default: postmaster).
|
||||
software
|
||||
Inform the postmaster of mail not delivered due to software problems.
|
||||
The notification is sent to the address specified with the
|
||||
error_notice_recipient configuration parameter (default: postmaster).
|
||||
|
||||
PPrrooxxyy//NNAATT eexxtteerrnnaall nneettwwoorrkk aaddddrreesssseess
|
||||
|
||||
Some mail servers are connected to the Internet via a network address
|
||||
translator (NAT) or proxy. This means that systems on the Internet connect to
|
||||
the address of the NAT or proxy, instead of connecting to the network address
|
||||
of the mail server. The NAT or proxy forwards the connection to the network
|
||||
address of the mail server, but Postfix does not know this.
|
||||
|
||||
If you run a Postfix server behind a proxy or NAT, you need to configure the
|
||||
proxy_interfaces parameter and specify all the external proxy or NAT addresses
|
||||
that Postfix receives mail on. You may specify symbolic hostnames instead of
|
||||
network addresses.
|
||||
|
||||
IMPORTANT: You must specify your proxy/NAT external addresses when your system
|
||||
is a backup MX host for other domains, otherwise mail delivery loops will
|
||||
happen when the primary MX host is down.
|
||||
|
||||
Example: host behind NAT box running a backup MX host.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
|
||||
|
||||
WWhhaatt yyoouu nneeeedd ttoo kknnooww aabboouutt PPoossttffiixx llooggggiinngg
|
||||
|
||||
Postfix daemon processes run in the background, and log problems and normal
|
||||
activity to the syslog daemon. The syslogd process sorts events by class and
|
||||
severity, and appends them to logfiles. The logging classes, levels and logfile
|
||||
names are usually specified in /etc/syslog.conf. At the very least you need
|
||||
something like:
|
||||
|
||||
/etc/syslog.conf:
|
||||
mail.err /dev/console
|
||||
mail.debug /var/log/maillog
|
||||
|
||||
After changing the syslog.conf file, send a "HUP" signal to the syslogd
|
||||
process.
|
||||
|
||||
IMPORTANT: many syslogd implementations will not create files. You must create
|
||||
files before (re)starting syslogd.
|
||||
|
||||
IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g.,
|
||||
-/var/log/maillog, otherwise the syslogd process will use more system resources
|
||||
than Postfix.
|
||||
|
||||
Hopefully, the number of problems will be small, but it is a good idea to run
|
||||
every night before the syslog files are rotated:
|
||||
|
||||
# postfix check
|
||||
# grep -E '(reject|warning|error|fatal|panic):' /some/log/file
|
||||
|
||||
* The first line (postfix check) causes Postfix to report file permission/
|
||||
ownership discrepancies.
|
||||
|
||||
* The second line looks for problem reports from the mail software, and
|
||||
reports how effective the relay and junk mail access blocks are. This may
|
||||
produce a lot of output. You will want to apply some postprocessing to
|
||||
eliminate uninteresting information.
|
||||
|
||||
The DEBUG_README document describes the meaning of the "warning" etc. labels in
|
||||
Postfix logging.
|
||||
|
||||
RRuunnnniinngg PPoossttffiixx ddaaeemmoonn pprroocceesssseess cchhrrooootteedd
|
||||
|
||||
Postfix daemon processes can be configured (via the master.cf file) to run in a
|
||||
chroot jail. The processes run at a fixed low privilege and with file system
|
||||
access limited to the Postfix queue directories (/var/spool/postfix). This
|
||||
provides a significant barrier against intrusion. The barrier is not
|
||||
impenetrable (chroot limits file system access only), but every little bit
|
||||
helps.
|
||||
|
||||
With the exception of Postfix daemons that deliver mail locally and/or that
|
||||
execute non-Postfix commands, every Postfix daemon can run chrooted.
|
||||
|
||||
Sites with high security requirements should consider to chroot all daemons
|
||||
that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also
|
||||
the lmtp(8) client. The author's own porcupine.org mail server runs all daemons
|
||||
chrooted that can be chrooted.
|
||||
|
||||
The default /etc/postfix/master.cf file specifies that no Postfix daemon runs
|
||||
chrooted. In order to enable chroot operation, edit the file /etc/postfix/
|
||||
master.cf, and follow instructions in the file. When you're finished, execute
|
||||
"postfix reload" to make the change effective.
|
||||
|
||||
Note that a chrooted daemon resolves all filenames relative to the Postfix
|
||||
queue directory (/var/spool/postfix). For successful use of a chroot jail, most
|
||||
UNIX systems require you to bring in some files or device nodes. The examples/
|
||||
chroot-setup directory in the source code distribution has a collection of
|
||||
scripts that help you set up Postfix chroot environments on different operating
|
||||
systems.
|
||||
|
||||
Additionally, you almost certainly need to configure syslogd so that it listens
|
||||
on a socket inside the Postfix queue directory. Examples of syslogd command
|
||||
line options that achieve this for specific systems:
|
||||
|
||||
FreeBSD: syslogd -l /var/spool/postfix/var/run/log
|
||||
|
||||
Linux, OpenBSD: syslogd -a /var/spool/postfix/dev/log
|
||||
|
||||
MMyy oowwnn hhoossttnnaammee
|
||||
|
||||
The myhostname parameter specifies the fully-qualified domain name of the
|
||||
machine running the Postfix system. $myhostname appears as the default value in
|
||||
many other Postfix configuration parameters.
|
||||
|
||||
By default, myhostname is set to the local machine name. If your local machine
|
||||
name is not in fully-qualified domain name form, or if you run Postfix on a
|
||||
virtual interface, you will have to specify the fully-qualified domain name
|
||||
that the mail system should use.
|
||||
|
||||
Alternatively, if you specify mydomain in main.cf, then Postfix will use its
|
||||
value to generate a fully-qualified default value for the myhostname parameter.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
myhostname = host.local.domain (machine name is not FQDN)
|
||||
myhostname = host.virtual.domain (virtual interface)
|
||||
myhostname = virtual.domain (virtual interface)
|
||||
|
||||
MMyy oowwnn ddoommaaiinn nnaammee
|
||||
|
||||
The mydomain parameter specifies the parent domain of $myhostname. By default,
|
||||
it is derived from $myhostname by stripping off the first part (unless the
|
||||
result would be a top-level domain).
|
||||
|
||||
Conversely, if you specify mydomain in main.cf, then Postfix will use its value
|
||||
to generate a fully-qualified default value for the myhostname parameter.
|
||||
|
||||
Examples (specify only one of the following):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mydomain = local.domain
|
||||
mydomain = virtual.domain (virtual interface)
|
||||
|
||||
MMyy oowwnn nneettwwoorrkk aaddddrreesssseess
|
||||
|
||||
The inet_interfaces parameter specifies all network interface addresses that
|
||||
the Postfix system should listen on; mail addressed to "user@[network address]"
|
||||
will be delivered locally, as if it is addressed to a domain listed in
|
||||
$mydestination.
|
||||
|
||||
You can override the inet_interfaces setting in the Postfix master.cf file by
|
||||
prepending an IP address to a server name.
|
||||
|
||||
The default is to listen on all active interfaces. If you run mailers on
|
||||
virtual interfaces, you will have to specify what interfaces to listen on.
|
||||
|
||||
IMPORTANT: If you run MTAs on virtual interfaces you must specify explicit
|
||||
inet_interfaces values for the MTA that receives mail for the machine itself:
|
||||
this MTA should never listen on the virtual interfaces or you would have a
|
||||
mailer loop when a virtual MTA is down.
|
||||
|
||||
Example: default setting.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
inet_interfaces = all
|
||||
|
||||
Example: host running one or more virtual mailers. For each Postfix instance,
|
||||
specify only one of the following.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
inet_interfaces = virtual.host.tld (virtual Postfix)
|
||||
inet_interfaces = $myhostname localhost... (non-virtual Postfix)
|
||||
|
||||
Note: you need to stop and start Postfix after changing this parameter.
|
||||
|
||||
124
README_FILES/BDAT_README
Normal file
124
README_FILES/BDAT_README
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
PPoossttffiixx BBDDAATT ((CCHHUUNNKKIINNGG)) ssuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
Postfix SMTP server supports RFC 3030 CHUNKING (the BDAT command) without
|
||||
BINARYMIME, in both smtpd(8) and postscreen(8). It is enabled by default.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Disabling BDAT support
|
||||
* Impact on existing configurations
|
||||
* Example SMTP session
|
||||
* Benefits of CHUNKING (BDAT) support without BINARYMIME
|
||||
* Downsides of CHUNKING (BDAT) support
|
||||
|
||||
DDiissaabblliinngg BBDDAATT ssuuppppoorrtt
|
||||
|
||||
BDAT support is enabled by default. To disable BDAT support globally:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# The logging alternative:
|
||||
smtpd_discard_ehlo_keywords = chunking
|
||||
# The non-logging alternative:
|
||||
smtpd_discard_ehlo_keywords = chunking, silent-discard
|
||||
|
||||
Specify '-o smtpd_discard_ehlo_keywords=' in master.cf for the submission and
|
||||
smtps services, if you have clients that benefit from CHUNKING support.
|
||||
|
||||
IImmppaacctt oonn eexxiissttiinngg ccoonnffiigguurraattiioonnss
|
||||
|
||||
* There are no changes for smtpd_mumble_restrictions, smtpd_proxy_filter,
|
||||
smtpd_milters, or for postscreen settings, except for the above mentioned
|
||||
option to suppress the SMTP server's CHUNKING service announcement.
|
||||
|
||||
* There are no changes in the Postfix queue file content, no changes for
|
||||
down-stream SMTP servers or after-queue content filters, and no changes in
|
||||
the envelope or message content that Milters will receive.
|
||||
|
||||
EExxaammppllee SSMMTTPP sseessssiioonn
|
||||
|
||||
The main differences are that the Postfix SMTP server announces "CHUNKING"
|
||||
support in the EHLO response, and that instead of sending one DATA request, the
|
||||
remote SMTP client may send one or more BDAT requests. In the example below,
|
||||
"S:" indicates server responses, and "C:" indicates client requests (bold
|
||||
font).
|
||||
|
||||
S: 220 server.example.com
|
||||
C: EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
|
||||
S: 250-server.example.com
|
||||
S: 250-PIPELINING
|
||||
S: 250-SIZE 153600000
|
||||
S: 250-VRFY
|
||||
S: 250-ETRN
|
||||
S: 250-STARTTLS
|
||||
S: 250-AUTH PLAIN LOGIN
|
||||
S: 250-ENHANCEDSTATUSCODES
|
||||
S: 250-8BITMIME
|
||||
S: 250-DSN
|
||||
S: 250-SMTPUTF8
|
||||
S: 250 CHUNKING
|
||||
C: MMAAIILL FFRROOMM::<<sseennddeerr@@eexxaammppllee..ccoomm>>
|
||||
S: 250 2.1.0 Ok
|
||||
C: RRCCPPTT TTOO::<<rreecciippiieenntt@@eexxaammppllee..ccoomm>>
|
||||
S: 250 2.1.5 Ok
|
||||
C: BBDDAATT 1100000000
|
||||
C: ....ffoolllloowweedd bbyy 1100000000 bbyytteess......
|
||||
S: 250 2.0.0 Ok: 10000 bytes
|
||||
C: BBDDAATT 112233
|
||||
C: ....ffoolllloowweedd bbyy 112233 bbyytteess......
|
||||
S: 250 2.0.0 Ok: 123 bytes
|
||||
C: BBDDAATT 00 LLAASSTT
|
||||
S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
|
||||
C: QQUUIITT
|
||||
S: 221 2.0.0 Bye
|
||||
|
||||
Internally in Postfix, there is no difference between mail that was received
|
||||
with BDAT or with DATA. Postfix smtpd_mumble_restrictions, policy delegation
|
||||
queries, smtpd_proxy_filter and Milters all behave as if Postfix received (MAIL
|
||||
+ RCPT + DATA + end-of-data). However, Postfix will log BDAT-related failures
|
||||
as "xxx after BDAT" to avoid complicating troubleshooting (xxx = 'lost
|
||||
connection' or 'timeout'), and will log a warning when a client sends a
|
||||
malformed BDAT command.
|
||||
|
||||
BBeenneeffiittss ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt wwiitthhoouutt BBIINNAARRYYMMIIMMEE
|
||||
|
||||
Support for CHUNKING (BDAT) was added to improve interoperability with some
|
||||
clients, a benefit that would reportedly exist even without Postfix support for
|
||||
BINARYMIME. Since June 2018, Wietse's mail server has received BDAT commands
|
||||
from a variety of systems.
|
||||
|
||||
Postfix does not support BINARYMIME at this time because:
|
||||
|
||||
* BINARYMIME support would require moderately invasive changes to Postfix, to
|
||||
support email content that is not line-oriented. With BINARYMIME, the
|
||||
Content-Length: message header specifies the length of content that may or
|
||||
may not have line boundaries. Without BINARYMIME support, email RFCs
|
||||
require that binary content is base64-encoded, and formatted as lines of
|
||||
text.
|
||||
|
||||
* For delivery to non-BINARYMIME systems including UNIX mbox, the available
|
||||
options are to convert binary content into 8bit text, one of the 7bit forms
|
||||
(base64 or quoted-printable), or to return email as undeliverable. Any
|
||||
conversion would obviously break digital signatures, so conversion would
|
||||
have to happen before signing.
|
||||
|
||||
DDoowwnnssiiddeess ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt
|
||||
|
||||
The RFC 3030 authors did not specify any limitations on how clients may
|
||||
pipeline commands (i.e. send commands without waiting for a server response).
|
||||
If a server announces PIPELINING support, like Postfix does, then a remote SMTP
|
||||
client can pipeline all commands following EHLO, for example, MAIL/RCPT/BDAT/
|
||||
BDAT/MAIL/RCPT/BDAT, without ever having to wait for a server response. This
|
||||
means that with BDAT, the Postfix SMTP server cannot distinguish between a
|
||||
well-behaved client and a spambot, based on their command pipelining behavior.
|
||||
If you require "reject_unauth_pipelining" to block spambots, then turn off
|
||||
Postfix's CHUNKING announcement as described above.
|
||||
|
||||
In RFC 4468, the authors write that a client may pipeline commands, and that
|
||||
after sending BURL LAST or BDAT LAST, a client must wait for the server's
|
||||
response. But as this text does not appear in RFC 3030 which defines BDAT, it
|
||||
is a useless restriction that Postfix will not enforce.
|
||||
|
||||
321
README_FILES/BUILTIN_FILTER_README
Normal file
321
README_FILES/BUILTIN_FILTER_README
Normal file
|
|
@ -0,0 +1,321 @@
|
|||
PPoossttffiixx BBuuiilltt--iinn CCoonntteenntt IInnssppeeccttiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
BBuuiilltt--iinn ccoonntteenntt iinnssppeeccttiioonn iinnttrroodduuccttiioonn
|
||||
|
||||
Postfix supports a built-in filter mechanism that examines message header and
|
||||
message body content, one line at a time, before it is stored in the Postfix
|
||||
queue. The filter is usually implemented with POSIX or PCRE regular
|
||||
expressions, as described in the header_checks(5) manual page.
|
||||
|
||||
The original purpose of the built-in filter is to stop an outbreak of specific
|
||||
email worms or viruses, and it does this job well. The filter has also helped
|
||||
to block bounced junk email, bounced email from worms or viruses, and
|
||||
notifications from virus detection systems. Information about this secondary
|
||||
application is given in the BACKSCATTER_README document.
|
||||
|
||||
Because the built-in filter is optimized for stopping specific worms and virus
|
||||
outbreaks, it has limitations that make it NOT suitable for general junk email
|
||||
and virus detection. For that, you should use one of the external content
|
||||
inspection methods that are described in the FILTER_README, SMTPD_PROXY_README
|
||||
and MILTER_README documents.
|
||||
|
||||
The following diagram gives an over-all picture of how Postfix built-in content
|
||||
inspection works:
|
||||
|
||||
Postmaster
|
||||
notifications
|
||||
|
||||
|
|
||||
v
|
||||
|
||||
Network or -> BBuuiilltt--iinn -> Postfix -> Delivery -> Network or
|
||||
local users ffiilltteerr queue agents local mailbox
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
Undeliverable mail
|
||||
Forwarded mail
|
||||
|
||||
The picture makes clear that the filter works while Postfix is receiving new
|
||||
mail. This means that Postfix can reject mail from the network without having
|
||||
to return undeliverable mail to the originator address (which is often spoofed
|
||||
anyway). However, this ability comes at a price: if mail inspection takes too
|
||||
much time, then the remote client will time out, and the client may send the
|
||||
same message repeatedly.
|
||||
|
||||
Topics covered by this document:
|
||||
|
||||
* What mail is subjected to header/body checks
|
||||
* Limitations of Postfix header/body checks
|
||||
* Preventing daily mail status reports from being blocked
|
||||
* Configuring header/body checks for mail from outside users only
|
||||
* Configuring different header/body checks for MX service and submission
|
||||
service
|
||||
* Configuring header/body checks for mail to some domains only
|
||||
|
||||
WWhhaatt mmaaiill iiss ssuubbjjeecctteedd ttoo hheeaaddeerr//bbooddyy cchheecckkss
|
||||
|
||||
Postfix header/body checks are implemented by the cleanup(8) server before it
|
||||
injects mail into the incoming queue. The diagram below zooms in on the cleanup
|
||||
(8) server, and shows that this server handles mail from many different
|
||||
sources. In order to keep the diagram readable, the sources of postmaster
|
||||
notifications are not shown, because they can be produced by many Postfix
|
||||
daemon processes.
|
||||
|
||||
bounce(8)
|
||||
(undeliverable)
|
||||
|
||||
ssmmttppdd((88)) |
|
||||
((nneettwwoorrkk)) \ v
|
||||
|
||||
qqmmqqppdd((88)) -\ cleanup(8) -> incoming
|
||||
((nneettwwoorrkk)) -/ queue
|
||||
|
||||
ppiicckkuupp((88)) / ^
|
||||
((llooccaall)) |
|
||||
|
||||
local(8)
|
||||
(forwarded)
|
||||
|
||||
For efficiency reasons, only mail that enters from outside of Postfix is
|
||||
inspected with header/body checks. It would be inefficient to filter already
|
||||
filtered mail again, and it would be undesirable to block postmaster
|
||||
notifications. The table below summarizes what mail is and is not subject to
|
||||
header/body checks.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|MMeessssaaggee ttyyppee |SSoouurrccee |HHeeaaddeerr//bbooddyy cchheecckkss??|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Undeliverable mail|bounce(8)|No |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Network mail |smtpd(8) |Configurable |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Network mail |qmqpd(8) |Configurable |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local submission |pickup(8)|Configurable |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Local forwarding |local(8) |No |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Postmaster notice |many |No |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
How does Postfix decide what mail needs to be filtered? It would be clumsy to
|
||||
make the decision in the cleanup(8) server, as this program receives mail from
|
||||
so many different sources. Instead, header/body checks are requested by the
|
||||
source. Examples of how to turn off header/body checks for mail received with
|
||||
smtpd(8), qmqpd(8) or pickup(8) are given below under "Configuring header/body
|
||||
checks for mail from outside users only", "Configuring different header/body
|
||||
checks for MX service and submission service", and "Configuring header/body
|
||||
checks for mail to some domains only".
|
||||
|
||||
LLiimmiittaattiioonnss ooff PPoossttffiixx hheeaaddeerr//bbooddyy cchheecckkss
|
||||
|
||||
* Header/body checks do not decode message headers or message body content.
|
||||
For example, if text in the message body is BASE64 encoded (RFC 2045) then
|
||||
your regular expressions will have to match the BASE64 encoded form.
|
||||
Likewise, message headers with encoded non-ASCII characters (RFC 2047) need
|
||||
to be matched in their encoded form.
|
||||
|
||||
* Header/body checks cannot filter on a combination of message headers or
|
||||
body lines. Header/body checks examine content one message header at a
|
||||
time, or one message body line at a time, and cannot carry a decision over
|
||||
to the next message header or body line.
|
||||
|
||||
* Header/body checks cannot depend on the recipient of a message.
|
||||
|
||||
o One message can have multiple recipients, and all recipients of a
|
||||
message receive the same treatment. Workarounds have been proposed that
|
||||
involve selectively deferring some recipients of multi-recipient mail,
|
||||
but that results in poor SMTP performance and does not work for non-
|
||||
SMTP mail.
|
||||
|
||||
o Some sources of mail send the headers and content ahead of the
|
||||
recipient information. It would be inefficient to buffer up an entire
|
||||
message before deciding if it needs to be filtered, and it would be
|
||||
clumsy to filter mail and to buffer up all the actions until it is
|
||||
known whether those actions need to be executed.
|
||||
|
||||
* Despite warnings, some people try to use the built-in filter feature for
|
||||
general junk email and/or virus blocking, using hundreds or even thousands
|
||||
of regular expressions. This can result in catastrophic performance
|
||||
failure. The symptoms are as follows:
|
||||
|
||||
o The cleanup(8) processes use up all available CPU time in order to
|
||||
process the regular expressions, and/or they use up all available
|
||||
memory so that the system begins to swap. This slows down all incoming
|
||||
mail deliveries.
|
||||
|
||||
o As Postfix needs more and more time to receive an email message, the
|
||||
number of simultaneous SMTP sessions increases to the point that the
|
||||
SMTP server process limit is reached.
|
||||
|
||||
o While all SMTP server processes are waiting for the cleanup(8) servers
|
||||
to finish, new SMTP clients have to wait until an SMTP server process
|
||||
becomes available. This causes mail deliveries to time out before they
|
||||
have even begun.
|
||||
|
||||
The remedy for this type of performance problem is simple: don't use
|
||||
header/body checks for general junk email and/or virus blocking, and don't
|
||||
filter mail before it is queued. When performance is a concern, use an
|
||||
external content filter that runs after mail is queued, as described in the
|
||||
FILTER_README document.
|
||||
|
||||
PPrreevveennttiinngg ddaaiillyy mmaaiill ssttaattuuss rreeppoorrttss ffrroomm bbeeiinngg bblloocckkeedd
|
||||
|
||||
The following is quoted from Jim Seymour's Pflogsumm FAQ at https://
|
||||
jimsun.linxnet.com/downloads/pflogsumm-faq.txt. Pflogsumm is a program that
|
||||
analyzes Postfix logs, including the logging from rejected mail. If these logs
|
||||
contain text that was rejected by Postfix body_checks patterns, then the
|
||||
logging is also likely to be rejected by those same body_checks patterns. This
|
||||
problem does not exist with header_checks patterns, because those are not
|
||||
applied to the text that is part of the mail status report.
|
||||
|
||||
You configure Postfix to do body checks, Postfix does its thing, Pflogsumm
|
||||
reports it and Postfix catches the same string in the Pflogsumm report.
|
||||
There are several solutions to this.
|
||||
|
||||
Wolfgang Zeikat contributed this:
|
||||
|
||||
#!/usr/bin/perl
|
||||
use MIME::Lite;
|
||||
|
||||
### Create a new message:
|
||||
$msg = MIME::Lite->new(
|
||||
From => 'your@send.er',
|
||||
To => 'your@recipie.nt',
|
||||
# Cc => 'some@other.com, some@more.com',
|
||||
Subject => 'pflogsumm',
|
||||
Date => `date`,
|
||||
Type => 'text/plain',
|
||||
Encoding => 'base64',
|
||||
Path => '/tmp/pflogg',
|
||||
);
|
||||
|
||||
$msg->send;
|
||||
|
||||
Where "/tmp/pflogg" is the output of Pflogsumm. This puts Pflogsumm's
|
||||
output in a base64 MIME attachment.
|
||||
|
||||
Note by Wietse: if you run this on a machine that is accessible by untrusted
|
||||
users, it is safer to store the Pflogsumm report in a directory that is not
|
||||
world writable.
|
||||
|
||||
In a follow-up to a thread in the postfix-users mailing list, Ralf
|
||||
Hildebrandt noted:
|
||||
|
||||
"mpack does the same thing."
|
||||
|
||||
And it does. Which tool one should use is a matter of preference.
|
||||
|
||||
Other solutions involve additional body_checks rules that make exceptions for
|
||||
daily mail status reports, but this is not recommended. Such rules slow down
|
||||
all mail and complicate Postfix maintenance.
|
||||
|
||||
CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
|
||||
|
||||
The following information applies to Postfix 2.1 and later. Earlier Postfix
|
||||
versions do not support the receive_override_options feature.
|
||||
|
||||
The easiest approach is to configure ONE Postfix instance with multiple SMTP
|
||||
server IP addresses in master.cf:
|
||||
|
||||
* Two SMTP server IP addresses for mail from inside users only, with header/
|
||||
body filtering turned off, and a local mail pickup service with header/body
|
||||
filtering turned off.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# ==================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# ==================================================================
|
||||
1.2.3.4:smtp inet n - n - - smtpd
|
||||
-o receive_override_options=no_header_body_checks
|
||||
127.0.0.1:smtp inet n - n - - smtpd
|
||||
-o receive_override_options=no_header_body_checks
|
||||
pickup unix n - n 60 1 pickup
|
||||
-o receive_override_options=no_header_body_checks
|
||||
|
||||
* Add some firewall rule to prevent access to 1.2.3.4:smtp from the outside
|
||||
world.
|
||||
|
||||
* One SMTP server address for mail from outside users with header/body
|
||||
filtering turned on via main.cf.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# =================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =================================================================
|
||||
1.2.3.5:smtp inet n - n - - smtpd
|
||||
|
||||
CCoonnffiigguurriinngg ddiiffffeerreenntt hheeaaddeerr//bbooddyy cchheecckkss ffoorr MMXX sseerrvviiccee aanndd ssuubbmmiissssiioonn sseerrvviiccee
|
||||
|
||||
If authorized user submissions require different header/body checks than mail
|
||||
from remote MTAs, then this is possible as long as you have separate mail
|
||||
streams for authorized users and for MX service.
|
||||
|
||||
The example below assumes that authorized users connect to TCP port 587
|
||||
(submission) or 465 (smtps), and that remote MTAs connect to TCP port 25
|
||||
(smtp).
|
||||
|
||||
First, we define a few "user-defined" parameters that will override settings
|
||||
for the submission and smtps services.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
msa_cleanup_service_name = msa_cleanup
|
||||
msa_header_checks = pcre:/etc/postfix/msa_header_checks
|
||||
msa_body_checks = pcre:/etc/postfix/msa_body_checks
|
||||
|
||||
Next, we define msa_cleanup as a dedicated cleanup service that will be used
|
||||
only by the submission and smtps services. This service uses the header_checks
|
||||
and body_checks overrides that were defined above.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# =================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =================================================================
|
||||
smtp inet n - n - - smtpd
|
||||
msa_cleanup unix n - n - 0 cleanup
|
||||
-o header_checks=$msa_header_checks
|
||||
-o body_checks=$msa_body_checks
|
||||
submission inet n - n - - smtpd
|
||||
-o cleanup_service_name=$msa_cleanup_service_name
|
||||
-o syslog_name=postfix/submission
|
||||
...[see sample master.cf file for more]...
|
||||
smtps inet n - n - - smtpd
|
||||
-o cleanup_service_name=$msa_cleanup_service_name
|
||||
-o syslog_name=postfix/smtps
|
||||
-o smtpd_tls_wrappermode=yes
|
||||
...[see sample master.cf file for more]...
|
||||
|
||||
By keeping the "msa_xxx" parameter settings in main.cf, you keep your master.cf
|
||||
file simple, and you minimize the amount of duplication.
|
||||
|
||||
CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ttoo ssoommee ddoommaaiinnss oonnllyy
|
||||
|
||||
The following information applies to Postfix 2.1. Earlier Postfix versions do
|
||||
not support the receive_override_options feature.
|
||||
|
||||
If you are an MX service provider and want to enable header/body checks only
|
||||
for some domains, you can configure ONE Postfix instance with multiple SMTP
|
||||
server IP addresses in master.cf. Each address provides a different service.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# =================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =================================================================
|
||||
# SMTP service for domains with header/body checks turned on.
|
||||
1.2.3.4:smtp inet n - n - - smtpd
|
||||
|
||||
# SMTP service for domains with header/body checks turned off.
|
||||
1.2.3.5:smtp inet n - n - - smtpd
|
||||
-o receive_override_options=no_header_body_checks
|
||||
|
||||
Once this is set up you can configure MX records in the DNS that route each
|
||||
domain to the proper SMTP server instance.
|
||||
|
||||
83
README_FILES/CDB_README
Normal file
83
README_FILES/CDB_README
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
PPoossttffiixx CCDDBB HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
CDB (Constant DataBase) is an indexed file format designed by Daniel Bernstein.
|
||||
CDB is optimized exclusively for read access and guarantees that each record
|
||||
will be read in at most two disk accesses. This is achieved by forgoing support
|
||||
for incremental updates: no single-record inserts or deletes are supported. CDB
|
||||
databases can be modified only by rebuilding them completely from scratch,
|
||||
hence the "constant" qualifier in the name.
|
||||
|
||||
Postfix CDB databases are specified as "cdb:name", where name specifies the CDB
|
||||
file name without the ".cdb" suffix (another suffix, ".tmp", is used
|
||||
temporarily while a CDB file is under construction). CDB databases are
|
||||
maintained with the postmap(1) or postalias(1) command. The DATABASE_README
|
||||
document has general information about Postfix databases.
|
||||
|
||||
You can use "cdb:" tables wherever you can use read-only "hash", "btree" or
|
||||
"lmdb" tables with the following limitations:
|
||||
|
||||
* CDB databases cannot be larger than 4GB on LP64 and ILP32 systems, because
|
||||
the CDB library API uses unsigned integers for file offsets.
|
||||
|
||||
* The "ppoossttmmaapp --ii" (incremental record insertion) and "ppoossttmmaapp --dd"
|
||||
(incremental record deletion) command-line options are not available. For
|
||||
the same reason the "cdb:" map type cannot be used to for persistent
|
||||
caches, such as the address verification cache for the verify(8) service,
|
||||
the TLS session cache for the tlsmgr(8) service, or the dynamic allowlist
|
||||
for postscreen(8).
|
||||
|
||||
* The "sequence" operation ("ppoossttmmaapp --ss" or "ppoossttaalliiaass --ss") is available only
|
||||
wen Postfix is built with tinycdb by Michael Tokarev, not with the original
|
||||
cdb library by Daniel Bernstein.
|
||||
|
||||
CDB support is available with Postfix 2.2 and later releases. The remainder of
|
||||
this document describes how to build Postfix with CDB support.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh CCDDBB ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
Postfix is compatible with two CDB implementations:
|
||||
|
||||
* The original cdb library from Daniel Bernstein, available from https://
|
||||
cr.yp.to/cdb.html, and
|
||||
|
||||
* tinycdb (version 0.5 and later) from Michael Tokarev, available from https:
|
||||
//www.corpit.ru/mjt/tinycdb.html.
|
||||
|
||||
Tinycdb is preferred, since it is a bit faster, has additional useful
|
||||
functionality and is much simpler to use.
|
||||
|
||||
To build Postfix after you have installed tinycdb, use something like:
|
||||
|
||||
% make tidy
|
||||
% CDB=../../../tinycdb-0.5
|
||||
% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
|
||||
"AUXLIBS_CDB=$CDB/libcdb.a"
|
||||
% make
|
||||
|
||||
Alternatively, for the D.J.B. version of CDB:
|
||||
|
||||
% make tidy
|
||||
% CDB=../../../cdb-0.75
|
||||
% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
|
||||
"AUXLIBS_CDB=$CDB/cdb.a $CDB/alloc.a $CDB/buffer.a $CDB/unix.a $CDB/
|
||||
byte.a"
|
||||
% make
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_CDB. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded CDB database client, but only the new AUXLIBS_CDB variable supports
|
||||
building a dynamically-loaded or statically-loaded CDB database client.
|
||||
|
||||
Failure to use the AUXLIBS_CDB variable will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have CDB
|
||||
database library dependencies. And that was exactly what dynamic database
|
||||
client loading was meant to avoid.
|
||||
|
||||
399
README_FILES/COMPATIBILITY_README
Normal file
399
README_FILES/COMPATIBILITY_README
Normal file
|
|
@ -0,0 +1,399 @@
|
|||
PPoossttffiixx BBaacckkwwaarrddss--CCoommppaattiibbiilliittyy SSaaffeettyy NNeett
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
Postfix 3.0 introduces a safety net that runs Postfix programs with backwards-
|
||||
compatible default settings after an upgrade. The safety net will log a warning
|
||||
whenever a "new" default setting could have an negative effect on your mail
|
||||
flow.
|
||||
|
||||
This document provides information on the following topics:
|
||||
|
||||
* Detailed descriptions of Postfix backwards-compatibility warnings.
|
||||
|
||||
* What backwards-compatible settings you may have to make permanent in
|
||||
main.cf or master.cf.
|
||||
|
||||
* How to turn off Postfix backwards-compatibility warnings.
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
With backwards compatibility turned on, Postfix logs a message whenever a
|
||||
backwards-compatible default setting may be required for continuity of service.
|
||||
Based on this logging the system administrator can decide if any backwards-
|
||||
compatible settings need to be made permanent in main.cf or master.cf, before
|
||||
turning off the backwards-compatibility safety net as described at the end of
|
||||
this document.
|
||||
|
||||
Logged with compatibility_level < 1:
|
||||
|
||||
* Using backwards-compatible default setting append_dot_mydomain=yes
|
||||
|
||||
* Using backwards-compatible default setting chroot=y
|
||||
|
||||
* Using backwards-compatible default setting "smtpd_relay_restrictions =
|
||||
(empty)"
|
||||
|
||||
* Using backwards-compatible default setting smtputf8_enable=no
|
||||
|
||||
Logged with compatibility_level < 2:
|
||||
|
||||
* Using backwards-compatible default setting mynetworks_style=subnet
|
||||
|
||||
* Using backwards-compatible default setting relay_domains=$mydestination
|
||||
|
||||
Logged with compatibility_level < 3.6:
|
||||
|
||||
* Using backwards-compatible default setting smtpd_tls_fingerprint_digest=md5
|
||||
|
||||
* Using backwards-compatible default setting smtp_tls_fingerprint_digest=md5
|
||||
|
||||
* Using backwards-compatible default setting lmtp_tls_fingerprint_digest=md5
|
||||
|
||||
* Using backwards-compatible default setting
|
||||
smtpd_relay_before_recipient_restrictions=no
|
||||
|
||||
* Using backwards-compatible default setting respectful_logging=no
|
||||
|
||||
If such a message is logged in the context of a legitimate request, the system
|
||||
administrator should make the backwards-compatible setting permanent in main.cf
|
||||
or master.cf, as detailed in the sections that follow.
|
||||
|
||||
When no more backwards-compatible settings need to be made permanent, the
|
||||
system administrator should turn off the backwards-compatibility safety net as
|
||||
described at the end of this document.
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
|
||||
|
||||
The append_dot_mydomain default value has changed from "yes" to "no". This
|
||||
could result in unexpected non-delivery of email after Postfix is updated from
|
||||
an older version. The backwards-compatibility safety net is designed to prevent
|
||||
such surprises.
|
||||
|
||||
As long as the append_dot_mydomain parameter is left at its implicit default
|
||||
value, and the compatibility_level setting is less than 1, Postfix may log one
|
||||
of the following messages:
|
||||
|
||||
* Messages about missing "localhost" in mydestination or other address class:
|
||||
|
||||
postfix/trivial-rewrite[14777]: using backwards-compatible
|
||||
default setting append_dot_mydomain=yes to rewrite
|
||||
"localhost" to "localhost.example.com"; please add
|
||||
"localhost" to mydestination or other address class
|
||||
|
||||
If Postfix logs the above message, add "localhost" to mydestination (or
|
||||
virtual_alias_domains, virtual_mailbox_domains, or relay_domains) and
|
||||
execute the command "ppoossttffiixx rreellooaadd".
|
||||
|
||||
* Messages about incomplete domains in email addresses:
|
||||
|
||||
postfix/trivial-rewrite[25835]: using backwards-compatible
|
||||
default setting append_dot_mydomain=yes to rewrite "foo" to
|
||||
"foo.example.com"
|
||||
|
||||
If Postfix logs the above message for domains different from "localhost",
|
||||
and the sender cannot be changed to use complete domain names in email
|
||||
addresses, then the system administrator should make the backwards-
|
||||
compatible setting "append_dot_mydomain = yes" permanent in main.cf:
|
||||
|
||||
# ppoossttccoonnff aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg cchhrroooott==yy
|
||||
|
||||
The master.cf chroot default value has changed from "y" (yes) to "n" (no). The
|
||||
new default avoids the need for copies of system files under the Postfix queue
|
||||
directory. However, sites with strict security requirements may want to keep
|
||||
the chroot feature enabled after updating Postfix from an older version. The
|
||||
backwards-compatibility safety net is designed allow the administrator to
|
||||
choose if they want to keep the old behavior.
|
||||
|
||||
As long as a master.cf chroot field is left at its implicit default value, and
|
||||
the compatibility_level setting is less than 1, Postfix may log the following
|
||||
message while it reads the master.cf file:
|
||||
|
||||
postfix/master[27664]: /etc/postfix/master.cf: line 72: using
|
||||
backwards-compatible default setting chroot=y
|
||||
|
||||
If this service should remain chrooted, then the system administrator should
|
||||
make the backwards-compatible setting "chroot = y" permanent in master.cf. For
|
||||
example, to update the chroot setting for the "smtp inet" service:
|
||||
|
||||
# ppoossttccoonnff --FF ssmmttpp//iinneett//cchhrroooott==yy
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppdd__rreellaayy__rreessttrriiccttiioonnss == ((eemmppttyy))
|
||||
|
||||
The smtpd_relay_restrictions feature was introduced with Postfix version 2.10,
|
||||
as a safety mechanism for configuration errors in smtpd_recipient_restrictions
|
||||
that could make Postfix an open relay.
|
||||
|
||||
The smtpd_relay_restrictions implicit default setting forbids mail to remote
|
||||
destinations from clients that don't match permit_mynetworks or
|
||||
permit_sasl_authenticated. This could result in unexpected 'Relay access
|
||||
denied' errors after Postfix is updated from an older Postfix version. The
|
||||
backwards-compatibility safety net is designed to prevent such surprises.
|
||||
|
||||
When the compatibility_level less than 1, and the smtpd_relay_restrictions
|
||||
parameter is left at its implicit default setting, Postfix may log the
|
||||
following message:
|
||||
|
||||
postfix/smtpd[38463]: using backwards-compatible default setting
|
||||
"smtpd_relay_restrictions = (empty)" to avoid "Relay access
|
||||
denied" error for recipient "user@example.com" from client
|
||||
"host.example.net[10.0.0.2]"
|
||||
|
||||
If this request should not be blocked, then the system administrator should
|
||||
make the backwards-compatible setting "smtpd_relay_restrictions=" (i.e. empty)
|
||||
permanent in main.cf:
|
||||
|
||||
# ppoossttccoonnff ssmmttppdd__rreellaayy__rreessttrriiccttiioonnss==
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppuuttff88__eennaabbllee==nnoo
|
||||
|
||||
The smtputf8_enable default value has changed from "no" to "yes". With the new
|
||||
"yes" setting, the Postfix SMTP server rejects non-ASCII addresses from clients
|
||||
that don't request SMTPUTF8 support, after Postfix is updated from an older
|
||||
version. The backwards-compatibility safety net is designed to prevent such
|
||||
surprises.
|
||||
|
||||
As long as the smtputf8_enable parameter is left at its implicit default value,
|
||||
and the compatibility_level setting is less than 1, Postfix logs a warning each
|
||||
time an SMTP command uses a non-ASCII address localpart without requesting
|
||||
SMTPUTF8 support:
|
||||
|
||||
postfix/smtpd[27560]: using backwards-compatible default setting
|
||||
smtputf8_enable=no to accept non-ASCII sender address
|
||||
"??@example.org" from localhost[127.0.0.1]
|
||||
|
||||
postfix/smtpd[27560]: using backwards-compatible default setting
|
||||
smtputf8_enable=no to accept non-ASCII recipient address
|
||||
"??@example.com" from localhost[127.0.0.1]
|
||||
|
||||
If the address should not be rejected, and the client cannot be updated to use
|
||||
SMTPUTF8, then the system administrator should make the backwards-compatible
|
||||
setting "smtputf8_enable = no" permanent in main.cf:
|
||||
|
||||
# ppoossttccoonnff ssmmttppuuttff88__eennaabbllee==nnoo
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
|
||||
|
||||
The mynetworks_style default value has changed from "subnet" to "host". This
|
||||
parameter is used to implement the "permit_mynetworks" feature. The change
|
||||
could cause unexpected 'access denied' errors after Postfix is updated from an
|
||||
older version. The backwards-compatibility safety net is designed to prevent
|
||||
such surprises.
|
||||
|
||||
As long as the mynetworks and mynetworks_style parameters are left at their
|
||||
implicit default values, and the compatibility_level setting is less than 2,
|
||||
the Postfix SMTP server may log one of the following messages:
|
||||
|
||||
postfix/smtpd[17375]: using backwards-compatible default setting
|
||||
mynetworks_style=subnet to permit request from client
|
||||
"foo.example.com[10.1.1.1]"
|
||||
|
||||
postfix/postscreen[24982]: using backwards-compatible default
|
||||
setting mynetworks_style=subnet to permit request from client
|
||||
"10.1.1.1"
|
||||
|
||||
If the client request should not be rejected, then the system administrator
|
||||
should make the backwards-compatible setting "mynetworks_style = subnet"
|
||||
permanent in main.cf:
|
||||
|
||||
# ppoossttccoonnff mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn
|
||||
|
||||
The relay_domains default value has changed from "$mydestination" to the empty
|
||||
value. This could result in unexpected 'Relay access denied' errors or ETRN
|
||||
errors after Postfix is updated from an older version. The backwards-
|
||||
compatibility safety net is designed to prevent such surprises.
|
||||
|
||||
As long as the relay_domains parameter is left at its implicit default value,
|
||||
and the compatibility_level setting is less than 2, Postfix may log one of the
|
||||
following messages.
|
||||
|
||||
* Messages about accepting mail for a remote domain:
|
||||
|
||||
postfix/smtpd[19052]: using backwards-compatible default setting
|
||||
relay_domains=$mydestination to accept mail for domain
|
||||
"foo.example.com"
|
||||
|
||||
postfix/smtpd[19052]: using backwards-compatible default setting
|
||||
relay_domains=$mydestination to accept mail for address
|
||||
"user@foo.example.com"
|
||||
|
||||
* Messages about providing ETRN service for a remote domain:
|
||||
|
||||
postfix/smtpd[19138]: using backwards-compatible default setting
|
||||
relay_domains=$mydestination to flush mail for domain
|
||||
"bar.example.com"
|
||||
|
||||
postfix/smtp[13945]: using backwards-compatible default setting
|
||||
relay_domains=$mydestination to update fast-flush logfile for
|
||||
domain "bar.example.com"
|
||||
|
||||
If Postfix should continue to accept mail for that domain or continue to
|
||||
provide ETRN service for that domain, then the system administrator should make
|
||||
the backwards-compatible setting "relay_domains = $mydestination" permanent in
|
||||
main.cf:
|
||||
|
||||
# ppoossttccoonnff ''rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn''
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
Note: quotes are required as indicated above.
|
||||
|
||||
Instead of $mydestination, it may be better to specify an explicit list of
|
||||
domain names.
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppdd__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
|
||||
|
||||
The smtpd_tls_fingerprint_digest default value has changed from "md5" to
|
||||
"sha256". With the new "sha256" setting, the Postfix SMTP server avoids using
|
||||
the deprecated "md5" algorithm and computes a more secure digest of the client
|
||||
certificate.
|
||||
|
||||
If you're using the default "md5" setting, or even an explicit "sha1" (also
|
||||
deprecated) setting, you should consider switching to "sha256". This will
|
||||
require updating any associated lookup table keys with the "sha256" digests of
|
||||
the expected client certificate or public key.
|
||||
|
||||
As long as the smtpd_tls_fingerprint_digest parameter is left at its implicit
|
||||
default value, and the compatibility_level setting is less than 3.6, Postfix
|
||||
logs a warning each time a client certificate or public key fingerprint is
|
||||
(potentially) used for access control:
|
||||
|
||||
postfix/smtpd[27560]: using backwards-compatible default setting
|
||||
smtpd_tls_fingerprint_digest=md5 to compute certificate fingerprints
|
||||
|
||||
Since any client certificate fingerprints are passed in policy service lookups,
|
||||
and Postfix doesn't know whether the fingerprint will be used, the warning may
|
||||
also be logged when policy lookups are performed for connections that used a
|
||||
client certificate, even if the policy service does not in fact examine the
|
||||
client certificate. To reduce the noise somewhat, such warnings are issued at
|
||||
most once per smtpd(8) process instance.
|
||||
|
||||
If you prefer to stick with "md5", you can suppress the warnings by making that
|
||||
setting explicit. After addressing any other compatibility warnings, you can
|
||||
update your compatibility level.
|
||||
|
||||
# ppoossttccoonnff ssmmttppdd__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
|
||||
|
||||
The smtp_tls_fingerprint_digest and lmtp_tls_fingerprint_digest default values
|
||||
have changed from "md5" to "sha256". With the new "sha256" setting, the Postfix
|
||||
SMTP and LMTP client avoids using the deprecated "md5" algorithm and computes a
|
||||
more secure digest of the server certificate.
|
||||
|
||||
If you're using the default "md5" setting, or even an explicit "sha1" (also
|
||||
deprecated) setting, you should consider switching to "sha256". This will
|
||||
require updating any "fingerprint" security level policies in the TLS policy
|
||||
table to specify matching "sha256" digests of the expected server certificates
|
||||
or public keys.
|
||||
|
||||
As long as the smtp_tls_fingerprint_digest (or LMTP equivalent) parameter is
|
||||
left at its implicit default value, and the compatibility_level setting is less
|
||||
than 3.6, Postfix logs a warning each time the "fingerprint" security level is
|
||||
used to specify matching "md5" digests of trusted server certificates or public
|
||||
keys:
|
||||
|
||||
postfix/smtp[27560]: using backwards-compatible default setting
|
||||
smtp_tls_fingerprint_digest=md5 to compute certificate fingerprints
|
||||
|
||||
If you prefer to stick with "md5", you can suppress the warnings by making that
|
||||
setting explicit. After addressing any other compatibility warnings, you can
|
||||
update your compatibility level.
|
||||
|
||||
# ppoossttccoonnff ''ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt == mmdd55'' \\
|
||||
''llmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt == mmdd55''
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg
|
||||
ssmmttppdd__rreellaayy__bbeeffoorree__rreecciippiieenntt__rreessttrriiccttiioonnss==nnoo
|
||||
|
||||
The smtpd_relay_before_recipient_restrictions feature was introduced in Postfix
|
||||
version 3.6, to evaluate smtpd_relay_restrictions before
|
||||
smtpd_recipient_restrictions. Historically, smtpd_relay_restrictions was
|
||||
evaluated after smtpd_recipient_restrictions, contradicting documented
|
||||
behavior.
|
||||
|
||||
Background: smtpd_relay_restrictions is primarily designed to enforce a
|
||||
mail relaying policy, while smtpd_recipient_restrictions is primarily
|
||||
designed to enforce spam blocking policy. Both are evaluated while replying
|
||||
to the RCPT TO command, and both support the same features.
|
||||
|
||||
To maintain compatibility with earlier versions, Postfix will keep evaluating
|
||||
smtpd_recipient_restrictions before smtpd_relay_restrictions, as long as the
|
||||
compatibility_level is less than 3.6, and the
|
||||
smtpd_relay_before_recipient_restrictions parameter is left at its implicit
|
||||
default setting. As a reminder, Postfix may log the following message:
|
||||
|
||||
postfix/smtpd[54696]: using backwards-compatible default setting
|
||||
smtpd_relay_before_recipient_restrictions=no to reject recipient
|
||||
"user@example.com" from client "host.example.net[10.0.0.2]"
|
||||
|
||||
If Postfix should keep evaluating smtpd_recipient_restrictions before
|
||||
smtpd_relay_restrictions, then the system administrator should make the
|
||||
backwards-compatible setting "smtpd_relay_before_recipient_restrictions=no"
|
||||
permanent in main.cf:
|
||||
|
||||
# ppoossttccoonnff ssmmttppdd__rreellaayy__bbeeffoorree__rreecciippiieenntt__rreessttrriiccttiioonnss==nnoo
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg rreessppeeccttffuull__llooggggiinngg==nnoo
|
||||
|
||||
Postfix version 3.6 deprecates configuration parameter names and logging that
|
||||
suggest white is better than black. Instead it prefers 'allowlist, 'denylist',
|
||||
and variations of those words. While the renamed configuration parameters have
|
||||
backwards-compatible default values, the changes in logging could affect
|
||||
logfile analysis tools.
|
||||
|
||||
To avoid breaking existing logfile analysis tools, Postfix will keep logging
|
||||
the deprecated form, as long as the respectful_logging parameter is left at its
|
||||
implicit default value, and the compatibility_level setting is less than 3.6.
|
||||
As a reminder, Postfix may log the following when a remote SMTP client is
|
||||
allowlisted or denylisted:
|
||||
|
||||
postfix/postscreen[22642]: Using backwards-compatible default setting
|
||||
respectful_logging=no for client [address]:port
|
||||
|
||||
If Postfix should keep logging the deprecated form, then the system
|
||||
administrator should make the backwards-compatible setting "respectful_logging
|
||||
= no" permanent in main.cf.
|
||||
|
||||
# ppoossttccoonnff ""rreessppeeccttffuull__llooggggiinngg == nnoo""
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
TTuurrnniinngg ooffff tthhee bbaacckkwwaarrddss--ccoommppaattiibbiilliittyy ssaaffeettyy nneett
|
||||
|
||||
Backwards compatibility is turned off by updating the compatibility_level
|
||||
setting in main.cf.
|
||||
|
||||
# ppoossttccoonnff ccoommppaattiibbiilliittyy__lleevveell==NN
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
For N specify the number that is logged in your postfix(1) warning message:
|
||||
|
||||
warning: To disable backwards compatibility use "postconf
|
||||
compatibility_level=N" and "postfix reload"
|
||||
|
||||
Sites that don't care about backwards compatibility may set
|
||||
"compatibility_level = 9999" at their own risk.
|
||||
|
||||
Starting with Postfix version 3.6, the compatibility level in the above warning
|
||||
message is the Postfix version that introduced the last incompatible change.
|
||||
The level is formatted as major.minor.patch, where patch is usually omitted and
|
||||
defaults to zero. Earlier compatibility levels are 0, 1 and 2.
|
||||
|
||||
NOTE: Postfix 3.6 also introduces support for the "<level", "<=level", and
|
||||
other operators to compare compatibility levels. With the standard operators
|
||||
"<", "<=", etc., compatibility level "3.10" would be smaller than "3.9" which
|
||||
is undesirable.
|
||||
|
||||
234
README_FILES/CONNECTION_CACHE_README
Normal file
234
README_FILES/CONNECTION_CACHE_README
Normal file
|
|
@ -0,0 +1,234 @@
|
|||
PPoossttffiixx CCoonnnneeccttiioonn CCaacchhee
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document describes the Postfix connection cache implementation, which is
|
||||
available with Postfix version 2.2 and later.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* What SMTP connection caching can do for you
|
||||
* Connection cache implementation
|
||||
* Connection cache configuration
|
||||
* Connection cache safety mechanisms
|
||||
* Connection cache limitations
|
||||
* Connection cache statistics
|
||||
|
||||
WWhhaatt SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg ccaann ddoo ffoorr yyoouu
|
||||
|
||||
With SMTP connection caching, Postfix can deliver multiple messages over the
|
||||
same SMTP connection. By default, Postfix 2.2 reuses a plaintext SMTP
|
||||
connection automatically when a destination has high volume of mail in the
|
||||
active queue.
|
||||
|
||||
SMTP Connection caching is a performance feature. Whether or not it actually
|
||||
improves performance depends on the conditions:
|
||||
|
||||
* SMTP Connection caching can greatly improve performance when delivering
|
||||
mail to a destination with multiple mail servers, because it can help
|
||||
Postfix to skip over a non-responding server.
|
||||
|
||||
* SMTP Connection caching can also help with receivers that impose rate
|
||||
limits on new connections.
|
||||
|
||||
* Otherwise, the benefits of SMTP connection caching are minor: it eliminates
|
||||
the latency of the TCP handshake (SYN, SYN+ACK, ACK), plus the latency of
|
||||
the SMTP initial handshake (220 greeting, EHLO command, EHLO response).
|
||||
With TLS-encrypted connections, this can save an additional two roundtrips
|
||||
that would otherwise be needed to send STARTTLS and to resume a TLS
|
||||
session.
|
||||
|
||||
* SMTP Connection caching gives no gains with respect to SMTP session tear-
|
||||
down. The Postfix smtp(8) client normally does not wait for the server's
|
||||
reply to the QUIT command, and it never waits for the TCP final handshake
|
||||
to complete.
|
||||
|
||||
* SMTP Connection caching introduces some overhead: the client needs to send
|
||||
an RSET command to find out if a connection is still usable, before it can
|
||||
send the next MAIL FROM command. This introduces one additional round-trip
|
||||
delay.
|
||||
|
||||
For other potential issues with SMTP connection caching, see the discussion of
|
||||
limitations at the end of this document.
|
||||
|
||||
CCoonnnneeccttiioonn ccaacchhee iimmpplleemmeennttaattiioonn
|
||||
|
||||
For an overview of how Postfix delivers mail, see the Postfix architecture
|
||||
OVERVIEW document.
|
||||
|
||||
The Postfix connection cache is shared among Postfix mail delivering processes.
|
||||
This maximizes the opportunity to reuse an open connection. Some MTAs such as
|
||||
Sendmail have a non-shared connection cache. Here, a connection can be reused
|
||||
only by the mail delivering process that creates the connection. To get the
|
||||
same performance improvement as with a shared connection cache, non-shared
|
||||
connections need to be kept open for a longer time.
|
||||
|
||||
The scache(8) server, introduced with Postfix version 2.2, maintains the shared
|
||||
connection cache. With Postfix version 2.2, only the smtp(8) client has support
|
||||
to access this cache.
|
||||
|
||||
When SMTP connection caching is enabled (see next section), the smtp(8) client
|
||||
does not disconnect after a mail transaction, but gives the connection to the
|
||||
scache(8) server which keeps the connection open for a limited amount of time.
|
||||
|
||||
After handing over the open connection to the scache(8) server, the smtp(8)
|
||||
client continues with some other mail delivery request. Meanwhile, any smtp(8)
|
||||
client process can ask the scache(8) server for that cached connection and
|
||||
reuse it for mail delivery.
|
||||
|
||||
/-- smtp(8) --> Internet
|
||||
|
||||
qmgr(8)
|
||||
|
|
||||
\-- | smtp(8)
|
||||
|
|
||||
| ^
|
||||
v |
|
||||
|
||||
scache(8)
|
||||
|
||||
With TLS connection reuse (Postfix 3.4 and later), the Postfix smtp(8) client
|
||||
connects to a remote SMTP server and sends plaintext EHLO and STARTTLS
|
||||
commands, then inserts a tlsproxy(8) process into the connection as shown
|
||||
below.
|
||||
|
||||
After delivering mail, the smtp(8) client hands over the open smtp(8)-to-
|
||||
tlsproxy(8) connection to the scache(8) server, and continues with some other
|
||||
mail delivery request. Meanwhile, any smtp(8) client process can ask the scache
|
||||
(8) server for that cached connection and reuse it for mail delivery.
|
||||
|
||||
/-- smtp(8) --> tlsproxy(8) --> Internet
|
||||
|
||||
qmgr(8)
|
||||
|
|
||||
\-- | smtp(8)
|
||||
|
|
||||
| ^
|
||||
v |
|
||||
|
||||
scache(8)
|
||||
|
||||
The connection cache can be searched by destination domain name (the right-hand
|
||||
side of the recipient address) and by the IP address of the host at the other
|
||||
end of the connection. This allows Postfix to reuse a connection even when the
|
||||
remote host is a mail server for domains with different names.
|
||||
|
||||
CCoonnnneeccttiioonn ccaacchhee ccoonnffiigguurraattiioonn
|
||||
|
||||
The Postfix smtp(8) client supports two connection caching strategies:
|
||||
|
||||
* On-demand connection caching. This is enabled by default, and is controlled
|
||||
with the smtp_connection_cache_on_demand configuration parameter. When this
|
||||
feature is enabled, the Postfix smtp(8) client automatically saves a
|
||||
connection to the connection cache when a destination has a high volume of
|
||||
mail in the active queue.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_connection_cache_on_demand = yes
|
||||
|
||||
* Per-destination connection caching. This is enabled by explicitly listing
|
||||
specific destinations with the smtp_connection_cache_destinations
|
||||
configuration parameter. After completing delivery to a selected
|
||||
destination, the Postfix smtp(8) client always saves the connection to the
|
||||
connection cache.
|
||||
|
||||
Specify a comma or white space separated list of destinations or pseudo-
|
||||
destinations:
|
||||
|
||||
o if mail is sent without a relay host: a domain name (the right-hand
|
||||
side of an email address, without the [] around a numeric IP address),
|
||||
|
||||
o if mail is sent via a relay host: a relay host name (without the [] or
|
||||
non-default TCP port), as specified in main.cf or in the transport map,
|
||||
|
||||
o a /file/name with domain names and/or relay host names as defined
|
||||
above,
|
||||
|
||||
o a "type:table" with domain names and/or relay host names on the left-
|
||||
hand side. The right-hand side result from "type:table" lookups is
|
||||
ignored.
|
||||
|
||||
Examples:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_connection_cache_destinations = $relayhost
|
||||
smtp_connection_cache_destinations = hotmail.com, ...
|
||||
smtp_connection_cache_destinations = static:all (not recommended)
|
||||
|
||||
See Client-side TLS connection reuse to enable multiple deliveries over a
|
||||
TLS-encrypted connection (Postfix version 3.4 and later).
|
||||
|
||||
CCoonnnneeccttiioonn ccaacchhee ssaaffeettyy mmeecchhaanniissmmss
|
||||
|
||||
Connection caching must be used wisely. It is anti-social to keep an unused
|
||||
SMTP connection open for a significant amount of time, and it is unwise to send
|
||||
huge numbers of messages through the same connection. In order to avoid
|
||||
problems with SMTP connection caching, Postfix implements the following safety
|
||||
mechanisms:
|
||||
|
||||
* The Postfix scache(8) server keeps a connection open for only a limited
|
||||
time. The time limit is specified with the smtp_connection_cache_time_limit
|
||||
and with the connection_cache_ttl_limit configuration parameters. This
|
||||
prevents anti-social behavior.
|
||||
|
||||
* The Postfix smtp(8) client reuses a session for only a limited number of
|
||||
times. This avoids triggering bugs in implementations that do not correctly
|
||||
handle multiple deliveries per session.
|
||||
|
||||
As of Postfix 2.3 connection reuse is preferably limited with the
|
||||
smtp_connection_reuse_time_limit parameter. In addition, Postfix 2.11
|
||||
provides smtp_connection_reuse_count_limit to limit how many times a
|
||||
connection may be reused, but this feature is unsafe as it introduces a
|
||||
"fatal attractor" failure mode (when a destination has multiple inbound
|
||||
MTAs, the slowest inbound MTA will attract most connections from Postfix to
|
||||
that destination).
|
||||
|
||||
Postfix 2.3 logs the use count of multiply-used connections, as shown in
|
||||
the following example:
|
||||
|
||||
Nov 3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
|
||||
to=<wietse@test.example.com>, orig_to=<wietse@test>,
|
||||
relay=mail.example.com[1.2.3.4], ccoonnnn__uussee==22, delay=0.22,
|
||||
delays=0.04/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
|
||||
|
||||
* The connection cache explicitly labels each cached connection with
|
||||
destination domain and IP address information. A connection cache lookup
|
||||
succeeds only when the correct information is specified. This prevents mis-
|
||||
delivery of mail.
|
||||
|
||||
CCoonnnneeccttiioonn ccaacchhee lliimmiittaattiioonnss
|
||||
|
||||
Postfix SMTP connection caching conflicts with certain applications:
|
||||
|
||||
* With Postfix versions < 3.4, the Postfix shared connection cache cannot be
|
||||
used with TLS, because an open TLS connection can be reused only in the
|
||||
process that creates it. For this reason, the Postfix smtp(8) client
|
||||
historically always closed the connection after completing an attempt to
|
||||
deliver mail over TLS.
|
||||
|
||||
* Postfix connection caching currently does not support multiple SASL
|
||||
accounts per mail server. Specifically, Postfix connection caching assumes
|
||||
that a SASL credential is valid for all hostnames or domain names that
|
||||
deliver via the same mail server IP address and TCP port, and assumes that
|
||||
the SASL credential does not depend on the message originator.
|
||||
|
||||
CCoonnnneeccttiioonn ccaacchhee ssttaattiissttiiccss
|
||||
|
||||
The scache(8) connection cache server logs statistics about the peak cache size
|
||||
and the cache hit rates. This information is logged every
|
||||
connection_cache_status_update_time seconds, when the process terminates after
|
||||
the maximal idle time is exceeded, or when Postfix is reloaded.
|
||||
|
||||
* Hit rates for connection cache lookups by domain will tell you how useful
|
||||
connection caching is.
|
||||
|
||||
* Connection cache lookups by network address will always fail, unless you're
|
||||
sending mail to different domains that share the same MX hosts.
|
||||
|
||||
* No statistics are logged when no attempts are made to access the connection
|
||||
cache.
|
||||
|
||||
56
README_FILES/CONTENT_INSPECTION_README
Normal file
56
README_FILES/CONTENT_INSPECTION_README
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
PPoossttffiixx CCoonntteenntt IInnssppeeccttiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
Postfix supports three content inspection methods, ranging from light-weight
|
||||
one-line-at-a-time scanning before mail is queued, to heavy duty machinery that
|
||||
does sophisticated content analysis after mail is queued. Each approach serves
|
||||
a different purpose.
|
||||
|
||||
bbeeffoorree qquueeuuee,, bbuuiilltt--iinn,, lliigghhtt--wweeiigghhtt
|
||||
This method inspects mail BEFORE it is stored in the queue, and uses
|
||||
Postfix's built-in message header and message body inspection. Although the
|
||||
main purpose is to stop a specific flood of mail from worms or viruses, it
|
||||
is also useful to block a flood of bounced junk email and email
|
||||
notifications from virus detection systems. The built-in regular
|
||||
expressions are not meant to implement general SPAM and virus detection.
|
||||
For that, you should use one of the content inspection methods described
|
||||
below. Details are described in the BUILTIN_FILTER_README and
|
||||
BACKSCATTER_README documents.
|
||||
|
||||
aafftteerr qquueeuuee,, eexxtteerrnnaall,, hheeaavvyy--wweeiigghhtt
|
||||
This method inspects mail AFTER it is stored in the queue, and uses
|
||||
standard protocols such as SMTP or "pipe to command and wait for exit
|
||||
status". After-queue inspection allows you to use content filters of
|
||||
arbitrary complexity without causing timeouts while receiving mail, and
|
||||
without running out of memory resources under a peak load. Details of this
|
||||
approach are in the FILTER_README document.
|
||||
|
||||
bbeeffoorree qquueeuuee,, eexxtteerrnnaall,, mmeeddiiuumm--wweeiigghhtt
|
||||
The following two methods inspect mail BEFORE it is stored in the queue.
|
||||
|
||||
* The first method uses the SMTP protocol, and is described in the
|
||||
SMTPD_PROXY_README document. This approach is available with Postfix
|
||||
version 2.1 and later.
|
||||
|
||||
* The second method uses the Sendmail 8 Milter protocol, and is described
|
||||
in the MILTER_README document. This approach is available with Postfix
|
||||
version 2.3 and later.
|
||||
|
||||
Although these approaches appear to be attractive, they have some serious
|
||||
limitations that you need to be aware of. First, content inspection
|
||||
software must finish in a limited amount of time; if content inspection
|
||||
needs too much time then incoming mail deliveries will time out. Second,
|
||||
content inspection software must run in a limited amount of memory; if
|
||||
content inspection needs too much memory then software will crash under a
|
||||
peak load. Before-queue inspection limits the peak load that your system
|
||||
can handle, and limits the sophistication of the content filter that you
|
||||
can use.
|
||||
|
||||
The more sophisticated content filtering software is not built into Postfix for
|
||||
good reasons: writing an MTA requires different skills than writing a SPAM or
|
||||
virus killer. Postfix encourages the use of external filters and standard
|
||||
protocols because this allows you to choose the best MTA and the best content
|
||||
inspection software for your purpose. Information about external content
|
||||
inspection software can be found on the Postfix website at https://
|
||||
www.postfix.org/, and on the postfix-users@postfix.org mailing list.
|
||||
|
||||
328
README_FILES/DATABASE_README
Normal file
328
README_FILES/DATABASE_README
Normal file
|
|
@ -0,0 +1,328 @@
|
|||
PPoossttffiixx LLooookkuupp TTaabbllee OOvveerrvviieeww
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document covers the following topics:
|
||||
|
||||
* The Postfix lookup table model
|
||||
* Postfix lists versus tables
|
||||
* Preparing Postfix for LDAP or SQL lookups
|
||||
* Maintaining Postfix lookup table files
|
||||
* Updating Berkeley DB files safely
|
||||
* Postfix lookup table types
|
||||
|
||||
TThhee PPoossttffiixx llooookkuupp ttaabbllee mmooddeell
|
||||
|
||||
Postfix uses lookup tables to store and look up information for access control,
|
||||
address rewriting and even for content filtering. All Postfix lookup tables are
|
||||
specified as "type:table", where "type" is one of the database types described
|
||||
under "Postfix lookup table types" at the end of this document, and where
|
||||
"table" is the lookup table name. The Postfix documentation uses the terms
|
||||
"database" and "lookup table" for the same thing.
|
||||
|
||||
Examples of lookup tables that appear often in the Postfix documentation:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
alias_maps = hash:/etc/postfix/aliases (local aliasing)
|
||||
header_checks = regexp:/etc/postfix/header_checks (content filtering)
|
||||
transport_maps = hash:/etc/postfix/transport (routing table)
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual (virtual aliasing)
|
||||
|
||||
All Postfix lookup tables store information as (key, value) pairs. This
|
||||
interface may seem simplistic at first, but it turns out to be very powerful.
|
||||
The (key, value) query interface completely hides the complexities of LDAP or
|
||||
SQL from Postfix. This is a good example of connecting complex systems with
|
||||
simple interfaces.
|
||||
|
||||
Benefits of the Postfix (key, value) query interface:
|
||||
|
||||
* You can implement Postfix lookup tables first with local Berkeley DB files
|
||||
and then switch to LDAP or MySQL without any impact on the Postfix
|
||||
configuration itself, as described under "Preparing Postfix for LDAP or SQL
|
||||
lookups" below.
|
||||
* You can use Berkeley DB files with fixed lookup strings for simple address
|
||||
rewriting operations and you can use regular expression tables for the more
|
||||
complicated work. In other words, you don't have to put everything into the
|
||||
same table.
|
||||
|
||||
PPoossttffiixx lliissttss vveerrssuuss ttaabblleess
|
||||
|
||||
Most Postfix lookup tables are used to look up information. Examples are
|
||||
address rewriting (the lookup string is the old address, and the result is the
|
||||
new address) or access control (the lookup string is the client, sender or
|
||||
recipient, and the result is an action such as "reject").
|
||||
|
||||
With some tables, however, Postfix needs to know only if the lookup key exists.
|
||||
Any non-empty lookup result value may be used here: the lookup result is not
|
||||
used. Examples are the local_recipient_maps that determine what local
|
||||
recipients Postfix accepts in mail from the network, the mydestination
|
||||
parameter that specifies what domains Postfix delivers locally for, or the
|
||||
mynetworks parameter that specifies the IP addresses of trusted clients or
|
||||
client networks. Technically, these are lists, not tables. Despite the
|
||||
difference, Postfix lists are described here because they use the same
|
||||
underlying infrastructure as Postfix lookup tables.
|
||||
|
||||
PPrreeppaarriinngg PPoossttffiixx ffoorr LLDDAAPP oorr SSQQLL llooookkuuppss
|
||||
|
||||
LDAP and SQL are complex systems. Trying to set up both Postfix and LDAP or SQL
|
||||
at the same time is definitely not a good idea. You can save yourself a lot of
|
||||
time by implementing Postfix first with local files such as Berkeley DB. Local
|
||||
files have few surprises, and are easy to debug with the postmap(1) command:
|
||||
|
||||
% ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm hhaasshh:://eettcc//ppoossttffiixx//vviirrttuuaall
|
||||
|
||||
Once you have local files working properly you can follow the instructions in
|
||||
ldap_table(5), mysql_table(5), pgsql_table(5) or sqlite_table(5) and replace
|
||||
local file lookups with LDAP or SQL lookups. When you do this, you should use
|
||||
the postmap(1) command again, to verify that database lookups still produce the
|
||||
exact same results as local file lookup:
|
||||
|
||||
% ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm llddaapp:://eettcc//ppoossttffiixx//vviirrttuuaall..ccff
|
||||
|
||||
Be sure to exercise all the partial address or parent domain queries that are
|
||||
documented under "table search order" in the relevant manual page: access(5),
|
||||
canonical(5), virtual(5), transport(5), or under the relevant configuration
|
||||
parameter: mynetworks, relay_domains, parent_domain_matches_subdomains.
|
||||
|
||||
MMaaiinnttaaiinniinngg PPoossttffiixx llooookkuupp ttaabbllee ffiilleess
|
||||
|
||||
When you make changes to a database while the mail system is running, it would
|
||||
be desirable if Postfix avoids reading information while that information is
|
||||
being changed. It would also be nice if you can change a database without
|
||||
having to execute "postfix reload", in order to force Postfix to use the new
|
||||
information. Each time you do "postfix reload" Postfix loses a lot of
|
||||
performance.
|
||||
|
||||
* If you change a network database such as LDAP, NIS or SQL, there is no need
|
||||
to execute "postfix reload". The LDAP, NIS or SQL server takes care of
|
||||
read/write access conflicts and gives the new data to Postfix once that
|
||||
data is available.
|
||||
|
||||
* If you change a regexp:, pcre:, cidr: or texthash: file then Postfix may
|
||||
not pick up the file changes immediately. This is because a Postfix process
|
||||
reads the entire file into memory once and never examines the file again.
|
||||
|
||||
o If the file is used by a short-running process such as smtpd(8),
|
||||
cleanup(8) or local(8), there is no need to execute "postfix reload"
|
||||
after making a change.
|
||||
|
||||
o If the file is being used by a long-running process such as trivial-
|
||||
rewrite(8) on a busy server it may be necessary to execute "postfix
|
||||
reload".
|
||||
|
||||
* If you change a local file based database such as DBM or Berkeley DB, there
|
||||
is no need to execute "postfix reload". Postfix uses file locking to avoid
|
||||
read/write access conflicts, and whenever a Postfix daemon process notices
|
||||
that a file has changed it will terminate before handling the next client
|
||||
request, so that a new process can initialize with the new database.
|
||||
|
||||
UUppddaattiinngg BBeerrkkeelleeyy DDBB ffiilleess ssaaffeellyy
|
||||
|
||||
Postfix uses file locking to avoid access conflicts while updating Berkeley DB
|
||||
or other local database files. This used to be safe, but as Berkeley DB has
|
||||
evolved to use more aggressive caching, file locking may no longer be
|
||||
sufficient.
|
||||
|
||||
Furthermore, file locking would not prevent problems when the update fails
|
||||
because the disk is full or something else causes a database update to fail. In
|
||||
particular, commands such as postmap(1) or postalias(1) overwrite existing
|
||||
files. If the overwrite fails in the middle then you have no usable database,
|
||||
and Postfix will stop working. This is not an issue with the CDB database type
|
||||
available with Postfix 2.2 and later: CDB creates a new file, and renames the
|
||||
file upon successful completion.
|
||||
|
||||
With Berkeley DB and other "one file" databases, it is possible to add some
|
||||
extra robustness by using "mv" to REPLACE an existing database file instead of
|
||||
overwriting it:
|
||||
|
||||
# ppoossttmmaapp aacccceessss..iinn &&&& mmvv aacccceessss..iinn..ddbb aacccceessss..ddbb
|
||||
|
||||
This converts the input file "access.in" into the output file "access.in.db",
|
||||
and replaces the file "access.db" only when the postmap(1) command was
|
||||
successful. Of course typing such commands becomes boring quickly, and this is
|
||||
why people use "make" instead, as shown below. User input is shown in bold
|
||||
font.
|
||||
|
||||
# ccaatt MMaakkeeffiillee
|
||||
all: aliases.db access.db virtual.db ...etcetera...
|
||||
|
||||
# Note 1: commands are specified after a TAB character.
|
||||
# Note 2: use postalias(1) for local aliases, postmap(1) for the rest.
|
||||
aliases.db: aliases.in
|
||||
postalias aliases.in
|
||||
mv aliases.in.db aliases.db
|
||||
|
||||
access.db: access.in
|
||||
postmap access.in
|
||||
mv access.in.db access.db
|
||||
|
||||
virtual.db: virtual.in
|
||||
postmap virtual.in
|
||||
mv virtual.in.db virtual.db
|
||||
|
||||
...etcetera...
|
||||
# vvii aacccceessss..iinn
|
||||
...editing session not shown...
|
||||
# mmaakkee
|
||||
postmap access.in
|
||||
mv access.in.db access.db
|
||||
#
|
||||
|
||||
The "make" command updates only the files that have changed. In case of error,
|
||||
the "make" command will stop and will not invoke the "mv" command, so that
|
||||
Postfix will keep using the existing database file as if nothing happened.
|
||||
|
||||
PPoossttffiixx llooookkuupp ttaabbllee ttyyppeess
|
||||
|
||||
To find out what database types your Postfix system supports, use the "ppoossttccoonnff
|
||||
--mm" command. Here is a list of database types that are often supported:
|
||||
|
||||
bbttrreeee
|
||||
A sorted, balanced tree structure. This is available only on systems
|
||||
with support for Berkeley DB databases. Database files are created with
|
||||
the postmap(1) or postalias(1) command. The lookup table name as used
|
||||
in "btree:table" is the database file name without the ".db" suffix.
|
||||
ccddbb
|
||||
A read-optimized structure with no support for incremental updates.
|
||||
Database files are created with the postmap(1) or postalias(1) command.
|
||||
The lookup table name as used in "cdb:table" is the database file name
|
||||
without the ".cdb" suffix. This feature is available with Postfix 2.2
|
||||
and later.
|
||||
cciiddrr
|
||||
A table that associates values with Classless Inter-Domain Routing
|
||||
(CIDR) patterns. The table format is described in cidr_table(5).
|
||||
ddbbmm
|
||||
An indexed file type based on hashing. This is available only on
|
||||
systems with support for DBM databases. Public database files are
|
||||
created with the postmap(1) or postalias(1) command, and private
|
||||
databases are maintained by Postfix daemons. The lookup table name as
|
||||
used in "dbm:table" is the database file name without the ".dir" or
|
||||
".pag" suffix.
|
||||
eennvviirroonn
|
||||
The UNIX process environment array. The lookup key is the variable
|
||||
name. The lookup table name in "environ:table" is ignored.
|
||||
ffaaiill
|
||||
A table that reliably fails all requests. The lookup table name is used
|
||||
for logging only. This table exists to simplify Postfix error tests.
|
||||
hhaasshh
|
||||
An indexed file type based on hashing. This is available only on
|
||||
systems with support for Berkeley DB databases. Public database files
|
||||
are created with the postmap(1) or postalias(1) command, and private
|
||||
databases are maintained by Postfix daemons. The database name as used
|
||||
in "hash:table" is the database file name without the ".db" suffix.
|
||||
iinnlliinnee (read-only)
|
||||
A non-shared, in-memory lookup table. Example: "inline:{ key=value,
|
||||
{ key = text with whitespace or comma }}". Key-value pairs are
|
||||
separated by whitespace or comma; with a key-value pair inside "{}",
|
||||
whitespace is ignored after the opening "{", around the "=" between key
|
||||
and value, and before the closing "}". Inline tables eliminate the need
|
||||
to create a database file for just a few fixed elements. See also the
|
||||
static: map type.
|
||||
iinntteerrnnaall
|
||||
A non-shared, in-memory hash table. Its contents are lost when a
|
||||
process terminates.
|
||||
llmmddbb
|
||||
OpenLDAP LMDB database. This is available only on systems with support
|
||||
for LMDB databases. Public database files are created with the postmap
|
||||
(1) or postalias(1) command, and private databases are maintained by
|
||||
Postfix daemons. The database name as used in "lmdb:table" is the
|
||||
database file name without the ".lmdb" suffix. See lmdb_table(5) for
|
||||
details.
|
||||
llddaapp (read-only)
|
||||
LDAP database client. Configuration details are given in the ldap_table
|
||||
(5).
|
||||
mmeemmccaacchhee
|
||||
Memcache database client. Configuration details are given in
|
||||
memcache_table(5).
|
||||
mmoonnggooddbb (read-only)
|
||||
MongoDB database client. Configuration details are given in
|
||||
mongodb_table(5), with examples in MONGODB_README.
|
||||
mmyyssqqll (read-only)
|
||||
MySQL database client. Configuration details are given in mysql_table
|
||||
(5).
|
||||
nneettiinnffoo (read-only)
|
||||
Netinfo database client.
|
||||
nniiss (read-only)
|
||||
NIS database client.
|
||||
nniisspplluuss (read-only)
|
||||
NIS+ database client. Configuration details are given in nisplus_table
|
||||
(5).
|
||||
ppccrree (read-only)
|
||||
A lookup table based on Perl Compatible Regular Expressions. The file
|
||||
format is described in pcre_table(5). The lookup table name as used in
|
||||
"pcre:table" is the name of the regular expression file.
|
||||
ppiippeemmaapp (read-only)
|
||||
A pipeline of lookup tables. Example: "pipemap:{type1:name1, ...,
|
||||
typen:namen}". Each "pipemap:" query is given to the first table. Each
|
||||
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 pipeline produces no result. The first and last
|
||||
characters of the "pipemap:" table name must be "{" and "}". Within
|
||||
these, individual maps are separated with comma or whitespace.
|
||||
ppggssqqll (read-only)
|
||||
PostgreSQL database client. Configuration details are given in
|
||||
pgsql_table(5).
|
||||
pprrooxxyy
|
||||
Postfix proxymap(8) client for shared access to Postfix databases. The
|
||||
lookup table name syntax is "proxy:type:table".
|
||||
rraannddmmaapp (read-only)
|
||||
An in-memory table that performs random selection. Example: "randmap:
|
||||
{result1. ..., resultn}". Each table query returns a random choice from
|
||||
the specified results. The first and last characters of the "randmap:
|
||||
" table name must be "{" and "}". Within these, individual maps are
|
||||
separated with comma or whitespace. To give a specific result more
|
||||
weight, specify it multiple times.
|
||||
rreeggeexxpp (read-only)
|
||||
A lookup table based on regular expressions. The file format is
|
||||
described in regexp_table(5). The lookup table name as used in "regexp:
|
||||
table" is the name of the regular expression file.
|
||||
ssddbbmm
|
||||
An indexed file type based on hashing. This is available only on
|
||||
systems with support for SDBM databases. Public database files are
|
||||
created with the postmap(1) or postalias(1) command, and private
|
||||
databases are maintained by Postfix daemons. The lookup table name as
|
||||
used in "sdbm:table" is the database file name without the ".dir" or
|
||||
".pag" suffix.
|
||||
ssoocckkeettmmaapp (read-only)
|
||||
Sendmail-style socketmap client. The name of the table is either iinneett:
|
||||
host:port:name for a TCP/IP server, or uunniixx:pathname:name for a UNIX-
|
||||
domain server. See socketmap_table(5) for details.
|
||||
ssqqlliittee (read-only)
|
||||
SQLite database. Configuration details are given in sqlite_table(5).
|
||||
ssttaattiicc (read-only)
|
||||
A table that always returns its name as the lookup result. For example,
|
||||
"static:foobar" always returns the string "foobar" as lookup result.
|
||||
Specify "static:{ text with whitespace }" when the result contains
|
||||
whitespace; this form ignores whitespace after the opening "{" and
|
||||
before the closing "}". See also the inline: map type.
|
||||
ttccpp
|
||||
TCP/IP client. The protocol is described in tcp_table(5). The lookup
|
||||
table name is "tcp:host:port" where "host" specifies a symbolic
|
||||
hostname or a numeric IP address, and "port" specifies a symbolic
|
||||
service name or a numeric port number.
|
||||
tteexxtthhaasshh (read-only)
|
||||
A table that produces similar results as hash: files, except that you
|
||||
don't have to run the postmap(1) command before you can use the file,
|
||||
and that texthash: does not detect changes after the file is read. The
|
||||
lookup table name is "texthash:filename", where the file name is taken
|
||||
literally; no suffix is appended.
|
||||
uunniioonnmmaapp (read-only)
|
||||
A table that sends each query to multiple lookup tables and that
|
||||
concatenates all found results, separated by comma. The table name
|
||||
syntax is the same as for pipemap tables.
|
||||
uunniixx (read-only)
|
||||
A limited view of the UNIX authentication database. The following
|
||||
tables are implemented:
|
||||
uunniixx::ppaasssswwdd..bbyynnaammee
|
||||
The table is the UNIX password database. The key is a login name.
|
||||
The result is a password file entry in passwd(5) format.
|
||||
uunniixx::ggrroouupp..bbyynnaammee
|
||||
The table is the UNIX group database. The key is a group name. The
|
||||
result is a group file entry in group(5) format.
|
||||
|
||||
Other lookup table types may be available depending on how Postfix was built.
|
||||
With some Postfix distributions the list is dynamically extensible as support
|
||||
for lookup tables is dynamically linked into Postfix.
|
||||
|
||||
175
README_FILES/DB_README
Normal file
175
README_FILES/DB_README
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
PPoossttffiixx BBeerrkkeelleeyy DDBB HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix uses databases of various kinds to store and look up information.
|
||||
Postfix databases are specified as "type:name". Berkeley DB implements the
|
||||
Postfix database type "hash" and "btree". The name of a Postfix Berkeley DB
|
||||
database is the name of the database file without the ".db" suffix. Berkeley DB
|
||||
databases are maintained with the postmap(1) command.
|
||||
|
||||
Note: Berkeley DB version 4 is not supported by Postfix versions before 2.0.
|
||||
|
||||
This document describes:
|
||||
|
||||
1. How to build Postfix without Berkeley DB support even if the system comes
|
||||
with Berkeley DB.
|
||||
|
||||
2. How to build Postfix on systems that normally have no Berkeley DB library.
|
||||
|
||||
3. How to build Postfix on BSD or Linux systems with multiple Berkeley DB
|
||||
versions.
|
||||
|
||||
4. How to tweak performance.
|
||||
|
||||
5. Missing pthread library trouble.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthhoouutt BBeerrkkeelleeyy DDBB ssuuppppoorrtt eevveenn iiff tthhee ssyysstteemm ccoommeess wwiitthh
|
||||
BBeerrkkeelleeyy DDBB
|
||||
|
||||
Note: The following instructions apply to Postfix 2.9 and later.
|
||||
|
||||
Postfix will normally enable Berkeley DB support if the system is known to have
|
||||
it. To build Postfix without Berkeley DB support, build the makefiles as
|
||||
follows:
|
||||
|
||||
% make makefiles CCARGS="-DNO_DB"
|
||||
% make
|
||||
|
||||
This will disable support for "hash" and "btree" files.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx oonn ssyysstteemmss tthhaatt nnoorrmmaallllyy hhaavvee nnoo BBeerrkkeelleeyy DDBB lliibbrraarryy
|
||||
|
||||
Some UNIXes ship without Berkeley DB support; for historical reasons these use
|
||||
DBM files instead. A problem with DBM files is that they can store only limited
|
||||
amounts of data. To build Postfix with Berkeley DB support you need to download
|
||||
and install the source code from https://www.oracle.com/database/technologies/
|
||||
related/berkeleydb.html.
|
||||
|
||||
Warning: some Linux system libraries use Berkeley DB, as do some third-party
|
||||
libraries such as SASL. If you compile Postfix with a different Berkeley DB
|
||||
implementation, then every Postfix program will dump core because either the
|
||||
system library, the SASL library, or Postfix itself ends up using the wrong
|
||||
version.
|
||||
|
||||
The more recent Berkeley DB versions have a compile-time switch, "--with-
|
||||
uniquename", which renames the symbols so that multiple versions of Berkeley DB
|
||||
can co-exist in the same application. Although wasteful, this may be the only
|
||||
way to keep things from falling apart.
|
||||
|
||||
To build Postfix after you installed the Berkeley DB from source code, use
|
||||
something like:
|
||||
|
||||
% make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
|
||||
AUXLIBS="-L/usr/local/BerkeleyDB/lib -ldb"
|
||||
% make
|
||||
|
||||
If your Berkeley DB shared library is in a directory that the RUN-TIME linker
|
||||
does not know about, add a "-Wl,-R,/path/to/directory" option after "-ldb".
|
||||
|
||||
Solaris needs this:
|
||||
|
||||
% make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
|
||||
AUXLIBS="-R/usr/local/BerkeleyDB/lib -L/usr/local/BerkeleyDB/lib -ldb"
|
||||
% make
|
||||
|
||||
The exact pathnames depend on the Berkeley DB version, and on how it was
|
||||
installed.
|
||||
|
||||
Warning: the file format produced by Berkeley DB version 1 is not compatible
|
||||
with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
|
||||
switch between DB versions, then you may have to rebuild all your Postfix DB
|
||||
files.
|
||||
|
||||
Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
|
||||
compatibility mode. Doing so would break fcntl file locking.
|
||||
|
||||
Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
|
||||
need to use the same Berkeley DB version in Perl as in Postfix.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx oonn BBSSDD ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
|
||||
|
||||
Some BSD systems ship with multiple Berkeley DB implementations. Normally,
|
||||
Postfix builds with the default DB version that ships with the system.
|
||||
|
||||
To build Postfix on BSD systems with a non-default DB version, use a variant of
|
||||
the following commands:
|
||||
|
||||
% make makefiles CCARGS=-I/usr/include/db3 AUXLIBS=-ldb3
|
||||
% make
|
||||
|
||||
Warning: the file format produced by Berkeley DB version 1 is not compatible
|
||||
with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
|
||||
switch between DB versions, then you may have to rebuild all your Postfix DB
|
||||
files.
|
||||
|
||||
Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
|
||||
compatibility mode. Doing so would break fcntl file locking.
|
||||
|
||||
Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
|
||||
need to use the same Berkeley DB version in Perl as in Postfix.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx oonn LLiinnuuxx ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
|
||||
|
||||
Some Linux systems ship with multiple Berkeley DB implementations. Normally,
|
||||
Postfix builds with the default DB version that ships with the system.
|
||||
|
||||
Warning: some Linux system libraries use Berkeley DB. If you compile Postfix
|
||||
with a non-default Berkeley DB implementation, then every Postfix program will
|
||||
dump core because either the system library or Postfix itself ends up using the
|
||||
wrong version.
|
||||
|
||||
On Linux, you need to edit the makedefs script in order to specify a non-
|
||||
default DB library. The reason is that the location of the default db.h include
|
||||
file changes randomly between vendors and between versions, so that Postfix has
|
||||
to choose the file for you.
|
||||
|
||||
Warning: the file format produced by Berkeley DB version 1 is not compatible
|
||||
with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
|
||||
switch between DB versions, then you may have to rebuild all your Postfix DB
|
||||
files.
|
||||
|
||||
Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
|
||||
compatibility mode. Doing so would break fcntl file locking.
|
||||
|
||||
Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
|
||||
need to use the same Berkeley DB version in Perl as in Postfix.
|
||||
|
||||
TTwweeaakkiinngg ppeerrffoorrmmaannccee
|
||||
|
||||
Postfix provides two configuration parameters that control how much buffering
|
||||
memory Berkeley DB will use.
|
||||
|
||||
* berkeley_db_create_buffer_size (default: 16 MBytes per table). This setting
|
||||
is used by the commands that maintain Berkeley DB files: postalias(1) and
|
||||
postmap(1). For "hash" files, create performance degrades rapidly unless
|
||||
the memory pool is O(file size). For "btree" files, create performance is
|
||||
good with sorted input even for small memory pools, but with random input
|
||||
degrades rapidly unless the memory pool is O(file size).
|
||||
|
||||
* berkeley_db_read_buffer_size (default: 128 kBytes per table). This setting
|
||||
is used by all other Postfix programs. The buffer size is adequate for
|
||||
reading. If the cache is smaller than the table, random read performance is
|
||||
hardly cache size dependent, except with btree tables, where the cache size
|
||||
must be large enough to contain the entire path from the root node.
|
||||
Empirical evidence shows that 64 kBytes may be sufficient. We double the
|
||||
size to play safe, and to anticipate changes in implementation and bloat.
|
||||
|
||||
MMiissssiinngg pptthhrreeaadd lliibbrraarryy ttrroouubbllee
|
||||
|
||||
When building Postfix fails with:
|
||||
|
||||
undefined reference to `pthread_condattr_setpshared'
|
||||
undefined reference to `pthread_mutexattr_destroy'
|
||||
undefined reference to `pthread_mutexattr_init'
|
||||
undefined reference to `pthread_mutex_trylock'
|
||||
|
||||
Add the "-lpthread" library to the "make makefiles" command.
|
||||
|
||||
% make makefiles .... AUXLIBS="... -lpthread"
|
||||
|
||||
More information is available at https://www.oracle.com/database/technologies/
|
||||
related/berkeleydb.html.
|
||||
|
||||
402
README_FILES/DEBUG_README
Normal file
402
README_FILES/DEBUG_README
Normal file
|
|
@ -0,0 +1,402 @@
|
|||
PPoossttffiixx DDeebbuuggggiinngg HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document describes how to debug parts of the Postfix mail system when
|
||||
things do not work according to expectation. The methods vary from making
|
||||
Postfix log a lot of detail, to running some daemon processes under control of
|
||||
a call tracer or debugger.
|
||||
|
||||
The text assumes that the Postfix main.cf and master.cf configuration files are
|
||||
stored in directory /etc/postfix. You can use the command "ppoossttccoonnff
|
||||
ccoonnffiigg__ddiirreeccttoorryy" to find out the actual location of this directory on your
|
||||
machine.
|
||||
|
||||
Listed in order of increasing invasiveness, the debugging techniques are as
|
||||
follows:
|
||||
|
||||
* Look for obvious signs of trouble
|
||||
* Debugging Postfix from inside
|
||||
* Try turning off chroot operation in master.cf
|
||||
* Verbose logging for specific SMTP connections
|
||||
* Record the SMTP session with a network sniffer
|
||||
* Making Postfix daemon programs more verbose
|
||||
* Manually tracing a Postfix daemon process
|
||||
* Automatically tracing a Postfix daemon process
|
||||
* Running daemon programs with the interactive ddd debugger
|
||||
* Running daemon programs with the interactive gdb debugger
|
||||
* Running daemon programs under a non-interactive debugger
|
||||
* Unreasonable behavior
|
||||
* Reporting problems to postfix-users@postfix.org
|
||||
|
||||
LLooookk ffoorr oobbvviioouuss ssiiggnnss ooff ttrroouubbllee
|
||||
|
||||
Postfix logs all failed and successful deliveries to a logfile.
|
||||
|
||||
* When Postfix uses syslog logging (the default), the file is usually called
|
||||
/var/log/maillog, /var/log/mail, or something similar; the exact pathname
|
||||
is configured in a file called /etc/syslog.conf, /etc/rsyslog.conf, or
|
||||
something similar.
|
||||
|
||||
* When Postfix uses its own logging system (see MAILLOG_README), the location
|
||||
of the logfile is configured with the Postfix maillog_file parameter.
|
||||
|
||||
When Postfix does not receive or deliver mail, the first order of business is
|
||||
to look for errors that prevent Postfix from working properly:
|
||||
|
||||
% ggrreepp --EE ''((wwaarrnniinngg||eerrrroorr||ffaattaall||ppaanniicc))::'' //ssoommee//lloogg//ffiillee || mmoorree
|
||||
|
||||
Note: the most important message is near the BEGINNING of the output. Error
|
||||
messages that come later are less useful.
|
||||
|
||||
The nature of each problem is indicated as follows:
|
||||
|
||||
* "ppaanniicc" indicates a problem in the software itself that only a programmer
|
||||
can fix. Postfix cannot proceed until this is fixed.
|
||||
|
||||
* "ffaattaall" is the result of missing files, incorrect permissions, incorrect
|
||||
configuration file settings that you can fix. Postfix cannot proceed until
|
||||
this is fixed.
|
||||
|
||||
* "eerrrroorr" reports an error condition. For safety reasons, a Postfix process
|
||||
will terminate when more than 13 of these happen.
|
||||
|
||||
* "wwaarrnniinngg" indicates a non-fatal error. These are problems that you may not
|
||||
be able to fix (such as a broken DNS server elsewhere on the network) but
|
||||
may also indicate local configuration errors that could become a problem
|
||||
later.
|
||||
|
||||
DDeebbuuggggiinngg PPoossttffiixx ffrroomm iinnssiiddee
|
||||
|
||||
Postfix version 2.1 and later can produce mail delivery reports for debugging
|
||||
purposes. These reports not only show sender/recipient addresses after address
|
||||
rewriting and alias expansion or forwarding, they also show information about
|
||||
delivery to mailbox, delivery to non-Postfix command, responses from remote
|
||||
SMTP servers, and so on.
|
||||
|
||||
Postfix can produce two types of mail delivery reports for debugging:
|
||||
|
||||
* What-if: report what would happen, but do not actually deliver mail. This
|
||||
mode of operation is requested with:
|
||||
|
||||
% //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
|
||||
Mail Delivery Status Report will be mailed to <your login name>.
|
||||
|
||||
* What happened: deliver mail and report successes and/or failures, including
|
||||
replies from remote SMTP servers. This mode of operation is requested with:
|
||||
|
||||
% //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
|
||||
Mail Delivery Status Report will be mailed to <your login name>.
|
||||
|
||||
These reports contain information that is generated by Postfix delivery agents.
|
||||
Since these run as daemon processes that cannot interact with users directly,
|
||||
the result is sent as mail to the sender of the test message. The format of
|
||||
these reports is practically identical to that of ordinary non-delivery
|
||||
notifications.
|
||||
|
||||
For a detailed example of a mail delivery status report, see the debugging
|
||||
section at the end of the ADDRESS_REWRITING_README document.
|
||||
|
||||
TTrryy ttuurrnniinngg ooffff cchhrroooott ooppeerraattiioonn iinn mmaasstteerr..ccff
|
||||
|
||||
A common mistake is to turn on chroot operation in the master.cf file without
|
||||
going through all the necessary steps to set up a chroot environment. This
|
||||
causes Postfix daemon processes to fail due to all kinds of missing files.
|
||||
|
||||
The example below shows an SMTP server that is configured with chroot turned
|
||||
off:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv cchhrroooott wakeup maxproc command
|
||||
# (yes) (yes) ((yyeess)) (never) (100)
|
||||
# =============================================================
|
||||
smtp inet n - nn - - smtpd
|
||||
|
||||
Inspect master.cf for any processes that have chroot operation not turned off.
|
||||
If you find any, save a copy of the master.cf file, and edit the entries in
|
||||
question. After executing the command "ppoossttffiixx rreellooaadd", see if the problem has
|
||||
gone away.
|
||||
|
||||
If turning off chrooted operation made the problem go away, then
|
||||
congratulations. Leaving Postfix running in this way is adequate for most
|
||||
sites. If you prefer chrooted operation, see the Postfix
|
||||
BASIC_CONFIGURATION_README file for information about how to prepare Postfix
|
||||
for chrooted operation.
|
||||
|
||||
VVeerrbboossee llooggggiinngg ffoorr ssppeecciiffiicc SSMMTTPP ccoonnnneeccttiioonnss
|
||||
|
||||
In /etc/postfix/main.cf, list the remote site name or address in the
|
||||
debug_peer_list parameter. For example, in order to make the software log a lot
|
||||
of information to the syslog daemon for connections from or to the loopback
|
||||
interface:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
debug_peer_list = 127.0.0.1
|
||||
|
||||
You can specify one or more hosts, domains, addresses or net/masks. To make the
|
||||
change effective immediately, execute the command "ppoossttffiixx rreellooaadd".
|
||||
|
||||
RReeccoorrdd tthhee SSMMTTPP sseessssiioonn wwiitthh aa nneettwwoorrkk ssnniiffffeerr
|
||||
|
||||
This example uses ttccppdduummpp. In order to record a conversation you need to
|
||||
specify a large enough buffer with the "--ss" option or else you will miss some
|
||||
or all of the packet payload.
|
||||
|
||||
# ttccppdduummpp --ww //ffiillee//nnaammee --ss 00 hhoosstt eexxaammppllee..ccoomm aanndd ppoorrtt 2255
|
||||
|
||||
Older tcpdump versions don't support "--ss 00"; in that case, use "--ss 22000000"
|
||||
instead.
|
||||
|
||||
Run this for a while, stop with Ctrl-C when done. To view the data use a binary
|
||||
viewer, eetthheerreeaall, or good old lleessss.
|
||||
|
||||
MMaakkiinngg PPoossttffiixx ddaaeemmoonn pprrooggrraammss mmoorree vveerrbboossee
|
||||
|
||||
Append one or more "--vv" options to selected daemon definitions in /etc/postfix/
|
||||
master.cf and type "ppoossttffiixx rreellooaadd". This will cause a lot of activity to be
|
||||
logged to the syslog daemon. For example, to make the Postfix SMTP server
|
||||
process more verbose:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd -v
|
||||
|
||||
To diagnose problems with address rewriting specify a "--vv" option for the
|
||||
cleanup(8) and/or trivial-rewrite(8) daemon, and to diagnose problems with mail
|
||||
delivery specify a "--vv" option for the qmgr(8) or oqmgr(8) queue manager, or
|
||||
for the lmtp(8), local(8), pipe(8), smtp(8), or virtual(8) delivery agent.
|
||||
|
||||
MMaannuuaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
|
||||
|
||||
Many systems allow you to inspect a running process with a system call tracer.
|
||||
For example:
|
||||
|
||||
# ttrraaccee --pp pprroocceessss--iidd (SunOS 4)
|
||||
# ssttrraaccee --pp pprroocceessss--iidd (Linux and many others)
|
||||
# ttrruussss --pp pprroocceessss--iidd (Solaris, FreeBSD)
|
||||
# kkttrraaccee --pp pprroocceessss--iidd (generic 4.4BSD)
|
||||
|
||||
Even more informative are traces of system library calls. Examples:
|
||||
|
||||
# llttrraaccee --pp pprroocceessss--iidd (Linux, also ported to FreeBSD and BSD/OS)
|
||||
# ssoottrruussss --pp pprroocceessss--iidd (Solaris)
|
||||
|
||||
See your system documentation for details.
|
||||
|
||||
Tracing a running process can give valuable information about what a process is
|
||||
attempting to do. This is as much information as you can get without running an
|
||||
interactive debugger program, as described in a later section.
|
||||
|
||||
AAuuttoommaattiiccaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
|
||||
|
||||
Postfix can attach a call tracer whenever a daemon process starts. Call tracers
|
||||
come in several kinds.
|
||||
|
||||
1. System call tracers such as ttrraaccee, ttrruussss, ssttrraaccee, or kkttrraaccee. These show the
|
||||
communication between the process and the kernel.
|
||||
|
||||
2. Library call tracers such as ssoottrruussss and llttrraaccee. These show calls of
|
||||
library routines, and give a better idea of what is going on within the
|
||||
process.
|
||||
|
||||
Append a --DD option to the suspect command in /etc/postfix/master.cf, for
|
||||
example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd -D
|
||||
|
||||
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
|
||||
the call tracer of your choice, for example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
debugger_command =
|
||||
PATH=/bin:/usr/bin:/usr/local/bin;
|
||||
(truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
|
||||
|
||||
Type "ppoossttffiixx rreellooaadd" and watch the logfile.
|
||||
|
||||
RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee dddddd ddeebbuuggggeerr
|
||||
|
||||
If you have X Windows installed on the Postfix machine, then an interactive
|
||||
debugger such as dddddd can be convenient.
|
||||
|
||||
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
|
||||
dddddd:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
debugger_command =
|
||||
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
|
||||
ddd $daemon_directory/$process_name $process_id & sleep 5
|
||||
|
||||
Be sure that ggddbb is in the command search path, and export XXAAUUTTHHOORRIITTYY so that X
|
||||
access control works, for example:
|
||||
|
||||
% sseetteennvv XXAAUUTTHHOORRIITTYY ~~//..XXaauutthhoorriittyy (csh syntax)
|
||||
$ eexxppoorrtt XXAAUUTTHHOORRIITTYY==$$HHOOMMEE//..XXaauutthhoorriittyy (sh syntax)
|
||||
|
||||
Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
|
||||
for example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd -D
|
||||
|
||||
Stop and start the Postfix system. This is necessary so that Postfix runs with
|
||||
the proper XXAAUUTTHHOORRIITTYY and DDIISSPPLLAAYY settings.
|
||||
|
||||
Whenever the suspect daemon process is started, a debugger window pops up and
|
||||
you can watch in detail what happens.
|
||||
|
||||
RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee ggddbb ddeebbuuggggeerr
|
||||
|
||||
If you have the screen command installed on the Postfix machine, then you can
|
||||
run an interactive debugger such as ggddbb as follows.
|
||||
|
||||
Edit the debugger_command definition in /etc/postfix/main.cf so that it runs
|
||||
ggddbb inside a detached ssccrreeeenn session:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
debugger_command =
|
||||
PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; HOME=/root;
|
||||
export HOME; screen -e^tt -dmS $process_name gdb
|
||||
$daemon_directory/$process_name $process_id & sleep 2
|
||||
|
||||
Be sure that ggddbb is in the command search path.
|
||||
|
||||
Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
|
||||
for example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd -D
|
||||
|
||||
Execute the command "ppoossttffiixx rreellooaadd" and wait until a daemon process is started
|
||||
(you can see this in the maillog file).
|
||||
|
||||
Then attach to the screen, and debug away:
|
||||
|
||||
# HOME=/root screen -r
|
||||
gdb) continue
|
||||
gdb) where
|
||||
|
||||
RRuunnnniinngg ddaaeemmoonn pprrooggrraammss uunnddeerr aa nnoonn--iinntteerraaccttiivvee ddeebbuuggggeerr
|
||||
|
||||
If you do not have X Windows installed on the Postfix machine, or if you are
|
||||
not familiar with interactive debuggers, then you can try to run ggddbb in non-
|
||||
interactive mode, and have it print a stack trace when the process crashes.
|
||||
|
||||
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
|
||||
the ggddbb debugger:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
debugger_command =
|
||||
PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
|
||||
where; sleep 8640000) | gdb $daemon_directory/$process_name
|
||||
$process_id 2>&1
|
||||
>$config_directory/$process_name.$process_id.log & sleep 5
|
||||
|
||||
Append a --DD option to the suspect daemon in /etc/postfix/master.cf, for
|
||||
example:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd -D
|
||||
|
||||
Type "ppoossttffiixx rreellooaadd" to make the configuration changes effective.
|
||||
|
||||
Whenever a suspect daemon process is started, an output file is created, named
|
||||
after the daemon and process ID (for example, smtpd.12345.log). When the
|
||||
process crashes, a stack trace (with output from the "wwhheerree" command) is
|
||||
written to its logfile.
|
||||
|
||||
UUnnrreeaassoonnaabbllee bbeehhaavviioorr
|
||||
|
||||
Sometimes the behavior exhibited by Postfix just does not match the source
|
||||
code. Why can a program deviate from the instructions given by its author?
|
||||
There are two possibilities.
|
||||
|
||||
* The compiler has erred. This rarely happens.
|
||||
|
||||
* The hardware has erred. Does the machine have ECC memory?
|
||||
|
||||
In both cases, the program being executed is not the program that was supposed
|
||||
to be executed, so anything could happen.
|
||||
|
||||
There is a third possibility:
|
||||
|
||||
* Bugs in system software (kernel or libraries).
|
||||
|
||||
Hardware-related failures usually do not reproduce in exactly the same way
|
||||
after power cycling and rebooting the system. There's little Postfix can do
|
||||
about bad hardware. Be sure to use hardware that at the very least can detect
|
||||
memory errors. Otherwise, Postfix will just be waiting to be hit by a bit
|
||||
error. Critical systems deserve real hardware.
|
||||
|
||||
When a compiler makes an error, the problem can be reproduced whenever the
|
||||
resulting program is run. Compiler errors are most likely to happen in the code
|
||||
optimizer. If a problem is reproducible across power cycles and system reboots,
|
||||
it can be worthwhile to rebuild Postfix with optimization disabled, and to see
|
||||
if optimization makes a difference.
|
||||
|
||||
In order to compile Postfix with optimizations turned off:
|
||||
|
||||
% mmaakkee ttiiddyy
|
||||
% mmaakkee mmaakkeeffiilleess OOPPTT==
|
||||
|
||||
This produces a set of Makefiles that do not request compiler optimization.
|
||||
|
||||
Once the makefiles are set up, build the software:
|
||||
|
||||
% mmaakkee
|
||||
% ssuu
|
||||
Password:
|
||||
# mmaakkee iinnssttaallll
|
||||
|
||||
If the problem goes away, then it is time to ask your vendor for help.
|
||||
|
||||
RReeppoorrttiinngg pprroobblleemmss ttoo ppoossttffiixx--uusseerrss@@ppoossttffiixx..oorrgg
|
||||
|
||||
The people who participate on postfix-users@postfix.org are very helpful,
|
||||
especially if YOU provide them with sufficient information. Remember, these
|
||||
volunteers are willing to help, but their time is limited.
|
||||
|
||||
When reporting a problem, be sure to include the following information.
|
||||
|
||||
* A summary of the problem. Please do not just send some logging without
|
||||
explanation of what YOU believe is wrong.
|
||||
|
||||
* Complete error messages. Please use cut-and-paste, or use attachments,
|
||||
instead of reciting information from memory.
|
||||
|
||||
* Postfix logging. See the text at the top of the DEBUG_README document to
|
||||
find out where logging is stored. Please do not frustrate the helpers by
|
||||
word wrapping the logging. If the logging is more than a few kbytes of
|
||||
text, consider posting an URL on a web or ftp site.
|
||||
|
||||
* Consider using a test email address so that you don't have to reveal email
|
||||
addresses or passwords of innocent people.
|
||||
|
||||
* If you can't use a test email address, please anonymize email addresses and
|
||||
host names consistently. Replace each letter by "A", each digit by "D" so
|
||||
that the helpers can still recognize syntactical errors.
|
||||
|
||||
* Command output from:
|
||||
|
||||
o "ppoossttccoonnff --nn". Please do not send your main.cf file, or 1000+ lines of
|
||||
ppoossttccoonnff command output.
|
||||
|
||||
o "ppoossttccoonnff --MMff" (Postfix 2.9 or later).
|
||||
|
||||
* Better, provide output from the ppoossttffiinnggeerr tool. This can be found at
|
||||
https://github.com/ford--prefect/postfinger.
|
||||
|
||||
* If the problem is SASL related, consider including the output from the
|
||||
ssaassllffiinnggeerr tool. This can be found at https://packages.debian.org/
|
||||
search?keywords=sasl2-bin.
|
||||
|
||||
* If the problem is about too much mail in the queue, consider including
|
||||
output from the qqsshhaappee tool, as described in the QSHAPE_README file.
|
||||
|
||||
* If the problem is protocol related (connections time out, or an SMTP server
|
||||
complains about syntax errors etc.) consider recording a session with
|
||||
ttccppdduummpp, as described in the DEBUG_README document.
|
||||
|
||||
270
README_FILES/DEPRECATION_README
Normal file
270
README_FILES/DEPRECATION_README
Normal file
|
|
@ -0,0 +1,270 @@
|
|||
PPoossttffiixx RReeppllaacceemmeennttss ffoorr DDeepprreeccaatteedd FFeeaattuurreess
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document describes Postfix features that are deprecated (will be removed)
|
||||
or that have already been removed. It also has tips for making an existing
|
||||
Postfix configuration more future-proof.
|
||||
|
||||
Overview:
|
||||
|
||||
* Why deprecate?
|
||||
* Deprecation process
|
||||
* Deprecated features
|
||||
|
||||
WWhhyy ddeepprreeccaattee??
|
||||
|
||||
Sometimes, a Postfix feature needs to be replaced with a different one. To give
|
||||
an example:
|
||||
|
||||
* The initial Postfix TLS implementation used multiple boolean parameters:
|
||||
one parameter to enable opportunistic TLS (for example, "smtp_enforce_tls =
|
||||
yes") and one parameter to enable mandatory TLS (for example,
|
||||
"smtp_require_tls = yes").
|
||||
|
||||
* As we added support more features such as fingerprint, dane, and so on, we
|
||||
decided not to add more boolean parameters. Instead we introduced one
|
||||
configuration parameter to select from multiple deployment models (for
|
||||
example, smtp_tls_security_level = may | encrypt | dane, etc...).
|
||||
|
||||
Having both the "old" and "new" way to configure Postfix is convenient for
|
||||
existing Postfix installations, because their configuration does not break
|
||||
after an upgrade to a new version. Unfortunately, there are also disadvantages.
|
||||
Having multiple ways to do similar things is not only confusing for newcomers,
|
||||
it also makes Postfix harder to change.
|
||||
|
||||
DDeepprreeccaattiioonn pprroocceessss
|
||||
|
||||
The basic process steps are:
|
||||
|
||||
1. Inform humans that a feature will be removed, and suggest replacements, in
|
||||
logging and documentation.
|
||||
|
||||
2. Remove the feature, and update logging and documentation.
|
||||
|
||||
Disclaimer: it has taken 20 years for some features to be removed. This past is
|
||||
not a guarantee for the future.
|
||||
|
||||
DDeepprreeccaatteedd ffeeaattuurreess
|
||||
|
||||
The table summarizes removed or deprecated features and replacements. Click on
|
||||
the "obsolete feature" name for a more detailed description.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
| |WWaarrnniinngg| | |
|
||||
|OObbssoolleettee ffeeaattuurree nnaammee |aass |RReemmoovveedd |RReeppllaacceemmeenntt |
|
||||
| |ooff |iinn vveerrssiioonn| |
|
||||
| |vveerrssiioonn| | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|disable_dns_lookups | 3.9 | - |smtp_dns_support_level |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|xxx_use_tls | 3.9 | - |xxx_tls_security_level |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|xxx_enforce_tls | 3.9 | - |xxx_tls_security_level |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|xxx_per_site | 3.9 | - |xxx_policy_maps |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|smtpd_tls_dh1024_param_file| 3.9 | - |do not specify (leave at |
|
||||
| | | |default) |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|smtpd_tls_eecdh_grade | 3.9 | - |do not specify (leave at |
|
||||
| | | |default) |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|permit_mx_backup | 3.9 | - |relay_domains |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|check_relay_domains | 2.2 | 3.9 |permit_mynetworks, |
|
||||
| | | |reject_unauth_destination|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|reject_maps_rbl | 2.1 | 3.9 |reject_rbl_client |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|permit_naked_ip_address | 2.0 | 3.9 |permit_mynetworks, |
|
||||
| | | |permit_sasl_authenticated|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
OObbssoolleettee DDNNSS oonn//ooffff ccoonnffiigguurraattiioonn
|
||||
|
||||
The postconf(1) command logs the following:
|
||||
|
||||
* support for parameter "disable_dns_lookups" will be removed; instead,
|
||||
specify "smtp_dns_support_level"
|
||||
|
||||
Replace obsolete configuration with its replacement:
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|GGooaall |OObbssoolleettee ccoonnffiigguurraattiioonn |RReeppllaacceemmeenntt |
|
||||
| | |ccoonnffiigguurraattiioonn |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|To disable DNS lookups|disable_dns_lookups = |smtp_dns_support_level =|
|
||||
|in the Postfix SMTP/ |yes |disabled |
|
||||
|LMTP client | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Leave |
|
||||
| | |smtp_dns_support_level |
|
||||
|To enable DNS lookups | |at the implicit default |
|
||||
|in the Postfix SMTP/ |disable_dns_lookups = no|which is empty, unless |
|
||||
|LMTP client | |you need a higher |
|
||||
| | |support level such as |
|
||||
| | |DNSSEC. |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
OObbssoolleettee ooppppoorrttuunniissttiicc TTLLSS ccoonnffiigguurraattiioonn
|
||||
|
||||
The postconf(1) command logs one of the following:
|
||||
|
||||
* support for parameter "lmtp_use_tls" will be removed; instead, specify
|
||||
"lmtp_tls_security_level"
|
||||
* support for parameter "smtp_use_tls" will be removed; instead, specify
|
||||
"smtp_tls_security_level"
|
||||
* support for parameter "smtpd_use_tls" will be removed; instead, specify
|
||||
"smtpd_tls_security_level"
|
||||
|
||||
There are similarly-named parameters and warnings for postscreen(8) and
|
||||
tlsproxy(8), but those parameters should rarely be specified by hand.
|
||||
|
||||
Replace obsolete configuration with its replacement:
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|GGooaall |OObbssoolleettee ccoonnffiigguurraattiioonn|RReeppllaacceemmeenntt ccoonnffiigguurraattiioonn|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|To turn off TLS |xxx_use_tls = no |xxx_security_level = none|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|To turn on opportunistic|xxx_use_tls = yes |xxx_security_level = may |
|
||||
|TLS | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
OObbssoolleettee mmaannddaattoorryy TTLLSS ccoonnffiigguurraattiioonn
|
||||
|
||||
The postconf(1) command logs one of the following:
|
||||
|
||||
* support for parameter "lmtp_enforce_tls" will be removed; instead, specify
|
||||
"lmtp_tls_security_level"
|
||||
* support for parameter "smtp_enforce_tls" will be removed; instead, specify
|
||||
"smtp_tls_security_level"
|
||||
* support for parameter "smtpd_enforce_tls" will be removed; instead, specify
|
||||
"smtpd_tls_security_level"
|
||||
|
||||
There are similarly-named parameters and warnings for postscreen(8) and
|
||||
tlsproxy(8), but those parameters should rarely be specified by hand.
|
||||
|
||||
Replace obsolete configuration with its replacement:
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|GGooaall |OObbssoolleettee ccoonnffiigguurraattiioonn|RReeppllaacceemmeenntt ccoonnffiigguurraattiioonn|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|To turn off mandatory |xxx_enforce_tls = no |xxx_security_level = may |
|
||||
|TLS | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|To turn on mandatory TLS|xxx_enforce_tls = yes |xxx_security_level = |
|
||||
| | |encrypt |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
OObbssoolleettee TTLLSS ppoolliiccyy ttaabbllee ccoonnffiigguurraattiioonn
|
||||
|
||||
The postconf(1) command logs one of the following:
|
||||
|
||||
* support for parameter "lmtp_tls_per_site" will be removed; instead, specify
|
||||
"lmtp_tls_policy_maps"
|
||||
* support for parameter "smtp_tls_per_site" will be removed; instead, specify
|
||||
"smtp_tls_policy_maps"
|
||||
|
||||
There is similarly-named parameter and warning for tlsproxy(8), but that
|
||||
parameter should rarely be specified by hand.
|
||||
|
||||
Unfortunately, this is more than a name change: the table format has changed
|
||||
too, as has the table search process. There is no simple conversion of the
|
||||
obsolete form to its replacement.
|
||||
|
||||
cchheecckk__rreellaayy__ddoommaaiinnss
|
||||
|
||||
Depending on the Postfix version, the Postfix SMTP daemon logs following
|
||||
warning:
|
||||
|
||||
* support for restriction "check_relay_domains" has been removed in Postfix
|
||||
3.9"; instead, specify "reject_unauth_destination"
|
||||
* support for restriction "check_relay_domains" will be removed from Postfix;
|
||||
use "reject_unauth_destination" instead
|
||||
|
||||
This feature was removed because it would relay based on the client domain
|
||||
name, which is not robust.
|
||||
|
||||
Recommended configuration to prevent an "open relay" problem with the SMTP
|
||||
service on port 25:
|
||||
|
||||
main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks,
|
||||
permit_sasl_authenticated,
|
||||
reject_unauth_destination
|
||||
...other restrictions...
|
||||
|
||||
Or equivalent in smtpd_relay_restrictions.
|
||||
|
||||
ppeerrmmiitt__mmxx__bbaacckkuupp
|
||||
|
||||
The Postfix version 3.9 and later SMTP daemon logs the following warning:
|
||||
|
||||
* support for restriction "permit_mx_backup" will be removed from Postfix;
|
||||
instead, specify "relay_domains"
|
||||
|
||||
This feature will be removed because it is too difficult to configure recipient
|
||||
address validation, making Postfix a source of backscatter bounces.
|
||||
|
||||
To specify the domains that Postfix will provide MX backup service for, see
|
||||
Configuring Postfix as primary or backup MX host for a remote site.
|
||||
|
||||
rreejjeecctt__mmaappss__rrbbll
|
||||
|
||||
Depending on the Postfix version, the SMTP daemon logs one of the following
|
||||
warnings:
|
||||
|
||||
* support for restriction "reject_maps_rbl" has been removed in Postfix 3.9";
|
||||
instead, specify "reject_rbl_client domain-name"
|
||||
* support for restriction "reject_maps_rbl" will be removed from Postfix; use
|
||||
"reject_rbl_client domain-name" instead
|
||||
|
||||
This feature was replaced because "MAPS RBL" is the name of a specific
|
||||
reputation service. The reject_rbl_client feature provides a superset of the
|
||||
reject_maps_rbl functionality.
|
||||
|
||||
Recommended configuration:
|
||||
|
||||
main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks,
|
||||
permit_sasl_authenticated,
|
||||
reject_unauth_destination
|
||||
reject_rbl_client domain-name
|
||||
...other restrictions...
|
||||
|
||||
Where domain-name is the domain name of a DNS reputation service.
|
||||
|
||||
ppeerrmmiitt__nnaakkeedd__iipp__aaddddrreessss
|
||||
|
||||
Depending on the Postfix version, the SMTP daemon logs one of the following
|
||||
warnings:
|
||||
|
||||
* support for restriction "permit_naked_ip_address" has been removed in
|
||||
Postfix 3.9"; instead, specify "permit_mynetworks" or
|
||||
"permit_sasl_authenticated"
|
||||
* restriction permit_naked_ip_address is deprecated. Use permit_mynetworks or
|
||||
permit_sasl_authenticated instead
|
||||
|
||||
This feature was removed because it was easy to get a false match when
|
||||
smtpd_recipient_restrictions was intended to match a remote SMTP client IP
|
||||
address.
|
||||
|
||||
Recommended configuration:
|
||||
|
||||
main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks,
|
||||
permit_sasl_authenticated,
|
||||
reject_unauth_destination
|
||||
reject_rbl_client domain-name
|
||||
...other restrictions...
|
||||
|
||||
That is, no restriction on HELO or EHLO syntax. Such restrictions ar rarely
|
||||
useful nowadays.
|
||||
|
||||
98
README_FILES/DSN_README
Normal file
98
README_FILES/DSN_README
Normal file
|
|
@ -0,0 +1,98 @@
|
|||
PPoossttffiixx DDSSNN SSuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix version 2.3 introduces support for Delivery Status Notifications as
|
||||
described in RFC 3464. This gives senders control over successful and failed
|
||||
delivery notifications.
|
||||
|
||||
Specifically, DSN support gives an email sender the ability to specify:
|
||||
|
||||
* What notifications are sent: success, failure, delay, or none. Normally,
|
||||
Postfix informs the sender only when mail delivery is delayed or when
|
||||
delivery fails.
|
||||
|
||||
* What content is returned in case of failure: only the message headers, or
|
||||
the full message.
|
||||
|
||||
* An envelope ID that is returned as part of delivery status notifications.
|
||||
This identifies the message submission transaction, and must not be
|
||||
confused with the message ID, which identifies the message content.
|
||||
|
||||
The implementation of DSN support involves extra parameters to the SMTP MAIL
|
||||
FROM and RCPT TO commands, as well as two Postfix sendmail command line options
|
||||
that provide a sub-set of the functions of the extra SMTP command parameters.
|
||||
|
||||
This document has information on the following topics:
|
||||
|
||||
* Restricting the scope of "success" notifications
|
||||
* Postfix sendmail command-line interface
|
||||
* Postfix VERP support compatibility
|
||||
|
||||
RReessttrriiccttiinngg tthhee ssccooppee ooff ""ssuucccceessss"" nnoottiiffiiccaattiioonnss
|
||||
|
||||
Just like reports of undeliverable mail, DSN reports of successful delivery can
|
||||
give away more information about the internal infrastructure than desirable.
|
||||
Unfortunately, disallowing "success" notification requests requires disallowing
|
||||
other DSN requests as well. The RFCs do not offer the option to negotiate
|
||||
feature subsets.
|
||||
|
||||
This is not as bad as it sounds. When you turn off DSN for remote inbound mail,
|
||||
remote senders with DSN support will still be informed that their mail reached
|
||||
your Postfix gateway successfully; they just will not get successful delivery
|
||||
notices from your internal systems. Remote senders lose very little: they can
|
||||
no longer specify how Postfix should report delayed or failed delivery.
|
||||
|
||||
Use the smtpd_discard_ehlo_keyword_address_maps feature if you wish to allow
|
||||
DSN requests from trusted clients but not from random strangers (see below for
|
||||
how to turn this off for all clients):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_discard_ehlo_keyword_address_maps =
|
||||
cidr:/etc/postfix/esmtp_access
|
||||
|
||||
/etc/postfix/esmtp_access:
|
||||
# Allow DSN requests from local subnet only
|
||||
192.168.0.0/28 silent-discard
|
||||
0.0.0.0/0 silent-discard, dsn
|
||||
::/0 silent-discard, dsn
|
||||
|
||||
If you want to disallow all use of DSN requests from the network, use the
|
||||
smtpd_discard_ehlo_keywords feature:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_discard_ehlo_keywords = silent-discard, dsn
|
||||
|
||||
PPoossttffiixx sseennddmmaaiill ccoommmmaanndd--lliinnee iinntteerrffaaccee
|
||||
|
||||
Postfix has two Sendmail-compatible command-line options for DSN support.
|
||||
|
||||
* The first option specifies what notifications are sent for mail that is
|
||||
submitted via the Postfix sendmail(1) command line:
|
||||
|
||||
$ sseennddmmaaiill --NN ssuucccceessss,,ddeellaayy,,ffaaiilluurree ...... (one or more of these)
|
||||
$ sseennddmmaaiill --NN nneevveerr ...... (or just this by itself)
|
||||
|
||||
The built-in default corresponds with "delay,failure".
|
||||
|
||||
* The second option specifies an envelope ID which is reported in delivery
|
||||
status notifications for mail that is submitted via the Postfix sendmail(1)
|
||||
command line:
|
||||
|
||||
$ sseennddmmaaiill --VV eennvveellooppee--iidd ......
|
||||
|
||||
Note: this conflicts with VERP support in older Postfix versions, as
|
||||
discussed in the next section.
|
||||
|
||||
PPoossttffiixx VVEERRPP ssuuppppoorrtt ccoommppaattiibbiilliittyy
|
||||
|
||||
With Postfix versions before 2.3, the sendmail(1) command uses the -V command-
|
||||
line option to request VERP-style delivery. In order to request VERP style
|
||||
delivery with Postfix 2.3 and later, you must specify -XV instead of -V.
|
||||
|
||||
The Postfix 2.3 sendmail(1) command will recognize if you try to use -V for
|
||||
VERP-style delivery. It will do the right thing and will remind you of the new
|
||||
syntax.
|
||||
|
||||
250
README_FILES/ETRN_README
Normal file
250
README_FILES/ETRN_README
Normal file
|
|
@ -0,0 +1,250 @@
|
|||
PPoossttffiixx EETTRRNN HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
|
||||
|
||||
The SMTP ETRN command was designed for sites that have intermittent Internet
|
||||
connectivity. With ETRN, a site can tell the mail server of its provider to
|
||||
"Please deliver all my mail now". The SMTP server searches the queue for mail
|
||||
to the customer, and delivers that mail bbyy ccoonnnneeccttiinngg ttoo tthhee ccuussttoommeerr''ss SSMMTTPP
|
||||
sseerrvveerr. The mail is not delivered via the connection that was used for sending
|
||||
ETRN.
|
||||
|
||||
As of version 1.0, Postfix has a fast ETRN implementation that does not require
|
||||
Postfix to examine every queue file. Instead, Postfix maintains a record of
|
||||
what queue files contain mail for destinations that are configured for ETRN
|
||||
service. ETRN service is no longer available for domains that aren't configured
|
||||
for the service.
|
||||
|
||||
This document provides information on the following topics:
|
||||
|
||||
* Using the Postfix fast ETRN service
|
||||
* How Postfix fast ETRN works
|
||||
* Postfix fast ETRN service limitations
|
||||
* Configuring the Postfix fast ETRN service
|
||||
* Configuring a domain for ETRN service only
|
||||
* Testing the Postfix fast ETRN service
|
||||
|
||||
Other documents with information on this subject:
|
||||
|
||||
* flush(8), flush service implementation
|
||||
|
||||
UUssiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
|
||||
|
||||
The following is an example SMTP session that shows how an SMTP client requests
|
||||
the ETRN service. Client commands are shown in bold font.
|
||||
|
||||
220 my.server.tld ESMTP Postfix
|
||||
HHEELLOO mmyy..cclliieenntt..ttlldd
|
||||
250 Ok
|
||||
EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
|
||||
250 Queuing started
|
||||
QQUUIITT
|
||||
221 Bye
|
||||
|
||||
As mentioned in the introduction, the mail is delivered by connecting to the
|
||||
customer's SMTP server; it is not sent over the connection that was used to
|
||||
send the ETRN command.
|
||||
|
||||
The Postfix operator can request delivery for a specific customer by using the
|
||||
command "sendmail -qRdestination" and, with Postfix version 1.1 and later,
|
||||
"postqueue -sdestination". Access to this feature is controlled with the
|
||||
authorized_flush_users configuration parameter (Postfix version 2.2 and later).
|
||||
|
||||
HHooww PPoossttffiixx ffaasstt EETTRRNN wwoorrkkss
|
||||
|
||||
When a Postfix delivery agent decides that mail must be delivered later, it
|
||||
sends the destination domain name and the queue file name to the flush(8)
|
||||
daemon which maintains per-destination logfiles with file names of queued mail.
|
||||
These logfiles are kept below $queue_directory/flush. Per-destination logfiles
|
||||
are maintained only for destinations that are listed with the
|
||||
$fast_flush_domains parameter and that have syntactically valid domain names.
|
||||
|
||||
Postfix Postfix One logfile
|
||||
delivery -(domain, queue ID)-> flush -(queue ID)-> per eligible
|
||||
agent daemon domain
|
||||
|
||||
When Postfix receives a request to "deliver mail for a domain now", the flush
|
||||
(8) daemon moves all deferred queue files that are listed for that domain to
|
||||
the incoming queue, and requests that the queue manager deliver them. In order
|
||||
to force delivery, the queue manager temporarily ignores the lists of
|
||||
undeliverable destinations: the volatile in-memory list of dead domains, and
|
||||
the list of message delivery transports specified with the defer_transports
|
||||
configuration parameter.
|
||||
|
||||
PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee lliimmiittaattiioonnss
|
||||
|
||||
The design of the flush(8) server and of the flush queue introduce a few
|
||||
limitations that should not be an issue unless you want to turn on fast ETRN
|
||||
service for every possible destination.
|
||||
|
||||
* The flush(8) daemon maintains per-destination logfiles with queue file
|
||||
names. When a request to "deliver mail now" arrives, Postfix will attempt
|
||||
to deliver all recipients in the queue files that have mail for the
|
||||
destination in question. This does not perform well with queue files that
|
||||
have recipients in many different domains, such as queue files with
|
||||
outbound mailing list traffic.
|
||||
|
||||
* The flush(8) daemon maintains per-destination logfiles only for
|
||||
destinations listed with $fast_flush_domains. With other destinations you
|
||||
cannot request delivery with "sendmail -qRdestination" or, with Postfix
|
||||
version 1.1 and later, "postqueue -sdestination".
|
||||
|
||||
* Up to and including early versions of Postfix version 2.1, the "fast flush"
|
||||
service may not deliver some messages if the request to "deliver mail now"
|
||||
is received while a deferred queue scan is already in progress. The reason
|
||||
is that the queue manager does not ignore the volatile in-memory list of
|
||||
dead domains, and the list of message delivery transports specified with
|
||||
the defer_transports configuration parameter.
|
||||
|
||||
* Up to and including Postfix version 2.3, the "fast flush" service may not
|
||||
deliver some messages if the request to "deliver mail now" arrives while an
|
||||
incoming queue scan is already in progress.
|
||||
|
||||
CCoonnffiigguurriinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
|
||||
|
||||
The behavior of the flush(8) daemon is controlled by parameters in the main.cf
|
||||
configuration file.
|
||||
|
||||
By default, Postfix "fast ETRN" service is available only for destinations that
|
||||
Postfix is willing to relay mail to:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
fast_flush_domains = $relay_domains
|
||||
smtpd_etrn_restrictions = permit_mynetworks, reject
|
||||
|
||||
Notes:
|
||||
|
||||
* The relay_domains parameter specifies what destinations Postfix will relay
|
||||
to. For destinations that are not eligible for the "fast ETRN" service,
|
||||
Postfix replies with an error message.
|
||||
|
||||
* The smtpd_etrn_restrictions parameter limits what clients may execute the
|
||||
ETRN command. By default, any client has permission.
|
||||
|
||||
To enable "fast ETRN" for some other destination, specify:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
fast_flush_domains = $relay_domains, some.other.domain
|
||||
|
||||
To disable "fast ETRN", so that Postfix rejects all ETRN requests and so that
|
||||
it maintains no per-destination logfiles, specify:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
fast_flush_domains =
|
||||
|
||||
CCoonnffiigguurriinngg aa ddoommaaiinn ffoorr EETTRRNN sseerrvviiccee oonnllyy
|
||||
|
||||
While an "ETRN" customer is off-line, Postfix will make spontaneous attempts to
|
||||
deliver mail to it. These attempts are separated in time by increasing time
|
||||
intervals, ranging from $minimal_backoff_time to $maximal_backoff_time, and
|
||||
should not be a problem unless a lot of mail is queued.
|
||||
|
||||
To prevent Postfix from making spontaneous delivery attempts you can configure
|
||||
Postfix to always defer mail for the "ETRN" customer. Mail is delivered only
|
||||
after the ETRN command or with "sendmail -q", with "sendmail -qRdomain", or
|
||||
with "postqueue -sdomain"(Postfix version 1.1 and later only),
|
||||
|
||||
In the example below we configure an "etrn-only" delivery transport which is
|
||||
simply a duplicate of the "smtp" and "relay" mail delivery transports. The only
|
||||
difference is that mail destined for this delivery transport is deferred as
|
||||
soon as it arrives.
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 # =============================================================
|
||||
3 # service type private unpriv chroot wakeup maxproc command
|
||||
4 # (yes) (yes) (yes) (never) (100)
|
||||
5 # =============================================================
|
||||
6 smtp unix - - n - - smtp
|
||||
7 relay unix - - n - - smtp
|
||||
8 etrn-only unix - - n - - smtp
|
||||
9
|
||||
10 /etc/postfix/main.cf:
|
||||
11 relay_domains = customer.tld ...other domains...
|
||||
12 defer_transports = etrn-only
|
||||
13 transport_maps = hash:/etc/postfix/transport
|
||||
14
|
||||
15 /etc/postfix/transport:
|
||||
16 customer.tld etrn-only:[mailhost.customer.tld]
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 8: The "etrn-only" mail delivery service is a copy of the "smtp" and
|
||||
"relay" service.
|
||||
|
||||
* Line 11: Don't forget to authorize relaying for this customer, either via
|
||||
relay_domains or with the permit_mx_backup feature.
|
||||
|
||||
* Line 12: The "etrn-only" mail delivery service is configured so that
|
||||
spontaneous mail delivery is disabled.
|
||||
|
||||
* Lines 13-16: Mail for the customer is given to the "etrn-only" mail
|
||||
delivery service.
|
||||
|
||||
* Line 16: The "[mailhost.customer.tld]" turns off MX record lookups; you
|
||||
must specify this if your Postfix server is the primary MX host for the
|
||||
customer's domain.
|
||||
|
||||
TTeessttiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
|
||||
|
||||
By default, "fast ETRN" service is enabled for all domains that match
|
||||
$relay_domains. If you run Postfix with "fast ETRN" service for the very first
|
||||
time, you need to run "sendmail -q" once in order to populate the per-site
|
||||
deferred mail logfiles. If you omit this step, no harm is done. The logfiles
|
||||
will eventually become populated as Postfix routinely attempts to deliver
|
||||
delayed mail, but that will take a couple hours. After the "sendmail -q"
|
||||
command has completed all delivery attempts (this can take a while), you're
|
||||
ready to test the "fast ETRN" service.
|
||||
|
||||
To test the "fast ETRN" service, telnet to the Postfix SMTP server from a
|
||||
client that is allowed to execute ETRN commands (by default, that's every
|
||||
client), and type the commands shown in boldface:
|
||||
|
||||
220 my.server.tld ESMTP Postfix
|
||||
HHEELLOO mmyy..cclliieenntt..ttlldd
|
||||
250 Ok
|
||||
EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
|
||||
250 Queuing started
|
||||
|
||||
where "some.customer.domain" is the name of a domain that has a non-empty
|
||||
logfile somewhere under $queue_directory/flush.
|
||||
|
||||
In the maillog file, you should immediately see a couple of logfile records, as
|
||||
evidence that the queue manager has opened queue files:
|
||||
|
||||
Oct 2 10:51:19 myhostname postfix/qmgr[51999]: 682E8440A4:
|
||||
from=<whatever>, size=12345, nrcpt=1 (queue active)
|
||||
Oct 2 10:51:19 myhostname postfix/qmgr[51999]: 02249440B7:
|
||||
from=<whatever>, size=4711, nrcpt=1 (queue active)
|
||||
|
||||
What happens next depends on whether the destination is reachable. If it's not
|
||||
reachable, the mail queue IDs will be added back to the some.customer.domain
|
||||
logfile under $queue_directory/flush.
|
||||
|
||||
Repeat the exercise with some other destination that your server is willing to
|
||||
relay to (any domain listed in $relay_domains), but that has no mail queued.
|
||||
The text in bold face stands for the commands that you type:
|
||||
|
||||
220 my.server.tld ESMTP Postfix
|
||||
HHEELLOO mmyy..cclliieenntt..ttlldd
|
||||
250 Ok
|
||||
EETTRRNN ssoommee..ootthheerr..ccuussttoommeerr..ddoommaaiinn
|
||||
250 Queuing started
|
||||
|
||||
This time, the "ETRN"" command should trigger NO mail deliveries at all. If
|
||||
this triggers delivery of all mail, then you used the wrong domain name, or
|
||||
"fast ETRN" service is turned off.
|
||||
|
||||
Finally, repeat the exercise with a destination that your mail server is not
|
||||
willing to relay to. It does not matter if your server has mail queued for that
|
||||
destination.
|
||||
|
||||
220 my.server.tld ESMTP Postfix
|
||||
HHEELLOO mmyy..cclliieenntt..ttlldd
|
||||
250 Ok
|
||||
EETTRRNN nnoott..aa..ccuussttoommeerr..ddoommaaiinn
|
||||
459 <not.a.customer.domain>: service unavailable
|
||||
|
||||
In this case, Postfix should reject the request as shown above.
|
||||
|
||||
617
README_FILES/FILTER_README
Normal file
617
README_FILES/FILTER_README
Normal file
|
|
@ -0,0 +1,617 @@
|
|||
PPoossttffiixx AAfftteerr--QQuueeuuee CCoonntteenntt FFiilltteerr
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document requires Postfix version 2.1 or later.
|
||||
|
||||
Normally, Postfix receives mail, stores it in the mail queue and then delivers
|
||||
it. With the external content filter described here, mail is filtered AFTER it
|
||||
is queued. This approach decouples mail receiving processes from mail filtering
|
||||
processes, and gives you maximal control over how many filtering processes you
|
||||
are willing to run in parallel.
|
||||
|
||||
The after-queue content filter is meant to be used as follows:
|
||||
|
||||
Network or -> Postfix -> CCoonntteenntt -> Postfix -> Network or
|
||||
local users queue ffiilltteerr queue local mailbox
|
||||
|
||||
This document describes implementations that use a single Postfix instance for
|
||||
everything: receiving, filtering and delivering mail. Applications that use two
|
||||
separate Postfix instances will be covered by a later version of this document.
|
||||
|
||||
The after-queue content filter is not to be confused with the approaches
|
||||
described in the SMTPD_PROXY_README or MILTER_README documents, where incoming
|
||||
SMTP mail is filtered BEFORE it is stored into the Postfix queue.
|
||||
|
||||
This document describes two approaches to content filter all email, as well as
|
||||
several options to filter mail selectively:
|
||||
|
||||
* Principles of operation
|
||||
* Simple content filter
|
||||
|
||||
o Simple content filter example
|
||||
o Simple content filter performance
|
||||
o Simple content filter limitations
|
||||
o Turning off the simple content filter
|
||||
|
||||
* Advanced content filter
|
||||
|
||||
o Advanced content filter example
|
||||
o Advanced content filter performance
|
||||
o Turning off the advanced content filter
|
||||
|
||||
* Selective content filtering
|
||||
|
||||
o Filtering mail from outside users only
|
||||
o Different filters for different domains
|
||||
o FILTER actions in access or header/body tables
|
||||
|
||||
PPrriinncciipplleess ooff ooppeerraattiioonn
|
||||
|
||||
An after-queue content filter receives unfiltered mail from Postfix (as
|
||||
described further below) and can do one of the following:
|
||||
|
||||
1. Re-inject the mail back into Postfix, perhaps after changing content and/or
|
||||
destination.
|
||||
|
||||
2. Discard or quarantine the mail.
|
||||
|
||||
3. Reject the mail (by sending a suitable status code back to Postfix).
|
||||
Postfix will send the mail back to the sender address.
|
||||
|
||||
NOTE: in this time of mail worms and forged spam, it is a VERY BAD IDEA to send
|
||||
viruses back to the sender address, because the sender address is almost
|
||||
certainly not the originator. It is better to discard known viruses, and to
|
||||
quarantine material that is suspect so that a human can decide what to do with
|
||||
it.
|
||||
|
||||
SSiimmppllee ccoonntteenntt ffiilltteerr eexxaammppllee
|
||||
|
||||
The first example is simple to set up, but has major limitations that will be
|
||||
addressed in a second example. Postfix receives unfiltered mail from the
|
||||
network with the smtpd(8) server, and delivers unfiltered mail to a content
|
||||
filter with the Postfix pipe(8) delivery agent. The content filter injects
|
||||
filtered mail back into Postfix with the Postfix sendmail(1) command, so that
|
||||
Postfix can deliver it to the final destination.
|
||||
|
||||
This means that mail submitted via the Postfix sendmail(1) command cannot be
|
||||
content filtered.
|
||||
|
||||
In the figure below, names followed by a number represent Postfix commands or
|
||||
daemon programs. See the OVERVIEW document for an introduction to the Postfix
|
||||
architecture.
|
||||
|
||||
Unfiltered -> smtpd(8) qmgr(8) local(8) -> Filtered
|
||||
>- cleanup(8) -> Postfix -< smtp(8) -> Filtered
|
||||
pickup(8) queue pipe(8)
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
maildrop Postfix Postfix Content
|
||||
queue <- postdrop <- sendmail <- filter
|
||||
(1) (1)
|
||||
|
||||
The content filter can be a simple shell script like this:
|
||||
|
||||
1 #!/bin/sh
|
||||
2
|
||||
3 # Simple shell-based filter. It is meant to be invoked as follows:
|
||||
4 # /path/to/script -f sender recipients...
|
||||
5
|
||||
6 # Localize these. The -G option does nothing before Postfix 2.3.
|
||||
7 INSPECT_DIR=/var/spool/filter
|
||||
8 SENDMAIL="/usr/sbin/sendmail -G -i" # NEVER NEVER NEVER use "-t" here.
|
||||
9
|
||||
10 # Exit codes from <sysexits.h>
|
||||
11 EX_TEMPFAIL=75
|
||||
12 EX_UNAVAILABLE=69
|
||||
13
|
||||
14 # Clean up when done or when aborting.
|
||||
15 trap "rm -f in.$$" 0 1 2 3 15
|
||||
16
|
||||
17 # Start processing.
|
||||
18 cd $INSPECT_DIR || {
|
||||
19 echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
|
||||
20
|
||||
21 cat >in.$$ || {
|
||||
22 echo Cannot save mail to file; exit $EX_TEMPFAIL; }
|
||||
23
|
||||
24 # Specify your content filter here.
|
||||
25 # filter <in.$$ || {
|
||||
26 # echo Message content rejected; exit $EX_UNAVAILABLE; }
|
||||
27
|
||||
28 $SENDMAIL "$@" <in.$$
|
||||
29
|
||||
30 exit $?
|
||||
|
||||
Notes:
|
||||
|
||||
* Line 8: The -G option says the filter output is not a local mail
|
||||
submission: don't do silly things like appending the local domain name to
|
||||
addresses in message headers. This option does nothing before Postfix
|
||||
version 2.3.
|
||||
|
||||
* Line 8: The -i option says don't stop reading input when a line contains
|
||||
"." only.
|
||||
|
||||
* Line 8: NEVER NEVER NEVER use the "-t" command-line option here. It will
|
||||
mis-deliver mail, like sending messages from a mailing list back to the
|
||||
mailing list.
|
||||
|
||||
* Line 21: The idea is to first capture the message to file and then run the
|
||||
content through a third-party content filter program.
|
||||
|
||||
* Line 22: If the message cannot be captured to file, mail delivery is
|
||||
deferred by terminating with exit status 75 (EX_TEMPFAIL). Postfix places
|
||||
the message in the deferred mail queue and tries again later.
|
||||
|
||||
* Line 25: You will need to specify a real content filter program here that
|
||||
receives the content on standard input.
|
||||
|
||||
* Line 26: If the content filter program finds a problem, the mail is bounced
|
||||
by terminating with exit status 69 (EX_UNAVAILABLE). Postfix will send the
|
||||
message back to the sender as undeliverable mail.
|
||||
|
||||
* NOTE: in this time of mail worms and spam, it is a BAD IDEA to send known
|
||||
viruses or spam back to the sender, because that address is likely to be
|
||||
forged. It is safer to discard known viruses and to quarantine suspicious
|
||||
content so that it can be inspected by a human being.
|
||||
|
||||
* Line 28: If the content is OK, it is given as input to the Postfix sendmail
|
||||
command, and the exit status of the filter command is whatever exit status
|
||||
the Postfix sendmail command produces. Postfix will deliver the message as
|
||||
usual.
|
||||
|
||||
* Line 30: Postfix returns the exit status of the Postfix sendmail command.
|
||||
|
||||
I suggest that you first run this script by hand until you are satisfied with
|
||||
the results. Run it with a real message (headers+body) as input:
|
||||
|
||||
% /path/to/script -f sender -- recipient... <message-file
|
||||
|
||||
Once you're satisfied with the content filtering script:
|
||||
|
||||
* Create a dedicated local user account called "filter". This user handles
|
||||
all potentially dangerous mail content - that is why it should be a
|
||||
separate account. Do not use "nobody", and most certainly do not use "root"
|
||||
or "postfix".
|
||||
|
||||
* Create a directory /var/spool/filter that is accessible only to the
|
||||
"filter" user. This is where the content filtering script is supposed to
|
||||
store its temporary files.
|
||||
|
||||
* Configure Postfix to deliver mail to the content filter with the pipe(8)
|
||||
delivery agent (see the pipe(8) manpage for a description of the command
|
||||
syntax below).
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
filter unix - n n - 10 pipe
|
||||
flags=Rq user=filter null_sender=
|
||||
argv=/path/to/script -f ${sender} -- ${recipient}
|
||||
|
||||
This runs up to 10 content filters in parallel. Instead of a limit of 10
|
||||
concurrent processes, use whatever process limit is feasible for your
|
||||
machine. Content inspection software can gobble up a lot of system
|
||||
resources, so you don't want to have too much of it running at the same
|
||||
time. The empty null_sender setting is required with Postfix 2.3 and later.
|
||||
|
||||
* To turn on content filtering for mail arriving via SMTP only, append "-
|
||||
o content_filter=filter:dummy" to the master.cf entry that defines the
|
||||
Postfix SMTP server:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
smtp inet ...other stuff here, do not change... smtpd
|
||||
-o content_filter=filter:dummy
|
||||
|
||||
The "-o content_filter" line causes Postfix to add one content filter
|
||||
request record to each incoming mail message, with content "filter:dummy".
|
||||
This record overrides the normal mail routing and causes mail to be given
|
||||
to the content filter instead.
|
||||
|
||||
The content_filter configuration parameter expects a value of the form
|
||||
transport:destination. The transport name specifies the first field of a
|
||||
mail delivery agent definition in master.cf; the syntax of the next-hop
|
||||
destination is described in the manual page of the corresponding delivery
|
||||
agent.
|
||||
|
||||
The meaning of an empty next-hop filter destination is version dependent.
|
||||
Postfix 2.7 and later will use the recipient domain; earlier versions will
|
||||
use $myhostname. Specify "default_filter_nexthop = $myhostname" for
|
||||
compatibility with Postfix 2.6 or earlier, or specify a non-empty next-hop
|
||||
filter destination.
|
||||
|
||||
The content_filter setting has lower precedence than a FILTER action that
|
||||
is specified in an access(5), header_checks(5) or body_checks(5) table.
|
||||
|
||||
* Execute "ppoossttffiixx rreellooaadd" to complete the change.
|
||||
|
||||
SSiimmppllee ccoonntteenntt ffiilltteerr ppeerrffoorrmmaannccee
|
||||
|
||||
With the shell script as shown above you will lose a factor of four in Postfix
|
||||
performance for transit mail that arrives and leaves via SMTP. You will lose
|
||||
another factor in transit performance for each additional temporary file that
|
||||
is created and deleted in the process of content filtering. The performance
|
||||
impact is less for mail that is submitted or delivered locally, because such
|
||||
deliveries are already slower than SMTP transit mail.
|
||||
|
||||
SSiimmppllee ccoonntteenntt ffiilltteerr lliimmiittaattiioonnss
|
||||
|
||||
The problem with content filters like the one above is that they are not very
|
||||
robust. The reason is that the software does not talk a well-defined protocol
|
||||
with Postfix. If the filter shell script aborts because the shell runs into
|
||||
some memory allocation problem, the script will not produce a nice exit status
|
||||
as defined in the file /usr/include/sysexits.h. Instead of going to the
|
||||
deferred queue, mail will bounce. The same lack of robustness can happen when
|
||||
the content filtering software itself runs into a resource problem.
|
||||
|
||||
The simple content filter method is not suitable for content filter actions
|
||||
that are invoked via header_checks or body_checks patterns. These patterns will
|
||||
be applied again after mail is re-injected with the Postfix sendmail command,
|
||||
resulting in a mail filtering loop. The advanced content filtering method (see
|
||||
below) makes it possible to turn off header_checks or body_checks patterns for
|
||||
filtered mail.
|
||||
|
||||
TTuurrnniinngg ooffff tthhee ssiimmppllee ccoonntteenntt ffiilltteerr
|
||||
|
||||
To turn off "simple" content filtering:
|
||||
|
||||
* Edit the master.cf file, remove the "-o content_filter=filter:dummy" text
|
||||
from the entry that defines the Postfix SMTP server.
|
||||
|
||||
* Execute "ppoossttssuuppeerr --rr AALLLL" to remove content filter request records from
|
||||
existing queue files.
|
||||
|
||||
* Execute another "ppoossttffiixx rreellooaadd".
|
||||
|
||||
AAddvvaanncceedd ccoonntteenntt ffiilltteerr eexxaammppllee
|
||||
|
||||
The second example is more complex, but can give better performance, and is
|
||||
less likely to bounce mail when the machine runs into some resource problem.
|
||||
This content filter receives unfiltered mail with SMTP on localhost port 10025,
|
||||
and sends filtered mail back into Postfix with SMTP on localhost port 10026.
|
||||
|
||||
For non-SMTP capable content filtering software, Bennett Todd's SMTP proxy
|
||||
implements a nice PERL/SMTP content filtering framework. See: https://
|
||||
web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/.
|
||||
|
||||
In the figure below, names followed by a number represent Postfix commands or
|
||||
daemon programs. See the OVERVIEW document for an introduction to the Postfix
|
||||
architecture.
|
||||
|
||||
Unfiltered -> smtpd(8) qmgr(8) smtp(8) -> Filtered
|
||||
>- cleanup(8) -> Postfix -<
|
||||
Unfiltered -> pickup(8) queue local(8) -> Filtered
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
smtpd(8) smtp(8)
|
||||
10026
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
content filter 10025
|
||||
|
||||
The example given here filters all mail, including mail that arrives via SMTP
|
||||
and mail that is locally submitted via the Postfix sendmail command (local
|
||||
submissions enter Postfix via the pickup(8) server; to keep the figure simple
|
||||
we omit local submission details). See examples near the end of this document
|
||||
for how to exclude local users from filtering, or how to configure a
|
||||
destination dependent content filter.
|
||||
|
||||
You can expect to lose about a factor of two in Postfix performance for mail
|
||||
that arrives and leaves via SMTP, provided that the content filter creates no
|
||||
temporary files. Each temporary file created by the content filter adds another
|
||||
factor to the performance loss.
|
||||
|
||||
AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rreeqquueessttiinngg tthhaatt aallll mmaaiill iiss ffiilltteerreedd
|
||||
|
||||
To enable the advanced content filter method for all mail, specify in main.cf:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
content_filter = scan:localhost:10025
|
||||
receive_override_options = no_address_mappings
|
||||
|
||||
* The "receive_override_options" line disables address manipulation before
|
||||
the content filter, so that the content filter sees the original mail
|
||||
addresses instead of the result of virtual alias expansion, canonical
|
||||
mapping, automatic bcc, address masquerading, etc.
|
||||
|
||||
* The "content_filter" line causes Postfix to add one content filter request
|
||||
record to each incoming mail message, with content "scan:localhost:10025".
|
||||
The content filter request records are added by the smtpd(8) and pickup(8)
|
||||
servers (and qmqpd(8) if you decide to enable this service).
|
||||
|
||||
* Content filter requests are stored in queue files; this is how Postfix
|
||||
keeps track of what mail needs filtering. When a queue file contains a
|
||||
content filter request, the queue manager will deliver the mail to the
|
||||
specified content filter regardless of its final destination.
|
||||
|
||||
* The content_filter configuration parameter expects a value of the form
|
||||
transport:destination. The transport name specifies the first field of a
|
||||
mail delivery agent definition in master.cf; the syntax of the next-hop
|
||||
destination is described in the manual page of the corresponding delivery
|
||||
agent.
|
||||
|
||||
* The meaning of an empty next-hop filter destination is version dependent.
|
||||
Postfix 2.7 and later will use the recipient domain; earlier versions will
|
||||
use $myhostname. Specify "default_filter_nexthop = $myhostname" for
|
||||
compatibility with Postfix 2.6 or earlier, or specify a non-empty next-hop
|
||||
filter destination.
|
||||
|
||||
* The content_filter setting has lower precedence than a FILTER action that
|
||||
is specified in an access(5), header_checks(5) or body_checks(5) table.
|
||||
|
||||
AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: sseennddiinngg uunnffiilltteerreedd mmaaiill ttoo tthhee ccoonntteenntt ffiilltteerr
|
||||
|
||||
In this example, "scan" is an instance of the Postfix SMTP client with slightly
|
||||
different configuration parameters. This is how one would set up the service in
|
||||
the Postfix master.cf file:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
scan unix - - n - 10 smtp
|
||||
-o smtp_send_xforward_command=yes
|
||||
-o disable_mime_output_conversion=yes
|
||||
-o smtp_generic_maps=
|
||||
|
||||
* This runs up to 10 content filters in parallel. Instead of a limit of 10
|
||||
concurrent processes, use whatever process limit is feasible for your
|
||||
machine. Content inspection software can gobble up a lot of system
|
||||
resources, so you don't want to have too much of it running at the same
|
||||
time.
|
||||
|
||||
* With "-o smtp_send_xforward_command=yes", the scan transport will try to
|
||||
forward the original client name and IP address through the content filter
|
||||
to the after-filter smtpd process, so that filtered mail is logged with the
|
||||
real client name IP address. See smtp(8) and XFORWARD_README for more
|
||||
information.
|
||||
|
||||
* The "-o disable_mime_output_conversion=yes" is a workaround that prevents
|
||||
the breaking of domainkeys and other digital signatures. This is needed
|
||||
because some SMTP-based content filters don't announce 8BITMIME support,
|
||||
even though they can handle 8-bit mail.
|
||||
|
||||
* The "-o smtp_generic_maps=" is a workaround that prevents local address
|
||||
rewriting with generic(5) maps. Such rewriting should happen only when mail
|
||||
is sent out to the Internet.
|
||||
|
||||
AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rruunnnniinngg tthhee ccoonntteenntt ffiilltteerr
|
||||
|
||||
The content filter can be set up with the Postfix spawn service, which is the
|
||||
Postfix equivalent of inetd. For example, to instantiate up to 10 content
|
||||
filtering processes on localhost port 10025:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# ===================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# ===================================================================
|
||||
localhost:10025 inet n n n - 10 spawn
|
||||
user=filter argv=/path/to/filter localhost 10026
|
||||
|
||||
* "filter" is a dedicated local user account. The user will never log in, and
|
||||
can be given a "*" password and non-existent shell and home directory. This
|
||||
user handles all potentially dangerous mail content - that is why it should
|
||||
be a separate account.
|
||||
|
||||
* By default, Postfix will terminate a command that runs longer than
|
||||
command_time_limit seconds (default: 1000s). This is a safety measure that
|
||||
prevents filters from running forever.
|
||||
|
||||
If you want to have your filter listening on port localhost:10025 instead of
|
||||
Postfix, then you must run your filter as a stand-alone program, and must not
|
||||
use the Postfix spawn service.
|
||||
|
||||
AAddvvaanncceedd ffiilltteerr:: iinnjjeeccttiinngg mmaaiill bbaacckk iinnttoo PPoossttffiixx
|
||||
|
||||
The job of the content filter is to either bounce mail with a suitable
|
||||
diagnostic, or to feed the mail back into Postfix through a dedicated listener
|
||||
on port localhost 10026.
|
||||
|
||||
The simplest content filter just copies SMTP commands and data between its
|
||||
inputs and outputs. If it has a problem, all it has to do is to reply to an
|
||||
input of `.' from Postfix with `550 content rejected', and to disconnect
|
||||
without sending `.' on the connection that injects mail back into Postfix.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# ===================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# ===================================================================
|
||||
localhost:10026 inet n - n - 10 smtpd
|
||||
-o content_filter=
|
||||
-
|
||||
o
|
||||
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
|
||||
-o smtpd_helo_restrictions=
|
||||
-o smtpd_client_restrictions=
|
||||
-o smtpd_sender_restrictions=
|
||||
# Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
|
||||
-o smtpd_relay_restrictions=
|
||||
-o smtpd_recipient_restrictions=permit_mynetworks,reject
|
||||
-o mynetworks=127.0.0.0/8
|
||||
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
|
||||
|
||||
* NOTE: do not use spaces around the "=" or "," characters.
|
||||
|
||||
* NOTE: the SMTP server must not have a smaller process limit than the
|
||||
"filter" master.cf entry.
|
||||
|
||||
* The "-o content_filter=" overrides main.cf settings, and requests no
|
||||
content filtering for mail from the content filter. This is required or
|
||||
else mail will loop.
|
||||
|
||||
* The "-o receive_override_options" overrides main.cf settings to avoid
|
||||
duplicating work that was already done before the content filter. These
|
||||
options are complementary to the options that are specified in main.cf:
|
||||
|
||||
o We specify "no_unknown_recipient_checks" to disable attempts to find
|
||||
out if a recipient is unknown.
|
||||
|
||||
o We specify "no_header_body_checks" to disable header/body checks.
|
||||
|
||||
o We specify "no_milters" to disable Milter applications (this option is
|
||||
available only in Postfix 2.3 and later).
|
||||
|
||||
o We don't specify "no_address_mappings" here. This enables virtual alias
|
||||
expansion, canonical mappings, address masquerading, and other address
|
||||
mappings after the content filter. The main.cf setting of
|
||||
"receive_override_options" disables these mappings before the content
|
||||
filter.
|
||||
|
||||
These receive override options are either implemented by the SMTP server
|
||||
itself, or they are passed on to the cleanup server.
|
||||
|
||||
* The "-o smtpd_xxx_restrictions" and "-o mynetworks=127.0.0.0/8" override
|
||||
main.cf settings. They turn off junk mail controls that would only waste
|
||||
time here.
|
||||
|
||||
* With "-o smtpd_authorized_xforward_hosts=127.0.0.0/8", the scan transport
|
||||
will try to forward the original client name and IP address to the after-
|
||||
filter smtpd process, so that filtered mail is logged with the real client
|
||||
name and IP address. See XFORWARD_README and smtpd(8).
|
||||
|
||||
AAddvvaanncceedd ccoonntteenntt ffiilltteerr ppeerrffoorrmmaannccee
|
||||
|
||||
With the "sandwich" approach to content filtering described here, it is
|
||||
important to match the filter concurrency to the available CPU, memory and I/
|
||||
O resources. Too few content filter processes and mail accumulates in the
|
||||
active queue even with low traffic volume; too much concurrency and Postfix
|
||||
ends up deferring mail destined for the content filter because processes fail
|
||||
due to insufficient resources.
|
||||
|
||||
Currently, content filter performance tuning is a process of trial and error;
|
||||
analysis is handicapped because filtered and unfiltered messages share the same
|
||||
queue. As mentioned in the introduction of this document, content filtering
|
||||
with multiple Postfix instances will be covered in a future version.
|
||||
|
||||
TTuurrnniinngg ooffff tthhee aaddvvaanncceedd ccoonntteenntt ffiilltteerr
|
||||
|
||||
To turn off "advanced" content filtering:
|
||||
|
||||
* Delete or comment out the two following main.cf lines. The other changes
|
||||
made for advanced content filtering have no effect when content filtering
|
||||
is turned off.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
content_filter = scan:localhost:10025
|
||||
receive_override_options = no_address_mappings
|
||||
|
||||
* Execute "ppoossttssuuppeerr --rr AALLLL" to remove content filter request records from
|
||||
existing queue files.
|
||||
|
||||
* Execute another "ppoossttffiixx rreellooaadd".
|
||||
|
||||
FFiilltteerriinngg mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
|
||||
|
||||
The easiest approach is to configure ONE Postfix instance with multiple SMTP
|
||||
server IP addresses in master.cf:
|
||||
|
||||
* Two SMTP server IP addresses for mail from inside users only, with content
|
||||
filtering turned off.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# ==================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# ==================================================================
|
||||
1.2.3.4:smtp inet n - n - - smtpd
|
||||
-o smtpd_client_restrictions=permit_mynetworks,reject
|
||||
127.0.0.1:smtp inet n - n - - smtpd
|
||||
-o smtpd_client_restrictions=permit_mynetworks,reject
|
||||
|
||||
* One SMTP server address for mail from outside users with content filtering
|
||||
turned on.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# =================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =================================================================
|
||||
1.2.3.5:smtp inet n - n - - smtpd
|
||||
-o content_filter=filter-service:filter-destination
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
After this, you can follow the same procedure as outlined in the "advanced" or
|
||||
"simple" content filtering examples above, except that you must not specify
|
||||
"content_filter" or "receive_override_options" in the main.cf file.
|
||||
|
||||
DDiiffffeerreenntt ffiilltteerrss ffoorr ddiiffffeerreenntt ddoommaaiinnss
|
||||
|
||||
If you are an MX service provider and want to apply different content filters
|
||||
for different domains, you can configure ONE Postfix instance with multiple
|
||||
SMTP server IP addresses in master.cf. Each address provides a different
|
||||
content filter service.
|
||||
|
||||
/etc/postfix.master.cf:
|
||||
# =================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =================================================================
|
||||
# SMTP service for domains that are filtered with service1:dest1
|
||||
1.2.3.4:smtp inet n - n - - smtpd
|
||||
-o content_filter=service1:dest1
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
# SMTP service for domains that are filtered with service2:dest2
|
||||
1.2.3.5:smtp inet n - n - - smtpd
|
||||
-o content_filter=service2:dest2
|
||||
-o receive_override_options=no_address_mappings
|
||||
|
||||
After this, you can follow the same procedure as outlined in the "advanced" or
|
||||
"simple" content filtering examples above, except that you must not specify
|
||||
"content_filter" or "receive_override_options" in the main.cf file.
|
||||
|
||||
Set up MX records in the DNS that route each domain to the proper SMTP server
|
||||
instance.
|
||||
|
||||
FFIILLTTEERR aaccttiioonnss iinn aacccceessss oorr hheeaaddeerr//bbooddyy ttaabblleess
|
||||
|
||||
The above filtering configurations are static. Mail that follows a given path
|
||||
is either always filtered or it is never filtered. As of Postfix 2.0 you can
|
||||
also turn on content filtering on the fly.
|
||||
|
||||
To turn on content filtering with an access(5) table rule:
|
||||
|
||||
/etc/postfix/access:
|
||||
whatever FILTER foo:bar
|
||||
|
||||
To turn on content filtering with a header_checks(5) or body_checks(5) table
|
||||
pattern:
|
||||
|
||||
/etc/postfix/header_checks:
|
||||
/whatever/ FILTER foo:bar
|
||||
|
||||
You can do this in smtpd access maps as well as the cleanup server's header/
|
||||
body_checks. This feature must be used with great care: you must disable all
|
||||
the UCE features in the after-filter smtpd and cleanup daemons or else you will
|
||||
have a content filtering loop.
|
||||
|
||||
Limitations:
|
||||
|
||||
* FILTER actions from smtpd access maps and header/body_checks take
|
||||
precedence over filters specified with the main.cf content_filter
|
||||
parameter.
|
||||
|
||||
* If a message triggers more than one filter action, only the last one takes
|
||||
effect.
|
||||
|
||||
* The same content filter is applied to all the recipients of a given
|
||||
message.
|
||||
|
||||
480
README_FILES/FORWARD_SECRECY_README
Normal file
480
README_FILES/FORWARD_SECRECY_README
Normal file
|
|
@ -0,0 +1,480 @@
|
|||
TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
WWaarrnniinngg
|
||||
|
||||
Forward secrecy does not protect against active attacks such as forged DNS
|
||||
replies or forged TLS server certificates. If such attacks are a concern, then
|
||||
the SMTP client will need to authenticate the remote SMTP server in a
|
||||
sufficiently-secure manner. For example, by the fingerprint of a (CA or leaf)
|
||||
public key or certificate. Conventional PKI relies on many trusted parties and
|
||||
is easily subverted by a state-funded adversary.
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
Postfix supports forward secrecy of TLS network communication since version
|
||||
2.2. This support was adopted from Lutz Ja"nicke's "Postfix TLS patch" for
|
||||
earlier Postfix versions. This document will focus on TLS Forward Secrecy in
|
||||
the Postfix SMTP client and server. See TLS_README for a general description of
|
||||
Postfix TLS support.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Give me some background on forward secrecy in Postfix
|
||||
|
||||
o What is Forward Secrecy
|
||||
o Forward Secrecy in TLS
|
||||
o Forward Secrecy in the Postfix SMTP Server
|
||||
o Forward Secrecy in the Postfix SMTP Client
|
||||
|
||||
* Never mind, just show me what it takes to get forward secrecy
|
||||
|
||||
o Getting started, quick and dirty
|
||||
o How can I see that a connection has forward secrecy?
|
||||
o What ciphers provide forward secrecy?
|
||||
o What do "Anonymous", "Untrusted", etc. in Postfix logging mean?
|
||||
|
||||
* Credits
|
||||
|
||||
WWhhaatt iiss FFoorrwwaarrdd SSeeccrreeccyy
|
||||
|
||||
The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy") is used to
|
||||
describe security protocols in which the confidentiality of past traffic is not
|
||||
compromised when long-term keys used by either or both sides are later
|
||||
disclosed.
|
||||
|
||||
Forward secrecy is accomplished by negotiating session keys using per-session
|
||||
cryptographically-strong random numbers that are not saved, and signing the
|
||||
exchange with long-term authentication keys. Later disclosure of the long-term
|
||||
keys allows impersonation of the key holder from that point on, but not
|
||||
recovery of prior traffic, since with forward secrecy, the discarded random key
|
||||
agreement inputs are not available to the attacker.
|
||||
|
||||
Forward secrecy is only "perfect" when brute-force attacks on the key agreement
|
||||
algorithm are impractical even for the best-funded adversary and the random-
|
||||
number generators used by both parties are sufficiently strong. Otherwise,
|
||||
forward secrecy leaves the attacker with the challenge of cracking the key-
|
||||
agreement protocol, which is likely quite computationally intensive, but may be
|
||||
feasible for sessions of sufficiently high value. Thus forward secrecy places
|
||||
cost constraints on the efficacy of bulk surveillance, recovering all past
|
||||
traffic is generally infeasible, and even recovery of individual sessions may
|
||||
be infeasible given a sufficiently-strong key agreement method.
|
||||
|
||||
FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS
|
||||
|
||||
Early implementations of the SSL protocol do not provide forward secrecy (some
|
||||
provide it only with artificially-weakened "export" cipher suites, but we will
|
||||
ignore those here). The client sends a random "pre-master secret" to the server
|
||||
encrypted with the server's RSA public key. The server decrypts this with its
|
||||
private key, and uses it together with other data exchanged in the clear to
|
||||
generate the session key. An attacker with access to the server's private key
|
||||
can perform the same computation at any later time.
|
||||
|
||||
Later revisions to the TLS protocol introduced forward-secrecy cipher suites in
|
||||
which the client and server implement a key exchange protocol based on
|
||||
ephemeral secrets. Sessions encrypted with one of these newer cipher suites are
|
||||
not compromised by future disclosure of long-term authentication keys.
|
||||
|
||||
The key-exchange algorithms used for forward secrecy require the TLS server to
|
||||
designate appropriate "parameters" consisting of a mathematical "group" and an
|
||||
element of that group called a "generator". Presently, there are two flavors of
|
||||
"groups" that work with PFS:
|
||||
|
||||
* FFFFDDHHEE:: Finite-field Diffie-Hellman ephemeral key exchange groups (also EDH
|
||||
or DHE). The server needs to be configured with a suitably-large prime and
|
||||
a corresponding "generator". Standard choices of the prime and generator
|
||||
are specified in RFC7919, and can be used in the TLS 1.3 protocol with the
|
||||
server and client negotiating a mutually supported choice. In earlier
|
||||
versions of TLS (1.0 through 1.2), when FFDHE key exchange is performed,
|
||||
the server chooses the prime and generator unilaterally.
|
||||
|
||||
* EEEECCDDHH:: This is short for Ephemeral Elliptic Curve Diffie-Hellman (also
|
||||
abbreviated as ECDHE). EECDH offers better security at lower computational
|
||||
cost than FFDHE. Elliptic curves used in cryptography are typically
|
||||
identified by a "name" that stands for a set of well-known parameter
|
||||
values, and it is these "named curves" (or, in certificates, associated
|
||||
ASN.1 object identifiers) that are used in the TLS protocol. When EECDH key
|
||||
exchange is used, a mutually supported named curve is negotiated as part of
|
||||
the TLS handshake.
|
||||
|
||||
FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr
|
||||
|
||||
The Postfix >= 2.2 SMTP server supports forward secrecy in its default
|
||||
configuration. If the remote SMTP client prefers cipher suites with forward
|
||||
secrecy, then the traffic between the server and client will resist decryption
|
||||
even if the server's long-term authentication keys are later compromised.
|
||||
|
||||
Most remote SMTP clients now support forward secrecy (the only choice as of TLS
|
||||
1.3), but some may prefer cipher suites without forward secrecy. Postfix >= 2.8
|
||||
servers can be configured to override the client's preference by setting
|
||||
"tls_preempt_cipherlist = yes".
|
||||
|
||||
FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt
|
||||
|
||||
Postfix >= 3.1 supports 2048-bit-prime FFDHE out of the box, with no additional
|
||||
configuration. You can also generate your own FFDHE parameters, but this is not
|
||||
necessary and no longer recommended. See the quick-start section for details.
|
||||
|
||||
Postfix >= 3.8 supports the finite-field Diffie-Hellman ephemeral (FFDHE) key
|
||||
exchange group negotiation API of OpenSSL >= 3.0. FFDHE groups are explicitly
|
||||
negotiated between client and server starting with TLS 1.3. In earlier TLS
|
||||
versions, the server chooses the group unilaterally. The list of candidate
|
||||
FFDHE groups can be configured via "tls_ffdhe_auto_groups", which can be used
|
||||
to select a prioritized list of supported groups (most preferred first) on both
|
||||
the server and client. The default list is suitable for most users. Either, but
|
||||
not both of "tls_eecdh_auto_curves" and "tls_ffdhe_auto_groups" may be set
|
||||
empty, disabling either EC or FFDHE key exchange in OpenSSL 3.0 with TLS 1.3.
|
||||
That said, interoperability will be poor if the EC curves are all disabled or
|
||||
don't include the most widely used curves.
|
||||
|
||||
EEEECCDDHH SSeerrvveerr ssuuppppoorrtt
|
||||
|
||||
As of Postfix 3.2 and OpenSSL 1.0.2, a range of supported EECDH curves is
|
||||
enabled in the server and client, and a suitable mutually supported curve is
|
||||
negotiated as part of the TLS handshake. The list of supported curves is
|
||||
configurable via the "tls_eecdh_auto_curves" parameter. With TLS 1.2 the server
|
||||
needs to leave its setting of "smtpd_tls_eecdh_grade" at the default value of
|
||||
"auto" (earlier choices of an explicit single curve grade are deprecated). With
|
||||
TLS 1.3, the "smtpd_tls_eecdh_grade" parameter is not used, and curve selection
|
||||
is unconditionally negotiated.
|
||||
|
||||
FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt
|
||||
|
||||
The Postfix >= 2.2 SMTP client supports forward secrecy in its default
|
||||
configuration. All supported OpenSSL releases support both FFDHE and EECDH key
|
||||
exchange. If the remote SMTP server supports cipher suites with forward secrecy
|
||||
(and does not override the SMTP client's cipher preference), then the traffic
|
||||
between the server and client will resist decryption even if the server's long-
|
||||
term authentication keys are later compromised. Forward secrecy is always on in
|
||||
TLS 1.3.
|
||||
|
||||
Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
|
||||
of candidate curves can be changed via the "tls_eecdh_auto_curves"
|
||||
configuration parameter, which can be used to select a prioritized list of
|
||||
supported curves (most preferred first) on both the Postfix SMTP server and
|
||||
SMTP client. The default list is suitable for most users.
|
||||
|
||||
Postfix >= 3.8 supports the finite-field Diffie-Hellman ephemeral (FFDHE) key
|
||||
exchange group negotiation API of OpenSSL >= 3.0. The list of candidate FFDHE
|
||||
groups can be configured via "tls_ffdhe_auto_groups", which can be used to
|
||||
select a prioritized list of supported groups (most preferred first) on both
|
||||
the server and client. The default list is suitable for most users.
|
||||
|
||||
The default Postfix SMTP client cipher lists are correctly ordered to prefer
|
||||
EECDH and FFDHE cipher suites ahead of similar cipher suites that don't
|
||||
implement forward secrecy. Administrators are strongly discouraged from
|
||||
changing the cipher list definitions.
|
||||
|
||||
GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
|
||||
|
||||
EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 33..22 wwiitthh OOppeennSSSSLL >>== 11..11..11))
|
||||
|
||||
This works "out of the box" with no need for additional configuration.
|
||||
|
||||
Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
|
||||
of candidate curves can be changed via the "tls_eecdh_auto_curves"
|
||||
configuration parameter, which can be used to select a prioritized list of
|
||||
supported curves (most preferred first) on both the Postfix SMTP server and
|
||||
SMTP client. The default list is suitable for most users.
|
||||
|
||||
EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 33..22 wwiitthh OOppeennSSSSLL >>== 11..11..11))
|
||||
|
||||
This works "out of the box" with no need for additional configuration.
|
||||
|
||||
Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
|
||||
of candidate curves can be changed via the "tls_eecdh_auto_curves"
|
||||
configuration parameter, which can be used to select a prioritized list of
|
||||
supported curves (most preferred first) on both the Postfix SMTP server and
|
||||
SMTP client. The default list is suitable for most users.
|
||||
|
||||
FFFFDDHHEE CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 33..22,, OOppeennSSSSLL >>== 11..11..11))
|
||||
|
||||
In Postfix < 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or below works
|
||||
"out of the box", no additional configuration is necessary. The most one can do
|
||||
is (not advisable) disable all "kDHE" ciphers, which would then disable FFDHE
|
||||
key exchange in TLS 1.2 and below.
|
||||
|
||||
With OpenSSL 1.1.1, FFDHE is not supported for TLS 1.3, which uses only EECDH
|
||||
key exchange. Support for FFDHE with TLS 1.3 was added in OpenSSL 3.0. With
|
||||
OpenSSL 3.0 and Postfix 3.8 the list of supported TLS 1.3 FFDHE groups becomes
|
||||
configurable via the "tls_ffdhe_auto_groups" parameter, which can be set empty
|
||||
to disable FFDHE in TLS 1.3, or conversely expanded to support more groups. The
|
||||
default should work well for most users.
|
||||
|
||||
FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
|
||||
|
||||
In Postfix < 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or below works
|
||||
"out of the box", no additional configuration is necessary. One can of course
|
||||
(not advisable) disable all "kDHE" ciphers, which would then disable FFDHE key
|
||||
exchange in TLS 1.2 and below.
|
||||
|
||||
The built-in default Postfix FFDHE group is a 2048-bit group as of Postfix 3.1.
|
||||
You can optionally generate non-default Postfix SMTP server FFDHE parameters
|
||||
for possibly improved security against pre-computation attacks, but this is not
|
||||
necessary or recommended. Just leave "smtpd_tls_dh1024_param_file" at its
|
||||
default empty value.
|
||||
|
||||
The set of FFDHE groups enabled for use with TLS 1.3 becomes configurable with
|
||||
Postfix >= 3.8 and OpenSSL >= 3.0. The default setting of
|
||||
"tls_ffdhe_auto_groups" enables the RFC7919 2048 and 3072-bit groups. If you
|
||||
need more security, you should probably be using EECDH.
|
||||
|
||||
HHooww ccaann II sseeee tthhaatt aa ccoonnnneeccttiioonn hhaass ffoorrwwaarrdd sseeccrreeccyy??
|
||||
|
||||
Postfix can be configured to report information about the negotiated cipher,
|
||||
the corresponding key lengths, and the remote peer certificate or public-key
|
||||
verification status.
|
||||
|
||||
* With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1", the Postfix SMTP
|
||||
client and server will log TLS connection information to the maillog file.
|
||||
The general logfile format is shown below. With TLS 1.3 there may be
|
||||
additional properties logged after the cipher name and bits.
|
||||
|
||||
postfix/smtp[process-id]: Untrusted TLS connection established
|
||||
to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name
|
||||
(actual-key-size/raw-key-size bits)
|
||||
|
||||
postfix/smtpd[process-id]: Anonymous TLS connection established
|
||||
from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name
|
||||
(actual-key-size/raw-key-size bits)
|
||||
|
||||
* With "smtpd_tls_received_header = yes", the Postfix SMTP server will record
|
||||
TLS connection information in the Received: header in the form of comments
|
||||
(text inside parentheses). The general format depends on the
|
||||
smtpd_tls_ask_ccert setting. With TLS 1.3 there may be additional
|
||||
properties logged after the cipher name and bits.
|
||||
|
||||
Received: from host.example.com (host.example.com [192.168.0.2])
|
||||
(using TLSv1 with cipher cipher-name
|
||||
(actual-key-size/raw-key-size bits))
|
||||
(Client CN "host.example.com", Issuer "John Doe" (not
|
||||
verified))
|
||||
|
||||
Received: from host.example.com (host.example.com [192.168.0.2])
|
||||
(using TLSv1 with cipher cipher-name
|
||||
(actual-key-size/raw-key-size bits))
|
||||
(No client certificate requested)
|
||||
|
||||
TLS 1.3 examples. Some of the new attributes may not appear when not
|
||||
applicable or not available in older versions of the OpenSSL library.
|
||||
|
||||
Received: from localhost (localhost [127.0.0.1])
|
||||
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
|
||||
bits)
|
||||
key-exchange X25519 server-signature RSA-PSS (2048 bits)
|
||||
server-digest SHA256)
|
||||
(No client certificate requested)
|
||||
|
||||
Received: from localhost (localhost [127.0.0.1])
|
||||
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
|
||||
bits)
|
||||
key-exchange X25519 server-signature RSA-PSS (2048 bits)
|
||||
server-digest SHA256
|
||||
client-signature ECDSA (P-256) client-digest SHA256)
|
||||
(Client CN "example.org", Issuer "example.org" (not verified))
|
||||
|
||||
o The "key-exchange" attribute records the type of "Diffie-Hellman" group
|
||||
used for key agreement. Possible values include "DHE", "ECDHE",
|
||||
"X25519" and "X448". With "DHE", the bit size of the prime will be
|
||||
reported in parentheses after the algorithm name, with "ECDHE", the
|
||||
curve name.
|
||||
|
||||
o The "server-signature" attribute shows the public key signature
|
||||
algorithm used by the server. With "RSA-PSS", the bit size of the
|
||||
modulus will be reported in parentheses. With "ECDSA", the curve name.
|
||||
If, for example, the server has both an RSA and an ECDSA private key
|
||||
and certificate, it will be possible to track which one was used for a
|
||||
given connection.
|
||||
|
||||
o The new "server-digest" attribute records the digest algorithm used by
|
||||
the server to prepare handshake messages for signing. The Ed25519 and
|
||||
Ed448 signature algorithms do not make use of such a digest, so no
|
||||
"server-digest" will be shown for these signature algorithms.
|
||||
|
||||
o When a client certificate is requested with "smtpd_tls_ask_ccert" and
|
||||
the client uses a TLS client-certificate, the "client-signature" and
|
||||
"client-digest" attributes will record the corresponding properties of
|
||||
the client's TLS handshake signature.
|
||||
|
||||
The next sections will explain what cipher-name, key-size, and peer
|
||||
verification status information to expect.
|
||||
|
||||
WWhhaatt cciipphheerrss pprroovviiddee ffoorrwwaarrdd sseeccrreeccyy??
|
||||
|
||||
There are dozens of ciphers that support forward secrecy. What follows is the
|
||||
beginning of a list of 51 ciphers available with OpenSSL 1.0.1e. The list is
|
||||
sorted in the default Postfix preference order. It excludes null ciphers that
|
||||
only authenticate and don't encrypt, together with export and low-grade ciphers
|
||||
whose encryption is too weak to offer meaningful secrecy. The first column
|
||||
shows the cipher name, and the second shows the key exchange method.
|
||||
|
||||
$ openssl ciphers -v \
|
||||
'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
|
||||
awk '{printf "%-32s %s\n", $1, $3}'
|
||||
AECDH-AES256-SHA Kx=ECDH
|
||||
ECDHE-RSA-AES256-GCM-SHA384 Kx=ECDH
|
||||
ECDHE-ECDSA-AES256-GCM-SHA384 Kx=ECDH
|
||||
ECDHE-RSA-AES256-SHA384 Kx=ECDH
|
||||
ECDHE-ECDSA-AES256-SHA384 Kx=ECDH
|
||||
ECDHE-RSA-AES256-SHA Kx=ECDH
|
||||
ECDHE-ECDSA-AES256-SHA Kx=ECDH
|
||||
ADH-AES256-GCM-SHA384 Kx=DH
|
||||
ADH-AES256-SHA256 Kx=DH
|
||||
ADH-AES256-SHA Kx=DH
|
||||
ADH-CAMELLIA256-SHA Kx=DH
|
||||
DHE-DSS-AES256-GCM-SHA384 Kx=DH
|
||||
DHE-RSA-AES256-GCM-SHA384 Kx=DH
|
||||
DHE-RSA-AES256-SHA256 Kx=DH
|
||||
...
|
||||
|
||||
To date, all ciphers that support forward secrecy have one of five values for
|
||||
the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or
|
||||
"DHE". Ciphers that don't implement forward secrecy have names that don't start
|
||||
with one of these prefixes. This pattern is likely to persist until some new
|
||||
key-exchange mechanism is invented that also supports forward secrecy.
|
||||
|
||||
The actual key length and raw algorithm key length are generally the same with
|
||||
non-export ciphers, but they may differ for the legacy export ciphers where the
|
||||
actual key is artificially shortened.
|
||||
|
||||
Starting with TLS 1.3 the cipher name no longer contains enough information to
|
||||
determine which forward-secrecy scheme was employed, but TLS 1.3 aallwwaayyss uses
|
||||
forward-secrecy. On the client side, up-to-date Postfix releases log additional
|
||||
information for TLS 1.3 connections, reporting the signature and key exchange
|
||||
algorithms. Two examples below (the long single line messages are folded across
|
||||
multiple lines for readability):
|
||||
|
||||
postfix/smtp[process-id]:
|
||||
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
|
||||
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
|
||||
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
|
||||
SHA256
|
||||
client-signature ECDSA (P-256) client-digest SHA256
|
||||
|
||||
postfix/smtp[process-id]:
|
||||
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
|
||||
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
|
||||
key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
|
||||
SHA256
|
||||
|
||||
In the above connections, the "key-exchange" value records the "Diffie-Hellman"
|
||||
algorithm used for key agreement. The "server-signature" value records the
|
||||
public key algorithm used by the server to sign the key exchange. The "server-
|
||||
digest" value records any hash algorithm used to prepare the data for signing.
|
||||
With "ED25519" and "ED448", no separate hash algorithm is used.
|
||||
|
||||
Examples of Postfix SMTP server logging:
|
||||
|
||||
postfix/smtpd[process-id]:
|
||||
Untrusted TLS connection established from localhost[127.0.0.1]:25:
|
||||
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
|
||||
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
|
||||
SHA256
|
||||
client-signature ECDSA (P-256) client-digest SHA256
|
||||
|
||||
postfix/smtpd[process-id]:
|
||||
Anonymous TLS connection established from localhost[127.0.0.1]:
|
||||
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
|
||||
server-signature RSA-PSS (2048 bits) server-digest SHA256
|
||||
|
||||
postfix/smtpd[process-id]:
|
||||
Anonymous TLS connection established from localhost[127.0.0.1]:
|
||||
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
|
||||
server-signature ED25519
|
||||
|
||||
Note that Postfix >= 3.4 server logging may also include a "to sni-name"
|
||||
element to record the use of an alternate server certificate chain for the
|
||||
connection in question. This happens when the client uses the TLS SNI
|
||||
extension, and the server selects a non-default certificate chain based on the
|
||||
client's SNI value:
|
||||
|
||||
postfix/smtpd[process-id]:
|
||||
Untrusted TLS connection established from client.example[192.0.2.1]
|
||||
to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
|
||||
bits)
|
||||
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
|
||||
SHA256
|
||||
client-signature ECDSA (P-256) client-digest SHA256
|
||||
|
||||
WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusstteedd"",, eettcc.. iinn PPoossttffiixx llooggggiinngg mmeeaann??
|
||||
|
||||
The verification levels below are subject to man-in-the-middle attacks to
|
||||
different degrees. If such attacks are a concern, then the SMTP client will
|
||||
need to authenticate the remote SMTP server in a sufficiently-secure manner.
|
||||
For example, by the fingerprint of a (CA or leaf) public key or certificate.
|
||||
Remember that conventional PKI relies on many trusted parties and is easily
|
||||
subverted by a state-funded adversary.
|
||||
|
||||
AAnnoonnyymmoouuss (no peer certificate)
|
||||
PPoossttffiixx SSMMTTPP cclliieenntt:: With opportunistic TLS (the "may" security level) the
|
||||
Postfix SMTP client does not verify any information in the peer
|
||||
certificate. In this case it enables and prefers anonymous cipher suites in
|
||||
which the remote SMTP server does not present a certificate (these ciphers
|
||||
offer forward secrecy of necessity). When the remote SMTP server also
|
||||
supports anonymous TLS, and agrees to such a cipher suite, the verification
|
||||
status will be logged as "Anonymous".
|
||||
|
||||
PPoossttffiixx SSMMTTPP sseerrvveerr:: This is by far most common, as client certificates are
|
||||
optional, and the Postfix SMTP server does not request client certificates
|
||||
by default (see smtpd_tls_ask_ccert). Even when client certificates are
|
||||
requested, the remote SMTP client might not send a certificate. Unlike the
|
||||
Postfix SMTP client, the Postfix SMTP server "anonymous" verification
|
||||
status does not imply that the cipher suite is anonymous, which corresponds
|
||||
to the server not sending a certificate.
|
||||
|
||||
UUnnttrruusstteedd (peer certificate not signed by trusted CA)
|
||||
PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server presented a certificate, but
|
||||
the Postfix SMTP client was unable to check the issuing CA signature. With
|
||||
opportunistic TLS this is common with remote SMTP servers that don't
|
||||
support anonymous cipher suites.
|
||||
|
||||
PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client presented a certificate, but
|
||||
the Postfix SMTP server was unable to check the issuing CA signature. This
|
||||
can happen when the server is configured to request client certificates
|
||||
(see smtpd_tls_ask_ccert).
|
||||
|
||||
TTrruusstteedd (peer certificate signed by trusted CA, unverified peer name)
|
||||
PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
|
||||
CA that the Postfix SMTP client trusts, but either the client was not
|
||||
configured to verify the destination server name against the certificate,
|
||||
or the server certificate did not contain any matching names. This is
|
||||
common with opportunistic TLS (smtp_tls_security_level is "may" or else
|
||||
"dane" with no usable TLSA DNS records) when the Postfix SMTP client's
|
||||
trusted CAs can verify the authenticity of the remote SMTP server's
|
||||
certificate, but the client is not configured or unable to verify the
|
||||
server name.
|
||||
|
||||
PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client certificate was signed by a CA
|
||||
that the Postfix SMTP server trusts. The Postfix SMTP server never verifies
|
||||
the remote SMTP client name against the names in the client certificate.
|
||||
Since the client chooses to connect to the server, the Postfix SMTP server
|
||||
has no expectation of a particular client hostname.
|
||||
|
||||
VVeerriiffiieedd (peer certificate signed by trusted CA and verified peer name; or:
|
||||
peer certificate with expected public-key or certificate fingerprint)
|
||||
PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
|
||||
CA that the Postfix SMTP client trusts, and the certificate name matches
|
||||
the destination or server name(s). The Postfix SMTP client was configured
|
||||
to require a verified name, otherwise the verification status would have
|
||||
been just "Trusted".
|
||||
|
||||
PPoossttffiixx SSMMTTPP cclliieenntt:: The "Verified" status may also mean that the Postfix
|
||||
SMTP client successfully matched the expected fingerprint against the
|
||||
remote SMTP server public key or certificate. The expected fingerprint may
|
||||
come from smtp_tls_policy_maps or from TLSA (secure) DNS records. The
|
||||
Postfix SMTP client ignores the CA signature.
|
||||
|
||||
PPoossttffiixx SSMMTTPP sseerrvveerr:: The status is never "Verified", because the Postfix
|
||||
SMTP server never verifies the remote SMTP client name against the names in
|
||||
the client certificate, and because the Postfix SMTP server does not expect
|
||||
a specific fingerprint in the client public key or certificate.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* TLS support for Postfix was originally developed by Lutz Ja"nicke at
|
||||
Cottbus Technical University.
|
||||
* Wietse Venema adopted and restructured the code and documentation.
|
||||
* Viktor Dukhovni implemented support for many subsequent TLS features,
|
||||
including EECDH, and authored the initial version of this document.
|
||||
|
||||
1168
README_FILES/INSTALL
Normal file
1168
README_FILES/INSTALL
Normal file
File diff suppressed because it is too large
Load diff
250
README_FILES/IPV6_README
Normal file
250
README_FILES/IPV6_README
Normal file
|
|
@ -0,0 +1,250 @@
|
|||
PPoossttffiixx IIPPvv66 SSuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix 2.2 introduces support for the IPv6 (IP version 6) protocol. IPv6
|
||||
support for older Postfix versions was available as an add-on patch. The
|
||||
section "Compatibility with Postfix <2.2 IPv6 support" below discusses the
|
||||
differences between these implementations.
|
||||
|
||||
The main feature of interest is that IPv6 uses 128-bit IP addresses instead of
|
||||
the 32-bit addresses used by IPv4. It can therefore accommodate a much larger
|
||||
number of hosts and networks without ugly kluges such as NAT. A side benefit of
|
||||
the much larger address space is that it makes random network scanning
|
||||
impractical.
|
||||
|
||||
Postfix uses the same SMTP protocol over IPv6 as it already uses over the older
|
||||
IPv4 network, and does AAAA record lookups in the DNS in addition to the older
|
||||
A records.
|
||||
|
||||
This document provides information on the following topics:
|
||||
|
||||
* Supported platforms
|
||||
* Configuration
|
||||
* Known limitations
|
||||
* Compatibility with Postfix <2.2 IPv6 support
|
||||
* IPv6 Support for unsupported platforms
|
||||
* Credits
|
||||
|
||||
SSuuppppoorrtteedd PPllaattffoorrmmss
|
||||
|
||||
Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:
|
||||
|
||||
* AIX 5.1+
|
||||
* Darwin 7.3+
|
||||
* FreeBSD 4+
|
||||
* Linux 2.4+
|
||||
* NetBSD 1.5+
|
||||
* OpenBSD 2+
|
||||
* Solaris 8+
|
||||
* Tru64Unix V5.1+
|
||||
|
||||
On other platforms Postfix will simply use IPv4 as it has always done.
|
||||
|
||||
See "IPv6 Support for unsupported platforms" for tips to port Postfix IPv6
|
||||
support to other environments.
|
||||
|
||||
CCoonnffiigguurraattiioonn
|
||||
|
||||
Postfix IPv6 support introduces two new main.cf configuration parameters, and
|
||||
introduces an important change in address syntax notation in match lists such
|
||||
as mynetworks or debug_peer_list.
|
||||
|
||||
Postfix IPv6 address syntax is a little tricky, because there are a few places
|
||||
where you must enclose an IPv6 address inside "[]" characters, and a few places
|
||||
where you must not. It is a good idea to use "[]" only in the few places where
|
||||
you have to. Check out the postconf(5) manual whenever you do IPv6 related
|
||||
configuration work with Postfix.
|
||||
|
||||
* Instead of hard-coding 127.0.0.1 and ::1 loopback addresses in master.cf,
|
||||
specify "inet_interfaces = loopback-only" in main.cf. This way you can use
|
||||
the same master.cf file regardless of whether or not Postfix will run on an
|
||||
IPv6-enabled system.
|
||||
|
||||
* The first new parameter is called inet_protocols. This specifies what
|
||||
protocols Postfix will use when it makes or accepts network connections,
|
||||
and also controls what DNS lookups Postfix will use when it makes network
|
||||
connections.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# You must stop/start Postfix after changing this parameter.
|
||||
inet_protocols = all (enable IPv4, and IPv6 if supported)
|
||||
inet_protocols = ipv4 (enable IPv4 only)
|
||||
inet_protocols = ipv4, ipv6 (enable both IPv4 and IPv6)
|
||||
inet_protocols = ipv6 (enable IPv6 only)
|
||||
|
||||
The default is compile-time dependent: "all" when Postfix is built on a
|
||||
software distribution with IPv6 support, "ipv4" otherwise.
|
||||
|
||||
Note 1: you must stop and start Postfix after changing the inet_protocols
|
||||
configuration parameter.
|
||||
|
||||
Note 2: on older Linux and Solaris systems, the setting "inet_protocols =
|
||||
ipv6" will not prevent Postfix from accepting IPv4 connections.
|
||||
|
||||
For an unsupported test option to build Postfix without IPv6 support, see
|
||||
the NO_IPV6 option in the INSTALL document.
|
||||
|
||||
* The other new parameter is smtp_bind_address6. This sets the local
|
||||
interface address for outgoing IPv6 SMTP connections, just like the
|
||||
smtp_bind_address parameter does for IPv4:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1
|
||||
|
||||
* If you left the value of the mynetworks parameter at its default (i.e. no
|
||||
mynetworks setting in main.cf) Postfix will figure out by itself what its
|
||||
network addresses are. This is what a typical setting looks like:
|
||||
|
||||
% postconf mynetworks
|
||||
mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [fe80::]/10 [2001:
|
||||
240:587::]/64
|
||||
|
||||
If you did specify the mynetworks parameter value in main.cf, you need to
|
||||
update the mynetworks value to include the IPv6 networks the system is in.
|
||||
Be sure to specify IPv6 address information inside "[]", like this:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mynetworks = ...IPv4 networks... [::1]/128 [2001:240:587::]/64 ...
|
||||
|
||||
NNOOTTEE:: wwhheenn ccoonnffiigguurriinngg PPoossttffiixx mmaattcchh lliissttss ssuucchh aass mmyynneettwwoorrkkss oorr
|
||||
ddeebbuugg__ppeeeerr__lliisstt,, yyoouu mmuusstt ssppeecciiffyy IIPPvv66 aaddddrreessss iinnffoorrmmaattiioonn iinnssiiddee ""[[]]"" iinn tthhee
|
||||
mmaaiinn..ccff ppaarraammeetteerr vvaalluuee aanndd iinn ffiilleess ssppeecciiffiieedd wwiitthh aa ""//ffiillee//nnaammee"" ppaatttteerrnn..
|
||||
IIPPvv66 aaddddrreesssseess ccoonnttaaiinn tthhee ""::"" cchhaarraacctteerr,, aanndd wwoouulldd ootthheerrwwiissee bbee ccoonnffuusseedd wwiitthh
|
||||
aa ""ttyyppee::ttaabbllee"" ppaatttteerrnn..
|
||||
|
||||
KKnnoowwnn LLiimmiittaattiioonnss
|
||||
|
||||
* Postfix SMTP clients before version 2.8 try to connect over IPv6 before
|
||||
trying IPv4. With more recent Postfix versions, the order of IPv6 versus
|
||||
IPv4 outgoing connection attempts is configurable with the
|
||||
smtp_address_preference parameter.
|
||||
|
||||
* Postfix versions before 2.6 do not support DNSBL (DNS blocklist) lookups
|
||||
for IPv6 client IP addresses.
|
||||
|
||||
* IPv6 does not have class A, B, C, etc. networks. With IPv6 networks, the
|
||||
setting "mynetworks_style = class" has the same effect as the setting
|
||||
"mynetworks_style = subnet".
|
||||
|
||||
* On Tru64Unix and AIX, Postfix can't figure out the local subnet mask and
|
||||
always assumes a /128 network. This is a problem only with
|
||||
"mynetworks_style = subnet" and no explicit mynetworks setting in main.cf.
|
||||
|
||||
CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 IIPPvv66 ssuuppppoorrtt
|
||||
|
||||
Postfix version 2.2 IPv6 support is based on the Postfix/IPv6 patch by Dean
|
||||
Strik and others, but differs in a few minor ways.
|
||||
|
||||
* main.cf: The inet_interfaces parameter does not support the notation "ipv6:
|
||||
all" or "ipv4:all". Use the inet_protocols parameter instead.
|
||||
|
||||
* main.cf: Specify "inet_protocols = all" or "inet_protocols = ipv4, ipv6" in
|
||||
order to enable both IPv4 and IPv6 support.
|
||||
|
||||
* main.cf: The inet_protocols parameter also controls what DNS lookups
|
||||
Postfix will attempt to make when delivering or receiving mail.
|
||||
|
||||
* main.cf: Specify "inet_interfaces = loopback-only" to listen on loopback
|
||||
network interfaces only.
|
||||
|
||||
* The lmtp_bind_address and lmtp_bind_address6 features were omitted. Postfix
|
||||
version 2.3 merged the LMTP client into the SMTP client, so there was no
|
||||
reason to keep adding features to the LMTP client.
|
||||
|
||||
* The SMTP server now requires that IPv6 addresses in SMTP commands are
|
||||
specified as [ipv6:ipv6address], as described in RFC 2821.
|
||||
|
||||
* The IPv6 network address matching code was rewritten from the ground up,
|
||||
and is expected to be closer to the specification. The result may be
|
||||
incompatible with the Postfix/IPv6 patch.
|
||||
|
||||
IIPPvv66 SSuuppppoorrtt ffoorr uunnssuuppppoorrtteedd ppllaattffoorrmmss
|
||||
|
||||
Getting Postfix IPv6 working on other platforms involves the following steps:
|
||||
|
||||
* Specify how Postfix should find the local network interfaces. Postfix needs
|
||||
this information to avoid mailer loops and to find out if mail for user@
|
||||
[ipaddress] is a local or remote destination.
|
||||
|
||||
If your system has the getifaddrs() routine then add the following to your
|
||||
platform-specific section in src/util/sys_defs.h:
|
||||
|
||||
#ifndef NO_IPV6
|
||||
# define HAS_IPV6
|
||||
# define HAVE_GETIFADDRS
|
||||
#endif
|
||||
|
||||
Otherwise, if your system has the SIOCGLIF ioctl() command in /usr/include/
|
||||
*/*.h, add the following to your platform-specific section in src/util/
|
||||
sys_defs.h:
|
||||
|
||||
#ifndef NO_IPV6
|
||||
# define HAS_IPV6
|
||||
# define HAS_SIOCGLIF
|
||||
#endif
|
||||
|
||||
Otherwise, Postfix will have to use the old SIOCGIF commands and get along
|
||||
with reduced IPv6 functionality (it won't be able to figure out your IPv6
|
||||
netmasks, which are needed for "mynetworks_style = subnet". Add this to
|
||||
your platform-specific section in src/util/sys_defs.h:
|
||||
|
||||
#ifndef NO_IPV6
|
||||
# define HAS_IPV6
|
||||
#endif
|
||||
|
||||
* Test if Postfix can figure out its interface information.
|
||||
|
||||
After compiling Postfix in the usual manner, step into the src/util
|
||||
directory and type "mmaakkee iinneett__aaddddrr__llooccaall". Running this file by hand should
|
||||
produce all the interface addresses and network masks, for example:
|
||||
|
||||
% make
|
||||
% cd src/util
|
||||
% make inet_addr_local
|
||||
[... some messages ...]
|
||||
% ./inet_addr_local
|
||||
[... some messages ...]
|
||||
./inet_addr_local: inet_addr_local: configured 2 IPv4 addresses
|
||||
./inet_addr_local: inet_addr_local: configured 4 IPv6 addresses
|
||||
168.100.189.2/255.255.255.224
|
||||
127.0.0.1/255.0.0.0
|
||||
fe80:1::2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
|
||||
2001:240:587:0:2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
|
||||
fe80:5::1/ffff:ffff:ffff:ffff::
|
||||
::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|
||||
|
||||
The above is for an old FreeBSD machine. Other systems produce slightly
|
||||
different results, but you get the idea.
|
||||
|
||||
If none of all this produces a usable result, send email to the postfix-
|
||||
users@postfix.org mailing list and we'll try to help you through this.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
The following information is in part based on information that was compiled by
|
||||
Dean Strik.
|
||||
|
||||
* Mark Huizer wrote the original Postfix IPv6 patch.
|
||||
|
||||
* Jun-ichiro 'itojun' Hagino of the KAME project made substantial
|
||||
improvements. Since then, we speak of the KAME patch.
|
||||
|
||||
* The PLD Linux Distribution ported the code to other stacks (notably USAGI).
|
||||
We speak of the PLD patch. A very important feature of the PLD patch was
|
||||
that it can work with Lutz Jaenicke's TLS patch for Postfix.
|
||||
|
||||
* Dean Strik extended IPv6 support to platforms other than KAME and USAGI,
|
||||
updated the patch to keep up with Postfix development, and provided a
|
||||
combined IPv6 + TLS patch. Information about his effort is found in an
|
||||
archived copy of Dean Strik's Postfix website at https://web.archive.org/
|
||||
web/20080603102834/http://www.ipnet6.org/postfix/.
|
||||
|
||||
* Wietse Venema took Dean Strik's IPv6 patch, merged it into Postfix 2.2, and
|
||||
took the opportunity to eliminate all IPv4-specific code from Postfix that
|
||||
could be removed. For systems without IPv6 support in the kernel and system
|
||||
libraries, Postfix has a simple compatibility layer, so that it will use
|
||||
IPv4 as before.
|
||||
|
||||
467
README_FILES/LDAP_README
Normal file
467
README_FILES/LDAP_README
Normal file
|
|
@ -0,0 +1,467 @@
|
|||
s!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" "https://
|
||||
www.w3.org/TR/html4/loose.dtd">
|
||||
|
||||
PPoossttffiixx LLDDAAPP HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
LLDDAAPP SSuuppppoorrtt iinn PPoossttffiixx
|
||||
|
||||
Postfix can use an LDAP directory as a source for any of its lookups: aliases
|
||||
(5), virtual(5), canonical(5), etc. This allows you to keep information for
|
||||
your mail service in a replicated network database with fine-grained access
|
||||
controls. By not storing it locally on the mail server, the administrators can
|
||||
maintain it from anywhere, and the users can control whatever bits of it you
|
||||
think appropriate. You can have multiple mail servers using the same
|
||||
information, without the hassle and delay of having to copy it to each.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Building Postfix with LDAP support
|
||||
* Configuring LDAP lookups
|
||||
* Example: aliases
|
||||
* Example: virtual domains/addresses
|
||||
* Example: expanding LDAP groups
|
||||
* Other uses of LDAP lookups
|
||||
* Notes and things to think about
|
||||
* Feedback
|
||||
* Credits
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh LLDDAAPP ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
Note 1: Postfix no longer supports the LDAP version 1 interface.
|
||||
|
||||
Note 2: to use LDAP with Debian GNU/Linux's Postfix, all you need is to install
|
||||
the postfix-ldap package and you're done. There is no need to recompile
|
||||
Postfix.
|
||||
|
||||
You need to have LDAP libraries and include files installed somewhere on your
|
||||
system, and you need to configure the Postfix Makefiles accordingly.
|
||||
|
||||
For example, to build the OpenLDAP libraries for use with Postfix (i.e. LDAP
|
||||
client code only), you could use the following command:
|
||||
|
||||
% ./configure --without-kerberos --without-cyrus-sasl --without-tls \
|
||||
--without-threads --disable-slapd --disable-slurpd \
|
||||
--disable-debug --disable-shared
|
||||
|
||||
If you're using the libraries from OpenLDAP (https://www.openldap.org),
|
||||
something like this in the top level of your Postfix source tree should work:
|
||||
|
||||
% make tidy
|
||||
% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
|
||||
AUXLIBS_LDAP="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
|
||||
|
||||
If your LDAP shared library is in a directory that the RUN-TIME linker does not
|
||||
know about, add a "-Wl,-R,/path/to/directory" option after "-lldap".
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LDAP. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded LDAP database client, but only the new AUXLIBS_LDAP variable supports
|
||||
building a dynamically-loaded or statically-loaded LDAP database client.
|
||||
|
||||
Failure to use the AUXLIBS_LDAP variable will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have LDAP
|
||||
database library dependencies. And that was exactly what dynamic database
|
||||
client loading was meant to avoid.
|
||||
|
||||
On Solaris 2.x you may have to specify run-time link information, otherwise
|
||||
ld.so will not find some of the shared libraries:
|
||||
|
||||
% make tidy
|
||||
% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
|
||||
AUXLIBS_LDAP="-L/usr/local/lib -R/usr/local/lib -lldap \
|
||||
-L/usr/local/lib -R/usr/local/lib -llber"
|
||||
|
||||
The 'make tidy' command is needed only if you have previously built Postfix
|
||||
without LDAP support.
|
||||
|
||||
Instead of '/usr/local' specify the actual locations of your LDAP include files
|
||||
and libraries. Be sure to not mix LDAP include files and LDAP libraries of
|
||||
different versions!!
|
||||
|
||||
If your LDAP libraries were built with Kerberos support, you'll also need to
|
||||
include your Kerberos libraries in this line. Note that the KTH Kerberos IV
|
||||
libraries might conflict with Postfix's lib/libdns.a, which defines dns_lookup.
|
||||
If that happens, you'll probably want to link with LDAP libraries that lack
|
||||
Kerberos support just to build Postfix, as it doesn't support Kerberos binds to
|
||||
the LDAP server anyway. Sorry about the bother.
|
||||
|
||||
If you're using one of the Netscape LDAP SDKs, you'll need to change the
|
||||
AUXLIBS line to point to libldap10.so or libldapssl30.so or whatever you have,
|
||||
and you may need to use the appropriate linker option (e.g. '-R') so the
|
||||
executables can find it at runtime.
|
||||
|
||||
If you are using OpenLDAP, and the libraries were built with SASL support, you
|
||||
can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. For example:
|
||||
|
||||
CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL"
|
||||
|
||||
CCoonnffiigguurriinngg LLDDAAPP llooookkuuppss
|
||||
|
||||
In order to use LDAP lookups, define an LDAP source as a table lookup in
|
||||
main.cf, for example:
|
||||
|
||||
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
|
||||
|
||||
The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters,
|
||||
including parameters that enable LDAP SSL or STARTTLS, and LDAP SASL. For a
|
||||
complete description, see the ldap_table(5) manual page.
|
||||
|
||||
EExxaammppllee:: llooccaall((88)) aalliiaasseess
|
||||
|
||||
Here's a basic example for using LDAP to look up local(8) aliases. Assume that
|
||||
in main.cf, you have:
|
||||
|
||||
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
|
||||
|
||||
and in ldap:/etc/postfix/ldap-aliases.cf you have:
|
||||
|
||||
server_host = ldap.example.com
|
||||
search_base = dc=example, dc=com
|
||||
|
||||
Upon receiving mail for a local address "ldapuser" that isn't found in the /
|
||||
etc/aliases database, Postfix will search the LDAP server listening at port 389
|
||||
on ldap.example.com. It will bind anonymously, search for any directory entries
|
||||
whose mailacceptinggeneralid attribute is "ldapuser", read the "maildrop"
|
||||
attributes of those found, and build a list of their maildrops, which will be
|
||||
treated as RFC822 addresses to which the message will be delivered.
|
||||
|
||||
EExxaammppllee:: vviirrttuuaall ddoommaaiinnss//aaddddrreesssseess
|
||||
|
||||
If you want to keep information for virtual lookups in your directory, it's
|
||||
only a little more complicated. First, you need to make sure Postfix knows
|
||||
about the virtual domain. An easy way to do that is to add the domain to the
|
||||
mailacceptinggeneralid attribute of some entry in the directory. Next, you'll
|
||||
want to make sure all of your virtual recipient's mailacceptinggeneralid
|
||||
attributes are fully qualified with their virtual domains. Finally, if you want
|
||||
to designate a directory entry as the default user for a virtual domain, just
|
||||
give it an additional mailacceptinggeneralid (or the equivalent in your
|
||||
directory) of "@fake.dom". That's right, no user part. If you don't want a
|
||||
catchall user, omit this step and mail to unknown users in the domain will
|
||||
simply bounce.
|
||||
|
||||
In summary, you might have a catchall user for a virtual domain that looks like
|
||||
this:
|
||||
|
||||
dn: cn=defaultrecipient, dc=fake, dc=dom
|
||||
objectclass: top
|
||||
objectclass: virtualaccount
|
||||
cn: defaultrecipient
|
||||
owner: uid=root, dc=someserver, dc=isp, dc=dom
|
||||
1 -> mailacceptinggeneralid: fake.dom
|
||||
2 -> mailacceptinggeneralid: @fake.dom
|
||||
3 -> maildrop: realuser@real.dom
|
||||
|
||||
1: Postfix knows fake.dom is a valid virtual domain when it looks for this
|
||||
and gets something (the maildrop) back.
|
||||
|
||||
2: This causes any mail for unknown users in fake.dom to go to this entry
|
||||
...
|
||||
|
||||
3: ... and then to its maildrop.
|
||||
|
||||
Normal users might simply have one mailacceptinggeneralid and maildrop, e.g.
|
||||
"normaluser@fake.dom" and "normaluser@real.dom".
|
||||
|
||||
EExxaammppllee:: eexxppaannddiinngg LLDDAAPP ggrroouuppss
|
||||
|
||||
LDAP is frequently used to store group member information. There are a number
|
||||
of ways of handling LDAP groups. We will show a few examples in order of
|
||||
increasing complexity, but owing to the number of independent variables, we can
|
||||
only present a tiny portion of the solution space. We show how to:
|
||||
|
||||
1. query groups as lists of addresses;
|
||||
|
||||
2. query groups as lists of user objects containing addresses;
|
||||
|
||||
3. forward special lists unexpanded to a separate list server, for moderation
|
||||
or other processing;
|
||||
|
||||
4. handle complex schemas by controlling expansion and by treating leaf nodes
|
||||
specially, using features that are new in Postfix 2.4.
|
||||
|
||||
The example LDAP entries and implied schema below show two group entries
|
||||
("agroup" and "bgroup") and four user entries ("auser", "buser", "cuser" and
|
||||
"duser"). The group "agroup" has the users "auser" (1) and "buser" (2) as
|
||||
members via DN references in the multi-valued attribute "memberdn", and direct
|
||||
email addresses of two external users "auser@example.org" (3) and
|
||||
"buser@example.org" (4) stored in the multi-valued attribute "memberaddr". The
|
||||
same is true of "bgroup" and "cuser"/"duser" (6)/(7)/(8)/(9), but "bgroup" also
|
||||
has a "maildrop" attribute of "bgroup@mlm.example.com" (5):
|
||||
|
||||
dn: cn=agroup, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapgroup
|
||||
cn: agroup
|
||||
mail: agroup@example.com
|
||||
1 -> memberdn: uid=auser, dc=example, dc=com
|
||||
2 -> memberdn: uid=buser, dc=example, dc=com
|
||||
3 -> memberaddr: auser@example.org
|
||||
4 -> memberaddr: buser@example.org
|
||||
|
||||
dn: cn=bgroup, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapgroup
|
||||
cn: bgroup
|
||||
mail: bgroup@example.com
|
||||
5 -> maildrop: bgroup@mlm.example.com
|
||||
6 -> memberdn: uid=cuser, dc=example, dc=com
|
||||
7 -> memberdn: uid=duser, dc=example, dc=com
|
||||
8 -> memberaddr: cuser@example.org
|
||||
9 -> memberaddr: duser@example.org
|
||||
|
||||
dn: uid=auser, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapuser
|
||||
uid: auser
|
||||
10 -> mail: auser@example.com
|
||||
11 -> maildrop: auser@mailhub.example.com
|
||||
|
||||
dn: uid=buser, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapuser
|
||||
uid: buser
|
||||
12 -> mail: buser@example.com
|
||||
13 -> maildrop: buser@mailhub.example.com
|
||||
|
||||
dn: uid=cuser, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapuser
|
||||
uid: cuser
|
||||
14 -> mail: cuser@example.com
|
||||
|
||||
dn: uid=duser, dc=example, dc=com
|
||||
objectclass: top
|
||||
objectclass: ldapuser
|
||||
uid: duser
|
||||
15 -> mail: duser@example.com
|
||||
|
||||
Our first use case ignores the "memberdn" attributes, and assumes that groups
|
||||
hold only direct "memberaddr" strings as in (3), (4), (8) and (9). The goal is
|
||||
to map the group address to the list of constituent "memberaddr" values. This
|
||||
is simple, ignoring the various connection related settings (hosts, ports, bind
|
||||
settings, timeouts, ...) we have:
|
||||
|
||||
simple.cf:
|
||||
...
|
||||
search_base = dc=example, dc=com
|
||||
query_filter = mail=%s
|
||||
result_attribute = memberaddr
|
||||
$ postmap -q agroup@example.com ldap:/etc/postfix/simple.cf \
|
||||
auser@example.org,buser@example.org
|
||||
|
||||
We search "dc=example, dc=com". The "mail" attribute is used in the
|
||||
query_filter to locate the right group, the "result_attribute" setting
|
||||
described in ldap_table(5) is used to specify that "memberaddr" values from the
|
||||
matching group are to be returned as a comma separated list. Always check
|
||||
tables using postmap(1) with the "-q" option, before deploying them into
|
||||
production use in main.cf.
|
||||
|
||||
Our second use case instead expands "memberdn" attributes (1), (2), (6) and
|
||||
(7), follows the DN references and returns the "maildrop" of the referenced
|
||||
user entries. Here we use the "special_result_attribute" setting from
|
||||
ldap_table(5) to designate the "memberdn" attribute as holding DNs of the
|
||||
desired member entries. The "result_attribute" setting selects which attributes
|
||||
are returned from the selected DNs. It is important to choose a result
|
||||
attribute that is not also present in the group object, because result
|
||||
attributes are collected from both the group and the member DNs. In this case
|
||||
we choose "maildrop" and assume for the moment that groups never have a
|
||||
"maildrop" (the "bgroup" "maildrop" attribute is for a different use case). The
|
||||
returned data for "auser" and "buser" is from items (11) and (13) in the
|
||||
example data.
|
||||
|
||||
special.cf:
|
||||
...
|
||||
search_base = dc=example, dc=com
|
||||
query_filter = mail=%s
|
||||
result_attribute = maildrop
|
||||
special_result_attribute = memberdn
|
||||
$ postmap -q agroup@example.com ldap:/etc/postfix/special.cf \
|
||||
auser@mailhub.example.com,buser@mailhub.example.com
|
||||
|
||||
Note: if the desired member object result attribute is always also present in
|
||||
the group, you get surprising results: the expansion also returns the address
|
||||
of the group. This is a known limitation of Postfix releases prior to 2.4, and
|
||||
is addressed in the new with Postfix 2.4 "leaf_result_attribute" feature
|
||||
described in ldap_table(5).
|
||||
|
||||
Our third use case has some groups that are expanded immediately, and other
|
||||
groups that are forwarded to a dedicated mailing list manager host for delayed
|
||||
expansion. This uses two LDAP tables, one for users and forwarded groups and a
|
||||
second for groups that can be expanded immediately. It is assumed that groups
|
||||
that require forwarding are never nested members of groups that are directly
|
||||
expanded.
|
||||
|
||||
no_expand.cf:
|
||||
...
|
||||
search_base = dc=example, dc=com
|
||||
query_filter = mail=%s
|
||||
result_attribute = maildrop
|
||||
expand.cf
|
||||
...
|
||||
search_base = dc=example, dc=com
|
||||
query_filter = mail=%s
|
||||
result_attribute = maildrop
|
||||
special_result_attribute = memberdn
|
||||
$ postmap -q auser@example.com \
|
||||
ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
|
||||
auser@mailhub.example.com
|
||||
$ postmap -q agroup@example.com \
|
||||
ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
|
||||
auser@mailhub.example.com,buser@mailhub.example.com
|
||||
$ postmap -q bgroup@example.com \
|
||||
ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
|
||||
bgroup@mlm.example.com
|
||||
|
||||
Non-group objects and groups with delayed expansion (those that have a maildrop
|
||||
attribute) are rewritten to a single maildrop value. Groups that don't have a
|
||||
maildrop are expanded as the second use case. This admits a more elegant
|
||||
solution with Postfix 2.4 and later.
|
||||
|
||||
Our final use case is the same as the third, but this time uses new features in
|
||||
Postfix 2.4. We now are able to use just one LDAP table and no longer need to
|
||||
assume that forwarded groups are never nested inside expanded groups.
|
||||
|
||||
fancy.cf:
|
||||
...
|
||||
search_base = dc=example, dc=com
|
||||
query_filter = mail=%s
|
||||
result_attribute = memberaddr
|
||||
special_result_attribute = memberdn
|
||||
terminal_result_attribute = maildrop
|
||||
leaf_result_attribute = mail
|
||||
$ postmap -q auser@example.com ldap:/etc/postfix/fancy.cf \
|
||||
auser@mailhub.example.com
|
||||
$ postmap -q cuser@example.com ldap:/etc/postfix/fancy.cf \
|
||||
cuser@example.com
|
||||
$ postmap -q agroup@example.com ldap:/etc/postfix/fancy.cf \
|
||||
|
||||
auser@mailhub.example.com,buser@mailhub.example.com,auser@example.org,buser@example.org
|
||||
$ postmap -q bgroup@example.com ldap:/etc/postfix/fancy.cf \
|
||||
bgroup@mlm.example.com
|
||||
|
||||
Above, delayed expansion is enabled via "terminal_result_attribute", which, if
|
||||
present, is used as the sole result and all other expansion is suppressed.
|
||||
Otherwise, the "leaf_result_attribute" is only returned for leaf objects that
|
||||
don't have a "special_result_attribute" (non-groups), while the
|
||||
"result_attribute" (direct member address of groups) is returned at every level
|
||||
of recursive expansion, not just the leaf nodes. This fancy example illustrates
|
||||
all the features of Postfix 2.4 group expansion.
|
||||
|
||||
OOtthheerr uusseess ooff LLDDAAPP llooookkuuppss
|
||||
|
||||
Other common uses for LDAP lookups include rewriting senders and recipients
|
||||
with Postfix's canonical lookups, for example in order to make mail leaving
|
||||
your site appear to be coming from "First.Last@example.com" instead of
|
||||
"userid@example.com".
|
||||
|
||||
NNootteess aanndd tthhiinnggss ttoo tthhiinnkk aabboouutt
|
||||
|
||||
* The bits of schema and attribute names used in this document are just
|
||||
examples. There's nothing special about them, other than that some are the
|
||||
defaults in the LDAP configuration parameters. You can use whatever schema
|
||||
you like, and configure Postfix accordingly.
|
||||
|
||||
* You probably want to make sure that mailacceptinggeneralids are unique, and
|
||||
that not just anyone can specify theirs as postmaster or root, say.
|
||||
|
||||
* An entry can have an arbitrary number of mailacceptinggeneralids or
|
||||
maildrops. Maildrops can also be comma-separated lists of addresses. They
|
||||
will all be found and returned by the lookups. For example, you could
|
||||
define an entry intended for use as a mailing list that looks like this
|
||||
(Warning! Schema made up just for this example):
|
||||
|
||||
dn: cn=Accounting Staff List, dc=example, dc=com
|
||||
cn: Accounting Staff List
|
||||
o: example.com
|
||||
objectclass: maillist
|
||||
mailacceptinggeneralid: accountingstaff
|
||||
mailacceptinggeneralid: accounting-staff
|
||||
maildrop: mylist-owner
|
||||
maildrop: an-accountant
|
||||
maildrop: some-other-accountant
|
||||
maildrop: this, that, theother
|
||||
|
||||
* If you use an LDAP map for lookups other than aliases, you may have to make
|
||||
sure the lookup makes sense. In the case of virtual lookups, maildrops
|
||||
other than mail addresses are pretty useless, because Postfix can't know
|
||||
how to set the ownership for program or file delivery. Your qquueerryy__ffiilltteerr
|
||||
should probably look something like this:
|
||||
|
||||
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
|
||||
(maildrop="*:*")(maildrop="*/*"))))
|
||||
|
||||
* And for that matter, even for aliases, you may not want users to be able to
|
||||
specify their maildrops as programs, includes, etc. This might be
|
||||
particularly pertinent on a "sealed" server where they don't have local
|
||||
UNIX accounts, but exist only in LDAP and Cyrus. You might allow the fun
|
||||
stuff only for directory entries owned by an administrative account, so
|
||||
that if the object had a program as its maildrop and weren't owned by
|
||||
"cn=root" it wouldn't be returned as a valid local user. This will require
|
||||
some thought on your part to implement safely, considering the
|
||||
ramifications of this type of delivery. You may decide it's not worth the
|
||||
bother to allow any of that nonsense in LDAP lookups, ban it in the
|
||||
qquueerryy__ffiilltteerr, and keep things like majordomo lists in local alias
|
||||
databases.
|
||||
|
||||
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
|
||||
(maildrop="*:*")(maildrop="*/*"))(owner=cn=root, dc=your, dc=com)))
|
||||
|
||||
* LDAP lookups are slower than local DB or DBM lookups. For most sites they
|
||||
won't be a bottleneck, but it's a good idea to know how to tune your
|
||||
directory service.
|
||||
|
||||
* Multiple LDAP maps share the same LDAP connection if they differ only in
|
||||
their query related parameters: base, scope, query_filter, and so on. To
|
||||
take advantage of this, avoid spurious differences in the definitions of
|
||||
LDAP maps: host selection order, version, bind, tls parameters, ... should
|
||||
be the same for multiple maps whenever possible.
|
||||
|
||||
FFeeeeddbbaacckk
|
||||
|
||||
If you have questions, send them to postfix-users@postfix.org. Please include
|
||||
relevant information about your Postfix setup: LDAP-related output from
|
||||
postconf, which LDAP libraries you built with, and which directory server
|
||||
you're using. If your question involves your directory contents, please include
|
||||
the applicable bits of some directory entries.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* Manuel Guesdon: Spotted a bug with the timeout attribute.
|
||||
* John Hensley: Multiple LDAP sources with more configurable attributes.
|
||||
* Carsten Hoeger: Search scope handling.
|
||||
* LaMont Jones: Domain restriction, URL and DN searches, multiple result
|
||||
attributes.
|
||||
* Mike Mattice: Alias dereferencing control.
|
||||
* Hery Rakotoarisoa: Patches for LDAPv3 updating.
|
||||
* Prabhat K Singh: Wrote the initial Postfix LDAP lookups and connection
|
||||
caching.
|
||||
* Keith Stevenson: RFC 2254 escaping in queries.
|
||||
* Samuel Tardieu: Noticed that searches could include wildcards, prompting
|
||||
the work on RFC 2254 escaping in queries. Spotted a bug in binding.
|
||||
* Sami Haahtinen: Referral chasing and v3 support.
|
||||
* Victor Duchovni: ldap_bind() timeout. With fixes from LaMont Jones:
|
||||
OpenLDAP cache deprecation. Limits on recursion, expansion and search
|
||||
results size. LDAP connection sharing for maps differing only in the query
|
||||
parameters.
|
||||
* Liviu Daia: Support for SSL/STARTTLS. Support for storing map definitions
|
||||
in external files (ldap:/path/ldap.cf) needed to securely store passwords
|
||||
for plain auth.
|
||||
* Liviu Daia revised the configuration interface and added the main.cf
|
||||
configuration feature.
|
||||
* Liviu Daia with further refinements from Jose Luis Tallon and Victor
|
||||
Duchovni developed the common query, result_format, domain and
|
||||
expansion_limit interface for LDAP, MySQL and PosgreSQL.
|
||||
* Gunnar Wrobel provided a first implementation of a feature to limit LDAP
|
||||
search results to leaf nodes only. Victor generalized this into the Postfix
|
||||
2.4 "leaf_result_attribute" feature.
|
||||
* Quanah Gibson-Mount contributed support for advanced LDAP SASL mechanisms,
|
||||
beyond the password-based LDAP "simple" bind.
|
||||
|
||||
And of course Wietse.
|
||||
|
||||
74
README_FILES/LINUX_README
Normal file
74
README_FILES/LINUX_README
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
PPoossttffiixx aanndd LLiinnuuxx
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
HHoosstt llooookkuupp iissssuueess
|
||||
|
||||
By default Linux /etc/hosts lookups do not support multiple IP addresses per
|
||||
hostname. This causes warnings from the Postfix SMTP server that "hostname XXX
|
||||
does not resolve to address YYY", and is especially a problem with hosts that
|
||||
have both IPv4 and IPv6 addresses. To fix this, turn on support for multiple IP
|
||||
addresses:
|
||||
|
||||
/etc/host.conf:
|
||||
...
|
||||
# We have machines with multiple IP addresses.
|
||||
multi on
|
||||
...
|
||||
|
||||
Alternatively, specify the RESOLV_MULTI environment variable in main.cf:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
|
||||
DISPLAY LANG=C RESOLV_MULTI=on
|
||||
|
||||
BBeerrkkeelleeyy DDBB iissssuueess
|
||||
|
||||
If you can't compile Postfix because the file "db.h" isn't found, then you MUST
|
||||
install the Berkeley DB development package (name: db???-devel-???) that
|
||||
matches your system library. You can find out what is installed with the rpm
|
||||
command. For example:
|
||||
|
||||
$ rrppmm --qqff //uussrr//lliibb//lliibbddbb..ssoo
|
||||
db4-4.3.29-2
|
||||
|
||||
This means that you need to install db4-devel-4.3.29-2 (on some systems,
|
||||
specify "rrppmm --qqff //lliibb//lliibbddbb..ssoo" instead).
|
||||
|
||||
DO NOT download some Berkeley DB version from the network. Every Postfix
|
||||
program will dump core when it is built with a different Berkeley DB version
|
||||
than the version that is used by the system library routines. See the DB_README
|
||||
file for further information.
|
||||
|
||||
PPrrooccmmaaiill iissssuueess
|
||||
|
||||
On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write to the
|
||||
mail spool directory. Workaround:
|
||||
|
||||
# chmod 1777 /var/spool/mail
|
||||
|
||||
LLooggggiinngg iinn aa ccoonnttaaiinneerr
|
||||
|
||||
When running Postfix inside a container, you can use stdout logging as
|
||||
described in MAILLOG_README. Alternatives: run syslogd inside the container, or
|
||||
mount the host's syslog socket inside the container.
|
||||
|
||||
SSyyssllooggdd ppeerrffoorrmmaannccee
|
||||
|
||||
LINUX ssyyssllooggdd uses synchronous writes by default. Because of this, ssyyssllooggdd can
|
||||
actually use more system resources than Postfix. To avoid such badness, disable
|
||||
synchronous mail logfile writes by editing /etc/syslog.conf and by prepending a
|
||||
- to the logfile name:
|
||||
|
||||
/etc/syslog.conf:
|
||||
mail.* -/var/log/mail.log
|
||||
|
||||
Send a "kkiillll --HHUUPP" to the ssyyssllooggdd to make the change effective.
|
||||
|
||||
OOtthheerr llooggggiinngg ppeerrffoorrmmaannccee iissssuueess
|
||||
|
||||
LINUX ssyysstteemmdd intercepts all logging and enforces its own rate limits before
|
||||
handing off requests to a backend such as rrssyyssllooggdd or ssyysslloogg--nngg. On a busy mail
|
||||
server this can result in information loss. As a workaround, you can use
|
||||
Postfix's built-in logging as described in MAILLOG_README.
|
||||
|
||||
126
README_FILES/LMDB_README
Normal file
126
README_FILES/LMDB_README
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
PPoossttffiixx OOppeennLLDDAAPP LLMMDDBB HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix uses databases of various kinds to store and look up information.
|
||||
Postfix databases are specified as "type:name". OpenLDAP LMDB (called "LMDB"
|
||||
from here on) implements the Postfix database type "lmdb". The name of a
|
||||
Postfix LMDB database is the name of the database file without the ".lmdb"
|
||||
suffix.
|
||||
|
||||
This document describes:
|
||||
|
||||
* Building Postfix with LMDB support.
|
||||
|
||||
* Configuring LMDB settings.
|
||||
|
||||
* Using LMDB maps with non-Postfix programs.
|
||||
|
||||
* Required minimum LMDB patchlevel.
|
||||
|
||||
* Credits.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh LLMMDDBB ssuuppppoorrtt
|
||||
|
||||
Postfix normally does not enable LMDB support. To build Postfix with LMDB
|
||||
support, use something like:
|
||||
|
||||
% make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
|
||||
AUXLIBS_LMDB="-L/usr/local/lib -llmdb"
|
||||
% make
|
||||
|
||||
If your LMDB shared library is in a directory that the RUN-TIME linker does not
|
||||
know about, add a "-Wl,-R,/path/to/directory" option after "-llmdb".
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LMDB. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded LMDB database client, but only the new AUXLIBS_LMDB variable supports
|
||||
building a dynamically-loaded or statically-loaded LMDB database client.
|
||||
|
||||
Failure to use the AUXLIBS_LMDB variable will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have LMDB
|
||||
database library dependencies. And that was exactly what dynamic database
|
||||
client loading was meant to avoid.
|
||||
|
||||
Solaris may need this:
|
||||
|
||||
% make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
|
||||
AUXLIBS_LMDB="-R/usr/local/lib -L/usr/local/lib -llmdb"
|
||||
% make
|
||||
|
||||
The exact pathnames depend on how LMDB was installed.
|
||||
|
||||
When building Postfix fails with:
|
||||
|
||||
undefined reference to `pthread_mutexattr_destroy'
|
||||
undefined reference to `pthread_mutexattr_init'
|
||||
undefined reference to `pthread_mutex_lock'
|
||||
|
||||
Add the "-lpthread" library to the "make makefiles" command.
|
||||
|
||||
% make makefiles .... AUXLIBS_LMDB="... -lpthread"
|
||||
|
||||
CCoonnffiigguurriinngg LLMMDDBB sseettttiinnggss
|
||||
|
||||
Postfix provides one configuration parameter that controls LMDB database
|
||||
behavior.
|
||||
|
||||
* lmdb_map_size (default: 16777216). This setting specifies the initial LMDB
|
||||
database size limit in bytes. Each time a database becomes "full", its size
|
||||
limit is doubled. The maximum size is the largest signed integer value of
|
||||
"long".
|
||||
|
||||
UUssiinngg LLMMDDBB mmaappss wwiitthh nnoonn--PPoossttffiixx pprrooggrraammss
|
||||
|
||||
Programs that use LMDB's built-in locking protocol will corrupt a Postfix LMDB
|
||||
database or will read garbage.
|
||||
|
||||
Postfix does not use LMDB's built-in locking protocol, because that would
|
||||
require world-writable lockfiles, and would violate Postfix security policy.
|
||||
Instead, Postfix uses external locks based on fcntl(2) to prevent writers from
|
||||
corrupting the database, and to prevent readers from receiving garbage.
|
||||
|
||||
See lmdb_table(5) for a detailed description of the locking protocol that all
|
||||
programs must use when they access a Postfix LMDB database.
|
||||
|
||||
RReeqquuiirreedd mmiinniimmuumm LLMMDDBB ppaattcchhlleevveell
|
||||
|
||||
Currently, Postfix requires LMDB 0.9.11 or later. The required minimum LMDB
|
||||
patchlevel has evolved over time, as the result of Postfix deployment
|
||||
experience:
|
||||
|
||||
* LMDB 0.9.11 allows Postfix daemons to log an LMDB error message, instead of
|
||||
falling out of the sky without any notification.
|
||||
|
||||
* LMDB 0.9.10 closes an information leak where LMDB was writing up to 4-kbyte
|
||||
chunks of uninitialized heap memory to the database. This would persist
|
||||
information that was not meant to be persisted, or share information that
|
||||
was not meant to be shared.
|
||||
|
||||
* LMDB 0.9.9 allows Postfix to use external (fcntl()-based) locks, instead of
|
||||
having to use world-writable LMDB lock files, violating the Postfix
|
||||
security model in multiple ways.
|
||||
|
||||
* LMDB 0.9.8 allows Postfix to recover from a "database full" error without
|
||||
having to close the database. This version adds support to update the
|
||||
database size limit on-the-fly. This is necessary because Postfix database
|
||||
sizes vary with mail server load.
|
||||
|
||||
* LMDB 0.9.7 allows the postmap(1) and postalias(1) commands to use a bulk-
|
||||
mode transaction larger than the amount of physical memory. This is
|
||||
necessary because LMDB supports databases larger than physical memory.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* Howard Chu contributed the initial Postfix dict_lmdb driver.
|
||||
|
||||
* Wietse Venema wrote an abstraction layer (slmdb) that behaves more like
|
||||
Berkeley DB, NDBM, etc. This layer automatically retries an LMDB request
|
||||
when a database needs to be resized, or after a database was resized by a
|
||||
different process.
|
||||
|
||||
* Howard and Wietse went through many iterations with changes to both LMDB
|
||||
and Postfix, with input from Viktor Dukhovni.
|
||||
|
||||
138
README_FILES/LOCAL_RECIPIENT_README
Normal file
138
README_FILES/LOCAL_RECIPIENT_README
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
RReejjeeccttiinngg UUnnkknnoowwnn LLooccaall RReecciippiieennttss wwiitthh PPoossttffiixx
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
As of Postfix version 2.0, the Postfix SMTP server rejects mail for unknown
|
||||
recipients in local domains (domains that match $mydestination or the IP
|
||||
addresses in $inet_interfaces or $proxy_interfaces) with "User unknown in local
|
||||
recipient table". This feature was optional with earlier Postfix versions.
|
||||
|
||||
The good news is that this keeps undeliverable mail out of your queue, so that
|
||||
your mail queue is not clogged up with undeliverable MAILER-DAEMON messages.
|
||||
|
||||
The bad news is that it may cause mail to be rejected when you upgrade from a
|
||||
Postfix system that was not configured to reject mail for unknown local
|
||||
recipients.
|
||||
|
||||
This document describes what steps are needed in order to reject unknown local
|
||||
recipients correctly.
|
||||
|
||||
* Configuring local_recipient_maps in main.cf
|
||||
* When you need to change the local_recipient_maps setting in main.cf
|
||||
* Local recipient table query format
|
||||
|
||||
CCoonnffiigguurriinngg llooccaall__rreecciippiieenntt__mmaappss iinn mmaaiinn..ccff
|
||||
|
||||
The local_recipient_maps parameter specifies lookup tables with all names or
|
||||
addresses of local recipients. A recipient address is local when its domain
|
||||
matches $mydestination, $inet_interfaces or $proxy_interfaces. If a local
|
||||
username or address is not listed in $local_recipient_maps, then the Postfix
|
||||
SMTP server will reject the address with "User unknown in local recipient
|
||||
table". Other interfaces such as the Postfix sendmail(1) command may still
|
||||
accept an "unknown" recipient.
|
||||
|
||||
The default setting, shown below, assumes that you use the default Postfix
|
||||
local(8) delivery agent for local delivery, where recipients are either UNIX
|
||||
accounts (typically, in /etc/passwd) or local aliases (typically, in /etc/
|
||||
aliases):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
|
||||
|
||||
To turn off unknown local recipient rejects by the SMTP server, specify:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_recipient_maps =
|
||||
|
||||
That is, an empty value. With this setting, the Postfix SMTP server will not
|
||||
reject mail with "User unknown in local recipient table". DDoonn''tt ddoo tthhiiss oonn
|
||||
ssyysstteemmss tthhaatt rreecceeiivvee mmaaiill ddiirreeccttllyy ffrroomm tthhee IInntteerrnneett.. WWiitthh ttooddaayy''ss wwoorrmmss aanndd
|
||||
vviirruusseess,, PPoossttffiixx wwiillll bbeeccoommee aa bbaacckkssccaatttteerr ssoouurrccee:: iitt aacccceeppttss mmaaiill ffoorr nnoonn--
|
||||
eexxiisstteenntt rreecciippiieennttss aanndd tthheenn ttrriieess ttoo rreettuurrnn tthhaatt mmaaiill aass ""uunnddeelliivveerraabbllee"" ttoo
|
||||
tthhee oofftteenn ffoorrggeedd sseennddeerr aaddddrreessss.
|
||||
|
||||
WWhheenn yyoouu nneeeedd ttoo cchhaannggee tthhee llooccaall__rreecciippiieenntt__mmaappss sseettttiinngg iinn mmaaiinn..ccff
|
||||
|
||||
* Problem: you don't use the default Postfix local(8) delivery agent for
|
||||
domains matching $mydestination, $inet_interfaces, or $proxy_interfaces.
|
||||
For example, you redefined the "local_transport" setting in main.cf.
|
||||
|
||||
Solution: your local_recipient_maps setting needs to specify a database
|
||||
that lists all the known user names or addresses for that delivery agent.
|
||||
For example, if you deliver users in $mydestination etc. domains via the
|
||||
virtual(8) delivery agent, specify:
|
||||
|
||||
/etc/postfix/main.cf
|
||||
mydestination = $myhostname localhost.$mydomain localhost ...
|
||||
local_transport = virtual
|
||||
local_recipient_maps = $virtual_mailbox_maps
|
||||
|
||||
If you don't use the local(8) or virtual(8) delivery agent for
|
||||
$mydestination etc. domains, see the section "Local recipient table format"
|
||||
below for a description of how the table should be populated.
|
||||
|
||||
* Problem: you use the mailbox_transport or fallback_transport feature of the
|
||||
Postfix local(8) delivery agent in order to deliver mail to non-UNIX
|
||||
recipients.
|
||||
|
||||
Solution: you need to add the database that lists the non-UNIX recipients:
|
||||
|
||||
/etc/postfix/main.cf
|
||||
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
|
||||
<the database with non-UNIX recipients>
|
||||
|
||||
See the section "Local recipient table format" below for a description of
|
||||
how the table should be populated.
|
||||
|
||||
* Problem: you use the luser_relay feature of the Postfix local delivery
|
||||
agent.
|
||||
|
||||
Solution: you must disable the local_recipient_maps feature completely, so
|
||||
that the Postfix SMTP server accepts mail for all local addresses:
|
||||
|
||||
/etc/postfix/main.cf
|
||||
local_recipient_maps =
|
||||
|
||||
LLooccaall rreecciippiieenntt ttaabbllee qquueerryy ffoorrmmaatt
|
||||
|
||||
If local_recipient_maps specifies local files, such as files in postmap(1) or
|
||||
postalias(1) format, then the Postfix SMTP server generates the following
|
||||
queries:
|
||||
|
||||
* The full recipient address. This query supports a non-default
|
||||
local_transport setting with a delivery agent such as lmtp(8) or virtual
|
||||
(8). See "Configuring local_recipient_maps in main.cf: for additional
|
||||
guidance for what lookup tables to specify.
|
||||
|
||||
* The recipient address local-part. This query supports the default
|
||||
local_transport setting with the UNIX-compatible local(8) delivery agent;
|
||||
the Postfix SMTP server makes this query only when the recipient domain
|
||||
matches $mydestination, $inet_interfaces or $proxy_interfaces.
|
||||
|
||||
* The recipient @domain. This query supports a non-default local_transport
|
||||
setting with a delivery agent such as virtual(8); it is a wildcard for
|
||||
domains that do not have a valid recipient list.
|
||||
|
||||
NOTES:
|
||||
|
||||
* A lookup table should return a non-empty result when the address exists,
|
||||
and should return "not found" when the address does not exist. In
|
||||
particular, a zero-length (empty) result does not count as a "not found"
|
||||
result.
|
||||
|
||||
* When local_recipient_maps specifies a lookup table based on ldap:,
|
||||
memcache:, mongodb:, mysql:, pgsql:, sqlite:, or other external database,
|
||||
then the Postfix SMTP server queries that lookup table with the same
|
||||
queries as described at the start of this section, and expects the same
|
||||
results.
|
||||
|
||||
* To suppress lookups for the local-part and the @domain wild-card, specify
|
||||
the ddoommaaiinn setting in a Postfix ldap:, memcache:, mongodb:, mysql:, pgsql:,
|
||||
sqlite:, etc., database client configuration file.
|
||||
|
||||
* When local_recipient_maps specifies a lookup table based on pcre:, regexp:,
|
||||
socketmap: or tcp:, Postfix queries that table only with the full recipient
|
||||
address, and not with the local-part or the @domain wild-card.
|
||||
|
||||
129
README_FILES/MAILDROP_README
Normal file
129
README_FILES/MAILDROP_README
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
PPoossttffiixx ++ MMaaiillddrroopp HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document discusses various options to plug the maildrop delivery agent
|
||||
into Postfix:
|
||||
|
||||
* Direct delivery without the local delivery agent
|
||||
* Indirect delivery via the local delivery agent
|
||||
* Credits
|
||||
|
||||
DDiirreecctt ddeelliivveerryy wwiitthhoouutt tthhee llooccaall ddeelliivveerryy aaggeenntt
|
||||
|
||||
Postfix can be configured to deliver mail directly to maildrop, without using
|
||||
the local(8) delivery agent as an intermediate. This means that you do not get
|
||||
local aliases(5) expansion or $HOME/.forward file processing. You would
|
||||
typically do this for hosted domains with recipients that don't have UNIX home
|
||||
directories.
|
||||
|
||||
The following example shows how to use maildrop for some.domain and for
|
||||
someother.domain. The example comes in two parts.
|
||||
|
||||
Part 1 describes changes to the main.cf file:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 maildrop_destination_recipient_limit = 1
|
||||
3 virtual_mailbox_domains = some.domain someother.domain
|
||||
4 virtual_transport = maildrop
|
||||
5 virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
|
||||
6 virtual_alias_maps = hash:/etc/postfix/virtual_alias
|
||||
7
|
||||
8 /etc/postfix/virtual_mailbox:
|
||||
9 user1@some.domain ...text here does not matter...
|
||||
10 user2@some.domain ...text here does not matter...
|
||||
11 user3@someother.domain ...text here does not matter...
|
||||
12
|
||||
13 /etc/postfix/virtual_alias:
|
||||
14 postmaster@some.domain postmaster
|
||||
15 postmaster@someother.domain postmaster
|
||||
|
||||
* Line 2 is needed so that Postfix will provide one recipient at a time to
|
||||
the maildrop delivery agent.
|
||||
|
||||
* Line 3 informs Postfix that some.domain and someother.domain are so-called
|
||||
virtual mailbox domains. Instead of listing the names in main.cf you can
|
||||
also list them in a file; see the virtual_mailbox_domains documentation for
|
||||
details.
|
||||
|
||||
* Line 4 specifies that mail for some.domain and someother.domain should be
|
||||
delivered by the maildrop delivery agent.
|
||||
|
||||
* Lines 5 and 8-11 specify what recipients the Postfix SMTP server should
|
||||
receive mail for. This prevents the mail queue from becoming clogged with
|
||||
undeliverable messages. Specify an empty value ("virtual_mailbox_maps =")
|
||||
to disable this feature.
|
||||
|
||||
* Lines 6 and 13-15 redirect mail for postmaster to the local postmaster. RFC
|
||||
821 requires that every domain has a postmaster address.
|
||||
|
||||
The vmail userid as used below is the user that maildrop should run as. This
|
||||
would be the owner of the virtual mailboxes if they all have the same owner. If
|
||||
maildrop is suid (see maildrop documentation), then maildrop will change to the
|
||||
appropriate owner to deliver the mail.
|
||||
|
||||
Note: Do not use the postfix user as the maildrop user.
|
||||
|
||||
Part 2 describes changes to the master.cf file:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
maildrop unix - n n - - pipe
|
||||
flags=ODRhu user=vmail argv=/path/to/maildrop -d ${recipient}
|
||||
|
||||
The pipe(8) manual page gives a detailed description of the above command line
|
||||
arguments, and more.
|
||||
|
||||
If you want to support user+extension@domain style addresses, use the following
|
||||
instead:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
maildrop unix - n n - - pipe
|
||||
flags=ODRhu user=vmail argv=/path/to/maildrop
|
||||
-d ${user}@${domain} ${extension} ${recipient} ${user} ${nexthop}
|
||||
|
||||
The mail is delivered to ${user}@${domain} (search key for maildrop userdb
|
||||
lookup). The ${extension} and the other address components are available to
|
||||
maildrop rules as $1, $2, $3, ... and can be omitted from master.cf or ignored
|
||||
by maildrop when not needed.
|
||||
|
||||
With Postfix 2.4 and earlier, use ${nexthop} instead of ${domain}.
|
||||
|
||||
IInnddiirreecctt ddeelliivveerryy vviiaa tthhee llooccaall ddeelliivveerryy aaggeenntt
|
||||
|
||||
Postfix can be configured to deliver mail to maildrop via the local delivery
|
||||
agent. This is slightly less efficient than the "direct" approach discussed
|
||||
above, but gives you the convenience of local aliases(5) expansion and
|
||||
$HOME/.forward file processing. You would typically use this for domains that
|
||||
are listed in mydestination and that have users with a UNIX system account.
|
||||
|
||||
To configure maildrop delivery for all UNIX system accounts:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mailbox_command = /path/to/maildrop -d ${USER}
|
||||
|
||||
Note: ${USER} is spelled in upper case.
|
||||
|
||||
To enable maildrop delivery for specific users only, you can use the Postfix
|
||||
local(8) delivery agent's mailbox_command_maps feature:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mailbox_command_maps = hash:/etc/postfix/mailbox_commands
|
||||
|
||||
/etc/postfix/mailbox_commands:
|
||||
you /path/to/maildrop -d ${USER}
|
||||
|
||||
Maildrop delivery for specific users is also possible by invoking it from the
|
||||
user's $HOME/.forward file:
|
||||
|
||||
/home/you/.forward:
|
||||
"|/path/to/maildrop -d ${USER}"
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* The original text was kindly provided by Russell Mosemann.
|
||||
* Victor Duchovni provided tips for supporting user+foo@domain addresses.
|
||||
* Tonni Earnshaw contributed text about delivery via the local(8) delivery
|
||||
agent.
|
||||
|
||||
123
README_FILES/MAILLOG_README
Normal file
123
README_FILES/MAILLOG_README
Normal file
|
|
@ -0,0 +1,123 @@
|
|||
PPoossttffiixx llooggggiinngg ttoo ffiillee oorr ssttddoouutt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
Postfix supports its own logging system as an alternative to syslog (which
|
||||
remains the default). This is available with Postfix version 3.4 or later.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Configuring logging to file
|
||||
* Configuring logging to stdout
|
||||
* Rotating logs
|
||||
* Limitations
|
||||
|
||||
CCoonnffiigguurriinngg llooggggiinngg ttoo ffiillee
|
||||
|
||||
Logging to file solves a usability problem for MacOS, and eliminates multiple
|
||||
problems for systemd-based systems.
|
||||
|
||||
1. Add the following line to master.cf if not already present (note: there
|
||||
must be no whitespace at the start of the line):
|
||||
|
||||
postlog unix-dgram n - n - 1 postlogd
|
||||
|
||||
Note: the service type "uunniixx--ddggrraamm" was introduced with Postfix 3.4. Remove
|
||||
the above line before backing out to an older Postfix version.
|
||||
|
||||
2. Configure Postfix to write logging, to, for example, /var/log/postfix.log.
|
||||
See also the "Logfile rotation" section below for logfile management.
|
||||
|
||||
In the example below, specifying maillog_file_permissions is optional
|
||||
(Postfix 3.9 and later). The default value is 0600, i.e., only the super-
|
||||
user can access the file; the value 0644 also adds 'group' and 'other' read
|
||||
access.
|
||||
|
||||
# postfix stop
|
||||
# postconf maillog_file=/var/log/postfix.log
|
||||
# postconf maillog_file_permissions=0644 # (Postfix 3.9 and later)
|
||||
# postfix start
|
||||
|
||||
By default, the logfile name must start with "/var" or "/dev/stdout" (the
|
||||
list of allowed prefixes is configured with the maillog_file_prefixes
|
||||
parameter). This safety mechanism limits the damage from a single
|
||||
configuration mistake.
|
||||
|
||||
CCoonnffiigguurriinngg llooggggiinngg ttoo ssttddoouutt
|
||||
|
||||
Logging to stdout is useful when Postfix runs in a container, as it eliminates
|
||||
a syslogd dependency.
|
||||
|
||||
1. Add the following line to master.cf if not already present (note: there
|
||||
must be no whitespace at the start of the line):
|
||||
|
||||
postlog unix-dgram n - n - 1 postlogd
|
||||
|
||||
Note: the service type "uunniixx--ddggrraamm" was introduced with Postfix 3.4. Remove
|
||||
the above line before backing out to an older Postfix version.
|
||||
|
||||
2. Configure main.cf with "maillog_file = /dev/stdout".
|
||||
|
||||
3. Start Postfix with "ppoossttffiixx ssttaarrtt--ffgg".
|
||||
|
||||
RRoottaattiinngg llooggss
|
||||
|
||||
The command "ppoossttffiixx llooggrroottaattee" may be run by hand or by a cronjob. It logs all
|
||||
errors, and reports errors to stderr if run from a terminal. This command
|
||||
implements the following steps:
|
||||
|
||||
* Rename the current logfile by appending a suffix that contains the date and
|
||||
time. This suffix is configured with the maillog_file_rotate_suffix
|
||||
parameter (default: %Y%m%d-%H%M%S).
|
||||
|
||||
* Reload Postfix so that postlogd(8) immediately closes the old logfile.
|
||||
|
||||
* After a brief pause, compress the old logfile. The compression program is
|
||||
configured with the maillog_file_compressor parameter (default: gzip).
|
||||
|
||||
* The next time it logs an event, postlogd(8) will create a new logfile, with
|
||||
permissions specified with the maillog_file_permissions parameter (default:
|
||||
0600).
|
||||
|
||||
Notes:
|
||||
|
||||
* This command will not rotate a logfile with a pathname under the /dev
|
||||
directory, such as /dev/stdout.
|
||||
|
||||
* This command does not (yet) remove old logfiles.
|
||||
|
||||
LLiimmiittaattiioonnss
|
||||
|
||||
Background:
|
||||
|
||||
* Postfix consists of a number of daemon programs that run in the background,
|
||||
as well as non-daemon programs for local mail submission or Postfix
|
||||
management.
|
||||
|
||||
* Logging to the Postfix logfile or stdout requires the Postfix postlogd(8)
|
||||
service. This ensures that simultaneous logging from different programs
|
||||
will not get mixed up.
|
||||
|
||||
* All Postfix programs can log to syslog, but not all programs have
|
||||
sufficient privileges to use the Postfix logging service, and many non-
|
||||
daemon programs must not log to stdout as that would corrupt their output.
|
||||
|
||||
Limitations:
|
||||
|
||||
* Non-daemon Postfix programs will log errors to syslogd(8) before they have
|
||||
processed command-line options and main.cf parameters.
|
||||
|
||||
* If Postfix is down, the non-daemon programs postfix(1), postsuper(1),
|
||||
postmulti(1), and postlog(1), will log directly to $maillog_file. These
|
||||
programs expect to run with root privileges, for example during Postfix
|
||||
start-up, reload, or shutdown.
|
||||
|
||||
* Other non-daemon Postfix programs will never write directly to
|
||||
$maillog_file (also, logging to stdout would interfere with the operation
|
||||
of some of these programs). These programs can log to postlogd(8) if they
|
||||
are run by the super-user, or if their executable file has set-gid
|
||||
permission. Do not set this permission on programs other than postdrop(1),
|
||||
postqueue(1), and (Postfix >= 3.7) postlog(1).
|
||||
|
||||
50
README_FILES/MEMCACHE_README
Normal file
50
README_FILES/MEMCACHE_README
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
PPoossttffiixx mmeemmccaacchhee cclliieenntt HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The Postfix memcache client allows you to hook up Postfix to a memcache server.
|
||||
The current implementation supports one memcache server per Postfix table, with
|
||||
one optional Postfix database that provides persistent backup. The Postfix
|
||||
memcache client supports the lookup, update, delete and sequence operations.
|
||||
The sequence (i.e. first/next) operation requires a backup database that
|
||||
supports this operation.
|
||||
|
||||
Typically, the Postfix memcache client is used to reduce query load on a
|
||||
persistent database, but it may also be used to query a memory-only database
|
||||
for low-value, easy-to-recreate, information such as a reputation cache for
|
||||
postscreen(8), verify(8) or greylisting.
|
||||
|
||||
LLiimmiittaattiioonnss
|
||||
|
||||
* The Postfix memcache client cannot be used for security-sensitive tables
|
||||
such as alias_maps (these may contain "|command" and "/file/name"
|
||||
destinations), or virtual_uid_maps, virtual_gid_maps and
|
||||
virtual_mailbox_maps (these specify UNIX process privileges or "/file/name"
|
||||
destinations). Typically, a memcache database is writable by any process
|
||||
that can talk to the memcache server; in contrast, security-sensitive
|
||||
tables must never be writable by the unprivileged Postfix user.
|
||||
|
||||
* The Postfix memcache client requires additional configuration when used as
|
||||
postscreen(8) or verify(8) cache. For details see the backup and ttl
|
||||
parameter discussions in the memcache_table(5) manual page.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh mmeemmccaacchhee ssuuppppoorrtt
|
||||
|
||||
The Postfix memcache client has no external dependencies, and is therefore
|
||||
built into Postfix by default.
|
||||
|
||||
CCoonnffiigguurriinngg mmeemmccaacchhee llooookkuupp ttaabblleess
|
||||
|
||||
Configuration is described in the memcache_table(5) manpage.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
The first memcache client for Postfix was written by Omar Kilani, and was based
|
||||
on the libmemcache library.
|
||||
|
||||
Wietse wrote the current memcache client from the ground up for Postfix version
|
||||
2.9. This implementation does not use libmemcache, and bears no resemblance to
|
||||
earlier work.
|
||||
|
||||
698
README_FILES/MILTER_README
Normal file
698
README_FILES/MILTER_README
Normal file
|
|
@ -0,0 +1,698 @@
|
|||
PPoossttffiixx bbeeffoorree--qquueeuuee MMiilltteerr ssuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
Postfix implements support for the Sendmail version 8 Milter (mail filter)
|
||||
protocol. This protocol is used by applications that run outside the MTA to
|
||||
inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM,
|
||||
etc.) as well as mail content (headers and body). All this happens before mail
|
||||
is queued.
|
||||
|
||||
The reason for adding Milter support to Postfix is that there exists a large
|
||||
collection of applications, not only to block unwanted mail, but also to verify
|
||||
authenticity (examples: OpenDKIM and DMARC) or to digitally sign mail (example:
|
||||
OpenDKIM). Having yet another Postfix-specific version of all that software is
|
||||
a poor use of human and system resources.
|
||||
|
||||
The Milter protocol has evolved over time, and different Postfix versions
|
||||
implement different feature sets. See the workarounds and limitations sections
|
||||
at the end of this document for differences between Postfix and Sendmail
|
||||
implementations.
|
||||
|
||||
This document provides information on the following topics:
|
||||
|
||||
* How Milter applications plug into Postfix
|
||||
* When Postfix and Milters inspect an SMTP session
|
||||
* Building Milter applications
|
||||
* Running Milter applications
|
||||
* Configuring Postfix
|
||||
* Workarounds
|
||||
* Limitations
|
||||
|
||||
HHooww MMiilltteerr aapppplliiccaattiioonnss pplluugg iinnttoo PPoossttffiixx
|
||||
|
||||
The Postfix Milter implementation uses two different lists of mail filters: one
|
||||
list of filters for SMTP mail only, and one list of filters for non-SMTP mail.
|
||||
The two lists have different capabilities, which is unfortunate. Avoiding this
|
||||
would require major restructuring of Postfix.
|
||||
|
||||
* The SMTP-only filters handle mail that arrives via the Postfix smtpd(8)
|
||||
server. They are typically used to filter unwanted mail and to sign mail
|
||||
from authorized SMTP clients. You specify SMTP-only Milter applications
|
||||
with the smtpd_milters parameter as described in a later section. Mail that
|
||||
arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
|
||||
filters that are described next.
|
||||
|
||||
* The non-SMTP filters handle mail that arrives via the Postfix sendmail(1)
|
||||
command-line or via the Postfix qmqpd(8) server. They are typically used to
|
||||
digitally sign mail only. Although non-SMTP filters can be used to filter
|
||||
unwanted mail, they have limitations compared to the SMTP-only filters. You
|
||||
specify non-SMTP Milter applications with the non_smtpd_milters parameter
|
||||
as described in a later section.
|
||||
|
||||
For those who are familiar with the Postfix architecture, the figure below
|
||||
shows how Milter applications plug into Postfix. Names followed by a number are
|
||||
Postfix commands or server programs, while unnumbered names inside shaded areas
|
||||
represent Postfix queues. To avoid clutter, the path for local submission is
|
||||
simplified (the OVERVIEW document has a more complete description of the
|
||||
Postfix architecture).
|
||||
|
||||
SMTP-only non-SMTP
|
||||
filters filters
|
||||
|
||||
^ |
|
||||
| v
|
||||
^ |
|
||||
| |
|
||||
Network -> smtpd(8) | |
|
||||
| v
|
||||
|
||||
\
|
||||
|
||||
Network -> qmqpd(8) -> cleanup(8) -> incoming
|
||||
|
||||
/
|
||||
|
||||
pickup(8)
|
||||
|
||||
:
|
||||
|
||||
Local -> sendmail(1)
|
||||
|
||||
WWhheenn PPoossttffiixx aanndd MMiilltteerrss iinnssppeecctt aann SSMMTTPP sseessssiioonn
|
||||
|
||||
Generally, Postfix inspects information first, then the first configured
|
||||
Milter, the second configured Milter, and so on.
|
||||
|
||||
* With most SMTP commands: Postfix reviews one SMTP command, and if Postfix
|
||||
does not reject it, Postfix passes the command to the first configured
|
||||
Milter. If the first Milter does not reject the command, Postfix passes it
|
||||
to the second configured Milter, and so on. This includes commands with an
|
||||
envelope sender (MAIL FROM) or envelope recipient (RCPT TO). Postfix stores
|
||||
the same envelope records in a queue file as when no Milters are
|
||||
configured, including rewritten envelope addresses, expanded virtual
|
||||
aliases, BCC addresses from sender/recipient_bcc_maps, and so on.
|
||||
|
||||
* With header/body content: Postfix may rewrite or reject header/body content
|
||||
before it stores that content in the queue file; Postfix stores the same
|
||||
header/body content as when no Milters are configured. If Postfix does not
|
||||
reject the header/body content, Postfix passes it to the first configured
|
||||
Milter which may modify or reject that content or may modify the stored
|
||||
envelope. If the first Milter does not reject the header/body content,
|
||||
Postfix passes it to the second configured Milter, and so on.
|
||||
|
||||
Details:
|
||||
|
||||
* Postfix hides its own Postfix-prepended Received: header, for compatibility
|
||||
with Sendmail. Postfix does not hide other headers that Postfix or Milters
|
||||
added or modified.
|
||||
|
||||
* When the Postfix SMTP server receives a sequence of one or more valid BDAT
|
||||
commands, it generates one DATA command for the Milters.
|
||||
|
||||
* The Milter API does not support inspection of SMTP commands such as QUIT,
|
||||
NOOP, or VRFY; the API supports only commands that are needed for email
|
||||
delivery.
|
||||
|
||||
BBuuiillddiinngg MMiilltteerr aapppplliiccaattiioonnss
|
||||
|
||||
Milter applications have been written in C, Haskell, Java, Perl, Python, Rust,
|
||||
and more, but this document covers C applications only. For these, you need an
|
||||
object library that implements the Sendmail 8 Milter protocol. Postfix
|
||||
currently does not provide such a library, but Sendmail does.
|
||||
|
||||
Some systems install the Sendmail libmilter library by default. With other
|
||||
systems, libmilter may be provided by a package (called "sendmail-devel" on
|
||||
some Linux systems).
|
||||
|
||||
Once libmilter is installed, applications such as OpenDKIM and OpenDMARC build
|
||||
out of the box without requiring any tinkering:
|
||||
|
||||
$ ggzzccaatt ooppeennddkkiimm--xx..yy..zz..ttaarr..ggzz || ttaarr xxff --
|
||||
$ ccdd ooppeennddkkiimm--xx..yy..zz
|
||||
$ ..//ccoonnffiigguurree ......ooppttiioonnss......
|
||||
$ mmaakkee
|
||||
[...lots of output omitted...]
|
||||
$ mmaakkee iinnssttaallll
|
||||
|
||||
RRuunnnniinngg MMiilltteerr aapppplliiccaattiioonnss
|
||||
|
||||
To run a Milter application, see the documentation of the filter for options. A
|
||||
typical command looks like this:
|
||||
|
||||
# //ssoommee//wwhheerree//ooppeennddkkiimm --ll --uu uusseerriidd --pp iinneett::ppoorrttnnuummbbeerr@@llooccaallhhoosstt ......ootthheerr
|
||||
ooppttiioonnss......
|
||||
|
||||
Please specify a userid value that isn't used for other applications (not
|
||||
"postfix", not "www", etc.).
|
||||
|
||||
CCoonnffiigguurriinngg PPoossttffiixx
|
||||
|
||||
Like Sendmail, Postfix has a lot of configuration options that control how it
|
||||
talks to Milter applications. Besides global options that apply to all Milter
|
||||
applications, Postfix 3.0 and later support per-Milter timeouts, per-Milter
|
||||
error handling, etc.
|
||||
|
||||
Information in this section:
|
||||
|
||||
* SMTP-Only Milter applications
|
||||
* Non-SMTP Milter applications
|
||||
* Milter error handling
|
||||
* Milter protocol version
|
||||
* Milter protocol timeouts
|
||||
* Different settings for different Milter applications
|
||||
* Different settings for different SMTP clients
|
||||
* Sendmail macro emulation
|
||||
* What macros will Postfix send to Milters?
|
||||
|
||||
SSMMTTPP--OOnnllyy MMiilltteerr aapppplliiccaattiioonnss
|
||||
|
||||
The SMTP-only Milter applications handle mail that arrives via the Postfix
|
||||
smtpd(8) server. They are typically used to filter unwanted mail, and to sign
|
||||
mail from authorized SMTP clients. Mail that arrives via the Postfix smtpd(8)
|
||||
server is not filtered by the non-SMTP filters that are described in the next
|
||||
section.
|
||||
|
||||
NOTE for Postfix versions that have a mail_release_date before 20141018: do
|
||||
not use the header_checks(5) IGNORE action to remove Postfix's own
|
||||
Received: message header. This causes problems with mail signing filters.
|
||||
Instead, keep Postfix's own Received: message header and use the
|
||||
header_checks(5) REPLACE action to sanitize information.
|
||||
|
||||
You specify SMTP-only Milter applications (there can be more than one) with the
|
||||
smtpd_milters parameter. Each Milter application is identified by the name of
|
||||
its listening socket; other Milter configuration options will be discussed in
|
||||
later sections. Postfix sends commands to each Milter application in the order
|
||||
as configured with smtpd_milters. When a Milter application rejects a command,
|
||||
that will override responses from other Milter applications.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Milters for mail that arrives via the smtpd(8) server.
|
||||
# See below for socket address syntax.
|
||||
smtpd_milters = inet:localhost:portnumber ...other filters...
|
||||
|
||||
The general syntax for listening sockets is as follows:
|
||||
|
||||
uunniixx::pathname
|
||||
Connect to the local UNIX-domain server that is bound to the specified
|
||||
pathname. If the smtpd(8) or cleanup(8) process runs chrooted, an
|
||||
absolute pathname is interpreted relative to the Postfix queue
|
||||
directory. On many systems, llooccaall is a synonym for uunniixx
|
||||
|
||||
iinneett::host::port
|
||||
Connect to the specified TCP port on the specified local or remote
|
||||
host. The host and port can be specified in numeric or symbolic form.
|
||||
|
||||
NOTE: Postfix syntax differs from Milter syntax which has the form
|
||||
iinneett::port@@host.
|
||||
|
||||
For advanced configuration see "Different settings for different SMTP clients"
|
||||
and "Different settings for different Milter applications".
|
||||
|
||||
NNoonn--SSMMTTPP MMiilltteerr aapppplliiccaattiioonnss
|
||||
|
||||
The non-SMTP Milter applications handle mail that arrives via the Postfix
|
||||
sendmail(1) command-line or via the Postfix qmqpd(8) server. They are typically
|
||||
used to digitally sign mail. Although non-SMTP filters can be used to filter
|
||||
unwanted mail, there are limitations as discussed later in this section. Mail
|
||||
that arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
|
||||
filters.
|
||||
|
||||
NOTE: Do not use the header_checks(5) IGNORE action to remove Postfix's own
|
||||
Received: message header. This causes problems with mail signing filters.
|
||||
Instead, keep Postfix's own Received: message header and use the header_checks
|
||||
(5) REPLACE action to sanitize information.
|
||||
|
||||
You specify non-SMTP Milter applications with the non_smtpd_milters parameter.
|
||||
This parameter uses the same syntax as the smtpd_milters parameter in the
|
||||
previous section. As with the SMTP-only filters, you can specify more than one
|
||||
Milter application. Postfix sends commands to each Milter application in the
|
||||
order as configured with non_smtpd_milters. When a Milter application rejects a
|
||||
command, that will override responses from other Milter applications.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Milters for non-SMTP mail.
|
||||
# See below for socket address syntax.
|
||||
non_smtpd_milters = inet:localhost:portnumber ...other filters...
|
||||
|
||||
There's one small complication when using Milter applications for non-SMTP
|
||||
mail: there is no SMTP session. To keep Milter applications happy, the Postfix
|
||||
cleanup(8) server actually has to simulate the SMTP client CONNECT and
|
||||
DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and DATA
|
||||
commands.
|
||||
|
||||
* When new mail arrives via the sendmail(1) command line, the Postfix cleanup
|
||||
(8) server pretends that the mail arrives with ESMTP from "localhost" with
|
||||
IP address "127.0.0.1". The result is very similar to what happens with
|
||||
command line submissions in Sendmail version 8.12 and later, although
|
||||
Sendmail uses a different mechanism to achieve this result.
|
||||
|
||||
* When new mail arrives via the qmqpd(8) server, the Postfix cleanup(8)
|
||||
server pretends that the mail arrives with ESMTP, and uses the QMQPD client
|
||||
hostname and IP address.
|
||||
|
||||
* When old mail is re-injected into the queue with "postsuper -r", the
|
||||
Postfix cleanup(8) server uses the same client information that was used
|
||||
when the mail arrived as new mail.
|
||||
|
||||
This generally works as expected, with only one exception: non-SMTP filters
|
||||
must not REJECT or TEMPFAIL simulated RCPT TO commands. When a
|
||||
non_smtpd_milters application REJECTs or TEMPFAILs a recipient, Postfix will
|
||||
report a configuration error, and mail will stay in the queue.
|
||||
|
||||
SSiiggnniinngg iinntteerrnnaallllyy--ggeenneerraatteedd bboouunnccee mmeessssaaggeess
|
||||
|
||||
Postfix normally does not apply content filters to mail that is generated
|
||||
internally such as bounces or Postmaster notifications. Filtering internally-
|
||||
generated bounces would result in loss of mail when a filter rejects a message,
|
||||
as the resulting double-bounce message would almost certainly also be blocked.
|
||||
|
||||
To sign Postfix's own bounce messages, enable filtering of internally-generated
|
||||
bounces (line 2 below), and don't reject any internally-generated bounces with
|
||||
non_smtpd_milters, header_checks or body_checks (lines 3-5 below).
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 internal_mail_filter_classes = bounce
|
||||
3 non_smtpd_milters = don't reject internally-generated bounces
|
||||
4 header_checks = don't reject internally-generated bounces
|
||||
5 body_checks = don't reject internally-generated bounces
|
||||
|
||||
MMiilltteerr eerrrroorr hhaannddlliinngg
|
||||
|
||||
The milter_default_action parameter specifies how Postfix handles Milter
|
||||
application errors. The default action is to respond with a temporary error
|
||||
status, so that the client will try again later. Specify "accept" if you want
|
||||
to receive mail as if the filter does not exist, and "reject" to reject mail
|
||||
with a permanent status. The "quarantine" action is like "accept" but freezes
|
||||
the message in the "hold" queue, and is available with Postfix 2.6 or later.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# What to do in case of errors? Specify accept, reject, tempfail,
|
||||
# or quarantine (Postfix 2.6 or later).
|
||||
milter_default_action = tempfail
|
||||
|
||||
See "Different settings for different Milter applications" for advanced
|
||||
configuration options.
|
||||
|
||||
MMiilltteerr pprroottooccooll vveerrssiioonn
|
||||
|
||||
As Postfix is not built with the Sendmail libmilter library, you may need to
|
||||
configure the Milter protocol version that Postfix should use. The default
|
||||
version is 6 (before Postfix 2.6 the default version is 2).
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Postfix >= 2.6
|
||||
milter_protocol = 6
|
||||
# 2.3 <= Postfix <= 2.5
|
||||
milter_protocol = 2
|
||||
|
||||
If the Postfix milter_protocol setting specifies a too low version, the
|
||||
libmilter library will log an error message like this:
|
||||
|
||||
application name: st_optionneg[xxxxx]: 0xyy does not fulfill action
|
||||
requirements 0xzz
|
||||
|
||||
The remedy is to increase the Postfix milter_protocol version number. See,
|
||||
however, the limitations section below for features that aren't supported by
|
||||
Postfix.
|
||||
|
||||
With Postfix 2.7 and earlier, if the Postfix milter_protocol setting specifies
|
||||
a too high version, the libmilter library simply hangs up without logging a
|
||||
warning, and you see a Postfix warning message like one of the following:
|
||||
|
||||
warning: milter inet:host:port: can't read packet header: Unknown error : 0
|
||||
warning: milter inet:host:port: can't read packet header: Success
|
||||
warning: milter inet:host:port: can't read SMFIC_DATA reply packet header:
|
||||
No such file or directory
|
||||
|
||||
The remedy is to lower the Postfix milter_protocol version number. Postfix 2.8
|
||||
and later will automatically turn off protocol features that the application's
|
||||
libmilter library does not expect.
|
||||
|
||||
See "Different settings for different Milter applications" for advanced
|
||||
configuration options.
|
||||
|
||||
MMiilltteerr pprroottooccooll ttiimmeeoouuttss
|
||||
|
||||
Postfix uses different time limits at different Milter protocol stages. The
|
||||
table shows the timeout settings and the corresponding protocol stages (EOH =
|
||||
end of headers; EOM = end of message).
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|PPoossttffiixx ppaarraammeetteerr |TTiimmee lliimmiitt|MMiilltteerr pprroottooccooll ssttaaggee |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_connect_timeout|30s |CONNECT |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_command_timeout|30s |HELO, MAIL, RCPT, DATA, UNKNOWN|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_content_timeout|300s |HEADER, EOH, BODY, EOM |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
Beware: 30s may be too short for Milter applications that do lots of DNS
|
||||
lookups. However, if you increase the above timeouts too much, remote SMTP
|
||||
clients may hang up and mail may be delivered multiple times. This is an
|
||||
inherent problem with before-queue filtering.
|
||||
|
||||
See "Different settings for different Milter applications" for advanced
|
||||
configuration options.
|
||||
|
||||
DDiiffffeerreenntt sseettttiinnggss ffoorr ddiiffffeerreenntt MMiilltteerr aapppplliiccaattiioonnss
|
||||
|
||||
The previous sections list a number of Postfix main.cf parameters that control
|
||||
time limits and other settings for all Postfix Milter clients. This is
|
||||
sufficient for simple configurations. With more complex configurations it
|
||||
becomes desirable to have different settings for different Milter clients. This
|
||||
is supported with Postfix 3.0 and later.
|
||||
|
||||
The following example shows a "non-critical" Milter client with a short connect
|
||||
timeout, and with "accept" as default action when the service is unvailable.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_milters = { inet:host:port,
|
||||
3 connect_timeout=10s, default_action=accept }
|
||||
|
||||
Instead of a server endpoint, we now have a list enclosed in {}.
|
||||
|
||||
* Line 2: The first item in the list is the server endpoint. This supports
|
||||
the exact same "inet" and "unix" syntax as described earlier.
|
||||
|
||||
* Line 3: The remainder of the list contains per-Milter settings. These
|
||||
settings override global main.cf parameters, and have the same name as
|
||||
those parameters, without the "milter_" prefix. The per-Milter settings
|
||||
that are supported as of Postfix 3.0 are command_timeout, connect_timeout,
|
||||
content_timeout, default_action, and protocol.
|
||||
|
||||
Inside the list, syntax is similar to what we already know from main.cf: items
|
||||
separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
|
||||
sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
|
||||
ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd ""=="".
|
||||
|
||||
DDiiffffeerreenntt sseettttiinnggss ffoorr ddiiffffeerreenntt SSMMTTPP cclliieennttss
|
||||
|
||||
The smtpd_milter_maps feature supports different Milter settings for different
|
||||
client IP addresses. Lookup results override the global smtpd_milters setting,
|
||||
and have the same syntax. For example, to disable Milter settings for local
|
||||
address ranges:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map
|
||||
smtpd_milters = inet:host:port, { inet:host:port, ... }, ...
|
||||
|
||||
/etc/postfix/smtpd_milter_map:
|
||||
# Disable Milters for local clients.
|
||||
127.0.0.0/8 DISABLE
|
||||
192.168.0.0/16 DISABLE
|
||||
::/64 DISABLE
|
||||
2001:db8::/32 DISABLE
|
||||
|
||||
This feature is available with Postfix 3.2 and later.
|
||||
|
||||
SSeennddmmaaiill mmaaccrroo eemmuullaattiioonn
|
||||
|
||||
Postfix emulates a limited number of Sendmail macros, as shown in the table.
|
||||
Some macro values depend on whether a recipient is rejected (rejected
|
||||
recipients are available on request by the Milter application). Different
|
||||
macros are available at different Milter protocol stages (EOH = end-of-header,
|
||||
EOM = end-of-message); their availability is not always the same as in
|
||||
Sendmail. See the workarounds section below for solutions.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|SSeennddmmaaiill mmaaccrroo |MMiilltteerr pprroottooccooll ssttaaggee |DDeessccrriippttiioonn |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|i |DATA, EOH, EOM |Queue ID, also Postfix |
|
||||
| | |queue file name |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|j |Always |Value of myhostname |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|_ |Always |The validated client name |
|
||||
| | |and address |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{auth_authen} |MAIL, DATA, EOH, EOM |SASL login name |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{auth_author} |MAIL, DATA, EOH, EOM |SASL sender |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{auth_type} |MAIL, DATA, EOH, EOM |SASL login method |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{client_addr} |Always |Remote client IP address |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Connection concurrency for|
|
||||
| | |this client (zero if the |
|
||||
|{client_connections}|CONNECT |client is excluded from |
|
||||
| | |all smtpd_client_* |
|
||||
| | |limits). |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Remote client hostname |
|
||||
| | |When address -> name |
|
||||
|{client_name} |Always |lookup or name -> address |
|
||||
| | |verification fails: |
|
||||
| | |"unknown" |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{client_port} |Always (Postfix >=2.5) |Remote client TCP port |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Client name from address -|
|
||||
|{client_ptr} |CONNECT, HELO, MAIL, DATA|> name lookup |
|
||||
| | |When address -> name |
|
||||
| | |lookup fails: "unknown" |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{cert_issuer} |HELO, MAIL, DATA, EOH, |TLS client certificate |
|
||||
| |EOM |issuer |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{cert_subject} |HELO, MAIL, DATA, EOH, |TLS client certificate |
|
||||
| |EOM |subject |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{cipher_bits} |HELO, MAIL, DATA, EOH, |TLS session key size |
|
||||
| |EOM | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{cipher} |HELO, MAIL, DATA, EOH, |TLS cipher |
|
||||
| |EOM | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{daemon_addr} |Always (Postfix >=3.2) |Local server IP address |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{daemon_name} |Always |value of |
|
||||
| | |milter_macro_daemon_name |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{daemon_port} |Always (Postfix >=3.2) |Local server TCP port |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{mail_addr} |MAIL |Sender address |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{mail_host} |MAIL (Postfix >= 2.6, |Sender next-hop |
|
||||
| |only with smtpd_milters) |destination |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{mail_mailer} |MAIL (Postfix >= 2.6, |Sender mail delivery |
|
||||
| |only with smtpd_milters) |transport |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Recipient address |
|
||||
|{rcpt_addr} |RCPT |With rejected recipient: |
|
||||
| | |descriptive text |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Recipient next-hop |
|
||||
|{rcpt_host} |RCPT (Postfix >= 2.6, |destination |
|
||||
| |only with smtpd_milters) |With rejected recipient: |
|
||||
| | |enhanced status code |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Recipient mail delivery |
|
||||
|{rcpt_mailer} |RCPT (Postfix >= 2.6, |transport |
|
||||
| |only with smtpd_milters) |With rejected recipient: |
|
||||
| | |"error" |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|{tls_version} |HELO, MAIL, DATA, EOH, |TLS protocol version |
|
||||
| |EOM | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|v |Always |value of milter_macro_v |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
WWhhaatt mmaaccrrooss wwiillll PPoossttffiixx sseenndd ttoo MMiilltteerrss??
|
||||
|
||||
Postfix sends specific sets of macros at different Milter protocol stages. The
|
||||
names of these macros are configured with the parameters shown in the table
|
||||
below (EOH = end of headers; EOM = end of message). Some lists require a
|
||||
minimum Milter protocol version.
|
||||
|
||||
As of Sendmail 8.14.0, Milter applications can specify what macros they want to
|
||||
receive at different Milter protocol stages. An application-specified list
|
||||
takes precedence over a Postfix-specified list.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|PPoossttffiixx ppaarraammeetteerr |MMiilltteerr pprroottooccooll|MMiilltteerr pprroottooccooll ssttaaggee|
|
||||
| |vveerrssiioonn | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_connect_macros |2 or higher |CONNECT |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_helo_macros |2 or higher |HELO/EHLO |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_mail_macros |2 or higher |MAIL FROM |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_rcpt_macros |2 or higher |RCPT TO |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_data_macros |4 or higher |DATA |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_end_of_header_macros |6 or higher |EOH |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_end_of_data_macros |2 or higher |EOM |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|milter_unknown_command_macros|3 or higher |unknown command |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
By default, Postfix will send only macros whose values have been updated with
|
||||
information from main.cf or master.cf, from an SMTP session (for example; SASL
|
||||
login, or TLS certificates) or from a Mail delivery transaction (for example;
|
||||
queue ID, sender, or recipient).
|
||||
|
||||
To force a macro to be sent even when its value has not been updated, you may
|
||||
specify macro default values with the milter_macro_defaults parameter. Specify
|
||||
zero or more name=value pairs separated by comma or whitespace; you may even
|
||||
specify macro names that Postfix does not know about!
|
||||
|
||||
WWoorrkkaarroouunnddss
|
||||
|
||||
* To avoid breaking DKIM etc. signatures with an SMTP-based content filter,
|
||||
update the before-filter SMTP client in master.cf, and add a line with "-
|
||||
o disable_mime_output_conversion=yes" (note: no spaces around the "="). For
|
||||
details, see the advanced content filter example.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
scan unix - - n - 10 smtp
|
||||
-o smtp_send_xforward_command=yes
|
||||
-o disable_mime_output_conversion=yes
|
||||
-o smtp_generic_maps=
|
||||
|
||||
* Some Milter applications use the "{if_addr}" macro to recognize local mail;
|
||||
this macro does not exist in Postfix. Workaround: use the "{daemon_addr}"
|
||||
(Postfix >= 3.2) or "{client_addr}" macro instead.
|
||||
|
||||
* Some Milter applications log a warning that looks like this:
|
||||
|
||||
sid-filter[36540]: WARNING: sendmail symbol 'i' not available
|
||||
|
||||
And they may insert an ugly message header with "unknown-msgid" like this:
|
||||
|
||||
X-SenderID: Sendmail Sender-ID Filter vx.y.z host.example.com <unknown-
|
||||
msgid>
|
||||
|
||||
The problem is that Milter applications expect that the queue ID is known
|
||||
before the MTA accepts the MAIL FROM (sender) command. Postfix does not
|
||||
choose a queue ID, which is used as the queue file name, until after it
|
||||
accepts the first valid RCPT TO (recipient) command.
|
||||
|
||||
If you experience the ugly header problem, see if a recent version of the
|
||||
Milter application fixes it. For example, current versions of dkim-filter
|
||||
and dk-filter already have code that looks up the Postfix queue ID at a
|
||||
later protocol stage, and sid-filter version 1.0.0 no longer includes the
|
||||
queue ID in the message header.
|
||||
|
||||
To fix the ugly message header, you will need to add code that looks up the
|
||||
Postfix queue ID at some later point in time. The example below adds the
|
||||
lookup after the end-of-message.
|
||||
|
||||
o Edit the filter source file (typically named xxx-filter/xxx-filter.c or
|
||||
similar).
|
||||
|
||||
o Look up the mlfi_eom() function and add code near the top shown as bboolldd
|
||||
text below:
|
||||
|
||||
dfc = cc->cctx_msg;
|
||||
assert(dfc != NULL);
|
||||
|
||||
//** DDeetteerrmmiinnee tthhee jjoobb IIDD ffoorr llooggggiinngg.. **//
|
||||
iiff ((ddffcc-->>mmccttxx__jjoobbiidd ==== 00 |||| ssttrrccmmpp((ddffcc-->>mmccttxx__jjoobbiidd,, JJOOBBIIDDUUNNKKNNOOWWNN)) ==== 00))
|
||||
{{
|
||||
cchhaarr **jjoobbiidd == ssmmffii__ggeettssyymmvvaall((ccttxx,, ""ii""));;
|
||||
iiff ((jjoobbiidd !!== 00))
|
||||
ddffcc-->>mmccttxx__jjoobbiidd == jjoobbiidd;;
|
||||
}}
|
||||
|
||||
NOTES:
|
||||
|
||||
o Different mail filters use slightly different names for variables. If
|
||||
the above code does not compile, look elsewhere in the mail filter
|
||||
source file for code that looks up the "i" macro value, and copy that
|
||||
code.
|
||||
|
||||
o This change fixes only the ugly message header, but not the WARNING
|
||||
message. Fortunately, many Milters log that message only once.
|
||||
|
||||
LLiimmiittaattiioonnss
|
||||
|
||||
This section lists limitations of the Postfix Milter implementation. Some
|
||||
limitations will be removed as the implementation is extended over time. Of
|
||||
course the usual limitations of before-queue filtering will always apply. See
|
||||
the CONTENT_INSPECTION_README document for a discussion.
|
||||
|
||||
* The Milter protocol has evolved over time. Therefore, different Postfix
|
||||
versions implement different feature sets.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|PPoossttffiixx|SSuuppppoorrtteedd MMiilltteerr rreeqquueessttss |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| 2.6 |All Milter requests of Sendmail 8.14.0 (see notes below). |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| |All Milter requests of Sendmail 8.14.0, except: |
|
||||
| |SMFIP_RCPT_REJ (report rejected recipients to the mail filter), |
|
||||
| 2.5 |SMFIR_CHGFROM (replace sender, with optional ESMTP parameters), |
|
||||
| |SMFIR_ADDRCPT_PAR (add recipient, with optional ESMTP |
|
||||
| |parameters). |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| 2.4 |All Milter requests of Sendmail 8.13.0. |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
| 2.3 |All Milter requests of Sendmail 8.13.0, except: |
|
||||
| |SMFIR_REPLBODY (replace message body). |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
* For Milter applications that are written in C, you need to use the Sendmail
|
||||
libmilter library.
|
||||
|
||||
* Postfix has TWO sets of mail filters: filters that are used for SMTP mail
|
||||
only (specified with the smtpd_milters parameter), and filters for non-SMTP
|
||||
mail (specified with the non_smtpd_milters parameter). The non-SMTP filters
|
||||
are primarily for local submissions.
|
||||
|
||||
When mail is filtered by non_smtpd_milters, the Postfix cleanup(8) server
|
||||
has to simulate SMTP client requests. This works as expected, with only one
|
||||
exception: non_smtpd_milters must not REJECT or TEMPFAIL simulated RCPT TO
|
||||
commands. When this rule is violated, Postfix will report a configuration
|
||||
error, and mail will stay in the queue.
|
||||
|
||||
* When you use the before-queue content filter for incoming SMTP mail (see
|
||||
SMTPD_PROXY_README), Milter applications have access only to the SMTP
|
||||
command information; they have no access to the message header or body, and
|
||||
cannot make modifications to the message or to the envelope.
|
||||
|
||||
* Postfix 3.3 and later support the ESMTP parameters RET and ENVID in
|
||||
requests to replace the envelope sender (SMFIR_CHGFROM). Postfix logs a
|
||||
warning message when a Milter application supplies other ESMTP parameters:
|
||||
|
||||
warning: queue-id: cleanup_chg_from: ignoring bad ESMTP
|
||||
parameter "whatever" in SMFI_CHGFROM request
|
||||
|
||||
* Postfix 3.0 and later support the ESMTP parameters NOTIFY and ORCPT in
|
||||
requests to add an envelope recipient. Postfix logs a warning message when
|
||||
a Milter application supplies other ESMTP parameters:
|
||||
|
||||
warning: queue-id: cleanup_add_rcpt: ignoring ESMTP argument
|
||||
from Milter or header/body_checks: "whatever"
|
||||
|
||||
* Postfix 2.6 and later ignore optional ESMTP parameters in requests to
|
||||
replace the sender (SMFIR_CHGFROM) or to append a recipient
|
||||
(SMFIR_ADDRCPT_PAR). Postfix logs a warning message when a Milter
|
||||
application supplies such ESMTP parameters:
|
||||
|
||||
warning: queue-id: cleanup_chg_from: ignoring ESMTP arguments "whatever"
|
||||
warning: queue-id: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
|
||||
|
||||
* Postfix 2.3 does not implement requests to replace the message body. Milter
|
||||
applications log a warning message when they need this unsupported
|
||||
operation:
|
||||
|
||||
st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
|
||||
|
||||
The solution is to use Postfix version 2.4 or later.
|
||||
|
||||
* Postfix versions before 3.0 did not support per-Milter timeouts, per-Milter
|
||||
error handling, etc.
|
||||
|
||||
188
README_FILES/MONGODB_README
Normal file
188
README_FILES/MONGODB_README
Normal file
|
|
@ -0,0 +1,188 @@
|
|||
PPoossttffiixx MMoonnggooDDBB HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
MMoonnggooDDBB SSuuppppoorrtt iinn PPoossttffiixx
|
||||
|
||||
Postfix can use MongoDB as a source for any of its lookups: aliases(5), virtual
|
||||
(5), canonical(5), etc. This allows you to keep information for your mail
|
||||
service in a replicated noSQL database with fine-grained access controls. By
|
||||
not storing it locally on the mail server, the administrators can maintain it
|
||||
from anywhere, and the users can control whatever bits of it you think
|
||||
appropriate. You can have multiple mail servers using the same information,
|
||||
without the hassle and delay of having to copy it to each.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Building Postfix with MongoDB support
|
||||
* Configuring MongoDB lookups
|
||||
* Example: virtual alias maps
|
||||
* Example: Mailing lists
|
||||
* Example: MongoDB projections
|
||||
* Feedback
|
||||
* Credits
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh MMoonnggooDDBB ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
The Postfix MongoDB client requires the mmoonnggoo--cc--ddrriivveerr library. This can be
|
||||
built from source code from the mongod-c project, or this can be installed as a
|
||||
binary package from your OS distribution, typically named mmoonnggoo--cc--ddrriivveerr,
|
||||
mmoonnggoo--cc--ddrriivveerr--ddeevveell or lliibbmmoonnggoocc--ddeevv. Installing the mongo-c-driver library
|
||||
may also install lliibbbbssoonn as a dependency.
|
||||
|
||||
To build Postfix with mongodb map support, add to the CCARGS environment
|
||||
variable the options -DHAS_MONGODB and -I for the directory containing the
|
||||
mongodb headers, and specify the AUXLIBS_MONGODB with the libmongoc and libbson
|
||||
libraries, for example:
|
||||
|
||||
% make tidy
|
||||
% make -f Makefile.init makefiles \
|
||||
CCARGS="$CCARGS -DHAS_MONGODB -I/usr/include/libmongoc-1.0 \
|
||||
-I/usr/include/libbson-1.0" \
|
||||
AUXLIBS_MONGODB="-lmongoc-1.0 -lbson-1.0"
|
||||
|
||||
The 'make tidy' command is needed only if you have previously built Postfix
|
||||
without MongoDB support.
|
||||
|
||||
If your MongoDB shared library is in a directory that the RUN-TIME linker does
|
||||
not know about, add a "-Wl,-R,/path/to/directory" option after "-lbson-1.0".
|
||||
Then, just run 'make'.
|
||||
|
||||
CCoonnffiigguurriinngg MMoonnggooDDBB llooookkuuppss
|
||||
|
||||
In order to use MongoDB lookups, define a MongoDB source as a table lookup in
|
||||
main.cf, for example:
|
||||
|
||||
alias_maps = hash:/etc/aliases, proxy:mongodb:/etc/postfix/mongo-aliases.cf
|
||||
|
||||
The file /etc/postfix/mongo-aliases.cf can specify a number of parameters. For
|
||||
a complete description, see the mongodb_table(5) manual page.
|
||||
|
||||
EExxaammppllee:: vviirrttuuaall((55)) aalliiaass mmaappss
|
||||
|
||||
Here's a basic example for using MongoDB to look up virtual(5) aliases. Assume
|
||||
that in main.cf, you have:
|
||||
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual_aliases,
|
||||
proxy:mongodb:/etc/postfix/mongo-virtual-aliases.cf
|
||||
|
||||
and in mongodb:/etc/postfix/mongo-virtual-aliases.cf you have:
|
||||
|
||||
uri = mongodb+srv://user_name:password@some_server
|
||||
dbname = mail
|
||||
collection = mailbox
|
||||
query_filter = {"$or": [{"username":"%s"}, {"alias.address": "%s"}],
|
||||
"active": 1}
|
||||
result_attribute = username
|
||||
|
||||
This example assumes mailbox names are stored in a MongoDB backend, in a format
|
||||
like:
|
||||
|
||||
{ "username": "user@example.com",
|
||||
"alias": [
|
||||
{"address": "admin@example.com"},
|
||||
{"address": "abuse@example.com"}
|
||||
],
|
||||
"active": 1
|
||||
}
|
||||
|
||||
Upon receiving mail for "admin@example.com" that isn't found in the /etc/
|
||||
postfix/virtual_aliases database, Postfix will search the MongoDB server/
|
||||
cluster listening at port 27017 on some_server. It will connect using the
|
||||
provided credentials, and search for any entries whose username is, or alias
|
||||
field has "admin@example.com". It will return the username attribute of those
|
||||
found, and build a list of their email addresses.
|
||||
|
||||
Notes:
|
||||
|
||||
* As with pprroojjeeccttiioonn (see below), the Postfix mongodb client automatically
|
||||
removes the top-level '_id' field from a result_attribute result.
|
||||
|
||||
* The Postfix mongodb client will only parse result fields with data types
|
||||
UTF8, INT32, INT64 and ARRAY. Other fields will be ignored, with a warning
|
||||
in the logs.
|
||||
|
||||
EExxaammppllee:: MMaaiilliinngg lliissttss
|
||||
|
||||
When it comes to mailing lists, one way of implementing one would be as below:
|
||||
|
||||
{ "name": "dev@example.com", "active": 1, "address":
|
||||
[ "hamid@example.com", "wietse@example.com", "viktor@example.com" ] }
|
||||
|
||||
using the filter below, will result in a comma separated string with all email
|
||||
addresses in this list.
|
||||
|
||||
query_filter = {"name": "%s", "active": 1}
|
||||
result_attribute = address
|
||||
|
||||
Notes:
|
||||
|
||||
* As with pprroojjeeccttiioonn (see below), the Postfix mongodb client automatically
|
||||
removes the top-level '_id' field from a result_attribute result.
|
||||
|
||||
* The Postfix mongodb client will only parse result fields with data types
|
||||
UTF8, INT32, INT64 and ARRAY. Other fields will be ignored, with a warning
|
||||
in the logs.
|
||||
|
||||
EExxaammppllee:: aaddvvaanncceedd pprroojjeeccttiioonnss
|
||||
|
||||
This module also supports the use of more complex MongoDB projections. There
|
||||
may be some use cases where operations such as concatenation are necessary to
|
||||
be performed on the data retrieved from the database. Although it is encouraged
|
||||
to keep the database design simple enough so this is not necessary, postfix
|
||||
supports the use of MongoDB projections to achieve the goal.
|
||||
|
||||
Consider the example below:
|
||||
|
||||
{ "username": "user@example.com",
|
||||
"local_part": "user",
|
||||
"domain": "example.com",
|
||||
"alias": [
|
||||
{"address": "admin@example.com"},
|
||||
{"address": "abuse@example.com"}
|
||||
],
|
||||
"active": 1
|
||||
}
|
||||
|
||||
virtual_mailbox_maps can be created using below parameters in a mongodb:/etc/
|
||||
postfix/mongo-virtual-mailboxes.cf file:
|
||||
|
||||
uri = mongodb+srv://user_name:password@some_server
|
||||
dbname = mail
|
||||
collection = mailbox
|
||||
query_filter = {"$or": [{"username":"%s"}, {"alias.address": "%s"}],
|
||||
"active": 1}
|
||||
projection = { "mail_path": {"$concat": ["$domain", "/", "$local_part"]} }
|
||||
|
||||
This will return 'example.com/user' path built from the database fields.
|
||||
|
||||
A couple of considerations when using projections:
|
||||
|
||||
* As with rreessuulltt__aattttrriibbuuttee, the Postfix mongodb client automatically removes
|
||||
the top-level '_id' field from a projection result.
|
||||
|
||||
* The Postfix mongodb client will only parse fields with data types UTF8,
|
||||
INT32, INT64 and ARRAY. Other fields will be ignored, with a warning in the
|
||||
logs. It is suggested to exclude any unnecessary fields when using a
|
||||
projection.
|
||||
|
||||
FFeeeeddbbaacckk
|
||||
|
||||
If you have questions, send them to postfix-users@postfix.org. Please include
|
||||
relevant information about your Postfix setup: MongoDB-related output from
|
||||
postconf, which libraries you built with, and such. If your question involves
|
||||
your database contents, please include the applicable bits of some database
|
||||
entries.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* Stephan Ferraro (Aionda GmbH) implemented an early version of the Postfix
|
||||
MongoDB client.
|
||||
* Hamid Maadani (Dextrous Technologies, LLC) added support for projections
|
||||
and %letter interpolation, and added documentation.
|
||||
* Wietse Venema adopted and restructured the code and documentation.
|
||||
|
||||
981
README_FILES/MULTI_INSTANCE_README
Normal file
981
README_FILES/MULTI_INSTANCE_README
Normal file
|
|
@ -0,0 +1,981 @@
|
|||
MMaannaaggiinngg mmuullttiippllee PPoossttffiixx iinnssttaanncceess oonn aa ssiinnggllee hhoosstt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document is a guide to managing multiple Postfix instances on a single
|
||||
host using the postmulti(1) instance manager. Multi-instance support is
|
||||
available with Postfix version 2.6 and later. See the postfix-wrapper(5) manual
|
||||
page for background on the instance management framework, and on how to deploy
|
||||
a custom instance manager.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Why multiple Postfix instances
|
||||
* Null-client instances versus service instances
|
||||
* Multi-instance walk-through
|
||||
* Components of a Postfix system
|
||||
* The default Postfix instance
|
||||
* Instance groups
|
||||
* Multi-instance configuration parameters
|
||||
* Using the postmulti(1) command
|
||||
* Credits
|
||||
|
||||
WWhhyy mmuullttiippllee PPoossttffiixx iinnssttaanncceess
|
||||
|
||||
Postfix is a general-purpose mail system that can be configured to serve a
|
||||
variety of needs. Examples of Postfix applications are:
|
||||
|
||||
* Local mail submission for shell users and system processes.
|
||||
|
||||
* Incoming (MX host) email from the Internet.
|
||||
|
||||
* Outbound mail relay for a corporate network.
|
||||
|
||||
* Authenticated submission for roaming users.
|
||||
|
||||
* Before/after content-filter mail.
|
||||
|
||||
A single Postfix configuration can provide many or all of these services, but a
|
||||
complex interplay of settings may be required, for example with master.cf
|
||||
options overriding main.cf settings. In this document we take the view that
|
||||
multiple Postfix instances may be a simpler way to configure a multi-function
|
||||
Postfix system. With multiple Postfix instances, each instance has its own
|
||||
directories for configuration, queue and data files, but it shares all Postfix
|
||||
program and documentation files with other instances.
|
||||
|
||||
Since there is no single right way to configure your system, we recommend that
|
||||
you choose what makes you most comfortable. If different Postfix services don't
|
||||
involve incompatible main.cf or master.cf settings, and if they can be combined
|
||||
together without complex tricks, then a single monolithic configuration may be
|
||||
the simplest approach.
|
||||
|
||||
The purpose of multi-instance support in Postfix is not to force you to create
|
||||
multiple Postfix instances, but rather to give you a choice. Multiple instances
|
||||
give you the freedom to tune each Postfix instance to a single task that it
|
||||
does well and to combine instances into complete systems.
|
||||
|
||||
With the introduction of the postmulti(1) utility and the reduction of the per-
|
||||
instance configuration footprint of a secondary Postfix instance to just a
|
||||
main.cf and master.cf file (other files are now in shared locations), we hope
|
||||
that multiple instances will be easier to use than ever before.
|
||||
|
||||
NNuullll--cclliieenntt iinnssttaanncceess vveerrssuuss sseerrvviiccee iinnssttaanncceess
|
||||
|
||||
In the multi-instance approach to configuring Postfix, the first simplification
|
||||
is with the default local-submission Postfix instance.
|
||||
|
||||
Most UNIX systems require support for email submission with the sendmail(1)
|
||||
command so that system processes such as cron jobs can send status reports, and
|
||||
so that system users can send email with command-line utilities. Such email can
|
||||
be handled with a null-client Postfix configuration that forwards all mail to a
|
||||
central mail hub. The null client will typically either not run an SMTP
|
||||
listener at all (master_service_disable = inet), or it will listen only on the
|
||||
loopback interface (inet_interfaces = loopback-only).
|
||||
|
||||
When implementing specialized servers for inbound Internet email, outbound
|
||||
MTAs, internal mail hubs, and so on, we recommend using a null client for local
|
||||
submission and creating single-function secondary Postfix instances to serve
|
||||
the specialized needs.
|
||||
|
||||
Note: usually, you need to use different "myhostname" settings when you run
|
||||
multiple instances on the same host. Otherwise, there will be false "mail
|
||||
loops back to myself" alarms when one instance tries to send mail into
|
||||
another instance. Typically, the null-client instance will use the system's
|
||||
hostname, and other instances will use their own dedicated "myhostname"
|
||||
settings. Different names are not needed when instances send mail to each
|
||||
other with a protocol other than SMTP, or with SMTP over a TCP port other
|
||||
than 25 as is usual with SMTP-based content filters.
|
||||
|
||||
MMuullttii--iinnssttaannccee wwaallkk--tthhrroouugghh
|
||||
|
||||
Before discussing the fine details of multi-instance operation we first show
|
||||
the steps for creating a border mail server. This server has with a null-client
|
||||
Postfix instance for local submission, an input Postfix instance to receive
|
||||
mail from the Internet, plus an advanced SMTP content-filter and an output
|
||||
Postfix instance to deliver filtered email to its internal destination.
|
||||
|
||||
SSeettttiinngg uupp tthhee nnuullll--cclliieenntt PPoossttffiixx iinnssttaannccee
|
||||
|
||||
On a border mail hub, while mail from the Internet requires a great deal of
|
||||
scrutiny, locally submitted messages are typically limited to mail from cron
|
||||
jobs and other system services. In this regard the border MTA is not different
|
||||
from other Unix hosts in your environment. For this reason, it will submit
|
||||
locally-generated email to the internal mail hub. We start the construction of
|
||||
the border mail server with the default instance, which will be a local-
|
||||
submission null client:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# We are mta1.example.com
|
||||
#
|
||||
myhostname = mta1.example.com
|
||||
mydomain = example.com
|
||||
|
||||
# Flat user-account namespace in example.com:
|
||||
#
|
||||
# user@example.com not user@host.example.com
|
||||
#
|
||||
myorigin = $mydomain
|
||||
|
||||
# Postfix 2.6+, disable inet services, specifically disable smtpd(8)
|
||||
#
|
||||
master_service_disable = inet
|
||||
|
||||
# No local delivery:
|
||||
#
|
||||
mydestination =
|
||||
local_transport = error:5.1.1 Mailbox unavailable
|
||||
alias_database =
|
||||
alias_maps =
|
||||
local_recipient_maps =
|
||||
|
||||
# Send everything to the internal mailhub
|
||||
#
|
||||
relayhost = [mailhub.example.com]
|
||||
|
||||
# Indexed table macro:
|
||||
# (use "hash", ... when cdb is not available)
|
||||
#
|
||||
default_database_type = cdb
|
||||
indexed = ${default_database_type}:${config_directory}/
|
||||
|
||||
# Expose origin host of mail from "root", ...
|
||||
#
|
||||
smtp_generic_maps = ${indexed}generic
|
||||
|
||||
# Send messages addressed to "root", ... to the MTA support team
|
||||
#
|
||||
virtual_alias_maps = ${indexed}virtual
|
||||
|
||||
/etc/postfix/generic:
|
||||
# The smarthost supports "+" addressing (recipient_delimiter = +).
|
||||
# Mail from "root" exposes the origin host, without replies
|
||||
# and bounces going back to the same host.
|
||||
#
|
||||
# On clustered MTAs this file is typically machine-built from
|
||||
# a template file. The build process expands the template into
|
||||
# "mtaadmin+root=mta1"
|
||||
#
|
||||
root mtaadmin+root=mta1
|
||||
|
||||
/etc/postfix/virtual:
|
||||
# Caretaker aliases:
|
||||
#
|
||||
root mtaadmin
|
||||
postmaster root
|
||||
|
||||
You would typically also add a Makefile, to automatically run postmap(1)
|
||||
commands when source files change. This Makefile also creates a "generic"
|
||||
database when none exists.
|
||||
|
||||
/etc/postfix/Makefile:
|
||||
MTAADMIN=mtaadmin
|
||||
|
||||
all: virtual.cdb generic.cdb
|
||||
|
||||
generic: Makefile
|
||||
@echo Creating $@
|
||||
@rm -f $@.tmp
|
||||
@printf '%s\t%s+root=%s\n' root ${MTAADMIN} `uname -n` > $@.tmp
|
||||
@mv $@.tmp generic
|
||||
|
||||
%.cdb: %
|
||||
postmap cdb:$<
|
||||
|
||||
Construct the "virtual" and "generic" databases (the latter is created by
|
||||
running "make"), then start and test the null-client:
|
||||
|
||||
# cd /etc/postfix; make
|
||||
# postfix start
|
||||
# sendmail -i -f root -t <<EOF
|
||||
From: root
|
||||
To: root
|
||||
Subject: test
|
||||
|
||||
testing
|
||||
EOF
|
||||
|
||||
The test message should be delivered to the members of the "mtaadmin" address
|
||||
group (or whatever address group you choose) with the following headers:
|
||||
|
||||
From: mtaadmin+root=mta1@example.com
|
||||
To: mtadmin+root=mta1@example.com
|
||||
Subject: test
|
||||
|
||||
SSeettttiinngg uupp tthhee ""oouuttppuutt"" PPoossttffiixx iinnssttaannccee
|
||||
|
||||
With the null-client instance out of the way, we can create the MTA "output"
|
||||
instance that will deliver filtered mail to the inside network. We add the
|
||||
"output" instance first, because the output instance needs to be up and running
|
||||
before the input instance can be fully tested, and when the system boots, the
|
||||
"output" instance must start before the input instance. We will put the output
|
||||
and input instances into a single instance group named "mta".
|
||||
|
||||
Just once, when adding the first secondary instance, enable multi-instance
|
||||
support in the default (null-client) instance:
|
||||
|
||||
# postmulti -e init
|
||||
|
||||
Then create the output instance:
|
||||
|
||||
# postmulti -I postfix-out -G mta -e create
|
||||
|
||||
The instance configuration directory defaults to /etc/postfix-out, more
|
||||
precisely, the "postfix-out" subdirectory of the parent directory of the
|
||||
default-instance configuration directory. The new instance will be created in a
|
||||
"disabled" state:
|
||||
|
||||
/etc/postfix-out/main.cf
|
||||
#
|
||||
# ... "stock" main.cf settings ...
|
||||
#
|
||||
multi_instance_name = postfix-out
|
||||
queue_directory = /var/spool/postfix-out
|
||||
data_directory = /var/lib/postfix-out
|
||||
#
|
||||
multi_instance_enable = no
|
||||
master_service_disable = inet
|
||||
authorized_submit_users =
|
||||
|
||||
This instance has a "stock" master.cf file, and its queue and data directories,
|
||||
also named "postfix-out", will be located in the same parent directories as the
|
||||
corresponding directories of the default instance (e.g., /var/spool/postfix-out
|
||||
and /var/lib/postfix-out).
|
||||
|
||||
While this instance is immediately safe to start, it is not yet usefully
|
||||
configured. It needs to be customized to fit the role of a post-filter re-
|
||||
injection SMTP service. Typical additions include:
|
||||
|
||||
/etc/postfix-out/master.cf:
|
||||
# Replace default "smtp inet" entry with one listening on port 10026.
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
|
||||
/etc/postfix-out/main.cf
|
||||
# ...
|
||||
|
||||
# Comment out if you don't use IPv6 internally
|
||||
# inet_protocols = ipv4
|
||||
inet_interfaces = loopback-only
|
||||
mynetworks_style = host
|
||||
smtpd_authorized_xforward_hosts = $mynetworks
|
||||
|
||||
# Don't anvil(8) control the re-injection port.
|
||||
#
|
||||
smtpd_client_connection_count_limit = 0
|
||||
smtpd_client_event_limit_exceptions = $mynetworks
|
||||
|
||||
# Best practice when inet_interfaces is set, as this is not a
|
||||
# "secondary IP personality" configuration.
|
||||
#
|
||||
smtp_bind_address = 0.0.0.0
|
||||
|
||||
# All header rewriting happens upstream
|
||||
#
|
||||
local_header_rewrite_clients =
|
||||
|
||||
# No local delivery on border gateway
|
||||
#
|
||||
mydestination =
|
||||
alias_maps =
|
||||
alias_database =
|
||||
local_recipient_maps =
|
||||
local_transport = error:5.1.1 Mailbox unavailable
|
||||
|
||||
# May need a recipient_delimiter for per-user transport lookups:
|
||||
#
|
||||
recipient_delimiter = +
|
||||
|
||||
# Only one (unrestricted client)
|
||||
# With multiple instances, rarely need "-o param=value" overrides
|
||||
# in master.cf, each instance gets its own main.cf file.
|
||||
#
|
||||
# Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
|
||||
smtpd_relay_restrictions =
|
||||
smtpd_recipient_restrictions = permit_mynetworks, reject
|
||||
|
||||
# Tolerate occasional high latency in the content filter.
|
||||
#
|
||||
smtpd_timeout = 1200s
|
||||
|
||||
# Best when empty, with all parent domain matches explicit.
|
||||
#
|
||||
parent_domain_matches_subdomains =
|
||||
|
||||
# Use the "relay" transport for inbound mail, and the default
|
||||
# "smtp" transport for outbound mail (bounces, ...). The latter
|
||||
# won't starve the former of delivery agent slots.
|
||||
#
|
||||
relay_domains = example.com, .example.com
|
||||
|
||||
# With xforward, match the input instance setting, if you
|
||||
# want "yes", set both to "yes".
|
||||
#
|
||||
smtpd_client_port_logging = no
|
||||
|
||||
# Transport settings ...
|
||||
# Message size limit
|
||||
# Concurrency tuning for "relay" and "smtp" transport
|
||||
# ...
|
||||
|
||||
With the "output" configuration in place, enable and start the instance:
|
||||
|
||||
1 # postmulti -i postfix-out -x postconf -e \
|
||||
2 "master_service_disable =" "authorized_submit_users = root"
|
||||
3 # postmulti -i postfix-out -e enable
|
||||
4 # postmulti -i postfix-out -p start
|
||||
|
||||
This uses the postmulti(1) command to invoke postconf(1) in the context
|
||||
(MAIL_CONFIG=/etc/postfix-out) of the output instance.
|
||||
|
||||
* Lines 1-2: With "authorized_submit_users = root", the superuser can test
|
||||
the postfix-out instance with "postmulti -i postfix-out -x sendmail -bv
|
||||
recipient...", but otherwise local submission remains disabled.
|
||||
|
||||
* Lines 1-2: With "master_service_disable =", the "inet" listeners are re-
|
||||
enabled.
|
||||
|
||||
* Line 3: The output instance is enabled for multi-instance start/stop.
|
||||
|
||||
* Line 4: The output instance is started.
|
||||
|
||||
Test the output instance by submitting probe messages via "sendmail -bv" and
|
||||
"telnet". For production systems, in-depth configuration tests should be done
|
||||
on a lab system. The simple tests just suggested will only confirm successful
|
||||
deployment of a configuration that should already be known good.
|
||||
|
||||
SSeettttiinngg uupp tthhee ccoonntteenntt--ffiilltteerr pprrooxxyy
|
||||
|
||||
With the output instance ready, deploy your content-filter proxy. Most proxies
|
||||
will need their own /etc/rc* start/stop script. Some proxies, however, are
|
||||
started on demand by the Postfix spawn(8) service, in which case you need to
|
||||
add the relevant spawn(8) entry to the output instance master.cf file.
|
||||
|
||||
Configure the proxy to listen on 127.0.0.1:10025 and to re-inject filtered
|
||||
email to 127.0.0.1:10026. Start the proxy service if necessary, then test the
|
||||
proxy via "telnet" or automated SMTP injectors. The proxy should support the
|
||||
following ESMTP features: DSN, 8BITMIME, and XFORWARD. In addition, the proxy
|
||||
should support multiple mail deliveries within an SMTP session.
|
||||
|
||||
SSeettttiinngg uupp tthhee iinnppuutt PPoossttffiixx iinnssttaannccee
|
||||
|
||||
The input Postfix instance receives mail from the network and sends it through
|
||||
the content filter. Now we create the input instance, also part of the "mta"
|
||||
instance group:
|
||||
|
||||
# postmulti -I postfix-in -G mta -e create
|
||||
|
||||
The new instance configuration directory defaults to /etc/postfix-in, more
|
||||
precisely, the "postfix-in" subdirectory of the parent directory of the
|
||||
default-instance configuration directory. The new instance will be created in a
|
||||
"disabled" state:
|
||||
|
||||
/etc/postfix-in/main.cf
|
||||
#
|
||||
# ... "stock" main.cf settings ...
|
||||
#
|
||||
multi_instance_name = postfix-in
|
||||
queue_directory = /var/spool/postfix-in
|
||||
data_directory = /var/lib/postfix-in
|
||||
#
|
||||
multi_instance_enable = no
|
||||
master_service_disable = inet
|
||||
authorized_submit_users =
|
||||
|
||||
As before, make appropriate changes to main.cf and master.cf to make the
|
||||
instance production ready. Consider setting "soft_bounce = yes" during the
|
||||
first few hours of deployment, so you can iron-out any unexpected "kinks".
|
||||
|
||||
Manual testing can start with:
|
||||
|
||||
/etc/postfix-in/main.cf
|
||||
# Accept only local traffic, but allow impersonation:
|
||||
inet_interfaces = 127.0.0.1
|
||||
smtpd_authorized_xclient_hosts = 127.0.0.1
|
||||
|
||||
This allows you to use the Postfix-specific XCLIENT SMTP command to safely
|
||||
simulate connections from remote systems before any remote systems are able to
|
||||
connect. If the test results look good, revert the above settings to the
|
||||
required production values. Typical settings in the pre-filter input instance
|
||||
include:
|
||||
|
||||
/etc/postfix-in/main.cf
|
||||
#
|
||||
# ...
|
||||
#
|
||||
|
||||
# No local delivery on border gateway
|
||||
#
|
||||
mydestination =
|
||||
alias_maps =
|
||||
alias_database =
|
||||
local_recipient_maps =
|
||||
local_transport = error:5.1.1 Mailbox unavailable
|
||||
|
||||
# Don't rewrite remote headers
|
||||
#
|
||||
local_header_rewrite_clients =
|
||||
|
||||
# All recipients of not yet filtered email go to the same filter
|
||||
together.
|
||||
#
|
||||
# With multiple instances, the content-filter is specified
|
||||
# via transport settings not the "content_filter" transport
|
||||
# switch override! Here the filter listens on local port 10025.
|
||||
#
|
||||
# If you need to route some users or recipient domains directly to the
|
||||
# output instance bypassing the filter, just define a transport table
|
||||
# with suitable entries.
|
||||
#
|
||||
default_transport = smtp:[127.0.0.1]:10025
|
||||
relay_transport = $default_transport
|
||||
virtual_transport = $default_transport
|
||||
transport_maps =
|
||||
|
||||
# Pass original client log information through the filter.
|
||||
#
|
||||
smtp_send_xforward_command = yes
|
||||
|
||||
# Avoid splitting the envelope and scanning messages multiple times.
|
||||
# Match the re-injection server's recipient limit.
|
||||
#
|
||||
smtp_destination_recipient_limit = 1000
|
||||
|
||||
# Tolerate occasional high latency in the content filter.
|
||||
#
|
||||
smtp_data_done_timeout = 1200s
|
||||
|
||||
# With xforward, match the output instance setting, if you
|
||||
# want "yes", set both to "yes".
|
||||
#
|
||||
smtpd_client_port_logging = no
|
||||
|
||||
# ... Lots of settings for inbound MX host ...
|
||||
|
||||
With the "input" instance configured, enable and start it:
|
||||
|
||||
# postmulti -i postfix-in -x postconf -e \
|
||||
"master_service_disable =" "authorized_submit_users = root"
|
||||
# postmulti -i postfix-in -e enable
|
||||
# postmulti -i postfix-in -p start
|
||||
|
||||
That's it. You now have a 3-instance configuration. A null-client sending all
|
||||
locally submitted mail to the internal mail hub and a pair of "mta" instances
|
||||
that receive mail from the Internet, pass it through a content-filter, and then
|
||||
deliver it to the internal destination.
|
||||
|
||||
Running "postfix start" or "postfix stop" will now start/stop all three Postfix
|
||||
instances. You can use "postfix -c /config/path start" to start just one
|
||||
instance, or use the instance name (or instance group name) via postmulti(1):
|
||||
|
||||
# postmulti -i - -p stop
|
||||
# postmulti -g mta -p status
|
||||
# postmulti -i postfix-out -p flush
|
||||
# postmulti -i postfix-in -p reload
|
||||
# ...
|
||||
|
||||
This example ends the multi-instance "walk through". The remainder of this
|
||||
document provides background information on Postfix multi-instance support
|
||||
features and options.
|
||||
|
||||
CCoommppoonneennttss ooff aa PPoossttffiixx ssyysstteemm
|
||||
|
||||
A Postfix system consists of the following components:
|
||||
|
||||
Shared among all instances:
|
||||
|
||||
* Command-line utilities for administrators and users installed in
|
||||
$command_directory, $sendmail_path, $mailq_path and $newaliases_path.
|
||||
|
||||
* Daemon executables, and run-time support files installed in
|
||||
$daemon_directory.
|
||||
|
||||
* Bundled documentation, installed in $html_directory, $manpage_directory and
|
||||
$readme_directory.
|
||||
|
||||
* Entries in /etc/passwd and /etc/group for the $mail_owner user and
|
||||
$setgid_group group. The $mail_owner user provides the mail system with a
|
||||
protected (non-root) execution context. The $setgid_group group is used
|
||||
exclusively to support the setgid postdrop(1) and postqueue(1) utilities
|
||||
(it mmuusstt nnoott be the primary group or secondary group of any users,
|
||||
including the $mail_owner user).
|
||||
|
||||
Private to each instance:
|
||||
|
||||
* The main.cf, master.cf (and other optional) configuration files in
|
||||
$config_directory.
|
||||
|
||||
* The maildrop, incoming, active, deferred and hold queues in
|
||||
$queue_directory (which contains additional directories needed by Postfix,
|
||||
and which optionally doubles as a chroot jail for Postfix daemon
|
||||
processes).
|
||||
|
||||
* Various caches (TLS session, address verification, ...) in $data_directory.
|
||||
|
||||
The Postfix configuration parameters mentioned above are collectively referred
|
||||
to as "installation parameters". Their default values are set when the Postfix
|
||||
software is built from source, and all but one may be optionally set to a non-
|
||||
default value via the main.cf file. The one parameter that (catch-22) cannot be
|
||||
set in main.cf is $config_directory, as this defines the location of the
|
||||
main.cf file itself.
|
||||
|
||||
Though config_directory cannot be set in main.cf, postfix(1) and most of the
|
||||
other command-line Postfix utilities allow you to specify a non-default
|
||||
configuration directory via a command line option (typically --cc) or via the
|
||||
MAIL_CONFIG environment variable. In this way, it is possible to have multiple
|
||||
configuration directories on the same machine, and to have multiple running
|
||||
master(8) daemons each with its own configuration files, queue directory and
|
||||
data directory.
|
||||
|
||||
These multiple running copies of master(8) share the base Postfix software.
|
||||
They do not (and cannot) share their configuration directories, queue
|
||||
directories or data directories.
|
||||
|
||||
Each combination of configuration directory, together with the queue directory
|
||||
and data directory (specified in the corresponding main.cf file) make up a
|
||||
Postfix iinnssttaannccee.
|
||||
|
||||
TThhee ddeeffaauulltt PPoossttffiixx iinnssttaannccee
|
||||
|
||||
One Postfix instance is special: this is the instance whose configuration
|
||||
directory is the default one compiled into the Postfix utilities. The location
|
||||
of the default configuration directory is typically /etc/postfix, and can be
|
||||
queried via the "postconf -d config_directory" command. We call the instance
|
||||
with this configuration directory the "default instance".
|
||||
|
||||
The default instance is responsible for local mail submission. The setgid
|
||||
postdrop(1) utility is used by the sendmail(1) local submission program to
|
||||
spool messages into the mmaaiillddrroopp sub-directory of the queue directory of the
|
||||
default instance.
|
||||
|
||||
Even in the rare case when "sendmail -C" is used to submit local mail into a
|
||||
non-default Postfix instance, for security reasons, postdrop(1) will consult
|
||||
the default main.cf file to check the validity of the requested non-default
|
||||
configuration directory.
|
||||
|
||||
So, while in most other respects, all instances are equal, the default instance
|
||||
is "more equal than others". You may choose to create additional instances, but
|
||||
you must have at least the default instance, with its configuration directory
|
||||
in the default compiled-in location.
|
||||
|
||||
IInnssttaannccee ggrroouuppss
|
||||
|
||||
The postmulti(1) multi-instance manager supports the notion of an instance
|
||||
"group". Typically, the member instances of an instance group constitute a
|
||||
logical service, and are expected to all be running or all be stopped.
|
||||
|
||||
In many cases a single Postfix instance will be a complete logical "service".
|
||||
You should define such instances as stand-alone instances that are not members
|
||||
of any instance "group". The null-client instance is an example of a non-group
|
||||
instance.
|
||||
|
||||
When a logical service consists of multiple Postfix instances, often a pair of
|
||||
pre-filter and post-filter instances with a content filter proxy between them,
|
||||
the related instances should be members of a single instance group (however,
|
||||
the content filter usually has its own start/stop procedure that is separate
|
||||
from any Postfix instance).
|
||||
|
||||
The default instance main.cf file's $multi_instance_directories configuration
|
||||
parameter lists the configuration directories of all secondary (non-default)
|
||||
instances. Together with the default instance, these secondary instances are
|
||||
managed by the multi-instance manager. Instances are started in the order
|
||||
listed, and stopped in the opposite order. For instances that are members of a
|
||||
service "group", you should arrange to start the service back-to-front, with
|
||||
the output stages started and ready to receive mail before the input stages are
|
||||
started.
|
||||
|
||||
MMuullttii--iinnssttaannccee ccoonnffiigguurraattiioonn ppaarraammeetteerrss
|
||||
|
||||
multi_instance_wrapper
|
||||
This default-instance configuration parameter must be set to a suitable
|
||||
multi-instance manager's "wrapper" program that controls the starting,
|
||||
stopping, etc. of a multi-instance Postfix system. To use the postmulti(1)
|
||||
manager described in this document, this parameter should be set with the
|
||||
"postmulti -e init" command.
|
||||
|
||||
multi_instance_directories
|
||||
This default-instance configuration parameter specifies an optional list of
|
||||
the secondary instances controlled via the multi-instance manager.
|
||||
Instances are listed in their "start" order, with the default instance
|
||||
always started first (if enabled). If $multi_instance_directories is left
|
||||
empty, the postfix(1) command runs with multi-instance support turned off,
|
||||
and none of the multi_instance_ configuration parameters will have any
|
||||
effect.
|
||||
|
||||
Do not assign a non-empty list of secondary instance configuration
|
||||
directories to multi_instance_directories until you have configured a
|
||||
suitable multi_instance_wrapper setting! This is best accomplished via the
|
||||
"postmulti -e init" command.
|
||||
|
||||
multi_instance_name
|
||||
Each Postfix instance may be assigned a distinct name (with "postfix -
|
||||
e create/import/assign -I name..."). This name can be used with the
|
||||
postmulti(1) command-line utility to perform tasks on the instance by name
|
||||
(rather than the full pathname of its configuration directory). Choose a
|
||||
name that concisely captures the role of the instance (it must start with
|
||||
"postfix-"). It is an error for two instances to have the same
|
||||
$multi_instance_name. You can leave an instance "nameless" by leaving this
|
||||
parameter at the default empty setting.
|
||||
|
||||
To avoid confusion in your logs, if you don't assign each secondary
|
||||
instance a non-empty (distinct) $multi_instance_name, you should make sure
|
||||
that the $syslog_name setting is different for each instance. The
|
||||
$syslog_name parameter defaults to $multi_instance_name when the latter is
|
||||
non-empty. If at all possible, the syslog_name should start with "postfix-
|
||||
", this helps log parsers to identify log entries from secondary Postfix
|
||||
instances.
|
||||
|
||||
multi_instance_group
|
||||
Each Postfix instance may be assigned an "instance group" name (with
|
||||
"postfix -e create/import/assign -G name..."). The default (empty) value of
|
||||
multi_instance_group parameter indicates a stand-alone instance that is not
|
||||
part of any group. The group name can be used with the postmulti(1)
|
||||
command-line utility to perform a task on the members of a group by name.
|
||||
Choose a single-word group name that concisely captures the role of the
|
||||
group.
|
||||
|
||||
multi_instance_enable
|
||||
This parameter controls whether a Postfix instance will be started by a
|
||||
Postfix multi-instance manager. The default value is "no". The instance can
|
||||
be started explicitly with "postfix -c /path/to/config/directory"; this is
|
||||
useful for testing.
|
||||
|
||||
When an instance is disabled, the postfix(1) "start" command is replaced by
|
||||
"check".
|
||||
|
||||
Some postfix(1) commands (such as "stop", "flush", ...) require a running
|
||||
Postfix instance, and skip instances that are disabled.
|
||||
|
||||
Other postfix(1) commands (such as "status", "set-permissions", "upgrade-
|
||||
configuration", ...) do not require a running Postfix system, and apply to
|
||||
all instances whether enabled or not.
|
||||
|
||||
The postmulti(1) utility can be used to create (or destroy) instances. It can
|
||||
also be used to "import" or "deport" existing instances into or from the list
|
||||
of managed instances. When using postmulti(1) to manage instances, the above
|
||||
configuration parameters are managed for you automatically. See below.
|
||||
|
||||
UUssiinngg tthhee ppoossttmmuullttii((11)) ccoommmmaanndd
|
||||
|
||||
* Initializing the multi-instance manager
|
||||
* Listing managed instances
|
||||
* Starting or stopping a multi-instance system
|
||||
* Ad-hoc multi-instance operations
|
||||
* Creating a new Postfix instance
|
||||
* Destroying a Postfix instance
|
||||
* Importing an existing Postfix instance
|
||||
* Deporting a managed Postfix instance
|
||||
* Assigning a new name or group name
|
||||
* Enabling/disabling managed instances
|
||||
|
||||
IInniittiiaalliizziinngg tthhee mmuullttii--iinnssttaannccee mmaannaaggeerr
|
||||
|
||||
Before postmulti(1) is used for the first time, you must install it as the
|
||||
multi_instance_wrapper for your Postfix system and enable multi-instance
|
||||
operation of the default Postfix instance. You can then proceed to add new or
|
||||
existing instances to the multi-instance configuration. This initial
|
||||
installation is accomplished as follows:
|
||||
|
||||
# postmulti -e init
|
||||
|
||||
This updates the default instance main.cf file as follows:
|
||||
|
||||
# Use postmulti(1) as a postfix-wrapper(5)
|
||||
#
|
||||
multi_instance_wrapper = ${command_directory}/postmulti -p --
|
||||
|
||||
# Configure the default instance to start when in multi-instance mode
|
||||
#
|
||||
multi_instance_enable = yes
|
||||
|
||||
If you prefer, you can make these changes by editing the default main.cf
|
||||
directly, or by using "postconf -e".
|
||||
|
||||
LLiissttiinngg mmaannaaggeedd iinnssttaanncceess
|
||||
|
||||
The list of managed instances consists of the default instance and the
|
||||
additional instances whose configuration directories are listed (in start
|
||||
order) under the multi_instance_directories parameter of the default main.cf
|
||||
configuration file.
|
||||
|
||||
You can list selected instances, groups of instances or all instances by
|
||||
specifying only the instance matching options with the "-l" option. The "-a"
|
||||
option is assumed if no other instance selection options are specified (this
|
||||
behavior changes with the "-e" option). As a special case, even if it has an
|
||||
explicit name, the default instance can always be selected via "-i -".
|
||||
|
||||
# postmulti -l -a
|
||||
# postmulti -l -g a_group
|
||||
# postmulti -l -i an_instance
|
||||
|
||||
The output is one line per instance (in "postfix start" order):
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|nnaammee |ggrroouupp|eennaabblleedd|ccoonnffiigg__ddiirreeccttoorryy |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|- |- |yes |/etc/postfix |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|mta-out|mta |yes |/etc/postfix/mta-out|
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|mta-in |mta |yes |/etc/postfix-mta-in |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|msa-out|msa |yes |/etc/postfix-msa-out|
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|msa-in |msa |yes |/etc/postfix-msa-in |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|test |- |no |/etc/postfix-test |
|
||||
|_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
The first line showing the column headings is not part of the output. When
|
||||
either the instance name or the instance group is not set, it is shown as a "-
|
||||
".
|
||||
|
||||
When selecting an existing instance via the "-i" option, you can always use the
|
||||
full pathname of its configuration directory instead of the instance (short)
|
||||
name. This is the only way to select a non-default nameless instance. The
|
||||
default instance can be selected via "-i -", whether it has a name or not.
|
||||
|
||||
To list instances in reverse start order, include the "-R" option together with
|
||||
the instance selection options.
|
||||
|
||||
SSttaarrttiinngg oorr ssttooppppiinngg aa mmuullttii--iinnssttaannccee ssyysstteemm
|
||||
|
||||
To start, stop, reload, etc. the complete (already configured as above) multi-
|
||||
instance system just use postfix(1) as you would with a single-instance system.
|
||||
The Postfix multi-instance wrapper framework insulates Postfix init.d start and
|
||||
package upgrade scripts from the details of multi-instance management!
|
||||
|
||||
The --pp option of postmulti(1) turns on postfix(1) compatibility mode. With this
|
||||
option the remaining arguments are exactly those supported by postfix(1), but
|
||||
commands are applied to all instances or all enabled instances as appropriate.
|
||||
As described above, this switch is required when using postmulti(1) as the
|
||||
multi_instance_wrapper.
|
||||
|
||||
If you want to specify a subset of instances by name, or group name, or run
|
||||
arbitrary commands (not just "postfix stop/start/etc. in the context
|
||||
(MAIL_CONFIG environment variable setting) of a particular instance or group of
|
||||
instances, then you can use the instance-aware postmulti(1) utility directly.
|
||||
|
||||
AAdd--hhoocc mmuullttii--iinnssttaannccee ooppeerraattiioonnss
|
||||
|
||||
The postmulti(1) command can be used by the administrator to run arbitrary
|
||||
commands in the context of one or more Postfix instances. The most common use-
|
||||
case is stopping or starting a group of Postfix instances:
|
||||
|
||||
# postmulti -g mygroup -p start
|
||||
# postmulti -g mygroup -p flush
|
||||
# postmulti -g mygroup -p reload
|
||||
# postmulti -g mygroup -p status
|
||||
# postmulti -g mygroup -p stop
|
||||
# postmulti -g mygroup -p upgrade-configuration
|
||||
|
||||
The --pp option is essentially a short-hand for a leading ppoossttffiixx command
|
||||
argument, but with appropriate additional options turned on depending on the
|
||||
first argument. In the case of "start", disabled instances are "checked"
|
||||
(postfix check) rather than simply skipped.
|
||||
|
||||
The resulting command is executed for each candidate instance with the
|
||||
MMAAIILL__CCOONNFFIIGG environment variable set to the configuration directory of the
|
||||
corresponding Postfix instance.
|
||||
|
||||
The postmulti(1) utility is able to launch commands other than postfix(1), Use
|
||||
the --xx option to ask postmulti to execute an ad-hoc command for all instances,
|
||||
a group of instances, or just one instance. With ad-hoc commands the
|
||||
multi_instance_enable parameter is ignored: the command is unconditionally
|
||||
executed for the instances selected via -a, -g or -i. In addition to
|
||||
MAIL_CONFIG, the following instance parameters are exported into the command
|
||||
environment:
|
||||
|
||||
command_directory=$command_directory
|
||||
daemon_directory=$daemon_directory
|
||||
config_directory=$config_directory
|
||||
queue_directory=$queue_directory
|
||||
data_directory=$data_directory
|
||||
multi_instance_name=$multi_instance_name
|
||||
multi_instance_group=$multi_instance_group
|
||||
multi_instance_enable=$multi_instance_enable
|
||||
|
||||
The config_directory setting is of course the same as MAIL_CONFIG, and is
|
||||
arguably redundant, but leaving it in is less surprising. If you want to skip
|
||||
disabled instances, just check multi_instance_enable environment variable and
|
||||
exit if it is set to "no".
|
||||
|
||||
The ability to run ad-hoc commands opens up a wealth of additional
|
||||
possibilities:
|
||||
|
||||
* Specify an instance by name rather than configuration directory when using
|
||||
sendmail(1) to send a verification probe:
|
||||
|
||||
$ postmulti -i postfix-myinst -x sendmail -bv test@example.net
|
||||
|
||||
* Display non-default main.cf settings of all Postfix instances. This uses an
|
||||
inline shell script to package together multiple shell commands to execute
|
||||
for each instance:
|
||||
|
||||
$ postmulti -x sh -c 'echo "-- $MAIL_CONFIG"; postconf -n'
|
||||
|
||||
* Put all mail in enabled member instances of a group on hold:
|
||||
|
||||
# postmulti -g group_name -x \
|
||||
sh -c 'test $multi_instance_enable = yes && postsuper -h ALL'
|
||||
|
||||
* Show top 10 domains in the deferred queue of all instances:
|
||||
|
||||
# postmulti -x sh -c 'echo "-- $MAIL_CONFIG"; qshape deferred | head -
|
||||
12'
|
||||
|
||||
CCrreeaattiinngg aa nneeww PPoossttffiixx iinnssttaannccee
|
||||
|
||||
The postmulti(1) command can be used to create additional Postfix instances.
|
||||
New instances are created with local submission and all "inet" services
|
||||
disabled via the following non-default parameter settings in the main.cf file:
|
||||
|
||||
authorized_submit_users =
|
||||
master_service_disable = inet
|
||||
|
||||
The above settings ensure that new instances are safe to start immediately:
|
||||
they will not conflict with inet listeners in existing Postfix instances. They
|
||||
will also not accept any mail until they are fully configured, at which point
|
||||
you can do away with one or both of the above safety measures.
|
||||
|
||||
The postmulti(1) command encourages a preferred way of organizing the
|
||||
configuration directories, queue directories and data directories of non-
|
||||
default instances. If the default instance settings are:
|
||||
|
||||
config_directory = /conf-path/postfix
|
||||
queue_directory = /queue-path/postfix
|
||||
data_directory = /data-path/postfix
|
||||
|
||||
A newly-created instance named postfix-myinst will by default have:
|
||||
|
||||
multi_instance_enable = no
|
||||
multi_instance_name = postfix-myinst
|
||||
config_directory = /conf-path/postfix-myinst
|
||||
queue_directory = /queue-path/postfix-myinst
|
||||
data_directory = /data-path/postfix-myinst
|
||||
|
||||
You can override any of these defaults when creating the instance, but unless
|
||||
you want to spread instance queue directories over multiple file-systems, use
|
||||
the default naming strategy. It keeps the multiple instances organized in a
|
||||
uniform, predictable fashion.
|
||||
|
||||
When specifying the instance name later, you can refer to it either as
|
||||
"postfix-myinst", or via the full path of the configuration directory.
|
||||
|
||||
To create a new instance just use the --ee ccrreeaattee option:
|
||||
|
||||
# postmulti -I postfix-myinst -e create
|
||||
|
||||
If the new instance is to belong to a group of related instances that implement
|
||||
a single logical service, assign it to a group:
|
||||
|
||||
# postmulti -I postfix-myinst -G mygroup -e create
|
||||
|
||||
If you want to override the conventional values of the instance installation
|
||||
parameters, specify their values on the command-line:
|
||||
|
||||
# postmulti [-I postfix-myinst] [-G mygroup] -e create \
|
||||
"config_directory = /path/to/config_directory" \
|
||||
"queue_directory = /path/to/queue_directory" \
|
||||
"data_directory = /path/to/data_directory"
|
||||
|
||||
A note on the --II and --GG options above. These are always used to assign a name
|
||||
or group name to an instance, while the --ii and --gg options always select
|
||||
existing instances. By default, the configuration directories of newly managed
|
||||
instances are appended to the instance list. You can use the "-i" or "-g" or "-
|
||||
a" options to insert the new instance before the specified instance or group,
|
||||
or at the beginning of the instance list (multi_instance_directories parameter
|
||||
of the default instance).
|
||||
|
||||
If you do specify a name (use "-I" with a name that is not "-") for the new
|
||||
instance, you may omit any of the 3 instance installation parameters whose
|
||||
instance-name based value is acceptable. Otherwise, all three instance
|
||||
installation parameters are required. You should set the "syslog_name"
|
||||
explicitly in the main.cf file of a "nameless" instance, in order to avoid
|
||||
confusion in the mail logs when multiple instances are in use.
|
||||
|
||||
DDeessttrrooyyiinngg aa PPoossttffiixx iinnssttaannccee
|
||||
|
||||
If you no longer need an instance, you can destroy it via:
|
||||
|
||||
# postmulti -i postfix-myinst -p stop
|
||||
# postmulti -i postfix-myinst -e disable
|
||||
# postmulti -i postfix-myinst -e destroy
|
||||
|
||||
The instance must be stopped, disabled and have no queued messages. This is
|
||||
expected to fully delete a just created instance that has never been used. If
|
||||
the instance is not freshly created, files added after the instance was created
|
||||
will remain in the configuration, queue or data directories, in which case the
|
||||
corresponding directory may not be fully removed and a warning to that effect
|
||||
will be displayed. You can complete the destruction of the instance manually by
|
||||
removing any unwanted remnants of the instance-specific "private" directories.
|
||||
|
||||
IImmppoorrttiinngg aann eexxiissttiinngg PPoossttffiixx iinnssttaannccee
|
||||
|
||||
If you already have an existing secondary Postfix instance that is not yet
|
||||
managed via postmulti(1), you can "import" it into the list of managed
|
||||
instances. If your instance is already using the default configuration
|
||||
directory naming scheme, just specify the corresponding instance name (the
|
||||
multi_instance_name parameter in its configuration file will be adjusted to
|
||||
match this name if necessary):
|
||||
|
||||
# postmulti -I postfix-myinst [-G mygroup] -e import
|
||||
|
||||
Otherwise, you must specify the location of its configuration directory:
|
||||
|
||||
# postmulti [-I postfix-myinst] [-G mygroup] -e import \
|
||||
"config_directory = /path/of/config_directory"
|
||||
|
||||
When the instance is imported, you can assign a name or a group. As with
|
||||
"create", you can control the placement of the new instance in the start order
|
||||
by using "-i", "-g" or "-a" to prepend before the selected instance or
|
||||
instances.
|
||||
|
||||
An imported instance is usually not multi-instance "enabled", unless it was
|
||||
part of a multi-instance configuration at an earlier time. If it is fully
|
||||
configured and ready to run, don't forget to enable it and if necessary start
|
||||
it. When other enabled instances are already running, new instances need to be
|
||||
started individually when they are first created or imported.
|
||||
|
||||
To find out what instances are running, use:
|
||||
|
||||
# postfix status
|
||||
|
||||
DDeeppoorrttiinngg aa mmaannaaggeedd PPoossttffiixx iinnssttaannccee
|
||||
|
||||
You can "deport" an existing instance from the list of managed instances. This
|
||||
does not destroy the instance, rather the instance just becomes a stand-alone
|
||||
Postfix instance not registered with the multi-instance manager. postmulti(1)
|
||||
will refuse to "deport" an instance that is not stopped and disabled.
|
||||
|
||||
# postmulti -i postfix-myinst -p stop
|
||||
# postmulti -i postfix-myinst -e disable
|
||||
# postmulti -i postfix-myinst -e deport
|
||||
|
||||
AAssssiiggnniinngg aa nneeww nnaammee oorr ggrroouupp nnaammee
|
||||
|
||||
You can assign a new name or new group to a managed instance. Use "-" as the
|
||||
new value to assign the instance to no group or make it nameless. To specify a
|
||||
nameless secondary instance use the configuration directory path instead of the
|
||||
old name:
|
||||
|
||||
# postmulti -i postfix-old [-I postfix-new] [-G newgroup] -e assign
|
||||
|
||||
EEnnaabblliinngg//ddiissaabblliinngg mmaannaaggeedd iinnssttaanncceess
|
||||
|
||||
You can enable or disable a managed instance. As documented in postfix-wrapper
|
||||
(5), disabled instances are skipped with actions that start, stop or control
|
||||
running Postfix instances.
|
||||
|
||||
# postmulti -i postfix-myinst -e enable
|
||||
# postmulti -i postfix-myinst -e disable
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
Wietse Venema created Postfix, designed and implemented the multi-instance
|
||||
wrapper framework and provided design feedback that made the postmulti(1)
|
||||
utility much more general and useful than originally envisioned.
|
||||
|
||||
The postmulti(1) utility was developed by Victor Duchovni of Morgan Stanley,
|
||||
who also wrote the initial version of this document.
|
||||
|
||||
135
README_FILES/MYSQL_README
Normal file
135
README_FILES/MYSQL_README
Normal file
|
|
@ -0,0 +1,135 @@
|
|||
PPoossttffiixx MMyySSQQLL HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The Postfix mysql map type allows you to hook up Postfix to a MySQL database.
|
||||
This implementation allows for multiple mysql databases: you can use one for a
|
||||
virtual(5) table, one for an access(5) table, and one for an aliases(5) table
|
||||
if you want. You can specify multiple servers for the same database, so that
|
||||
Postfix can switch to a good database server if one goes bad.
|
||||
|
||||
Busy mail servers using mysql maps will generate lots of concurrent mysql
|
||||
clients, so the mysql server(s) should be run with this fact in mind. You can
|
||||
reduce the number of concurrent mysql clients by using the Postfix proxymap(8)
|
||||
service.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh MMyySSQQLL ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
Note: to use mysql with Debian GNU/Linux's Postfix, all you need is to install
|
||||
the postfix-mysql package and you're done. There is no need to recompile
|
||||
Postfix.
|
||||
|
||||
The Postfix MySQL client utilizes the mysql client library, which can be
|
||||
obtained from:
|
||||
|
||||
https://www.mysql.com/downloads/
|
||||
|
||||
In order to build Postfix with mysql map support, you will need to add -
|
||||
DHAS_MYSQL and -I for the directory containing the mysql headers, and the
|
||||
mysqlclient library (and libm) to AUXLIBS_MYSQL, for example:
|
||||
|
||||
make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include" \
|
||||
"AUXLIBS_MYSQL=-L/usr/local/mysql/lib -lmysqlclient -lz -lm"
|
||||
|
||||
If your MySQL shared library is in a directory that the RUN-TIME linker does
|
||||
not know about, add a "-Wl,-R,/path/to/directory" option after "-lmysqlclient".
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_MYSQL. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded MySQL database client, but only the new AUXLIBS_MYSQL variable supports
|
||||
building a dynamically-loaded or statically-loaded MySQL database client.
|
||||
|
||||
Failure to use the AUXLIBS_MYSQL variable will defeat the purpose of
|
||||
dynamic database client loading. Every Postfix executable file will have
|
||||
MYSQL database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
On Solaris, use this instead:
|
||||
|
||||
make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include" \
|
||||
"AUXLIBS_MYSQL=-L/usr/local/mysql/lib -R/usr/local/mysql/lib \
|
||||
-lmysqlclient -lz -lm"
|
||||
|
||||
Then, just run 'make'. This requires libz, the compression library. Older mysql
|
||||
implementations build without libz.
|
||||
|
||||
UUssiinngg MMyySSQQLL ttaabblleess
|
||||
|
||||
Once Postfix is built with mysql support, you can specify a map type in main.cf
|
||||
like this:
|
||||
|
||||
alias_maps = mysql:/etc/postfix/mysql-aliases.cf
|
||||
|
||||
The file /etc/postfix/mysql-aliases.cf specifies lots of information telling
|
||||
Postfix how to reference the mysql database. For a complete description, see
|
||||
the mysql_table(5) manual page.
|
||||
|
||||
EExxaammppllee:: llooccaall aalliiaasseess
|
||||
|
||||
#
|
||||
# mysql config file for local(8) aliases(5) lookups
|
||||
#
|
||||
|
||||
# The user name and password to log into the mysql server.
|
||||
user = someone
|
||||
password = some_password
|
||||
|
||||
# The database name on the servers.
|
||||
dbname = customer_database
|
||||
|
||||
# For Postfix 2.2 and later The SQL query template.
|
||||
# See mysql_table(5) for details.
|
||||
query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
|
||||
|
||||
# For Postfix releases prior to 2.2. See mysql_table(5) for details.
|
||||
select_field = forw_addr
|
||||
table = mxaliases
|
||||
where_field = alias
|
||||
# Don't forget the leading "AND"!
|
||||
additional_conditions = AND status = 'paid'
|
||||
|
||||
# This is necessary to make UTF8 queries work for Postfix 2.11 .. 3.1,
|
||||
# and is the default setting as of Postfix 3.2.
|
||||
option_group = client
|
||||
|
||||
AAddddiittiioonnaall nnootteess
|
||||
|
||||
Postfix 3.2 and later read [[cclliieenntt]] option group settings by default. To
|
||||
disable this, specify no ooppttiioonn__ffiillee and specify "ooppttiioonn__ggrroouupp ==" (i.e. an
|
||||
empty value).
|
||||
|
||||
Postfix 3.1 and earlier don't read [[cclliieenntt]] option group settings unless a non-
|
||||
empty ooppttiioonn__ffiillee or ooppttiioonn__ggrroouupp value are specified. To enable this, specify,
|
||||
for example "ooppttiioonn__ggrroouupp == cclliieenntt".
|
||||
|
||||
The MySQL configuration interface setup allows for multiple mysql databases:
|
||||
you can use one for a virtual table, one for an access table, and one for an
|
||||
aliases table if you want.
|
||||
|
||||
Since sites that have a need for multiple mail exchangers may enjoy the
|
||||
convenience of using a networked mailer database, but do not want to introduce
|
||||
a single point of failure to their system, we've included the ability to have
|
||||
Postfix reference multiple hosts for access to a single mysql map. This will
|
||||
work if sites set up mirrored mysql databases on two or more hosts. Whenever
|
||||
queries fail with an error at one host, the rest of the hosts will be tried in
|
||||
random order. If no mysql server hosts are reachable, then mail will be
|
||||
deferred until at least one of those hosts is reachable.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* The initial version was contributed by Scott Cotton and Joshua Marcus, IC
|
||||
Group, Inc.
|
||||
* Liviu Daia revised the configuration interface and added the main.cf
|
||||
configuration feature.
|
||||
* Liviu Daia with further refinements from Jose Luis Tallon and Victor
|
||||
Duchovni developed the common query, result_format, domain and
|
||||
expansion_limit interface for LDAP, MySQL and PostgreSQL.
|
||||
|
||||
102
README_FILES/NFS_README
Normal file
102
README_FILES/NFS_README
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
PPoossttffiixx aanndd NNFFSS
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPoossttffiixx ssuuppppoorrtt ssttaattuuss ffoorr NNFFSS
|
||||
|
||||
What is the status of support for Postfix on NFS? The answer is that Postfix
|
||||
itself is supported when you use NFS, but there is no promise that an NFS-
|
||||
related problem will promptly receive a Postfix workaround, or that a
|
||||
workaround will even be possible.
|
||||
|
||||
That said, Postfix will in many cases work very well on NFS, because Postfix
|
||||
implements a number of workarounds (see below). Good NFS implementations seldom
|
||||
if ever give problems with Postfix, so Wietse recommends that you spend your
|
||||
money wisely.
|
||||
|
||||
PPoossttffiixx ffiillee lloocckkiinngg aanndd NNFFSS
|
||||
|
||||
For the Postfix mail queue, it does not matter how well NFS file locking works.
|
||||
The reason is that you cannot share Postfix queues among multiple running
|
||||
Postfix instances. You can use NFS to switch a Postfix mail queue from one NFS
|
||||
client to another one, but only one NFS client can access a Postfix mail queue
|
||||
at any particular point in time.
|
||||
|
||||
For mailbox file sharing with NFS, your options are to use ffccnnttll (kernel
|
||||
locks), ddoottlloocckk (username.lock files), to use both locking methods
|
||||
simultaneously, or to switch to maildir format. The maildir format uses one
|
||||
file per message and needs no file locking support in Postfix or in other mail
|
||||
software.
|
||||
|
||||
Many sites that use mailbox format play safe and use both locking methods
|
||||
simultaneously.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
virtual_mailbox_lock = fcntl, dotlock
|
||||
mailbox_delivery_lock = fcntl, dotlock
|
||||
|
||||
PPoossttffiixx NNFFSS wwoorrkkaarroouunnddss
|
||||
|
||||
The list below summarizes the workarounds that exist for running Postfix on NFS
|
||||
as of the middle of 2003. As a reminder, Postfix itself is still supported when
|
||||
it runs on NFS, but there is no promise that an NFS-related problem will
|
||||
promptly receive a Postfix workaround, or that a workaround will even be
|
||||
possible.
|
||||
|
||||
* Problem: when renaming a file, the operation may succeed but report an
|
||||
error anyway[1].
|
||||
|
||||
Workaround: when rename(old, new) reports an error, Postfix checks if the
|
||||
new name exists and the old name is gone. If the check succeeds, Postfix
|
||||
assumes that the rename() operation completed normally.
|
||||
|
||||
* Problem: when creating a directory, the operation may succeed but report an
|
||||
error anyway[1].
|
||||
|
||||
Workaround: when mkdir(new) reports an EEXIST error, Postfix checks if the
|
||||
new name resolves to a directory. If the check succeeds, Postfix assumes
|
||||
that the mkdir() operation completed normally.
|
||||
|
||||
* Problem: when creating a hardlink to a file, the operation may succeed but
|
||||
report an error anyway[1].
|
||||
|
||||
Workaround: when link(old, new) fails, Postfix compares the device and
|
||||
inode number of the old and new files. When the two files are identical,
|
||||
Postfix assumes that the link() operation completed normally.
|
||||
|
||||
* Problem: when creating a dotlock (username.lock) file, the operation may
|
||||
succeed but report an error anyway[1].
|
||||
|
||||
Workaround: in this case, the only safe action is to back off and try again
|
||||
later.
|
||||
|
||||
* Problem: when a file server's "time of day" clock is not synchronized with
|
||||
the client's "time of day" clock, email deliveries are delayed by a minute
|
||||
or more.
|
||||
|
||||
Workaround: Postfix explicitly sets file time stamps to avoid delays with
|
||||
new mail (Postfix uses "last modified" file time stamps to decide when a
|
||||
queue file is ready for delivery).
|
||||
|
||||
[1] How can an operation succeed and report an error anyway?
|
||||
|
||||
Suppose that an NFS server executes a client request successfully, and that the
|
||||
server's reply to the client is lost. After some time the client retransmits
|
||||
the request to the server. Normally, the server remembers that it already
|
||||
completed the request (it keeps a list of recently-completed requests and
|
||||
replies), and simply retransmits the reply.
|
||||
|
||||
However, when the server has rebooted or when it has been very busy, the server
|
||||
no longer remembers that it already completed the request, and repeats the
|
||||
operation. This causes no problems with file read/write requests (they contain
|
||||
a file offset and can therefore be repeated safely), but fails with non-
|
||||
idempotent operations. For example, when the server executes a retransmitted
|
||||
rename() request, the server reports an ENOENT error because the old name does
|
||||
not exist; and when the server executes a retransmitted link(), mkdir() or
|
||||
create() request, the server reports an EEXIST error because the name already
|
||||
exists.
|
||||
|
||||
Thus, successful, non-idempotent, NFS operations will report false errors when
|
||||
the server reply is lost, the client retransmits the request, and the server
|
||||
does not remember that it already completed the request.
|
||||
|
||||
496
README_FILES/OVERVIEW
Normal file
496
README_FILES/OVERVIEW
Normal file
|
|
@ -0,0 +1,496 @@
|
|||
PPoossttffiixx AArrcchhiitteeccttuurree OOvveerrvviieeww
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document presents an overview of the Postfix architecture, and provides
|
||||
pointers to descriptions of every Postfix command or server program. The text
|
||||
gives the general context in which each command or server program is used, and
|
||||
provides pointers to documents with specific usage examples and background
|
||||
information.
|
||||
|
||||
Topics covered by this document:
|
||||
|
||||
* How Postfix receives mail
|
||||
* How Postfix delivers mail
|
||||
* Postfix behind the scenes
|
||||
* Postfix support commands
|
||||
|
||||
HHooww PPoossttffiixx rreecceeiivveess mmaaiill
|
||||
|
||||
When a message enters the Postfix mail system, the first stop on the inside is
|
||||
the incoming queue. The figure below shows the main processes that are involved
|
||||
with new mail. Names followed by a number are Postfix commands or server
|
||||
programs, while unnumbered names inside shaded areas represent Postfix queues.
|
||||
|
||||
trivial-
|
||||
rewrite(8)
|
||||
|
||||
Network -> smtpd(8)
|
||||
|
||||
^ |
|
||||
\ | v
|
||||
|
||||
Network -> qmqpd(8) -> cleanup(8) -> incoming
|
||||
|
||||
/
|
||||
|
||||
pickup(8) <- maildrop
|
||||
|
||||
^
|
||||
|
|
||||
|
||||
Local -> sendmail(1) -> postdrop(1)
|
||||
|
||||
* Network mail enters Postfix via the smtpd(8) or qmqpd(8) servers. These
|
||||
servers remove the SMTP or QMQP protocol encapsulation, enforce some sanity
|
||||
checks to protect Postfix, and give the sender, recipients and message
|
||||
content to the cleanup(8) server. The smtpd(8) server can be configured to
|
||||
block unwanted mail, as described in the SMTPD_ACCESS_README document.
|
||||
|
||||
* Local submissions are received with the Postfix sendmail(1) compatibility
|
||||
command, and are queued in the maildrop queue by the privileged postdrop(1)
|
||||
command. This arrangement even works while the Postfix mail system is not
|
||||
running. The local pickup(8) server picks up local submissions, enforces
|
||||
some sanity checks to protect Postfix, and gives the sender, recipients and
|
||||
message content to the cleanup(8) server.
|
||||
|
||||
* Mail from internal sources is given directly to the cleanup(8) server.
|
||||
These sources are not shown in the figure, and include: mail that is
|
||||
forwarded by the local(8) delivery agent (see next section), messages that
|
||||
are returned to the sender by the bounce(8) server (see second-next
|
||||
section), and postmaster notifications about problems with Postfix.
|
||||
|
||||
* The cleanup(8) server implements the final processing stage before mail is
|
||||
queued. It adds missing From: and other message headers, and transforms
|
||||
addresses as described in the ADDRESS_REWRITING_README document.
|
||||
Optionally, the cleanup(8) server can be configured to do light-weight
|
||||
content inspection with regular expressions as described in the
|
||||
BUILTIN_FILTER_README document. The cleanup(8) server places the result as
|
||||
a single file into the incoming queue, and notifies the queue manager (see
|
||||
next section) of the arrival of new mail.
|
||||
|
||||
* The trivial-rewrite(8) server rewrites addresses to the standard
|
||||
"user@fully.qualified.domain" form, as described in the
|
||||
ADDRESS_REWRITING_README document. Postfix currently does not implement a
|
||||
rewriting language, but a lot can be done via table lookups and, if need
|
||||
be, regular expressions.
|
||||
|
||||
HHooww PPoossttffiixx ddeelliivveerrss mmaaiill
|
||||
|
||||
Once a message has reached the incoming queue the next step is to deliver it.
|
||||
The figure shows the main components of the Postfix mail delivery apparatus.
|
||||
Names followed by a number are Postfix commands or server programs, while
|
||||
unnumbered names inside shaded areas represent Postfix queues.
|
||||
|
||||
trivial- smtp(8) -> Network
|
||||
rewrite(8)
|
||||
/
|
||||
|
||||
- lmtp(8) -> Network
|
||||
^ |
|
||||
| v /
|
||||
|
||||
incoming -> active -> qmgr(8) --- local(8) -> File, command
|
||||
|
||||
\
|
||||
^ |
|
||||
| v - virtual(8) -> File
|
||||
|
||||
deferred \
|
||||
|
||||
pipe(8) -> Command
|
||||
|
||||
* The queue manager (the qmgr(8) server process in the figure) is the heart
|
||||
of Postfix mail delivery. It contacts the smtp(8), lmtp(8), local(8),
|
||||
virtual(8), pipe(8), discard(8) or error(8) delivery agents, and sends a
|
||||
delivery request for one or more recipient addresses. The discard(8) and
|
||||
error(8) delivery agents are special: they discard or bounce all mail, and
|
||||
are not shown in the figure above.
|
||||
|
||||
The queue manager maintains a limited active queue with the messages that
|
||||
it has opened for delivery. The active queue acts as a limited window on
|
||||
potentially large incoming or deferred queues. The limited active queue
|
||||
prevents the queue manager from running out of memory under heavy load.
|
||||
|
||||
The queue manager maintains a separate deferred queue for mail that cannot
|
||||
be delivered, so that a large mail backlog will not slow down normal queue
|
||||
accesses. The queue manager's strategy for delayed mail delivery attempts
|
||||
is described in the QSHAPE_README and TUNING_README documents.
|
||||
|
||||
* The trivial-rewrite(8) server resolves each recipient address according to
|
||||
its local or remote address class, as defined in the ADDRESS_CLASS_README
|
||||
document. Additional routing information can be specified with the optional
|
||||
transport(5) table. The trivial-rewrite(8) server optionally queries the
|
||||
relocated(5) table for recipients whose address has changed; mail for such
|
||||
recipients is returned to the sender with an explanation.
|
||||
|
||||
* The smtp(8) client looks up a list of SMTP servers for the destination(s)
|
||||
in a delivery request, sorts the list by preference, and tries each server
|
||||
in turn until it has delivered or bounced all recipients in the delivery
|
||||
request. It encapsulates the sender, recipients and message content as
|
||||
required by the SMTP protocol; this includes message body conversion from
|
||||
8-bit MIME to 7-bit encoding, but does not include RFC 2047 header
|
||||
encoding.
|
||||
|
||||
* The lmtp(8) client speaks a protocol similar to SMTP that is optimized for
|
||||
delivery to mailbox servers such as Cyrus. The advantage of this setup is
|
||||
that one Postfix machine can feed multiple mailbox servers over LMTP. The
|
||||
opposite is true as well: one mailbox server can be fed over LMTP by
|
||||
multiple Postfix machines.
|
||||
|
||||
* The local(8) delivery agent understands UNIX-style mailboxes, qmail-
|
||||
compatible maildir files, Sendmail-style system-wide aliases(5) databases,
|
||||
and Sendmail-style per-user .forward files. Multiple local delivery agents
|
||||
can be run in parallel, but parallel delivery to the same user is usually
|
||||
limited.
|
||||
|
||||
The local(8) delivery agent has hooks for alternative forms of local
|
||||
delivery: you can configure it to deliver to mailbox files in user home
|
||||
directories, you can configure it to delegate mailbox delivery to an
|
||||
external command such as procmail, or you can delegate delivery to a
|
||||
different Postfix delivery agent.
|
||||
|
||||
* The virtual(8) delivery agent is a bare-bones delivery agent that delivers
|
||||
to UNIX-style mailbox or qmail-style maildir files only. This delivery
|
||||
agent can deliver mail for multiple domains, which makes it especially
|
||||
suitable for hosting lots of small domains on a single machine. This is
|
||||
described in the VIRTUAL_README document.
|
||||
|
||||
* The pipe(8) mailer is the outbound interface to other mail processing
|
||||
systems (the Postfix sendmail(1) command being the inbound interface). The
|
||||
interface is UNIX compatible: the pipe(8) mailer provides information to a
|
||||
child process command line, environment variables, and standard input
|
||||
stream, and expects a child process exit status code as defined in
|
||||
<sysexits.h>. Examples of delivery via the pipe(8) mailer are in the
|
||||
FILTER_README, MAILDROP_README, and UUCP_README documents.
|
||||
|
||||
PPoossttffiixx bbeehhiinndd tthhee sscceenneess
|
||||
|
||||
The previous sections gave an overview of how Postfix server processes send and
|
||||
receive mail. These server processes rely on other server processes that do
|
||||
things behind the scenes. The text below attempts to visualize each service in
|
||||
its own context. As before, names followed by a number are Postfix commands or
|
||||
server programs, while unnumbered names inside shaded areas represent Postfix
|
||||
queues.
|
||||
|
||||
* The resident master(8) server is the supervisor that keeps an eye on the
|
||||
well-being of the Postfix mail system. It is typically started at system
|
||||
boot time with the "postfix start" command, and keeps running until the
|
||||
system goes down. The master(8) server is responsible for starting Postfix
|
||||
server processes to receive and deliver mail, and for restarting servers
|
||||
that terminate prematurely because of some problem. The master(8) server is
|
||||
also responsible for enforcing the server process count limits as specified
|
||||
in the mmaasstteerr..ccff configuration file. The picture below gives the program
|
||||
hierarchy when Postfix is started up. Only some of the mail handling daemon
|
||||
processes are shown.
|
||||
|
||||
postfix(1)
|
||||
|
||||
|
|
||||
|
|
||||
|
||||
postfix-script(1)
|
||||
|
||||
/ | \
|
||||
|
|
||||
/ \
|
||||
|
||||
postsuper(1) master(8) postlog(1)
|
||||
|
||||
/ | \
|
||||
|
|
||||
/ \
|
||||
|
||||
smtpd(8) qmgr(8) local(8)
|
||||
|
||||
* The anvil(8) server implements client connection and request rate limiting
|
||||
for all smtpd(8) servers. The TUNING_README document provides guidance for
|
||||
dealing with mis-behaving SMTP clients. The anvil(8) service is available
|
||||
in Postfix version 2.2 and later.
|
||||
|
||||
Network -> smtpd(8) <-> anvil(8)
|
||||
|
||||
* The bounce(8), defer(8) and trace(8) services each maintain their own queue
|
||||
directory trees with per-message logfiles. Postfix uses this information
|
||||
when sending "failed", "delayed" or "success" delivery status notifications
|
||||
to the sender.
|
||||
|
||||
The trace(8) service also implements support for the Postfix "sendmail -bv"
|
||||
and "sendmail -v" commands which produce reports about how Postfix delivers
|
||||
mail, and is available with Postfix version 2.1 and later. See DEBUG_README
|
||||
for examples.
|
||||
|
||||
qmgr(8) Delivery
|
||||
cleanup(8) -> Postfix -> agents
|
||||
queue
|
||||
|
||||
^ | |
|
||||
| v v
|
||||
|
||||
(Non-) bounce(8) Queue id,
|
||||
delivery <- defer(8) <- recipient,
|
||||
notice trace(8) status
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
Per-
|
||||
message
|
||||
logfiles
|
||||
|
||||
* The flush(8) servers maintain per-destination logs and implement "sendmail
|
||||
-qRsite", "sendmail -qIqueueid" "postqueue -s site", "postqueue -
|
||||
i queueid", and ETRN as described in the ETRN_README document. This moves
|
||||
selected queue files from the deferred queue back to the incoming queue and
|
||||
requests their delivery. The flush(8) service is available with Postfix
|
||||
version 1.0 and later.
|
||||
|
||||
incoming
|
||||
^
|
||||
deferred
|
||||
|
||||
^
|
||||
|
|
||||
|
||||
smtpd(8) Destination Deferred Delivery
|
||||
sendmail(1) - to flush -> flush(8) <- destination, - agents,
|
||||
postqueue(1) queue id qmgr(8)
|
||||
|
||||
^ |
|
||||
| v
|
||||
|
||||
Per-dest-
|
||||
ination
|
||||
logs
|
||||
|
||||
* The proxymap(8) servers provide read-only and read-write table lookup
|
||||
service to Postfix processes. This overcomes chroot restrictions, reduces
|
||||
the number of open lookup tables by sharing one open table among multiple
|
||||
processes, and implements single-updater tables.
|
||||
|
||||
* The scache(8) server maintains the connection cache for the Postfix smtp(8)
|
||||
client. When connection caching is enabled for selected destinations, the
|
||||
smtp(8) client does not disconnect immediately after a mail transaction,
|
||||
but gives the connection to the connection cache server which keeps the
|
||||
connection open for a limited amount of time. The smtp(8) client continues
|
||||
with some other mail delivery request. Meanwhile, any smtp(8) process can
|
||||
ask the scache(8) server for that cached connection and reuse it for mail
|
||||
delivery. As a safety measure, Postfix limits the number of times that a
|
||||
connection may be reused.
|
||||
|
||||
When delivering mail to a destination with multiple mail servers,
|
||||
connection caching can help to skip over a non-responding server, and thus
|
||||
dramatically speed up delivery. SMTP connection caching is available in
|
||||
Postfix version 2.2 and later. More information about this feature is in
|
||||
the CONNECTION_CACHE_README document.
|
||||
|
||||
/-- smtp(8) --> Internet
|
||||
|
||||
qmgr(8)
|
||||
|
|
||||
\-- | smtp(8)
|
||||
|
|
||||
| ^
|
||||
v |
|
||||
|
||||
scache(8)
|
||||
|
||||
A Postfix smtp(8) client can reuse a TLS-encrypted connection (with
|
||||
"smtp_tls_connection_reuse = yes"). This can greatly reduce the overhead of
|
||||
connection setup and improves message delivery rates. After a Postfix smtp
|
||||
(8) client connects to a remote SMTP server and sends plaintext EHLO and
|
||||
STARTTLS commands, the smtp(8) client inserts a tlsproxy(8) process into
|
||||
the connection as shown in the top of the figure below.
|
||||
|
||||
/-- smtp(8) --> tlsproxy(8) --> Internet
|
||||
|
||||
qmgr(8)
|
||||
|
|
||||
\-- | smtp(8)
|
||||
|
|
||||
| ^
|
||||
v |
|
||||
|
||||
scache(8)
|
||||
|
||||
After the mail transaction completes, the Postfix smtp(8) client gives the
|
||||
smtp(8)-to-tlsproxy(8) connection to the scache(8) server, which keeps the
|
||||
connection open for a limited amount of time. The smtp(8) client continues
|
||||
with some other mail delivery request. Meanwhile, any Postfix smtp(8)
|
||||
client can ask the scache(8) server for that cached connection and reuse it
|
||||
for mail delivery.
|
||||
|
||||
* The showq(8) servers list the Postfix queue status. This is the queue
|
||||
listing service that does the work for the mailq(1) and postqueue(1)
|
||||
commands.
|
||||
|
||||
mailq(1) Postfix
|
||||
Output <- post- <- showq(8) <- queue
|
||||
queue(1)
|
||||
|
||||
* The spawn(8) servers run non-Postfix commands on request, with the client
|
||||
connected via socket or FIFO to the command's standard input, output and
|
||||
error streams. You can find examples of its use in the SMTPD_POLICY_README
|
||||
document.
|
||||
|
||||
* The tlsmgr(8) server runs when TLS (Transport Layer Security, formerly
|
||||
known as SSL) is turned on in the Postfix smtp(8) client or smtpd(8)
|
||||
server. This process has two duties:
|
||||
|
||||
o Maintain the pseudo-random number generator (PRNG) that is used to seed
|
||||
the TLS engines in Postfix smtp(8) client or smtpd(8) server processes.
|
||||
The state of this PRNG is periodically saved to a file, and is read
|
||||
when tlsmgr(8) starts up.
|
||||
|
||||
o Maintain the optional Postfix smtp(8) client or smtpd(8) server caches
|
||||
with TLS session keys. Saved keys can improve performance by reducing
|
||||
the amount of computation at the start of a TLS session.
|
||||
|
||||
TLS support is available in Postfix version 2.2 and later. Information
|
||||
about the Postfix TLS implementation is in the TLS_README document.
|
||||
|
||||
<---seed--- ---seed--->
|
||||
Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network
|
||||
<-session-> <-session->
|
||||
|
||||
/ | \
|
||||
|
|
||||
/ \
|
||||
|
||||
smtpd PRNG smtp
|
||||
session state session
|
||||
cache file cache
|
||||
|
||||
* The verify(8) server verifies that a sender or recipient address is
|
||||
deliverable before the smtpd(8) server accepts it. The verify(8) server
|
||||
queries a cache with address verification results. If a result is not
|
||||
found, the verify(8) server injects a probe message into the Postfix queue
|
||||
and processes the status update from a delivery agent or queue manager.
|
||||
This process is described in the ADDRESS_VERIFICATION_README document. The
|
||||
verify(8) service is available with Postfix version 2.1 and later.
|
||||
|
||||
probe Postfix
|
||||
message -> mail
|
||||
Network -> smtpd(8) <-> verify(8) -> queue
|
||||
|
||||
|
|
||||
v
|
||||
|
||||
<- probe Postfix -> Local
|
||||
status <- delivery -> Network
|
||||
^ agents
|
||||
|
|
||||
v
|
||||
|
||||
Address
|
||||
verification
|
||||
cache
|
||||
|
||||
* The postscreen(8) server can be put "in front" of Postfix smtpd(8)
|
||||
processes. Its purpose is to accept connections from the network and to
|
||||
decide what SMTP clients are allowed to talk to Postfix. According to the
|
||||
2008 MessageLabs annual report, 81% of all email was spam, and 90% of that
|
||||
was sent by botnets; by 2010, those numbers were 92% and 95%, respectively.
|
||||
While postscreen(8) keeps the zombies away, more smtpd(8) processes remain
|
||||
available for legitimate clients.
|
||||
|
||||
postscreen(8) maintains a temporary allowlist for clients that pass its
|
||||
tests; by allowing allowlisted clients to skip tests, postscreen(8)
|
||||
minimizes its impact on legitimate email traffic.
|
||||
|
||||
The postscreen(8) server is available with Postfix 2.8 and later. To keep
|
||||
the implementation simple, postscreen(8) delegates DNS allow/denylist
|
||||
lookups to dnsblog(8) server processes, and delegates TLS encryption/
|
||||
decryption to tlsproxy(8) server processes. This delegation is invisible to
|
||||
the remote SMTP client.
|
||||
|
||||
zombie
|
||||
|
||||
\
|
||||
|
||||
zombie - tlsproxy(8) - - smtpd(8)
|
||||
|
||||
\ /
|
||||
|
||||
other --- postscreen(8)
|
||||
|
||||
/ \
|
||||
|
||||
other - - smtpd(8)
|
||||
|
||||
/
|
||||
|
||||
zombie
|
||||
|
||||
* The postlogd(8) server provides an alternative to syslog logging, which
|
||||
remains the default. This feature is available with Postfix version 3.4 or
|
||||
later, and supports the following modes:
|
||||
|
||||
o Logging to file, which addresses a usability problem with MacOS, and
|
||||
eliminates information loss caused by systemd rate limits.
|
||||
|
||||
commands -> postlogd(8) -> /path/to/file
|
||||
or daemons
|
||||
|
||||
o Logging to stdout, which eliminates a syslog dependency when Postfix
|
||||
runs inside a container.
|
||||
|
||||
commands -> postlogd(8) -> stdout inherited
|
||||
or daemons from "postfix start-fg"
|
||||
|
||||
See MAILLOG_README for details and limitations.
|
||||
|
||||
PPoossttffiixx ssuuppppoorrtt ccoommmmaannddss
|
||||
|
||||
The Postfix architecture overview ends with a summary of command-line utilities
|
||||
for day-to-day use of the Postfix mail system. Besides the Sendmail-compatible
|
||||
sendmail(1), mailq(1), and newaliases(1) commands, the Postfix system comes
|
||||
with it own collection of command-line utilities. For consistency, these are
|
||||
all named postsomething.
|
||||
|
||||
* The postfix(1) command controls the operation of the mail system. It is the
|
||||
interface for starting, stopping, and restarting the mail system, as well
|
||||
as for some other administrative operations. This command is reserved to
|
||||
the super-user.
|
||||
|
||||
* The postalias(1) command maintains Postfix aliases(5) type databases. This
|
||||
is the program that does the work for the newaliases(1) command.
|
||||
|
||||
* The postcat(1) command displays the contents of Postfix queue files. This
|
||||
is a limited, preliminary utility. This program is likely to be superseded
|
||||
by something more powerful that can also edit Postfix queue files.
|
||||
|
||||
* The postconf(1) command displays or updates Postfix main.cf parameters and
|
||||
displays system dependent information about the supported file locking
|
||||
methods, and the supported types of lookup tables.
|
||||
|
||||
* The postdrop(1) command is the mail posting utility that is run by the
|
||||
Postfix sendmail(1) command in order to deposit mail into the maildrop
|
||||
queue directory.
|
||||
|
||||
* The postkick(1) command makes some Postfix internal communication channels
|
||||
available for use in, for example, shell scripts.
|
||||
|
||||
* The postlock(1) command provides Postfix-compatible mailbox locking for use
|
||||
in, for example, shell scripts.
|
||||
|
||||
* The postlog(1) command provides Postfix-compatible logging for shell
|
||||
scripts.
|
||||
|
||||
* The postmap(1) command maintains Postfix lookup tables such as canonical
|
||||
(5), virtual(5) and others. It is a cousin of the UNIX makemap command.
|
||||
|
||||
* The postmulti(1) command repeats the "postfix start" etc. command for each
|
||||
Postfix instance, and supports creation, deletion etc. of Postfix
|
||||
instances. For a tutorial, see MULTI_INSTANCE_README.
|
||||
|
||||
* The postqueue(1) command is the privileged command that is run by Postfix
|
||||
sendmail(1) and mailq(1) in order to flush or list the mail queue.
|
||||
|
||||
* The postsuper(1) command maintains the Postfix queue. It removes old
|
||||
temporary files, and moves queue files into the right directory after a
|
||||
change in the hashing depth of queue directories. This command is run at
|
||||
mail system startup time and when Postfix is restarted.
|
||||
|
||||
109
README_FILES/PACKAGE_README
Normal file
109
README_FILES/PACKAGE_README
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
GGuuiiddeelliinneess ffoorr PPaacckkaaggee BBuuiillddeerrss
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document has hints and tips for those who manage their own Postfix binary
|
||||
distribution for internal use, and for those who maintain Postfix binary
|
||||
distributions for general use.
|
||||
|
||||
GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee pprroovviiddee aa ssmmaallll ddeeffaauulltt mmaaiinn..ccff ffiillee
|
||||
|
||||
The installed main.cf file must be small. PLEASE resist the temptation to list
|
||||
all parameters in the main.cf file. Postfix is supposed to be easy to
|
||||
configure. Listing all parameters in main.cf defeats the purpose. It is an
|
||||
invitation for hobbyists to make random changes without understanding what they
|
||||
do, and gets them into endless trouble.
|
||||
|
||||
GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee iinncclluuddee RREEAADDMMEE oorr HHTTMMLL ffiilleess
|
||||
|
||||
Please provide the applicable README or HTML files. They are referenced by the
|
||||
Postfix manual pages and by other files. Without README or HTML files, Postfix
|
||||
will be difficult if not impossible to configure.
|
||||
|
||||
PPoossttffiixx IInnssttaallllaattiioonn ppaarraammeetteerrss
|
||||
|
||||
Postfix installation is controlled by a dozen installation parameters. See the
|
||||
postfix-install and post-install files for details. Most parameters have
|
||||
system-dependent default settings that are configurable at compile time, as
|
||||
described in the INSTALL file.
|
||||
|
||||
PPrreeppaarriinngg aa pprree--bbuuiilltt ppaacckkaaggee ffoorr ddiissttrriibbuuttiioonn ttoo ootthheerr ssyysstteemmss
|
||||
|
||||
You can build a Postfix package on a machine that does not have Postfix
|
||||
installed on it. All you need is Postfix source code and a compilation
|
||||
environment that is compatible with the target system.
|
||||
|
||||
You can build a pre-built Postfix package as an unprivileged user.
|
||||
|
||||
First compile Postfix. After successful compilation, execute:
|
||||
|
||||
% mmaakkee ppaacckkaaggee
|
||||
|
||||
With Postfix versions before 2.2 you must invoke the post-install script
|
||||
directly (% sshh ppoosstt--iinnssttaallll).
|
||||
|
||||
You will be prompted for installation parameters. Specify an install_root
|
||||
directory other than /. The mail_owner and setgid_group installation parameter
|
||||
settings will be recorded in the main.cf file, but they won't take effect until
|
||||
the package is unpacked and installed on the destination machine.
|
||||
|
||||
If you want to fully automate this process, specify all the non-default
|
||||
installation parameters on the command line:
|
||||
|
||||
% mmaakkee nnoonn--iinntteerraaccttiivvee--ppaacckkaaggee iinnssttaallll__rroooott==//ssoommee//wwhheerree...
|
||||
|
||||
With Postfix versions before 2.2 you must invoke the post-install script
|
||||
directly (% sshh ppoosstt--iinnssttaallll --nnoonn--iinntteerraaccttiivvee iinnssttaallll__rroooott......).
|
||||
|
||||
With Postfix 3.0 and later, the command "make package name=value ..." will
|
||||
replace the string MAIL_VERSION in a configuration parameter value with the
|
||||
Postfix release version. Do not try to specify something like $mail_version on
|
||||
this command line. This produces inconsistent results with different versions
|
||||
of the make(1) command.
|
||||
|
||||
BBeeggiinn SSeeccuurriittyy AAlleerrtt
|
||||
|
||||
WWhheenn bbuuiillddiinngg aann aarrcchhiivvee ffoorr ddiissttrriibbuuttiioonn,, bbee ssuurree ttoo aarrcchhiivvee oonnllyy ffiilleess aanndd
|
||||
ssyymmbboolliicc lliinnkkss,, nnoott tthheeiirr ppaarreenntt ddiirreeccttoorriieess.. OOtthheerrwwiissee,, uunnppaacckkiinngg aa pprree--bbuuiilltt
|
||||
PPoossttffiixx ppaacckkaaggee mmaayy mmeessss uupp ppeerrmmiissssiioonn aanndd//oorr oowwnneerrsshhiipp ooff ssyysstteemm ddiirreeccttoorriieess
|
||||
ssuucchh aass // //eettcc //uussrr //uussrr//bbiinn //vvaarr //vvaarr//ssppooooll aanndd ssoo oonn.. TThhiiss iiss eessppeecciiaallllyy aann
|
||||
iissssuuee iiff yyoouu eexxeeccuutteedd ppoossttffiixx--iinnssttaallll ((sseeee aabboovvee)) aass aann uunnpprriivviilleeggeedd uusseerr..
|
||||
|
||||
EEnndd SSeeccuurriittyy AAlleerrtt
|
||||
|
||||
Thus, to tar up the pre-built package, take the following steps:
|
||||
|
||||
% cd INSTALL_ROOT
|
||||
% rm -f SOMEWHERE/outputfile
|
||||
% find . \! -type d -print | xargs tar rf SOMEWHERE/outputfile
|
||||
% gzip SOMEWHERE/outputfile
|
||||
|
||||
This way you will not include any directories that might cause trouble upon
|
||||
extraction.
|
||||
|
||||
IInnssttaalllliinngg aa pprree--bbuuiilltt PPoossttffiixx ppaacckkaaggee
|
||||
|
||||
* To unpack a pre-built Postfix package, execute the equivalent of:
|
||||
|
||||
# umask 022
|
||||
# gzip -d <outputfile.tar.gz | (cd / ; tar xvpf -)
|
||||
|
||||
The umask command is necessary for getting the correct permissions on non-
|
||||
Postfix directories that need to be created in the process.
|
||||
|
||||
* Create the necessary mail_owner account and setgid_group group for
|
||||
exclusive use by Postfix.
|
||||
|
||||
* Execute the postfix command to set ownership and permission of Postfix
|
||||
files and directories, and to update Postfix configuration files. If
|
||||
necessary, specify any non-default settings for mail_owner or setgid_group
|
||||
on the postfix command line:
|
||||
|
||||
# postfix set-permissions upgrade-configuration \
|
||||
setgid_group=xxx mail_owner=yyy
|
||||
|
||||
With Postfix versions before 2.1 you achieve the same result by invoking
|
||||
the post-install script directly.
|
||||
|
||||
78
README_FILES/PCRE_README
Normal file
78
README_FILES/PCRE_README
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
PPoossttffiixx PPCCRREE SSuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPCCRREE ((PPeerrll CCoommppaattiibbllee RReegguullaarr EExxpprreessssiioonnss)) mmaapp ssuuppppoorrtt
|
||||
|
||||
The optional "pcre" map type allows you to specify regular expressions with the
|
||||
PERL style notation such as \s for space and \S for non-space. The main
|
||||
benefit, however, is that pcre lookups are often faster than regexp lookups.
|
||||
This is because the pcre implementation is often more efficient than the POSIX
|
||||
regular expression implementation that you find on many systems.
|
||||
|
||||
A description of how to use pcre tables, including examples, is given in the
|
||||
pcre_table(5) manual page. Information about PCRE itself can be found at https:
|
||||
//www.pcre.org/.
|
||||
|
||||
UUssiinngg PPoossttffiixx ppaacckkaaggeess wwiitthh PPCCRREE ssuuppppoorrtt
|
||||
|
||||
To use pcre with Debian GNU/Linux's Postfix, or with Fedora or RHEL Postfix,
|
||||
all you need is to install the postfix-pcre package and you're done. There is
|
||||
no need to recompile Postfix.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx ffrroomm ssoouurrccee wwiitthh PPCCRREE ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document.
|
||||
|
||||
To build Postfix from source with pcre support, you need a pcre library.
|
||||
Install a vendor package, or download the source code from locations in https:/
|
||||
/www.pcre.org/ and build that yourself.
|
||||
|
||||
Postfix can build with the pcre2 library or the legacy pcre library. It's
|
||||
probably easiest to let the Postfix build procedure pick one. The following
|
||||
commands will first discover if the pcre2 library is installed, and if that is
|
||||
not available, will discover if the legacy pcre library is installed.
|
||||
|
||||
$ make -f Makefile.init makefiles
|
||||
$ make
|
||||
|
||||
To build Postfix explicitly with a pcre2 library (Postfix 3.7 and later):
|
||||
|
||||
$ make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_PCRE=2 `pcre2-config --cflags`" \
|
||||
"AUXLIBS_PCRE=`pcre2-config --libs8`"
|
||||
$ make
|
||||
|
||||
To build Postfix explicitly with a legacy pcre library (all Postfix versions):
|
||||
|
||||
$ make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_PCRE=1 `pcre-config --cflags`" \
|
||||
"AUXLIBS_PCRE=`pcre-config --libs`"
|
||||
$ make
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PCRE. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded PCRE database client, but only the new AUXLIBS_PCRE variable supports
|
||||
building a dynamically-loaded or statically-loaded PCRE database client.
|
||||
|
||||
Failure to use the AUXLIBS_PCRE variable will defeat the purpose of dynamic
|
||||
database client loading. Every Postfix executable file will have PCRE
|
||||
library dependencies. And that was exactly what dynamic database client
|
||||
loading was meant to avoid.
|
||||
|
||||
TThhiinnggss ttoo kknnooww
|
||||
|
||||
* When Postfix searches a pcre: or regexp: lookup table, each pattern is
|
||||
applied to the entire input string. Depending on the application, that
|
||||
string is an entire client hostname, an entire client IP address, or an
|
||||
entire mail address. Thus, no parent domain or parent network search is
|
||||
done, "user@domain" mail addresses are not broken up into their user and
|
||||
domain constituent parts, and "user+foo" is not broken up into user and
|
||||
foo.
|
||||
|
||||
* Regular expression tables such as pcre: or regexp: are not allowed to do
|
||||
$number substitution in lookup results that can be security sensitive:
|
||||
currently, that restriction applies to the local aliases(5) database or the
|
||||
virtual(8) delivery agent tables.
|
||||
|
||||
126
README_FILES/PGSQL_README
Normal file
126
README_FILES/PGSQL_README
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
PPoossttffiixx PPoossttggrreeSSQQLL HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The Postfix pgsql map type allows you to hook up Postfix to a PostgreSQL
|
||||
database. This implementation allows for multiple pgsql databases: you can use
|
||||
one for a virtual(5) table, one for an access(5) table, and one for an aliases
|
||||
(5) table if you want. You can specify multiple servers for the same database,
|
||||
so that Postfix can switch to a good database server if one goes bad.
|
||||
|
||||
Busy mail servers using pgsql maps will generate lots of concurrent pgsql
|
||||
clients, so the pgsql server(s) should be run with this fact in mind. You can
|
||||
reduce the number of concurrent pgsql clients by using the Postfix proxymap(8)
|
||||
service.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh PPoossttggrreeSSQQLL ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
Note: to use pgsql with Debian GNU/Linux's Postfix, all you need to do is to
|
||||
install the postfix-pgsql package and you're done. There is no need to
|
||||
recompile Postfix.
|
||||
|
||||
In order to build Postfix with pgsql map support, you specify -DHAS_PGSQL, the
|
||||
directory with the PostgreSQL header files, and the location of the libpq
|
||||
library file.
|
||||
|
||||
For example:
|
||||
|
||||
% make tidy
|
||||
% make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql" \
|
||||
"AUXLIBS_PGSQL=-L/usr/local/lib -lpq"
|
||||
|
||||
If your PostgreSQL shared library is in a directory that the RUN-TIME linker
|
||||
does not know about, add a "-Wl,-R,/path/to/directory" option after "-lpq".
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PGSQL. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded PostgreSQL database client, but only the new AUXLIBS_PGSQL variable
|
||||
supports building a dynamically-loaded or statically-loaded PostgreSQL database
|
||||
client.
|
||||
|
||||
Failure to use the AUXLIBS_PGSQL variable will defeat the purpose of
|
||||
dynamic database client loading. Every Postfix executable file will have
|
||||
PGSQL database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
Then just run 'make'.
|
||||
|
||||
CCoonnffiigguurriinngg PPoossttggrreeSSQQLL llooookkuupp ttaabblleess
|
||||
|
||||
Once Postfix is built with pgsql support, you can specify a map type in main.cf
|
||||
like this:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf
|
||||
|
||||
The file /etc/postfix/pgsql-aliases.cf specifies lots of information telling
|
||||
postfix how to reference the pgsql database. For a complete description, see
|
||||
the pgsql_table(5) manual page.
|
||||
|
||||
EExxaammppllee:: llooccaall aalliiaasseess
|
||||
|
||||
#
|
||||
# pgsql config file for local(8) aliases(5) lookups
|
||||
#
|
||||
|
||||
#
|
||||
# The hosts that Postfix will try to connect to
|
||||
hosts = host1.some.domain host2.some.domain
|
||||
|
||||
# The user name and password to log into the pgsql server.
|
||||
user = someone
|
||||
password = some_password
|
||||
|
||||
# The database name on the servers.
|
||||
dbname = customer_database
|
||||
|
||||
# Postfix 2.2 and later The SQL query template. See pgsql_table(5).
|
||||
query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
|
||||
|
||||
# For Postfix releases prior to 2.2. See pgsql_table(5) for details.
|
||||
select_field = forw_addr
|
||||
table = mxaliases
|
||||
where_field = alias
|
||||
# Don't forget the leading "AND"!
|
||||
additional_conditions = AND status = 'paid'
|
||||
|
||||
UUssiinngg mmiirrrroorreedd ddaattaabbaasseess
|
||||
|
||||
Sites that have a need for multiple mail exchangers may enjoy the convenience
|
||||
of using a networked mailer database, but do not want to introduce a single
|
||||
point of failure to their system.
|
||||
|
||||
For this reason we've included the ability to have Postfix reference multiple
|
||||
hosts for access to a single pgsql map. This will work if sites set up mirrored
|
||||
pgsql databases on two or more hosts.
|
||||
|
||||
Whenever queries fail with an error at one host, the rest of the hosts will be
|
||||
tried in random order. If no pgsql server hosts are reachable, then mail will
|
||||
be deferred until at least one of those hosts is reachable.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* This code is based upon the Postfix mysql map by Scott Cotton and Joshua
|
||||
Marcus, IC Group, Inc.
|
||||
* The PostgreSQL changes were done by Aaron Sethman.
|
||||
* Updates for Postfix 1.1.x and PostgreSQL 7.1+ and support for calling
|
||||
stored procedures were added by Philip Warner.
|
||||
* LaMont Jones was the initial Postfix pgsql maintainer.
|
||||
* Liviu Daia revised the configuration interface and added the main.cf
|
||||
configuration feature.
|
||||
* Liviu Daia revised the configuration interface and added the main.cf
|
||||
configuration feature.
|
||||
* Liviu Daia with further refinements from Jose Luis Tallon and Victor
|
||||
Duchovni developed the common query, result_format, domain and
|
||||
expansion_limit interface for LDAP, MySQL and PosgreSQL.
|
||||
* Leandro Santi updated the PostgreSQL client after the PostgreSQL developers
|
||||
made major database API changes in response to SQL injection problems, and
|
||||
made PQexec() handling more robust.
|
||||
|
||||
863
README_FILES/POSTSCREEN_3_5_README
Normal file
863
README_FILES/POSTSCREEN_3_5_README
Normal file
|
|
@ -0,0 +1,863 @@
|
|||
PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo ((PPoossttffiixx 22..88 -- 33..55))
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document describes features that are available in Postfix 2.8 - 3.5.
|
||||
|
||||
The Postfix postscreen(8) daemon provides additional protection against mail
|
||||
server overload. One postscreen(8) process handles multiple inbound SMTP
|
||||
connections, and decides which clients may talk to a Postfix SMTP server
|
||||
process. By keeping spambots away, postscreen(8) leaves more SMTP server
|
||||
processes available for legitimate clients, and delays the onset of server
|
||||
overload conditions.
|
||||
|
||||
postscreen(8) should not be used on SMTP ports that receive mail from end-user
|
||||
clients (MUAs). In a typical deployment, postscreen(8) handles the MX service
|
||||
on TCP port 25, while MUA clients submit mail via the submission service on TCP
|
||||
port 587 which requires client authentication. Alternatively, a site could set
|
||||
up a dedicated, non-postscreen, "port 25" server that provides submission
|
||||
service and client authentication, but no MX service.
|
||||
|
||||
postscreen(8) maintains a temporary allowlist for clients that pass its tests;
|
||||
by allowing allowlisted clients to skip tests, postscreen(8) minimizes its
|
||||
impact on legitimate email traffic.
|
||||
|
||||
postscreen(8) is part of a multi-layer defense.
|
||||
|
||||
* As the first layer, postscreen(8) blocks connections from zombies and other
|
||||
spambots that are responsible for about 90% of all spam. It is implemented
|
||||
as a single process to make this defense as inexpensive as possible.
|
||||
|
||||
* The second layer implements more complex SMTP-level access checks with
|
||||
Postfix SMTP servers, policy daemons, and Milter applications.
|
||||
|
||||
* The third layer performs light-weight content inspection with the Postfix
|
||||
built-in header_checks and body_checks. This can block unacceptable
|
||||
attachments such as executable programs, and worms or viruses with easy-to-
|
||||
recognize signatures.
|
||||
|
||||
* The fourth layer provides heavy-weight content inspection with external
|
||||
content filters. Typical examples are Amavisd-new, SpamAssassin, and Milter
|
||||
applications.
|
||||
|
||||
Each layer reduces the spam volume. The general strategy is to use the less
|
||||
expensive defenses first, and to use the more expensive defenses only for the
|
||||
spam that remains.
|
||||
|
||||
Topics in this document:
|
||||
|
||||
* Introduction
|
||||
* The basic idea behind postscreen(8)
|
||||
* General operation
|
||||
* Quick tests before everything else
|
||||
* Tests before the 220 SMTP server greeting
|
||||
* Tests after the 220 SMTP server greeting
|
||||
* Other errors
|
||||
* When all tests succeed
|
||||
* Configuring the postscreen(8) service
|
||||
* Historical notes and credits
|
||||
|
||||
TThhee bbaassiicc iiddeeaa bbeehhiinndd ppoossttssccrreeeenn((88))
|
||||
|
||||
Most email is spam, and most spam is sent out by zombies (malware on
|
||||
compromised end-user computers). Wietse expects that the zombie problem will
|
||||
get worse before things improve, if ever. Without a tool like postscreen(8)
|
||||
that keeps the zombies away, Postfix would be spending most of its resources
|
||||
not receiving email.
|
||||
|
||||
The main challenge for postscreen(8) is to make an is-a-zombie decision based
|
||||
on a single measurement. This is necessary because many zombies try to fly
|
||||
under the radar and avoid spamming the same site repeatedly. Once postscreen(8)
|
||||
decides that a client is not-a-zombie, it allowlists the client temporarily to
|
||||
avoid further delays for legitimate mail.
|
||||
|
||||
Zombies have challenges too: they have only a limited amount of time to deliver
|
||||
spam before their IP address becomes denylisted. To speed up spam deliveries,
|
||||
zombies make compromises in their SMTP protocol implementation. For example,
|
||||
they speak before their turn, or they ignore responses from SMTP servers and
|
||||
continue sending mail even when the server tells them to go away.
|
||||
|
||||
postscreen(8) uses a variety of measurements to recognize zombies. First,
|
||||
postscreen(8) determines if the remote SMTP client IP address is denylisted.
|
||||
Second, postscreen(8) looks for protocol compromises that are made to speed up
|
||||
delivery. These are good indicators for making is-a-zombie decisions based on
|
||||
single measurements.
|
||||
|
||||
postscreen(8) does not inspect message content. Message content can vary from
|
||||
one delivery to the next, especially with clients that (also) send legitimate
|
||||
email. Content is not a good indicator for making is-a-zombie decisions based
|
||||
on single measurements, and that is the problem that postscreen(8) is focused
|
||||
on.
|
||||
|
||||
GGeenneerraall ooppeerraattiioonn
|
||||
|
||||
For each connection from an SMTP client, postscreen(8) performs a number of
|
||||
tests in the order as described below. Some tests introduce a delay of a few
|
||||
seconds. postscreen(8) maintains a temporary allowlist for clients that pass
|
||||
its tests; by allowing allowlisted clients to skip tests, postscreen(8)
|
||||
minimizes its impact on legitimate email traffic.
|
||||
|
||||
By default, postscreen(8) hands off all connections to a Postfix SMTP server
|
||||
process after logging its findings. This mode is useful for non-destructive
|
||||
testing.
|
||||
|
||||
In a typical production setting, postscreen(8) is configured to reject mail
|
||||
from clients that fail one or more tests, after logging the helo, sender and
|
||||
recipient information.
|
||||
|
||||
Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is
|
||||
to keep zombies away from Postfix, with minimal overhead for legitimate
|
||||
clients.
|
||||
|
||||
QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
|
||||
|
||||
Before engaging in SMTP-level tests. postscreen(8) queries a number of local
|
||||
deny and allowlists. These tests speed up the handling of known clients.
|
||||
|
||||
* Permanent allow/denylist test
|
||||
* Temporary allowlist test
|
||||
* MX Policy test
|
||||
|
||||
PPeerrmmaanneenntt aallllooww//ddeennyylliisstt tteesstt
|
||||
|
||||
The postscreen_access_list parameter (default: permit_mynetworks) specifies a
|
||||
permanent access list for SMTP client IP addresses. Typically one would specify
|
||||
something that allowlists local networks, followed by a CIDR table for
|
||||
selective allow- and denylisting.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
# Rules are evaluated in the order as specified.
|
||||
# Denylist 192.168.* except 192.168.0.1.
|
||||
192.168.0.1 permit
|
||||
192.168.0.0/16 reject
|
||||
|
||||
See the postscreen_access_list manpage documentation for more details.
|
||||
|
||||
When the SMTP client address matches a "permit" action, postscreen(8) logs this
|
||||
with the client address and port number as:
|
||||
|
||||
WWHHIITTEELLIISSTTEEDD [address]:port
|
||||
|
||||
The allowlist action is not configurable: immediately hand off the connection
|
||||
to a Postfix SMTP server process.
|
||||
|
||||
When the SMTP client address matches a "reject" action, postscreen(8) logs this
|
||||
with the client address and port number as:
|
||||
|
||||
BBLLAACCKKLLIISSTTEEDD [address]:port
|
||||
|
||||
The postscreen_blacklist_action parameter specifies the action that is taken
|
||||
next. See "When tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
TTeemmppoorraarryy aalllloowwlliisstt tteesstt
|
||||
|
||||
The postscreen(8) daemon maintains a temporary allowlist for SMTP client IP
|
||||
addresses that have passed all the tests described below. The
|
||||
postscreen_cache_map parameter specifies the location of the temporary
|
||||
allowlist. The temporary allowlist is not used for SMTP client addresses that
|
||||
appear on the permanent access list.
|
||||
|
||||
By default the temporary allowlist is not shared with other postscreen(8)
|
||||
daemons. See Sharing the temporary allowlist below for alternatives.
|
||||
|
||||
When the SMTP client address appears on the temporary allowlist, postscreen(8)
|
||||
logs this with the client address and port number as:
|
||||
|
||||
PPAASSSS OOLLDD [address]:port
|
||||
|
||||
The action is not configurable: immediately hand off the connection to a
|
||||
Postfix SMTP server process. The client is excluded from further tests until
|
||||
its temporary allowlist entry expires, as controlled with the postscreen_*_ttl
|
||||
parameters. Expired entries are silently renewed if possible.
|
||||
|
||||
MMXX PPoolliiccyy tteesstt
|
||||
|
||||
When the remote SMTP client is not on the static access list or temporary
|
||||
allowlist, postscreen(8) can implement a number of allowlist tests, before it
|
||||
grants the client a temporary allowlist status that allows it to talk to a
|
||||
Postfix SMTP server process.
|
||||
|
||||
When postscreen(8) is configured to monitor all primary and backup MX
|
||||
addresses, it can refuse to allowlist clients that connect to a backup MX
|
||||
address only (an old spammer trick to take advantage of backup MX hosts with
|
||||
weaker anti-spam policies than primary MX hosts).
|
||||
|
||||
NOTE: The following solution is for small sites. Larger sites would have to
|
||||
share the postscreen(8) cache between primary and backup MTAs, which would
|
||||
introduce a common point of failure.
|
||||
|
||||
* First, configure the host to listen on both primary and backup MX
|
||||
addresses. Use the appropriate ifconfig or ip command for the local
|
||||
operating system, or update the appropriate configuration files and
|
||||
"refresh" the network protocol stack.
|
||||
|
||||
Second, configure Postfix to listen on the new IP address (this step is
|
||||
needed when you have specified inet_interfaces in main.cf).
|
||||
|
||||
* Then, configure postscreen(8) to deny the temporary allowlist status on the
|
||||
backup MX address(es). An example for Wietse's server is:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_whitelist_interfaces = !168.100.189.8 static:all
|
||||
|
||||
Translation: allow clients to obtain the temporary allowlist status on all
|
||||
server IP addresses except 168.100.189.8, which is a backup MX address.
|
||||
|
||||
When a non-allowlisted client connects the backup MX address, postscreen(8)
|
||||
logs this with the client address and port number as:
|
||||
|
||||
CCOONNNNEECCTT ffrroomm [address]:port ttoo [[116688..110000..118899..88]]::2255
|
||||
WWHHIITTEELLIISSTT VVEETTOO [address]:port
|
||||
|
||||
Translation: the client at [address]:port connected to the backup MX address
|
||||
168.100.189.8 while it was not allowlisted. The client will not be granted the
|
||||
temporary allowlist status, even if passes all the allowlist tests described
|
||||
below.
|
||||
|
||||
TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
The postscreen_greet_wait parameter specifies a short time interval before the
|
||||
"220 text..." server greeting, where postscreen(8) can run a number of tests in
|
||||
parallel.
|
||||
|
||||
When a good client passes these tests, and no "deep protocol tests" are
|
||||
configured, postscreen(8) adds the client to the temporary allowlist and hands
|
||||
off the "live" connection to a Postfix SMTP server process. The client can then
|
||||
continue as if postscreen(8) never even existed (except of course for the short
|
||||
postscreen_greet_wait delay).
|
||||
|
||||
* Pregreet test
|
||||
* DNS Allow/denylist test
|
||||
* When tests fail before the 220 SMTP server greeting
|
||||
|
||||
PPrreeggrreeeett tteesstt
|
||||
|
||||
The SMTP protocol is a classic example of a protocol where the server speaks
|
||||
before the client. postscreen(8) detects zombies that are in a hurry and that
|
||||
speak before their turn. This test is enabled by default.
|
||||
|
||||
The postscreen_greet_banner parameter specifies the text portion of a "220-
|
||||
text..." teaser banner (default: $smtpd_banner). Note that this becomes the
|
||||
first part of a multi-line server greeting. The postscreen(8) daemon sends this
|
||||
before the postscreen_greet_wait timer is started. The purpose of the teaser
|
||||
banner is to confuse zombies so that they speak before their turn. It has no
|
||||
effect on SMTP clients that correctly implement the protocol.
|
||||
|
||||
To avoid problems with poorly-implemented SMTP engines in network appliances or
|
||||
network testing tools, either exclude them from all tests with the
|
||||
postscreen_access_list feature or else specify an empty teaser banner:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Exclude broken clients by allowlisting. Clients in mynetworks
|
||||
# should always be allowlisted.
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
192.168.254.0/24 permit
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Disable the teaser banner (try allowlisting first if you can).
|
||||
postscreen_greet_banner =
|
||||
|
||||
When an SMTP client sends a command before the postscreen_greet_wait time has
|
||||
elapsed, postscreen(8) logs this as:
|
||||
|
||||
PPRREEGGRREEEETT count aafftteerr time ffrroomm [address]:port text...
|
||||
|
||||
Translation: the client at [address]:port sent count bytes before its turn to
|
||||
speak. This happened time seconds after the postscreen_greet_wait timer was
|
||||
started. The text is what the client sent (truncated to 100 bytes, and with
|
||||
non-printable characters replaced with C-style escapes such as \r for carriage-
|
||||
return and \n for newline).
|
||||
|
||||
The postscreen_greet_action parameter specifies the action that is taken next.
|
||||
See "When tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
DDNNSS AAllllooww//ddeennyylliisstt tteesstt
|
||||
|
||||
The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS
|
||||
blocklist servers with optional filters and weight factors (positive weights
|
||||
for denylisting, negative for allowlisting). These servers will be queried in
|
||||
parallel with the reverse client IP address. This test is disabled by default.
|
||||
|
||||
CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
|
||||
domain name. Use the postscreen_dnsbl_reply_map feature to hide "password"
|
||||
information in DNSBL domain names.
|
||||
|
||||
When the postscreen_greet_wait time has elapsed, and the combined DNSBL score
|
||||
is equal to or greater than the postscreen_dnsbl_threshold parameter value,
|
||||
postscreen(8) logs this as:
|
||||
|
||||
DDNNSSBBLL rraannkk count ffoorr [address]:port
|
||||
|
||||
Translation: the SMTP client at [address]:port has a combined DNSBL score of
|
||||
count.
|
||||
|
||||
The postscreen_dnsbl_action parameter specifies the action that is taken when
|
||||
the combined DNSBL score is equal to or greater than the threshold. See "When
|
||||
tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
When the client address matches the permanent denylist, or when the client
|
||||
fails the pregreet or DNSBL tests, the action is specified with
|
||||
postscreen_blacklist_action, postscreen_greet_action, or
|
||||
postscreen_dnsbl_action, respectively.
|
||||
|
||||
iiggnnoorree (default)
|
||||
Ignore the failure of this test. Allow other tests to complete. Repeat this
|
||||
test the next time the client connects. This option is useful for testing
|
||||
and collecting statistics without blocking mail.
|
||||
eennffoorrccee
|
||||
Allow other tests to complete. Reject attempts to deliver mail with a 550
|
||||
SMTP reply, and log the helo/sender/recipient information. Repeat this test
|
||||
the next time the client connects.
|
||||
ddrroopp
|
||||
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
|
||||
next time the client connects.
|
||||
|
||||
TTeessttss aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
In this phase of the protocol, postscreen(8) implements a number of "deep
|
||||
protocol" tests. These tests use an SMTP protocol engine that is built into the
|
||||
postscreen(8) server.
|
||||
|
||||
Important note: these protocol tests are disabled by default. They are more
|
||||
intrusive than the pregreet and DNSBL tests, and they have limitations as
|
||||
discussed next.
|
||||
|
||||
* The main limitation of "after 220 greeting" tests is that a new client must
|
||||
disconnect after passing these tests (reason: postscreen is not a proxy).
|
||||
Then the client must reconnect from the same IP address before it can
|
||||
deliver mail. The following measures may help to avoid email delays:
|
||||
|
||||
o Allow "good" clients to skip tests with the
|
||||
postscreen_dnsbl_whitelist_threshold feature (Postfix 2.11 and later).
|
||||
This is especially effective for sites such as Google that never retry
|
||||
immediately from the same IP address.
|
||||
|
||||
o Small sites: Configure postscreen(8) to listen on multiple IP
|
||||
addresses, published in DNS as different IP addresses for the same MX
|
||||
hostname or for different MX hostnames. This avoids mail delivery
|
||||
delays with clients that reconnect immediately from the same IP
|
||||
address.
|
||||
|
||||
o Large sites: Share the postscreen(8) cache between different Postfix
|
||||
MTAs with a large-enough memcache_table(5). Again, this avoids mail
|
||||
delivery delays with clients that reconnect immediately from the same
|
||||
IP address.
|
||||
|
||||
* postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT,
|
||||
and XFORWARD features. If you need to make these services available on port
|
||||
25, then do not enable the tests after the 220 server greeting.
|
||||
|
||||
* End-user clients should connect directly to the submission service, so that
|
||||
they never have to deal with postscreen(8)'s tests.
|
||||
|
||||
The following "after 220 greeting" tests are available:
|
||||
|
||||
* Command pipelining test
|
||||
* Non-SMTP command test
|
||||
* Bare newline test
|
||||
* When tests fail after the 220 SMTP server greeting
|
||||
|
||||
CCoommmmaanndd ppiippeelliinniinngg tteesstt
|
||||
|
||||
By default, SMTP is a half-duplex protocol: the sender and receiver send one
|
||||
command and one response at a time. Unlike the Postfix SMTP server, postscreen
|
||||
(8) does not announce support for ESMTP command pipelining. Therefore, clients
|
||||
are not allowed to send multiple commands. postscreen(8)'s deep protocol test
|
||||
for this is disabled by default.
|
||||
|
||||
With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that
|
||||
send multiple commands, instead of sending one command and waiting for the
|
||||
server to reply.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends multiple commands, postscreen(8) logs this as:
|
||||
|
||||
CCOOMMMMAANNDD PPIIPPEELLIINNIINNGG ffrroomm [address]:port aafftteerr command: text
|
||||
|
||||
Translation: the SMTP client at [address]:port sent multiple SMTP commands,
|
||||
instead of sending one command and then waiting for the server to reply. This
|
||||
happened after the client sent command. The text shows part of the input that
|
||||
was sent too early; it is not logged with Postfix 2.8.
|
||||
|
||||
The postscreen_pipelining_action parameter specifies the action that is taken
|
||||
next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
NNoonn--SSMMTTPP ccoommmmaanndd tteesstt
|
||||
|
||||
Some spambots send their mail through open proxies. A symptom of this is the
|
||||
usage of commands such as CONNECT and other non-SMTP commands. Just like the
|
||||
Postfix SMTP server's smtpd_forbidden_commands feature, postscreen(8) has an
|
||||
equivalent postscreen_forbidden_commands feature to block these clients.
|
||||
postscreen(8)'s deep protocol test for this is disabled by default.
|
||||
|
||||
With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies
|
||||
that send commands specified with the postscreen_forbidden_commands parameter.
|
||||
This also detects commands with the syntax of a message header label. The
|
||||
latter is a symptom that the client is sending message content after ignoring
|
||||
all the responses from postscreen(8) that reject mail.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends non-SMTP commands, postscreen(8) logs this as:
|
||||
|
||||
NNOONN--SSMMTTPP CCOOMMMMAANNDD ffrroomm [address]:port aafftteerr command: text
|
||||
|
||||
Translation: the SMTP client at [address]:port sent a command that matches the
|
||||
postscreen_forbidden_commands parameter, or that has the syntax of a message
|
||||
header label (text followed by optional space and ":"). The "aafftteerr command"
|
||||
portion is logged with Postfix 2.10 and later.
|
||||
|
||||
The postscreen_non_smtp_command_action parameter specifies the action that is
|
||||
taken next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
BBaarree nneewwlliinnee tteesstt
|
||||
|
||||
SMTP is a line-oriented protocol: lines have a limited length, and are
|
||||
terminated with <CR><LF>. Lines ending in a "bare" <LF>, that is newline not
|
||||
preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep
|
||||
protocol test for this is disabled by default.
|
||||
|
||||
With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that
|
||||
send lines ending in bare newline characters.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends bare newline characters, postscreen(8) logs this as:
|
||||
|
||||
BBAARREE NNEEWWLLIINNEE ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port sent a bare newline character,
|
||||
that is newline not preceded by carriage return. The "aafftteerr command" portion is
|
||||
logged with Postfix 2.10 and later.
|
||||
|
||||
The postscreen_bare_newline_action parameter specifies the action that is taken
|
||||
next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
WWhheenn tteessttss ffaaiill aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
When the client fails the pipelining, non-SMTP command or bare newline tests,
|
||||
the action is specified with postscreen_pipelining_action,
|
||||
postscreen_non_smtp_command_action or postscreen_bare_newline_action,
|
||||
respectively.
|
||||
|
||||
iiggnnoorree (default for bare newline)
|
||||
Ignore the failure of this test. Allow other tests to complete. Do NOT
|
||||
repeat this test before the result from some other test expires. This
|
||||
option is useful for testing and collecting statistics without blocking
|
||||
mail permanently.
|
||||
eennffoorrccee (default for pipelining)
|
||||
Allow other tests to complete. Reject attempts to deliver mail with a 550
|
||||
SMTP reply, and log the helo/sender/recipient information. Repeat this test
|
||||
the next time the client connects.
|
||||
ddrroopp (default for non-SMTP commands)
|
||||
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
|
||||
next time the client connects. This action is compatible with the Postfix
|
||||
SMTP server's smtpd_forbidden_commands feature.
|
||||
|
||||
OOtthheerr eerrrroorrss
|
||||
|
||||
When an SMTP client hangs up unexpectedly, postscreen(8) logs this as:
|
||||
|
||||
HHAANNGGUUPP aafftteerr time ffrroomm [address]:port iinn test name
|
||||
|
||||
Translation: the SMTP client at [address]:port disconnected unexpectedly, time
|
||||
seconds after the start of the test named test name.
|
||||
|
||||
There is no punishment for hanging up. A client that hangs up without sending
|
||||
the QUIT command can still pass all postscreen(8) tests.
|
||||
|
||||
The following errors are reported by the built-in SMTP engine. This engine
|
||||
never accepts mail, therefore it has per-session limits on the number of
|
||||
commands and on the session length.
|
||||
|
||||
CCOOMMMMAANNDD TTIIMMEE LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-command time
|
||||
limit as specified with the postscreen_command_time_limit parameter. The
|
||||
session is terminated immediately. The "aafftteerr command" portion is logged with
|
||||
Postfix 2.10 and later.
|
||||
|
||||
CCOOMMMMAANNDD CCOOUUNNTT LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-session command
|
||||
count limit as specified with the postscreen_command_count_limit parameter. The
|
||||
session is terminated immediately. The "aafftteerr command" portion is logged with
|
||||
Postfix 2.10 and later.
|
||||
|
||||
CCOOMMMMAANNDD LLEENNGGTTHH LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-command length
|
||||
limit, as specified with the line_length_limit parameter. The session is
|
||||
terminated immediately. The "aafftteerr command" portion is logged with Postfix 2.10
|
||||
and later.
|
||||
|
||||
When an SMTP client makes too many connections at the same time, postscreen(8)
|
||||
rejects the connection with a 421 status code and logs:
|
||||
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
|
||||
|
||||
The postscreen_client_connection_count_limit parameter controls this limit.
|
||||
|
||||
When an SMTP client connects after postscreen(8) has reached a connection count
|
||||
limit, postscreen(8) rejects the connection with a 421 status code and logs:
|
||||
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll ssccrreeeenniinngg ppoorrttss bbuussyy
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
|
||||
|
||||
The postscreen_pre_queue_limit and postscreen_post_queue_limit parameters
|
||||
control these limits.
|
||||
|
||||
WWhheenn aallll tteessttss ssuucccceeeedd
|
||||
|
||||
When a new SMTP client passes all tests (i.e. it is not allowlisted via some
|
||||
mechanism), postscreen(8) logs this as:
|
||||
|
||||
PPAASSSS NNEEWW [address]:port
|
||||
|
||||
Where [address]:port are the client IP address and port. Then, postscreen(8)
|
||||
creates a temporary allowlist entry that excludes the client IP address from
|
||||
further tests until the temporary allowlist entry expires, as controlled with
|
||||
the postscreen_*_ttl parameters.
|
||||
|
||||
When no "deep protocol tests" are configured, postscreen(8) hands off the
|
||||
"live" connection to a Postfix SMTP server process. The client can then
|
||||
continue as if postscreen(8) never even existed (except for the short
|
||||
postscreen_greet_wait delay).
|
||||
|
||||
When any "deep protocol tests" are configured, postscreen(8) cannot hand off
|
||||
the "live" connection to a Postfix SMTP server process in the middle of the
|
||||
session. Instead, postscreen(8) defers mail delivery attempts with a 4XX
|
||||
status, logs the helo/sender/recipient information, and waits for the client to
|
||||
disconnect. The next time the client connects it will be allowed to talk to a
|
||||
Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the
|
||||
impact of this limitation by giving deep protocol tests a long expiration time.
|
||||
|
||||
CCoonnffiigguurriinngg tthhee ppoossttssccrreeeenn((88)) sseerrvviiccee
|
||||
|
||||
postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9
|
||||
systems.
|
||||
|
||||
* Turning on postscreen(8) without blocking mail
|
||||
* postscreen(8) TLS configuration
|
||||
* Blocking mail with postscreen(8)
|
||||
* Turning off postscreen(8)
|
||||
* Sharing the temporary allowlist
|
||||
|
||||
TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
|
||||
|
||||
To enable the postscreen(8) service and log client information without blocking
|
||||
mail:
|
||||
|
||||
1. Make sure that local clients and systems with non-standard SMTP
|
||||
implementations are excluded from any postscreen(8) tests. The default is
|
||||
to exclude all clients in mynetworks. To exclude additional clients, for
|
||||
example, third-party performance monitoring tools (these tend to have
|
||||
broken SMTP implementations):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Exclude broken clients by allowlisting. Clients in mynetworks
|
||||
# should always be allowlisted.
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
192.168.254.0/24 permit
|
||||
|
||||
2. Comment out the "smtp inet ... smtpd" service in master.cf, including any
|
||||
"-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtp inet n - n - - smtpd
|
||||
# -o parameter=value ...
|
||||
|
||||
3. Uncomment the new "smtpd pass ... smtpd" service in master.cf, and
|
||||
duplicate any "-o parameter=value" entries from the smtpd service that was
|
||||
commented out in the previous step.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtpd pass - - n - - smtpd
|
||||
-o parameter=value ...
|
||||
|
||||
4. Uncomment the new "smtp inet ... postscreen" service in master.cf.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - 1 postscreen
|
||||
|
||||
5. Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This
|
||||
service implements STARTTLS support for postscreen(8).
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
tlsproxy unix - - n - 0 tlsproxy
|
||||
|
||||
6. Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This
|
||||
service does DNSBL lookups for postscreen(8) and logs results.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
dnsblog unix - - n - 0 dnsblog
|
||||
|
||||
7. To enable DNSBL lookups, list some DNS blocklist sites in main.cf,
|
||||
separated by whitespace. Different sites can have different weights. For
|
||||
example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_dnsbl_threshold = 2
|
||||
postscreen_dnsbl_sites = zen.spamhaus.org*2
|
||||
bl.spamcop.net*1 b.barracudacentral.org*1
|
||||
|
||||
Note: if your DNSBL queries have a "secret" in the domain name, you must
|
||||
censor this information from the postscreen(8) SMTP replies. For example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
|
||||
|
||||
/etc/postfix/dnsbl_reply:
|
||||
# Secret DNSBL name Name in postscreen(8) replies
|
||||
secret.zen.dq.spamhaus.net zen.spamhaus.org
|
||||
|
||||
The texthash: format is similar to hash: except that there is no need to
|
||||
run postmap(1) before the file can be used, and that it does not detect
|
||||
changes after the file is read. It is new with Postfix version 2.8.
|
||||
|
||||
8. Read the new configuration with "postfix reload".
|
||||
|
||||
Notes:
|
||||
|
||||
* Some postscreen(8) configuration parameters implement stress-dependent
|
||||
behavior. This is supported only when the default value is stress-dependent
|
||||
(that is, "postconf -d parametername" output shows "parametername = $
|
||||
{stress?something}${stress:something}" or "parametername = ${stress?
|
||||
{something}:{something}}"). Other parameters always evaluate as if the
|
||||
stress value is the empty string.
|
||||
|
||||
* See "Tests before the 220 SMTP server greeting" for details about the
|
||||
logging from these postscreen(8) tests.
|
||||
|
||||
* If you run Postfix 2.6 or earlier you must stop and start the master daemon
|
||||
("postfix stop; postfix start"). This is needed because the Postfix "pass"
|
||||
master service type did not work reliably on all systems.
|
||||
|
||||
ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
|
||||
|
||||
postscreen(8) TLS support is available for remote SMTP clients that aren't
|
||||
allowlisted, including clients that need to renew their temporary allowlist
|
||||
status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
|
||||
hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
|
||||
and decrypts the traffic between postscreen(8) and the remote SMTP client. One
|
||||
tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy
|
||||
(8) processes slowly increases with server load, but it should always be much
|
||||
smaller than the number of postscreen(8) TLS sessions.
|
||||
|
||||
TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with
|
||||
smtpd(8). We recommend that you keep the relevant configuration parameters in
|
||||
main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in
|
||||
master.cf for a postscreen-protected smtpd(8) service, then you should specify
|
||||
those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
|
||||
|
||||
BBlloocckkiinngg mmaaiill wwiitthh ppoossttssccrreeeenn((88))
|
||||
|
||||
For compatibility with smtpd(8), postscreen(8) implements the soft_bounce
|
||||
safety feature. This causes Postfix to reject mail with a "try again" reply
|
||||
code.
|
||||
|
||||
* To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
|
||||
|
||||
* To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note:
|
||||
NO SPACES around '=') to the postscreen entry in master.cf.
|
||||
|
||||
Execute "postfix reload" to make the change effective.
|
||||
|
||||
After testing, do not forget to remove the soft_bounce feature, otherwise
|
||||
senders won't receive their non-delivery notification until many days later.
|
||||
|
||||
To use the postscreen(8) service to block mail, edit main.cf and specify one or
|
||||
more of:
|
||||
|
||||
* "postscreen_dnsbl_action = enforce", to reject clients that are on DNS
|
||||
blocklists, and to log the helo/sender/recipient information. With good
|
||||
DNSBLs this reduces the amount of load on Postfix SMTP servers
|
||||
dramatically.
|
||||
|
||||
* "postscreen_greet_action = enforce", to reject clients that talk before
|
||||
their turn, and to log the helo/sender/recipient information. This stops
|
||||
over half of all known-to-be illegitimate connections to Wietse's mail
|
||||
server. It is backup protection for zombies that haven't yet been
|
||||
denylisted.
|
||||
|
||||
* You can also enable "deep protocol tests", but these are more intrusive
|
||||
than the pregreet or DNSBL tests.
|
||||
|
||||
When a good client passes the "deep protocol tests", postscreen(8) adds the
|
||||
client to the temporary allowlist but it cannot hand off the "live"
|
||||
connection to a Postfix SMTP server process in the middle of the session.
|
||||
Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
|
||||
logs the helo/sender/recipient information, and waits for the client to
|
||||
disconnect.
|
||||
|
||||
When the good client comes back in a later session, it is allowed to talk
|
||||
directly to a Postfix SMTP server. See "Tests after the 220 SMTP server
|
||||
greeting" above for limitations with AUTH and other features that clients
|
||||
may need.
|
||||
|
||||
An unexpected benefit from "deep protocol tests" is that some "good"
|
||||
clients don't return after the 4XX reply; these clients were not so good
|
||||
after all.
|
||||
|
||||
Unfortunately, some senders will retry requests from different IP
|
||||
addresses, and may never get allowlisted. For this reason, Wietse stopped
|
||||
using "deep protocol tests" on his own internet-facing mail server.
|
||||
|
||||
* There is also support for permanent denylisting and allowlisting; see the
|
||||
description of the postscreen_access_list parameter for details.
|
||||
|
||||
TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
|
||||
|
||||
To turn off postscreen(8) and handle mail directly with Postfix SMTP server
|
||||
processes:
|
||||
|
||||
1. Comment out the "smtp inet ... postscreen" service in master.cf, including
|
||||
any "-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtp inet n - n - 1 postscreen
|
||||
# -o parameter=value ...
|
||||
|
||||
2. Comment out the "dnsblog unix ... dnsblog" service in master.cf.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#dnsblog unix - - n - 0 dnsblog
|
||||
|
||||
3. Comment out the "smtpd pass ... smtpd" service in master.cf, including any
|
||||
"-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtpd pass - - n - - smtpd
|
||||
# -o parameter=value ...
|
||||
|
||||
4. Comment out the "tlsproxy unix ... tlsproxy" service in master.cf,
|
||||
including any "-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#tlsproxy unix - - n - 0 tlsproxy
|
||||
# -o parameter=value ...
|
||||
|
||||
5. Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-
|
||||
o parameter=value" entries that may follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd
|
||||
-o parameter=value ...
|
||||
|
||||
6. Read the new configuration with "postfix reload".
|
||||
|
||||
SShhaarriinngg tthhee tteemmppoorraarryy aalllloowwlliisstt
|
||||
|
||||
By default, the temporary allowlist is not shared between multiple postscreen
|
||||
(8) daemons. To enable sharing, choose one of the following options:
|
||||
|
||||
* A non-persistent memcache: temporary allowlist can be shared between
|
||||
postscreen(8) daemons on the same host or different hosts. Disable cache
|
||||
cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8)
|
||||
daemons because memcache: has no first-next API (but see example 4 below
|
||||
for memcache: with persistent backup). This requires Postfix 2.9 or later.
|
||||
|
||||
# Example 1: non-persistent memcache: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
|
||||
postscreen_cache_cleanup_interval = 0
|
||||
|
||||
/etc/postfix/postscreen_cache:
|
||||
memcache = inet:127.0.0.1:11211
|
||||
key_format = postscreen:%s
|
||||
|
||||
* A persistent lmdb: temporary allowlist can be shared between postscreen(8)
|
||||
daemons that run under the same master(8) daemon, or under different master
|
||||
(8) daemons on the same host. Disable cache cleanup
|
||||
(postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons except
|
||||
one that is responsible for cache cleanup. This requires Postfix 2.11 or
|
||||
later.
|
||||
|
||||
# Example 2: persistent lmdb: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = lmdb:$data_directory/postscreen_cache
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
* Other kinds of persistent temporary allowlist can be shared only between
|
||||
postscreen(8) daemons that run under the same master(8) daemon. In this
|
||||
case, temporary allowlist access must be shared through the proxymap(8)
|
||||
daemon. This requires Postfix 2.9 or later.
|
||||
|
||||
# Example 3: proxied btree: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map =
|
||||
proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
# Example 4: proxied btree: allowlist with memcache: accelerator.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
|
||||
proxy_write_maps =
|
||||
proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
... other proxied tables ...
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
/etc/postfix/postscreen_cache:
|
||||
# Note: the $data_directory macro is not defined in this context.
|
||||
memcache = inet:127.0.0.1:11211
|
||||
backup = proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
key_format = postscreen:%s
|
||||
|
||||
Note 1: disable cache cleanup (postscreen_cache_cleanup_interval = 0) in
|
||||
all postscreen(8) daemons except one that is responsible for cache cleanup.
|
||||
|
||||
Note 2: postscreen(8) cache sharing via proxymap(8) requires Postfix 2.9 or
|
||||
later; earlier proxymap(8) implementations don't support cache cleanup.
|
||||
|
||||
HHiissttoorriiccaall nnootteess aanndd ccrreeddiittss
|
||||
|
||||
Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev,
|
||||
in OpenBSD spamd, and in MailChannels Traffic Control.
|
||||
|
||||
Wietse threw together a crude prototype with pregreet and dnsbl support in June
|
||||
2009, because he needed something new for a Mailserver conference presentation
|
||||
in July. Ralf Hildebrandt ran this code on several servers to collect real-
|
||||
world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
|
||||
|
||||
Wietse needed new material for a LISA conference presentation in November 2010,
|
||||
so he added support for DNSBL weights and filters in August, followed by a
|
||||
major code rewrite, deep protocol tests, helo/sender/recipient logging, and
|
||||
stress-adaptive behavior in September. Ralf Hildebrandt ran this code on
|
||||
several servers to collect real-world statistics. This version still used the
|
||||
embarrassing dnsblog(8) ad-hoc DNS client program.
|
||||
|
||||
Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable
|
||||
for sites that require TLS support. The implementation introduces the tlsproxy
|
||||
(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple
|
||||
SMTP clients.
|
||||
|
||||
The tlsproxy(8) implementation led to the discovery of a "new" class of
|
||||
vulnerability (CVE-2011-0411) that affected multiple implementations of SMTP,
|
||||
POP, IMAP, NNTP, and FTP over TLS.
|
||||
|
||||
postscreen(8) was officially released as part of the Postfix 2.8 stable release
|
||||
in January 2011.
|
||||
|
||||
876
README_FILES/POSTSCREEN_README
Normal file
876
README_FILES/POSTSCREEN_README
Normal file
|
|
@ -0,0 +1,876 @@
|
|||
PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
This document describes features that are available in Postfix 3.6 and later.
|
||||
See POSTSCREEN_3_5_README.html for Postfix versions 2.8 - 3.5.
|
||||
|
||||
The Postfix postscreen(8) daemon provides additional protection against mail
|
||||
server overload. One postscreen(8) process handles multiple inbound SMTP
|
||||
connections, and decides which clients may talk to a Postfix SMTP server
|
||||
process. By keeping spambots away, postscreen(8) leaves more SMTP server
|
||||
processes available for legitimate clients, and delays the onset of server
|
||||
overload conditions.
|
||||
|
||||
postscreen(8) should not be used on SMTP ports that receive mail from end-user
|
||||
clients (MUAs). In a typical deployment, postscreen(8) handles the MX service
|
||||
on TCP port 25, while MUA clients submit mail via the submission service on TCP
|
||||
port 587 which requires client authentication. Alternatively, a site could set
|
||||
up a dedicated, non-postscreen, "port 25" server that provides submission
|
||||
service and client authentication, but no MX service.
|
||||
|
||||
postscreen(8) maintains a temporary allowlist for clients that pass its tests;
|
||||
by allowing allowlisted clients to skip tests, postscreen(8) minimizes its
|
||||
impact on legitimate email traffic.
|
||||
|
||||
postscreen(8) is part of a multi-layer defense.
|
||||
|
||||
* As the first layer, postscreen(8) blocks connections from zombies and other
|
||||
spambots that are responsible for about 90% of all spam. It is implemented
|
||||
as a single process to make this defense as inexpensive as possible.
|
||||
|
||||
* The second layer implements more complex SMTP-level access checks with
|
||||
Postfix SMTP servers, policy daemons, and Milter applications.
|
||||
|
||||
* The third layer performs light-weight content inspection with the Postfix
|
||||
built-in header_checks and body_checks. This can block unacceptable
|
||||
attachments such as executable programs, and worms or viruses with easy-to-
|
||||
recognize signatures.
|
||||
|
||||
* The fourth layer provides heavy-weight content inspection with external
|
||||
content filters. Typical examples are Amavisd-new, SpamAssassin, and Milter
|
||||
applications.
|
||||
|
||||
Each layer reduces the spam volume. The general strategy is to use the less
|
||||
expensive defenses first, and to use the more expensive defenses only for the
|
||||
spam that remains.
|
||||
|
||||
Topics in this document:
|
||||
|
||||
* Introduction
|
||||
* The basic idea behind postscreen(8)
|
||||
* General operation
|
||||
* Quick tests before everything else
|
||||
* Tests before the 220 SMTP server greeting
|
||||
* Tests after the 220 SMTP server greeting
|
||||
* Other errors
|
||||
* When all tests succeed
|
||||
* Configuring the postscreen(8) service
|
||||
* Historical notes and credits
|
||||
|
||||
TThhee bbaassiicc iiddeeaa bbeehhiinndd ppoossttssccrreeeenn((88))
|
||||
|
||||
Most email is spam, and most spam is sent out by zombies (malware on
|
||||
compromised end-user computers). Wietse expects that the zombie problem will
|
||||
get worse before things improve, if ever. Without a tool like postscreen(8)
|
||||
that keeps the zombies away, Postfix would be spending most of its resources
|
||||
not receiving email.
|
||||
|
||||
The main challenge for postscreen(8) is to make an is-a-zombie decision based
|
||||
on a single measurement. This is necessary because many zombies try to fly
|
||||
under the radar and avoid spamming the same site repeatedly. Once postscreen(8)
|
||||
decides that a client is not-a-zombie, it allowlists the client temporarily to
|
||||
avoid further delays for legitimate mail.
|
||||
|
||||
Zombies have challenges too: they have only a limited amount of time to deliver
|
||||
spam before their IP address becomes denylisted. To speed up spam deliveries,
|
||||
zombies make compromises in their SMTP protocol implementation. For example,
|
||||
they speak before their turn, or they ignore responses from SMTP servers and
|
||||
continue sending commands even when the server tells them to go away.
|
||||
|
||||
postscreen(8) uses a variety of measurements to recognize zombies. First,
|
||||
postscreen(8) determines if the remote SMTP client IP address is denylisted.
|
||||
Second, postscreen(8) looks for protocol compromises that are made to speed up
|
||||
delivery. These are good indicators for making is-a-zombie decisions based on
|
||||
single measurements.
|
||||
|
||||
postscreen(8) does not inspect message content. Message content can vary from
|
||||
one delivery to the next, especially with clients that (also) send legitimate
|
||||
email. Content is not a good indicator for making is-a-zombie decisions based
|
||||
on single measurements, and that is the problem that postscreen(8) is focused
|
||||
on.
|
||||
|
||||
GGeenneerraall ooppeerraattiioonn
|
||||
|
||||
For each connection from an SMTP client, postscreen(8) performs a number of
|
||||
tests in the order as described below. Some tests introduce a delay of a few
|
||||
seconds. postscreen(8) maintains a temporary allowlist for clients that pass
|
||||
its tests; by allowing allowlisted clients to skip tests, postscreen(8)
|
||||
minimizes its impact on legitimate email traffic.
|
||||
|
||||
By default, postscreen(8) hands off all connections to a Postfix SMTP server
|
||||
process after logging its findings. This mode is useful for non-destructive
|
||||
testing.
|
||||
|
||||
In a typical production setting, postscreen(8) is configured to reject mail
|
||||
from clients that fail one or more tests, after logging the helo, sender and
|
||||
recipient information.
|
||||
|
||||
Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is
|
||||
to keep zombies away from Postfix, with minimal overhead for legitimate
|
||||
clients.
|
||||
|
||||
QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
|
||||
|
||||
Before engaging in SMTP-level tests, postscreen(8) queries a number of local
|
||||
deny and allowlists. These tests speed up the handling of known clients.
|
||||
|
||||
* Permanent allow/denylist test
|
||||
* Temporary allowlist test
|
||||
* MX Policy test
|
||||
|
||||
PPeerrmmaanneenntt aallllooww//ddeennyylliisstt tteesstt
|
||||
|
||||
The postscreen_access_list parameter (default: permit_mynetworks) specifies a
|
||||
permanent access list for SMTP client IP addresses. Typically one would specify
|
||||
something that allowlists local networks, followed by a CIDR table for
|
||||
selective allow- and denylisting.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
# Rules are evaluated in the order as specified.
|
||||
# Denylist 192.168.* except 192.168.0.1.
|
||||
192.168.0.1 permit
|
||||
192.168.0.0/16 reject
|
||||
|
||||
See the postscreen_access_list manpage documentation for more details.
|
||||
|
||||
When the SMTP client address matches a "permit" action, postscreen(8) logs this
|
||||
with the client address and port number as:
|
||||
|
||||
AALLLLOOWWLLIISSTTEEDD [address]:port
|
||||
|
||||
Use the respectful_logging configuration parameter to select a deprecated
|
||||
form of this logging.
|
||||
|
||||
The allowlist action is not configurable: immediately hand off the connection
|
||||
to a Postfix SMTP server process.
|
||||
|
||||
When the SMTP client address matches a "reject" action, postscreen(8) logs this
|
||||
with the client address and port number as:
|
||||
|
||||
DDEENNYYLLIISSTTEEDD [address]:port
|
||||
|
||||
Use the respectful_logging configuration parameter to select a deprecated
|
||||
form of this logging.
|
||||
|
||||
The postscreen_denylist_action parameter specifies the action that is taken
|
||||
next. See "When tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
TTeemmppoorraarryy aalllloowwlliisstt tteesstt
|
||||
|
||||
The postscreen(8) daemon maintains a temporary allowlist for SMTP client IP
|
||||
addresses that have passed all the tests described below. The
|
||||
postscreen_cache_map parameter specifies the location of the temporary
|
||||
allowlist. The temporary allowlist is not used for SMTP client addresses that
|
||||
appear on the permanent access list.
|
||||
|
||||
By default the temporary allowlist is not shared with other postscreen(8)
|
||||
daemons. See Sharing the temporary allowlist below for alternatives.
|
||||
|
||||
When the SMTP client address appears on the temporary allowlist, postscreen(8)
|
||||
logs this with the client address and port number as:
|
||||
|
||||
PPAASSSS OOLLDD [address]:port
|
||||
|
||||
The action is not configurable: immediately hand off the connection to a
|
||||
Postfix SMTP server process. The client is excluded from further tests until
|
||||
its temporary allowlist entry expires, as controlled with the postscreen_*_ttl
|
||||
parameters. Expired entries are silently renewed if possible.
|
||||
|
||||
MMXX PPoolliiccyy tteesstt
|
||||
|
||||
When the remote SMTP client is not on the static access list or temporary
|
||||
allowlist, postscreen(8) can implement a number of allowlist tests, before it
|
||||
grants the client a temporary allowlist status that allows it to talk to a
|
||||
Postfix SMTP server process.
|
||||
|
||||
When postscreen(8) is configured to monitor all primary and backup MX
|
||||
addresses, it can refuse to allowlist clients that connect to a backup MX
|
||||
address only (an old spammer trick to take advantage of backup MX hosts with
|
||||
weaker anti-spam policies than primary MX hosts).
|
||||
|
||||
NOTE: The following solution is for small sites. Larger sites would have to
|
||||
share the postscreen(8) cache between primary and backup MTAs, which would
|
||||
introduce a common point of failure.
|
||||
|
||||
* First, configure the host to listen on both primary and backup MX
|
||||
addresses. Use the appropriate ifconfig or ip command for the local
|
||||
operating system, or update the appropriate configuration files and
|
||||
"refresh" the network protocol stack.
|
||||
|
||||
Second, configure Postfix to listen on the new IP address (this step is
|
||||
needed when you have specified inet_interfaces in main.cf).
|
||||
|
||||
* Then, configure postscreen(8) to deny the temporary allowlist status on the
|
||||
backup MX address(es). An example for Wietse's server is:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_allowlist_interfaces = !168.100.189.8 static:all
|
||||
|
||||
Translation: allow clients to obtain the temporary allowlist status on all
|
||||
server IP addresses except 168.100.189.8, which is a backup MX address.
|
||||
|
||||
When a non-allowlisted client connects the backup MX address, postscreen(8)
|
||||
logs this with the client address and port number as:
|
||||
|
||||
CCOONNNNEECCTT ffrroomm [address]:port ttoo [[116688..110000..118899..88]]::2255
|
||||
AALLLLOOWWLLIISSTT VVEETTOO [address]:port
|
||||
|
||||
Use the respectful_logging configuration parameter to select a deprecated
|
||||
form of this logging.
|
||||
|
||||
Translation: the client at [address]:port connected to the backup MX address
|
||||
168.100.189.8 while it was not allowlisted. The client will not be granted the
|
||||
temporary allowlist status, even if passes all the allowlist tests described
|
||||
below.
|
||||
|
||||
TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
The postscreen_greet_wait parameter specifies a short time interval before the
|
||||
"220 text..." server greeting, where postscreen(8) can run a number of tests in
|
||||
parallel.
|
||||
|
||||
When a good client passes these tests, and no "deep protocol tests" are
|
||||
configured, postscreen(8) adds the client to the temporary allowlist and hands
|
||||
off the "live" connection to a Postfix SMTP server process. The client can then
|
||||
continue as if postscreen(8) never even existed (except of course for the short
|
||||
postscreen_greet_wait delay).
|
||||
|
||||
* Pregreet test
|
||||
* DNS Allow/denylist test
|
||||
* When tests fail before the 220 SMTP server greeting
|
||||
|
||||
PPrreeggrreeeett tteesstt
|
||||
|
||||
The SMTP protocol is a classic example of a protocol where the server speaks
|
||||
before the client. postscreen(8) detects zombies that are in a hurry and that
|
||||
speak before their turn. This test is enabled by default.
|
||||
|
||||
The postscreen_greet_banner parameter specifies the text portion of a "220-
|
||||
text..." teaser banner (default: $smtpd_banner). Note that this becomes the
|
||||
first part of a multi-line server greeting. The postscreen(8) daemon sends this
|
||||
before the postscreen_greet_wait timer is started. The purpose of the teaser
|
||||
banner is to confuse zombies so that they speak before their turn. It has no
|
||||
effect on SMTP clients that correctly implement the protocol.
|
||||
|
||||
To avoid problems with poorly-implemented SMTP engines in network appliances or
|
||||
network testing tools, either exclude them from all tests with the
|
||||
postscreen_access_list feature or else specify an empty teaser banner:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Exclude broken clients by allowlisting. Clients in mynetworks
|
||||
# should always be allowlisted.
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
192.168.254.0/24 permit
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Disable the teaser banner (try allowlisting first if you can).
|
||||
postscreen_greet_banner =
|
||||
|
||||
When an SMTP client sends a command before the postscreen_greet_wait time has
|
||||
elapsed, postscreen(8) logs this as:
|
||||
|
||||
PPRREEGGRREEEETT count aafftteerr time ffrroomm [address]:port text...
|
||||
|
||||
Translation: the client at [address]:port sent count bytes before its turn to
|
||||
speak. This happened time seconds after the postscreen_greet_wait timer was
|
||||
started. The text is what the client sent (truncated to 100 bytes, and with
|
||||
non-printable characters replaced with C-style escapes such as \r for carriage-
|
||||
return and \n for newline).
|
||||
|
||||
The postscreen_greet_action parameter specifies the action that is taken next.
|
||||
See "When tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
DDNNSS AAllllooww//ddeennyylliisstt tteesstt
|
||||
|
||||
The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS
|
||||
blocklist servers with optional filters and weight factors (positive weights
|
||||
for denylisting, negative for allowlisting). These servers will be queried in
|
||||
parallel with the reverse client IP address. This test is disabled by default.
|
||||
|
||||
CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
|
||||
domain name. Use the postscreen_dnsbl_reply_map feature to hide "password"
|
||||
information in DNSBL domain names.
|
||||
|
||||
When the postscreen_greet_wait time has elapsed, and the combined DNSBL score
|
||||
is equal to or greater than the postscreen_dnsbl_threshold parameter value,
|
||||
postscreen(8) logs this as:
|
||||
|
||||
DDNNSSBBLL rraannkk count ffoorr [address]:port
|
||||
|
||||
Translation: the SMTP client at [address]:port has a combined DNSBL score of
|
||||
count.
|
||||
|
||||
The postscreen_dnsbl_action parameter specifies the action that is taken when
|
||||
the combined DNSBL score is equal to or greater than the threshold. See "When
|
||||
tests fail before the 220 SMTP server greeting" below.
|
||||
|
||||
WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
When the client address matches the permanent denylist, or when the client
|
||||
fails the pregreet or DNSBL tests, the action is specified with
|
||||
postscreen_denylist_action, postscreen_greet_action, or
|
||||
postscreen_dnsbl_action, respectively.
|
||||
|
||||
iiggnnoorree (default)
|
||||
Ignore the failure of this test. Allow other tests to complete. Repeat this
|
||||
test the next time the client connects. This option is useful for testing
|
||||
and collecting statistics without blocking mail.
|
||||
eennffoorrccee
|
||||
Allow other tests to complete. Reject attempts to deliver mail with a 550
|
||||
SMTP reply, and log the helo/sender/recipient information. Repeat this test
|
||||
the next time the client connects.
|
||||
ddrroopp
|
||||
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
|
||||
next time the client connects.
|
||||
|
||||
TTeessttss aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
In this phase of the protocol, postscreen(8) implements a number of "deep
|
||||
protocol" tests. These tests use an SMTP protocol engine that is built into the
|
||||
postscreen(8) server.
|
||||
|
||||
Important note: these protocol tests are disabled by default. They are more
|
||||
intrusive than the pregreet and DNSBL tests, and they have limitations as
|
||||
discussed next.
|
||||
|
||||
* The main limitation of "after 220 greeting" tests is that a new client must
|
||||
disconnect after passing these tests (reason: postscreen is not a proxy).
|
||||
Then the client must reconnect from the same IP address before it can
|
||||
deliver mail. The following measures may help to avoid email delays:
|
||||
|
||||
o Allow "good" clients to skip tests with the
|
||||
postscreen_dnsbl_allowlist_threshold feature. This is especially
|
||||
effective for large providers that usually don't retry from the same IP
|
||||
address.
|
||||
|
||||
o Small sites: Configure postscreen(8) to listen on multiple IP
|
||||
addresses, published in DNS as different IP addresses for the same MX
|
||||
hostname or for different MX hostnames. This avoids mail delivery
|
||||
delays with clients that reconnect immediately from the same IP
|
||||
address.
|
||||
|
||||
o Large sites: Share the postscreen(8) cache between different Postfix
|
||||
MTAs with a large-enough memcache_table(5). Again, this avoids mail
|
||||
delivery delays with clients that reconnect immediately from the same
|
||||
IP address.
|
||||
|
||||
* postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT,
|
||||
and XFORWARD features. If you need to make these services available on port
|
||||
25, then do not enable the tests after the 220 server greeting.
|
||||
|
||||
* End-user clients should connect directly to the submission service, so that
|
||||
they never have to deal with postscreen(8)'s tests.
|
||||
|
||||
The following "after 220 greeting" tests are available:
|
||||
|
||||
* Command pipelining test
|
||||
* Non-SMTP command test
|
||||
* Bare newline test
|
||||
* When tests fail after the 220 SMTP server greeting
|
||||
|
||||
CCoommmmaanndd ppiippeelliinniinngg tteesstt
|
||||
|
||||
By default, SMTP is a half-duplex protocol: the sender and receiver send one
|
||||
command and one response at a time. Unlike the Postfix SMTP server, postscreen
|
||||
(8) does not announce support for ESMTP command pipelining. Therefore, clients
|
||||
are not allowed to send multiple commands. postscreen(8)'s deep protocol test
|
||||
for this is disabled by default.
|
||||
|
||||
With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that
|
||||
send multiple commands, instead of sending one command and waiting for the
|
||||
server to reply.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends multiple commands, postscreen(8) logs this as:
|
||||
|
||||
CCOOMMMMAANNDD PPIIPPEELLIINNIINNGG ffrroomm [address]:port aafftteerr command: text
|
||||
|
||||
Translation: the SMTP client at [address]:port sent multiple SMTP commands,
|
||||
instead of sending one command and then waiting for the server to reply. This
|
||||
happened after the client sent command. The text shows part of the input that
|
||||
was sent too early; it is not logged with Postfix 2.8.
|
||||
|
||||
The postscreen_pipelining_action parameter specifies the action that is taken
|
||||
next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
NNoonn--SSMMTTPP ccoommmmaanndd tteesstt
|
||||
|
||||
Some spambots send their mail through open proxies. A symptom of this is the
|
||||
usage of commands such as CONNECT and other non-SMTP commands. Just like the
|
||||
Postfix SMTP server's smtpd_forbidden_commands feature, postscreen(8) has an
|
||||
equivalent postscreen_forbidden_commands feature to block these clients.
|
||||
postscreen(8)'s deep protocol test for this is disabled by default.
|
||||
|
||||
With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies
|
||||
that send commands specified with the postscreen_forbidden_commands parameter.
|
||||
This also detects commands with the syntax of a message header label. The
|
||||
latter is a symptom that the client is sending message content after ignoring
|
||||
all the responses from postscreen(8) that reject mail.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends non-SMTP commands, postscreen(8) logs this as:
|
||||
|
||||
NNOONN--SSMMTTPP CCOOMMMMAANNDD ffrroomm [address]:port aafftteerr command: text
|
||||
|
||||
Translation: the SMTP client at [address]:port sent a command that matches the
|
||||
postscreen_forbidden_commands parameter, or that has the syntax of a message
|
||||
header label (text followed by optional space and ":"). The "aafftteerr command"
|
||||
portion is logged with Postfix 2.10 and later.
|
||||
|
||||
The postscreen_non_smtp_command_action parameter specifies the action that is
|
||||
taken next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
BBaarree nneewwlliinnee tteesstt
|
||||
|
||||
SMTP is a line-oriented protocol: lines have a limited length, and are
|
||||
terminated with <CR><LF>. Lines ending in a "bare" <LF>, that is newline not
|
||||
preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep
|
||||
protocol test for this is disabled by default.
|
||||
|
||||
With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that
|
||||
send lines ending in bare newline characters.
|
||||
|
||||
This test is opportunistically enabled when postscreen(8) has to use the built-
|
||||
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
|
||||
|
||||
When a client sends bare newline characters, postscreen(8) logs this as:
|
||||
|
||||
BBAARREE NNEEWWLLIINNEE ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port sent a bare newline character,
|
||||
that is newline not preceded by carriage return. The "aafftteerr command" portion is
|
||||
logged with Postfix 2.10 and later.
|
||||
|
||||
The postscreen_bare_newline_action parameter specifies the action that is taken
|
||||
next. See "When tests fail after the 220 SMTP server greeting" below.
|
||||
|
||||
WWhheenn tteessttss ffaaiill aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
|
||||
|
||||
When the client fails the pipelining, non-SMTP command or bare newline tests,
|
||||
the action is specified with postscreen_pipelining_action,
|
||||
postscreen_non_smtp_command_action or postscreen_bare_newline_action,
|
||||
respectively.
|
||||
|
||||
iiggnnoorree (default for bare newline)
|
||||
Ignore the failure of this test. Allow other tests to complete. Do NOT
|
||||
repeat this test before the result from some other test expires. This
|
||||
option is useful for testing and collecting statistics without blocking
|
||||
mail permanently.
|
||||
eennffoorrccee (default for pipelining)
|
||||
Allow other tests to complete. Reject attempts to deliver mail with a 550
|
||||
SMTP reply, and log the helo/sender/recipient information. Repeat this test
|
||||
the next time the client connects.
|
||||
ddrroopp (default for non-SMTP commands)
|
||||
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
|
||||
next time the client connects. This action is compatible with the Postfix
|
||||
SMTP server's smtpd_forbidden_commands feature.
|
||||
|
||||
OOtthheerr eerrrroorrss
|
||||
|
||||
When an SMTP client hangs up unexpectedly, postscreen(8) logs this as:
|
||||
|
||||
HHAANNGGUUPP aafftteerr time ffrroomm [address]:port iinn test name
|
||||
|
||||
Translation: the SMTP client at [address]:port disconnected unexpectedly, time
|
||||
seconds after the start of the test named test name.
|
||||
|
||||
There is no punishment for hanging up. A client that hangs up without sending
|
||||
the QUIT command can still pass all postscreen(8) tests.
|
||||
|
||||
The following errors are reported by the built-in SMTP engine. This engine
|
||||
never accepts mail, therefore it has per-session limits on the number of
|
||||
commands and on the session length.
|
||||
|
||||
CCOOMMMMAANNDD TTIIMMEE LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-command time
|
||||
limit as specified with the postscreen_command_time_limit parameter. The
|
||||
session is terminated immediately. The "aafftteerr command" portion is logged with
|
||||
Postfix 2.10 and later.
|
||||
|
||||
CCOOMMMMAANNDD CCOOUUNNTT LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-session command
|
||||
count limit as specified with the postscreen_command_count_limit parameter. The
|
||||
session is terminated immediately. The "aafftteerr command" portion is logged with
|
||||
Postfix 2.10 and later.
|
||||
|
||||
CCOOMMMMAANNDD LLEENNGGTTHH LLIIMMIITT ffrroomm [address]:port aafftteerr command
|
||||
|
||||
Translation: the SMTP client at [address]:port reached the per-command length
|
||||
limit, as specified with the line_length_limit parameter. The session is
|
||||
terminated immediately. The "aafftteerr command" portion is logged with Postfix 2.10
|
||||
and later.
|
||||
|
||||
When an SMTP client makes too many connections at the same time, postscreen(8)
|
||||
rejects the connection with a 421 status code and logs:
|
||||
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
|
||||
|
||||
The postscreen_client_connection_count_limit parameter controls this limit.
|
||||
|
||||
When an SMTP client connects after postscreen(8) has reached a connection count
|
||||
limit, postscreen(8) rejects the connection with a 421 status code and logs:
|
||||
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll ssccrreeeenniinngg ppoorrttss bbuussyy
|
||||
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
|
||||
|
||||
The postscreen_pre_queue_limit and postscreen_post_queue_limit parameters
|
||||
control these limits.
|
||||
|
||||
WWhheenn aallll tteessttss ssuucccceeeedd
|
||||
|
||||
When a new SMTP client passes all tests (i.e. it is not allowlisted via some
|
||||
mechanism), postscreen(8) logs this as:
|
||||
|
||||
PPAASSSS NNEEWW [address]:port
|
||||
|
||||
Where [address]:port are the client IP address and port. Then, postscreen(8)
|
||||
creates a temporary allowlist entry that excludes the client IP address from
|
||||
further tests until the temporary allowlist entry expires, as controlled with
|
||||
the postscreen_*_ttl parameters.
|
||||
|
||||
When no "deep protocol tests" are configured, postscreen(8) hands off the
|
||||
"live" connection to a Postfix SMTP server process. The client can then
|
||||
continue as if postscreen(8) never even existed (except for the short
|
||||
postscreen_greet_wait delay).
|
||||
|
||||
When any "deep protocol tests" are configured, postscreen(8) cannot hand off
|
||||
the "live" connection to a Postfix SMTP server process in the middle of the
|
||||
session. Instead, postscreen(8) defers mail delivery attempts with a 4XX
|
||||
status, logs the helo/sender/recipient information, and waits for the client to
|
||||
disconnect. The next time the client connects it will be allowed to talk to a
|
||||
Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the
|
||||
impact of this limitation by giving deep protocol tests a long expiration time.
|
||||
|
||||
CCoonnffiigguurriinngg tthhee ppoossttssccrreeeenn((88)) sseerrvviiccee
|
||||
|
||||
postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9
|
||||
systems.
|
||||
|
||||
* Turning on postscreen(8) without blocking mail
|
||||
* postscreen(8) TLS configuration
|
||||
* Blocking mail with postscreen(8)
|
||||
* Turning off postscreen(8)
|
||||
* Sharing the temporary allowlist
|
||||
|
||||
TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
|
||||
|
||||
To enable the postscreen(8) service and log client information without blocking
|
||||
mail:
|
||||
|
||||
1. Make sure that local clients and systems with non-standard SMTP
|
||||
implementations are excluded from any postscreen(8) tests. The default is
|
||||
to exclude all clients in mynetworks. To exclude additional clients, for
|
||||
example, third-party performance monitoring tools (these tend to have
|
||||
broken SMTP implementations):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Exclude broken clients by allowlisting. Clients in mynetworks
|
||||
# should always be allowlisted.
|
||||
postscreen_access_list = permit_mynetworks,
|
||||
cidr:/etc/postfix/postscreen_access.cidr
|
||||
|
||||
/etc/postfix/postscreen_access.cidr:
|
||||
192.168.254.0/24 permit
|
||||
|
||||
2. Comment out the "smtp inet ... smtpd" service in master.cf, including any
|
||||
"-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtp inet n - n - - smtpd
|
||||
# -o parameter=value ...
|
||||
|
||||
3. Uncomment the new "smtpd pass ... smtpd" service in master.cf, and
|
||||
duplicate any "-o parameter=value" entries from the smtpd service that was
|
||||
commented out in the previous step.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtpd pass - - n - - smtpd
|
||||
-o parameter=value ...
|
||||
|
||||
4. Uncomment the new "smtp inet ... postscreen" service in master.cf.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - 1 postscreen
|
||||
|
||||
5. Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This
|
||||
service implements STARTTLS support for postscreen(8).
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
tlsproxy unix - - n - 0 tlsproxy
|
||||
|
||||
6. Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This
|
||||
service does DNSBL lookups for postscreen(8) and logs results.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
dnsblog unix - - n - 0 dnsblog
|
||||
|
||||
7. To enable DNSBL lookups, list some DNS blocklist sites in main.cf,
|
||||
separated by whitespace. Different sites can have different weights. For
|
||||
example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_dnsbl_threshold = 2
|
||||
postscreen_dnsbl_sites = zen.spamhaus.org*2
|
||||
bl.spamcop.net*1 b.barracudacentral.org*1
|
||||
|
||||
Note: if your DNSBL queries have a "secret" in the domain name, you must
|
||||
censor this information from the postscreen(8) SMTP replies. For example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
|
||||
|
||||
/etc/postfix/dnsbl_reply:
|
||||
# Secret DNSBL name Name in postscreen(8) replies
|
||||
secret.zen.dq.spamhaus.net zen.spamhaus.org
|
||||
|
||||
The texthash: format is similar to hash: except that there is no need to
|
||||
run postmap(1) before the file can be used, and that it does not detect
|
||||
changes after the file is read. It is new with Postfix version 2.8.
|
||||
|
||||
8. Read the new configuration with "postfix reload".
|
||||
|
||||
Notes:
|
||||
|
||||
* Some postscreen(8) configuration parameters implement stress-dependent
|
||||
behavior. This is supported only when the default value is stress-dependent
|
||||
(that is, "postconf -d parametername" output shows "parametername = $
|
||||
{stress?something}${stress:something}" or "parametername = ${stress?
|
||||
{something}:{something}}"). Other parameters always evaluate as if the
|
||||
stress value is the empty string.
|
||||
|
||||
* See "Tests before the 220 SMTP server greeting" for details about the
|
||||
logging from these postscreen(8) tests.
|
||||
|
||||
* If you run Postfix 2.6 or earlier you must stop and start the master daemon
|
||||
("postfix stop; postfix start"). This is needed because the Postfix "pass"
|
||||
master service type did not work reliably on all systems.
|
||||
|
||||
ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
|
||||
|
||||
postscreen(8) TLS support is available for remote SMTP clients that aren't
|
||||
allowlisted, including clients that need to renew their temporary allowlist
|
||||
status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
|
||||
hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
|
||||
and decrypts the traffic between postscreen(8) and the remote SMTP client. One
|
||||
tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy
|
||||
(8) processes slowly increases with server load, but it should always be much
|
||||
smaller than the number of postscreen(8) TLS sessions.
|
||||
|
||||
TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with
|
||||
smtpd(8). We recommend that you keep the relevant configuration parameters in
|
||||
main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in
|
||||
master.cf for a postscreen-protected smtpd(8) service, then you should specify
|
||||
those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
|
||||
|
||||
BBlloocckkiinngg mmaaiill wwiitthh ppoossttssccrreeeenn((88))
|
||||
|
||||
For compatibility with smtpd(8), postscreen(8) implements the soft_bounce
|
||||
safety feature. This causes Postfix to reject mail with a "try again" reply
|
||||
code.
|
||||
|
||||
* To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
|
||||
|
||||
* To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note:
|
||||
NO SPACES around '=') to the postscreen entry in master.cf.
|
||||
|
||||
Execute "postfix reload" to make the change effective.
|
||||
|
||||
After testing, do not forget to remove the soft_bounce feature, otherwise
|
||||
senders won't receive their non-delivery notification until many days later.
|
||||
|
||||
To use the postscreen(8) service to block mail, edit main.cf and specify one or
|
||||
more of:
|
||||
|
||||
* "postscreen_dnsbl_action = enforce", to reject clients that are on DNS
|
||||
blocklists, and to log the helo/sender/recipient information. With good
|
||||
DNSBLs this reduces the amount of load on Postfix SMTP servers
|
||||
dramatically.
|
||||
|
||||
* "postscreen_greet_action = enforce", to reject clients that talk before
|
||||
their turn, and to log the helo/sender/recipient information. This stops
|
||||
over half of all known-to-be illegitimate connections to Wietse's mail
|
||||
server. It is backup protection for zombies that haven't yet been
|
||||
denylisted.
|
||||
|
||||
* You can also enable "deep protocol tests", but these are more intrusive
|
||||
than the pregreet or DNSBL tests.
|
||||
|
||||
When a good client passes the "deep protocol tests", postscreen(8) adds the
|
||||
client to the temporary allowlist but it cannot hand off the "live"
|
||||
connection to a Postfix SMTP server process in the middle of the session.
|
||||
Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
|
||||
logs the helo/sender/recipient information, and waits for the client to
|
||||
disconnect.
|
||||
|
||||
When the good client comes back in a later session, it is allowed to talk
|
||||
directly to a Postfix SMTP server. See "Tests after the 220 SMTP server
|
||||
greeting" above for limitations with AUTH and other features that clients
|
||||
may need.
|
||||
|
||||
An unexpected benefit from "deep protocol tests" is that some "good"
|
||||
clients don't return after the 4XX reply; these clients were not so good
|
||||
after all.
|
||||
|
||||
Unfortunately, some senders will retry requests from different IP
|
||||
addresses, and may never get allowlisted. For this reason, Wietse stopped
|
||||
using "deep protocol tests" on his own internet-facing mail server.
|
||||
|
||||
* There is also support for permanent denylisting and allowlisting; see the
|
||||
description of the postscreen_access_list parameter for details.
|
||||
|
||||
TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
|
||||
|
||||
To turn off postscreen(8) and handle mail directly with Postfix SMTP server
|
||||
processes:
|
||||
|
||||
1. Comment out the "smtp inet ... postscreen" service in master.cf, including
|
||||
any "-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtp inet n - n - 1 postscreen
|
||||
# -o parameter=value ...
|
||||
|
||||
2. Comment out the "dnsblog unix ... dnsblog" service in master.cf.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#dnsblog unix - - n - 0 dnsblog
|
||||
|
||||
3. Comment out the "smtpd pass ... smtpd" service in master.cf, including any
|
||||
"-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#smtpd pass - - n - - smtpd
|
||||
# -o parameter=value ...
|
||||
|
||||
4. Comment out the "tlsproxy unix ... tlsproxy" service in master.cf,
|
||||
including any "-o parameter=value" entries that follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
#tlsproxy unix - - n - 0 tlsproxy
|
||||
# -o parameter=value ...
|
||||
|
||||
5. Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-
|
||||
o parameter=value" entries that may follow.
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
smtp inet n - n - - smtpd
|
||||
-o parameter=value ...
|
||||
|
||||
6. Read the new configuration with "postfix reload".
|
||||
|
||||
SShhaarriinngg tthhee tteemmppoorraarryy aalllloowwlliisstt
|
||||
|
||||
By default, the temporary allowlist is not shared between multiple postscreen
|
||||
(8) daemons. To enable sharing, choose one of the following options:
|
||||
|
||||
* A non-persistent memcache: temporary allowlist can be shared between
|
||||
postscreen(8) daemons on the same host or different hosts. Disable cache
|
||||
cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8)
|
||||
daemons because memcache: has no first-next API (but see example 4 below
|
||||
for memcache: with persistent backup). This requires Postfix 2.9 or later.
|
||||
|
||||
# Example 1: non-persistent memcache: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
|
||||
postscreen_cache_cleanup_interval = 0
|
||||
|
||||
/etc/postfix/postscreen_cache:
|
||||
memcache = inet:127.0.0.1:11211
|
||||
key_format = postscreen:%s
|
||||
|
||||
* A persistent lmdb: temporary allowlist can be shared between postscreen(8)
|
||||
daemons that run under the same master(8) daemon, or under different master
|
||||
(8) daemons on the same host. Disable cache cleanup
|
||||
(postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons except
|
||||
one that is responsible for cache cleanup. This requires Postfix 2.11 or
|
||||
later.
|
||||
|
||||
# Example 2: persistent lmdb: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = lmdb:$data_directory/postscreen_cache
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
* Other kinds of persistent temporary allowlist can be shared only between
|
||||
postscreen(8) daemons that run under the same master(8) daemon. In this
|
||||
case, temporary allowlist access must be shared through the proxymap(8)
|
||||
daemon. This requires Postfix 2.9 or later.
|
||||
|
||||
# Example 3: proxied btree: allowlist.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map =
|
||||
proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
# Example 4: proxied btree: allowlist with memcache: accelerator.
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
|
||||
proxy_write_maps =
|
||||
proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
... other proxied tables ...
|
||||
# See note 1 below.
|
||||
# postscreen_cache_cleanup_interval = 0
|
||||
|
||||
/etc/postfix/postscreen_cache:
|
||||
# Note: the $data_directory macro is not defined in this context.
|
||||
memcache = inet:127.0.0.1:11211
|
||||
backup = proxy:btree:/var/lib/postfix/postscreen_cache
|
||||
key_format = postscreen:%s
|
||||
|
||||
Note 1: disable cache cleanup (postscreen_cache_cleanup_interval = 0) in
|
||||
all postscreen(8) daemons except one that is responsible for cache cleanup.
|
||||
|
||||
Note 2: postscreen(8) cache sharing via proxymap(8) requires Postfix 2.9 or
|
||||
later; earlier proxymap(8) implementations don't support cache cleanup.
|
||||
|
||||
HHiissttoorriiccaall nnootteess aanndd ccrreeddiittss
|
||||
|
||||
Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev,
|
||||
in OpenBSD spamd, and in MailChannels Traffic Control.
|
||||
|
||||
Wietse threw together a crude prototype with pregreet and dnsbl support in June
|
||||
2009, because he needed something new for a Mailserver conference presentation
|
||||
in July. Ralf Hildebrandt ran this code on several servers to collect real-
|
||||
world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
|
||||
|
||||
Wietse needed new material for a LISA conference presentation in November 2010,
|
||||
so he added support for DNSBL weights and filters in August, followed by a
|
||||
major code rewrite, deep protocol tests, helo/sender/recipient logging, and
|
||||
stress-adaptive behavior in September. Ralf Hildebrandt ran this code on
|
||||
several servers to collect real-world statistics. This version still used the
|
||||
embarrassing dnsblog(8) ad-hoc DNS client program.
|
||||
|
||||
Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable
|
||||
for sites that require TLS support. The implementation introduces the tlsproxy
|
||||
(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple
|
||||
SMTP clients.
|
||||
|
||||
The tlsproxy(8) implementation led to the discovery of a "new" class of
|
||||
vulnerability (CVE-2011-0411) that affected multiple implementations of SMTP,
|
||||
POP, IMAP, NNTP, and FTP over TLS.
|
||||
|
||||
postscreen(8) was officially released as part of the Postfix 2.8 stable release
|
||||
in January 2011.
|
||||
|
||||
Noel Jones helped with the Postfix 3.6 transition towards respectful
|
||||
documentation.
|
||||
|
||||
5
README_FILES/QMQP_README
Normal file
5
README_FILES/QMQP_README
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
PPoossttffiixx qqmmaaiill aanndd eezzmmllmm ssuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
This document will be made available via http://www.postfix.org/.
|
||||
|
||||
740
README_FILES/QSHAPE_README
Normal file
740
README_FILES/QSHAPE_README
Normal file
|
|
@ -0,0 +1,740 @@
|
|||
PPoossttffiixx BBoottttlleenneecckk AAnnaallyyssiiss
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document is an introduction to Postfix queue congestion analysis. It
|
||||
explains how the qshape(1) program can help to track down the reason for queue
|
||||
congestion. qshape(1) is bundled with Postfix 2.1 and later source code, under
|
||||
the "auxiliary" directory. This document describes qshape(1) as bundled with
|
||||
Postfix 2.4.
|
||||
|
||||
This document covers the following topics:
|
||||
|
||||
* Introducing the qshape tool
|
||||
* Trouble shooting with qshape
|
||||
* Example 1: Healthy queue
|
||||
* Example 2: Deferred queue full of dictionary attack bounces
|
||||
* Example 3: Congestion in the active queue
|
||||
* Example 4: High volume destination backlog
|
||||
* Postfix queue directories
|
||||
|
||||
o The "maildrop" queue
|
||||
o The "hold" queue
|
||||
o The "incoming" queue
|
||||
o The "active" queue
|
||||
o The "deferred" queue
|
||||
|
||||
* Credits
|
||||
|
||||
IInnttrroodduucciinngg tthhee qqsshhaappee ttooooll
|
||||
|
||||
When mail is draining slowly or the queue is unexpectedly large, run qshape(1)
|
||||
as the super-user (root) to help zero in on the problem. The qshape(1) program
|
||||
displays a tabular view of the Postfix queue contents.
|
||||
|
||||
* On the horizontal axis, it displays the queue age with fine granularity for
|
||||
recent messages and (geometrically) less fine granularity for older
|
||||
messages.
|
||||
|
||||
* The vertical axis displays the destination (or with the "-s" switch the
|
||||
sender) domain. Domains with the most messages are listed first.
|
||||
|
||||
For example, in the output below we see the top 10 lines of the (mostly forged)
|
||||
sender domain distribution for captured spam in the "hold" queue:
|
||||
|
||||
$ qshape -s hold | head
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 486 0 0 1 0 0 2 4 20 40 419
|
||||
yahoo.com 14 0 0 1 0 0 0 0 1 0 12
|
||||
extremepricecuts.net 13 0 0 0 0 0 0 0 2 0 11
|
||||
ms35.hinet.net 12 0 0 0 0 0 0 0 0 1 11
|
||||
winnersdaily.net 12 0 0 0 0 0 0 0 2 0 10
|
||||
hotmail.com 11 0 0 0 0 0 0 0 0 1 10
|
||||
worldnet.fr 6 0 0 0 0 0 0 0 0 0 6
|
||||
ms41.hinet.net 6 0 0 0 0 0 0 0 0 0 6
|
||||
osn.de 5 0 0 0 0 0 1 0 0 0 4
|
||||
|
||||
* The "T" column shows the total (in this case sender) count for each domain.
|
||||
The columns with numbers above them, show counts for messages aged fewer
|
||||
than that many minutes, but not younger than the age limit for the previous
|
||||
column. The row labeled "TOTAL" shows the total count for all domains.
|
||||
|
||||
* In this example, there are 14 messages allegedly from yahoo.com, 1 between
|
||||
10 and 20 minutes old, 1 between 320 and 640 minutes old and 12 older than
|
||||
1280 minutes (1440 minutes in a day).
|
||||
|
||||
When the output is a terminal intermediate results showing the top 20 domains
|
||||
(-n option) are displayed after every 1000 messages (-N option) and the final
|
||||
output also shows only the top 20 domains. This makes qshape useful even when
|
||||
the "deferred" queue is very large and it may otherwise take prohibitively long
|
||||
to read the entire "deferred" queue.
|
||||
|
||||
By default, qshape shows statistics for the union of both the "incoming" and
|
||||
"active" queues which are the most relevant queues to look at when analyzing
|
||||
performance.
|
||||
|
||||
One can request an alternate list of queues:
|
||||
|
||||
$ qshape deferred
|
||||
$ qshape incoming active deferred
|
||||
|
||||
this will show the age distribution of the "deferred" queue or the union of the
|
||||
"incoming", "active" and "deferred" queues.
|
||||
|
||||
Command line options control the number of display "buckets", the age limit for
|
||||
the smallest bucket, display of parent domain counts and so on. The "-h" option
|
||||
outputs a summary of the available switches.
|
||||
|
||||
TTrroouubbllee sshhoooottiinngg wwiitthh qqsshhaappee
|
||||
|
||||
Large numbers in the qshape output represent a large number of messages that
|
||||
are destined to (or alleged to come from) a particular domain. It should be
|
||||
possible to tell at a glance which domains dominate the queue sender or
|
||||
recipient counts, approximately when a burst of mail started, and when it
|
||||
stopped.
|
||||
|
||||
The problem destinations or sender domains appear near the top left corner of
|
||||
the output table. Remember that the "active" queue can accommodate up to 20000
|
||||
($qmgr_message_active_limit) messages. To check whether this limit has been
|
||||
reached, use:
|
||||
|
||||
$ qshape -s active (show sender statistics)
|
||||
|
||||
If the total sender count is below 20000 the "active" queue is not yet
|
||||
saturated, any high volume sender domains show near the top of the output.
|
||||
|
||||
With oqmgr(8) the "active" queue is also limited to at most 20000 recipient
|
||||
addresses ($qmgr_message_recipient_limit). To check for exhaustion of this
|
||||
limit use:
|
||||
|
||||
$ qshape active (show recipient statistics)
|
||||
|
||||
Having found the high volume domains, it is often useful to search the logs for
|
||||
recent messages pertaining to the domains in question.
|
||||
|
||||
# Find deliveries to example.com
|
||||
#
|
||||
$ tail -10000 /var/log/maillog |
|
||||
grep -E -i ': to=<.*@example\.com>,' |
|
||||
less
|
||||
|
||||
# Find messages from example.com
|
||||
#
|
||||
$ tail -10000 /var/log/maillog |
|
||||
grep -E -i ': from=<.*@example\.com>,' |
|
||||
less
|
||||
|
||||
You may want to drill in on some specific queue ids:
|
||||
|
||||
# Find all messages for a specific queue id.
|
||||
#
|
||||
$ tail -10000 /var/log/maillog | grep -E ': 2B2173FF68: '
|
||||
|
||||
Also look for queue manager warning messages in the log. These warnings can
|
||||
suggest strategies to reduce congestion.
|
||||
|
||||
$ grep -E 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
|
||||
|
||||
When all else fails try the Postfix mailing list for help, but please don't
|
||||
forget to include the top 10 or 20 lines of qshape(1) output.
|
||||
|
||||
EExxaammppllee 11:: HHeeaalltthhyy qquueeuuee
|
||||
|
||||
When looking at just the "incoming" and "active" queues, under normal
|
||||
conditions (no congestion) the "incoming" and "active" queues are nearly empty.
|
||||
Mail leaves the system almost as quickly as it comes in or is deferred without
|
||||
congestion in the "active" queue.
|
||||
|
||||
$ qshape (show "incoming" and "active" queue status)
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 5 0 0 0 1 0 0 0 1 1 2
|
||||
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
|
||||
|
||||
If one looks at the two queues separately, the "incoming" queue is empty or
|
||||
perhaps briefly has one or two messages, while the "active" queue holds more
|
||||
messages and for a somewhat longer time:
|
||||
|
||||
$ qshape incoming
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 0 0 0 0 0 0 0 0 0 0 0
|
||||
|
||||
$ qshape active
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 5 0 0 0 1 0 0 0 1 1 2
|
||||
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
|
||||
|
||||
EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuullll ooff ddiiccttiioonnaarryy aattttaacckk bboouunncceess
|
||||
|
||||
This is from a server where recipient validation is not yet available for some
|
||||
of the hosted domains. Dictionary attacks on the unvalidated domains result in
|
||||
bounce backscatter. The bounces dominate the queue, but with proper tuning they
|
||||
do not saturate the "incoming" or "active" queues. The high volume of deferred
|
||||
mail is not a direct cause for alarm.
|
||||
|
||||
$ qshape deferred | head
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 2234 4 2 5 9 31 57 108 201 464 1353
|
||||
heyhihellothere.com 207 0 0 1 1 6 6 8 25 68 92
|
||||
pleazerzoneprod.com 105 0 0 0 0 0 0 0 5 44 56
|
||||
groups.msn.com 63 2 1 2 4 4 14 14 14 8 0
|
||||
orion.toppoint.de 49 0 0 0 1 0 2 4 3 16 23
|
||||
kali.com.cn 46 0 0 0 0 1 0 2 6 12 25
|
||||
meri.uwasa.fi 44 0 0 0 0 1 0 2 8 11 22
|
||||
gjr.paknet.com.pk 43 1 0 0 1 1 3 3 6 12 16
|
||||
aristotle.algonet.se 41 0 0 0 0 0 1 2 11 12 15
|
||||
|
||||
The domains shown are mostly bulk-mailers and all the volume is the tail end of
|
||||
the time distribution, showing that short term arrival rates are moderate.
|
||||
Larger numbers and lower message ages are more indicative of current trouble.
|
||||
Old mail still going nowhere is largely harmless so long as the "active" and
|
||||
"incoming" queues are short. We can also see that the groups.msn.com
|
||||
undeliverables are low rate steady stream rather than a concentrated dictionary
|
||||
attack that is now over.
|
||||
|
||||
$ qshape -s deferred | head
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 2193 4 4 5 8 33 56 104 205 465 1309
|
||||
MAILER-DAEMON 1709 4 4 5 8 33 55 101 198 452 849
|
||||
example.com 263 0 0 0 0 0 0 0 0 2 261
|
||||
example.org 209 0 0 0 0 0 1 3 6 11 188
|
||||
example.net 6 0 0 0 0 0 0 0 0 0 6
|
||||
example.edu 3 0 0 0 0 0 0 0 0 0 3
|
||||
example.gov 2 0 0 0 0 0 0 0 1 0 1
|
||||
example.mil 1 0 0 0 0 0 0 0 0 0 1
|
||||
|
||||
Looking at the sender distribution, we see that as expected most of the
|
||||
messages are bounces.
|
||||
|
||||
EExxaammppllee 33:: CCoonnggeessttiioonn iinn tthhee aaccttiivvee qquueeuuee
|
||||
|
||||
This example is taken from a Feb 2004 discussion on the Postfix Users list.
|
||||
Congestion was reported with the "active" and "incoming" queues large and not
|
||||
shrinking despite very large delivery agent process limits. The thread is
|
||||
archived at: https://web.archive.org/web/20120227170207/http://
|
||||
archives.neohapsis.com/archives/postfix/2004-02/thread.html#1371
|
||||
|
||||
Using an older version of qshape(1) it was quickly determined that all the
|
||||
messages were for just a few destinations:
|
||||
|
||||
$ qshape (show "incoming" and "active" queue status)
|
||||
|
||||
T A 5 10 20 40 80 160 320 320+
|
||||
TOTAL 11775 9996 0 0 1 1 42 94 221 1420
|
||||
user.sourceforge.net 7678 7678 0 0 0 0 0 0 0 0
|
||||
lists.sourceforge.net 2313 2313 0 0 0 0 0 0 0 0
|
||||
gzd.gotdns.com 102 0 0 0 0 0 0 0 2 100
|
||||
|
||||
The "A" column showed the count of messages in the "active" queue, and the
|
||||
numbered columns showed totals for the "deferred" queue. At 10000 messages
|
||||
(Postfix 1.x "active" queue size limit) the "active" queue is full. The
|
||||
"incoming" queue was growing rapidly.
|
||||
|
||||
With the trouble destinations clearly identified, the administrator quickly
|
||||
found and fixed the problem. It is substantially harder to glean the same
|
||||
information from the logs. While a careful reading of mailq(1) output should
|
||||
yield similar results, it is much harder to gauge the magnitude of the problem
|
||||
by looking at the queue one message at a time.
|
||||
|
||||
EExxaammppllee 44:: HHiigghh vvoolluummee ddeessttiinnaattiioonn bbaacckklloogg
|
||||
|
||||
When a site you send a lot of email to is down or slow, mail messages will
|
||||
rapidly build up in the "deferred" queue, or worse, in the "active" queue. The
|
||||
qshape output will show large numbers for the destination domain in all age
|
||||
buckets that overlap the starting time of the problem:
|
||||
|
||||
$ qshape deferred | head
|
||||
|
||||
T 5 10 20 40 80 160 320 640 1280 1280+
|
||||
TOTAL 5000 200 200 400 800 1600 1000 200 200 200 200
|
||||
highvolume.com 4000 160 160 320 640 1280 1440 0 0 0 0
|
||||
...
|
||||
|
||||
Here the "highvolume.com" destination is continuing to accumulate deferred
|
||||
mail. The "incoming" and "active" queues are fine, but the "deferred" queue
|
||||
started growing some time between 1 and 2 hours ago and continues to grow.
|
||||
|
||||
If the high volume destination is not down, but is instead slow, one might see
|
||||
similar congestion in the "active" queue. "Active" queue congestion is a
|
||||
greater cause for alarm; one might need to take measures to ensure that the
|
||||
mail is deferred instead or even add an access(5) rule asking the sender to try
|
||||
again later.
|
||||
|
||||
If a high volume destination exhibits frequent bursts of consecutive
|
||||
connections refused by all MX hosts or "421 Server busy errors", it is possible
|
||||
for the queue manager to mark the destination as "dead" despite the transient
|
||||
nature of the errors. The destination will be retried again after the
|
||||
expiration of a $minimal_backoff_time timer. If the error bursts are frequent
|
||||
enough it may be that only a small quantity of email is delivered before the
|
||||
destination is again marked "dead". In some cases enabling static (not on
|
||||
demand) connection caching by listing the appropriate nexthop domain in a table
|
||||
included in "smtp_connection_cache_destinations" may help to reduce the error
|
||||
rate, because most messages will re-use existing connections.
|
||||
|
||||
The MTA that has been observed most frequently to exhibit such bursts of errors
|
||||
is Microsoft Exchange, which refuses connections under load. Some proxy virus
|
||||
scanners in front of the Exchange server propagate the refused connection to
|
||||
the client as a "421" error.
|
||||
|
||||
Note that it is now possible to configure Postfix to exhibit similarly erratic
|
||||
behavior by misconfiguring the anvil(8) service. Do not use anvil(8) for
|
||||
steady-state rate limiting, its purpose is (unintentional) DoS prevention and
|
||||
the rate limits set should be very generous!
|
||||
|
||||
If one finds oneself needing to deliver a high volume of mail to a destination
|
||||
that exhibits frequent brief bursts of errors and connection caching does not
|
||||
solve the problem, there is a subtle workaround.
|
||||
|
||||
* Postfix version 2.5 and later:
|
||||
|
||||
o In master.cf set up a dedicated clone of the "smtp" transport for the
|
||||
destination in question. In the example below we will call it
|
||||
"fragile".
|
||||
|
||||
o In master.cf configure a reasonable process limit for the cloned smtp
|
||||
transport (a number in the 10-20 range is typical).
|
||||
|
||||
o IMPORTANT!!! In main.cf configure a large per-destination pseudo-cohort
|
||||
failure limit for the cloned smtp transport.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
fragile_destination_concurrency_failed_cohort_limit = 100
|
||||
fragile_destination_concurrency_limit = 20
|
||||
|
||||
/etc/postfix/transport:
|
||||
example.com fragile:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
fragile unix - - n - 20 smtp
|
||||
|
||||
See also the documentation for
|
||||
default_destination_concurrency_failed_cohort_limit and
|
||||
default_destination_concurrency_limit.
|
||||
|
||||
* Earlier Postfix versions:
|
||||
|
||||
o In master.cf set up a dedicated clone of the "smtp" transport for the
|
||||
destination in question. In the example below we will call it
|
||||
"fragile".
|
||||
|
||||
o In master.cf configure a reasonable process limit for the transport (a
|
||||
number in the 10-20 range is typical).
|
||||
|
||||
o IMPORTANT!!! In main.cf configure a very large initial and destination
|
||||
concurrency limit for this transport (say 2000).
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
initial_destination_concurrency = 2000
|
||||
fragile_destination_concurrency_limit = 2000
|
||||
|
||||
/etc/postfix/transport:
|
||||
example.com fragile:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
fragile unix - - n - 20 smtp
|
||||
|
||||
See also the documentation for default_destination_concurrency_limit.
|
||||
|
||||
The effect of this configuration is that up to 2000 consecutive errors are
|
||||
tolerated without marking the destination dead, while the total concurrency
|
||||
remains reasonable (10-20 processes). This trick is only for a very specialized
|
||||
situation: high volume delivery into a channel with multi-error bursts that is
|
||||
capable of high throughput, but is repeatedly throttled by the bursts of
|
||||
errors.
|
||||
|
||||
When a destination is unable to handle the load even after the Postfix process
|
||||
limit is reduced to 1, a desperate measure is to insert brief delays between
|
||||
delivery attempts.
|
||||
|
||||
* Postfix version 2.5 and later:
|
||||
|
||||
o In master.cf set up a dedicated clone of the "smtp" transport for the
|
||||
problem destination. In the example below we call it "slow".
|
||||
|
||||
o In main.cf configure a short delay between deliveries to the same
|
||||
destination.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
slow_destination_rate_delay = 1
|
||||
slow_destination_concurrency_failed_cohort_limit = 100
|
||||
|
||||
/etc/postfix/transport:
|
||||
example.com slow:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
slow unix - - n - - smtp
|
||||
|
||||
See also the documentation for default_destination_rate_delay.
|
||||
|
||||
This solution forces the Postfix smtp(8) client to wait for
|
||||
$slow_destination_rate_delay seconds between deliveries to the same
|
||||
destination.
|
||||
|
||||
IMPORTANT!! The large slow_destination_concurrency_failed_cohort_limit
|
||||
value is needed. This prevents Postfix from deferring all mail for the same
|
||||
destination after only one connection or handshake error (the reason for
|
||||
this is that non-zero slow_destination_rate_delay forces a per-destination
|
||||
concurrency of 1).
|
||||
|
||||
* Earlier Postfix versions:
|
||||
|
||||
o In the transport map entry for the problem destination, specify a dead
|
||||
host as the primary nexthop.
|
||||
|
||||
o In the master.cf entry for the transport specify the problem
|
||||
destination as the fallback_relay and specify a small
|
||||
smtp_connect_timeout value.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
|
||||
/etc/postfix/transport:
|
||||
example.com slow:[dead.host]
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
slow unix - - n - 1 smtp
|
||||
-o fallback_relay=problem.example.com
|
||||
-o smtp_connect_timeout=1
|
||||
-o smtp_connection_cache_on_demand=no
|
||||
|
||||
This solution forces the Postfix smtp(8) client to wait for
|
||||
$smtp_connect_timeout seconds between deliveries. The connection caching
|
||||
feature is disabled to prevent the client from skipping over the dead host.
|
||||
|
||||
PPoossttffiixx qquueeuuee ddiirreeccttoorriieess
|
||||
|
||||
The following sections describe Postfix queues: their purpose, what normal
|
||||
behavior looks like, and how to diagnose abnormal behavior.
|
||||
|
||||
TThhee ""mmaaiillddrroopp"" qquueeuuee
|
||||
|
||||
Messages that have been submitted via the Postfix sendmail(1) command, but not
|
||||
yet brought into the main Postfix queue by the pickup(8) service, await
|
||||
processing in the "maildrop" queue. Messages can be added to the "maildrop"
|
||||
queue even when the Postfix system is not running. They will begin to be
|
||||
processed once Postfix is started.
|
||||
|
||||
The "maildrop" queue is drained by the single threaded pickup(8) service
|
||||
scanning the queue directory periodically or when notified of new message
|
||||
arrival by the postdrop(1) program. The postdrop(1) program is a setgid helper
|
||||
that allows the unprivileged Postfix sendmail(1) program to inject mail into
|
||||
the "maildrop" queue and to notify the pickup(8) service of its arrival.
|
||||
|
||||
All mail that enters the main Postfix queue does so via the cleanup(8) service.
|
||||
The cleanup service is responsible for envelope and header rewriting, header
|
||||
and body regular expression checks, automatic bcc recipient processing, milter
|
||||
content processing, and reliable insertion of the message into the Postfix
|
||||
"incoming" queue.
|
||||
|
||||
In the absence of excessive CPU consumption in cleanup(8) header or body
|
||||
regular expression checks or other software consuming all available CPU
|
||||
resources, Postfix performance is disk I/O bound. The rate at which the pickup
|
||||
(8) service can inject messages into the queue is largely determined by disk
|
||||
access times, since the cleanup(8) service must commit the message to stable
|
||||
storage before returning success. The same is true of the postdrop(1) program
|
||||
writing the message to the "maildrop" directory.
|
||||
|
||||
As the pickup service is single threaded, it can only deliver one message at a
|
||||
time at a rate that does not exceed the reciprocal disk I/O latency (+ CPU if
|
||||
not negligible) of the cleanup service.
|
||||
|
||||
Congestion in this queue is indicative of an excessive local message submission
|
||||
rate or perhaps excessive CPU consumption in the cleanup(8) service due to
|
||||
excessive body_checks, or (Postfix >= 2.3) high latency milters.
|
||||
|
||||
Note, that once the "active" queue is full, the cleanup service will attempt to
|
||||
slow down message injection by pausing $in_flow_delay for each message. In this
|
||||
case "maildrop" queue congestion may be a consequence of congestion downstream,
|
||||
rather than a problem in its own right.
|
||||
|
||||
Note, you should not attempt to deliver large volumes of mail via the pickup(8)
|
||||
service. High volume sites should avoid using "simple" content filters that re-
|
||||
inject scanned mail via Postfix sendmail(1) and postdrop(1).
|
||||
|
||||
A high arrival rate of locally submitted mail may be an indication of an
|
||||
uncaught forwarding loop, or a run-away notification program. Try to keep the
|
||||
volume of local mail injection to a moderate level.
|
||||
|
||||
The "postsuper -r" command can place selected messages into the "maildrop"
|
||||
queue for reprocessing. This is most useful for resetting any stale
|
||||
content_filter settings. Requeuing a large number of messages using "postsuper
|
||||
-r" can clearly cause a spike in the size of the "maildrop" queue.
|
||||
|
||||
TThhee ""hhoolldd"" qquueeuuee
|
||||
|
||||
The administrator can define "smtpd" access(5) policies, or cleanup(8) header/
|
||||
body checks that cause messages to be automatically diverted from normal
|
||||
processing and placed indefinitely in the "hold" queue. Messages placed in the
|
||||
"hold" queue stay there until the administrator intervenes. No periodic
|
||||
delivery attempts are made for messages in the "hold" queue. The postsuper(1)
|
||||
command can be used to manually release messages into the "deferred" queue.
|
||||
|
||||
Messages can potentially stay in the "hold" queue longer than
|
||||
$maximal_queue_lifetime. If such "old" messages need to be released from the
|
||||
"hold" queue, they should typically be moved into the "maildrop" queue using
|
||||
"postsuper -r", so that the message gets a new timestamp and is given more than
|
||||
one opportunity to be delivered. Messages that are "young" can be moved
|
||||
directly into the "deferred" queue using "postsuper -H".
|
||||
|
||||
The "hold" queue plays little role in Postfix performance, and monitoring of
|
||||
the "hold" queue is typically more closely motivated by tracking spam and
|
||||
malware, than by performance issues.
|
||||
|
||||
TThhee ""iinnccoommiinngg"" qquueeuuee
|
||||
|
||||
All new mail entering the Postfix queue is written by the cleanup(8) service
|
||||
into the "incoming" queue. New queue files are created owned by the "postfix"
|
||||
user with an access bitmask (or mode) of 0600. Once a queue file is ready for
|
||||
further processing the cleanup(8) service changes the queue file mode to 0700
|
||||
and notifies the queue manager of new mail arrival. The queue manager ignores
|
||||
incomplete queue files whose mode is 0600, as these are still being written by
|
||||
cleanup.
|
||||
|
||||
The queue manager scans the "incoming" queue bringing any new mail into the
|
||||
"active" queue if the "active" queue resource limits have not been exceeded. By
|
||||
default, the "active" queue accommodates at most 20000 messages. Once the
|
||||
"active" queue message limit is reached, the queue manager stops scanning the
|
||||
"incoming" queue (and the "deferred" queue, see below).
|
||||
|
||||
Under normal conditions the "incoming" queue is nearly empty (has only mode
|
||||
0600 files), with the queue manager able to import new messages into the
|
||||
"active" queue as soon as they become available.
|
||||
|
||||
The "incoming" queue grows when the message input rate spikes above the rate at
|
||||
which the queue manager can import messages into the "active" queue. The main
|
||||
factors slowing down the queue manager are disk I/O and lookup queries to the
|
||||
trivial-rewrite service. If the queue manager is routinely not keeping up,
|
||||
consider not using "slow" lookup services (MySQL, LDAP, ...) for transport
|
||||
lookups or speeding up the hosts that provide the lookup service. If the
|
||||
problem is I/O starvation, consider striping the queue over more disks, faster
|
||||
controllers with a battery write cache, or other hardware improvements. At the
|
||||
very least, make sure that the queue directory is mounted with the "noatime"
|
||||
option if applicable to the underlying filesystem.
|
||||
|
||||
The in_flow_delay parameter is used to clamp the input rate when the queue
|
||||
manager starts to fall behind. The cleanup(8) service will pause for
|
||||
$in_flow_delay seconds before creating a new queue file if it cannot obtain a
|
||||
"token" from the queue manager.
|
||||
|
||||
Since the number of cleanup(8) processes is limited in most cases by the SMTP
|
||||
server concurrency, the input rate can exceed the output rate by at most "SMTP
|
||||
connection count" / $in_flow_delay messages per second.
|
||||
|
||||
With a default process limit of 100, and an in_flow_delay of 1s, the coupling
|
||||
is strong enough to limit a single run-away injector to 1 message per second,
|
||||
but is not strong enough to deflect an excessive input rate from many sources
|
||||
at the same time.
|
||||
|
||||
If a server is being hammered from multiple directions, consider raising the
|
||||
in_flow_delay to 10 seconds, but only if the "incoming" queue is growing even
|
||||
while the "active" queue is not full and the trivial-rewrite service is using a
|
||||
fast transport lookup mechanism.
|
||||
|
||||
TThhee ""aaccttiivvee"" qquueeuuee
|
||||
|
||||
The queue manager is a delivery agent scheduler; it works to ensure fast and
|
||||
fair delivery of mail to all destinations within designated resource limits.
|
||||
|
||||
The "active" queue is somewhat analogous to an operating system's process run
|
||||
queue. Messages in the "active" queue are ready to be sent (runnable), but are
|
||||
not necessarily in the process of being sent (running).
|
||||
|
||||
While most Postfix administrators think of the "active" queue as a directory on
|
||||
disk, the real "active" queue is a set of data structures in the memory of the
|
||||
queue manager process.
|
||||
|
||||
Messages in the "maildrop", "hold", "incoming" and "deferred" queues (see
|
||||
below) do not occupy memory; they are safely stored on disk waiting for their
|
||||
turn to be processed. The envelope information for messages in the "active"
|
||||
queue is managed in memory, allowing the queue manager to do global scheduling,
|
||||
allocating available delivery agent processes to an appropriate message in the
|
||||
"active" queue.
|
||||
|
||||
Within the "active" queue, (multi-recipient) messages are broken up into groups
|
||||
of recipients that share the same transport/nexthop combination; the group size
|
||||
is capped by the transport's recipient concurrency limit.
|
||||
|
||||
Multiple recipient groups (from one or more messages) are queued for delivery
|
||||
grouped by transport/nexthop combination. The ddeessttiinnaattiioonn concurrency limit for
|
||||
the transports caps the number of simultaneous delivery attempts for each
|
||||
nexthop. Transports with a rreecciippiieenntt concurrency limit of 1 are special: these
|
||||
are grouped by the actual recipient address rather than the nexthop, yielding
|
||||
per-recipient concurrency limits rather than per-domain concurrency limits.
|
||||
Per-recipient limits are appropriate when performing final delivery to
|
||||
mailboxes rather than when relaying to a remote server.
|
||||
|
||||
Congestion occurs in the "active" queue when one or more destinations drain
|
||||
slower than the corresponding message input rate.
|
||||
|
||||
Input into the "active" queue comes both from new mail in the "incoming" queue,
|
||||
and retries of mail in the "deferred" queue. Should the "deferred" queue get
|
||||
really large, retries of old mail can dominate the arrival rate of new mail.
|
||||
Systems with more CPU, faster disks and more network bandwidth can deal with
|
||||
larger "deferred" queues, but as a rule of thumb the "deferred" queue scales to
|
||||
somewhere between 100,000 and 1,000,000 messages with good performance unlikely
|
||||
above that "limit". Systems with queues this large should typically stop
|
||||
accepting new mail, or put the backlog "on hold" until the underlying issue is
|
||||
fixed (provided that there is enough capacity to handle just the new mail).
|
||||
|
||||
When a destination is down for some time, the queue manager will mark it dead,
|
||||
and immediately defer all mail for the destination without trying to assign it
|
||||
to a delivery agent. In this case the messages will quickly leave the "active"
|
||||
queue and end up in the "deferred" queue (with Postfix < 2.4, this is done
|
||||
directly by the queue manager, with Postfix >= 2.4 this is done via the "retry"
|
||||
delivery agent).
|
||||
|
||||
When the destination is instead simply slow, or there is a problem causing an
|
||||
excessive arrival rate the "active" queue will grow and will become dominated
|
||||
by mail to the congested destination.
|
||||
|
||||
The only way to reduce congestion is to either reduce the input rate or
|
||||
increase the throughput. Increasing the throughput requires either increasing
|
||||
the concurrency or reducing the latency of deliveries.
|
||||
|
||||
For high volume sites a key tuning parameter is the number of "smtp" delivery
|
||||
agents allocated to the "smtp" and "relay" transports. High volume sites tend
|
||||
to send to many different destinations, many of which may be down or slow, so a
|
||||
good fraction of the available delivery agents will be blocked waiting for slow
|
||||
sites. Also mail destined across the globe will incur large SMTP command-
|
||||
response latencies, so high message throughput can only be achieved with more
|
||||
concurrent delivery agents.
|
||||
|
||||
The default "smtp" process limit of 100 is good enough for most sites, and may
|
||||
even need to be lowered for sites with low bandwidth connections (no use
|
||||
increasing concurrency once the network pipe is full). When one finds that the
|
||||
queue is growing on an "idle" system (CPU, disk I/O and network not exhausted)
|
||||
the remaining reason for congestion is insufficient concurrency in the face of
|
||||
a high average latency. If the number of outbound SMTP connections (either
|
||||
ESTABLISHED or SYN_SENT) reaches the process limit, mail is draining slowly and
|
||||
the system and network are not loaded, raise the "smtp" and/or "relay" process
|
||||
limits!
|
||||
|
||||
When a high volume destination is served by multiple MX hosts with typically
|
||||
low delivery latency, performance can suffer dramatically when one of the MX
|
||||
hosts is unresponsive and SMTP connections to that host timeout. For example,
|
||||
if there are 2 equal weight MX hosts, the SMTP connection timeout is 30 seconds
|
||||
and one of the MX hosts is down, the average SMTP connection will take
|
||||
approximately 15 seconds to complete. With a default per-destination
|
||||
concurrency limit of 20 connections, throughput falls to just over 1 message
|
||||
per second.
|
||||
|
||||
The best way to avoid bottlenecks when one or more MX hosts is non-responsive
|
||||
is to use connection caching. Connection caching was introduced with Postfix
|
||||
2.2 and is by default enabled on demand for destinations with a backlog of mail
|
||||
in the "active" queue. When connection caching is in effect for a particular
|
||||
destination, established connections are re-used to send additional messages,
|
||||
this reduces the number of connections made per message delivery and maintains
|
||||
good throughput even in the face of partial unavailability of the destination's
|
||||
MX hosts.
|
||||
|
||||
If connection caching is not available (Postfix < 2.2) or does not provide a
|
||||
sufficient latency reduction, especially for the "relay" transport used to
|
||||
forward mail to "your own" domains, consider setting lower than default SMTP
|
||||
connection timeouts (1-5 seconds) and higher than default destination
|
||||
concurrency limits. This will further reduce latency and provide more
|
||||
concurrency to maintain throughput should latency rise.
|
||||
|
||||
Setting high concurrency limits to domains that are not your own may be viewed
|
||||
as hostile by the receiving system, and steps may be taken to prevent you from
|
||||
monopolizing the destination system's resources. The defensive measures may
|
||||
substantially reduce your throughput or block access entirely. Do not set
|
||||
aggressive concurrency limits to remote domains without coordinating with the
|
||||
administrators of the target domain.
|
||||
|
||||
If necessary, dedicate and tune custom transports for selected high volume
|
||||
destinations. The "relay" transport is provided for forwarding mail to domains
|
||||
for which your server is a primary or backup MX host. These can make up a
|
||||
substantial fraction of your email traffic. Use the "relay" and not the "smtp"
|
||||
transport to send email to these domains. Using the "relay" transport allocates
|
||||
a separate delivery agent pool to these destinations and allows separate tuning
|
||||
of timeouts and concurrency limits.
|
||||
|
||||
Another common cause of congestion is unwarranted flushing of the entire
|
||||
"deferred" queue. The "deferred" queue holds messages that are likely to fail
|
||||
to be delivered and are also likely to be slow to fail delivery (time out). As
|
||||
a result the most common reaction to a large "deferred" queue (flush it!) is
|
||||
more than likely counter-productive, and typically makes the congestion worse.
|
||||
Do not flush the "deferred" queue unless you expect that most of its content
|
||||
has recently become deliverable (e.g. relayhost back up after an outage)!
|
||||
|
||||
Note that whenever the queue manager is restarted, there may already be
|
||||
messages in the "active" queue directory, but the "real" "active" queue in
|
||||
memory is empty. In order to recover the in-memory state, the queue manager
|
||||
moves all the "active" queue messages back into the "incoming" queue, and then
|
||||
uses its normal "incoming" queue scan to refill the "active" queue. The process
|
||||
of moving all the messages back and forth, redoing transport table (trivial-
|
||||
rewrite(8) resolve service) lookups, and re-importing the messages back into
|
||||
memory is expensive. At all costs, avoid frequent restarts of the queue manager
|
||||
(e.g. via frequent execution of "postfix reload").
|
||||
|
||||
TThhee ""ddeeffeerrrreedd"" qquueeuuee
|
||||
|
||||
When all the deliverable recipients for a message are delivered, and for some
|
||||
recipients delivery failed for a transient reason (it might succeed later), the
|
||||
message is placed in the "deferred" queue.
|
||||
|
||||
The queue manager scans the "deferred" queue periodically. The scan interval is
|
||||
controlled by the queue_run_delay parameter. While a "deferred" queue scan is
|
||||
in progress, if an "incoming" queue scan is also in progress (ideally these are
|
||||
brief since the "incoming" queue should be short), the queue manager alternates
|
||||
between looking for messages in the "incoming" queue and in the "deferred"
|
||||
queue. This "round-robin" strategy prevents starvation of either the "incoming"
|
||||
or the "deferred" queues.
|
||||
|
||||
Each "deferred" queue scan only brings a fraction of the "deferred" queue back
|
||||
into the "active" queue for a retry. This is because each message in the
|
||||
"deferred" queue is assigned a "cool-off" time when it is deferred. This is
|
||||
done by time-warping the modification time of the queue file into the future.
|
||||
The queue file is not eligible for a retry if its modification time is not yet
|
||||
reached.
|
||||
|
||||
The "cool-off" time is at least $minimal_backoff_time and at most
|
||||
$maximal_backoff_time. The next retry time is set by doubling the message's age
|
||||
in the queue, and adjusting up or down to lie within the limits. This means
|
||||
that young messages are initially retried more often than old messages.
|
||||
|
||||
If a high volume site routinely has large "deferred" queues, it may be useful
|
||||
to adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
|
||||
provide short enough delays on first failure (Postfix >= 2.4 has a sensibly low
|
||||
minimal backoff time by default), with perhaps longer delays after multiple
|
||||
failures, to reduce the retransmission rate of old messages and thereby reduce
|
||||
the quantity of previously deferred mail in the "active" queue. If you want a
|
||||
really low minimal_backoff_time, you may also want to lower queue_run_delay,
|
||||
but understand that more frequent scans will increase the demand for disk I/O.
|
||||
|
||||
One common cause of large "deferred" queues is failure to validate recipients
|
||||
at the SMTP input stage. Since spammers routinely launch dictionary attacks
|
||||
from unrepliable sender addresses, the bounces for invalid recipient addresses
|
||||
clog the "deferred" queue (and at high volumes proportionally clog the "active"
|
||||
queue). Recipient validation is strongly recommended through use of the
|
||||
local_recipient_maps and relay_recipient_maps parameters. Even when bounces
|
||||
drain quickly they inundate innocent victims of forgery with unwanted email. To
|
||||
avoid this, do not accept mail for invalid recipients.
|
||||
|
||||
When a host with lots of deferred mail is down for some time, it is possible
|
||||
for the entire "deferred" queue to reach its retry time simultaneously. This
|
||||
can lead to a very full "active" queue once the host comes back up. The
|
||||
phenomenon can repeat approximately every maximal_backoff_time seconds if the
|
||||
messages are again deferred after a brief burst of congestion. Perhaps, a
|
||||
future Postfix release will add a random offset to the retry time (or use a
|
||||
combination of strategies) to reduce the odds of repeated complete "deferred"
|
||||
queue flushes.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
The qshape(1) program was developed by Victor Duchovni of Morgan Stanley, who
|
||||
also wrote the initial version of this document.
|
||||
|
||||
1
README_FILES/RELEASE_NOTES
Symbolic link
1
README_FILES/RELEASE_NOTES
Symbolic link
|
|
@ -0,0 +1 @@
|
|||
../RELEASE_NOTES
|
||||
166
README_FILES/RESTRICTION_CLASS_README
Normal file
166
README_FILES/RESTRICTION_CLASS_README
Normal file
|
|
@ -0,0 +1,166 @@
|
|||
PPoossttffiixx PPeerr--CClliieenntt//UUsseerr//eettcc.. AAcccceessss CCoonnttrrooll
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPoossttffiixx rreessttrriiccttiioonn ccllaasssseess
|
||||
|
||||
The Postfix SMTP server supports access restrictions such as reject_rbl_client
|
||||
or reject_unknown_client_hostname on the right-hand side of SMTP server access
|
||||
(5) tables. This allows you to implement different junk mail restrictions for
|
||||
different clients or users.
|
||||
|
||||
Having to specify lists of access restrictions for every recipient becomes
|
||||
tedious quickly. Postfix restriction classes allow you to give easy-to-remember
|
||||
names to groups of UCE restrictions (such as "permissive", "restrictive", and
|
||||
so on).
|
||||
|
||||
The real reason for the existence of Postfix restriction classes is more
|
||||
mundane: you can't specify a lookup table on the right-hand side of a Postfix
|
||||
access table. This is because Postfix needs to open lookup tables ahead of
|
||||
time, but the reader probably does not care about these low-level details.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_restriction_classes = restrictive, permissive
|
||||
# With Postfix < 2.3 specify reject_unknown_client.
|
||||
restrictive = reject_unknown_sender_domain
|
||||
reject_unknown_client_hostname ...
|
||||
permissive = permit
|
||||
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks
|
||||
# reject_unauth_destination is not needed here if the mail
|
||||
# relay policy is specified with smtpd_relay_restrictions
|
||||
# (available with Postfix 2.10 and later).
|
||||
reject_unauth_destination
|
||||
check_recipient_access hash:/etc/postfix/recipient_access
|
||||
...
|
||||
|
||||
/etc/postfix/recipient_access:
|
||||
joe@my.domain permissive
|
||||
jane@my.domain restrictive
|
||||
|
||||
With this in place, you can use "restrictive" or "permissive" on the right-hand
|
||||
side of your per-client, helo, sender, or recipient SMTPD access tables.
|
||||
|
||||
The remainder of this document gives examples of how Postfix access restriction
|
||||
classes can be used to:
|
||||
|
||||
* Shield an internal mailing list from outside posters,
|
||||
* Prevent external access by internal senders.
|
||||
|
||||
These questions come up frequently, and the examples hopefully make clear that
|
||||
Postfix restriction classes aren't really the right solution. They should be
|
||||
used for what they were designed to do, different junk mail restrictions for
|
||||
different clients or users.
|
||||
|
||||
PPrrootteeccttiinngg iinntteerrnnaall eemmaaiill ddiissttrriibbuuttiioonn lliissttss
|
||||
|
||||
We want to implement an internal email distribution list. Something like
|
||||
all@our.domain.com, which aliases to all employees. My first thought was to
|
||||
use the aliases map, but that would lead to "all" being accessible from the
|
||||
"outside", and this is not desired... :-)
|
||||
|
||||
Postfix can implement per-address access controls. What follows is based on the
|
||||
SMTP client IP address, and therefore is subject to IP spoofing.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
...
|
||||
check_recipient_access hash:/etc/postfix/access
|
||||
...the usual stuff...
|
||||
|
||||
/etc/postfix/access:
|
||||
all@my.domain permit_mynetworks,reject
|
||||
all@my.hostname permit_mynetworks,reject
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
|
||||
|
||||
Now, that would be sufficient when your machine receives all Internet mail
|
||||
directly from the Internet. That's unlikely if your network is a bit larger
|
||||
than an office. For example, your backup MX hosts would "launder" the client IP
|
||||
address of mail from the outside so it would appear to come from a trusted
|
||||
machine.
|
||||
|
||||
In the general case you need two lookup tables: one table that lists
|
||||
destinations that need to be protected, and one table that lists domains that
|
||||
are allowed to send to the protected destinations.
|
||||
|
||||
What follows is based on the sender SMTP envelope address, and therefore is
|
||||
subject to SMTP sender spoofing.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
...
|
||||
check_recipient_access hash:/etc/postfix/protected_destinations
|
||||
...the usual stuff...
|
||||
|
||||
smtpd_restriction_classes = insiders_only
|
||||
insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
|
||||
|
||||
/etc/postfix/protected_destinations:
|
||||
all@my.domain insiders_only
|
||||
all@my.hostname insiders_only
|
||||
|
||||
/etc/postfix/insiders:
|
||||
my.domain OK matches my.domain and subdomains
|
||||
another.domain OK matches another.domain and subdomains
|
||||
|
||||
Getting past this scheme is relatively easy, because all one has to do is to
|
||||
spoof the SMTP sender address.
|
||||
|
||||
If the internal list is a low-volume one, perhaps it makes more sense to make
|
||||
it moderated.
|
||||
|
||||
RReessttrriiccttiinngg wwhhaatt uusseerrss ccaann sseenndd mmaaiill ttoo ooffff--ssiittee ddeessttiinnaattiioonnss
|
||||
|
||||
How can I configure Postfix in a way that some users can send mail to the
|
||||
internet and other users not. The users with no access should receive a
|
||||
generic bounce message. Please don't discuss whether such access
|
||||
restrictions are necessary, it was not my decision.
|
||||
|
||||
Postfix has support for per-user restrictions. The restrictions are implemented
|
||||
by the SMTP server. Thus, users that violate the policy have their mail
|
||||
rejected by the SMTP server. Like this:
|
||||
|
||||
554 <user@remote>: Access denied
|
||||
|
||||
The implementation uses two lookup tables. One table defines what users are
|
||||
restricted in where they can send mail, and the other table defines what
|
||||
destinations are local. It is left as an exercise for the reader to change this
|
||||
into a scheme where only some users have permission to send mail to off-site
|
||||
destinations, and where most users are restricted.
|
||||
|
||||
The example assumes DB/DBM files, but this could also be done with LDAP or SQL.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_recipient_restrictions =
|
||||
...
|
||||
check_sender_access hash:/etc/postfix/restricted_senders
|
||||
...other stuff...
|
||||
|
||||
smtpd_restriction_classes = local_only
|
||||
local_only =
|
||||
check_recipient_access hash:/etc/postfix/local_domains, reject
|
||||
|
||||
/etc/postfix/restricted_senders:
|
||||
foo@domain local_only
|
||||
bar@domain local_only
|
||||
|
||||
/etc/postfix/local_domains:
|
||||
this.domain OK matches this.domain and subdomains
|
||||
that.domain OK matches that.domain and subdomains
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
|
||||
|
||||
Note: this scheme does not authenticate the user, and therefore it can be
|
||||
bypassed in several ways:
|
||||
|
||||
* By sending mail via a less restrictive mail relay host.
|
||||
|
||||
* By sending mail as someone else who does have permission to send mail to
|
||||
off-site destinations.
|
||||
|
||||
1433
README_FILES/SASL_README
Normal file
1433
README_FILES/SASL_README
Normal file
File diff suppressed because it is too large
Load diff
1161
README_FILES/SCHEDULER_README
Normal file
1161
README_FILES/SCHEDULER_README
Normal file
File diff suppressed because it is too large
Load diff
347
README_FILES/SMTPD_ACCESS_README
Normal file
347
README_FILES/SMTPD_ACCESS_README
Normal file
|
|
@ -0,0 +1,347 @@
|
|||
PPoossttffiixx SSMMTTPP rreellaayy aanndd aacccceessss ccoonnttrrooll
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The Postfix SMTP server receives mail from the network and is exposed to the
|
||||
big bad world of junk email and viruses. This document introduces the built-in
|
||||
and external methods that control what SMTP mail Postfix will accept, what
|
||||
mistakes to avoid, and how to test your configuration.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Relay control, junk mail control, and per-user policies
|
||||
* Restrictions that apply to all SMTP mail
|
||||
* Getting selective with SMTP access restriction lists
|
||||
* Delayed evaluation of SMTP access restriction lists
|
||||
* Dangerous use of smtpd_recipient_restrictions
|
||||
* SMTP access rule testing
|
||||
|
||||
RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttrrooll,, aanndd ppeerr--uusseerr ppoolliicciieess
|
||||
|
||||
In a distant past, the Internet was a friendly environment. Mail servers
|
||||
happily forwarded mail on behalf of anyone towards any destination. On today's
|
||||
Internet, spammers abuse servers that forward mail from arbitrary systems, and
|
||||
abused systems end up on anti-spammer denylists. See, for example, the
|
||||
information on https://www.spamhaus.org/ and other websites.
|
||||
|
||||
By default, Postfix has a moderately restrictive approach to mail relaying.
|
||||
Postfix forwards mail only from clients in trusted networks, from clients that
|
||||
have authenticated with SASL, or to domains that are configured as authorized
|
||||
relay destinations. For a description of the default mail relay policy, see the
|
||||
smtpd_relay_restrictions parameter in the postconf(5) manual page, and the
|
||||
information that is referenced from there.
|
||||
|
||||
NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions.
|
||||
They combined the mail relay and spam blocking policies, under
|
||||
smtpd_recipient_restrictions. This could lead to unexpected results. For
|
||||
example, a permissive spam blocking policy could unexpectedly result in a
|
||||
permissive mail relay policy. An example of this is documented under
|
||||
"Dangerous use of smtpd_recipient_restrictions".
|
||||
|
||||
Most of the Postfix SMTP server access controls are targeted at stopping junk
|
||||
email.
|
||||
|
||||
* Protocol oriented: some SMTP server access controls block mail by being
|
||||
very strict with respect to the SMTP protocol; these catch poorly
|
||||
implemented and/or poorly configured junk email software, as well as email
|
||||
worms that come with their own non-standard SMTP client implementations.
|
||||
Protocol-oriented access controls become less useful over time as spammers
|
||||
and worm writers learn to read RFC documents.
|
||||
|
||||
* Denylist oriented: some SMTP server access controls query denylists with
|
||||
known to be bad sites such as open mail relays, open web proxies, and home
|
||||
computers that have been compromised and that are under remote control by
|
||||
criminals. The effectiveness of these denylists depends on how complete and
|
||||
how up to date they are.
|
||||
|
||||
* Threshold oriented: some SMTP server access controls attempt to raise the
|
||||
bar by either making the client do more work (greylisting) or by asking for
|
||||
a second opinion (SPF and sender/recipient address verification). The
|
||||
greylisting and SPF policies are implemented externally, and are the
|
||||
subject of the SMTPD_POLICY_README document. Sender/recipient address
|
||||
verification is the subject of the ADDRESS_VERIFICATION_README document.
|
||||
|
||||
Unfortunately, all junk mail controls have the possibility of falsely rejecting
|
||||
legitimate mail. This can be a problem for sites with many different types of
|
||||
users. For some users it is unacceptable when any junk email slips through,
|
||||
while for other users the world comes to an end when a single legitimate email
|
||||
message is blocked. Because there is no single policy that is "right" for all
|
||||
users, Postfix supports different SMTP access restrictions for different users.
|
||||
This is described in the RESTRICTION_CLASS_README document.
|
||||
|
||||
RReessttrriiccttiioonnss tthhaatt aappppllyy ttoo aallll SSMMTTPP mmaaiill
|
||||
|
||||
Besides the restrictions that can be made configurable per client or per user
|
||||
as described in the next section, Postfix implements a few restrictions that
|
||||
apply to all SMTP mail.
|
||||
|
||||
* The built-in header_checks and body_checks content restrictions, as
|
||||
described in the BUILTIN_FILTER_README document. This happens while Postfix
|
||||
receives mail, before it is stored in the incoming queue.
|
||||
|
||||
* The external before-queue content restrictions, as described in the
|
||||
SMTPD_PROXY_README document. This happens while Postfix receives mail,
|
||||
before it is stored in the incoming queue.
|
||||
|
||||
* Requiring that the client sends the HELO or EHLO command before sending the
|
||||
MAIL FROM or ETRN command. This may cause problems with home-grown
|
||||
applications that send mail. For this reason, the requirement is disabled
|
||||
by default ("smtpd_helo_required = no").
|
||||
|
||||
* Disallowing illegal syntax in MAIL FROM or RCPT TO commands. This may cause
|
||||
problems with home-grown applications that send mail, and with ancient PC
|
||||
mail clients. For this reason, the requirement is disabled by default
|
||||
("strict_rfc821_envelopes = no").
|
||||
|
||||
o Disallowing RFC 822 address syntax (example: "MAIL FROM: the dude
|
||||
<dude@example.com>").
|
||||
|
||||
o Disallowing addresses that are not enclosed with <> (example: "MAIL
|
||||
FROM: dude@example.com").
|
||||
|
||||
* Rejecting mail from a non-existent sender address. This form of egress
|
||||
filtering helps to slow down worms and other malware, but may cause
|
||||
problems with home-grown software that sends out mail software with an
|
||||
unreplyable address. For this reason the requirement is disabled by default
|
||||
("smtpd_reject_unlisted_sender = no").
|
||||
|
||||
* Rejecting mail for a non-existent recipient address. This form of ingress
|
||||
filtering helps to keep the mail queue free of undeliverable MAILER-DAEMON
|
||||
messages. This requirement is enabled by default
|
||||
("smtpd_reject_unlisted_recipient = yes").
|
||||
|
||||
GGeettttiinngg sseelleeccttiivvee wwiitthh SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
|
||||
|
||||
Postfix allows you to specify lists of access restrictions for each stage of
|
||||
the SMTP conversation. Individual restrictions are described in the postconf(5)
|
||||
manual page.
|
||||
|
||||
Examples of simple restriction lists are:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Allow connections from trusted networks only.
|
||||
smtpd_client_restrictions = permit_mynetworks, reject
|
||||
|
||||
# Don't talk to mail systems that don't know their own hostname.
|
||||
# With Postfix < 2.3, specify reject_unknown_hostname.
|
||||
smtpd_helo_restrictions = reject_unknown_helo_hostname
|
||||
|
||||
# Don't accept mail from domains that don't exist.
|
||||
smtpd_sender_restrictions = reject_unknown_sender_domain
|
||||
|
||||
# Spam control: exclude local clients and authenticated clients
|
||||
# from DNSBL lookups.
|
||||
smtpd_recipient_restrictions = permit_mynetworks,
|
||||
permit_sasl_authenticated,
|
||||
# reject_unauth_destination is not needed here if the mail
|
||||
# relay policy is specified under smtpd_relay_restrictions
|
||||
# (available with Postfix 2.10 and later).
|
||||
reject_unauth_destination
|
||||
reject_rbl_client zen.spamhaus.org,
|
||||
reject_rhsbl_reverse_client dbl.spamhaus.org,
|
||||
reject_rhsbl_helo dbl.spamhaus.org,
|
||||
reject_rhsbl_sender dbl.spamhaus.org
|
||||
|
||||
# Relay control (Postfix 2.10 and later): local clients and
|
||||
# authenticated clients may specify any destination domain.
|
||||
smtpd_relay_restrictions = permit_mynetworks,
|
||||
permit_sasl_authenticated,
|
||||
reject_unauth_destination
|
||||
|
||||
# Block clients that speak too early.
|
||||
smtpd_data_restrictions = reject_unauth_pipelining
|
||||
|
||||
# Enforce mail volume quota via policy service callouts.
|
||||
smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
|
||||
|
||||
Each restriction list is evaluated from left to right until some restriction
|
||||
produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
|
||||
list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
|
||||
REJECT restriction you can make exceptions for specific clients or users. This
|
||||
is called allowlisting; the smtpd_relay_restrictions example above allows mail
|
||||
from local networks, and from SASL authenticated clients, but otherwise rejects
|
||||
mail to arbitrary destinations.
|
||||
|
||||
The table below summarizes the purpose of each SMTP access restriction list.
|
||||
All lists use the exact same syntax; they differ only in the time of evaluation
|
||||
and in the effect of a REJECT or DEFER result.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
| | | |EEffffeecctt ooff |
|
||||
|RReessttrriiccttiioonn lliisstt nnaammee |VVeerrssiioonn|SSttaattuuss |RREEJJEECCTT oorr |
|
||||
| | | |DDEEFFEERR |
|
||||
| | | |rreessuulltt |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | | |Reject all |
|
||||
|smtpd_client_restrictions |All |Optional |client |
|
||||
| | | |commands |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | | |Reject |
|
||||
|smtpd_helo_restrictions |All |Optional |HELO/EHLO |
|
||||
| | | |information|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | | |Reject MAIL|
|
||||
|smtpd_sender_restrictions |All |Optional |FROM |
|
||||
| | | |information|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Required if | |
|
||||
| |>= 2.10|smtpd_relay_restrictions | |
|
||||
| | |does not enforce relay |Reject RCPT|
|
||||
|smtpd_recipient_restrictions | |policy |TO |
|
||||
| |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
|
||||
| | | | |
|
||||
| |< 2.10 |Required | |
|
||||
| | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | |Required if | |
|
||||
| |>= 2.10|smtpd_recipient_restrictions| |
|
||||
| | |does not enforce relay |Reject RCPT|
|
||||
|smtpd_relay_restrictions | |policy |TO |
|
||||
| |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
|
||||
| | | | |
|
||||
| |< 2.10 |Not available | |
|
||||
| | | | |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
|smtpd_data_restrictions |>= 2.0 |Optional |Reject DATA|
|
||||
| | | |command |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
| | | |Reject END-|
|
||||
|smtpd_end_of_data_restrictions|>= 2.2 |Optional |OF-DATA |
|
||||
| | | |command |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
|smtpd_etrn_restrictions |All |Optional |Reject ETRN|
|
||||
| | | |command |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
DDeellaayyeedd eevvaalluuaattiioonn ooff SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
|
||||
|
||||
Early Postfix versions evaluated SMTP access restrictions lists as early as
|
||||
possible. The client restriction list was evaluated before Postfix sent the
|
||||
"220 $myhostname..." greeting banner to the SMTP client, the helo restriction
|
||||
list was evaluated before Postfix replied to the HELO (EHLO) command, the
|
||||
sender restriction list was evaluated before Postfix replied to the MAIL FROM
|
||||
command, and so on. This approach turned out to be difficult to use.
|
||||
|
||||
Current Postfix versions postpone the evaluation of client, helo and sender
|
||||
restriction lists until the RCPT TO or ETRN command. This behavior is
|
||||
controlled by the smtpd_delay_reject parameter. Restriction lists are still
|
||||
evaluated in the proper order of (client, helo, etrn) or (client, helo, sender,
|
||||
relay, recipient, data, or end-of-data) restrictions. When a restriction list
|
||||
(example: client) evaluates to REJECT or DEFER the restriction lists that
|
||||
follow (example: helo, sender, etc.) are skipped.
|
||||
|
||||
Around the time that smtpd_delay_reject was introduced, Postfix was also
|
||||
changed to support mixed restriction lists that combine information about the
|
||||
client, helo, sender and recipient or etrn command.
|
||||
|
||||
Benefits of delayed restriction evaluation, and of restriction mixing:
|
||||
|
||||
* Some SMTP clients do not expect a negative reply early in the SMTP session.
|
||||
When the bad news is postponed until the RCPT TO reply, the client goes
|
||||
away as it is supposed to, instead of hanging around until a timeout
|
||||
happens, or worse, going into an endless connect-reject-connect loop.
|
||||
|
||||
* Postfix can log more useful information. For example, when Postfix rejects
|
||||
a client name or address and delays the action until the RCPT TO command,
|
||||
it can log the sender and the recipient address. This is more useful than
|
||||
logging only the client hostname and IP address and not knowing whose mail
|
||||
was being blocked.
|
||||
|
||||
* Mixing is needed for complex allowlisting policies. For example, in order
|
||||
to reject local sender addresses in mail from non-local clients, you need
|
||||
to be able to mix restrictions on client information with restrictions on
|
||||
sender information in the same restriction list. Without this ability, many
|
||||
per-user access restrictions would be impossible to express.
|
||||
|
||||
DDaannggeerroouuss uussee ooff ssmmttppdd__rreecciippiieenntt__rreessttrriiccttiioonnss
|
||||
|
||||
By now the reader may wonder why we need smtpd client, helo or sender
|
||||
restrictions, when their evaluation is postponed until the RCPT TO or ETRN
|
||||
command. Some people recommend placing ALL the access restrictions in the
|
||||
smtpd_recipient_restrictions list. Unfortunately, this can result in too
|
||||
permissive access. How is this possible?
|
||||
|
||||
The purpose of the smtpd_recipient_restrictions feature is to control how
|
||||
Postfix replies to the RCPT TO command. If the restriction list evaluates to
|
||||
REJECT or DEFER, the recipient address is rejected; no surprises here. If the
|
||||
result is PERMIT, then the recipient address is accepted. And this is where
|
||||
surprises can happen.
|
||||
|
||||
The problem is that Postfix versions before 2.10 did not have
|
||||
smtpd_relay_restrictions. They combined the mail relay and spam blocking
|
||||
policies, under smtpd_recipient_restrictions. The result is that a permissive
|
||||
spam blocking policy could unexpectedly result in a permissive mail relay
|
||||
policy.
|
||||
|
||||
Here is an example that shows when a PERMIT result can result in too much
|
||||
access permission:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_recipient_restrictions =
|
||||
3 permit_mynetworks
|
||||
4 check_helo_access hash:/etc/postfix/helo_access
|
||||
5 reject_unknown_helo_hostname
|
||||
6 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
|
||||
7
|
||||
8 /etc/postfix/helo_access:
|
||||
9 localhost.localdomain PERMIT
|
||||
|
||||
Line 5 rejects mail from hosts that don't specify a proper hostname in the HELO
|
||||
command (with Postfix < 2.3, specify reject_unknown_hostname). Lines 4 and 9
|
||||
make an exception to allow mail from some machine that announces itself with
|
||||
"HELO localhost.localdomain".
|
||||
|
||||
The problem with this configuration is that smtpd_recipient_restrictions
|
||||
evaluates to PERMIT for EVERY host that announces itself as
|
||||
"localhost.localdomain", making Postfix an open relay for all such hosts.
|
||||
|
||||
With Postfix before version 2.10 you should place non-recipient restrictions
|
||||
AFTER the reject_unauth_destination restriction, not before. In the above
|
||||
example, the HELO based restrictions should be placed AFTER
|
||||
reject_unauth_destination, or better, the HELO based restrictions should be
|
||||
placed under smtpd_helo_restrictions where they can do no harm.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_recipient_restrictions =
|
||||
3 permit_mynetworks
|
||||
4 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
|
||||
5 check_helo_access hash:/etc/postfix/helo_access
|
||||
6 reject_unknown_helo_hostname
|
||||
7
|
||||
8 /etc/postfix/helo_access:
|
||||
9 localhost.localdomain PERMIT
|
||||
|
||||
The above mistake will not happen with Postfix 2.10 and later, when the relay
|
||||
policy is specified under smtpd_relay_restrictions, and the spam blocking
|
||||
policy under smtpd_recipient_restrictions. Then, a permissive spam blocking
|
||||
policy will not result in a permissive mail relay policy.
|
||||
|
||||
SSMMTTPP aacccceessss rruullee tteessttiinngg
|
||||
|
||||
Postfix has several features that aid in SMTP access rule testing:
|
||||
|
||||
soft_bounce
|
||||
This is a safety net that changes SMTP server REJECT actions into DEFER
|
||||
(try again later) actions. This keeps mail queued that would otherwise be
|
||||
returned to the sender. Specify "soft_bounce = yes" in the main.cf file to
|
||||
prevent the Postfix SMTP server from rejecting mail permanently, by
|
||||
changing all 5xx SMTP reply codes into 4xx.
|
||||
|
||||
warn_if_reject
|
||||
When placed before a reject-type restriction, access table query, or
|
||||
check_policy_service query, this logs a "reject_warning" message instead of
|
||||
rejecting a request (when a reject-type restriction fails due to a
|
||||
temporary error, this logs a "reject_warning" message for any implicit
|
||||
"defer_if_permit" actions that would normally prevent mail from being
|
||||
accepted by some later access restriction). This feature has no effect on
|
||||
defer_if_reject restrictions.
|
||||
|
||||
XCLIENT
|
||||
With this feature, an authorized SMTP client can impersonate other systems
|
||||
and perform realistic SMTP access rule tests. Examples of how to
|
||||
impersonate other systems for access rule testing are given at the end of
|
||||
the XCLIENT_README document.
|
||||
This feature is available in Postfix 2.1.
|
||||
|
||||
651
README_FILES/SMTPD_POLICY_README
Normal file
651
README_FILES/SMTPD_POLICY_README
Normal file
|
|
@ -0,0 +1,651 @@
|
|||
PPoossttffiixx SSMMTTPP AAcccceessss PPoolliiccyy DDeelleeggaattiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff PPoossttffiixx SSMMTTPP aacccceessss ppoolliiccyy ddeelleeggaattiioonn
|
||||
|
||||
The Postfix SMTP server has a number of built-in mechanisms to block or accept
|
||||
mail at specific SMTP protocol stages. In addition, the Postfix SMTP server can
|
||||
delegate decisions to an external policy server (Postfix 2.1 and later).
|
||||
|
||||
With this policy delegation mechanism, a simple greylist policy can be
|
||||
implemented with only a dozen lines of Perl, as is shown at the end of this
|
||||
document. A complete example can be found in the Postfix source code, in the
|
||||
directory examples/smtpd-policy.
|
||||
|
||||
Another example of policy delegation is the SPF policy server at http://
|
||||
www.open-spf.org/Software/
|
||||
|
||||
Policy delegation is now the preferred method for adding policies to Postfix.
|
||||
It's much easier to develop a new feature in few lines of Perl, Python, Ruby,
|
||||
or TCL, than trying to do the same in C code. The difference in performance
|
||||
will be unnoticeable except in the most demanding environments. On active
|
||||
systems a policy daemon process is used multiple times, for up to $max_use
|
||||
incoming SMTP connections.
|
||||
|
||||
This document covers the following topics:
|
||||
|
||||
* Policy protocol description
|
||||
* Simple policy client/server configuration
|
||||
* Advanced policy client configuration
|
||||
* Example: greylist policy server
|
||||
* Greylisting mail from frequently forged domains
|
||||
* Greylisting all your mail
|
||||
* Routine greylist maintenance
|
||||
* Example Perl greylist server
|
||||
|
||||
PPrroottooccooll ddeessccrriippttiioonn
|
||||
|
||||
The Postfix policy delegation protocol is really simple. The client sends a
|
||||
request and the server sends a response. Unless there was an error, the server
|
||||
must not close the connection, so that the same connection can be used multiple
|
||||
times.
|
||||
|
||||
The client request is a sequence of name=value attributes separated by newline,
|
||||
and is terminated by an empty line. The server reply is one name=value
|
||||
attribute and it, too, is terminated by an empty line.
|
||||
|
||||
Here is an example of all the attributes that the Postfix SMTP server sends in
|
||||
a delegated SMTPD access policy request:
|
||||
|
||||
PPoossttffiixx vveerrssiioonn 22..11 aanndd llaatteerr::
|
||||
request=smtpd_access_policy
|
||||
protocol_state=RCPT
|
||||
protocol_name=SMTP
|
||||
helo_name=some.domain.tld
|
||||
queue_id=8045F2AB23
|
||||
sender=foo@bar.tld
|
||||
recipient=bar@foo.tld
|
||||
recipient_count=0
|
||||
client_address=1.2.3.4
|
||||
client_name=another.domain.tld
|
||||
reverse_client_name=another.domain.tld
|
||||
instance=123.456.7
|
||||
PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr::
|
||||
sasl_method=plain
|
||||
sasl_username=you
|
||||
sasl_sender=
|
||||
size=12345
|
||||
ccert_subject=solaris9.porcupine.org
|
||||
ccert_issuer=Wietse+20Venema
|
||||
ccert_fingerprint=C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
|
||||
PPoossttffiixx vveerrssiioonn 22..33 aanndd llaatteerr::
|
||||
encryption_protocol=TLSv1/SSLv3
|
||||
encryption_cipher=DHE-RSA-AES256-SHA
|
||||
encryption_keysize=256
|
||||
etrn_domain=
|
||||
PPoossttffiixx vveerrssiioonn 22..55 aanndd llaatteerr::
|
||||
stress=
|
||||
PPoossttffiixx vveerrssiioonn 22..99 aanndd llaatteerr::
|
||||
ccert_pubkey_fingerprint=68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40
|
||||
PPoossttffiixx vveerrssiioonn 33..00 aanndd llaatteerr::
|
||||
client_port=1234
|
||||
PPoossttffiixx vveerrssiioonn 33..11 aanndd llaatteerr::
|
||||
policy_context=submission
|
||||
PPoossttffiixx vveerrssiioonn 33..22 aanndd llaatteerr::
|
||||
server_address=10.3.2.1
|
||||
server_port=54321
|
||||
PPoossttffiixx vveerrssiioonn 33..88 aanndd llaatteerr::
|
||||
compatibility_level=major.minor.patch
|
||||
mail_version=3.8.0
|
||||
[empty line]
|
||||
|
||||
Notes:
|
||||
|
||||
* The "request" attribute is required. In this example the request type is
|
||||
"smtpd_access_policy".
|
||||
|
||||
* The order of the attributes does not matter. The policy server should
|
||||
ignore any attributes that it does not care about.
|
||||
|
||||
* When the same attribute name is sent more than once, the server may keep
|
||||
the first value or the last attribute value.
|
||||
|
||||
* When an attribute value is unavailable, the client either does not send the
|
||||
attribute, sends the attribute with an empty value ("name="), or sends a
|
||||
zero value ("name=0") in the case of a numerical attribute.
|
||||
|
||||
* The "recipient" attribute is available in the "RCPT TO" stage. It is also
|
||||
available in the "DATA" and "END-OF-MESSAGE" stages if Postfix accepted
|
||||
only one recipient for the current message. The DATA protocol state also
|
||||
applies to email that is received with BDAT commands (Postfix 3.4 and
|
||||
later).
|
||||
|
||||
* The "recipient_count" attribute (Postfix 2.3 and later) is non-zero only in
|
||||
the "DATA" and "END-OF-MESSAGE" stages. It specifies the number of
|
||||
recipients that Postfix accepted for the current message. The DATA protocol
|
||||
state also applies to email that is received with BDAT commands (Postfix
|
||||
3.4 and later).
|
||||
|
||||
* The remote client or local server IP address is an IPv4 dotted quad in the
|
||||
form 1.2.3.4 or it is an IPv6 address in the form 1:2:3::4:5:6.
|
||||
|
||||
* The remote client or local server port is a decimal number in the range 0-
|
||||
65535.
|
||||
|
||||
* For a discussion of the differences between reverse and verified
|
||||
client_name information, see the reject_unknown_client_hostname discussion
|
||||
in the postconf(5) document.
|
||||
|
||||
* An attribute name must not contain "=", null or newline, and an attribute
|
||||
value must not contain null or newline.
|
||||
|
||||
* The "instance" attribute value can be used to correlate different requests
|
||||
regarding the same message delivery. These requests are sent over the same
|
||||
policy connection (unless the policy daemon terminates the connection).
|
||||
Once Postfix sends a query with a different instance attribute over that
|
||||
same policy connection, the previous message delivery is either completed
|
||||
or aborted.
|
||||
|
||||
* The "size" attribute value specifies the message size that the client
|
||||
specified in the MAIL FROM command (zero if none was specified). With
|
||||
Postfix 2.2 and later, it specifies the actual message size after the
|
||||
client sends the END-OF-MESSAGE.
|
||||
|
||||
* The "sasl_*" attributes (Postfix 2.2 and later) specify information about
|
||||
how the client was authenticated via SASL. These attributes are empty in
|
||||
case of no SASL authentication.
|
||||
|
||||
* The "ccert_*" attributes (Postfix 2.2 and later) specify information about
|
||||
how the client was authenticated via TLS. These attributes are empty in
|
||||
case of no certificate authentication. As of Postfix 2.2.11 these attribute
|
||||
values are encoded as xtext: some characters are represented by +XX, where
|
||||
XX is the two-digit hexadecimal representation of the character value. With
|
||||
Postfix 2.6 and later, the decoded string is an UTF-8 string without non-
|
||||
printable ASCII characters.
|
||||
|
||||
* The "encryption_*" attributes (Postfix 2.3 and later) specify information
|
||||
about how the connection is encrypted. With plaintext connections the
|
||||
protocol and cipher attributes are empty and the keysize is zero.
|
||||
|
||||
* The "etrn_domain" attribute is defined only in the context of the ETRN
|
||||
command, and specifies the ETRN command parameter.
|
||||
|
||||
* The "stress" attribute is either empty or "yes". See the STRESS_README
|
||||
document for further information.
|
||||
|
||||
* The "policy_context" attribute provides a way to pass information that is
|
||||
not available via other attributes (Postfix version 3.1 and later).
|
||||
|
||||
* The "compatibility_level" attribute corresponds to the compatibility_level
|
||||
parameter value. It has the form major.minor.patch where minor and patch
|
||||
may be absent.
|
||||
|
||||
* The "mail_version" attribute corresponds to the mail_version parameter
|
||||
value. It has the form major.minor.patch for stable releases, and
|
||||
major.minor-yyyymmdd for unstable releases.
|
||||
|
||||
The following is specific to SMTPD delegated policy requests:
|
||||
|
||||
* Protocol names are ESMTP or SMTP.
|
||||
|
||||
* Protocol states are CONNECT, EHLO, HELO, MAIL, RCPT, DATA, END-OF-MESSAGE,
|
||||
VRFY or ETRN; these are the SMTP protocol states where the Postfix SMTP
|
||||
server makes an OK/REJECT/HOLD/etc. decision. The DATA protocol state also
|
||||
applies to email that is received with BDAT commands (Postfix 3.4 and
|
||||
later).
|
||||
|
||||
The policy server replies with any action that is allowed in a Postfix SMTPD
|
||||
access(5) table. Example:
|
||||
|
||||
action=defer_if_permit Service temporarily unavailable
|
||||
[empty line]
|
||||
|
||||
This causes the Postfix SMTP server to reject the request with a 450 temporary
|
||||
error code and with text "Service temporarily unavailable", if the Postfix SMTP
|
||||
server finds no reason to reject the request permanently.
|
||||
|
||||
In case of trouble the policy server must not send a reply. Instead the server
|
||||
must log a warning and disconnect. Postfix will retry the request at some later
|
||||
time.
|
||||
|
||||
SSiimmppllee ppoolliiccyy cclliieenntt//sseerrvveerr ccoonnffiigguurraattiioonn
|
||||
|
||||
The Postfix delegated policy client can connect to a TCP socket or to a UNIX-
|
||||
domain socket. Examples:
|
||||
|
||||
inet:127.0.0.1:9998
|
||||
unix:/some/where/policy
|
||||
unix:private/policy
|
||||
|
||||
The first example specifies that the policy server listens on a TCP socket at
|
||||
127.0.0.1 port 9998. The second example specifies an absolute pathname of a
|
||||
UNIX-domain socket. The third example specifies a pathname relative to the
|
||||
Postfix queue directory; use this for policy servers that are spawned by the
|
||||
Postfix master daemon. On many systems, "local" is a synonym for "unix".
|
||||
|
||||
To create a policy service that listens on a UNIX-domain socket called
|
||||
"policy", and that runs under control of the Postfix spawn(8) daemon, you would
|
||||
use something like this:
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 policy unix - n n - 0 spawn
|
||||
3 user=nobody argv=/some/where/policy-server
|
||||
4
|
||||
5 /etc/postfix/main.cf:
|
||||
6 smtpd_recipient_restrictions =
|
||||
7 ...
|
||||
8 reject_unauth_destination
|
||||
9 check_policy_service unix:private/policy
|
||||
10 ...
|
||||
11 policy_time_limit = 3600
|
||||
12 # smtpd_policy_service_request_limit = 1
|
||||
|
||||
NOTES:
|
||||
|
||||
* Lines 2-3: this creates the service called "policy" that listens on a UNIX-
|
||||
domain socket. The service is implemented by the Postfix spawn(8) daemon,
|
||||
which executes the policy server program that is specified with the aarrggvv
|
||||
attribute, using the privileges specified with the uusseerr attribute.
|
||||
|
||||
* Line 2: specify a "0" process limit instead of the default "-", to avoid
|
||||
"connection refused" and other problems when you increase the smtpd process
|
||||
limit.
|
||||
|
||||
* Line 8: reject_unauth_destination is not needed here if the mail relay
|
||||
policy is specified with smtpd_relay_restrictions (available with Postfix
|
||||
2.10 and later).
|
||||
|
||||
* Lines 8, 9: always specify "check_policy_service" AFTER
|
||||
"reject_unauth_destination" or else your system could become an open relay.
|
||||
|
||||
* Line 11: this increases the time that a policy server process may run to
|
||||
3600 seconds. The default time limit of 1000 seconds is too short; the
|
||||
policy daemon needs to run as long as the SMTP server process that talks to
|
||||
it. See the spawn(8) manpage for more information about the
|
||||
transport_time_limit parameter.
|
||||
|
||||
Note: the "policy_time_limit" parameter will not show up in "postconf"
|
||||
command output before Postfix version 2.9. This limitation applies to
|
||||
many parameters whose name is a combination of a master.cf service name
|
||||
(in the above example, "policy") and a built-in suffix (in the above
|
||||
example: "_time_limit").
|
||||
|
||||
* Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
|
||||
delays with policy servers that cannot maintain a persistent connection.
|
||||
|
||||
* With Solaris < 9, or Postfix < 2.10 on any Solaris version, use TCP sockets
|
||||
instead of UNIX-domain sockets:
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 127.0.0.1:9998 inet n n n - 0 spawn
|
||||
3 user=nobody argv=/some/where/policy-server
|
||||
4
|
||||
5 /etc/postfix/main.cf:
|
||||
6 smtpd_recipient_restrictions =
|
||||
7 ...
|
||||
8 reject_unauth_destination
|
||||
9 check_policy_service inet:127.0.0.1:9998
|
||||
10 ...
|
||||
11 127.0.0.1:9998_time_limit = 3600
|
||||
12 # smtpd_policy_service_request_limit = 1
|
||||
|
||||
Configuration parameters that control the client side of the policy delegation
|
||||
protocol:
|
||||
|
||||
* smtpd_policy_service_default_action (default: 451 4.3.5 Server
|
||||
configuration problem): The default action when an SMTPD policy service
|
||||
request fails. Available with Postfix 3.0 and later.
|
||||
|
||||
* smtpd_policy_service_max_idle (default: 300s): The amount of time before
|
||||
the Postfix SMTP server closes an unused policy client connection.
|
||||
|
||||
* smtpd_policy_service_max_ttl (default: 1000s): The amount of time before
|
||||
the Postfix SMTP server closes an active policy client connection.
|
||||
|
||||
* smtpd_policy_service_request_limit (default: 0): The maximal number of
|
||||
requests per policy connection, or zero (no limit). Available with Postfix
|
||||
3.0 and later.
|
||||
|
||||
* smtpd_policy_service_timeout (default: 100s): The time limit to connect to,
|
||||
send to or receive from a policy server.
|
||||
|
||||
* smtpd_policy_service_try_limit (default: 2): The maximal number of attempts
|
||||
to send an SMTPD policy service request before giving up. Available with
|
||||
Postfix 3.0 and later.
|
||||
|
||||
* smtpd_policy_service_retry_delay (default: 1s): The delay between attempts
|
||||
to resend a failed SMTPD policy service request. Available with Postfix 3.0
|
||||
and later.
|
||||
|
||||
* smtpd_policy_service_policy_context (default: empty): Optional information
|
||||
that is passed in the "policy_context" attribute of an SMTPD policy service
|
||||
request (originally, to share the same SMTPD service endpoint among
|
||||
multiple check_policy_service clients). Available with Postfix 3.1 and
|
||||
later.
|
||||
|
||||
Configuration parameters that control the server side of the policy delegation
|
||||
protocol:
|
||||
|
||||
* transport_time_limit ($command_time_limit): The maximal amount of time the
|
||||
policy daemon is allowed to run before it is terminated. The transport is
|
||||
the service name of the master.cf entry for the policy daemon service. In
|
||||
the above examples, the service name is "policy" or "127.0.0.1:9998".
|
||||
|
||||
AAddvvaanncceedd ppoolliiccyy cclliieenntt ccoonnffiigguurraattiioonn
|
||||
|
||||
The previous section lists a number of Postfix main.cf parameters that control
|
||||
time limits and other settings for all policy clients. This is sufficient for
|
||||
simple configurations. With more complex configurations it becomes desirable to
|
||||
have different settings per policy client. This is supported with Postfix 3.0
|
||||
and later.
|
||||
|
||||
The following example shows a "non-critical" policy service with a short
|
||||
timeout, and with "DUNNO" as default action when the service is unvailable. The
|
||||
"DUNNO" action causes Postfix to ignore the result.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 mua_recipient_restrictions =
|
||||
3 ...
|
||||
4 reject_unauth_destination
|
||||
5 check_policy_service { inet:host:port,
|
||||
6 timeout=10s, default_action=DUNNO
|
||||
7 policy_context=submission }
|
||||
8 ...
|
||||
|
||||
Instead of a server endpoint, we now have a list enclosed in {}.
|
||||
|
||||
* Line 5: The first item in the list is the server endpoint. This supports
|
||||
the exact same "inet" and "unix" syntax as described earlier.
|
||||
|
||||
* Line 6-7: The remainder of the list contains per-client settings. These
|
||||
settings override global main.cf parameters, and have the same name as
|
||||
those parameters, without the "smtpd_policy_service_" prefix.
|
||||
|
||||
Inside the list, syntax is similar to what we already know from main.cf: items
|
||||
separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
|
||||
sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
|
||||
ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd ""=="". This comes in handy when different policy
|
||||
servers require different default actions with different SMTP status codes or
|
||||
text:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_recipient_restrictions =
|
||||
3 ...
|
||||
4 reject_unauth_destination
|
||||
5 check_policy_service {
|
||||
6 inet:host:port1,
|
||||
7 { default_action = 451 4.3.5 See https://www.example.com/
|
||||
support1 }
|
||||
8 }
|
||||
9 ...
|
||||
|
||||
EExxaammppllee:: ggrreeyylliisstt ppoolliiccyy sseerrvveerr
|
||||
|
||||
Greylisting is a defense against junk email that is described at https://
|
||||
www.greylisting.org/. The idea was discussed on the postfix-users mailing list
|
||||
one year before it was popularized (alternative version).
|
||||
|
||||
The file examples/smtpd-policy/greylist.pl in the Postfix source tree
|
||||
implements a simplified greylist policy server. This server stores a time stamp
|
||||
for every (client, sender, recipient) triple. By default, mail is not accepted
|
||||
until a time stamp is more than 60 seconds old. This stops junk mail with
|
||||
randomly selected sender addresses, and mail that is sent through randomly
|
||||
selected open proxies. It also stops junk mail from spammers that change their
|
||||
IP address frequently.
|
||||
|
||||
Copy examples/smtpd-policy/greylist.pl to /usr/libexec/postfix or whatever
|
||||
location is appropriate for your system.
|
||||
|
||||
In the greylist.pl Perl script you need to specify the location of the greylist
|
||||
database file, and how long mail will be delayed before it is accepted. The
|
||||
default settings are:
|
||||
|
||||
$database_name="/var/mta/greylist.db";
|
||||
$greylist_delay=60;
|
||||
|
||||
The /var/mta directory (or whatever you choose) should be writable by "nobody",
|
||||
or by whatever username you configure below in master.cf for the policy
|
||||
service.
|
||||
|
||||
Example:
|
||||
|
||||
# mkdir /var/mta
|
||||
# chown nobody /var/mta
|
||||
|
||||
Note: DO NOT create the greylist database in a world-writable directory such as
|
||||
/tmp or /var/tmp, and DO NOT create the greylist database in a file system that
|
||||
may run out of space. Postfix can survive "out of space" conditions with the
|
||||
mail queue and with the mailbox store, but it cannot survive a corrupted
|
||||
greylist database. If the file becomes corrupted you may not be able to receive
|
||||
mail at all until you delete the file by hand.
|
||||
|
||||
The greylist.pl Perl script can be run under control by the Postfix master
|
||||
daemon. For example, to run the script as user "nobody", using a UNIX-domain
|
||||
socket that is accessible by Postfix processes only:
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 greylist unix - n n - 0 spawn
|
||||
3 user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
|
||||
4
|
||||
5 /etc/postfix/main.cf:
|
||||
6 greylist_time_limit = 3600
|
||||
7 smtpd_recipient_restrictions =
|
||||
8 ...
|
||||
9 reject_unauth_destination
|
||||
10 check_policy_service unix:private/greylist
|
||||
11 ...
|
||||
12 # smtpd_policy_service_request_limit = 1
|
||||
|
||||
Notes:
|
||||
|
||||
* Lines 2-3: this creates the service called "greylist" that listens on a
|
||||
UNIX-domain socket. The service is implemented by the Postfix spawn(8)
|
||||
daemon, which executes the greylist.pl script that is specified with the
|
||||
aarrggvv attribute, using the privileges specified with the uusseerr attribute.
|
||||
|
||||
* Line 2: specify a "0" process limit instead of the default "-", to avoid
|
||||
"connection refused" and other problems when you increase the smtpd process
|
||||
limit.
|
||||
|
||||
* Line 3: Specify "greylist.pl -v" for verbose logging of each request and
|
||||
reply.
|
||||
|
||||
* Line 6: this increases the time that a greylist server process may run to
|
||||
3600 seconds. The default time limit of 1000 seconds is too short; the
|
||||
greylist daemon needs to run as long as the SMTP server process that talks
|
||||
to it. See the spawn(8) manpage for more information about the
|
||||
transport_time_limit parameter.
|
||||
|
||||
* Line 9: reject_unauth_destination is not needed here if the mail relay
|
||||
policy is specified with smtpd_relay_restrictions (available with Postfix
|
||||
2.10 and later).
|
||||
|
||||
Note: the "greylist_time_limit" parameter will not show up in
|
||||
"postconf" command output before Postfix version 2.9. This limitation
|
||||
applies to many parameters whose name is a combination of a master.cf
|
||||
service name (in the above example, "greylist") and a built-in suffix
|
||||
(in the above example: "_time_limit").
|
||||
|
||||
* Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
|
||||
delays with policy servers that cannot maintain a persistent connection.
|
||||
|
||||
With Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet: style
|
||||
sockets instead of unix: style, as detailed in the "Policy client/server
|
||||
configuration" section above.
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 127.0.0.1:9998 inet n n n - 0 spawn
|
||||
3 user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
|
||||
4
|
||||
5 /etc/postfix/main.cf:
|
||||
6 127.0.0.1:9998_time_limit = 3600
|
||||
7 smtpd_recipient_restrictions =
|
||||
8 ...
|
||||
9 reject_unauth_destination
|
||||
10 check_policy_service inet:127.0.0.1:9998
|
||||
11 ...
|
||||
12 # smtpd_policy_service_request_limit = 1
|
||||
|
||||
GGrreeyylliissttiinngg mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
|
||||
|
||||
It is relatively safe to turn on greylisting for specific domains that often
|
||||
appear in forged email. At some point in cyberspace/time a list of frequently
|
||||
forged MAIL FROM domains could be found at https://web.archive.org/web/
|
||||
20080526153208/http://www.monkeys.com/anti-spam/filtering/sender-domain-
|
||||
validate.in.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_recipient_restrictions =
|
||||
3 reject_unlisted_recipient
|
||||
4 ...
|
||||
5 reject_unauth_destination
|
||||
6 check_sender_access hash:/etc/postfix/sender_access
|
||||
7 ...
|
||||
8 smtpd_restriction_classes = greylist
|
||||
9 greylist = check_policy_service unix:private/greylist
|
||||
10
|
||||
11 /etc/postfix/sender_access:
|
||||
12 aol.com greylist
|
||||
13 hotmail.com greylist
|
||||
14 bigfoot.com greylist
|
||||
15 ... etcetera ...
|
||||
|
||||
NOTES:
|
||||
|
||||
* Line 9: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
|
||||
style sockets instead of unix: style, as detailed in the "Example: greylist
|
||||
policy server" section above.
|
||||
|
||||
* Line 5: reject_unauth_destination is not needed here if the mail relay
|
||||
policy is specified with smtpd_relay_restrictions (available with Postfix
|
||||
2.10 and later).
|
||||
|
||||
* Line 6: Be sure to specify "check_sender_access" AFTER
|
||||
"reject_unauth_destination" or else your system could become an open mail
|
||||
relay.
|
||||
|
||||
* Line 3: With Postfix 2.0 snapshot releases, "reject_unlisted_recipient" is
|
||||
called "check_recipient_maps". Postfix 2.1 understands both forms.
|
||||
|
||||
* Line 3: The greylist database gets polluted quickly with bogus addresses.
|
||||
It helps if you protect greylist lookups with other restrictions that
|
||||
reject unknown senders and/or recipients.
|
||||
|
||||
GGrreeyylliissttiinngg aallll yyoouurr mmaaiill
|
||||
|
||||
If you turn on greylisting for all mail you may want to make exceptions for
|
||||
mailing lists that use one-time sender addresses, because each message will be
|
||||
delayed due to greylisting, and the one-time sender addresses can pollute your
|
||||
greylist database relatively quickly. Instead of making exceptions, you can
|
||||
automatically allowlist clients that survive greylisting repeatedly; this
|
||||
avoids most of the delays and most of the database pollution problem.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_recipient_restrictions =
|
||||
3 reject_unlisted_recipient
|
||||
4 ...
|
||||
5 reject_unauth_destination
|
||||
6 check_sender_access hash:/etc/postfix/sender_access
|
||||
7 check_policy_service unix:private/policy
|
||||
8 ...
|
||||
9
|
||||
10 /etc/postfix/sender_access:
|
||||
11 securityfocus.com OK
|
||||
12 ...
|
||||
|
||||
NOTES:
|
||||
|
||||
* Line 7: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
|
||||
style sockets instead of unix: style, as detailed in the "Example: greylist
|
||||
policy server" section above.
|
||||
|
||||
* Line 5: reject_unauth_destination is not needed here if the mail relay
|
||||
policy is specified with smtpd_relay_restrictions (available with Postfix
|
||||
2.10 and later).
|
||||
|
||||
* Lines 6-7: Be sure to specify check_sender_access and check_policy_service
|
||||
AFTER reject_unauth_destination or else your system could become an open
|
||||
mail relay.
|
||||
|
||||
* Line 3: The greylist database gets polluted quickly with bogus addresses.
|
||||
It helps if you precede greylist lookups with restrictions that reject
|
||||
unknown senders and/or recipients.
|
||||
|
||||
RRoouuttiinnee ggrreeyylliisstt mmaaiinntteennaannccee
|
||||
|
||||
The greylist database grows over time, because the greylist server never
|
||||
removes database entries. If left unattended, the greylist database will
|
||||
eventually run your file system out of space.
|
||||
|
||||
When the status file size exceeds some threshold you can simply rename or
|
||||
remove the file without adverse effects; Postfix automatically creates a new
|
||||
file. In the worst case, new mail will be delayed by an hour or so. To lessen
|
||||
the impact, rename or remove the file in the middle of the night at the
|
||||
beginning of a weekend.
|
||||
|
||||
EExxaammppllee PPeerrll ggrreeyylliisstt sseerrvveerr
|
||||
|
||||
This is the Perl subroutine that implements the example greylist policy. It is
|
||||
part of a general purpose sample policy server that is distributed with the
|
||||
Postfix source as examples/smtpd-policy/greylist.pl.
|
||||
|
||||
#
|
||||
# greylist status database and greylist time interval. DO NOT create the
|
||||
# greylist status database in a world-writable directory such as /tmp
|
||||
# or /var/tmp. DO NOT create the greylist database in a file system
|
||||
# that can run out of space.
|
||||
#
|
||||
$database_name="/var/mta/greylist.db";
|
||||
$greylist_delay=60;
|
||||
|
||||
#
|
||||
# Auto-allowlist threshold. Specify 0 to disable, or the number of
|
||||
# successful "come backs" after which a client is no longer subject
|
||||
# to greylisting.
|
||||
#
|
||||
$auto_allowlist_threshold = 10;
|
||||
|
||||
#
|
||||
# Demo SMTPD access policy routine. The result is an action just like
|
||||
# it would be specified on the right-hand side of a Postfix access
|
||||
# table. Request attributes are available via the %attr hash.
|
||||
#
|
||||
sub smtpd_access_policy {
|
||||
my($key, $time_stamp, $now);
|
||||
|
||||
# Open the database on the fly.
|
||||
open_database() unless $database_obj;
|
||||
|
||||
# Search the auto-allowlist.
|
||||
if ($auto_allowlist_threshold > 0) {
|
||||
$count = read_database($attr{"client_address"});
|
||||
if ($count > $auto_allowlist_threshold) {
|
||||
return "dunno";
|
||||
}
|
||||
}
|
||||
|
||||
# Lookup the time stamp for this client/sender/recipient.
|
||||
$key =
|
||||
lc $attr{"client_address"}."/".$attr{"sender"}."/".$attr{"recipient"};
|
||||
$time_stamp = read_database($key);
|
||||
$now = time();
|
||||
|
||||
# If new request, add this client/sender/recipient to the database.
|
||||
if ($time_stamp == 0) {
|
||||
$time_stamp = $now;
|
||||
update_database($key, $time_stamp);
|
||||
}
|
||||
|
||||
# The result can be any action that is allowed in a Postfix access(5) map.
|
||||
#
|
||||
# To label the mail, return ``PREPEND headername: headertext''
|
||||
#
|
||||
# In case of success, return ``DUNNO'' instead of ``OK'', so that the
|
||||
# check_policy_service restriction can be followed by other restrictions.
|
||||
#
|
||||
# In case of failure, return ``DEFER_IF_PERMIT optional text...'',
|
||||
# so that mail can still be blocked by other access restrictions.
|
||||
#
|
||||
syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
|
||||
if ($now - $time_stamp > $greylist_delay) {
|
||||
# Update the auto-allowlist.
|
||||
if ($auto_allowlist_threshold > 0) {
|
||||
update_database($attr{"client_address"}, $count + 1);
|
||||
}
|
||||
return "dunno";
|
||||
} else {
|
||||
return "defer_if_permit Service temporarily unavailable";
|
||||
}
|
||||
}
|
||||
|
||||
263
README_FILES/SMTPD_PROXY_README
Normal file
263
README_FILES/SMTPD_PROXY_README
Normal file
|
|
@ -0,0 +1,263 @@
|
|||
PPoossttffiixx BBeeffoorree--QQuueeuuee CCoonntteenntt FFiilltteerr
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
WWAARRNNIINNGG
|
||||
|
||||
The before-queue content filtering feature described in this document limits
|
||||
the amount of mail that a site can handle. See the "Pros and Cons" section
|
||||
below for details.
|
||||
|
||||
TThhee PPoossttffiixx bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr ffeeaattuurree
|
||||
|
||||
As of version 2.1, the Postfix SMTP server can forward all incoming mail to a
|
||||
content filtering proxy server that inspects all mail BEFORE it is stored in
|
||||
the Postfix mail queue. It is roughly equivalent in capabilities to the
|
||||
approach described in MILTER_README, except that the latter uses a dedicated
|
||||
protocol instead of SMTP.
|
||||
|
||||
The before-queue content filter is meant to be used as follows:
|
||||
|
||||
Postfix BBeeffoorree Postfix Postfix Postfix smtp
|
||||
Internet -> SMTP -> qquueeuuee -> SMTP -> cleanup -> queue -< local
|
||||
server ffiilltteerr server server virtual
|
||||
|
||||
The before-queue content filter is not to be confused with the approach
|
||||
described in the FILTER_README document, where mail is filtered AFTER it is
|
||||
stored in the Postfix mail queue.
|
||||
|
||||
This document describes the following topics:
|
||||
|
||||
* Principles of operation
|
||||
* Pros and cons of before-queue content filtering
|
||||
* Configuring the Postfix SMTP pass-through proxy feature
|
||||
* Configuration parameters
|
||||
* How Postfix talks to the before-queue content filter
|
||||
|
||||
PPrriinncciipplleess ooff ooppeerraattiioonn
|
||||
|
||||
As shown in the diagram above, the before-queue filter sits between two Postfix
|
||||
SMTP server processes.
|
||||
|
||||
* The before-filter Postfix SMTP server accepts connections from the Internet
|
||||
and does the usual relay access control, SASL authentication, TLS
|
||||
negotiation, RBL lookups, rejecting non-existent sender or recipient
|
||||
addresses, etc.
|
||||
|
||||
* The before-queue filter receives unfiltered mail content from Postfix and
|
||||
does one of the following:
|
||||
|
||||
1. Re-inject the mail back into Postfix via SMTP, perhaps after changing
|
||||
its content and/or destination.
|
||||
|
||||
2. Discard or quarantine the mail.
|
||||
|
||||
3. Reject the mail by sending a suitable SMTP status code back to Postfix.
|
||||
Postfix passes the status back to the remote SMTP client. This way,
|
||||
Postfix does not have to send a bounce message.
|
||||
|
||||
* The after-filter Postfix SMTP server receives mail from the content filter.
|
||||
From then on Postfix processes the mail as usual.
|
||||
|
||||
The before-queue content filter described here works just like the after-queue
|
||||
content filter described in the FILTER_README document. In many cases you can
|
||||
use the same software, within the limitations as discussed in the "Pros and
|
||||
Cons" section below.
|
||||
|
||||
PPrrooss aanndd ccoonnss ooff bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerriinngg
|
||||
|
||||
* Pro: Postfix can reject mail before the incoming SMTP mail transfer
|
||||
completes, so that Postfix does not have to send rejected mail back to the
|
||||
sender (which is usually forged anyway). Mail that is not accepted remains
|
||||
the responsibility of the remote SMTP client.
|
||||
|
||||
* Con: The smtpd(8) service before the smtpd_proxy_filter cannot support
|
||||
features that involve header or body access, or that involve queue file
|
||||
manipulation (i.e., anything that involves processing by the cleanup(8)
|
||||
service).
|
||||
|
||||
o No support for HOLD actions in Postfix smtpd access(5) restrictions.
|
||||
|
||||
o No support for smtpd_milters features that involve message header or
|
||||
body content.
|
||||
|
||||
o No support for receive_override_options.
|
||||
|
||||
Instead, specify those features with the smtpd(8) service behind the
|
||||
smtpd_proxy_filter. In some cases, it may be possible to combine a before-
|
||||
filter PREPEND action that emits a unique pattern (for example containing
|
||||
the MTA domain name), with an after-filter header_checks action that does
|
||||
what you want, and with an smtp_header_checks IGNORE action that deletes
|
||||
the prepended header from transit mail.
|
||||
|
||||
* Con: The remote SMTP client expects an SMTP reply within a deadline. As the
|
||||
system load increases, fewer and fewer CPU cycles remain available to
|
||||
answer within the deadline, and eventually you either have to stop
|
||||
accepting mail or you have to stop filtering mail. It is for this reason
|
||||
that the before-queue content filter limits the amount of mail that a site
|
||||
can handle.
|
||||
|
||||
* Con: Content filtering software can use lots of memory resources. You have
|
||||
to reduce the number of simultaneous content filter processes so that a
|
||||
burst of mail will not drive your system into the ground.
|
||||
|
||||
o With Postfix versions 2.7 and later, SMTP clients will experience an
|
||||
increase in the delay between the time the client sends "end-of-
|
||||
message" and the time the Postfix SMTP server replies (here, the number
|
||||
of before-filter SMTP server processes can be larger than the number of
|
||||
filter processes).
|
||||
|
||||
o With Postfix versions before 2.7, SMTP clients will experience an
|
||||
increase in the delay before they can receive service (here, the number
|
||||
of before-filter SMTP server processes is always equal to the number of
|
||||
filter processes).
|
||||
|
||||
CCoonnffiigguurriinngg tthhee PPoossttffiixx SSMMTTPP ppaassss--tthhrroouugghh pprrooxxyy ffeeaattuurree
|
||||
|
||||
In the following example, the before-filter Postfix SMTP server gives mail to a
|
||||
content filter that listens on localhost port 10025. The after-filter Postfix
|
||||
SMTP server receives mail from the content filter via localhost port 10026.
|
||||
From then on mail is processed as usual.
|
||||
|
||||
The content filter itself is not described here. You can use any filter that is
|
||||
SMTP enabled. For non-SMTP capable content filtering software, Bennett Todd's
|
||||
SMTP proxy implements a nice Perl-based framework. See: https://
|
||||
web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/ or https:/
|
||||
/github.com/jnorell/smtpprox/
|
||||
|
||||
Postfix
|
||||
Postfix filter on SMTP server Postfix Postfix
|
||||
Internet -> SMTP server -> localhost -> on -> cleanup -> incoming
|
||||
on port 25 port 10025 localhost server queue
|
||||
port 10026
|
||||
|
||||
This is configured by editing the master.cf file:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
#
|
||||
# Before-filter SMTP server. Receive mail from the network and
|
||||
# pass it to the content filter on localhost port 10025.
|
||||
#
|
||||
smtp inet n - n - 20 smtpd
|
||||
-o smtpd_proxy_filter=127.0.0.1:10025
|
||||
-o smtpd_client_connection_count_limit=10
|
||||
# Postfix 2.7 and later performance feature.
|
||||
# -o smtpd_proxy_options=speed_adjust
|
||||
#
|
||||
# After-filter SMTP server. Receive mail from the content filter
|
||||
# on localhost port 10026.
|
||||
#
|
||||
127.0.0.1:10026 inet n - n - - smtpd
|
||||
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
|
||||
-o smtpd_client_restrictions=
|
||||
-o smtpd_helo_restrictions=
|
||||
-o smtpd_sender_restrictions=
|
||||
# Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
|
||||
-o smtpd_relay_restrictions=
|
||||
-o smtpd_recipient_restrictions=permit_mynetworks,reject
|
||||
-o smtpd_data_restrictions=
|
||||
-o mynetworks=127.0.0.0/8
|
||||
-o receive_override_options=no_unknown_recipient_checks
|
||||
|
||||
Note: do not specify spaces around the "=" or "," characters.
|
||||
|
||||
The before-filter SMTP server entry is a modified version of the default
|
||||
Postfix SMTP server entry that is normally configured at the top of the
|
||||
master.cf file:
|
||||
|
||||
* The number of SMTP sessions is reduced from the default 100 to only 20.
|
||||
This prevents a burst of mail from running your system into the ground with
|
||||
too many content filter processes.
|
||||
|
||||
* The "-o smtpd_client_connection_count_limit=10" prevents one SMTP client
|
||||
from using up all 20 SMTP server processes. This limit is not necessary if
|
||||
you receive all mail from a trusted relay host.
|
||||
|
||||
Note: this setting is available in Postfix version 2.2 and later. Earlier
|
||||
Postfix versions will ignore it.
|
||||
|
||||
* The "-o smtpd_proxy_filter=127.0.0.1:10025" tells the before-filter SMTP
|
||||
server that it should give incoming mail to the content filter that listens
|
||||
on localhost TCP port 10025.
|
||||
|
||||
* The "-o smtpd_proxy_options=speed_adjust" tells the before-filter SMTP
|
||||
server that it should receive an entire email message before it connects to
|
||||
a content filter. This reduces the number of simultaneous filter processes.
|
||||
|
||||
NOTE 1: When this option is turned on, a content filter must not
|
||||
selectively reject recipients of a multi-recipient message. Rejecting all
|
||||
recipients is OK, as is accepting all recipients.
|
||||
|
||||
NOTE 2: This feature increases the minimum amount of free queue space by
|
||||
$message_size_limit. The extra space is needed to save the message to a
|
||||
temporary file.
|
||||
|
||||
* Postfix >= 2.3 supports both TCP and UNIX-domain filters. The above filter
|
||||
could be specified as "inet:127.0.0.1:10025". To specify a UNIX-domain
|
||||
filter, specify "unix:pathname". A relative pathname is interpreted
|
||||
relative to the Postfix queue directory.
|
||||
|
||||
The after-filter SMTP server is a new master.cf entry:
|
||||
|
||||
* The "127.0.0.1:10026" makes the after-filter SMTP server listen on the
|
||||
localhost address only, without exposing it to the network. NEVER expose
|
||||
the after-filter SMTP server to the Internet :-)
|
||||
|
||||
* The "-o smtpd_authorized_xforward_hosts=127.0.0.0/8" allows the after-
|
||||
filter SMTP server to receive remote SMTP client information from the
|
||||
before-filter SMTP server, so that the after-filter Postfix daemons log the
|
||||
remote SMTP client information instead of logging localhost[127.0.0.1].
|
||||
|
||||
* The other after-filter SMTP server settings avoid duplication of work that
|
||||
is already done in the "before filter" SMTP server.
|
||||
|
||||
By default, the filter has 100 seconds to do its work. If it takes longer then
|
||||
Postfix gives up and reports an error to the remote SMTP client. You can
|
||||
increase this time limit (see the "Configuration parameters" section below) but
|
||||
doing so is pointless because you can't control when the remote SMTP client
|
||||
times out.
|
||||
|
||||
CCoonnffiigguurraattiioonn ppaarraammeetteerrss
|
||||
|
||||
Parameters that control proxying:
|
||||
|
||||
* smtpd_proxy_filter (syntax: host:port): The host and TCP port of the
|
||||
before-queue content filter. When no host or host: is specified here,
|
||||
localhost is assumed.
|
||||
|
||||
* smtpd_proxy_timeout (default: 100s): Timeout for connecting to the before-
|
||||
queue content filter and for sending and receiving commands and data. All
|
||||
proxy errors are logged to the maillog file. For privacy reasons, all the
|
||||
remote SMTP client sees is "451 Error: queue file write error". It would
|
||||
not be right to disclose internal details to strangers.
|
||||
|
||||
* smtpd_proxy_ehlo (default: $myhostname): The hostname to use when sending
|
||||
an EHLO command to the before-queue content filter.
|
||||
|
||||
HHooww PPoossttffiixx ttaallkkss ttoo tthhee bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr
|
||||
|
||||
The before-filter Postfix SMTP server connects to the content filter, delivers
|
||||
one message, and disconnects. While sending mail into the content filter,
|
||||
Postfix speaks ESMTP but uses no command pipelining. Postfix generates its own
|
||||
EHLO, XFORWARD (for logging the remote client IP address instead of localhost
|
||||
[127.0.0.1]), DATA and QUIT commands, and forwards unmodified copies of all the
|
||||
MAIL FROM and RCPT TO commands that the before-filter Postfix SMTP server
|
||||
didn't reject itself. Postfix sends no other SMTP commands.
|
||||
|
||||
The content filter should accept the same MAIL FROM and RCPT TO command syntax
|
||||
as the before-filter Postfix SMTP server, and should forward the commands
|
||||
without modification to the after-filter SMTP server. If the content filter or
|
||||
after-filter SMTP server does not support all the ESMTP features that the
|
||||
before-filter Postfix SMTP server supports, then the missing features must be
|
||||
turned off in the before-filter Postfix SMTP server with the
|
||||
smtpd_discard_ehlo_keywords parameter.
|
||||
|
||||
When the filter rejects content, it should send a negative SMTP response back
|
||||
to the before-filter Postfix SMTP server, and it should abort the connection
|
||||
with the after-filter Postfix SMTP server without completing the SMTP
|
||||
conversation with the after-filter Postfix SMTP server.
|
||||
|
||||
294
README_FILES/SMTPUTF8_README
Normal file
294
README_FILES/SMTPUTF8_README
Normal file
|
|
@ -0,0 +1,294 @@
|
|||
PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document describes Postfix support for Email Address Internationalization
|
||||
(EAI) as defined in RFC 6531 (SMTPUTF8 extension), RFC 6532 (Internationalized
|
||||
email headers) and RFC 6533 (Internationalized delivery status notifications).
|
||||
Introduced with Postfix version 3.0, this fully supports UTF-8 email addresses
|
||||
and UTF-8 message header values.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Building with/without SMTPUTF8 support
|
||||
* Enabling Postfix SMTPUTF8 support
|
||||
* Using Postfix SMTPUTF8 support
|
||||
* SMTPUTF8 autodetection
|
||||
* Limitations of the current implementation
|
||||
* Compatibility with pre-SMTPUTF8 environments
|
||||
* Compatibility with IDNA2003
|
||||
* Credits
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh//wwiitthhoouutt SSMMTTPPUUTTFF88 ssuuppppoorrtt
|
||||
|
||||
Postfix will build with SMTPUTF8 support if the ICU version >= 46 library and
|
||||
header files are installed on the system. The package name varies with the OS
|
||||
distribution. The table shows package names for a number of platforms at the
|
||||
time this text was written.
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|OOSS DDiissttrriibbuuttiioonn |PPaacckkaaggee |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|FreeBSD, NetBSD, etc.|icu |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Centos, Fedora, RHEL |libicu-devel|
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|Debian, Ubuntu |libicu-dev |
|
||||
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
To force Postfix to build without SMTPUTF8, specify:
|
||||
|
||||
$ mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDNNOO__EEAAII ......""
|
||||
|
||||
See the INSTALL document for more "make makefiles" options.
|
||||
|
||||
EEnnaabblliinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
|
||||
|
||||
There is more to SMTPUTF8 than just Postfix itself. The rest of your email
|
||||
infrastructure also needs to be able to handle UTF-8 email addresses and
|
||||
message header values. This includes SMTPUTF8 protocol support in SMTP-based
|
||||
content filters (Amavisd), LMTP servers (Dovecot), and down-stream SMTP
|
||||
servers.
|
||||
|
||||
Postfix SMTPUTF8 support is enabled by default, but it may be disabled as part
|
||||
of a backwards-compatibility safety net (see the COMPATIBILITY_README file).
|
||||
|
||||
SMTPUTF8 support is enabled by setting the smtputf8_enable parameter in
|
||||
main.cf:
|
||||
|
||||
# ppoossttccoonnff ""ssmmttppuuttff88__eennaabbllee == yyeess""
|
||||
# ppoossttffiixx rreellooaadd
|
||||
|
||||
(With Postfix <= 3.1, you may also need to specify "ooppttiioonn__ggrroouupp == cclliieenntt" in
|
||||
Postfix MySQL client files, to enable UTF8 support in MySQL queries. This
|
||||
setting is the default as of Postfix 3.2.)
|
||||
|
||||
With SMTPUTF8 support enabled, Postfix changes behavior with respect to earlier
|
||||
Postfix releases:
|
||||
|
||||
* UTF-8 is permitted in the myorigin parameter value. However, the myhostname
|
||||
and mydomain parameters must currently specify ASCII-only domain names.
|
||||
This limitation may be removed later.
|
||||
|
||||
* UTF-8 is the only form of non-ASCII text that Postfix supports in access
|
||||
tables, address rewriting tables, and other tables that are indexed with an
|
||||
email address, hostname, or domain name.
|
||||
|
||||
* The header_checks-like and body_checks-like features are not UTF-8 enabled,
|
||||
and therefore they do not enforce UTF-8 syntax rules on inputs and outputs.
|
||||
The reason is that non-ASCII text may be sent in encodings other than UTF-
|
||||
8, and that real email sometimes contains malformed headers. Instead of
|
||||
skipping non-UTF-8 content, Postfix should be able to filter it. You may
|
||||
try to enable UTF-8 processing by starting a PCRE pattern with the sequence
|
||||
(*UTF8), but this is will result in "message not accepted, try again later"
|
||||
errors when the PCRE pattern matcher encounters non-UTF-8 input. Other
|
||||
features that are not UTF-8 enabled are smtpd_command_filter,
|
||||
smtp_reply_filter, the *_delivery_status_filter features, and the
|
||||
*_dns_reply_filter features (the latter because DNS is by definition an
|
||||
ASCII protocol).
|
||||
|
||||
* The Postfix SMTP server announces SMTPUTF8 support in the EHLO response.
|
||||
|
||||
220 server.example.com ESMTP Postfix
|
||||
EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
|
||||
250-server.example.com
|
||||
250-PIPELINING
|
||||
250-SIZE 10240000
|
||||
250-VRFY
|
||||
250-ETRN
|
||||
250-STARTTLS
|
||||
250-AUTH PLAIN LOGIN
|
||||
250-ENHANCEDSTATUSCODES
|
||||
250-8BITMIME
|
||||
250-DSN
|
||||
250 SMTPUTF8
|
||||
|
||||
* The Postfix SMTP server accepts the SMTPUTF8 request in MAIL FROM and VRFY
|
||||
commands.
|
||||
|
||||
MMAAIILL FFRROOMM::<<aaddddrreessss>> SSMMTTPPUUTTFF88 ......
|
||||
|
||||
VVRRFFYY aaddddrreessss SSMMTTPPUUTTFF88
|
||||
|
||||
* The Postfix SMTP client may issue the SMTPUTF8 request in MAIL FROM
|
||||
commands.
|
||||
|
||||
* The Postfix SMTP server accepts UTF-8 in email address domains, but only
|
||||
after the remote SMTP client issues the SMTPUTF8 request in MAIL FROM or
|
||||
VRFY commands.
|
||||
|
||||
Postfix already permitted UTF-8 in message header values and in address
|
||||
localparts. This does not change.
|
||||
|
||||
UUssiinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
|
||||
|
||||
After Postfix SMTPUTF8 support is turned on, Postfix behavior will depend on 1)
|
||||
whether a remote SMTP client requests SMTPUTF8 support, 2) the presence of UTF-
|
||||
8 content in the message envelope and headers, and 3) whether a down-stream
|
||||
SMTP (or LMTP) server announces SMTPUTF8 support.
|
||||
|
||||
* When the Postfix SMTP server receives a message WITHOUT the SMTPUTF8
|
||||
request, Postfix handles the message as it has always done (at least that
|
||||
is the default, see autodetection below). Specifically, the Postfix SMTP
|
||||
server does not accept UTF-8 in the envelope sender domain name or envelope
|
||||
recipient domain name, and the Postfix SMTP client does not issue the
|
||||
SMTPUTF8 request when delivering that message to an SMTP or LMTP server
|
||||
that announces SMTPUTF8 support (again, that is the default). Postfix will
|
||||
accept UTF-8 in message header values and in the localpart of envelope
|
||||
sender and recipient addresses, because it has always done that.
|
||||
|
||||
* When the Postfix SMTP server receives a message WITH the SMTPUTF8 request,
|
||||
Postfix will issue the SMTPUTF8 request when delivering that message to an
|
||||
SMTP or LMTP server that announces SMTPUTF8 support. This is not
|
||||
configurable.
|
||||
|
||||
* When a message is received with the SMTPUTF8 request, Postfix will deliver
|
||||
the message to a non-SMTPUTF8 SMTP or LMTP server ONLY if:
|
||||
|
||||
o No message header value contains UTF-8.
|
||||
|
||||
o The envelope sender address contains no UTF-8,
|
||||
|
||||
o No envelope recipient address for that specific SMTP/LMTP delivery
|
||||
transaction contains UTF-8.
|
||||
|
||||
NOTE: Recipients in other email delivery transactions for that same
|
||||
message may still contain UTF-8.
|
||||
|
||||
Otherwise, Postfix will return the recipient(s) for that email delivery
|
||||
transaction as undeliverable. The delivery status notification message will
|
||||
be an SMTPUTF8 message. It will therefore be subject to the same
|
||||
restrictions as email that is received with the SMTPUTF8 request.
|
||||
|
||||
* When the Postfix SMTP server receives a message with the SMTPUTF8 request,
|
||||
that request also applies after the message is forwarded via a virtual or
|
||||
local alias, or $HOME/.forward file.
|
||||
|
||||
SSMMTTPPUUTTFF88 aauuttooddeetteeccttiioonn
|
||||
|
||||
This section applies only to systems that have SMTPUTF8 support turned on
|
||||
(smtputf8_enable = yes).
|
||||
|
||||
For compatibility with pre-SMTPUTF8 environments, Postfix does not
|
||||
automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8
|
||||
clients that contain a UTF-8 header value or UTF-8 address localpart. This
|
||||
would make such messages undeliverable to non-SMTPUTF8 servers, and could be a
|
||||
barrier to SMTPUTF8 adoption.
|
||||
|
||||
By default, Postfix sets the "SMTPUTF8 requested" flag only on address
|
||||
verification probes and on Postfix sendmail submissions that contain UTF-8 in
|
||||
the sender address, UTF-8 in a recipient address, or UTF-8 in a message header
|
||||
value.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtputf8_autodetect_classes = sendmail, verify
|
||||
|
||||
However, if you have a non-ASCII myorigin or mydomain setting, or if you have a
|
||||
configuration that introduces UTF-8 addresses with virtual aliases, canonical
|
||||
mappings, or BCC mappings, then you may have to apply SMTPUTF8 autodetection to
|
||||
all email:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtputf8_autodetect_classes = all
|
||||
|
||||
This will, of course, also flag email that was received without SMTPUTF8
|
||||
request, but that contains UTF-8 in a sender address localpart, receiver
|
||||
address localpart, or message header value. Such email was not standards-
|
||||
compliant, but Postfix would have delivered it if SMTPUTF8 support was
|
||||
disabled.
|
||||
|
||||
LLiimmiittaattiioonnss ooff tthhee ccuurrrreenntt iimmpplleemmeennttaattiioonn
|
||||
|
||||
The Postfix implementation is a work in progress; limitations are steadily
|
||||
being removed. The text below describes the situation at one point in time.
|
||||
|
||||
NNoo aauuttoommaattiicc ccoonnvveerrssiioonnss bbeettwweeeenn AASSCCIIII aanndd UUTTFF--88 ddoommaaiinn nnaammeess..
|
||||
|
||||
Some background: According to RFC 6530 and related documents, an
|
||||
internationalized domain name can appear in two forms: the UTF-8 form, and the
|
||||
ASCII (xn--mumble) form. An internationalized address localpart must be encoded
|
||||
in UTF-8; the RFCs do not define an ASCII alternative form.
|
||||
|
||||
Postfix currently does not convert internationalized domain names from UTF-
|
||||
8 into ASCII (or from ASCII into UTF-8) before using domain names in SMTP
|
||||
commands and responses, before looking up domain names in lists such as
|
||||
mydestination, relay_domains or in lookup tables such as access tables, etc.,
|
||||
before using domain names in a policy daemon or Milter request, or before
|
||||
logging events.
|
||||
|
||||
Postfix does, however, casefold domain names and email addresses before
|
||||
matching them against a Postfix configuration parameter or lookup table.
|
||||
|
||||
In order to use Postfix SMTPUTF8 support:
|
||||
|
||||
* The Postfix parameters myhostname and mydomain must be in ASCII form. One
|
||||
is a substring of the other, and the myhostname value is used in SMTP
|
||||
commands and responses that require ASCII. The parameter myorigin (added to
|
||||
local addresses without domain) supports UTF-8.
|
||||
|
||||
* You need to configure both the ASCII and UTF-8 forms of an
|
||||
Internationalized domain name in Postfix parameters such as mydestination
|
||||
and relay_domains, as well as lookup table search keys.
|
||||
|
||||
* Milters, content filters, policy servers and logfile analysis tools need to
|
||||
be able to handle both the ASCII and UTF-8 forms of Internationalized
|
||||
domain names.
|
||||
|
||||
CCoommppaattiibbiilliittyy wwiitthh pprree--SSMMTTPPUUTTFF88 eennvviirroonnmmeennttss
|
||||
|
||||
MMaaiilliinngg lliissttss wwiitthh UUTTFF--88 aanndd nnoonn--UUTTFF--88 ssuubbssccrriibbeerrss
|
||||
|
||||
With Postfix, there is no need to split mailing lists into UTF-8 and non-UTF-
|
||||
8 members. Postfix will try to deliver the non-UTF8 subscribers over
|
||||
"traditional" non-SMTPUTF8 sessions, as long as the message has an ASCII
|
||||
envelope sender address and all-ASCII header values. The mailing list manager
|
||||
may have to apply RFC 2047 encoding to satisfy that last condition.
|
||||
|
||||
PPrree--eexxiissttiinngg nnoonn--AASSCCIIII eemmaaiill fflloowwss
|
||||
|
||||
With "smtputf8_enable = no", Postfix handles email with non-ASCII in address
|
||||
localparts (and in headers) as before. The vast majority of email software is
|
||||
perfectly capable of handling such email, even if pre-SMTPUTF8 standards do not
|
||||
support such practice.
|
||||
|
||||
RReejjeeccttiinngg nnoonn--UUTTFF88 aaddddrreesssseess
|
||||
|
||||
With "smtputf8_enable = yes", Postfix requires that non-ASCII address
|
||||
information is encoded in UTF-8 and will reject other encodings such as ISO-
|
||||
8859. It is not practical for Postfix to support multiple encodings at the same
|
||||
time. There is no problem with RFC 2047 encodings such as "=?ISO-8859-
|
||||
1?Q?text?=", because those use only characters from the ASCII characterset.
|
||||
|
||||
RReejjeeccttiinngg nnoonn--AASSCCIIII aaddddrreesssseess iinn nnoonn--SSMMTTPPUUTTFF88 ttrraannssaaccttiioonnss
|
||||
|
||||
Setting "strict_smtputf8 = yes" in addition to "smtputf8_enable = yes" will
|
||||
enable stricter enforcement of the SMTPUTF8 protocol. Specifically, the Postfix
|
||||
SMTP server will not only reject non-UTF8 sender or recipient addresses, it
|
||||
will in addition accept UTF-8 sender or recipient addresses only when the
|
||||
client requests an SMTPUTF8 mail transaction.
|
||||
|
||||
CCoommppaattiibbiilliittyy wwiitthh IIDDNNAA22000033
|
||||
|
||||
Postfix >= 3.2 by default disables the 'transitional' compatibility between
|
||||
IDNA2003 and IDNA2008, when converting UTF-8 domain names to/from the ASCII
|
||||
form that is used in DNS lookups. This makes Postfix behavior consistent with
|
||||
current versions of the Firefox and Chrome web browsers. Specify
|
||||
"enable_idna2003_compatibility = yes" to get the historical behavior.
|
||||
|
||||
This affects the conversion of domain names that contain for example the German
|
||||
sz (ß) and the Greek zeta (ς). See https://unicode.org/cldr/utility/idna.jsp
|
||||
for more examples.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* May 15, 2014: Arnt Gulbrandsen posted his patch for Unicode email support.
|
||||
This work was sponsored by CNNIC.
|
||||
|
||||
* July 15, 2014: Wietse integrated Arnt Gulbrandsen's code and released
|
||||
Postfix with SMTPUTF8 support.
|
||||
|
||||
* January 2015: Wietse added UTF-8 support for casefolding in Postfix lookup
|
||||
tables and caseless string comparison in Postfix list-based features.
|
||||
|
||||
288
README_FILES/SOHO_README
Normal file
288
README_FILES/SOHO_README
Normal file
|
|
@ -0,0 +1,288 @@
|
|||
PPoossttffiixx SSmmaallll//HHoommee OOffffiiccee HHiinnttss aanndd TTiippss
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document combines hints and tips for "small office/home office"
|
||||
applications into one document so that they are easier to find. The text
|
||||
describes the mail sending side only. If your machine does not receive mail
|
||||
directly (i.e. it does not have its own Internet domain name and its own fixed
|
||||
IP address), then you will need a solution such as "fetchmail", which is
|
||||
outside the scope of the Postfix documentation.
|
||||
|
||||
* Selected topics from the STANDARD_CONFIGURATION_README document:
|
||||
|
||||
o Postfix on a stand-alone Internet host
|
||||
o Postfix on hosts without a real Internet hostname
|
||||
|
||||
Selected topics from the SASL_README document:
|
||||
|
||||
o Enabling SASL authentication in the Postfix SMTP client
|
||||
o Configuring Sender-Dependent SASL authentication
|
||||
|
||||
See the SASL_README and STANDARD_CONFIGURATION_README documents for further
|
||||
information on these topics.
|
||||
|
||||
PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
|
||||
|
||||
Postfix should work out of the box without change on a stand-alone machine that
|
||||
has direct Internet access. At least, that is how Postfix installs when you
|
||||
download the Postfix source code via https://www.postfix.org/.
|
||||
|
||||
You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
|
||||
by your main.cf. Besides a few pathname settings, few parameters should be set
|
||||
on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
|
||||
document:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Optional: send mail as user@domainname instead of user@hostname.
|
||||
#myorigin = $mydomain
|
||||
|
||||
# Optional: specify NAT/proxy external address.
|
||||
#proxy_interfaces = 1.2.3.4
|
||||
|
||||
# Alternative 1: don't relay mail from other hosts.
|
||||
mynetworks_style = host
|
||||
relay_domains =
|
||||
|
||||
# Alternative 2: relay mail from local clients only.
|
||||
# mynetworks = 192.168.1.0/28
|
||||
# relay_domains =
|
||||
|
||||
See also the section "Postfix on hosts without a real Internet hostname" if
|
||||
this is applicable to your configuration.
|
||||
|
||||
PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
|
||||
|
||||
This section is for hosts that don't have their own Internet hostname.
|
||||
Typically these are systems that get a dynamic IP address via DHCP or via
|
||||
dialup. Postfix will let you send and receive mail just fine between accounts
|
||||
on a machine with a fantasy name. However, you cannot use a fantasy hostname in
|
||||
your email address when sending mail into the Internet, because no-one would be
|
||||
able to reply to your mail. In fact, more and more sites refuse mail addresses
|
||||
with non-existent domain names.
|
||||
|
||||
Note: the following information is Postfix version dependent. To find out what
|
||||
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
|
||||
|
||||
SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
|
||||
|
||||
Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
|
||||
addresses by valid Internet addresses. This mapping happens ONLY when mail
|
||||
leaves the machine; not when you send mail between users on the same machine.
|
||||
|
||||
The following example presents additional configuration. You need to combine
|
||||
this with basic configuration information as discussed in the first half of
|
||||
this document.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtp_generic_maps = hash:/etc/postfix/generic
|
||||
3
|
||||
4 /etc/postfix/generic:
|
||||
5 his@localdomain.local hisaccount@hisisp.example
|
||||
6 her@localdomain.local heraccount@herisp.example
|
||||
7 @localdomain.local hisaccount+local@hisisp.example
|
||||
|
||||
When mail is sent to a remote host via SMTP:
|
||||
|
||||
* Line 5 replaces his@localdomain.local by his ISP mail address,
|
||||
|
||||
* Line 6 replaces her@localdomain.local by her ISP mail address, and
|
||||
|
||||
* Line 7 replaces other local addresses by his ISP account, with an address
|
||||
extension of +local (this example assumes that the ISP supports "+" style
|
||||
address extensions).
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
|
||||
generic table.
|
||||
|
||||
SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
|
||||
|
||||
The solution with older Postfix systems is to use valid Internet addresses
|
||||
where possible, and to let Postfix map valid Internet addresses to local
|
||||
fantasy addresses. With this, you can send mail to the Internet and to local
|
||||
fantasy addresses, including mail to local fantasy addresses that don't have a
|
||||
valid Internet address of their own.
|
||||
|
||||
The following example presents additional configuration. You need to combine
|
||||
this with basic configuration information as discussed in the first half of
|
||||
this document.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 myhostname = hostname.localdomain
|
||||
3 mydomain = localdomain
|
||||
4
|
||||
5 canonical_maps = hash:/etc/postfix/canonical
|
||||
6
|
||||
7 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
8
|
||||
9 /etc/postfix/canonical:
|
||||
10 your-login-name your-account@your-isp.com
|
||||
11
|
||||
12 /etc/postfix/virtual:
|
||||
13 your-account@your-isp.com your-login-name
|
||||
|
||||
Translation:
|
||||
|
||||
* Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
|
||||
that is already in use by real organizations on the Internet. See RFC 2606
|
||||
for examples of domain names that are guaranteed not to be owned by anyone.
|
||||
|
||||
* Lines 5, 9, 10: This provides the mapping from "your-login-
|
||||
name@hostname.localdomain" to "your-account@your-isp.com". This part is
|
||||
required.
|
||||
|
||||
* Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
|
||||
instead of sending it to the ISP. This part is not required but is
|
||||
convenient.
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
|
||||
canonical table.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
|
||||
virtual table.
|
||||
|
||||
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
|
||||
|
||||
This section shows a typical scenario where the Postfix SMTP client sends all
|
||||
messages via a mail gateway server that requires SASL authentication.
|
||||
|
||||
TTrroouubbllee ssoollvviinngg ttiippss::
|
||||
|
||||
* If your SASL logins fail with "SASL authentication failure: No worthy
|
||||
mechs found" in the mail logfile, then see the section "Postfix SMTP/
|
||||
LMTP client policy - SASL mechanism pprrooppeerrttiieess".
|
||||
|
||||
* For a solution to a more obscure class of SASL authentication failures,
|
||||
see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
|
||||
|
||||
To make the example more readable we introduce it in two parts. The first part
|
||||
takes care of the basic configuration, while the second part sets up the
|
||||
username/password information.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_sasl_auth_enable = yes
|
||||
smtp_tls_security_level = encrypt
|
||||
smtp_sasl_tls_security_options = noanonymous
|
||||
relayhost = [mail.isp.example]
|
||||
# Alternative form:
|
||||
# relayhost = [mail.isp.example]:submission
|
||||
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
|
||||
|
||||
* The smtp_sasl_auth_enable setting enables client-side authentication. We
|
||||
will configure the client's username and password information in the second
|
||||
part of the example.
|
||||
|
||||
* The smtp_tls_security_level setting ensures that the connection to the
|
||||
remote smtp server will be encrypted, and smtp_sasl_tls_security_options
|
||||
removes the prohibition on plaintext passwords.
|
||||
|
||||
* The relayhost setting forces the Postfix SMTP to send all remote messages
|
||||
to the specified mail server instead of trying to deliver them directly to
|
||||
their destination.
|
||||
|
||||
* In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
|
||||
from looking up MX (mail exchanger) records for the enclosed name.
|
||||
|
||||
* The relayhost destination may also specify a non-default TCP port. For
|
||||
example, the alternative form [mail.isp.example]:submission tells Postfix
|
||||
to connect to TCP network port 587, which is reserved for email client
|
||||
applications.
|
||||
|
||||
* The Postfix SMTP client is compatible with SMTP servers that use the non-
|
||||
standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
|
||||
requires no additional Postfix client configuration.
|
||||
|
||||
* With the setting "smtp_tls_wrappermode = yes", the Postfix SMTP client
|
||||
supports the "wrappermode" protocol, which uses TCP port 465 on the SMTP
|
||||
server (Postfix 3.0 and later).
|
||||
|
||||
* With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
|
||||
client to send username and password information to the mail gateway
|
||||
server. As discussed in the next section, the Postfix SMTP client supports
|
||||
multiple ISP accounts. For this reason the username and password are stored
|
||||
in a table that contains one username/password combination for each mail
|
||||
gateway server.
|
||||
|
||||
/etc/postfix/sasl_passwd:
|
||||
# destination credentials
|
||||
[mail.isp.example] username:password
|
||||
# Alternative form:
|
||||
# [mail.isp.example]:submission username:password
|
||||
|
||||
IImmppoorrttaanntt
|
||||
|
||||
Keep the SASL client password file in /etc/postfix, and make the file
|
||||
read+write only for root to protect the username/password combinations
|
||||
against other users. The Postfix SMTP client will still be able to read the
|
||||
SASL client passwords. It opens the file as user root before it drops
|
||||
privileges, and before entering an optional chroot jail.
|
||||
|
||||
* Use the postmap command whenever you change the /etc/postfix/sasl_passwd
|
||||
file.
|
||||
|
||||
* If you specify the "[" and "]" in the relayhost destination, then you must
|
||||
use the same form in the smtp_sasl_password_maps file.
|
||||
|
||||
* If you specify a non-default TCP Port (such as ":submission" or ":587") in
|
||||
the relayhost destination, then you must use the same form in the
|
||||
smtp_sasl_password_maps file.
|
||||
|
||||
CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
|
||||
|
||||
Postfix supports different ISP accounts for different sender addresses (version
|
||||
2.3 and later). This can be useful when one person uses the same machine for
|
||||
work and for personal use, or when people with different ISP accounts share the
|
||||
same Postfix server.
|
||||
|
||||
To make this possible, Postfix supports per-sender SASL passwords and per-
|
||||
sender relay hosts. In the example below, the Postfix SMTP client will search
|
||||
the SASL password file by sender address before it searches that same file by
|
||||
destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
|
||||
per-sender relayhost file, and use the default relayhost setting only as a
|
||||
final resort.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_sender_dependent_authentication = yes
|
||||
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
|
||||
smtp_sasl_auth_enable = yes
|
||||
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
|
||||
relayhost = [mail.isp.example]
|
||||
# Alternative form:
|
||||
# relayhost = [mail.isp.example]:submission
|
||||
|
||||
/etc/postfix/sasl_passwd:
|
||||
# Per-sender authentication; see also /etc/postfix/sender_relay.
|
||||
user1@example.com username1:password1
|
||||
user2@example.net username2:password2
|
||||
# Login information for the default relayhost.
|
||||
[mail.isp.example] username:password
|
||||
# Alternative form:
|
||||
# [mail.isp.example]:submission username:password
|
||||
|
||||
/etc/postfix/sender_relay:
|
||||
# Per-sender provider; see also /etc/postfix/sasl_passwd.
|
||||
user1@example.com [mail.example.com]:submission
|
||||
user2@example.net [mail.example.net]
|
||||
|
||||
* If you are creative, then you can try to combine the two tables into one
|
||||
single MySQL database, and configure different Postfix queries to extract
|
||||
the appropriate information.
|
||||
|
||||
* Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
|
||||
files. To find out what lookup tables Postfix supports, use the command
|
||||
"ppoossttccoonnff --mm".
|
||||
|
||||
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
|
||||
the sasl_passwd table.
|
||||
|
||||
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
|
||||
the sender_relay table.
|
||||
|
||||
74
README_FILES/SQLITE_README
Normal file
74
README_FILES/SQLITE_README
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
PPoossttffiixx SSQQLLiittee HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The Postfix sqlite map type allows you to hook up Postfix to a SQLite database.
|
||||
This implementation allows for multiple sqlite databases: you can use one for a
|
||||
virtual(5) table, one for an access(5) table, and one for an aliases(5) table
|
||||
if you want.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh SSQQLLiittee ssuuppppoorrtt
|
||||
|
||||
The Postfix SQLite client utilizes the sqlite3 library, which can be obtained
|
||||
from:
|
||||
|
||||
https://www.sqlite.org/
|
||||
|
||||
In order to build Postfix with sqlite map support, you will need to add to
|
||||
CCARGS the flags -DHAS_SQLITE and -I with the directory containing the sqlite
|
||||
header files, and you will need to add to AUXLIBS the directory and name of the
|
||||
sqlite3 library, plus the name of the standard POSIX thread library (pthread).
|
||||
For example:
|
||||
|
||||
make -f Makefile.init makefiles \
|
||||
"CCARGS=-DHAS_SQLITE -I/usr/local/include" \
|
||||
"AUXLIBS_SQLITE=-L/usr/local/lib -lsqlite3 -lpthread"
|
||||
|
||||
If your SQLite shared library is in a directory that the RUN-TIME linker does
|
||||
not know about, add a "-Wl,-R,/path/to/directory" option after "-lsqlite3".
|
||||
|
||||
Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_SQLITE. With Postfix
|
||||
3.0 and later, the old AUXLIBS variable still supports building a statically-
|
||||
loaded SQLite database client, but only the new AUXLIBS_SQLITE variable
|
||||
supports building a dynamically-loaded or statically-loaded SQLite database
|
||||
client.
|
||||
|
||||
Failure to use the AUXLIBS_SQLITE variable will defeat the purpose of
|
||||
dynamic database client loading. Every Postfix executable file will have
|
||||
SQLITE database library dependencies. And that was exactly what dynamic
|
||||
database client loading was meant to avoid.
|
||||
|
||||
Then, just run 'make'.
|
||||
|
||||
UUssiinngg SSQQLLiittee ttaabblleess
|
||||
|
||||
Once Postfix is built with sqlite support, you can specify a map type in
|
||||
main.cf like this:
|
||||
|
||||
alias_maps = sqlite:/etc/postfix/sqlite-aliases.cf
|
||||
|
||||
The file /etc/postfix/sqlite-aliases.cf specifies lots of information telling
|
||||
Postfix how to reference the sqlite database. For a complete description, see
|
||||
the sqlite_table(5) manual page.
|
||||
|
||||
EExxaammppllee:: llooccaall aalliiaasseess
|
||||
|
||||
#
|
||||
# sqlite config file for local(8) aliases(5) lookups
|
||||
#
|
||||
|
||||
# Path to database
|
||||
dbpath = /some/path/to/sqlite_database
|
||||
|
||||
# See sqlite_table(5) for details.
|
||||
query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
SQLite support was added with Postfix version 2.8.
|
||||
|
||||
* Implementation by Axel Steiner
|
||||
* Documentation by Jesus Garcia Crespo
|
||||
|
||||
637
README_FILES/STANDARD_CONFIGURATION_README
Normal file
637
README_FILES/STANDARD_CONFIGURATION_README
Normal file
|
|
@ -0,0 +1,637 @@
|
|||
PPoossttffiixx SSttaannddaarrdd CCoonnffiigguurraattiioonn EExxaammpplleess
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document presents a number of typical Postfix configurations. This
|
||||
document should be reviewed after you have followed the basic configuration
|
||||
steps as described in the BASIC_CONFIGURATION_README document. In particular,
|
||||
do not proceed here if you don't already have Postfix working for local mail
|
||||
submission and for local mail delivery.
|
||||
|
||||
The first part of this document presents standard configurations that each
|
||||
solve one specific problem.
|
||||
|
||||
* Postfix on a stand-alone Internet host
|
||||
* Postfix on a null client
|
||||
* Postfix on a local network
|
||||
* Postfix email firewall/gateway
|
||||
|
||||
The second part of this document presents additional configurations for hosts
|
||||
in specific environments.
|
||||
|
||||
* Delivering some but not all accounts locally
|
||||
* Running Postfix behind a firewall
|
||||
* Configuring Postfix as primary or backup MX host for a remote site
|
||||
* Postfix on a dialup machine
|
||||
* Postfix on hosts without a real Internet hostname
|
||||
|
||||
PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
|
||||
|
||||
Postfix should work out of the box without change on a stand-alone machine that
|
||||
has direct Internet access. At least, that is how Postfix installs when you
|
||||
download the Postfix source code via https://www.postfix.org/.
|
||||
|
||||
You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
|
||||
by your main.cf. Besides a few pathname settings, few parameters should be set
|
||||
on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
|
||||
document:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Optional: send mail as user@domainname instead of user@hostname.
|
||||
#myorigin = $mydomain
|
||||
|
||||
# Optional: specify NAT/proxy external address.
|
||||
#proxy_interfaces = 1.2.3.4
|
||||
|
||||
# Alternative 1: don't relay mail from other hosts.
|
||||
mynetworks_style = host
|
||||
relay_domains =
|
||||
|
||||
# Alternative 2: relay mail from local clients only.
|
||||
# mynetworks = 192.168.1.0/28
|
||||
# relay_domains =
|
||||
|
||||
See also the section "Postfix on hosts without a real Internet hostname" if
|
||||
this is applicable to your configuration.
|
||||
|
||||
PPoossttffiixx oonn aa nnuullll cclliieenntt
|
||||
|
||||
A null client is a machine that can only send mail. It receives no mail from
|
||||
the network, and it does not deliver any mail locally. A null client typically
|
||||
uses POP, IMAP or NFS for mailbox access.
|
||||
|
||||
In this example we assume that the Internet domain name is "example.com" and
|
||||
that the machine is named "hostname.example.com". As usual, the examples show
|
||||
only parameters that are not left at their default settings.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 myhostname = hostname.example.com
|
||||
3 myorigin = $mydomain
|
||||
4 relayhost = $mydomain
|
||||
5 inet_interfaces = loopback-only
|
||||
6 mydestination =
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 2: Set myhostname to hostname.example.com, in case the machine name
|
||||
isn't set to a fully-qualified domain name (use the command "postconf -
|
||||
d myhostname" to find out what the machine name is).
|
||||
|
||||
* Line 2: The myhostname value also provides the default value for the
|
||||
mydomain parameter (here, "mydomain = example.com").
|
||||
|
||||
* Line 3: Send mail as "user@example.com" (instead of
|
||||
"user@hostname.example.com"), so that nothing ever has a reason to send
|
||||
mail to "user@hostname.example.com".
|
||||
|
||||
* Line 4: Forward all mail to the mail server that is responsible for the
|
||||
"example.com" domain. This prevents mail from getting stuck on the null
|
||||
client if it is turned off while some remote destination is unreachable.
|
||||
Specify a real hostname here if your "example.com" domain has no MX record.
|
||||
|
||||
* Line 5: Do not accept mail from the network.
|
||||
|
||||
* Line 6: Disable local mail delivery. All mail goes to the mail server as
|
||||
specified in line 4.
|
||||
|
||||
PPoossttffiixx oonn aa llooccaall nneettwwoorrkk
|
||||
|
||||
This section describes a local area network environment of one main server and
|
||||
multiple other systems that send and receive email. As usual we assume that the
|
||||
Internet domain name is "example.com". All systems are configured to send mail
|
||||
as "user@example.com", and all systems receive mail for
|
||||
"user@hostname.example.com". The main server also receives mail for
|
||||
"user@example.com". We call this machine by the name of mailhost.example.com.
|
||||
|
||||
A drawback of sending mail as "user@example.com" is that mail for "root" and
|
||||
other system accounts is also sent to the central mailhost. See the section
|
||||
"Delivering some but not all accounts locally" below for possible solutions.
|
||||
|
||||
As usual, the examples show only parameters that are not left at their default
|
||||
settings.
|
||||
|
||||
First we present the non-mailhost configuration, because it is the simpler one.
|
||||
This machine sends mail as "user@example.com" and is the final destination for
|
||||
"user@hostname.example.com".
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 myorigin = $mydomain
|
||||
3 mynetworks = 127.0.0.0/8 10.0.0.0/24
|
||||
4 relay_domains =
|
||||
5 # Optional: forward all non-local mail to mailhost
|
||||
6 #relayhost = $mydomain
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 2: Send mail as "user@example.com".
|
||||
|
||||
* Line 3: Specify the trusted networks.
|
||||
|
||||
* Line 4: This host does not relay mail from untrusted networks.
|
||||
|
||||
* Line 6: This is needed if no direct Internet access is available. See also
|
||||
below, "Postfix behind a firewall".
|
||||
|
||||
Next we present the mailhost configuration. This machine sends mail as
|
||||
"user@example.com" and is the final destination for "user@hostname.example.com"
|
||||
as well as "user@example.com".
|
||||
|
||||
1 DNS:
|
||||
2 example.com IN MX 10 mailhost.example.com.
|
||||
3
|
||||
4 /etc/postfix/main.cf:
|
||||
5 myorigin = $mydomain
|
||||
6 mydestination = $myhostname localhost.$mydomain localhost $mydomain
|
||||
7 mynetworks = 127.0.0.0/8 10.0.0.0/24
|
||||
8 relay_domains =
|
||||
9 # Optional: forward all non-local mail to firewall
|
||||
10 #relayhost = [firewall.example.com]
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 2: Send mail for the domain "example.com" to the machine
|
||||
mailhost.example.com. Remember to specify the "." at the end of the line.
|
||||
|
||||
* Line 5: Send mail as "user@example.com".
|
||||
|
||||
* Line 6: This host is the final mail destination for the "example.com"
|
||||
domain, in addition to the names of the machine itself.
|
||||
|
||||
* Line 7: Specify the trusted networks.
|
||||
|
||||
* Line 8: This host does not relay mail from untrusted networks.
|
||||
|
||||
* Line 10: This is needed only when the mailhost has to forward non-local
|
||||
mail via a mail server on a firewall. The [] forces Postfix to do no MX
|
||||
record lookups.
|
||||
|
||||
In an environment like this, users access their mailbox in one or more of the
|
||||
following ways:
|
||||
|
||||
* Mailbox access via NFS or equivalent.
|
||||
|
||||
* Mailbox access via POP or IMAP.
|
||||
|
||||
* Mailbox on the user's preferred machine.
|
||||
|
||||
In the latter case, each user has an alias on the mailhost that forwards mail
|
||||
to her preferred machine:
|
||||
|
||||
/etc/aliases:
|
||||
joe: joe@joes.preferred.machine
|
||||
jane: jane@janes.preferred.machine
|
||||
|
||||
On some systems the alias database is not in /etc/aliases. To find out the
|
||||
location for your system, execute the command "ppoossttccoonnff aalliiaass__mmaappss".
|
||||
|
||||
Execute the command "nneewwaalliiaasseess" whenever you change the aliases file.
|
||||
|
||||
PPoossttffiixx eemmaaiill ffiirreewwaallll//ggaatteewwaayy
|
||||
|
||||
The idea is to set up a Postfix email firewall/gateway that forwards mail for
|
||||
"example.com" to an inside gateway machine but rejects mail for
|
||||
"anything.example.com". There is only one problem: with "relay_domains =
|
||||
example.com", the firewall normally also accepts mail for
|
||||
"anything.example.com". That would not be right.
|
||||
|
||||
Note: this example requires Postfix version 2.0 and later. To find out what
|
||||
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
|
||||
|
||||
The solution is presented in multiple parts. This first part gets rid of local
|
||||
mail delivery on the firewall, making the firewall harder to break.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 myorigin = example.com
|
||||
3 mydestination =
|
||||
4 local_recipient_maps =
|
||||
5 local_transport = error:local mail delivery is disabled
|
||||
6
|
||||
7 /etc/postfix/master.cf:
|
||||
8 Comment out the local delivery agent
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 2: Send mail from this machine as "user@example.com", so that no
|
||||
reason exists to send mail to "user@firewall.example.com".
|
||||
|
||||
* Lines 3-8: Disable local mail delivery on the firewall machine.
|
||||
|
||||
For the sake of technical correctness the firewall must be able to receive mail
|
||||
for postmaster@[firewall ip address]. Reportedly, some things actually expect
|
||||
this ability to exist. The second part of the solution therefore adds support
|
||||
for postmaster@[firewall ip address], and as a bonus we do abuse@[firewall ip
|
||||
address] as well. All the mail to these two accounts is forwarded to an inside
|
||||
address.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
3
|
||||
4 /etc/postfix/virtual:
|
||||
5 postmaster postmaster@example.com
|
||||
6 abuse abuse@example.com
|
||||
|
||||
Translation:
|
||||
|
||||
* Because mydestination is empty (see the previous example), only address
|
||||
literals matching $inet_interfaces or $proxy_interfaces are deemed local.
|
||||
So "localpart@[a.d.d.r]" can be matched as simply "localpart" in canonical
|
||||
(5) and virtual(5). This avoids the need to specify firewall IP addresses
|
||||
in Postfix configuration files.
|
||||
|
||||
The last part of the solution does the email forwarding, which is the real
|
||||
purpose of the firewall email function.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 mynetworks = 127.0.0.0/8 12.34.56.0/24
|
||||
3 relay_domains = example.com
|
||||
4 parent_domain_matches_subdomains =
|
||||
5 debug_peer_list smtpd_access_maps
|
||||
|
||||
6a # Postfix 2.10 and later support separate relay control and
|
||||
7a # spam control.
|
||||
8a smtpd_relay_restrictions =
|
||||
9a permit_mynetworks reject_unauth_destination
|
||||
10a smtpd_recipient_restrictions = ...spam blocking rules....
|
||||
|
||||
6b # Older configurations combine relay control and spam control. To
|
||||
7b # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
|
||||
8b smtpd_recipient_restrictions =
|
||||
9b permit_mynetworks reject_unauth_destination
|
||||
10b ...spam blocking rules....
|
||||
|
||||
11 relay_recipient_maps = hash:/etc/postfix/relay_recipients
|
||||
12 transport_maps = hash:/etc/postfix/transport
|
||||
13
|
||||
14 /etc/postfix/relay_recipients:
|
||||
15 user1@example.com x
|
||||
16 user2@example.com x
|
||||
17 . . .
|
||||
18
|
||||
19 /etc/postfix/transport:
|
||||
20 example.com relay:[inside-gateway.example.com]
|
||||
|
||||
Translation:
|
||||
|
||||
* Lines 1-10: Accept mail from local systems in $mynetworks, and accept mail
|
||||
from outside for "user@example.com" but not for
|
||||
"user@anything.example.com". The magic is in lines 4-5.
|
||||
|
||||
* Lines 11, 13-16: Define the list of valid addresses in the "example.com"
|
||||
domain that can receive mail from the Internet. This prevents the mail
|
||||
queue from filling up with undeliverable MAILER-DAEMON messages. If you
|
||||
can't maintain a list of valid recipients then you must specify
|
||||
"relay_recipient_maps =" (that is, an empty value), or you must specify an
|
||||
"@example.com x" wild-card in the relay_recipients table.
|
||||
|
||||
* Lines 12, 19-20: Route mail for "example.com" to the inside gateway
|
||||
machine. The [] forces Postfix to do no MX lookup. This uses the "relay"
|
||||
delivery transport (a copy of the default "smtp" delivery transport) to
|
||||
forward inbound mail. This can improve performance of deliveries to
|
||||
internal domains because they will compete for SMTP clients from the
|
||||
"relay" delivery transport, instead of competing with other SMTP deliveries
|
||||
for SMTP clients from the default "smtp" delivery transport.
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//rreellaayy__rreecciippiieennttss" whenever you change
|
||||
the relay_recipients table.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
|
||||
transport table.
|
||||
|
||||
In some installations, there may be separate instances of Postfix processing
|
||||
inbound and outbound mail on a multi-homed firewall. The inbound Postfix
|
||||
instance has an SMTP server listening on the external firewall interface, and
|
||||
the outbound Postfix instance has an SMTP server listening on the internal
|
||||
interface. In such a configuration it is tempting to configure $inet_interfaces
|
||||
in each instance with just the corresponding interface address.
|
||||
|
||||
In most cases, using inet_interfaces in this way will not work, because as
|
||||
documented in the $inet_interfaces reference manual, the smtp(8) delivery agent
|
||||
will also use the specified interface address as the source address for
|
||||
outbound connections and will be unable to reach hosts on "the other side" of
|
||||
the firewall. The symptoms are that the firewall is unable to connect to hosts
|
||||
that are in fact up. See the inet_interfaces parameter documentation for
|
||||
suggested work-arounds.
|
||||
|
||||
DDeelliivveerriinngg ssoommee bbuutt nnoott aallll aaccccoouunnttss llooccaallllyy
|
||||
|
||||
A drawback of sending mail as "user@example.com" (instead of
|
||||
"user@hostname.example.com") is that mail for "root" and other system accounts
|
||||
is also sent to the central mailhost. In order to deliver such accounts
|
||||
locally, you can set up virtual aliases as follows:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
3
|
||||
4 /etc/postfix/virtual:
|
||||
5 root root@localhost
|
||||
6 . . .
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 5: As described in the virtual(5) manual page, the bare name "root"
|
||||
matches "root@site" when "site" is equal to $myorigin, when "site" is
|
||||
listed in $mydestination, or when it matches $inet_interfaces or
|
||||
$proxy_interfaces.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after editing the file.
|
||||
|
||||
RRuunnnniinngg PPoossttffiixx bbeehhiinndd aa ffiirreewwaallll
|
||||
|
||||
The simplest way to set up Postfix on a host behind a firewalled network is to
|
||||
send all mail to a gateway host, and to let that mail host take care of
|
||||
internal and external forwarding. Examples of that are shown in the local area
|
||||
network section above. A more sophisticated approach is to send only external
|
||||
mail to the gateway host, and to send intranet mail directly.
|
||||
|
||||
Note: this example requires Postfix version 2.0 and later. To find out what
|
||||
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
|
||||
|
||||
The following example presents additional configuration. You need to combine
|
||||
this with basic configuration information as discussed in the first half of
|
||||
this document.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 transport_maps = hash:/etc/postfix/transport
|
||||
3 relayhost =
|
||||
4 # Optional for a machine that isn't "always on"
|
||||
5 #fallback_relay = [gateway.example.com]
|
||||
6
|
||||
7 /etc/postfix/transport:
|
||||
8 # Internal delivery.
|
||||
9 example.com :
|
||||
10 .example.com :
|
||||
11 # External delivery.
|
||||
12 * smtp:[gateway.example.com]
|
||||
|
||||
Translation:
|
||||
|
||||
* Lines 2, 7-12: Request that intranet mail is delivered directly, and that
|
||||
external mail is given to a gateway. Obviously, this example assumes that
|
||||
the organization uses DNS MX records internally. The [] forces Postfix to
|
||||
do no MX lookup.
|
||||
|
||||
* Line 3: IMPORTANT: do not specify a relayhost in main.cf.
|
||||
|
||||
* Line 5: This prevents mail from being stuck in the queue when the machine
|
||||
is turned off. Postfix tries to deliver mail directly, and gives
|
||||
undeliverable mail to a gateway.
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you edit the
|
||||
transport table.
|
||||
|
||||
CCoonnffiigguurriinngg PPoossttffiixx aass pprriimmaarryy oorr bbaacckkuupp MMXX hhoosstt ffoorr aa rreemmoottee ssiittee
|
||||
|
||||
This section presents additional configuration. You need to combine this with
|
||||
basic configuration information as discussed in the first half of this
|
||||
document.
|
||||
|
||||
When your system is SECONDARY MX host for a remote site this is all you need:
|
||||
|
||||
1 DNS:
|
||||
2 the.backed-up.domain.tld IN MX 100 your.machine.tld.
|
||||
3
|
||||
4 /etc/postfix/main.cf:
|
||||
5 relay_domains = . . . the.backed-up.domain.tld
|
||||
|
||||
6a # Postfix 2.10 and later support separate relay control and
|
||||
7a # spam control.
|
||||
8a smtpd_relay_restrictions =
|
||||
9a permit_mynetworks reject_unauth_destination
|
||||
10a smtpd_recipient_restrictions = ...spam blocking rules....
|
||||
|
||||
6b # Older configurations combine relay control and spam control. To
|
||||
7b # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
|
||||
8b smtpd_recipient_restrictions =
|
||||
9b permit_mynetworks reject_unauth_destination
|
||||
10b ...spam blocking rules....
|
||||
|
||||
11 # You must specify your NAT/proxy external address.
|
||||
12 #proxy_interfaces = 1.2.3.4
|
||||
13
|
||||
14 relay_recipient_maps = hash:/etc/postfix/relay_recipients
|
||||
15
|
||||
16 /etc/postfix/relay_recipients:
|
||||
17 user1@the.backed-up.domain.tld x
|
||||
18 user2@the.backed-up.domain.tld x
|
||||
19 . . .
|
||||
|
||||
When your system is PRIMARY MX host for a remote site you need the above, plus:
|
||||
|
||||
20 /etc/postfix/main.cf:
|
||||
21 transport_maps = hash:/etc/postfix/transport
|
||||
22
|
||||
23 /etc/postfix/transport:
|
||||
24 the.backed-up.domain.tld relay:[their.mail.host.tld]
|
||||
|
||||
Important notes:
|
||||
|
||||
* Do not list the.backed-up.domain.tld in mydestination.
|
||||
|
||||
* Do not list the.backed-up.domain.tld in virtual_alias_domains.
|
||||
|
||||
* Do not list the.backed-up.domain.tld in virtual_mailbox_domains.
|
||||
|
||||
* Lines 1-9: Forward mail from the Internet for "the.backed-up.domain.tld" to
|
||||
the primary MX host for that domain.
|
||||
|
||||
* Line 12: This is a must if Postfix receives mail via a NAT relay or proxy
|
||||
that presents a different IP address to the world than the local machine.
|
||||
|
||||
* Lines 14-18: Define the list of valid addresses in the "the.backed-
|
||||
up.domain.tld" domain. This prevents your mail queue from filling up with
|
||||
undeliverable MAILER-DAEMON messages. If you can't maintain a list of valid
|
||||
recipients then you must specify "relay_recipient_maps =" (that is, an
|
||||
empty value), or you must specify an "@the.backed-up.domain.tld x" wild-
|
||||
card in the relay_recipients table.
|
||||
|
||||
* Line 24: The [] forces Postfix to do no MX lookup.
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
|
||||
transport table.
|
||||
|
||||
NOTE for Postfix < 2.2: Do not use the fallback_relay feature when relaying
|
||||
mail for a backup or primary MX domain. Mail would loop between the Postfix MX
|
||||
host and the fallback_relay host when the final destination is unavailable.
|
||||
|
||||
* In main.cf specify "relay_transport = relay",
|
||||
* In master.cf specify "-o fallback_relay =" at the end of the relay entry.
|
||||
* In transport maps, specify "relay:nexthop..." as the right-hand side for
|
||||
backup or primary MX domain entries.
|
||||
|
||||
These are default settings in Postfix version 2.2 and later.
|
||||
|
||||
PPoossttffiixx oonn aa ddiiaalluupp mmaacchhiinnee
|
||||
|
||||
This section applies to dialup connections that are down most of the time. For
|
||||
dialup connections that are up 24x7, see the local area network section above.
|
||||
|
||||
This section presents additional configuration. You need to combine this with
|
||||
basic configuration information as discussed in the first half of this
|
||||
document.
|
||||
|
||||
If you do not have your own hostname and IP address (usually with dialup, cable
|
||||
TV or DSL connections) then you should also study the section on "Postfix on
|
||||
hosts without a real Internet hostname".
|
||||
|
||||
* Route all outgoing mail to your network provider.
|
||||
If your machine is disconnected most of the time, there isn't a lot of
|
||||
opportunity for Postfix to deliver mail to hard-to-reach corners of the
|
||||
Internet. It's better to give the mail to a machine that is connected all
|
||||
the time. In the example below, the [] prevents Postfix from trying to look
|
||||
up DNS MX records.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = [smtprelay.someprovider.com]
|
||||
|
||||
* Disable spontaneous SMTP mail delivery (if using on-demand dialup IP only).
|
||||
|
||||
Normally, Postfix attempts to deliver outbound mail at its convenience. If
|
||||
your machine uses on-demand dialup IP, this causes your system to place a
|
||||
telephone call whenever you submit new mail, and whenever Postfix retries
|
||||
to deliver delayed mail. To prevent such telephone calls from being placed,
|
||||
disable spontaneous SMTP mail deliveries.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
defer_transports = smtp (Only for on-demand dialup IP hosts)
|
||||
|
||||
* Disable SMTP client DNS lookups (dialup LAN only).
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
disable_dns_lookups = yes (Only for on-demand dialup IP hosts)
|
||||
|
||||
* Flush the mail queue whenever the Internet link is established.
|
||||
Put the following command into your PPP or SLIP dialup scripts:
|
||||
|
||||
/usr/sbin/sendmail -q (whenever the Internet link is up)
|
||||
|
||||
The exact location of the Postfix sendmail command is system-specific. Use
|
||||
the command "ppoossttccoonnff sseennddmmaaiill__ppaatthh" to find out where the Postfix sendmail
|
||||
command is located on your machine.
|
||||
|
||||
In order to find out if the mail queue is flushed, use something like:
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
# Start mail deliveries.
|
||||
/usr/sbin/sendmail -q
|
||||
|
||||
# Allow deliveries to start.
|
||||
sleep 10
|
||||
|
||||
# Loop until all messages have been tried at least once.
|
||||
while mailq | grep '^[^ ]*\*' >/dev/null
|
||||
do
|
||||
sleep 10
|
||||
done
|
||||
|
||||
If you have disabled spontaneous SMTP mail delivery, you also need to run
|
||||
the "sseennddmmaaiill --qq" command every now and then while the dialup link is up,
|
||||
so that newly-posted mail is flushed from the queue.
|
||||
|
||||
PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
|
||||
|
||||
This section is for hosts that don't have their own Internet hostname.
|
||||
Typically these are systems that get a dynamic IP address via DHCP or via
|
||||
dialup. Postfix will let you send and receive mail just fine between accounts
|
||||
on a machine with a fantasy name. However, you cannot use a fantasy hostname in
|
||||
your email address when sending mail into the Internet, because no-one would be
|
||||
able to reply to your mail. In fact, more and more sites refuse mail addresses
|
||||
with non-existent domain names.
|
||||
|
||||
Note: the following information is Postfix version dependent. To find out what
|
||||
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
|
||||
|
||||
SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
|
||||
|
||||
Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
|
||||
addresses by valid Internet addresses. This mapping happens ONLY when mail
|
||||
leaves the machine; not when you send mail between users on the same machine.
|
||||
|
||||
The following example presents additional configuration. You need to combine
|
||||
this with basic configuration information as discussed in the first half of
|
||||
this document.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtp_generic_maps = hash:/etc/postfix/generic
|
||||
3
|
||||
4 /etc/postfix/generic:
|
||||
5 his@localdomain.local hisaccount@hisisp.example
|
||||
6 her@localdomain.local heraccount@herisp.example
|
||||
7 @localdomain.local hisaccount+local@hisisp.example
|
||||
|
||||
When mail is sent to a remote host via SMTP:
|
||||
|
||||
* Line 5 replaces his@localdomain.local by his ISP mail address,
|
||||
|
||||
* Line 6 replaces her@localdomain.local by her ISP mail address, and
|
||||
|
||||
* Line 7 replaces other local addresses by his ISP account, with an address
|
||||
extension of +local (this example assumes that the ISP supports "+" style
|
||||
address extensions).
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
|
||||
generic table.
|
||||
|
||||
SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
|
||||
|
||||
The solution with older Postfix systems is to use valid Internet addresses
|
||||
where possible, and to let Postfix map valid Internet addresses to local
|
||||
fantasy addresses. With this, you can send mail to the Internet and to local
|
||||
fantasy addresses, including mail to local fantasy addresses that don't have a
|
||||
valid Internet address of their own.
|
||||
|
||||
The following example presents additional configuration. You need to combine
|
||||
this with basic configuration information as discussed in the first half of
|
||||
this document.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 myhostname = hostname.localdomain
|
||||
3 mydomain = localdomain
|
||||
4
|
||||
5 canonical_maps = hash:/etc/postfix/canonical
|
||||
6
|
||||
7 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
8
|
||||
9 /etc/postfix/canonical:
|
||||
10 your-login-name your-account@your-isp.com
|
||||
11
|
||||
12 /etc/postfix/virtual:
|
||||
13 your-account@your-isp.com your-login-name
|
||||
|
||||
Translation:
|
||||
|
||||
* Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
|
||||
that is already in use by real organizations on the Internet. See RFC 2606
|
||||
for examples of domain names that are guaranteed not to be owned by anyone.
|
||||
|
||||
* Lines 5, 9, 10: This provides the mapping from "your-login-
|
||||
name@hostname.localdomain" to "your-account@your-isp.com". This part is
|
||||
required.
|
||||
|
||||
* Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
|
||||
instead of sending it to the ISP. This part is not required but is
|
||||
convenient.
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
|
||||
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
|
||||
canonical table.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
|
||||
virtual table.
|
||||
|
||||
426
README_FILES/STRESS_README
Normal file
426
README_FILES/STRESS_README
Normal file
|
|
@ -0,0 +1,426 @@
|
|||
PPoossttffiixx SSttrreessss--DDeeppeennddeenntt CCoonnffiigguurraattiioonn
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
OOvveerrvviieeww
|
||||
|
||||
This document describes the symptoms of Postfix SMTP server overload. It
|
||||
presents permanent main.cf changes to avoid overload during normal operation,
|
||||
and temporary main.cf changes to cope with an unexpected burst of mail. This
|
||||
document makes specific suggestions for Postfix 2.5 and later which support
|
||||
stress-adaptive behavior, and for earlier Postfix versions that don't.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Symptoms of Postfix SMTP server overload
|
||||
* Automatic stress-adaptive behavior
|
||||
* Service more SMTP clients at the same time
|
||||
* Spend less time per SMTP client
|
||||
* Disconnect suspicious SMTP clients
|
||||
* Temporary measures for older Postfix releases
|
||||
* Detecting support for stress-adaptive behavior
|
||||
* Forcing stress-adaptive behavior on or off
|
||||
* Other measures to off-load zombies
|
||||
* Credits
|
||||
|
||||
SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd
|
||||
|
||||
Under normal conditions, the Postfix SMTP server responds immediately when an
|
||||
SMTP client connects to it; the time to deliver mail is noticeable only with
|
||||
large messages. Performance degrades dramatically when the number of SMTP
|
||||
clients exceeds the number of Postfix SMTP server processes. When an SMTP
|
||||
client connects while all Postfix SMTP server processes are busy, the client
|
||||
must wait until a server process becomes available.
|
||||
|
||||
SMTP server overload may be caused by a surge of legitimate mail (example: a
|
||||
DNS registrar opens a new zone for registrations), by mistake (mail explosion
|
||||
caused by a forwarding loop) or by malice (worm outbreak, botnet, or other
|
||||
illegitimate activity).
|
||||
|
||||
Symptoms of Postfix SMTP server overload are:
|
||||
|
||||
* Remote SMTP clients experience a long delay before Postfix sends the "220
|
||||
hostname.example.com ESMTP Postfix" greeting.
|
||||
|
||||
o NOTE: Broken DNS configurations can also cause lengthy delays before
|
||||
Postfix sends "220 hostname.example.com ...". These delays also exist
|
||||
when Postfix is NOT overloaded.
|
||||
|
||||
o NOTE: To avoid "overload" delays for end-user mail clients, enable the
|
||||
"submission" service entry in master.cf (present since Postfix 2.1),
|
||||
and tell users to connect to this instead of the public SMTP service.
|
||||
|
||||
* The Postfix SMTP server logs an increased number of "lost connection after
|
||||
CONNECT" events. This happens because remote SMTP clients disconnect before
|
||||
Postfix answers the connection.
|
||||
|
||||
o NOTE: A portscan for open SMTP ports can also result in "lost
|
||||
connection ..." logfile messages.
|
||||
|
||||
* Postfix 2.3 and later logs a warning that all server ports are busy:
|
||||
|
||||
Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp"
|
||||
(25) has reached its process limit "30": new clients may experience
|
||||
noticeable delays
|
||||
Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
|
||||
condition, increase the process count in master.cf or reduce the
|
||||
service time per client
|
||||
Oct 3 20:39:27 spike postfix/master[28905]: warning: see
|
||||
https://www.postfix.org/STRESS_README.html for examples of
|
||||
stress-adapting configuration settings
|
||||
|
||||
Legitimate mail that doesn't get through during an episode of Postfix SMTP
|
||||
server overload is not necessarily lost. It should still arrive once the
|
||||
situation returns to normal, as long as the overload condition is temporary.
|
||||
|
||||
AAuuttoommaattiicc ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
|
||||
|
||||
Postfix version 2.5 introduces automatic stress-adaptive behavior. It works as
|
||||
follows. When a "public" network service such as the SMTP server runs into an
|
||||
"all server ports are busy" condition, the Postfix master(8) daemon logs a
|
||||
warning, restarts the service (without interrupting existing network sessions),
|
||||
and runs the service with "-o stress=yes" on the server process command line:
|
||||
|
||||
80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
|
||||
|
||||
Normally, the Postfix master(8) daemon runs such a service with "-o stress=" on
|
||||
the command line (i.e. with an empty parameter value):
|
||||
|
||||
83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
|
||||
|
||||
You won't see "-o stress" command-line parameters with services that have local
|
||||
clients only. These include services internal to Postfix such as the queue
|
||||
manager, and services that listen on a loopback interface only, such as after-
|
||||
filter SMTP services.
|
||||
|
||||
The "stress" parameter value is the key to making main.cf parameter settings
|
||||
stress adaptive. The following settings are the default with Postfix 2.6 and
|
||||
later.
|
||||
|
||||
1 smtpd_timeout = ${stress?{10}:{300}}s
|
||||
2 smtpd_hard_error_limit = ${stress?{1}:{20}}
|
||||
3 smtpd_junk_command_limit = ${stress?{1}:{100}}
|
||||
4 # Parameters added after Postfix 2.6:
|
||||
5 smtpd_per_record_deadline = ${stress?{yes}:{no}}
|
||||
6 smtpd_starttls_timeout = ${stress?{10}:{300}}s
|
||||
7 address_verify_poll_count = ${stress?{1}:{3}}
|
||||
|
||||
Postfix versions before 3.0 use the older form ${stress?x}${stress:y} instead
|
||||
of the newer form ${stress?{x}:{y}}.
|
||||
|
||||
The syntax of ${name?{value}:{value}}, ${name?value} and ${name:value} is
|
||||
explained at the beginning of the postconf(5) manual page.
|
||||
|
||||
Translation:
|
||||
|
||||
* Line 1: under conditions of stress, use an smtpd_timeout value of 10
|
||||
seconds instead of the default 300 seconds. Experience on the postfix-users
|
||||
list from a variety of sysadmins shows that reducing the "normal"
|
||||
smtpd_timeout to 60s is unlikely to affect legitimate clients. However, it
|
||||
is unlikely to become the Postfix default because it's not RFC compliant.
|
||||
Setting smtpd_timeout to 10s or even 5s under stress will still allow most
|
||||
legitimate clients to connect and send mail, but may delay mail from some
|
||||
clients. No mail should be lost, as long as this measure is used only
|
||||
temporarily.
|
||||
|
||||
* Line 2: under conditions of stress, use an smtpd_hard_error_limit of 1
|
||||
instead of the default 20. This disconnects clients after a single error,
|
||||
giving other clients a chance to connect. However, this may cause
|
||||
significant delays with legitimate mail, such as a mailing list that
|
||||
contains a few no-longer-active user names that didn't bother to
|
||||
unsubscribe. No mail should be lost, as long as this measure is used only
|
||||
temporarily.
|
||||
|
||||
* Line 3: under conditions of stress, use an smtpd_junk_command_limit of 1
|
||||
instead of the default 100. This prevents clients from keeping connections
|
||||
open by repeatedly sending HELO, EHLO, NOOP, RSET, VRFY or ETRN commands.
|
||||
|
||||
* Line 5: under conditions of stress, change the behavior of smtpd_timeout
|
||||
and smtpd_starttls_timeout, from a time limit per read or write system
|
||||
call, to a time limit to send or receive a complete record (an SMTP command
|
||||
line, SMTP response line, SMTP message content line, or TLS protocol
|
||||
message).
|
||||
|
||||
* Line 6: under conditions of stress, reduce the time limit for TLS protocol
|
||||
handshake messages to 10 seconds, from the default value of 300 seconds.
|
||||
See also the smtpd_timeout discussion above.
|
||||
|
||||
* Line 7: under conditions of stress, do not wait up to 6 seconds for the
|
||||
completion of an address verification probe. If the result is not already
|
||||
in the address verification cache, reply immediately with
|
||||
$unverified_recipient_tempfail_action or
|
||||
$unverified_sender_tempfail_action. No mail should be lost, as long as this
|
||||
measure is used only temporarily.
|
||||
|
||||
NOTE: Please keep in mind that the stress-adaptive feature is a fairly
|
||||
desperate measure to keep ssoommee legitimate mail flowing under overload
|
||||
conditions. If a site is reaching the SMTP server process limit when there
|
||||
isn't an attack or bot flood occurring, then either the process limit needs to
|
||||
be raised or more hardware needs to be added.
|
||||
|
||||
SSeerrvviiccee mmoorree SSMMTTPP cclliieennttss aatt tthhee ssaammee ttiimmee
|
||||
|
||||
This section and the ones that follow discuss permanent measures against mail
|
||||
server overload.
|
||||
|
||||
One measure to avoid the "all server processes busy" condition is to service
|
||||
more SMTP clients simultaneously. For this you need to increase the number of
|
||||
Postfix SMTP server processes. This will improve the responsiveness for remote
|
||||
SMTP clients, as long as the server machine has enough hardware and software
|
||||
resources to run the additional processes, and as long as the file system can
|
||||
keep up with the additional load.
|
||||
|
||||
* You increase the number of SMTP server processes either by increasing the
|
||||
default_process_limit in main.cf (line 3 below), or by increasing the SMTP
|
||||
server's "maxproc" field in master.cf (line 10 below). Either way, you need
|
||||
to issue a "postfix reload" command to make the change effective.
|
||||
|
||||
* Process limits above 1000 require Postfix version 2.4 or later, and an
|
||||
operating system that supports kernel-based event filters (BSD kqueue(2),
|
||||
Linux epoll(4), or Solaris /dev/poll).
|
||||
|
||||
* More processes use more memory. You can reduce the Postfix memory footprint
|
||||
by using cdb: lookup tables instead of Berkeley DB's hash: or btree:
|
||||
tables.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 # Raise the global process limit, 100 since Postfix 2.0.
|
||||
3 default_process_limit = 200
|
||||
4
|
||||
5 /etc/postfix/master.cf:
|
||||
6 # =============================================================
|
||||
7 # service type private unpriv chroot wakeup maxproc command
|
||||
8 # =============================================================
|
||||
9 # Raise the SMTP service process limit only.
|
||||
10 smtp inet n - n - 200 smtpd
|
||||
|
||||
* NOTE: older versions of the SMTPD_POLICY_README document contain a mistake:
|
||||
they configure a fixed number of policy daemon processes. When you raise
|
||||
the SMTP server's "maxproc" field in master.cf, SMTP server processes will
|
||||
report problems when connecting to policy server processes, because there
|
||||
aren't enough of them. Examples of errors are "connection refused" or
|
||||
"operation timed out".
|
||||
|
||||
To fix, edit master.cf and specify a zero "maxproc" field in all policy
|
||||
server entries; see line 6 in the example below. Issue a "postfix reload"
|
||||
command to make the change effective.
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 # =============================================================
|
||||
3 # service type private unpriv chroot wakeup maxproc command
|
||||
4 # =============================================================
|
||||
5 # Disable the policy service process limit.
|
||||
6 policy unix - n n - 0 spawn
|
||||
7 user=nobody argv=/some/where/policy-server
|
||||
|
||||
SSppeenndd lleessss ttiimmee ppeerr SSMMTTPP cclliieenntt
|
||||
|
||||
When increasing the number of SMTP server processes is not practical, you can
|
||||
improve Postfix server responsiveness by eliminating delays. When Postfix
|
||||
spends less time per SMTP session, the same number of SMTP server processes can
|
||||
service more clients in a given amount of time.
|
||||
|
||||
* Eliminate non-functional RBL lookups (blocklists that are no longer in
|
||||
operation). These lookups can degrade performance. Postfix logs a warning
|
||||
when an RBL server does not respond.
|
||||
|
||||
* Eliminate redundant RBL lookups (people often use multiple Spamhaus RBLs
|
||||
that include each other). To find out whether RBLs include other RBLs, look
|
||||
up the websites that document the RBL's policies.
|
||||
|
||||
* Eliminate header_checks and body_checks, and keep just a few emergency
|
||||
patterns to block the latest worm explosion or backscatter mail. See
|
||||
BACKSCATTER_README for examples of the latter.
|
||||
|
||||
* Group your header_checks and body_checks patterns to avoid unnecessary
|
||||
pattern matching operations:
|
||||
|
||||
1 /etc/postfix/header_checks:
|
||||
2 if /^Subject:/
|
||||
3 /^Subject: virus found in mail from you/ reject
|
||||
4 /^Subject: ..other../ reject
|
||||
5 endif
|
||||
6
|
||||
7 if /^Received:/
|
||||
8 /^Received: from (postfix\.org) / reject forged client name in
|
||||
received header: $1
|
||||
9 /^Received: from ..other../ reject ....
|
||||
10 endif
|
||||
|
||||
DDiissccoonnnneecctt ssuussppiicciioouuss SSMMTTPP cclliieennttss
|
||||
|
||||
Under conditions of overload you can improve Postfix SMTP server responsiveness
|
||||
by hanging up on suspicious clients, so that other clients get a chance to talk
|
||||
to Postfix.
|
||||
|
||||
* Use "521" SMTP reply codes (Postfix 2.6 and later) or "421" (Postfix 2.3-
|
||||
2.5) to hang up on clients that that match botnet-related RBLs (see next
|
||||
bullet) or that match selected non-RBL restrictions such as SMTP access
|
||||
maps. The Postfix SMTP server will reject mail and disconnect without
|
||||
waiting for the remote SMTP client to send a QUIT command.
|
||||
|
||||
* To hang up connections from denylisted zombies, you can set specific
|
||||
Postfix SMTP server reject codes for specific RBLs, and for individual
|
||||
responses from specific RBLs. We'll use zen.spamhaus.org as an example; by
|
||||
the time you read this document, details may have changed. Right now, their
|
||||
documents say that a response of 127.0.0.10 or 127.0.0.11 indicates a
|
||||
dynamic client IP address, which means that the machine is probably running
|
||||
a bot of some kind. To give a 521 response instead of the default 554
|
||||
response, use something like:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_client_restrictions =
|
||||
3 permit_mynetworks
|
||||
4 reject_rbl_client zen.spamhaus.org=127.0.0.10
|
||||
5 reject_rbl_client zen.spamhaus.org=127.0.0.11
|
||||
6 reject_rbl_client zen.spamhaus.org
|
||||
7
|
||||
8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
|
||||
9
|
||||
10 /etc/postfix/rbl_reply_maps:
|
||||
11 # With Postfix 2.3-2.5 use "421" to hang up connections.
|
||||
12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
|
||||
13 $rbl_class [$rbl_what] blocked using
|
||||
14 $rbl_domain${rbl_reason?; $rbl_reason}
|
||||
15
|
||||
16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
|
||||
17 $rbl_class [$rbl_what] blocked using
|
||||
18 $rbl_domain${rbl_reason?; $rbl_reason}
|
||||
|
||||
Although the above example shows three RBL lookups (lines 4-6), Postfix
|
||||
will only do a single DNS query, so it does not affect the performance.
|
||||
|
||||
* With Postfix 2.3-2.5, use reply code 421 (521 will not cause Postfix to
|
||||
disconnect). The down-side of replying with 421 is that it works only for
|
||||
zombies and other malware. If the client is running a real MTA, then it may
|
||||
connect again several times until the mail expires in its queue. When this
|
||||
is a problem, stick with the default 554 reply, and use
|
||||
"smtpd_hard_error_limit = 1" as described below.
|
||||
|
||||
* You can automatically turn on the above overload measure with Postfix 2.5
|
||||
and later, or with earlier releases that contain the stress-adaptive
|
||||
behavior source code patch from the mirrors listed at https://
|
||||
www.postfix.org/download.html. Simply replace line above 8 with:
|
||||
|
||||
8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
|
||||
|
||||
More information about automatic stress-adaptive behavior is in section
|
||||
"Automatic stress-adaptive behavior".
|
||||
|
||||
TTeemmppoorraarryy mmeeaassuurreess ffoorr oollddeerr PPoossttffiixx rreelleeaasseess
|
||||
|
||||
See the section "Automatic stress-adaptive behavior" if you are running Postfix
|
||||
version 2.5 or later, or if you have applied the source code patch for stress-
|
||||
adaptive behavior from the mirrors listed at https://www.postfix.org/
|
||||
download.html.
|
||||
|
||||
The following measures can be applied temporarily during overload. They still
|
||||
allow mmoosstt legitimate clients to connect and send mail, but may affect some
|
||||
legitimate clients.
|
||||
|
||||
* Reduce smtpd_timeout (default: 300s). Experience on the postfix-users list
|
||||
from a variety of sysadmins shows that reducing the "normal" smtpd_timeout
|
||||
to 60s is unlikely to affect legitimate clients. However, it is unlikely to
|
||||
become the Postfix default because it's not RFC compliant. Setting
|
||||
smtpd_timeout to 10s (line 2 below) or even 5s under stress will still
|
||||
allow mmoosstt legitimate clients to connect and send mail, but may delay mail
|
||||
from some clients. No mail should be lost, as long as this measure is used
|
||||
only temporarily.
|
||||
|
||||
* Reduce smtpd_hard_error_limit (default: 20). Setting this to 1 under stress
|
||||
(line 3 below) helps by disconnecting clients after a single error, giving
|
||||
other clients a chance to connect. However, this may cause significant
|
||||
delays with legitimate mail, such as a mailing list that contains a few no-
|
||||
longer-active user names that didn't bother to unsubscribe. No mail should
|
||||
be lost, as long as this measure is used only temporarily.
|
||||
|
||||
* Use an smtpd_junk_command_limit of 1 instead of the default 100. This
|
||||
prevents clients from keeping idle connections open by repeatedly sending
|
||||
NOOP or RSET commands.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 smtpd_timeout = 10
|
||||
3 smtpd_hard_error_limit = 1
|
||||
4 smtpd_junk_command_limit = 1
|
||||
|
||||
With these measures, no mail should be lost, as long as these measures are used
|
||||
only temporarily. The next section of this document introduces a way to
|
||||
automate this process.
|
||||
|
||||
DDeetteeccttiinngg ssuuppppoorrtt ffoorr ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
|
||||
|
||||
To find out if your Postfix installation supports stress-adaptive behavior, use
|
||||
the "ps" command, and look for the smtpd processes. Postfix has stress-adaptive
|
||||
support when you see "-o stress=" or "-o stress=yes" command-line options.
|
||||
Remember that Postfix never enables stress-adaptive behavior on servers that
|
||||
listen on local addresses only.
|
||||
|
||||
The following example is for FreeBSD or Linux. On Solaris, HP-UX and other
|
||||
System-V flavors, use "ps -ef" instead of "ps ax".
|
||||
|
||||
$ ps ax|grep smtpd
|
||||
83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
|
||||
84345 ?? Ss 0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-
|
||||
policy.pl
|
||||
|
||||
You can't use postconf(1) to detect stress-adaptive support. The postconf(1)
|
||||
command ignores the existence of the stress parameter in main.cf, because the
|
||||
parameter has no effect there. Command-line "-o parameter" settings always take
|
||||
precedence over main.cf parameter settings.
|
||||
|
||||
If you configure stress-adaptive behavior in main.cf when it isn't supported,
|
||||
nothing bad will happen. The processes will run as if the stress parameter
|
||||
always has an empty value.
|
||||
|
||||
FFoorrcciinngg ssttrreessss--aaddaappttiivvee bbeehhaavviioorr oonn oorr ooffff
|
||||
|
||||
You can manually force stress-adaptive behavior on, by adding a "-o stress=yes"
|
||||
command-line option in master.cf. This can be useful for testing overrides on
|
||||
the SMTP service. Issue "postfix reload" to make the change effective.
|
||||
|
||||
Note: setting the stress parameter in main.cf has no effect for services that
|
||||
accept remote connections.
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 # =============================================================
|
||||
3 # service type private unpriv chroot wakeup maxproc command
|
||||
4 # =============================================================
|
||||
5 #
|
||||
6 smtp inet n - n - - smtpd
|
||||
7 -o stress=yes
|
||||
8 -o . . .
|
||||
|
||||
To permanently force stress-adaptive behavior off with a specific service,
|
||||
specify "-o stress=" on its master.cf command line. This may be desirable for
|
||||
the "submission" service. Issue "postfix reload" to make the change effective.
|
||||
|
||||
Note: setting the stress parameter in main.cf has no effect for services that
|
||||
accept remote connections.
|
||||
|
||||
1 /etc/postfix/master.cf:
|
||||
2 # =============================================================
|
||||
3 # service type private unpriv chroot wakeup maxproc command
|
||||
4 # =============================================================
|
||||
5 #
|
||||
6 submission inet n - n - - smtpd
|
||||
7 -o stress=
|
||||
8 -o . . .
|
||||
|
||||
OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoommbbiieess
|
||||
|
||||
The postscreen(8) daemon, introduced with Postfix 2.8, provides additional
|
||||
protection against mail server overload. One postscreen(8) process handles
|
||||
multiple inbound SMTP connections, and decides which clients may talk to a
|
||||
Postfix SMTP server process. By keeping spambots away, postscreen(8) leaves
|
||||
more SMTP server processes available for legitimate clients, and delays the
|
||||
onset of server overload conditions.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* Thanks to the postfix-users mailing list members for sharing early
|
||||
experiences with the stress-adaptive feature.
|
||||
* The RBL example and several other paragraphs of text were adapted from
|
||||
postfix-users postings by Noel Jones.
|
||||
* Wietse implemented stress-adaptive behavior as the smallest possible patch
|
||||
while he should be working on other things.
|
||||
|
||||
334
README_FILES/TLSRPT_README
Normal file
334
README_FILES/TLSRPT_README
Normal file
|
|
@ -0,0 +1,334 @@
|
|||
PPoossttffiixx TTLLSSRRPPTT HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
TTaabbllee ooff CCoonntteennttss
|
||||
|
||||
* Introduction
|
||||
* Building Postfix with TLSRPT support
|
||||
* Turning on TLSRPT
|
||||
* TLSRPT Status logging
|
||||
* Delivering TLSRPT summaries via email
|
||||
* MTA-STS Support via smtp_tls_policy_maps
|
||||
* Limitations
|
||||
* Credits
|
||||
|
||||
IInnttrroodduuccttiioonn
|
||||
|
||||
The TLSRPT protocol is defined in RFC 8460. With this, an email receiving
|
||||
domain can publish a policy in DNS, and request daily summary reports for
|
||||
successful and failed SMTP over TLS connections to that domain's MX hosts.
|
||||
Support for TLSRPT was added in Postfix 3.10.
|
||||
|
||||
A policy for domain example.com could look like this:
|
||||
|
||||
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:smtp-tls-
|
||||
report@example.com"
|
||||
|
||||
Instead of mailto:, a policy may specify an https: destination.
|
||||
|
||||
The diagram below shows how Postfix TLS handshake success and failure events
|
||||
are collected and processed into daily summary reports.
|
||||
|
||||
Postfix SMTP and TLSRPT client TLSRPT collector, Email or HTTP
|
||||
TLS client engines -> library (linked -> fetcher, and -> delivery
|
||||
into Postfix) summary generator
|
||||
|
||||
* The Postfix SMTP and TLS client engines will generate a "success" or
|
||||
"failure" event for each TLS handshake,
|
||||
|
||||
* They will pass those events to an in-process TLSRPT client library that
|
||||
sends data over a local socket to
|
||||
|
||||
* A local TLSRPT collector that runs on each Postfix machine. A TLSRPT
|
||||
fetcher gathers information from individual collectors, and a central
|
||||
TLSRPT report generator produces daily summary reports.
|
||||
|
||||
The TLSRPT client library, and the infrastructure to collect, fetch, and report
|
||||
TLSRPT information, are implemented and maintained by sys4 at https://
|
||||
github.com/sys4/libtlsrpt and https://github.com/sys4/tlsrpt-reporter,
|
||||
respectively.
|
||||
|
||||
The Postfix implementation supports TLSRPT or domains with DANE (Postfix built-
|
||||
in) and MTA-STS (through an smtp_tls_policy_maps plug-in).
|
||||
|
||||
The Postfix smtp(8) client process implements the SMTP client engine. With
|
||||
"smtp_tls_connection_reuse = no", the smtp(8) client process also implements
|
||||
the TLS client engine. With "smtp_tls_connection_reuse = yes", the smtp(8)
|
||||
client process delegates TLS processing to a Postfix tlsproxy(8) process.
|
||||
Either way, Postfix will generate the exact same TLSRPT events.
|
||||
|
||||
BBuuiillddiinngg PPoossttffiixx wwiitthh TTLLSSRRPPTT ssuuppppoorrtt
|
||||
|
||||
These instructions assume that you build Postfix from source code as described
|
||||
in the INSTALL document. Some modification may be required if you build Postfix
|
||||
from a vendor-specific source package.
|
||||
|
||||
The Postfix TLSRPT client builds on a TLSRPT library which may be available as
|
||||
a built package (rpm, deb, etc.), or which you can build from source code from:
|
||||
|
||||
https://github.com/sys4/libtlsrpt
|
||||
|
||||
The library is typically installed as a header file in /usr/local/include/
|
||||
tlsrpt.h and an object library in /usr/local/lib/libtlsrpt.a or /usr/local/lib/
|
||||
libtlsrpt.so. The actual pathnames will depend on OS platform conventions.
|
||||
|
||||
In order to build Postfix with TLSRPT support, you will need to add compiler
|
||||
options -DUSE_TLSRPT (to build with TLSRPT support) and -I (with the directory
|
||||
containing the tlsrpt.h header file), and you will need to add linker options
|
||||
to link with the TLSRPT client library, for example:
|
||||
|
||||
make -f Makefile.init makefiles \
|
||||
"CCARGS=-DUSE_TLSRPT -I/usr/local/include" \
|
||||
"AUXLIBS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
|
||||
|
||||
(On Solaris systems you may need to use "-Wl,-R" instead of "-Wl,-rpath".)
|
||||
|
||||
Then, just run 'make'.
|
||||
|
||||
Note: if your build command line already has CCARGS or AUXLIBS settings,
|
||||
then simply append the above settings to the existing CCARGS or AUXLIBS
|
||||
values:
|
||||
|
||||
make -f Makefile.init makefiles \
|
||||
"CCARGS=... -DUSE_TLSRPT -I/usr/local/include" \
|
||||
"AUXLIBS=... -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
|
||||
|
||||
TTuurrnniinngg oonn TTLLSSRRPPTT
|
||||
|
||||
After installing Postfix TLSRPT support, you can enable TLSRPT support in
|
||||
main.cf like this:
|
||||
|
||||
smtp_tlsrpt_enable = yes
|
||||
smtp_tlsrpt_socket_name = path/to/socket
|
||||
|
||||
The smtp_tlsrpt_socket_name parameter specifies either an absolute pathname, or
|
||||
a pathname that is relative to $queue_directory.
|
||||
|
||||
Notes:
|
||||
|
||||
* The recommended socket location is still to be determined. A good socket
|
||||
location would be under the Postfix queue directory, for example:
|
||||
"smtp_tlsrpt_socket_name = run/tlsrpt/tlsrpt.sock". The advantage of using
|
||||
a relative name is that it will work equally well whether or not Postfix
|
||||
chroot is turned on.
|
||||
|
||||
* Regardless of whether Postfix chroot is enabled, the TLSRPT receiver
|
||||
(tlsrpt_collectd) will need to be configured with the socket's absolute
|
||||
pathname.
|
||||
|
||||
* Do not specify a TLSRPT socket location under a Postfix socket directory
|
||||
such as private or public. Only Postfix programs should create sockets
|
||||
there.
|
||||
|
||||
For details on how to run the TLSRPT collection and reporting infrastructure,
|
||||
see the documentation at https://github.com/sys4/tlsrpt-reporter.
|
||||
|
||||
TTLLSSRRPPTT SSttaattuuss llooggggiinngg
|
||||
|
||||
With TLSRPT support turned on, the Postfix TLSRPT client will not only report
|
||||
an event to an invisible daily success/fail summary queue, but it will also log
|
||||
a visible record to the mail logfile.
|
||||
|
||||
Below are a few examples of logging from a Postfix SMTP client or tlsproxy
|
||||
daemon:
|
||||
|
||||
TLSRPT: status=success, domain=example.com, receiving_mx=mail.example.com
|
||||
[ipaddr]
|
||||
|
||||
TLSRPT: status=failure, domain=example.org, receiving_mx=mail.example.org
|
||||
[ipaddr],
|
||||
failure_type=starttls_not_supported
|
||||
|
||||
TLSRPT: status=failure, domain=example.net, receiving_mx=mail.example.net
|
||||
[ipaddr],
|
||||
failure_type=validation_failure, failure_reason=self-signed_certificate
|
||||
|
||||
Notes:
|
||||
|
||||
* Postfix logs and reports the TLSRPT status only for TLS handshakes on a new
|
||||
SMTP connection. There is no TLS handshake, and thus no TLSRPT status
|
||||
logging, when an SMTP connection is reused. Such connections have Postfix
|
||||
SMTP client logging like this:
|
||||
|
||||
Verified TTLLSS ccoonnnneeccttiioonn rreeuusseedd to mail.example.com[ipaddr]:25:
|
||||
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
|
||||
|
||||
Untrusted TTLLSS ccoonnnneeccttiioonn rreeuusseedd to mail.example.com[ipaddr]:25:
|
||||
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
|
||||
|
||||
* By default, Postfix does not report the TLSRPT status for a TLS handshake
|
||||
that reuses a previously-negotiated TLS session (there would be no new
|
||||
information to report). Specify "smtp_tlsrpt_skip_reused_handshakes = no"
|
||||
to report the TLSRPT status for all TLS handshakes. This may be useful for
|
||||
troubleshooting.
|
||||
|
||||
* Postfix logging for certificate verification failures may differ between
|
||||
new or reused TLS sessions.
|
||||
|
||||
o New TLS session:
|
||||
|
||||
TLSRPT: status=failure, domain=example.org,
|
||||
receiving_mx=mail.example.org[ipaddr],
|
||||
ffaaiilluurree__ttyyppee==vvaalliiddaattiioonn__ffaaiilluurree, ffaaiilluurree__rreeaassoonn==sseellff--
|
||||
ssiiggnneedd__cceerrttiiffiiccaattee
|
||||
|
||||
o Reused TLS session:
|
||||
|
||||
mail.example.org[ipaddr]:25: rree--uussiinngg sseessssiioonn with untrusted peer
|
||||
credential, look for details earlier in the log
|
||||
TLSRPT: status=failure, domain=example.org,
|
||||
receiving_mx=mail.example.org[ipaddr],
|
||||
ffaaiilluurree__ttyyppee==cceerrttiiffiiccaattee__nnoott__ttrruusstteedd
|
||||
|
||||
The logging may differ because a reused TLS session does not have the
|
||||
details for why TLS authentication failed.
|
||||
|
||||
DDeelliivveerriinngg TTLLSSRRPPTT ssuummmmaarriieess vviiaa eemmaaiill
|
||||
|
||||
RFC 8460 Section 3 specifies that an MTA must not enforce TLS security when
|
||||
sending failure reports via email.
|
||||
|
||||
Options:
|
||||
|
||||
* In an email report, specify the "TTLLSS--RReeqquuiirreedd:: nnoo" message header, defined
|
||||
in RFC 8689, to reduce the Postfix SMTP client TLS security level to "mmaayy"
|
||||
(that is, do not verify remote SMTP server certificates, and fall back to
|
||||
plaintext if TLS is unavailable).
|
||||
|
||||
This feature is available in Postfix 3.10 and later. If your outbound MTAs
|
||||
run an older version, you can use one of the options described below.
|
||||
|
||||
* Do nothing. When TLS security enforcement is required but fails, a TLSRPT
|
||||
summary message will be delayed until the problem is addressed, or until
|
||||
the message expires in the mail queue. Keep in mind that TLSRPT is not a
|
||||
real-time monitoring service; it takes on average 12 hours before a failure
|
||||
is reported through TLSRPT.
|
||||
|
||||
* On outbound MTAs that don't support the "TTLLSS--RReeqquuiirreedd:: nnoo" header feature
|
||||
(such as Postfix 3.9 and earlier), disable TLS security enforcement for the
|
||||
sender of TLSRPT summaries. Implement the configuration below on outbound
|
||||
MTA instances (replace noreply-smtp-tls-reporting@example.com with your
|
||||
actual report generator's sender address):
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Limitation: this setting is overruled with transport_maps.
|
||||
sender_dependent_default_transport_maps = inline:{
|
||||
{ noreply-smtp-tls-reporting@example.com = allow-plaintext } }
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# service name type private unpriv chroot wakeup maxproc
|
||||
command
|
||||
allow-plaintext unix - - - - - smtp
|
||||
-o { smtp_tls_security_level = may }
|
||||
-o { smtp_tls_policy_maps = static:may }
|
||||
|
||||
MMTTAA--SSTTSS SSuuppppoorrtt vviiaa ssmmttpp__ttllss__ppoolliiccyy__mmaappss
|
||||
|
||||
Postfix supports MTA-STS though an smtp_tls_policy_maps policy plugin, which
|
||||
replies with a TLS security level and name=value attributes with certificate
|
||||
matching requirements. Postfix 3.10 and later extend the policy plugin response
|
||||
with additional name=value attributes that are needed for TLSRPT.
|
||||
|
||||
Examples of smtp_tls_policy_maps plugins with MTA-STS support are:
|
||||
|
||||
* postfix-tlspol, supports domains with DANE (using Postfix built-in DANE),
|
||||
and domains with MTA-STS.
|
||||
|
||||
* postfix-mta-sts-resolver, supports domains with MTA-STS as of release 1.5.0
|
||||
(February 2025).
|
||||
|
||||
Both plugins can generate the additional name=value attributes that Postfix
|
||||
needs for TLSRPT support (as of February 2025). This is enabled by setting a
|
||||
tlsrpt boolean in a plugin configuration file. This setting is safe with
|
||||
Postfix 3.10 and later, even if Postfix TLSRPT support is disabled (at build
|
||||
time or at run time). Postfix versions 3.9 and earlier will report a policy
|
||||
error with "invalid attribute name".
|
||||
|
||||
The examples in the text below apply to this MTA-STS policy example given in
|
||||
RFC 8461 Section 3.2:
|
||||
|
||||
version: STSv1
|
||||
mode: enforce
|
||||
mx: mail.example.com
|
||||
mx: *.example.net
|
||||
mx: backupmx.example.com
|
||||
max_age: 604800
|
||||
|
||||
The list of supported attributes is given below. Instead of name=value, specify
|
||||
{ name = value } when a value may contain whitespace. A policy response may
|
||||
contain line breaks.
|
||||
|
||||
* policy_type=type
|
||||
|
||||
Specify sts or no-policy-found.
|
||||
|
||||
Example: policy_type=sts
|
||||
|
||||
* policy_domain=name
|
||||
|
||||
The domain that the MTA-STS policy applies to.
|
||||
|
||||
Example: policy_domain=example.com
|
||||
|
||||
* { policy_string = value }
|
||||
|
||||
Specify one policy_string instance for each MTA-STS policy feature,
|
||||
enclosed inside "{" and "}" to protect whitespace in attribute values.
|
||||
|
||||
Example: { policy_string = version: STSv1 } { policy_string = mode: enforce
|
||||
} ...
|
||||
|
||||
The above form ignores whitespace after the opening "{", around the "=",
|
||||
and before the closing "}".
|
||||
|
||||
* mx_host_pattern=pattern
|
||||
|
||||
Specify one mx_host_pattern instance for each "mx:" feature in the MTA-STS
|
||||
policy.
|
||||
|
||||
Example: mx_host_pattern=mail.example.com mx_host_pattern=*.example.net ...
|
||||
|
||||
* policy_failure=type
|
||||
|
||||
If specified, forces MTA-STS policy enforcement to fail with the indicated
|
||||
error, even if a server certificate would satisfy conventional PKI
|
||||
constraints. Valid errors are sts-policy-fetch-error, sts-policy-invalid,
|
||||
sts-webpki-invalid, or the less informative validation-failure.
|
||||
|
||||
Example: policy_failure=sts-webpki-invalid
|
||||
|
||||
* policy_ttl=time (deprecated)
|
||||
|
||||
This attribute is deprecated. The time value is not used, and support for
|
||||
this attribute will eventually be removed from the code.
|
||||
|
||||
Notes:
|
||||
|
||||
* Postfix 3.10 and later will accept these additional attributes in an MTA-
|
||||
STS response even if Postfix TLSRPT support is disabled (at build time or
|
||||
at run time). With Postfix TLSRPT support turned off, Postfix may still use
|
||||
the policy_failure attribute, and will ignore the attributes that are used
|
||||
only for TLSRPT.
|
||||
|
||||
* It is an error to specify these attributes for a non-STS policy.
|
||||
|
||||
LLiimmiittaattiioonnss
|
||||
|
||||
The Postfix TLSRPT implementation reports only TLS handshake success or
|
||||
failure. It does not report failure to connect, or connections that break
|
||||
before or after a TLS handshake.
|
||||
|
||||
The Postfix TLSRPT implementation reports at most one final TLS handshake
|
||||
status (either 'success' or 'failure') per SMTP connection. Postfix TLSRPT will
|
||||
not report a recoverable failure and then later report a final status of
|
||||
'success' for that same connection. The reason is that it's too complicated to
|
||||
filter TLS errors and to report error details from the TLS engine back to the
|
||||
SMTP protocol engine. It just is not how Postfix works internally.
|
||||
|
||||
CCrreeddiittss
|
||||
|
||||
* The TLSRPT client library, and the infrastructure to collect, fetch, and
|
||||
report TLSRPT information, are implemented and maintained by sys4.
|
||||
* Wietse Venema implemented the integration with Postfix.
|
||||
|
||||
1119
README_FILES/TLS_LEGACY_README
Normal file
1119
README_FILES/TLS_LEGACY_README
Normal file
File diff suppressed because it is too large
Load diff
2478
README_FILES/TLS_README
Normal file
2478
README_FILES/TLS_README
Normal file
File diff suppressed because it is too large
Load diff
494
README_FILES/TUNING_README
Normal file
494
README_FILES/TUNING_README
Normal file
|
|
@ -0,0 +1,494 @@
|
|||
PPoossttffiixx PPeerrffoorrmmaannccee TTuunniinngg
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff PPoossttffiixx ppeerrffoorrmmaannccee ttuunniinngg
|
||||
|
||||
The hints and tips in this document help you improve the performance of Postfix
|
||||
systems that already work. If your Postfix system is unable to receive or
|
||||
deliver mail, then you need to solve those problems first, using the
|
||||
DEBUG_README document as guidance.
|
||||
|
||||
For tuning external content filter performance, first read the respective
|
||||
information in the FILTER_README and SMTPD_PROXY_README documents. Then make
|
||||
sure to avoid latency in the content filter code. As much as possible avoid
|
||||
performing queries against external data sources with a high or highly variable
|
||||
delay. Your content filter will run with a small concurrency to avoid CPU/
|
||||
memory starvation, and if any latency creeps in, content filter throughput will
|
||||
suffer. High volume environments should avoid RBL lookups, complex database
|
||||
queries and so on.
|
||||
|
||||
Topics on mail receiving performance:
|
||||
|
||||
* General mail receiving performance tips
|
||||
* Doing more work with your SMTP server processes
|
||||
* Slowing down SMTP clients that make many errors
|
||||
* Measures against clients that make too many connections
|
||||
|
||||
Topics on mail delivery performance:
|
||||
|
||||
* General mail delivery performance tips
|
||||
* Tuning the frequency of deferred mail delivery attempts
|
||||
* Tuning the number of simultaneous deliveries
|
||||
* Tuning the number of recipients per delivery
|
||||
|
||||
Other Postfix performance tuning topics:
|
||||
|
||||
* Tuning the number of Postfix processes
|
||||
* Tuning the number of processes on the system
|
||||
* Tuning the number of open files or sockets
|
||||
|
||||
The following tools can be used to measure mail system performance under
|
||||
artificial loads. They are normally not installed with Postfix.
|
||||
|
||||
* smtp-source, SMTP/LMTP message generator
|
||||
* smtp-sink, SMTP/LMTP message dump
|
||||
* qmqp-source, QMQP message generator
|
||||
* qmqp-sink, QMQP message dump
|
||||
|
||||
GGeenneerraall mmaaiill rreecceeiivviinngg ppeerrffoorrmmaannccee ttiippss
|
||||
|
||||
* Read and understand the maildrop queue, incoming queue, and active queue
|
||||
discussions in the QSHAPE_README document.
|
||||
|
||||
* Run a local name server to reduce slow-down due to DNS lookups. If you run
|
||||
multiple Postfix systems, point each local name server to a shared
|
||||
forwarding server to reduce the number of lookups across the upstream
|
||||
network link.
|
||||
|
||||
* Eliminate unnecessary LDAP lookups, by specifying a domain filter. This
|
||||
eliminates lookups for addresses in remote domains, and eliminates lookups
|
||||
of partial addresses. See ldap_table(5) for details.
|
||||
|
||||
When Postfix responds slowly to SMTP clients:
|
||||
|
||||
* Look for obvious signs of trouble as described in the DEBUG_README
|
||||
document, and eliminate those problems first.
|
||||
|
||||
* Turn off your header_checks and body_checks patterns and see if the problem
|
||||
goes away.
|
||||
|
||||
* Turn off chroot operation as described in the DEBUG_README document and see
|
||||
if the problem goes away.
|
||||
|
||||
* If Postfix logs the SMTP client as "unknown" then you have a name service
|
||||
problem: the name server is bad, or the resolv.conf file contains bad
|
||||
information, or some packet filter is blocking the DNS requests or replies.
|
||||
|
||||
* If the number of smtpd(8) processes has reached the process limit as
|
||||
specified in master.cf, new SMTP clients must wait until a process becomes
|
||||
available. See the STRESS_README and POSTSCREEN_README documents for
|
||||
measures that help to prevent SMTP server overload.
|
||||
|
||||
DDooiinngg mmoorree wwoorrkk wwiitthh yyoouurr SSMMTTPP sseerrvveerr pprroocceesssseess
|
||||
|
||||
With Postfix versions 2.0 and earlier, the smtpd(8) server pauses before
|
||||
reporting an error to an SMTP client. The idea is called tar pitting. However,
|
||||
these delays also slow down Postfix. When the smtpd(8) server replies slowly,
|
||||
sessions take more time, so that more smtpd(8) server processes are needed to
|
||||
handle the load. When your Postfix smtpd(8) server process limit is reached,
|
||||
new clients must wait until a server process becomes available. This means that
|
||||
all clients experience poor performance.
|
||||
|
||||
You can speed up the handling of smtpd(8) server error replies by turning off
|
||||
the delay:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Not needed with Postfix 2.1
|
||||
smtpd_error_sleep_time = 0
|
||||
|
||||
With the above setting, Postfix 2.0 and earlier can serve more SMTP clients
|
||||
with the same number SMTP server processes. The next section describes how
|
||||
Postfix deals with clients that make a large number of errors.
|
||||
|
||||
SSlloowwiinngg ddoowwnn SSMMTTPP cclliieennttss tthhaatt mmaakkee mmaannyy eerrrroorrss
|
||||
|
||||
The Postfix smtpd(8) server maintains a per-session error count. The error
|
||||
count is reset when a message is transferred successfully, and is incremented
|
||||
when a client request is unrecognized or unimplemented, when a client request
|
||||
violates access restrictions, or when some other error happens.
|
||||
|
||||
As the per-session error count increases, the smtpd(8) server changes behavior
|
||||
and begins to insert delays into the responses. The idea is to slow down a run-
|
||||
away client in order to limit resource usage. The behavior is Postfix version
|
||||
dependent.
|
||||
|
||||
IMPORTANT: These delays slow down Postfix, too. When too much delay is
|
||||
configured, the number of simultaneous SMTP sessions will increase until it
|
||||
reaches the smtpd(8) server process limit, and new SMTP clients must wait until
|
||||
an smtpd(8) server process becomes available.
|
||||
|
||||
Postfix version 2.1 and later:
|
||||
|
||||
* When the error count reaches $smtpd_soft_error_limit (default: 10), the
|
||||
Postfix smtpd(8) server delays all non-error and error responses by
|
||||
$smtpd_error_sleep_time seconds (default: 1 second).
|
||||
|
||||
* When the error count reaches $smtpd_hard_error_limit (default: 20) the
|
||||
Postfix smtpd(8) server breaks the connection.
|
||||
|
||||
Postfix version 2.0 and earlier:
|
||||
|
||||
* When the error count is less than $smtpd_soft_error_limit (default: 10) the
|
||||
Postfix smtpd(8) server delays all error replies by $smtpd_error_sleep_time
|
||||
(1 second with Postfix 2.0, 5 seconds with Postfix 1.1 and earlier).
|
||||
|
||||
* When the error count reaches $smtpd_soft_error_limit, the Postfix smtpd(8)
|
||||
server delays all responses by "error count" seconds or
|
||||
$smtpd_error_sleep_time, whichever is more.
|
||||
|
||||
* When the error count reaches $smtpd_hard_error_limit (default: 20) the
|
||||
Postfix smtpd(8) server breaks the connection.
|
||||
|
||||
MMeeaassuurreess aaggaaiinnsstt cclliieennttss tthhaatt mmaakkee ttoooo mmaannyy ccoonnnneeccttiioonnss
|
||||
|
||||
Note: these features use the Postfix anvil(8) service, introduced with Postfix
|
||||
version 2.2.
|
||||
|
||||
The Postfix smtpd(8) server can limit the number of simultaneous connections
|
||||
from the same SMTP client, as well as the connection rate and the rate of
|
||||
certain SMTP commands from the same client. These statistics are maintained by
|
||||
the anvil(8) server (translation: if anvil(8) breaks, then connection limits
|
||||
stop working).
|
||||
|
||||
IMPORTANT: These limits must not be used to regulate legitimate traffic: mail
|
||||
will suffer grotesque delays if you do so. The limits are designed to protect
|
||||
the smtpd(8) server against abuse by out-of-control clients.
|
||||
|
||||
smtpd_client_connection_count_limit (default: 50)
|
||||
The maximum number of connections that an SMTP client may make
|
||||
simultaneously.
|
||||
smtpd_client_connection_rate_limit (default: no limit)
|
||||
The maximum number of connections that an SMTP client may make in the
|
||||
time interval specified with anvil_rate_time_unit (default: 60s).
|
||||
smtpd_client_message_rate_limit (default: no limit)
|
||||
The maximum number of message delivery requests that an SMTP client may
|
||||
make in the time interval specified with anvil_rate_time_unit (default:
|
||||
60s).
|
||||
smtpd_client_recipient_rate_limit (default: no limit)
|
||||
The maximum number of recipient addresses that an SMTP client may
|
||||
specify in the time interval specified with anvil_rate_time_unit
|
||||
(default: 60s).
|
||||
smtpd_client_new_tls_session_rate_limit (default: no limit)
|
||||
The maximum number of new TLS sessions (without using the TLS session
|
||||
cache) that an SMTP client may negotiate in the time interval specified
|
||||
with anvil_rate_time_unit (default: 60s).
|
||||
smtpd_client_auth_rate_limit (default: no limit)
|
||||
The maximum number of AUTH commands that an SMTP client may send in the
|
||||
time interval specified with anvil_rate_time_unit (default: 60s).
|
||||
Available in Postfix 3.1 and later.
|
||||
smtpd_client_event_limit_exceptions (default: $mynetworks)
|
||||
SMTP clients that are excluded from connection and rate limits
|
||||
specified above.
|
||||
|
||||
GGeenneerraall mmaaiill ddeelliivveerryy ppeerrffoorrmmaannccee ttiippss
|
||||
|
||||
* Read and understand the maildrop queue, incoming queue, active queue and
|
||||
deferred queue discussions in the QSHAPE_README document.
|
||||
|
||||
* In case of slow delivery, run the qshape tool as described in the
|
||||
QSHAPE_README document.
|
||||
|
||||
* Submit multiple recipients per message instead of submitting messages with
|
||||
only a few recipients.
|
||||
|
||||
* Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to adjust
|
||||
the smtpd_recipient_limit parameter setting.
|
||||
|
||||
* Don't overwhelm the disk with mail submissions. Optimize the mail
|
||||
submission rate by tuning the number of parallel submissions and/or by
|
||||
tuning the Postfix in_flow_delay parameter setting.
|
||||
|
||||
* Run a local name server to reduce slow-down due to DNS lookups. If you run
|
||||
multiple Postfix systems, point each local name server to a shared
|
||||
forwarding server to reduce the number of lookups across the upstream
|
||||
network link.
|
||||
|
||||
* Reduce the smtp_connect_timeout and smtp_helo_timeout values so that
|
||||
Postfix does not waste lots of time connecting to non-responding remote
|
||||
SMTP servers.
|
||||
|
||||
* Use a dedicated mail delivery transport for problematic destinations, with
|
||||
reduced timeouts and with adjusted concurrency. See "Tuning the number of
|
||||
simultaneous deliveries" below.
|
||||
|
||||
* Use a fallback_relay host for mail that cannot be delivered upon the first
|
||||
attempt. This "graveyard" machine can use shorter retry times for difficult
|
||||
to reach destinations. See "Tuning the frequency of deferred mail delivery
|
||||
attempts" below.
|
||||
|
||||
* Speed up disk updates with a large (64MB) persistent write cache. This
|
||||
allows disk updates to be sorted for optimal access speed without
|
||||
compromising file system integrity when the system crashes.
|
||||
|
||||
* Use a solid-state disk (a persistent RAM disk). This is an expensive
|
||||
solution that should be used in combination with short SMTP timeouts and a
|
||||
fallback_relay "graveyard" machine that delivers mail for problem
|
||||
destinations.
|
||||
|
||||
TTuunniinngg tthhee nnuummbbeerr ooff ssiimmuullttaanneeoouuss ddeelliivveerriieess
|
||||
|
||||
Although Postfix can be configured to run 1000 SMTP client processes at the
|
||||
same time, it is rarely desirable that it makes 1000 simultaneous connections
|
||||
to the same remote system. For this reason, Postfix has safety mechanisms in
|
||||
place to avoid this so-called "thundering herd" problem.
|
||||
|
||||
The Postfix queue manager implements the analog of the TCP slow start flow
|
||||
control strategy: when delivering to a site, send a small number of messages
|
||||
first, then increase the concurrency as long as all goes well; reduce
|
||||
concurrency in the face of congestion.
|
||||
|
||||
* The initial_destination_concurrency parameter (default: 5) controls how
|
||||
many messages are initially sent to the same destination before adapting
|
||||
delivery concurrency. Of course, this setting is effective only as long as
|
||||
it does not exceed the process limit and the destination concurrency limit
|
||||
for the specific mail transport channel.
|
||||
|
||||
* The default_destination_concurrency_limit parameter (default: 20) controls
|
||||
how many messages may be sent to the same destination simultaneously. You
|
||||
can override this setting for specific message delivery transports by
|
||||
taking the name of the master.cf entry and appending
|
||||
"_destination_concurrency_limit".
|
||||
|
||||
Examples of transport specific concurrency limits are:
|
||||
|
||||
* The local_destination_concurrency_limit parameter (default: 2) controls how
|
||||
many messages are delivered simultaneously to the same local recipient. The
|
||||
recommended limit is low because delivery to the same mailbox must happen
|
||||
sequentially, so massive parallelism is not useful. Another good reason to
|
||||
limit delivery concurrency to the same recipient: if the recipient has an
|
||||
expensive shell command in her .forward file, or if the recipient is a
|
||||
mailing list manager, you don't want to run too many instances of those
|
||||
processes at the same time.
|
||||
|
||||
* The default smtp_destination_concurrency_limit of 20 seems enough to
|
||||
noticeably load a system without bringing it to its knees. Be careful when
|
||||
changing this to a much larger number.
|
||||
|
||||
The above default values of the concurrency limits work well in a broad range
|
||||
of situations. Knee-jerk changes to these parameters in the face of congestion
|
||||
can actually make problems worse. Specifically, large destination concurrencies
|
||||
should never be the default. They should be used only for transports that
|
||||
deliver mail to a small number of high volume domains.
|
||||
|
||||
A common situation where high concurrency is called for is on gateways relaying
|
||||
a high volume of mail between the Internet and an intranet mail environment.
|
||||
Approximately half the mail (assuming equal volumes inbound and outbound) will
|
||||
be destined for the internal mail hubs. Since the internal mail hubs will be
|
||||
receiving all external mail exclusively from the gateway, it is reasonable to
|
||||
configure the gateway to make greater demands on the capacity of the internal
|
||||
SMTP servers.
|
||||
|
||||
The tuning of the inbound concurrency limits need not be trial and error. A
|
||||
high volume capable mailhub should be able to easily handle 50 or 100 (rather
|
||||
than the default 20) simultaneous connections, especially if the gateway
|
||||
forwards to multiple MX hosts. When all MX hosts are up and accepting
|
||||
connections in a timely fashion, throughput will be high. If any MX host is
|
||||
down and completely unresponsive, the average connection latency rises to at
|
||||
least 1/N * $smtp_connect_timeout, if there are N MX hosts. This limits
|
||||
throughput to at most the destination concurrency * N / $smtp_connect_timeout.
|
||||
|
||||
For example, with a destination concurrency of 100 and 2 MX hosts, each host
|
||||
will handle up to 50 simultaneous connections. If one MX host is down and the
|
||||
default SMTP connection timeout is 30s, the throughput limit is 100 * 2 / 30 ~=
|
||||
6 messages per second. This suggests that high volume destinations with good
|
||||
connectivity and multiple MX hosts need a lower connection timeout, values as
|
||||
low as 5s or even 1s can be used to prevent congestion when one or more, but
|
||||
not all MX hosts are down.
|
||||
|
||||
If necessary, set a higher transport_destination_concurrency_limit (in main.cf
|
||||
since this is a queue manager parameter) and a lower smtp_connect_timeout (with
|
||||
a "-o" override in master.cf since this parameter has no per-transport name)
|
||||
for the relay transport and any transports dedicated for specific high volume
|
||||
destinations.
|
||||
|
||||
TTuunniinngg tthhee nnuummbbeerr ooff rreecciippiieennttss ppeerr ddeelliivveerryy
|
||||
|
||||
The default_destination_recipient_limit parameter (default: 50) controls how
|
||||
many recipients a Postfix delivery agent will send with each copy of an email
|
||||
message. You can override this setting for specific Postfix delivery agents.
|
||||
For example, "uucp_destination_recipient_limit = 100" would limit the number of
|
||||
recipients per UUCP delivery to 100.
|
||||
|
||||
If an email message exceeds the recipient limit for some destination, the
|
||||
Postfix queue manager breaks up the list of recipients into smaller lists.
|
||||
Postfix will attempt to send multiple copies of the message in parallel.
|
||||
|
||||
IMPORTANT: Be careful when increasing the recipient limit per message delivery;
|
||||
some SMTP servers abort the connection when they run out of memory or when a
|
||||
hard recipient limit is reached, so that the message will never be delivered.
|
||||
|
||||
The smtpd_recipient_limit parameter (default: 1000) controls how many
|
||||
recipients the Postfix smtpd(8) server will take per delivery. The default
|
||||
limit is more than any reasonable SMTP client would send. The limit exists to
|
||||
protect the local mail system against a run-away client.
|
||||
|
||||
TTuunniinngg tthhee ffrreeqquueennccyy ooff ddeeffeerrrreedd mmaaiill ddeelliivveerryy aatttteemmppttss
|
||||
|
||||
When a Postfix delivery agent (smtp(8), local(8), etc.) is unable to deliver a
|
||||
message it may blame the message itself, or it may blame the receiving party.
|
||||
|
||||
* When the delivery agent blames the message, the queue manager gives the
|
||||
queue file a time stamp into the future, so it won't be looked at for a
|
||||
while. By default, the amount of time to cool down is the amount of time
|
||||
that has passed since the message arrived. This results in so-called
|
||||
exponential backoff behavior.
|
||||
|
||||
* When the delivery agent blames the receiving party (for example a local
|
||||
recipient user, or a remote host), the queue manager not only advances the
|
||||
queue file time stamp, but also puts the receiving party on a "dead" list
|
||||
so that it will be skipped for some amount of time.
|
||||
|
||||
This process is governed by a bunch of little parameters.
|
||||
|
||||
queue_run_delay (default: 300 seconds; before Postfix 2.4: 1000s)
|
||||
How often the queue manager scans the queue for deferred mail.
|
||||
minimal_backoff_time (default: 300 seconds; before Postfix 2.4: 1000s)
|
||||
The minimal amount of time a message won't be looked at, and the
|
||||
minimal amount of time to stay away from a "dead" destination.
|
||||
maximal_backoff_time (default: 4000 seconds)
|
||||
The maximal amount of time a message won't be looked at after a
|
||||
delivery failure.
|
||||
maximal_queue_lifetime (default: 5 days)
|
||||
How long a message stays in the queue before it is sent back as
|
||||
undeliverable. Specify 0 for mail that should be returned immediately
|
||||
after the first unsuccessful delivery attempt.
|
||||
bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1
|
||||
and later)
|
||||
How long a MAILER-DAEMON message stays in the queue before it is
|
||||
considered undeliverable. Specify 0 for mail that should be tried only
|
||||
once.
|
||||
qmgr_message_recipient_limit (default: 20000)
|
||||
The size of many in-memory queue manager data structures. Among others,
|
||||
this parameter limits the size of the short-term, in-memory list of
|
||||
"dead" destinations. Destinations that don't fit the list are not
|
||||
added.
|
||||
transport_destination_concurrency_failed_cohort_limit
|
||||
Controls when a destination is considered "dead". This parameter is
|
||||
critical with a non-zero transport_destination_rate_delay, with a
|
||||
reduced transport_destination_concurrency_limit, or with a reduced
|
||||
initial_destination_concurrency.
|
||||
|
||||
IMPORTANT: If you increase the frequency of deferred mail delivery attempts, or
|
||||
if you flush the deferred mail queue frequently, then you may find that Postfix
|
||||
mail delivery performance actually becomes worse. The symptoms are as follows:
|
||||
|
||||
* The active queue becomes saturated with mail that has delivery problems.
|
||||
New mail enters the active queue only when an old message is deferred. This
|
||||
is a slow process that usually requires timing out one or more SMTP
|
||||
connections.
|
||||
|
||||
* All available Postfix delivery agents become occupied trying to connect to
|
||||
unreachable sites etc. New mail has to wait until a delivery agent becomes
|
||||
available. This is a slow process that usually requires timing out one or
|
||||
more SMTP connections.
|
||||
|
||||
When mail is being deferred frequently, fixing the problem is always better
|
||||
than increasing the frequency of delivery attempts. However, if you can control
|
||||
only the delivery attempt frequency, consider using a dedicated fallback_relay
|
||||
"graveyard" machine for bad destinations, so that these destinations do not
|
||||
ruin the performance of normal mail deliveries.
|
||||
|
||||
TTuunniinngg tthhee nnuummbbeerr ooff PPoossttffiixx pprroocceesssseess
|
||||
|
||||
The default_process_limit configuration parameter gives direct control over how
|
||||
many daemon processes Postfix will run. As of Postfix 2.0 the default limit is
|
||||
100 SMTP client processes, 100 SMTP server processes, and so on. This may
|
||||
overwhelm systems with little memory, as well as networks with low bandwidth.
|
||||
|
||||
You can change the global process limit by specifying a non-default
|
||||
default_process_limit in the main.cf file. For example, to run up to 10 SMTP
|
||||
client processes, 10 SMTP server processes, and so on:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
default_process_limit = 10
|
||||
|
||||
You need to execute "postfix reload" to make the change effective. This limit
|
||||
is enforced by the Postfix master(8) daemon which does not automatically read
|
||||
main.cf when it changes.
|
||||
|
||||
You can override the process limit for specific Postfix daemons by editing the
|
||||
master.cf file. For example, if you do not wish to receive 100 SMTP messages at
|
||||
the same time, but do not want to change the process limits for other Postfix
|
||||
daemons, you could specify:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# ====================================================================
|
||||
# service type private unpriv chroot wakeup maxproc command + args
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# ====================================================================
|
||||
. . .
|
||||
smtp inet n - - - 10 smtpd
|
||||
. . .
|
||||
|
||||
TTuunniinngg tthhee nnuummbbeerr ooff pprroocceesssseess oonn tthhee ssyysstteemm
|
||||
|
||||
* MacOS X will run out of process slots when you increase Postfix process
|
||||
limits. The following works with OSX 10.4 and OSX 10.5.
|
||||
|
||||
MacOS X kernel parameters can be specified in /etc/sysctl.conf.
|
||||
|
||||
/etc/sysctl.conf:
|
||||
kern.maxproc=2048
|
||||
kern.maxprocperuid=2048
|
||||
|
||||
Unfortunately these can't simply be set on the fly with "sysctl -w". You
|
||||
also have to set the following in /etc/launchd.conf so that the root user
|
||||
after boot will have the right process limit (2048). Otherwise you have to
|
||||
always run ulimit -u 2048 as root, then start a user shell, and then start
|
||||
processes for things to take effect.
|
||||
|
||||
/etc/launchd.conf:
|
||||
limit maxproc 2048
|
||||
|
||||
Once these are in place, reboot the system. After that, the limits will
|
||||
stay in place.
|
||||
|
||||
TTuunniinngg tthhee nnuummbbeerr ooff ooppeenn ffiilleess oorr ssoocckkeettss
|
||||
|
||||
When Postfix opens too many files or sockets, processes will abort with fatal
|
||||
errors, and the system may log "file table full" errors.
|
||||
|
||||
* Depending on your Postfix and operating system versions you may need to
|
||||
recompile Postfix if you need more than 1024 file descriptors per process:
|
||||
|
||||
o No recompilation is needed for Postfix version 2.4 and later, when it
|
||||
was compiled for systems that support BSD kqueue(2) (FreeBSD 4.1,
|
||||
NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or Linux 2.6 epoll(4).
|
||||
|
||||
o Otherwise, Postfix needs to be recompiled to override the default
|
||||
FD_SETSIZE value.
|
||||
|
||||
* Reduce the number of processes as described under "Tuning the number of
|
||||
Postfix processes" above. Fewer processes need fewer open files and
|
||||
sockets.
|
||||
|
||||
* Configure the kernel for more open files and sockets. The details are
|
||||
extremely system dependent and change with the operating system version. Be
|
||||
sure to verify the following information with your system tuning guide:
|
||||
|
||||
o Some FreeBSD kernel parameters can be specified in /boot/loader.conf,
|
||||
and some can be specified in /etc/sysctl.conf or changed with sysctl
|
||||
commands. Which is which depends on the version.
|
||||
|
||||
kern.ipc.maxsockets="5000"
|
||||
kern.ipc.nmbclusters="65536"
|
||||
kern.maxproc="2048"
|
||||
kern.maxfiles="16384"
|
||||
kern.maxfilesperproc="16384"
|
||||
|
||||
o Linux kernel parameters can be specified in /etc/sysctl.conf or changed
|
||||
with sysctl commands:
|
||||
|
||||
fs.file-max=16384
|
||||
kernel.threads-max=2048
|
||||
|
||||
o Solaris kernel parameters can be specified in /etc/system, as described
|
||||
in the Solaris FAQ entry titled "How can I increase the number of file
|
||||
descriptors per process?"
|
||||
|
||||
* set hard limit on file descriptors
|
||||
set rlim_fd_max = 4096
|
||||
* set soft limit on file descriptors
|
||||
set rlim_fd_cur = 1024
|
||||
|
||||
45
README_FILES/ULTRIX_README
Normal file
45
README_FILES/ULTRIX_README
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
PPoossttffiixx aanndd UUllttrriixx
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPoossttffiixx oonn UUllttrriixx
|
||||
|
||||
This document is probably only of historical value, because Ultrix version 4
|
||||
dates from the early 1990s. However, as long as Wietse keeps Postfix alive for
|
||||
SunOS 4, it is likely to run on Ultrix 4 with very little change. Feedback is
|
||||
welcome if anyone actually still uses Postfix on any version of Ultrix.
|
||||
|
||||
The source of this document is an email message by Christian von Roques that
|
||||
was sent on Jun 2, 1999.
|
||||
|
||||
I've upgraded the MTA of our DECstation-3100 running Ultrix4.3a to postfix-
|
||||
19990317-pl05 and am sending you the patches I needed to get it running
|
||||
under Ultrix.
|
||||
|
||||
. . .
|
||||
|
||||
One of the bugs of Ultrix's /bin/sh is that shell-variables set in
|
||||
arguments of `:' expand to garbage if expanded in here-documents. Using a
|
||||
different shell helps. I needed to replace all calls of ``sh .../makedefs''
|
||||
by ``$(SHELL) .../makedefs'' in all the Makefile.in and am now able to use
|
||||
``make SHELL=/bin/sh5'' or zsh.
|
||||
|
||||
. . .
|
||||
|
||||
Ultrix's FD_SET_SIZE is 4096, but getdtablesize() returns 64 by default, if
|
||||
not increased when building a new kernel. getrlimit() doesn't know
|
||||
RLIMIT_NOFILE. This makes event_init() always log the warning: `could
|
||||
allocate space for only 64 open files'.
|
||||
|
||||
I just reduced the threshold from 256 to 64, but this is not good. The
|
||||
initial problem still remains: How to disable this warning on Ultrix
|
||||
without making the source ugly?
|
||||
|
||||
To work around the first problem, all the Makefile.in files have been updated
|
||||
to use `$(SHELL)' instead of `sh'. So you only need to supply a non-default
|
||||
shell in order to eliminate Ultrix shell trouble.
|
||||
|
||||
To work around the latter, util/sys_defs.h was updated for Ultrix, with a
|
||||
default FD_SETSIZE of 100. This should be sufficient for a workstation. Even in
|
||||
1999, no-one would run a major mail hub on Ultrix 4.
|
||||
|
||||
121
README_FILES/UUCP_README
Normal file
121
README_FILES/UUCP_README
Normal file
|
|
@ -0,0 +1,121 @@
|
|||
PPoossttffiixx aanndd UUUUCCPP
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
UUssiinngg UUUUCCPP oovveerr TTCCPP
|
||||
|
||||
Despite a serious lack of sex-appeal, email via UUCP over TCP is a practical
|
||||
option for sites without permanent Internet connections, and for sites without
|
||||
a fixed IP address. For first-hand information, see the following guides:
|
||||
|
||||
* Jim Seymour's guide for using UUCP over TCP at https://jimsun.LinxNet.com/
|
||||
jdp/uucp_over_tcp/index.html,
|
||||
* Craig Sanders's guide for SSL-encrypted UUCP over TCP using stunnel at
|
||||
http://taz.net.au/postfix/uucp/.
|
||||
|
||||
Here's a graphical description of what this document is about:
|
||||
|
||||
LAN to Internet
|
||||
Local network <---> UUCP <--- UUCP ---> to UUCP <---> Internet
|
||||
Gateway Gateway
|
||||
|
||||
And here's the table of contents of this document:
|
||||
|
||||
* Setting up a Postfix Internet to UUCP gateway
|
||||
* Setting up a Postfix LAN to UUCP gateway
|
||||
|
||||
SSeettttiinngg uupp aa PPoossttffiixx IInntteerrnneett ttoo UUUUCCPP ggaatteewwaayy
|
||||
|
||||
Here is how to set up a machine that sits on the Internet and that forwards
|
||||
mail to a LAN that is connected via UUCP. See the LAN to UUCP gateway section
|
||||
for the other side of the story.
|
||||
|
||||
* You need an rrmmaaiill program that extracts the sender address from mail that
|
||||
arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
|
||||
command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
|
||||
pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
|
||||
rrmmaaiill directory.
|
||||
|
||||
* Define a pipe(8) based mail delivery transport for delivery via UUCP:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
uucp unix - n n - - pipe
|
||||
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
|
||||
($recipient)
|
||||
|
||||
This runs the uuuuxx command to place outgoing mail into the UUCP queue after
|
||||
replacing $nexthop by the next-hop hostname (the receiving UUCP host) and
|
||||
after replacing $recipient by the recipients. The pipe(8) delivery agent
|
||||
executes the uuuuxx command without assistance from the shell, so there are no
|
||||
problems with shell meta characters in command-line parameters.
|
||||
|
||||
* Specify that mail for example.com, should be delivered via UUCP, to a host
|
||||
named uucp-host:
|
||||
|
||||
/etc/postfix/transport:
|
||||
example.com uucp:uucp-host
|
||||
.example.com uucp:uucp-host
|
||||
|
||||
See the transport(5) manual page for more details.
|
||||
|
||||
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change
|
||||
the ttrraannssppoorrtt file.
|
||||
|
||||
* Enable ttrraannssppoorrtt table lookups:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
|
||||
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
|
||||
files. To find out what map types Postfix supports, use the command
|
||||
"ppoossttccoonnff --mm".
|
||||
|
||||
* Add example.com to the list of domains that your site is willing to relay
|
||||
mail for.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relay_domains = example.com ...other relay domains...
|
||||
|
||||
See the relay_domains configuration parameter description for details.
|
||||
|
||||
* Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
|
||||
|
||||
SSeettttiinngg uupp aa PPoossttffiixx LLAANN ttoo UUUUCCPP ggaatteewwaayy
|
||||
|
||||
Here is how to relay mail from a LAN via UUCP to the Internet. See the Internet
|
||||
to UUCP gateway section for the other side of the story.
|
||||
|
||||
* You need an rrmmaaiill program that extracts the sender address from mail that
|
||||
arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
|
||||
command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
|
||||
pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
|
||||
rrmmaaiill directory.
|
||||
|
||||
* Specify that all remote mail must be sent via the uuuuccpp mail transport to
|
||||
your UUCP gateway host, say, uucp-gateway:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = uucp-gateway
|
||||
default_transport = uucp
|
||||
|
||||
Postfix 2.0 and later also allows the following more succinct form:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
default_transport = uucp:uucp-gateway
|
||||
|
||||
* Define a pipe(8) based message delivery transport for mail delivery via
|
||||
UUCP:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
uucp unix - n n - - pipe
|
||||
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
|
||||
($recipient)
|
||||
|
||||
This runs the uuuuxx command to place outgoing mail into the UUCP queue. It
|
||||
substitutes the next-hop hostname (uucp-gateway, or whatever you specified)
|
||||
and the recipients before executing the command. The uuuuxx command is
|
||||
executed without assistance from the shell, so there are no problems with
|
||||
shell meta characters.
|
||||
|
||||
* Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
|
||||
|
||||
186
README_FILES/VERP_README
Normal file
186
README_FILES/VERP_README
Normal file
|
|
@ -0,0 +1,186 @@
|
|||
PPoossttffiixx VVEERRPP HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPoossttffiixx VVEERRPP ssuuppppoorrtt
|
||||
|
||||
Postfix versions 1.1 and later support variable envelope return path addresses
|
||||
on request. When VERP style delivery is requested, each recipient of a message
|
||||
receives a customized copy of the message, with his/her own recipient address
|
||||
encoded in the envelope sender address.
|
||||
|
||||
For example, when VERP style delivery is requested, Postfix delivers mail from
|
||||
"owner-listname@origin" for a recipient "user@domain", with a sender address
|
||||
that encodes the recipient as follows:
|
||||
|
||||
owner-listname+user=domain@origin
|
||||
|
||||
Thus, undeliverable mail can reveal the undeliverable recipient address without
|
||||
requiring the list owner to parse bounce messages.
|
||||
|
||||
The VERP concept was popularized by the qmail MTA and by the ezmlm mailing list
|
||||
manager. See https://cr.yp.to/proto/verp.txt for the ideas behind this concept.
|
||||
|
||||
Topics covered in this document:
|
||||
|
||||
* Postfix VERP configuration parameters
|
||||
* Using VERP with majordomo etc. mailing lists
|
||||
* VERP support in the Postfix SMTP server
|
||||
* VERP support in the Postfix sendmail command
|
||||
* VERP support in the Postfix QMQP server
|
||||
|
||||
PPoossttffiixx VVEERRPP ccoonnffiigguurraattiioonn ppaarraammeetteerrss
|
||||
|
||||
With Postfix, the whole process is controlled by four configuration parameters.
|
||||
|
||||
default_verp_delimiters (default value: +=)
|
||||
What VERP delimiter characters Postfix uses when VERP style delivery is
|
||||
requested but no explicit delimiters are specified.
|
||||
|
||||
verp_delimiter_filter (default: -+=)
|
||||
What characters Postfix accepts as VERP delimiter characters on the
|
||||
sendmail command line and in SMTP commands. Many characters must not be
|
||||
used as VERP delimiter characters, either because they already have a
|
||||
special meaning in email addresses (such as the @ or the %), because they
|
||||
are used as part of a username or domain name (such as alphanumerics), or
|
||||
because they are non-ASCII or control characters. And who knows, some
|
||||
characters may tickle bugs in vulnerable software, and we would not want
|
||||
that to happen.
|
||||
|
||||
smtpd_authorized_verp_clients (default value: none)
|
||||
What SMTP clients are allowed to request VERP style delivery. The Postfix
|
||||
QMQP server uses its own access control mechanism, and local submission
|
||||
(via /usr/sbin/sendmail etc.) is always authorized. To authorize a host,
|
||||
list its name, IP address, subnet (net/mask) or parent .domain.
|
||||
|
||||
With Postfix versions 1.1 and 2.0, this parameter is called
|
||||
authorized_verp_clients (default: $mynetworks).
|
||||
|
||||
disable_verp_bounces (default: no)
|
||||
Send one bounce report for multi-recipient VERP mail, instead of one bounce
|
||||
report per recipient. The default, one per recipient, is what ezmlm needs.
|
||||
|
||||
UUssiinngg VVEERRPP wwiitthh mmaajjoorrddoommoo eettcc.. mmaaiilliinngg lliissttss
|
||||
|
||||
In order to make VERP useful with majordomo etc. mailing lists, you would
|
||||
configure the list manager to submit mail according to one of the following two
|
||||
forms:
|
||||
|
||||
Postfix 2.3 and later:
|
||||
|
||||
% sendmail -XV -f owner-listname other-arguments...
|
||||
|
||||
% sendmail -XV+= -f owner-listname other-arguments...
|
||||
|
||||
Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
|
||||
compatibility, but will log a warning that reminds you of the new syntax):
|
||||
|
||||
% sendmail -V -f owner-listname other-arguments...
|
||||
|
||||
% sendmail -V+= -f owner-listname other-arguments...
|
||||
|
||||
The first form uses the default main.cf VERP delimiter characters. The second
|
||||
form allows you to explicitly specify the VERP delimiter characters. The
|
||||
example shows the recommended values.
|
||||
|
||||
This text assumes that you have set up an owner-listname alias that routes
|
||||
undeliverable mail to a real person:
|
||||
|
||||
/etc/aliases:
|
||||
owner-listname: yourname+listname
|
||||
|
||||
In order to process bounces we are going to make extensive use of address
|
||||
extension tricks.
|
||||
|
||||
You need to tell Postfix that + is the separator between an address and its
|
||||
optional address extension, that address extensions are appended to .forward
|
||||
file names, and that address extensions are to be discarded when doing alias
|
||||
expansions:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
recipient_delimiter = +
|
||||
forward_path = $home/.forward${recipient_delimiter}${extension},
|
||||
$home/.forward
|
||||
propagate_unmatched_extensions = canonical, virtual
|
||||
|
||||
(the last two parameter settings are default settings).
|
||||
|
||||
You need to set up a file named .forward+listname with the commands that
|
||||
process all the mail that is sent to the owner-listname address:
|
||||
|
||||
~/.forward+listname:
|
||||
"|/some/where/command ..."
|
||||
|
||||
With this set up, undeliverable mail for user@domain will be returned to the
|
||||
following address:
|
||||
|
||||
owner-listname+user=domain@your.domain
|
||||
|
||||
which is processed by the command in your .forward+listname file. The message
|
||||
should contain, among others, a To: header with the encapsulated recipient
|
||||
sender address:
|
||||
|
||||
To: owner-listname+user=domain@your.domain
|
||||
|
||||
It is left as an exercise for the reader to parse the To: header line and to
|
||||
pull out the user=domain part from the recipient address.
|
||||
|
||||
VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
|
||||
|
||||
The Postfix SMTP server implements a command XVERP to enable VERP style
|
||||
delivery. The syntax allows two forms:
|
||||
|
||||
MAIL FROM:<sender@domain> XVERP
|
||||
|
||||
MAIL FROM:<sender@domain> XVERP=+=
|
||||
|
||||
The first form uses the default main.cf VERP delimiters, the second form
|
||||
overrides them explicitly. The values shown are the recommended ones.
|
||||
|
||||
You can use the smtpd_command_filter feature to append XVERP to SMTP commands
|
||||
from legacy software. This requires Postfix 2.7 or later.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_command_filter = pcre:/etc/postfix/append_verp.pcre
|
||||
smtpd_authorized_verp_clients = $mynetworks
|
||||
|
||||
/etc/postfix/append_verp.pcre:
|
||||
/^(MAIL FROM:<listname@example\.com>.*)/ $1 XVERP
|
||||
|
||||
VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx sseennddmmaaiill ccoommmmaanndd
|
||||
|
||||
The Postfix sendmail command has a -V flag to request VERP style delivery.
|
||||
Specify one of the following two forms:
|
||||
|
||||
Postfix 2.3 and later:
|
||||
|
||||
% sendmail -XV -f owner-listname ....
|
||||
|
||||
% sendmail -XV+= -f owner-listname ....
|
||||
|
||||
Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
|
||||
compatibility, but will log a warning that reminds you of the new syntax):
|
||||
|
||||
% sendmail -V -f owner-listname ....
|
||||
|
||||
% sendmail -V+= -f owner-listname ....
|
||||
|
||||
The first form uses the default main.cf VERP delimiters, the second form
|
||||
overrides them explicitly. The values shown are the recommended ones.
|
||||
|
||||
VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx QQMMQQPP sseerrvveerr
|
||||
|
||||
When the Postfix QMQP server receives mail with an envelope sender address of
|
||||
the form:
|
||||
|
||||
listname-@your.domain-@[]
|
||||
|
||||
Postfix generates sender addresses "listname-user=domain@your.domain", using "-
|
||||
=" as the VERP delimiters because qmail/ezmlm expect this.
|
||||
|
||||
More generally, a sender address of "prefix@origin-@[]" requests VERP style
|
||||
delivery with sender addresses of the form "prefixuser=domain@origin". However,
|
||||
Postfix allows only VERP delimiters that are specified with the
|
||||
verp_delimiter_filter parameter. In particular, the "=" delimiter is required
|
||||
for qmail compatibility (see the qmail addresses(5) manual page for details).
|
||||
|
||||
483
README_FILES/VIRTUAL_README
Normal file
483
README_FILES/VIRTUAL_README
Normal file
|
|
@ -0,0 +1,483 @@
|
|||
PPoossttffiixx VViirrttuuaall DDoommaaiinn HHoossttiinngg HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
|
||||
|
||||
This document requires Postfix version 2.0 or later.
|
||||
|
||||
This document gives an overview of how Postfix can be used for hosting multiple
|
||||
Internet domains, both for final delivery on the machine itself and for the
|
||||
purpose of forwarding to destinations elsewhere.
|
||||
|
||||
The text not only describes delivery mechanisms that are built into Postfix,
|
||||
but also gives pointers for using non-Postfix mail delivery software.
|
||||
|
||||
The following topics are covered:
|
||||
|
||||
* Canonical versus hosted versus other domains
|
||||
* Local files versus network databases
|
||||
* As simple as can be: shared domains, UNIX system accounts
|
||||
* Postfix virtual ALIAS example: separate domains, UNIX system accounts
|
||||
* Postfix virtual MAILBOX example: separate domains, non-UNIX accounts
|
||||
* Non-Postfix mailbox store: separate domains, non-UNIX accounts
|
||||
* Mail forwarding domains
|
||||
* Mailing lists
|
||||
* Autoreplies
|
||||
|
||||
CCaannoonniiccaall vveerrssuuss hhoosstteedd vveerrssuuss ootthheerr ddoommaaiinnss
|
||||
|
||||
Most Postfix systems are the ffiinnaall ddeessttiinnaattiioonn for only a few domain names.
|
||||
These include the hostnames and [the IP addresses] of the machine that Postfix
|
||||
runs on, and sometimes also include the parent domain of the hostname. The
|
||||
remainder of this document will refer to these domains as the canonical
|
||||
domains. They are usually implemented with the Postfix local domain address
|
||||
class, as defined in the ADDRESS_CLASS_README file.
|
||||
|
||||
Besides the canonical domains, Postfix can be configured to be the ffiinnaall
|
||||
ddeessttiinnaattiioonn for any number of additional domains. These domains are called
|
||||
hosted, because they are not directly associated with the name of the machine
|
||||
itself. Hosted domains are usually implemented with the virtual alias domain
|
||||
address class and/or with the virtual mailbox domain address class, as defined
|
||||
in the ADDRESS_CLASS_README file.
|
||||
|
||||
But wait! There is more. Postfix can be configured as a backup MX host for
|
||||
other domains. In this case Postfix is nnoott tthhee ffiinnaall ddeessttiinnaattiioonn for those
|
||||
domains. It merely queues the mail when the primary MX host is down, and
|
||||
forwards the mail when the primary MX host becomes available. This function is
|
||||
implemented with the relay domain address class, as defined in the
|
||||
ADDRESS_CLASS_README file.
|
||||
|
||||
Finally, Postfix can be configured as a transit host for sending mail across
|
||||
the internet. Obviously, Postfix is not the final destination for such mail.
|
||||
This function is available only for authorized clients and/or users, and is
|
||||
implemented by the default domain address class, as defined in the
|
||||
ADDRESS_CLASS_README file.
|
||||
|
||||
LLooccaall ffiilleess vveerrssuuss nneettwwoorrkk ddaattaabbaasseess
|
||||
|
||||
The examples in this text use table lookups from local files such as DBM or
|
||||
Berkeley DB. These are easy to debug with the ppoossttmmaapp command:
|
||||
|
||||
Example: postmap -q info@example.com hash:/etc/postfix/virtual
|
||||
|
||||
See the documentation in LDAP_README, MYSQL_README and PGSQL_README for how to
|
||||
replace local files by databases. The reader is strongly advised to make the
|
||||
system work with local files before migrating to network databases, and to use
|
||||
the ppoossttmmaapp command to verify that network database lookups produce the exact
|
||||
same results as local file lookup.
|
||||
|
||||
Example: postmap -q info@example.com ldap:/etc/postfix/virtual.cf
|
||||
|
||||
AAss ssiimmppllee aass ccaann bbee:: sshhaarreedd ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
|
||||
|
||||
The simplest method to host an additional domain is to add the domain name to
|
||||
the domains listed in the Postfix mydestination configuration parameter, and to
|
||||
add the user names to the UNIX password file.
|
||||
|
||||
This approach makes no distinction between canonical and hosted domains. Each
|
||||
username can receive mail in every domain.
|
||||
|
||||
In the examples we will use "example.com" as the domain that is being hosted on
|
||||
the local Postfix machine.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
mydestination = $myhostname localhost.$mydomain ... example.com
|
||||
|
||||
The limitations of this approach are:
|
||||
|
||||
* A total lack of separation: mail for info@my.host.name is delivered to the
|
||||
same UNIX system account as mail for info@example.com.
|
||||
* With users in the UNIX password file, administration of large numbers of
|
||||
users becomes inconvenient.
|
||||
|
||||
The examples that follow provide solutions for both limitations.
|
||||
|
||||
PPoossttffiixx vviirrttuuaall AALLIIAASS eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
|
||||
|
||||
With the approach described in this section, every hosted domain can have its
|
||||
own info etc. email address. However, it still uses UNIX system accounts for
|
||||
local mailbox deliveries.
|
||||
|
||||
With virtual alias domains, each hosted address is aliased to a local UNIX
|
||||
system account or to a remote address. The example below shows how to use this
|
||||
mechanism for the example.com domain.
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_alias_domains = example.com ...other hosted domains...
|
||||
3 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
4
|
||||
5 /etc/postfix/virtual:
|
||||
6 postmaster@example.com postmaster
|
||||
7 info@example.com joe
|
||||
8 sales@example.com jane
|
||||
9 # Uncomment entry below to implement a catch-all address
|
||||
10 # @example.com jim
|
||||
11 ...virtual aliases for more domains...
|
||||
|
||||
Notes:
|
||||
|
||||
* Line 2: the virtual_alias_domains setting tells Postfix that example.com is
|
||||
a so-called virtual alias domain. If you omit this setting then Postfix
|
||||
will reject mail (relay access denied) or will not be able to deliver it
|
||||
(mail for example.com loops back to myself).
|
||||
|
||||
NEVER list a virtual alias domain name as a mydestination domain!
|
||||
|
||||
* Lines 3-8: the /etc/postfix/virtual file contains the virtual aliases. With
|
||||
the example above, mail for postmaster@example.com goes to the local
|
||||
postmaster, while mail for info@example.com goes to the UNIX account joe,
|
||||
and mail for sales@example.com goes to the UNIX account jane. Mail for all
|
||||
other addresses in example.com is rejected with the error message "User
|
||||
unknown".
|
||||
|
||||
* Line 10: the commented out entry (text after #) shows how one would
|
||||
implement a catch-all virtual alias that receives mail for every
|
||||
example.com address not listed in the virtual alias file. This is not
|
||||
without risk. Spammers nowadays try to send mail from (or mail to) every
|
||||
possible name that they can think of. A catch-all mailbox is likely to
|
||||
receive many spam messages, and many bounces for spam messages that were
|
||||
sent in the name of anything@example.com.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
|
||||
file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
|
||||
|
||||
Note: virtual aliases can resolve to a local address or to a remote address, or
|
||||
both. They don't have to resolve to UNIX system accounts on your machine.
|
||||
|
||||
More details about the virtual alias file are given in the virtual(5) manual
|
||||
page, including multiple addresses on the right-hand side.
|
||||
|
||||
Virtual aliasing solves one problem: it allows each domain to have its own info
|
||||
mail address. But there still is one drawback: each virtual address is aliased
|
||||
to a UNIX system account. As you add more virtual addresses you also add more
|
||||
UNIX system accounts. The next section eliminates this problem.
|
||||
|
||||
PPoossttffiixx vviirrttuuaall MMAAIILLBBOOXX eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
|
||||
|
||||
As a system hosts more and more domains and users, it becomes less desirable to
|
||||
give every user their own UNIX system account.
|
||||
|
||||
With the Postfix virtual(8) mailbox delivery agent, every recipient address can
|
||||
have its own virtual mailbox. Unlike virtual alias domains, virtual mailbox
|
||||
domains do not need the clumsy translation from each recipient addresses into a
|
||||
different address, and owners of a virtual mailbox address do not need to have
|
||||
a UNIX system account.
|
||||
|
||||
The Postfix virtual(8) mailbox delivery agent looks up the user mailbox
|
||||
pathname, uid and gid via separate tables that are searched with the
|
||||
recipient's mail address. Maildir style delivery is turned on by terminating
|
||||
the mailbox pathname with "/".
|
||||
|
||||
If you find the idea of multiple tables bothersome, remember that you can
|
||||
migrate the information (once it works), to an SQL database. If you take that
|
||||
route, be sure to review the "local files versus databases" section at the top
|
||||
of this document.
|
||||
|
||||
Here is an example of a virtual mailbox domain "example.com":
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_mailbox_domains = example.com ...more domains...
|
||||
3 virtual_mailbox_base = /var/mail/vhosts
|
||||
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
|
||||
5 virtual_minimum_uid = 100
|
||||
6 virtual_uid_maps = static:5000
|
||||
7 virtual_gid_maps = static:5000
|
||||
8 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
9
|
||||
10 /etc/postfix/vmailbox:
|
||||
11 info@example.com example.com/info
|
||||
12 sales@example.com example.com/sales/
|
||||
13 # Comment out the entry below to implement a catch-all.
|
||||
14 # @example.com example.com/catchall
|
||||
15 ...virtual mailboxes for more domains...
|
||||
16
|
||||
17 /etc/postfix/virtual:
|
||||
18 postmaster@example.com postmaster
|
||||
|
||||
Notes:
|
||||
|
||||
* Line 2: The virtual_mailbox_domains setting tells Postfix that example.com
|
||||
is a so-called virtual mailbox domain. If you omit this setting then
|
||||
Postfix will reject mail (relay access denied) or will not be able to
|
||||
deliver it (mail for example.com loops back to myself).
|
||||
|
||||
NEVER list a virtual MAILBOX domain name as a mydestination domain!
|
||||
|
||||
NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
|
||||
|
||||
* Line 3: The virtual_mailbox_base parameter specifies a prefix for all
|
||||
virtual mailbox pathnames. This is a safety mechanism in case someone makes
|
||||
a mistake. It prevents mail from being delivered all over the file system.
|
||||
|
||||
* Lines 4, 10-15: The virtual_mailbox_maps parameter specifies the lookup
|
||||
table with mailbox (or maildir) pathnames, indexed by the virtual mail
|
||||
address. In this example, mail for info@example.com goes to the mailbox at
|
||||
/var/mail/vhosts/example.com/info while mail for sales@example.com goes to
|
||||
the maildir located at /var/mail/vhosts/example.com/sales/.
|
||||
|
||||
* Line 5: The virtual_minimum_uid specifies a lower bound on the mailbox or
|
||||
maildir owner's UID. This is a safety mechanism in case someone makes a
|
||||
mistake. It prevents mail from being written to sensitive files.
|
||||
|
||||
* Lines 6, 7: The virtual_uid_maps and virtual_gid_maps parameters specify
|
||||
that all the virtual mailboxes are owned by a fixed uid and gid 5000. If
|
||||
this is not what you want, specify lookup tables that are searched by the
|
||||
recipient's mail address.
|
||||
|
||||
* Line 14: The commented out entry (text after #) shows how one would
|
||||
implement a catch-all virtual mailbox address. Be prepared to receive a lot
|
||||
of spam, as well as bounced spam that was sent in the name of
|
||||
anything@example.com.
|
||||
|
||||
NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
|
||||
|
||||
* Lines 8, 17, 18: As you see, it is possible to mix virtual aliases with
|
||||
virtual mailboxes. We use this feature to redirect mail for example.com's
|
||||
postmaster address to the local postmaster. You can use the same mechanism
|
||||
to redirect an address to a remote address.
|
||||
|
||||
* Line 18: This example assumes that in main.cf, $myorigin is listed under
|
||||
the mydestination parameter setting. If that is not the case, specify an
|
||||
explicit domain name on the right-hand side of the virtual alias table
|
||||
entries or else mail will go to the wrong domain.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
|
||||
file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
|
||||
and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
|
||||
|
||||
Note: mail delivery happens with the recipient's UID/GID privileges specified
|
||||
with virtual_uid_maps and virtual_gid_maps. Postfix 2.0 and earlier will not
|
||||
create mailDIRs in world-writable parent directories; you must create them in
|
||||
advance before you can use them. Postfix may be able to create mailBOX files by
|
||||
itself, depending on parent directory write permissions, but it is safer to
|
||||
create mailBOX files ahead of time.
|
||||
|
||||
More details about the virtual mailbox delivery agent are given in the virtual
|
||||
(8) manual page.
|
||||
|
||||
NNoonn--PPoossttffiixx mmaaiillbbooxx ssttoorree:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
|
||||
|
||||
This is a variation on the Postfix virtual mailbox example. Again, every hosted
|
||||
address can have its own mailbox. However, most parameters that control the
|
||||
virtual(8) delivery agent are no longer applicable: only
|
||||
virtual_mailbox_domains and virtual_mailbox_maps stay in effect. These
|
||||
parameters are needed to reject mail for unknown recipients.
|
||||
|
||||
While non-Postfix software is being used for final delivery, some Postfix
|
||||
concepts are still needed in order to glue everything together. For additional
|
||||
background on this glue you may want to take a look at the virtual mailbox
|
||||
domain class as defined in the ADDRESS_CLASS_README file.
|
||||
|
||||
The text in this section describes what things should look like from Postfix's
|
||||
point of view. See CYRUS_README or MAILDROP_README for specific information
|
||||
about Cyrus or about Courier maildrop.
|
||||
|
||||
Here is an example for a hosted domain example.com that delivers to a non-
|
||||
Postfix delivery agent:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_transport = ...see below...
|
||||
3 virtual_mailbox_domains = example.com ...more domains...
|
||||
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
|
||||
5 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
6
|
||||
7 /etc/postfix/vmailbox:
|
||||
8 info@example.com whatever
|
||||
9 sales@example.com whatever
|
||||
10 # Comment out the entry below to implement a catch-all.
|
||||
11 # Configure the mailbox store to accept all addresses.
|
||||
12 # @example.com whatever
|
||||
13 ...virtual mailboxes for more domains...
|
||||
14
|
||||
15 /etc/postfix/virtual:
|
||||
16 postmaster@example.com postmaster
|
||||
|
||||
Notes:
|
||||
|
||||
* Line 2: With delivery to a non-Postfix mailbox store for hosted domains,
|
||||
the virtual_transport parameter usually specifies the Postfix LMTP client,
|
||||
or the name of a master.cf entry that executes non-Postfix software via the
|
||||
pipe delivery agent. Typical examples (use only one):
|
||||
|
||||
virtual_transport = lmtp:unix:/path/name (uses UNIX-domain socket)
|
||||
virtual_transport = lmtp:hostname:port (uses TCP socket)
|
||||
virtual_transport = maildrop: (uses pipe(8) to command)
|
||||
|
||||
Postfix comes ready with support for LMTP. And an example maildrop delivery
|
||||
method is already defined in the default Postfix master.cf file. See the
|
||||
MAILDROP_README document for more details.
|
||||
|
||||
* Line 3: The virtual_mailbox_domains setting tells Postfix that example.com
|
||||
is delivered via the virtual_transport that was discussed in the previous
|
||||
paragraph. If you omit this virtual_mailbox_domains setting then Postfix
|
||||
will either reject mail (relay access denied) or will not be able to
|
||||
deliver it (mail for example.com loops back to myself).
|
||||
|
||||
NEVER list a virtual MAILBOX domain name as a mydestination domain!
|
||||
|
||||
NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
|
||||
|
||||
* Lines 4, 7-13: The virtual_mailbox_maps parameter specifies the lookup
|
||||
table with all valid recipient addresses. The lookup result value is
|
||||
ignored by Postfix. In the above example, info@example.com and
|
||||
sales@example.com are listed as valid addresses; other mail for example.com
|
||||
is rejected with "User unknown" by the Postfix SMTP server. It's left up to
|
||||
the non-Postfix delivery agent to reject non-existent recipients from local
|
||||
submission or from local alias expansion. If you intend to use LDAP, MySQL
|
||||
or PgSQL instead of local files, be sure to review the "local files versus
|
||||
databases" section at the top of this document!
|
||||
|
||||
* Line 12: The commented out entry (text after #) shows how one would inform
|
||||
Postfix of the existence of a catch-all address. Again, the lookup result
|
||||
is ignored by Postfix.
|
||||
|
||||
NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
|
||||
|
||||
Note: if you specify a wildcard in virtual_mailbox_maps, then you still
|
||||
need to configure the non-Postfix mailbox store to receive mail for any
|
||||
address in that domain.
|
||||
|
||||
* Lines 5, 15, 16: As you see above, it is possible to mix virtual aliases
|
||||
with virtual mailboxes. We use this feature to redirect mail for
|
||||
example.com's postmaster address to the local postmaster. You can use the
|
||||
same mechanism to redirect any addresses to a local or remote address.
|
||||
|
||||
* Line 16: This example assumes that in main.cf, $myorigin is listed under
|
||||
the mydestination parameter setting. If that is not the case, specify an
|
||||
explicit domain name on the right-hand side of the virtual alias table
|
||||
entries or else mail will go to the wrong domain.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
|
||||
file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
|
||||
and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
|
||||
|
||||
MMaaiill ffoorrwwaarrddiinngg ddoommaaiinnss
|
||||
|
||||
Some providers host domains that have no (or only a few) local mailboxes. The
|
||||
main purpose of these domains is to forward mail elsewhere. The following
|
||||
example shows how to set up example.com as a mail forwarding domain:
|
||||
|
||||
1 /etc/postfix/main.cf:
|
||||
2 virtual_alias_domains = example.com ...other hosted domains...
|
||||
3 virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
4
|
||||
5 /etc/postfix/virtual:
|
||||
6 postmaster@example.com postmaster
|
||||
7 joe@example.com joe@somewhere
|
||||
8 jane@example.com jane@somewhere-else
|
||||
9 # Uncomment entry below to implement a catch-all address
|
||||
10 # @example.com jim@yet-another-site
|
||||
11 ...virtual aliases for more domains...
|
||||
|
||||
Notes:
|
||||
|
||||
* Line 2: The virtual_alias_domains setting tells Postfix that example.com is
|
||||
a so-called virtual alias domain. If you omit this setting then Postfix
|
||||
will reject mail (relay access denied) or will not be able to deliver it
|
||||
(mail for example.com loops back to myself).
|
||||
|
||||
NEVER list a virtual alias domain name as a mydestination domain!
|
||||
|
||||
* Lines 3-11: The /etc/postfix/virtual file contains the virtual aliases.
|
||||
With the example above, mail for postmaster@example.com goes to the local
|
||||
postmaster, while mail for joe@example.com goes to the remote address
|
||||
joe@somewhere, and mail for jane@example.com goes to the remote address
|
||||
jane@somewhere-else. Mail for all other addresses in example.com is
|
||||
rejected with the error message "User unknown".
|
||||
|
||||
* Line 10: The commented out entry (text after #) shows how one would
|
||||
implement a catch-all virtual alias that receives mail for every
|
||||
example.com address not listed in the virtual alias file. This is not
|
||||
without risk. Spammers nowadays try to send mail from (or mail to) every
|
||||
possible name that they can think of. A catch-all mailbox is likely to
|
||||
receive many spam messages, and many bounces for spam messages that were
|
||||
sent in the name of anything@example.com.
|
||||
|
||||
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
|
||||
file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
|
||||
|
||||
More details about the virtual alias file are given in the virtual(5) manual
|
||||
page, including multiple addresses on the right-hand side.
|
||||
|
||||
MMaaiilliinngg lliissttss
|
||||
|
||||
The examples that were given above already show how to direct mail for virtual
|
||||
postmaster addresses to a local postmaster. You can use the same method to
|
||||
direct mail for any address to a local or remote address.
|
||||
|
||||
There is one major limitation: virtual aliases and virtual mailboxes can't
|
||||
directly deliver to mailing list managers such as majordomo. The solution is to
|
||||
set up virtual aliases that direct virtual addresses to the local delivery
|
||||
agent:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
|
||||
/etc/postfix/virtual:
|
||||
listname-request@example.com listname-request
|
||||
listname@example.com listname
|
||||
owner-listname@example.com owner-listname
|
||||
|
||||
/etc/aliases:
|
||||
listname: "|/some/where/majordomo/wrapper ..."
|
||||
owner-listname: ...
|
||||
listname-request: ...
|
||||
|
||||
This example assumes that in main.cf, $myorigin is listed under the
|
||||
mydestination parameter setting. If that is not the case, specify an explicit
|
||||
domain name on the right-hand side of the virtual alias table entries or else
|
||||
mail will go to the wrong domain.
|
||||
|
||||
More information about the Postfix local delivery agent can be found in the
|
||||
local(8) manual page.
|
||||
|
||||
Why does this example use a clumsy virtual alias instead of a more elegant
|
||||
transport mapping? The reason is that mail for the virtual mailing list would
|
||||
be rejected with "User unknown". In order to make the transport mapping work
|
||||
one would still need a bunch of virtual alias or virtual mailbox table entries.
|
||||
|
||||
* In case of a virtual alias domain, there would need to be one identity
|
||||
mapping from each mailing list address to itself.
|
||||
* In case of a virtual mailbox domain, there would need to be a dummy mailbox
|
||||
for each mailing list address.
|
||||
|
||||
AAuuttoorreepplliieess
|
||||
|
||||
In order to set up an autoreply for virtual recipients while still delivering
|
||||
mail as normal, set up a rule in a virtual alias table:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
|
||||
/etc/postfix/virtual:
|
||||
user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld
|
||||
|
||||
This delivers mail to the recipient, and sends a copy of the mail to the
|
||||
address that produces automatic replies. The address can be serviced on a
|
||||
different machine, or it can be serviced locally by setting up a transport map
|
||||
entry that pipes all mail for autoreply.mydomain.tld into some script that
|
||||
sends an automatic reply back to the sender.
|
||||
|
||||
DO NOT list autoreply.mydomain.tld in mydestination!
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
transport_maps = hash:/etc/postfix/transport
|
||||
|
||||
/etc/postfix/transport:
|
||||
autoreply.mydomain.tld autoreply:
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
# =============================================================
|
||||
# service type private unpriv chroot wakeup maxproc command
|
||||
# (yes) (yes) (yes) (never) (100)
|
||||
# =============================================================
|
||||
autoreply unix - n n - - pipe
|
||||
flags= user=nobody argv=/path/to/autoreply $sender $mailbox
|
||||
|
||||
This invokes /path/to/autoreply with the sender address and the user@domain.tld
|
||||
recipient address on the command line.
|
||||
|
||||
For more information, see the pipe(8) manual page, and the comments in the
|
||||
Postfix master.cf file.
|
||||
|
||||
199
README_FILES/XCLIENT_README
Normal file
199
README_FILES/XCLIENT_README
Normal file
|
|
@ -0,0 +1,199 @@
|
|||
PPoossttffiixx XXCCLLIIEENNTT HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhee XXCCLLIIEENNTT eexxtteennssiioonn ttoo SSMMTTPP
|
||||
|
||||
When an SMTP server announces support for the XCLIENT command, an SMTP client
|
||||
may send information that overrides one or more client-related session
|
||||
attributes. The XCLIENT command targets the following problems:
|
||||
|
||||
1. Access control tests. SMTP server access rules are difficult to verify when
|
||||
decisions can be triggered only by remote clients. In order to facilitate
|
||||
access rule testing, an authorized SMTP client test program needs the
|
||||
ability to override the SMTP server's idea of the SMTP client hostname,
|
||||
network address, and other client information, for the entire duration of
|
||||
an SMTP session.
|
||||
|
||||
2. Client software that downloads mail from an up-stream mail server and
|
||||
injects it into a local MTA via SMTP. In order to take advantage of the
|
||||
local MTA's SMTP server access rules, the client software needs the ability
|
||||
to override the SMTP server's idea of the remote client name, client
|
||||
address and other information. Such information can typically be extracted
|
||||
from the up-stream mail server's Received: message header.
|
||||
|
||||
3. Post-filter access control and logging. With Internet->filter->MTA style
|
||||
content filter applications, the filter can be simplified if it can
|
||||
delegate decisions concerning mail relay and other access control to the
|
||||
MTA. This is especially useful when the filter acts as a transparent proxy
|
||||
for SMTP commands. This requires that the filter can override the MTA's
|
||||
idea of the SMTP client hostname, network address, and other information.
|
||||
|
||||
XXCCLLIIEENNTT CCoommmmaanndd ssyynnttaaxx
|
||||
|
||||
An example client-server conversation is given at the end of this document.
|
||||
|
||||
In SMTP server EHLO replies, the keyword associated with this extension is
|
||||
XCLIENT. It is followed by the names of the attributes that the XCLIENT
|
||||
implementation supports.
|
||||
|
||||
The XCLIENT command may be sent at any time, except in the middle of a mail
|
||||
delivery transaction (i.e. between MAIL and DOT, or MAIL and RSET). The XCLIENT
|
||||
command may be pipelined when the server supports ESMTP command pipelining. To
|
||||
avoid triggering spamware detectors, the command should be sent at the end of a
|
||||
command group.
|
||||
|
||||
The syntax of XCLIENT requests is described below. Upper case and quoted
|
||||
strings specify terminals, lowercase strings specify meta terminals, and SP is
|
||||
whitespace. Although command and attribute names are shown in upper case, they
|
||||
are in fact case insensitive.
|
||||
|
||||
xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value )
|
||||
|
||||
attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | LOGIN | DESTADDR |
|
||||
DESTPORT )
|
||||
|
||||
attribute-value = xtext
|
||||
|
||||
* Attribute values are xtext encoded as per RFC 1891.
|
||||
|
||||
* The NAME attribute specifies a remote SMTP client hostname (not an SMTP
|
||||
client address), [UNAVAILABLE] when client hostname lookup failed due to a
|
||||
permanent error, or [TEMPUNAVAIL] when the lookup error condition was
|
||||
transient.
|
||||
|
||||
* The ADDR attribute specifies a remote SMTP client numerical IPv4 network
|
||||
address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the
|
||||
address information is unavailable. Address information is not enclosed
|
||||
with [].
|
||||
|
||||
* The PORT attribute specifies a remote SMTP client TCP port number as a
|
||||
decimal number, or [UNAVAILABLE] when the information is unavailable.
|
||||
|
||||
* The PROTO attribute specifies either SMTP or ESMTP.
|
||||
|
||||
* The DESTADDR attribute specifies a local SMTP server numerical IPv4 network
|
||||
address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the
|
||||
address information is unavailable. Address information is not enclosed
|
||||
with [].
|
||||
|
||||
* The DESTPORT attribute specifies a local SMTP server TCP port number as a
|
||||
decimal number, or [UNAVAILABLE] when the information is unavailable.
|
||||
|
||||
* The HELO attribute specifies an SMTP HELO parameter value, or the value
|
||||
[UNAVAILABLE] when the information is unavailable.
|
||||
|
||||
* The LOGIN attribute specifies a SASL login name, or the value [UNAVAILABLE]
|
||||
when the information is unavailable.
|
||||
|
||||
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 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.
|
||||
|
||||
Note 3: Postfix implementations prior to version 2.3 do not xtext encode
|
||||
attribute values. Servers that wish to interoperate with these older
|
||||
implementations should be prepared to receive unencoded information.
|
||||
|
||||
Note 4: Some Postfix implementations do not implement the PORT or LOGIN
|
||||
attributes.
|
||||
|
||||
XXCCLLIIEENNTT SSeerrvveerr rreessppoonnssee
|
||||
|
||||
Upon receipt of a correctly formatted XCLIENT command, the server resets state
|
||||
to the initial SMTP greeting protocol stage. Depending on the outcome of
|
||||
optional access decisions, the server responds with 220 or with a suitable
|
||||
rejection code.
|
||||
|
||||
For practical reasons it is not always possible to reset the complete server
|
||||
state to the initial SMTP greeting protocol stage:
|
||||
|
||||
* TLS session information may not be reset, because turning off TLS leaves
|
||||
the connection in an undefined state. Consequently, the server may not
|
||||
announce STARTTLS when TLS is already active, and access decisions may be
|
||||
influenced by client certificate information that was received prior to the
|
||||
XCLIENT command.
|
||||
|
||||
* The SMTP server must not reset attributes that were received with the last
|
||||
XCLIENT command. This includes HELO or PROTO attributes.
|
||||
|
||||
NOTE: Postfix implementations prior to version 2.3 do not jump back to the
|
||||
initial SMTP greeting protocol stage. These older implementations will not
|
||||
correctly simulate connection-level access decisions under some conditions.
|
||||
|
||||
XXCCLLIIEENNTT sseerrvveerr rreeppllyy ccooddeess
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|CCooddee |MMeeaanniinngg |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|220 |success |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|421 |unable to proceed, disconnecting |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|501 |bad command parameter syntax |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|503 |mail transaction in progress |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|550 |insufficient authorization |
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|other|connection rejected by connection-level access decision|
|
||||
|_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
XXCCLLIIEENNTT EExxaammppllee
|
||||
|
||||
In the example, the client impersonates a mail originating system by passing
|
||||
all SMTP client information via the XCLIENT command. Information sent by the
|
||||
client is shown in bold font.
|
||||
|
||||
220 server.example.com ESMTP Postfix
|
||||
EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
|
||||
250-server.example.com
|
||||
250-PIPELINING
|
||||
250-SIZE 10240000
|
||||
250-VRFY
|
||||
250-ETRN
|
||||
250-XCLIENT NAME ADDR PROTO HELO
|
||||
250 8BITMIME
|
||||
XXCCLLIIEENNTT NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22
|
||||
220 server.example.com ESMTP Postfix
|
||||
EEHHLLOO ssppiikkee..ppoorrccuuppiinnee..oorrgg
|
||||
250-server.example.com
|
||||
250-PIPELINING
|
||||
250-SIZE 10240000
|
||||
250-VRFY
|
||||
250-ETRN
|
||||
250-XCLIENT NAME ADDR PROTO HELO
|
||||
250 8BITMIME
|
||||
MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
|
||||
250 Ok
|
||||
RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
|
||||
250 Ok
|
||||
DDAATTAA
|
||||
354 End data with <CR><LF>.<CR><LF>
|
||||
.. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
|
||||
..
|
||||
250 Ok: queued as 763402AAE6
|
||||
QQUUIITT
|
||||
221 Bye
|
||||
|
||||
SSeeccuurriittyy
|
||||
|
||||
The XCLIENT command changes audit trails and/or SMTP client access permissions.
|
||||
Use of this command must be restricted to authorized SMTP clients.
|
||||
|
||||
SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
|
||||
|
||||
XCLIENT attributes persist until the end of an SMTP session. If one session is
|
||||
used to deliver mail on behalf of different SMTP clients, the XCLIENT
|
||||
attributes need to be reset as appropriate before each MAIL FROM command.
|
||||
|
||||
RReeffeerreenncceess
|
||||
|
||||
Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
|
||||
January 1996.
|
||||
|
||||
179
README_FILES/XFORWARD_README
Normal file
179
README_FILES/XFORWARD_README
Normal file
|
|
@ -0,0 +1,179 @@
|
|||
PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP
|
||||
|
||||
When an SMTP server announces support for the XFORWARD command, an SMTP client
|
||||
may send information that overrides one or more client-related logging
|
||||
attributes. The XFORWARD command targets the following problem:
|
||||
|
||||
* Logging after SMTP-based content filter. With the deployment of Internet-
|
||||
>MTA1->filter->MTA2 style content filter applications, the logging of
|
||||
client and message identifying information changes when MTA1 gives the mail
|
||||
to the content filter. To simplify the interpretation of MTA2 logging, it
|
||||
would help if MTA1 could forward remote client and/or message identifying
|
||||
information through the content filter to MTA2, so that the information
|
||||
could be logged as part of mail handling transactions.
|
||||
|
||||
This extension is implemented as a separate ESMTP command, and can be used to
|
||||
transmit client or message attributes incrementally. It is not implemented by
|
||||
passing additional parameters via the MAIL FROM command, because doing so would
|
||||
require extending the MAIL FROM command length limit by another 600 or more
|
||||
characters beyond the space that is already needed to support other extensions
|
||||
such as AUTH and DSN.
|
||||
|
||||
XXFFOORRWWAARRDD CCoommmmaanndd ssyynnttaaxx
|
||||
|
||||
An example of a client-server conversation is given at the end of this
|
||||
document.
|
||||
|
||||
In SMTP server EHLO replies, the keyword associated with this extension is
|
||||
XFORWARD. The keyword is followed by the names of the attributes that the
|
||||
XFORWARD implementation supports.
|
||||
|
||||
After receiving the server's announcement for XFORWARD support, the client may
|
||||
send XFORWARD requests at any time except in the middle of a mail delivery
|
||||
transaction (i.e. between MAIL and RSET or DOT). The command may be pipelined
|
||||
when the server supports ESMTP command pipelining.
|
||||
|
||||
The syntax of XFORWARD requests is described below. Upper case and quoted
|
||||
strings specify terminals, lowercase strings specify meta terminals, and SP is
|
||||
whitespace. Although command and attribute names are shown in upper case, they
|
||||
are in fact case insensitive.
|
||||
|
||||
xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
|
||||
|
||||
attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE )
|
||||
|
||||
attribute-value = xtext
|
||||
|
||||
* Attribute values are xtext encoded as per RFC 1891.
|
||||
|
||||
* The NAME attribute specifies the up-stream hostname, or [UNAVAILABLE] when
|
||||
the information is unavailable. The hostname may be a non-DNS hostname.
|
||||
|
||||
* The ADDR attribute specifies the up-stream network address: a numerical
|
||||
IPv4 network address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE]
|
||||
when the address information is unavailable. Address information is not
|
||||
enclosed with [].
|
||||
|
||||
* The PORT attribute specifies an up-stream client TCP port number in
|
||||
decimal, or [UNAVAILABLE] when the information is unavailable.
|
||||
|
||||
* The PROTO attribute specifies the mail protocol for receiving mail from the
|
||||
up-stream host. This may be an SMTP or non-SMTP protocol name of up to 64
|
||||
characters, or [UNAVAILABLE] when the information is unavailable.
|
||||
|
||||
* The HELO attribute specifies the hostname that the up-stream host announced
|
||||
itself with (not necessarily via the SMTP HELO command), or [UNAVAILABLE]
|
||||
when the information is unavailable. The hostname may be a non-DNS
|
||||
hostname.
|
||||
|
||||
* The IDENT attribute specifies a local message identifier on the up-stream
|
||||
host, or [UNAVAILABLE] when the information is unavailable. The down-stream
|
||||
MTA may log this information together with its own local message identifier
|
||||
to facilitate message tracking across MTAs.
|
||||
|
||||
* The SOURCE attribute specifies LOCAL when the message was received from a
|
||||
source that is local with respect to the up-stream host (for example, the
|
||||
message originated from the up-stream host itself), REMOTE for all other
|
||||
mail, or [UNAVAILABLE] when the information is unavailable. The down-stream
|
||||
MTA may decide to enable features such as header munging or address
|
||||
qualification with mail from local sources but not other sources.
|
||||
|
||||
Note 1: an attribute-value element must not be longer than 255 characters
|
||||
(specific attributes may impose shorter lengths). After xtext decoding,
|
||||
attribute values must not contain control characters, non-ASCII characters,
|
||||
whitespace, or other characters that are special in message headers.
|
||||
|
||||
Note 2: DNS hostnames can be up to 255 characters long. The XFORWARD client
|
||||
implementation must not send XFORWARD commands that exceed the 512 character
|
||||
limit for SMTP commands.
|
||||
|
||||
Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
|
||||
|
||||
Note 4: Postfix implementations prior to version 2.3 do not xtext encode
|
||||
attribute values. Servers that wish to interoperate with these older
|
||||
implementations should be prepared to receive unencoded information.
|
||||
|
||||
XXFFOORRWWAARRDD SSeerrvveerr ooppeerraattiioonn
|
||||
|
||||
The server maintains a set of XFORWARD attributes with forwarded information,
|
||||
in addition the current SMTP session attributes. Normally, all XFORWARD
|
||||
attributes are in the undefined state, and the server uses the current SMTP
|
||||
session attributes for logging purposes.
|
||||
|
||||
Upon receipt of an initial XFORWARD command, the SMTP server initializes all
|
||||
XFORWARD attributes to [UNAVAILABLE]. With each valid XFORWARD command, the
|
||||
server updates XFORWARD attributes with the specified values.
|
||||
|
||||
The server must not mix client attributes from XFORWARD with client attributes
|
||||
from the current SMTP session.
|
||||
|
||||
At the end of each MAIL FROM transaction (i.e. RSET or DOT), the server resets
|
||||
all XFORWARD attributes to the undefined state, and is ready to receive another
|
||||
initial XFORWARD command.
|
||||
|
||||
XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess
|
||||
|
||||
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
||||
|CCooddee|MMeeaanniinngg |
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|250 |success |
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|421 |unable to proceed, disconnecting|
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|501 |bad command parameter syntax |
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|503 |mail transaction in progress |
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|550 |insufficient authorization |
|
||||
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
||||
|
||||
XXFFOORRWWAARRDD EExxaammppllee
|
||||
|
||||
In the following example, information sent by the client is shown in bold font.
|
||||
|
||||
220 server.example.com ESMTP Postfix
|
||||
EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
|
||||
250-server.example.com
|
||||
250-PIPELINING
|
||||
250-SIZE 10240000
|
||||
250-VRFY
|
||||
250-ETRN
|
||||
250-XFORWARD NAME ADDR PROTO HELO
|
||||
250 8BITMIME
|
||||
XXFFOORRWWAARRDD NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22 PPRROOTTOO==EESSMMTTPP
|
||||
250 Ok
|
||||
XXFFOORRWWAARRDD HHEELLOO==ssppiikkee..ppoorrccuuppiinnee..oorrgg
|
||||
250 Ok
|
||||
MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
|
||||
250 Ok
|
||||
RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
|
||||
250 Ok
|
||||
DDAATTAA
|
||||
354 End data with <CR><LF>.<CR><LF>
|
||||
.. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
|
||||
..
|
||||
250 Ok: queued as 3CF6B2AAE8
|
||||
QQUUIITT
|
||||
221 Bye
|
||||
|
||||
SSeeccuurriittyy
|
||||
|
||||
The XFORWARD command changes audit trails. Use of this command must be
|
||||
restricted to authorized clients.
|
||||
|
||||
SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
|
||||
|
||||
SMTP connection caching makes it possible to deliver multiple messages within
|
||||
the same SMTP session. The XFORWARD attributes are reset after the MAIL FROM
|
||||
transaction completes (after RSET or DOT), so there is no risk of information
|
||||
leakage.
|
||||
|
||||
RReeffeerreenncceess
|
||||
|
||||
Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
|
||||
January 1996.
|
||||
|
||||
200
RELEASE_NOTES
Normal file
200
RELEASE_NOTES
Normal file
|
|
@ -0,0 +1,200 @@
|
|||
This is the Postfix 3.10 stable release.
|
||||
|
||||
The stable Postfix release is called postfix-3.10.x where 3=major
|
||||
release number, 10=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.11-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 3.8 or earlier, please read RELEASE_NOTES-3.9
|
||||
before proceeding.
|
||||
|
||||
Dual license
|
||||
------------
|
||||
|
||||
As of Postfix 3.2.5 this software is distributed with a dual license:
|
||||
in addition to the historical IBM Public License (IPL) 1.0, it is
|
||||
now also distributed with the more recent Eclipse Public License
|
||||
(EPL) 2.0. Recipients can choose to take the software under the
|
||||
license of their choice. Those who are more comfortable with the
|
||||
IPL can continue with that license.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Forward compatibility 20250212] Support for OpenSSL 3.5 post-quantum
|
||||
cryptography. To manage algorithm selection, OpenSSL introduces new
|
||||
TLS group syntax that Postfix will not attempt to imitate. Instead,
|
||||
Postfix now allows the tls_eecdh_auto_curves and tls_ffdhe_auto_groups
|
||||
parameter values to have an empty value. When both are set empty,
|
||||
the algorithm selection can be managed through OpenSSL configuration.
|
||||
For more, look for "Post-quantum" in the postconf(5) manpage.
|
||||
|
||||
[Feature 20250117] Support for the RFC 8689 "TLS-Required: no"
|
||||
message header to request delivery of messages such as TLSRPT
|
||||
summaries even if the preferred TLS security policy cannot be
|
||||
enforced. This limits the Postfix SMTP client to "smtp_tls_security_level
|
||||
= may" which does not authenticate server certificates and which
|
||||
allows falling back to plaintext.
|
||||
|
||||
Support for the REQUIRETLS SMTP service extension remains future work.
|
||||
|
||||
[Feature 20240926] Support for the TLSRPT protocol (defined in RFC
|
||||
8460). With this, a domain can publish a policy in DNS, and request
|
||||
daily summary reports for successful and failed SMTP-over-TLS
|
||||
connections to that domain's MX hosts.
|
||||
|
||||
Postfix supports TLSRPT summaries for DANE (built-in) and MTA-STS
|
||||
(via an smtp_tls_policy_maps plugin). For details, see TLSRPT_README.
|
||||
|
||||
Major changes - privacy
|
||||
-----------------------
|
||||
|
||||
[Feature 20250205] With "smtpd_hide_client_session = yes", the
|
||||
Postfix SMTP server generates a Received: header without client
|
||||
session info This setting may be used with the MUA submission
|
||||
services (port 465 and 587), but it must not be used with the MTA
|
||||
service (port 25).
|
||||
|
||||
Depending on the number of recipients, a redacted Received: header
|
||||
has one of the following forms:
|
||||
|
||||
Received: by mail.example.com (Postfix) id postfix-queue-id
|
||||
for <user@example.com>; Day, dd Mon yyyy hh:mm:ss tz-offset (zone)
|
||||
|
||||
Received: by mail.example.com (Postfix) id postfix-queue-id
|
||||
Day, dd Mon yyyy hh:mm:ss tz-offset (zone)
|
||||
|
||||
The redacted form hides that a message was received with SMTP, and
|
||||
therefore it does not need to provide the information required by
|
||||
RFC 5321. It only has to satisfy RFC 5322.
|
||||
|
||||
Major changes - rfc2047
|
||||
-----------------------
|
||||
|
||||
[Feature 20250105] Support for automatic RFC 2047 encoding of
|
||||
non-ASCII "full name" information in Postfix-generated From: message
|
||||
headers. Encoding non-ASCII full names can avoid the need to use
|
||||
SMTPUTF8, and therefore can avoid incompatibility with sites that
|
||||
do not support SMTPUTF8.
|
||||
|
||||
The encoded result looks like "=?charset?Q?gibberish?=: for
|
||||
quoted-printable encoding, or "=?charset?B?gibberish?=" for base64
|
||||
encoding. Postfix uses quoted-printable for a full name that is
|
||||
short or mostly ASCII, and uses base64 otherwise.
|
||||
|
||||
Background: when a message without a From: header is submitted with
|
||||
the Postfix sendmail(1) command, Postfix may add a From: header and
|
||||
use the sender's full name specified with the Postfix sendmail(1)
|
||||
"-F" option, with the sendmail(1) "NAME" environment variable, or
|
||||
with the GECOS field in the UNIX password database.
|
||||
|
||||
This introduces a new configuration parameter "full_name_encoding_charset"
|
||||
(default: utf8) which specifies the character set of the full name
|
||||
information in the Postfix sendmail(1) "-F" option or "NAME"
|
||||
environment variable, or in the GECOS field in the UNIX password
|
||||
database. The parameter value becomes part of the encoded full name,
|
||||
and informs a Mail User Agent how to display the decoded gibberish.
|
||||
|
||||
Major changes - bugfix
|
||||
----------------------
|
||||
|
||||
[Incompat 20241130] The spawn(8) daemon failed to enforce the command
|
||||
time limit. It was sending the SIGKILL signal using the wrong
|
||||
effective UID and GID. The pipe(8) daemon has always done this
|
||||
right.
|
||||
|
||||
Major changes - database
|
||||
------------------------
|
||||
|
||||
[Feature 20250207] When mysql: or pgsql: configuration specifies
|
||||
a single host, assume that it is a load balancer and reconnect
|
||||
immediately after a single failure, instead of failing all requests
|
||||
for 60s.
|
||||
|
||||
[Feature 20250114] first/next iterator support for cdb: tables, and
|
||||
other cdb: table code cleanups by Michael Tokarev.
|
||||
|
||||
[Feature 20241024] In a pgsql: client configuration, the setting
|
||||
"dbname" is required, but ignored when the setting "hosts" contains
|
||||
an URI with a database name.
|
||||
|
||||
[Feature 20241025] The Postfix pgsql: client configuration now
|
||||
allows any well-formed URI prefix as a pgsql: client connection
|
||||
target (the PostgreSQL URI parser decides what is allowed). The
|
||||
dbname setting is now optional if the hosts setting specifies only
|
||||
URIs.
|
||||
|
||||
Major changes - internal protocol
|
||||
---------------------------------
|
||||
|
||||
[Incompat 20250116] Postfix needs "postfix reload" after upgrade,
|
||||
because of a change in the delivery agent protocol. If this step
|
||||
is skipped, Postfix delivery agents will log a warning:
|
||||
|
||||
unexpected attribute smtputf8 from xxx socket (expecting: sendopts)
|
||||
|
||||
where xxx is the delivery agent service name.
|
||||
|
||||
Major changes - milter
|
||||
----------------------
|
||||
|
||||
[Incompat 20250106] The logging of the Milter 'quarantine' action
|
||||
has changed. Instead of logging "milter triggers HOLD action", it
|
||||
logs the reason given by a Milter application, or "default_action"
|
||||
if a Milter application was unavailable and the milter_default_action
|
||||
parameter or per-Milter "default_action" property specifies
|
||||
"quarantine".
|
||||
|
||||
[Feature 20250106] The Postfix Milter implementation now logs the
|
||||
reason for a 'quarantine' action, instead of "milter triggers HOLD
|
||||
action".
|
||||
|
||||
- If the quarantine action was requested by a Milter application,
|
||||
Postfix will log the reason given by the application.
|
||||
|
||||
- If the quarantine action was requested with the "milter_default_action"
|
||||
parameter setting or with a per-Milter "default_action" property,
|
||||
Postfix will log "default_action".
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Feature 20250106] The Postfix Milter implementation now logs the
|
||||
reason for a 'quarantine' action, instead of "milter triggers HOLD
|
||||
action".
|
||||
|
||||
- If the quarantine action was requested by a Milter application,
|
||||
Postfix will log the reason given by the application.
|
||||
|
||||
- If the quarantine action was requested with the "milter_default_action"
|
||||
parameter setting or with a per-Milter "default_action" property,
|
||||
Postfix will log "default_action".
|
||||
|
||||
[Incompat 20250105] The SMTP server now logs the queue ID (or
|
||||
"NOQUEUE") when a connection ends abnormally (timeout, lost connection,
|
||||
or too many errors).
|
||||
|
||||
[Feature 20250105] The SMTP server now logs the queue ID (or
|
||||
"NOQUEUE") when a connection ends abnormally (timeout, lost connection,
|
||||
or too many errors).
|
||||
|
||||
[Incompat 20241104] The cleanup server now logs "queueid: canceled"
|
||||
when a message transaction is started but not completed.
|
||||
|
||||
[Feature 20241104] The cleanup server now logs "queueid: canceled"
|
||||
when a message transaction is started but not completed. This
|
||||
provides a clear signal to logfile collation tools.
|
||||
|
||||
[Incompat 20241031] the Dovecot SASL client logging for "Invalid
|
||||
authentication mechanism" now includes the name of that mechanism.
|
||||
|
||||
[Incompat 20241023] Postfix SMTP server 'reject' logging now shows
|
||||
the sasl_method, sasl_username, and sasl_sender if available.
|
||||
746
RELEASE_NOTES-1.0
Normal file
746
RELEASE_NOTES-1.0
Normal file
|
|
@ -0,0 +1,746 @@
|
|||
This is the first official Postfix release that is not called BETA.
|
||||
May it help the people who cannot get BETA software past their
|
||||
management.
|
||||
|
||||
Release 20010228 differs from snapshot 20010228 in that the virtual
|
||||
delivery agent and nqmgr queue manager are left out. That software
|
||||
will become part of the official release when it has not changed
|
||||
in a while.
|
||||
|
||||
In the text below, incompatible changes are labeled with the Postfix
|
||||
version that introduced the change. If you upgrade from a later
|
||||
Postfix version, then you do not have to worry about that particular
|
||||
incompatibility.
|
||||
|
||||
Major incompatible changes with release-20010228
|
||||
================================================
|
||||
|
||||
[snapshot-20010225] POSTFIX NO LONGER RELAYS MAIL FOR CLIENTS IN
|
||||
THE ENTIRE CLASS A/B/C NETWORK. To get the old behavior, specify
|
||||
"mynetworks_style = class" in the main.cf file. The default
|
||||
(mynetworks_style = subnet) is to relay for clients in the local
|
||||
IP subnet. See conf/main.cf.
|
||||
|
||||
[snapshot-20001005, snapshot-20010225] You must execute "postfix
|
||||
stop" before installing this release. Some recommended parameter
|
||||
settings have changed, and a new entry must be added to the master.cf
|
||||
file before you can start Postfix again.
|
||||
|
||||
1 - The recommended Postfix configuration no longer uses flat
|
||||
directories for the "incoming" "active", "bounce", and "defer"
|
||||
queue directories. The "flush" directory for the new "flush"
|
||||
service directory should not be flat either.
|
||||
|
||||
Upon start-up, Postfix checks if the hash_queue_names configuration
|
||||
parameter is properly set up, and will add any queue directory
|
||||
names that are missing.
|
||||
|
||||
2 - In order to improve performance of one-to-one mail deliveries
|
||||
the queue manager will now look at up to 10000 queue files
|
||||
(was: 1000). The default qmgr_message_active_limit setting
|
||||
was changed accordingly.
|
||||
|
||||
If you have a non-default qmgr_message_active_limit in main.cf,
|
||||
you may want adjust it.
|
||||
|
||||
3 - The new "flush" service needs to be configured in master.cf.
|
||||
|
||||
Upon start-up, Postfix checks if the new "flush" service is
|
||||
configured in the master.cf file, and will add an entry if it
|
||||
is missing.
|
||||
|
||||
Should you wish to back out to a previous Postfix release there is
|
||||
no need to undo the above queue configuration changes.
|
||||
|
||||
[snapshot-20000921] The protocol between queue manager and delivery
|
||||
agents has changed. This means that you cannot mix the Postfix
|
||||
queue manager or delivery agents with those of Postfix versions
|
||||
prior to 20000921. This change does not affect Postfix queue file
|
||||
formats.
|
||||
|
||||
[snapshot-20000529] This release introduces an incompatible queue
|
||||
file format change ONLY when content filtering is enabled (see text
|
||||
in FILTER_README). Old Postfix queue files will work fine, but
|
||||
queue files with the new content filtering info will not work with
|
||||
Postfix versions before 20000529. Postfix logs a warning and moves
|
||||
incompatible queue files to the "corrupt" mail queue subdirectory.
|
||||
|
||||
Minor incompatible changes with release-20010228
|
||||
================================================
|
||||
|
||||
[snapshot-20010225] The incoming and deferred queue directories
|
||||
are now hashed by default. This improves the performance considerably
|
||||
under heavy load, at the cost of a small but noticeable slowdown
|
||||
when one runs "mailq" on an unloaded system.
|
||||
|
||||
[snapshot-20010222] Postfix no longer automatically delivers
|
||||
recipients one at a time when their domain is listed in $mydestination.
|
||||
This change solves delivery performance problems with delivery via
|
||||
LMTP, with virus scanning, and with firewall relays that forward
|
||||
all mail for $mydestination to an inside host.
|
||||
|
||||
The "one recipient at a time" delivery behavior is now controlled
|
||||
by the per-transport recipient limit (xxx_destination_recipient_limit,
|
||||
where xxx is the name of the delivery mechanism). This parameter
|
||||
controls the number of recipients that can be sent in one delivery
|
||||
(surprise).
|
||||
|
||||
The setting of the per-transport recipient limit also controls the
|
||||
meaning of the per-transport destination concurrency limit (named
|
||||
xxx_destination_concurrency_limit, where xxx is again the name of
|
||||
the delivery mechanism):
|
||||
|
||||
1) When the per-transport recipient limit is 1 (i.e., send one
|
||||
recipient per delivery), the per-transport destination concurrency
|
||||
limit controls the number of simultaneous deliveries to the
|
||||
same recipient. This is the default behavior for delivery via
|
||||
the Postfix local delivery agent.
|
||||
|
||||
2) When the per-transport recipient limit is > 1 (i.e., send
|
||||
multiple recipients per delivery), the per-transport destination
|
||||
concurrency limit controls the number of simultaneous deliveries
|
||||
to the same domain. This is the default behavior for all other
|
||||
Postfix delivery agents.
|
||||
|
||||
[snapshot-20010128] The Postfix local delivery agent now enforces
|
||||
mailbox file size limits (default: mailbox_size_limit = 51200000).
|
||||
This limit affects all file write access by the local delivery
|
||||
agent or by a process run by the local delivery agent. The purpose
|
||||
of this parameter is to act as a safety for run-away software. It
|
||||
cannot be a substitute for a file quota management system. Specify
|
||||
a limit of 0 to disable.
|
||||
|
||||
[snapshot-20010128] REJECT in header/body_checks is now flagged as
|
||||
policy violation rather than bounce, for consistency in postmaster
|
||||
notifications.
|
||||
|
||||
[snapshot-20010128] The default RBL (real-time blackhole lists)
|
||||
domain examples have been changed from *.vix.com to *.mail-abuse.org.
|
||||
|
||||
[snapshot-20001210] Several interfaces of libutil and libglobal
|
||||
routines have changed. This may break third-party code written
|
||||
for Postfix. In particular, the safe_open() routine has changed,
|
||||
the way the preferred locking method is specified in the sys_defs.h
|
||||
file, as well as all routines that perform file locking. When
|
||||
compiling third-party code written for Postfix, the incompatibilities
|
||||
will be detected by the compiler provided that #include file
|
||||
dependencies are properly maintained.
|
||||
|
||||
[snapshot-20001210] When delivering to /file/name (as directed in
|
||||
an alias or .forward file), the local delivery agent now logs a
|
||||
warning when it is unable to create a /file/name.lock file. Mail
|
||||
is still delivered as before.
|
||||
|
||||
[snapshot-20001210] The "sun_mailtool_compatibility" feature is
|
||||
going away (a compatibility mode that turns off kernel locks on
|
||||
mailbox files). It still works, but a warning is logged. Instead
|
||||
of using "sun_mailtool_compatibility", specify the mailbox locking
|
||||
strategy as "mailbox_delivery_lock = dotlock".
|
||||
|
||||
[snapshot-20001210] The Postfix SMTP client now skips SMTP server
|
||||
replies that do not start with "CODE SPACE" or with "CODE HYPHEN"
|
||||
and flags them as protocol errors. Older Postfix SMTP clients
|
||||
silently treated "CODE TEXT" as "CODE SPACE TEXT", i.e. as a valid
|
||||
SMTP reply.
|
||||
|
||||
[snapshot-20001121] On RedHat Linux 7.0, you must install the
|
||||
db3-devel RPM before you can compile the Postfix source code.
|
||||
|
||||
[snapshot-20000924] The postmaster address in the "sorry" text at
|
||||
the top of bounced mail is now just postmaster, not postmaster@machine.
|
||||
The idea is to refer users to their own postmaster.
|
||||
|
||||
[snapshot-20000921] The notation of [host:port] in transport tables
|
||||
etc. is going away but it is still supported. The preferred form
|
||||
is now [host]:port. This change is necessary to support IPV6
|
||||
address forms which use ":" as part of a numeric IP address. In a
|
||||
future release, Postfix will log a warning when it encounters the
|
||||
[host:port] form.
|
||||
|
||||
[snapshot-20000921] In mail headers, Errors-To:, Reply-To: and
|
||||
Return-Receipt: addresses are now rewritten as a sender address
|
||||
(was: recipient).
|
||||
|
||||
[snapshot-20000921] Postfix no longer inserts Sender: message
|
||||
headers.
|
||||
|
||||
[snapshot-20000921] The queue manager now logs the original number
|
||||
of recipients when opening a queue file (example: from=<>, size=3502,
|
||||
nrcpt=1).
|
||||
|
||||
[snapshot-20000921] The local delivery agent no longer appends a
|
||||
blank line to mail that is delivered to external command.
|
||||
|
||||
[snapshot-20000921] The pipe delivery agent no longer appends a
|
||||
blank line when the F flag is specified (in the master.cf file).
|
||||
Specify the B flag if you need that blank line.
|
||||
|
||||
[snapshot-20000507] As required by RFC 822, Postfix now inserts a
|
||||
generic destination message header when no destination header is
|
||||
present. The text is specified via the undisclosed_recipients_header
|
||||
configuration parameter (default: "To: undisclosed-recipients:;").
|
||||
|
||||
[snapshot-20000507] The Postfix sendmail command treats a line with
|
||||
only `.' as the end of input, for the sake of sendmail compatibility.
|
||||
To disable this feature, specify the sendmail-compatible `-i' or
|
||||
`-oi' flags on the sendmail command line.
|
||||
|
||||
[snapshot-20000507] For the sake of Sendmail compatibility, the
|
||||
Postfix SMTP client skips over SMTP servers that greet with a 4XX
|
||||
or 5XX reply code, treating them as unreachable servers. To obtain
|
||||
prior behavior (4XX=retry, 5XX=bounce), specify "smtp_skip_4xx_greeting
|
||||
= no" and "smtp_skip_5xx_greeting = no".
|
||||
|
||||
Major changes with release-20010228
|
||||
===================================
|
||||
|
||||
Postfix produces DSN formatted bounced/delayed mail notifications.
|
||||
The human-readable text still exists, so that users will not have
|
||||
to be unnecessarily confused by all the ugliness of RFC 1894. Full
|
||||
DSN support will be later.
|
||||
|
||||
This release introduces full content filtering through an external
|
||||
process. This involves an incompatible change in queue file format.
|
||||
Mail is delivered to content filtering software via an existing
|
||||
mail delivery agent, and is re-injected into Postfix via an existing
|
||||
mail submission agent. See examples in the FILTER_README file.
|
||||
Depending on how the filter is implemented, you can expect to lose
|
||||
a factor of 2 to 4 in delivery performance of SMTP transit mail,
|
||||
more if the content filtering software needs lots of CPU or memory.
|
||||
|
||||
Specify "body_checks = regexp:/etc/postfix/body_checks" for a quick
|
||||
and dirty emergency content filter that looks at non-header lines
|
||||
one line at a time (including MIME headers inside the message body).
|
||||
Details in conf/sample-filter.cf.
|
||||
|
||||
The header_checks and body_checks features can be used to strip
|
||||
out unwanted data. Specify IGNORE on the right-hand side and the
|
||||
data will disappear from the mail.
|
||||
|
||||
Support for SASL (RFC 2554) authentication in the SMTP server and
|
||||
in the SMTP and LMTP clients. See the SASL_README file for more
|
||||
details. This file still needs better examples.
|
||||
|
||||
Postfix now ships with an LMTP delivery agent that can deliver over
|
||||
local/remote TCP sockets and over local UNIX-domain sockets. The
|
||||
LMTP_README file gives example, but still needs to be revised.
|
||||
|
||||
Fast "ETRN" and "sendmail -qR". Postfix maintains per-destination
|
||||
logfiles with information about what mail is queued for selected
|
||||
destinations. See the file ETRN_README for details.
|
||||
|
||||
The mailbox locking style is now fully configurable at runtime.
|
||||
The new configuration parameter is called "mailbox_delivery_lock".
|
||||
Depending on the operating system type, mailboxes can be locked
|
||||
with one or more of "flock", "fcntl" or "dotlock". The command
|
||||
"postconf -l" shows the available locking styles. The default
|
||||
mailbox locking style is system dependent. This change affects
|
||||
all mailbox and all "/file/name" deliveries by the Postfix local
|
||||
delivery agent.
|
||||
|
||||
Minor changes with release-20010228
|
||||
===================================
|
||||
|
||||
You can now specify multiple SMTP destinations in the relayhost
|
||||
and fallback_relay configuration parameters. The destinations are
|
||||
tried in the specified order. Specify host or host:port (perform
|
||||
MX record lookups), [host] or [host]:port (no MX record lookups),
|
||||
[address] or [address]:port (numerical IP address).
|
||||
|
||||
The "mailbox_transport" and "fallback_transport" parameters now
|
||||
understand the form "transport:nexthop", with suitable defaults
|
||||
when either transport or nexthop are omitted, just like in the
|
||||
Postfix transport map. This allows you to specify for example,
|
||||
"mailbox_transport = lmtp:unix:/file/name".
|
||||
|
||||
The local_transport and default_transport configuration parameters
|
||||
can now be specified in transport:destination notation, just like
|
||||
the mailbox_transport and fallback_transport parameters. The
|
||||
:destination part is optional. However, these parameters take only
|
||||
one destination, unlike relayhost and fallback-relay which take
|
||||
any number of destinations.
|
||||
|
||||
More general virtual domain support. Postfix now supports both
|
||||
Sendmail-style virtual domains and Postfix-style virtual domains.
|
||||
Details and examples are given in the revised virtual manual page.
|
||||
|
||||
- With Sendmail-style virtual domains, local users/aliases/mailing
|
||||
lists are visible as localname@virtual.domain. This is convenient
|
||||
if you want to host mailing lists under virtual domains.
|
||||
|
||||
- With Postfix-style virtual domains, local users/aliases/mailing
|
||||
lists are not visible as localname@virtual.domain. Each virtual
|
||||
domain has its own separate name space.
|
||||
|
||||
More general "soft bounce" feature. Specify "soft_bounce = yes"
|
||||
in main.cf to prevent the SMTP server from bouncing mail while you
|
||||
are testing configurations. Until this release the SMTP server was
|
||||
not aware of soft bounces.
|
||||
|
||||
Workarounds for non-standard RFC 2554 (AUTH command) implementations.
|
||||
Specify "broken_sasl_auth_clients = yes" to enable SMTP server
|
||||
support for old Microsoft client applications. The Postfix SMTP
|
||||
client supports non-standard RFC 2554 servers by default.
|
||||
|
||||
All time-related configuration parameters now accept a one-letter
|
||||
suffix to indicate the time unit (s: second, m: minute, h: hour,
|
||||
d: day, w: week). The exceptions are the LDAP and MYSQL modules
|
||||
which are maintained separately.
|
||||
|
||||
New "import_environment" and "export_environment" configuration
|
||||
parameters provide explicit control over what environment variables
|
||||
Postfix will import, and what environment variables Postfix will
|
||||
pass on to a non-Postfix process.
|
||||
|
||||
In order to improve performance of one-to-one deliveries, Postfix
|
||||
by default now looks at up to 10000 messages at a time (was: 1000).
|
||||
|
||||
Specify "syslog_facility = log_local1" etc. to separate the logging
|
||||
from multiple Postfix instances. However, a non-default logging
|
||||
facility takes effect only after process initialization. Errors
|
||||
during command-line parsing are still logged with the default syslog
|
||||
facility, as are errors while processing the main.cf file.
|
||||
|
||||
Postfix now strips out Content-Length: headers in incoming mail to
|
||||
avoid confusion in mail user agents.
|
||||
|
||||
Specify "require_home_directory = yes" to prevent mail from being
|
||||
delivered to a user whose home directory is not mounted. This
|
||||
feature is implemented by the Postfix local delivery agent.
|
||||
|
||||
The pipe mailer has a size limit (size=nnn) command-line argument.
|
||||
|
||||
The pipe delivery agent has a configurable end-of-line attribute.
|
||||
Specify "pipe ... eol=\r\n" for delivery mechanisms that require
|
||||
CRLF record delimiters. The eol attribute understands the following
|
||||
C-style escape sequences: \a \b \f \n \r \t \v \nnn \\.
|
||||
|
||||
In master.cf you can selectively override main.cf configuration
|
||||
parameters, for example: "smtpd -o myhostname=foo.com".
|
||||
|
||||
In main.cf, specify "smtp_bind_address=x.x.x.x" to bind SMTP
|
||||
connections to a specific local interface. Or override the default
|
||||
setting in master.cf with "smtp -o smtp_bind_address=x.x.x.x".
|
||||
For now, you must specify a numeric IP address.
|
||||
|
||||
Questionable feature: with "smtp_always_send_ehlo = yes", the SMTP
|
||||
client sends EHLO regardless of the content of the SMTP server's
|
||||
greeting.
|
||||
|
||||
Specify "-d key" to postalias or postmap in order to remove one
|
||||
key. This still needs to be generalized to multi-key removal (e.g.,
|
||||
read keys from stdin).
|
||||
|
||||
Comments in Postfix configuration files no longer contain troff
|
||||
formatting codes. The text is now generated from prototype files
|
||||
in a new "proto" subdirectory.
|
||||
|
||||
Major changes with postfix-19991231:
|
||||
====================================
|
||||
|
||||
- It is now much more difficult to configure Postfix as an open
|
||||
relay. The SMTP server requires that "smtpd_recipient_restrictions"
|
||||
contains at least one restriction that by default refuses mail (as
|
||||
is the default). There were too many accidents with changes to
|
||||
the UCE restrictions.
|
||||
|
||||
- The relay_domains parameter no longer needs to contain $virtual_maps.
|
||||
|
||||
- Overhauled FAQ (html/faq.html) with many more examples.
|
||||
|
||||
- Updated UCE documentation (html/uce.html) with more examples.
|
||||
More UCE configuration examples in sample configuration files.
|
||||
|
||||
- Several little improvements to the installation procedure:
|
||||
relative symlinks, configurable directory for scratch files so the
|
||||
installation can be done without write access to the build tree.
|
||||
|
||||
- Updated LDAP client code (John Hensley).
|
||||
|
||||
- Updated mysql client code (Scott Cotton).
|
||||
|
||||
- The SMTP server now rejects mail for unknown users in virtual
|
||||
domains that are defined by Postfix virtual maps.
|
||||
|
||||
- The SMTP server can reject mail for unknown local users. Specify
|
||||
"local_recipient_maps = $alias_maps, unix:passwd.byname" if your
|
||||
local mail is delivered by a UNIX-style local delivery agent. See
|
||||
example in conf/main.cf.
|
||||
|
||||
- Use "disable_vrfy_command = yes" to disable the SMTP VRFY command.
|
||||
This prevents some forms of address harvesting.
|
||||
|
||||
- The sendmail "-f" option now understands <user> and even understands
|
||||
forms with RFC 822-style comments.
|
||||
|
||||
- New "qmgr_fudge_factor" parameter allows you to balance mailing
|
||||
list performance against response time for one-to-one mail. The
|
||||
fudge factor controls what percentage of delivery resources Postfix
|
||||
will devote to one message. With 100%, delivery of one message
|
||||
does not begin before delivery of the previous message is completed.
|
||||
This is good for list performance, bad for one-to-one mail. With
|
||||
10%, response time for one-to-one mail improves much, but list
|
||||
performance suffers: in the worst case, people near the start of a
|
||||
mailing list get a burst of postings today, while people near the
|
||||
end of the list get that same burst of postings a whole day later.
|
||||
|
||||
- It is now relatively safe to configure 550 status codes for the
|
||||
main.cf unknown_address_reject_code or unknown_client_reject_code
|
||||
parameters. The SMTP server now always sends a 450 (try again)
|
||||
reply code when an UCE restriction fails due to a soft DNS error,
|
||||
regardless of what main.cf specifies.
|
||||
|
||||
- The RBL checks now show the content of TXT records (Simon J Mudd).
|
||||
|
||||
- The Postfix SMTP server now understands a wider range of illegal
|
||||
address forms in MAIL FROM and RCPT TO commands. In order to disable
|
||||
illegal forms, specify "strict_rfc821_envelopes = yes". This also
|
||||
disables support for MAIL FROM and RCPT TO addresses without <>.
|
||||
|
||||
- Per-client/helo/sender/recipient UCE restrictions (fully-recursive
|
||||
UCE restriction parser). See the RESTRICTION_CLASS file for details.
|
||||
|
||||
- Use "postmap -q key" or "postalias -q key" for testing Postfix
|
||||
lookup tables or alias files.
|
||||
|
||||
- Use "postconf -e name=value..." to edit the main.cf file. This
|
||||
is easier and safer than editing the main.cf file by hand. The
|
||||
edits are done on a temporary copy that is renamed into place.
|
||||
|
||||
- Use "postconf -m" to display all supported lookup table types
|
||||
(Scott Cotton).
|
||||
|
||||
- New "permit_auth_destination" UCE restriction for finer-grained
|
||||
access control (Jesper Skriver).
|
||||
|
||||
Incompatible changes with postfix-19990906
|
||||
==========================================
|
||||
|
||||
- On systems that use user.lock files to protect system mailboxes
|
||||
against simultaneous updates, Postfix now uses /file/name.lock
|
||||
files while delivering to files specified in aliases/forward/include
|
||||
files. This is a no-op when the recipient lacks directory write
|
||||
permission.
|
||||
|
||||
- The LDAP client code no longer looks up a name containing "*"
|
||||
because it could be abused. See the LDAP_README file for how to
|
||||
restore previous behavior.
|
||||
|
||||
- The Postfix to PCRE interface now expects PCRE version 2.08.
|
||||
Postfix is no longer compatible with PCRE versions prior to 2.06.
|
||||
|
||||
Major changes with postfix-19990906
|
||||
===================================
|
||||
|
||||
Several bugfixes, none related to security. See the HISTORY file
|
||||
for a complete list of changes.
|
||||
|
||||
- Postfix is now distributed under IBM Public License Version 1.0
|
||||
which does not carry the controversial termination clause. The new
|
||||
license does have a requirement that contributors make source code
|
||||
available.
|
||||
|
||||
- INSTALL.sh install/upgrade procedure that replaces existing
|
||||
programs and shell scripts instead of overwriting them, and that
|
||||
leaves existing queue files and configuration files alone.
|
||||
|
||||
- The ugly Delivered-To: header can now be turned off selectively.
|
||||
The default setting is: "prepend_delivered_header = command, file,
|
||||
forward". Turning off the Delivered-To: header when forwarding
|
||||
mail is not recommended.
|
||||
|
||||
- mysql client support by Scott Cotton and Joshua Marcus, Internet
|
||||
Consultants Group, Inc. See the file MYSQL_README for instructions.
|
||||
|
||||
- reject_unauth_destination SMTP recipient restriction that rejects
|
||||
destinations not in $relay_domains. Unlike the check_relay_domains
|
||||
restriction, reject_unauth_destination ignores the client hostname.
|
||||
By Lamont Jones of Hewlett-Packard.
|
||||
|
||||
- reject_unauth_pipelining SMTP *anything* restriction to stop mail
|
||||
from spammers that improperly use SMTP command pipelining to speed
|
||||
up their deliveries.
|
||||
|
||||
- Postfix "sendmail" now issues a warning and drops privileges if
|
||||
installed set-uid root.
|
||||
|
||||
- No more duplicate delivery when "postfix reload" is immediately
|
||||
followed by "sendmail -q".
|
||||
|
||||
- No more "invalid argument" errors when a Postfix daemon opens a
|
||||
DB/DBM file while some other process is changing the file.
|
||||
|
||||
- Portability to the Mac OS X Server, Reliant Unix, AIX 3.2.5 and
|
||||
Ultrix 4.3.
|
||||
|
||||
Incompatible changes with postfix-19990601:
|
||||
===========================================
|
||||
|
||||
- The SMTP server now delays all UCE restrictions until the RCPT
|
||||
TO, VRFY or ETRN command. This makes the restrictions more useful,
|
||||
because many SMTP clients do not expect negative responses earlier
|
||||
in the protocol. In order to restore the old behavior, specify
|
||||
"smtpd_delay_reject = no" in /etc/postfix/main.cf.
|
||||
|
||||
- The Postfix local delivery agent no longer automatically propagates
|
||||
address extensions to aliases/include/forward addresses. Specify
|
||||
"propagate_unmatched_extensions = canonical, virtual, alias, forward,
|
||||
include" to restore the old behavior.
|
||||
|
||||
- The Postfix local delivery agent no longer does $name expansion
|
||||
on words found in the mailbox_command configuration parameter. This
|
||||
makes it easier to specify shell syntax. See conf/main.cf.
|
||||
|
||||
- The luser_relay syntax has changed. You can specify one address;
|
||||
it is subjected to $user, etc. expansions. See conf/main.cf.
|
||||
|
||||
- File system reorganization: daemon executables are now in the
|
||||
libexec subdirectory, command executables in the bin subdirectory.
|
||||
The INSTALL instructions now recommend installing daemons and
|
||||
commands into separate directories.
|
||||
|
||||
Major changes with postfix-19990601:
|
||||
=====================================
|
||||
|
||||
- New USER, EXTENSION, LOCAL, DOMAIN and RECIPIENT environment
|
||||
variables for delivery to command (including mailbox_command) by
|
||||
the local delivery agent. As you might expect, the information is
|
||||
censored. The list of acceptable characters is specified with the
|
||||
command_expansion_filter configuration parameter. Unacceptable
|
||||
characters are replaced by underscores. See html/local.8.html.
|
||||
|
||||
- Specify "forward_path = /var/forward/$user" to avoid looking up
|
||||
.forward files in user home directories. The default value is
|
||||
$home/.forward$recipient_delimiter$extension, $home/.forward.
|
||||
Initial code by Philip A. Prindeville, Mirapoint, Inc., USA.
|
||||
|
||||
- Conditional $name expansion in forward_path and luser_relay.
|
||||
Available names are: $user (bare user name) $shell (user login
|
||||
shell), $home (user home directory), $local (everything to the left
|
||||
of @), $extension (optional address extension), $domain (everything
|
||||
to the right of @), $recipient (the complete address) and
|
||||
$recipient_delimiter. A simple $name expands as usual. ${name?value}
|
||||
expands to value when $name is defined. ${name:value} expands to
|
||||
value when $name is not defined. With ${name?value} and ${name:value},
|
||||
the value is subject to another iteration of $name expansion.
|
||||
|
||||
- POSIX regular expression support, enabled by default on 4.4BSD,
|
||||
LINUX, HP-UX, and Solaris 2.5 and later. See conf/sample-regexp.cf.
|
||||
Initial code by Lamont Jones, Hewlett-Packard, borrowing heavily
|
||||
from the PCRE implementation by Andrew McNamara, connect.com.au
|
||||
Pty. Ltd., Australia.
|
||||
|
||||
- Regular expression checks for message headers. This requires
|
||||
support for POSIX or for PCRE regular expressions. Specify
|
||||
"header_checks = regexp:/file/name" or "header_checks = pcre:/file/name",
|
||||
and specify "/^header-name: badstuff/ REJECT" in the pattern file
|
||||
(patterns are case-insensitive by default). Code by Lamont Jones,
|
||||
Hewlett-Packard. It is to be expected that full content filtering
|
||||
will be delegated to an external command.
|
||||
|
||||
- Regular expression support for all lookup tables, including access
|
||||
control (full mail addresses only), address rewriting (canonical/virtual,
|
||||
full mail addresses only) and transport tables (full domain names
|
||||
only). However, regular expressions are not allowed for aliases,
|
||||
because that would open up security exposures.
|
||||
|
||||
- Automatic detection of changes to DB or DBM lookup tables. This
|
||||
eliminates the need to run "postfix reload" after each change to
|
||||
the SMTP access table, or to the canonical, virtual, transport or
|
||||
aliases tables.
|
||||
|
||||
- New error mailer. Specify ".domain.name error:domain is undeliverable"
|
||||
in the transport table to bounce mail for entire domains.
|
||||
|
||||
- No more Postfix lockups on Solaris (knock on wood). The code no
|
||||
longer uses Solaris UNIX-domain sockets, because they are still
|
||||
broken, even with Solaris 7.
|
||||
|
||||
- Workaround for the Solaris mailtool, which keeps an exclusive
|
||||
kernel lock on the mailbox while its window is not iconified (specify
|
||||
"sun_mailtool_compatibility = yes" in main.cf).
|
||||
|
||||
- Questionable workaround for Solaris, which reportedly loses
|
||||
long-lived exclusive locks that are held by the master daemon.
|
||||
|
||||
- New reject_unknown_{sender,recipient}_domain restrictions for
|
||||
sender and recipient mail addresses that distinguish between soft
|
||||
errors (always 450) and hard errors (unknown_address_reject_code,
|
||||
default 450).
|
||||
|
||||
- MIME-encapsulated bounce messages, making it easier to recover
|
||||
bounced mail. Initial implementation by Philip A. Prindeville,
|
||||
Mirapoint, Inc., USA. Support for RFC 1892 (multipart/report) and
|
||||
RFC 1894 (DSN) will have to wait until Postfix internals have been
|
||||
revised to support RFC 1893.
|
||||
|
||||
- Separately configurable "postmaster" addresses for single bounces
|
||||
(bounce_notice_recipient), double bounces (2bounce_notice_recipient),
|
||||
delayed mail (delay_notice_recipient), and for mailer error reports
|
||||
(error_notice_recipient). See conf/main.cf.
|
||||
|
||||
- Questionable feature: specify "best_mx_transport = local" if
|
||||
this machine is the best MX host for domains not in mydestinations.
|
||||
|
||||
Incompatible changes with postfix-19990317:
|
||||
===========================================
|
||||
|
||||
- You MUST install the new version of /etc/postfix/postfix-script.
|
||||
|
||||
- The pipe mailer "flags" syntax has changed. You now explicitly
|
||||
MUST specify the R flag in order to generate a Return-Path: message
|
||||
header (as needed by, for example, cyrus).
|
||||
|
||||
Major changes with postfix-19990317:
|
||||
====================================
|
||||
|
||||
A detailed record of changes is given in the HISTORY file.
|
||||
|
||||
- Less postmaster mail. Undeliverable bounce messages (double
|
||||
bounces) are now discarded. Specify "notify_classes = 2bounce..."
|
||||
to get copies of double bounces. Specify "notify_classes = bounce..."
|
||||
to get copies of normal and double bounces.
|
||||
|
||||
- Improved LDAP client code by John Hensley of Merit Network, USA.
|
||||
See LDAP_README for details.
|
||||
|
||||
- Perl-compatible regular expression support for lookup maps by
|
||||
Andrew McNamara, connect.com.au Pty. Ltd., Australia.. Example:
|
||||
"check_recipient_access pcre:/etc/postfix/sample-pcre.cf". Regular
|
||||
expressions provide a powerful tool not only for SMTP access control
|
||||
but also for address rewriting. See PCRE_README for details.
|
||||
|
||||
- Automatic notification of delayed mail (disabled by default).
|
||||
With "delay_warning_time = 4", Postfix informs senders when mail
|
||||
has not been delivered after 4 hours. Initial version of the code
|
||||
by Daniel Eisenbud, University of California at Berkeley. In order
|
||||
to get postmaster copies of such warnings, specify "notify_classes
|
||||
= delay...".
|
||||
|
||||
- More configurable local delivery: "mail_spool_directory" to
|
||||
specify the UNIX mail spool directory; "mailbox_transport" to
|
||||
delegate all mailbox delivery to, for example, cyrus, and
|
||||
"fallback_transport" to delegate delivery of only non-UNIX users.
|
||||
And all this without losing local aliases and local .forward
|
||||
processing. See config/main.cf and config/master.cf.
|
||||
|
||||
- Several changes to improve Postfix behavior under worst-case
|
||||
conditions (frequent Postfix restarts/reloads combined with lots
|
||||
if inbound mail, intermittent connectivity problems, SMTP servers
|
||||
that become comatose after receiving QUIT).
|
||||
|
||||
- More NFS-friendly mailbox delivery. The local delivery agent
|
||||
now avoids using root privileges where possible.
|
||||
|
||||
- For sites that do not receive mail at all, mydestination can now
|
||||
be an empty string. Be sure to set up a transport table entry to
|
||||
prevent mail from looping.
|
||||
|
||||
- New "postsuper" utility to clean up stale files from Postfix
|
||||
queues.
|
||||
|
||||
- Workaround for BSD select() collisions that cause performance
|
||||
problems on large BSD systems.
|
||||
|
||||
- Several questionable but useful features to capture mail:
|
||||
"always_bcc = address" to capture a copy of every message that
|
||||
enters the system, and "luser_relay = address" to capture mail for
|
||||
unknown recipients (does not work when mailbox_transport or
|
||||
fallback_transport are being used).
|
||||
|
||||
- Junk mail controls: new reject_non_fqdn_{hostname,sender,recipient}
|
||||
restrictions to reject non-FQDN arguments in HELO, MAIL FROM and
|
||||
RCPT TO commands, and stricter checking of numeric HELO arguments.
|
||||
|
||||
- "fallback_relay" feature for sites that use DNS but that can't
|
||||
talk to the entire world. The fall-back relay gets the mail when
|
||||
a destination is not found in the DNS or when the destination is
|
||||
found but not reachable.
|
||||
|
||||
- Several questionable controls that can help to keep mail going:
|
||||
specify "smtp_skip_4xx_greeting = yes" to skip SMTP servers that
|
||||
greet with 4XX, "ignore_mx_lookup_error = yes" to look up an A
|
||||
record when a DNS server does not respond to an MX query.
|
||||
|
||||
Incompatible changes with postfix-beta-19990122-pl01:
|
||||
=====================================================
|
||||
|
||||
None.
|
||||
|
||||
Major changes with postfix-beta-19990122-pl01:
|
||||
==============================================
|
||||
|
||||
- Restrict who may use ETRN and what domains may be specified.
|
||||
Example: "smtpd_etrn_restrictions = permit_mynetworks, reject".
|
||||
|
||||
- BIFF notifications. For compatibility reasons this feature is
|
||||
on by default. Specify "biff = no" in main.cf if your machine has
|
||||
lots of shell users.
|
||||
|
||||
- With "soft_bounce = yes", defer delivery instead of bouncing
|
||||
mail. This is a safety net for configuration errors with delivery
|
||||
agents. It has no effect on errors in virtual maps, canonical maps,
|
||||
or in junk mail restrictions.
|
||||
|
||||
- Specify "owner_request_special = no" to turn off special treatment
|
||||
of owner-foo and foo-request addresses.
|
||||
|
||||
Incompatible changes with postfix-beta-19990122:
|
||||
================================================
|
||||
|
||||
- The syntax of the transport table has changed. An entry like:
|
||||
|
||||
customer.org smtp:[gateway.customer.org]
|
||||
|
||||
no longer forwards mail for anything.customer.org. For that you
|
||||
need to specify:
|
||||
|
||||
customer.org smtp:[gateway.customer.org]
|
||||
.customer.org smtp:[gateway.customer.org]
|
||||
|
||||
This change makes transport tables more compatible with
|
||||
sendmail mailer tables.
|
||||
|
||||
- The format of syslog records has changed. A client is now always
|
||||
logged as hostname[address]; the pickup daemon logs queue file uid
|
||||
and sender address.
|
||||
|
||||
Major changes with postfix-beta-19990122:
|
||||
=========================================
|
||||
|
||||
- Junk mail restrictions can now be postponed to the RCPT TO command.
|
||||
Specify: "smtpd_recipient_restrictions = reject_maps_rbl...".
|
||||
|
||||
- More flexible interface for delivery to e.g., cyrus IMAP without
|
||||
need for PERL scripts to munge recipient addresses. In addition to
|
||||
$sender, $nexthop and $recipient, the pipe mailer now also supports
|
||||
$user, $extension and $mailbox.
|
||||
|
||||
- New mail now has precedence over deferred mail, plus some other
|
||||
tweaks to make bulk mail go faster. But it ain't no cure for massive
|
||||
network outages.
|
||||
|
||||
- Watchdog timer for systems that cause the Postfix queue manager
|
||||
to lock up, so it recovers without human intervention.
|
||||
|
||||
- Delivery to qmail-style maildir files, which is good for NFS
|
||||
environments. Specify "home_mailbox = Maildir/", or specify
|
||||
/file/name/ in aliases or in .forward files. The trailing / is
|
||||
required to turn on maildir delivery.
|
||||
|
||||
- Incremental updates of aliases and maps. Specify "postmap -i
|
||||
mapname" and it will read new entries from stdin.
|
||||
|
||||
- Newaliases will now update more than one alias database.
|
||||
Specify the names with the main.cf "alias_database" parameter.
|
||||
|
||||
- Address masquerading exceptions to prevent users from being
|
||||
masqueraded. Specify "masquerade_exceptions = root".
|
||||
|
||||
- A pipelined SMTP client. Deliveries to Postfix, qmail, LSOFT,
|
||||
zmailer, and exim (once it's fixed) speed up by some 30% for short
|
||||
messages with one recipient, with more for multi-recipient mails.
|
||||
|
||||
- Hook for local delivery to "|command" via the smrsh restricted
|
||||
shell, to restrict what commands may be used in .forward etc. files.
|
||||
Specify "local_command_shell = /some/where/smrsh -c".
|
||||
1087
RELEASE_NOTES-1.1
Normal file
1087
RELEASE_NOTES-1.1
Normal file
File diff suppressed because it is too large
Load diff
853
RELEASE_NOTES-2.0
Normal file
853
RELEASE_NOTES-2.0
Normal file
|
|
@ -0,0 +1,853 @@
|
|||
==============================================================
|
||||
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
|
||||
==============================================================
|
||||
Before upgrading from Postfix 1.1 you must stop Postfix ("postfix
|
||||
stop"). Some internal protocols have changed. No mail will be
|
||||
lost if you fail to stop and restart Postfix, but Postfix won't be
|
||||
able to receive any new mail, either.
|
||||
==============================================================
|
||||
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
|
||||
==============================================================
|
||||
|
||||
In the text below, changes are labeled with the Postfix snapshot
|
||||
that introduced the change, and whether the change introduced a
|
||||
feature, an incompatibility, or whether the feature is obsolete.
|
||||
If you upgrade from a later Postfix version, then you do not have
|
||||
to worry about incompatibilities introduced in earlier versions.
|
||||
|
||||
Official Postfix releases are called a.b.c where a=major release
|
||||
number, b=minor release number, c=patchlevel. Snapshot releases
|
||||
are now called a.b.c-yyyymmdd where yyyymmdd is the release date
|
||||
(yyyy=year, mm=month, dd=day). The mail_release_date configuration
|
||||
parameter contains the release date (both for official release and
|
||||
snapshot release). Patches change the patchlevel and the release
|
||||
date. Snapshots change only the release date, unless they include
|
||||
the same bugfixes as a patch release.
|
||||
|
||||
Major changes with Postfix version 2.0.0 (released 20021222, 20021223)
|
||||
======================================================================
|
||||
|
||||
First comes the bad news - things that may break when you upgrade
|
||||
from Postfix 1.1. Then comes the good news - things that evolved
|
||||
in snapshots over the past year.
|
||||
|
||||
For the release notes of Postfix 1.1 and earlier, see the
|
||||
RELEASE_NOTES-1.1 file.
|
||||
|
||||
Unknown Recipients are now rejected by default
|
||||
==============================================
|
||||
|
||||
[Incompatibility 20021209] The Postfix SMTP server now rejects mail
|
||||
for $mydestination domain recipients that it does not know about.
|
||||
This keeps undeliverable mail out of your queue.
|
||||
|
||||
[Incompatibility 20021209] To avoid losing mail when upgrading from
|
||||
Postfix 1.1, you need to review the LOCAL_RECIPIENT_README file if
|
||||
one of the following is true:
|
||||
|
||||
- You define $mydestination domain recipients in files other than
|
||||
/etc/passwd or /etc/aliases. For example, you define $mydestination
|
||||
domain recipients in the $virtual_mailbox_maps files.
|
||||
- You run the Postfix SMTP server chrooted (see master.cf).
|
||||
- You redefined the local delivery agent in master.cf.
|
||||
- You redefined the "local_transport" setting in main.cf.
|
||||
- You use the mailbox_transport feature of the Postfix local delivery agent.
|
||||
- You use the fallback_transport feature of the Postfix local delivery agent.
|
||||
- You use the luser_relay feature of the Postfix local delivery agent.
|
||||
|
||||
Name change of virtual domain tables
|
||||
====================================
|
||||
|
||||
This release introduces separation of lookup tables for addresses
|
||||
and for domain names of virtual domains.
|
||||
|
||||
[Incompat 20021209] the virtual_maps parameter is replaced by
|
||||
virtual_alias_maps (for address lookups) and virtual_alias_domains
|
||||
(for the names of what were formerly called "Postfix-style virtual
|
||||
domains").
|
||||
|
||||
For backwards compatibility with Postfix version 1.1, the new
|
||||
virtual_alias_maps parameter defaults to $virtual_maps, and the
|
||||
new virtual_alias_domains parameter defaults to $virtual_alias_maps.
|
||||
This means that you can still keep all information about a domain
|
||||
in one file, just like before.
|
||||
|
||||
For details, see the virtual(5) and sample-virtual.cf files.
|
||||
|
||||
[Incompat 20021209] the virtual_mailbox_maps parameter now has a
|
||||
companion parameter called virtual_mailbox_domains (for the names
|
||||
of domains served by the virtual delivery agent). virtual_mailbox_maps
|
||||
is now used for address lookups only.
|
||||
|
||||
For backwards compatibility with Postfix version 1.1,, the new
|
||||
virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
|
||||
This means that you can still keep all information about a domain
|
||||
in one file, just like before.
|
||||
|
||||
For details, see the VIRTUAL_README file.
|
||||
|
||||
[Incompat 20021209] If you use the "advanced content filter"
|
||||
technique, you MUST NOT override the virtual aliases and virtual
|
||||
mailbox settings in the SMTP server that receives mail from the
|
||||
content filter, or else mail for virtual recipients will be rejected
|
||||
with "User unknown".
|
||||
|
||||
For details, see the FILTER_README file.
|
||||
|
||||
Incompatible queue file format changes
|
||||
======================================
|
||||
|
||||
[Incompat 20020527] Queue files created with the header/body_checks
|
||||
"FILTER" feature are not compatible with "postqueue -r" (move queue
|
||||
files back to the maildrop directory) of previous Postfix releases.
|
||||
|
||||
[Incompat 20020512] Postfix queue files contain records that are
|
||||
incompatible with "postqueue -r" on all Postfix versions prior to
|
||||
1.1 and release candidates. This happens whenever the sender
|
||||
specifies MIME body type information via the SMTP `MAIL FROM'
|
||||
command, via the `sendmail -B' command line option, or via the
|
||||
Content-Transfer-Encoding: message header.
|
||||
|
||||
[Incompat 20020512] Postfix queue files may contain records that
|
||||
are incompatible with "postqueue -r" on previous 1.1 Postfix versions
|
||||
and release candidates. This happens whenever the sender specifies
|
||||
the MIME body type only via the Content-Transfer-Encoding: message
|
||||
header, and not via `MAIL FROM' or `sendmail -B'.
|
||||
|
||||
Features that are going away
|
||||
============================
|
||||
|
||||
[Obsolete 20021209] Sendmail-style virtual domains are no longer
|
||||
documented. This part of Postfix was too confusing.
|
||||
|
||||
[Obsolete 20021209] The "reject_maps_rbl" restriction is going
|
||||
away. The SMTP server now logs a warning and suggests using the
|
||||
more flexible "reject_rbl_client" feature instead.
|
||||
|
||||
[Obsolete 20021209] The "check_relay_domains" restriction is going
|
||||
away. The SMTP server logs a warning and suggests using the more
|
||||
robust "reject_unauth_destination" instead. This means that Postfix
|
||||
by default no longer grants relay permissions on the basis of the
|
||||
client hostname, and that relay clients must be authorized via
|
||||
other means such as permit_mynetworks.
|
||||
|
||||
[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
|
||||
is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
|
||||
form. The old form still exists but is no longer documented, and
|
||||
causes a warning (suggesting to use the new format) to be logged.
|
||||
For details, see "man regexp_table".
|
||||
|
||||
[Obsolete 20020819] The qmgr_site_hog_factor feature is gone (this
|
||||
would defer mail delivery for sites that occupy too much space in
|
||||
the active queue, and be a real performance drain due to excessive
|
||||
disk I/O). The new qmgr_clog_warn_time feature (see below) provides
|
||||
more useful suggestions for dealing with Postfix congestion.
|
||||
|
||||
[Obsolete 20020819] The "permit_naked_ip_address" restriction on
|
||||
HELO command syntax is unsafe when used with most smtpd_XXX_restrictions
|
||||
and will go away. Postfix logs a warning, suggesting to use
|
||||
"permit_mynetworks" instead.
|
||||
|
||||
MIME support
|
||||
============
|
||||
|
||||
[Feature 20020527] Postfix now has real MIME support. This improves
|
||||
content filtering efficiency and accuracy, and improves inter-operability
|
||||
with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
|
||||
for details.
|
||||
|
||||
[Feature 20020527] Postfix header_checks now properly recognize
|
||||
MIME headers in attachments. This is much more efficient than
|
||||
previous versions that recognized MIME headers via body_checks.
|
||||
MIME headers are now processed one multi-line header at a time,
|
||||
instead of one body line at a time. To get the old behavior,
|
||||
specify "disable_mime_input_processing = yes". More details in
|
||||
conf/sample-filter.cf.
|
||||
|
||||
[Feature 20020527] Postfix now has three classes of header patterns:
|
||||
header_checks (for primary message headers except MIME headers),
|
||||
mime_header_checks (for MIME headers), and nested_header_checks
|
||||
(for headers of attached email messages except MIME headers). By
|
||||
default, all headers are matched with header_checks.
|
||||
|
||||
[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
|
||||
mail to 7BIT when delivering to an SMTP server that does not announce
|
||||
8BITMIME support. To disable, specify "disable_mime_output_conversion
|
||||
= yes". However, this conversion is required by RFC standards.
|
||||
|
||||
[Feature 20020528] Postfix can enforce specific aspects of the MIME
|
||||
standards while receiving mail.
|
||||
|
||||
* Specify "strict_7bit_headers = yes" to disallow 8-bit characters
|
||||
in message headers. These are always illegal.
|
||||
|
||||
* Specify "strict_8bitmime_body = yes" to block mail with 8-bit
|
||||
content that is not properly labeled as 8-bit MIME. This blocks
|
||||
mail from poorly written mail software, including (bounces from
|
||||
qmail, bounces from Postfix before snapshot 20020514, and Majordomo
|
||||
approval requests) that contain valid 8BITMIME mail.
|
||||
|
||||
* Specify "strict_8bitmime = yes" to turn on both strict_7bit_headers
|
||||
and strict_8bitmime_body.
|
||||
|
||||
* Specify "strict_mime_encoding_domain = yes" to block mail from
|
||||
poorly written mail software. More details in conf/sample-mime.cf.
|
||||
|
||||
[Incompat 20020527] Postfix now rejects mail if the MIME multipart
|
||||
structure is nested more than mime_nesting_limit levels (default:
|
||||
100) when MIME input processing is enabled while receiving mail, or
|
||||
when Postfix is performing 8BITMIME to 7BIT conversion while
|
||||
delivering mail.
|
||||
|
||||
[Incompat 20020527] Postfix now recognizes "name :" as a valid
|
||||
message header, but normalizes it to "name:" for consistency
|
||||
(actually, there is so much code in Postfix that would break with
|
||||
"name :" that there is little choice, except to not recognize "name
|
||||
:" headers).
|
||||
|
||||
[Incompat 20020512] Postfix queue files contain records that are
|
||||
incompatible with "postqueue -r" on all Postfix versions prior to
|
||||
1.1 and release candidates. This happens whenever the sender
|
||||
specifies MIME body type information via the SMTP `MAIL FROM'
|
||||
command, via the `sendmail -B' command line option, or via the
|
||||
Content-Transfer-Encoding: message header.
|
||||
|
||||
[Incompat 20020512] Postfix queue files may contain records that
|
||||
are incompatible with "postqueue -r" on previous 1.1 Postfix versions
|
||||
and release candidates. This happens whenever the sender specifies
|
||||
the MIME body type only via the Content-Transfer-Encoding: message
|
||||
header, and not via `MAIL FROM' or `sendmail -B'.
|
||||
|
||||
[Feature 20020512] The Postfix SMTP and LMTP clients now properly
|
||||
pass on the MIME body type information (7BIT or 8BITMIME), provided
|
||||
that the sender properly specifies MIME body type information via
|
||||
the SMTP MAIL FROM command, via the sendmail -B command line option,
|
||||
or via MIME message headers. This includes mail that is returned
|
||||
as undeliverable.
|
||||
|
||||
Improved performance
|
||||
====================
|
||||
|
||||
[Incompat 20021209] The default queue directory hash_queue_depth
|
||||
setting is reduced to 1 level of subdirectories per Postfix queue.
|
||||
This improves "mailq" performance on most systems, but can result
|
||||
in poorer worst-case performance on systems with lots of mail in
|
||||
the queue.
|
||||
|
||||
[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
|
||||
in MAIL FROM or RCPT TO addresses (as permitted by RFC 2821). This
|
||||
eliminates one DNS lookup per sender and recipient, and can make
|
||||
a dramatic difference when sending mailing list mail via a relayhost.
|
||||
|
||||
[Incompat 20021209] The Postfix installation procedure no longer
|
||||
sets the "chattr +S" bit on Linux queue directories. Wietse has
|
||||
gotten too annoyed with naive reviewers who complain about performance
|
||||
without having a clue of what they are comparing.
|
||||
|
||||
[Feature 20021209] On mail gateway systems, separation of inbound
|
||||
mail relay traffic from outbound traffic. This eliminates a problem
|
||||
where inbound mail deliveries could become resource starved in the
|
||||
presence of a high volume of outbound mail.
|
||||
|
||||
[Feature 20021013] The body_checks_size_limit parameter limits the
|
||||
amount of text per message body segment (or attachment, if you
|
||||
prefer to use that term) that is subjected to body_checks inspection.
|
||||
The default limit is 50 kbytes. This speeds up the processing of
|
||||
mail with large attachments.
|
||||
|
||||
[Feature 20020917] Speedups of regexp table lookups by optimizing
|
||||
for the $number substitutions that are actually present in the
|
||||
right-hand side. Based on a suggestion by Liviu Daia.
|
||||
|
||||
[Feature 20020917] Speedups of regexp and pcre tables, using
|
||||
IF..ENDIF support. Based on an idea by Bert Driehuis. To protect
|
||||
a block of patterns, use:
|
||||
|
||||
if /pattern1/
|
||||
/pattern2/ result2
|
||||
/pattern3/ result3
|
||||
endif
|
||||
|
||||
IF..ENDIF can nest. Don't specify blanks at the beginning of lines
|
||||
inside IF..ENDIF, because lines beginning with whitespace are
|
||||
appended to the previous line. More details about the syntax are
|
||||
given in the pcre_table(5) and regexp_table(5) manual pages.
|
||||
|
||||
[Feature 20020717] The default timeout for establishing an SMTP
|
||||
connection has been reduced to 30 seconds, because many system
|
||||
TCP/IP stacks have an atrociously large default timeout value.
|
||||
|
||||
[Feature 20020505] Finer control over Berkeley DB memory usage,
|
||||
The parameter "berkeley_db_create_buffer_size" (default: 16 MBytes)
|
||||
specifies the buffer size for the postmap and postalias commands.
|
||||
The parameter "berkeley_db_read_buffer_size" (default: 128 kBytes)
|
||||
specifies the buffer size for all other applications. Specify
|
||||
"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
|
||||
size. Contributed by Victor Duchovni. For more information, see
|
||||
the last paragraphs of the DB_README file.
|
||||
|
||||
[Incompat 20021211] The default process limit is doubled from 50
|
||||
to 100. The default limits on the number of active queue files or
|
||||
recipients are doubled from 10000 to 20000. The default concurrency
|
||||
for parallel delivery to the same destination is doubled from 10
|
||||
to 20.
|
||||
|
||||
Improved compatibility
|
||||
======================
|
||||
|
||||
[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
|
||||
mail to 7BIT when delivering to an SMTP server that does not announce
|
||||
8BITMIME support. To disable, specify "disable_mime_output_conversion
|
||||
= yes". However, this conversion is required by RFC standards.
|
||||
|
||||
[Feature 20020512] The Postfix SMTP and LMTP clients now properly
|
||||
pass on the MIME body type information (7BIT or 8BITMIME), provided
|
||||
that the sender properly specifies MIME body type information via
|
||||
the SMTP MAIL FROM command, via the sendmail -B command line option,
|
||||
or via MIME message headers. This includes mail that is returned
|
||||
as undeliverable.
|
||||
|
||||
[Incompat 20020326] The Postfix SMTP client now breaks message
|
||||
header or body lines that are longer than $smtp_line_length_limit
|
||||
characters (default: 990). Earlier Postfix versions broke lines
|
||||
at $line_length_limit characters (default: 2048). Postfix versions
|
||||
before 20010611 did not break long lines at all. Reportedly, some
|
||||
mail servers refuse to receive mail with lines that exceed the 1000
|
||||
character limit that is specified by the SMTP standard.
|
||||
|
||||
[Incompat 20020326] The Postfix SMTP client now breaks long message
|
||||
header or body lines by inserting <CR> <LF> <SPACE>. Earlier
|
||||
Postfix versions broke long lines by inserting <CR> <LF> only. This
|
||||
broke MIME encapsulation, causing MIME attachments to "disappear"
|
||||
with Postfix versions after 20010611.
|
||||
|
||||
[Incompat 20020326] Postfix now discards text when a logical message
|
||||
header exceeds $header_size_limit characters (default: 102400).
|
||||
Earlier Postfix versions would place excess text, and all following
|
||||
text, in the message body. The same thing was done when a physical
|
||||
header line exceeded $line_length_limit characters (default: 2048).
|
||||
Both behaviors broke MIME encapsulation, causing MIME attachments
|
||||
to "disappear" with all previous Postfix versions.
|
||||
|
||||
[Incompat 20021015] The Postfix LMTP client no longer lowercases email
|
||||
addresses in MAIL FROM and RCPT TO commands.
|
||||
|
||||
[Incompat 20021013] The default Linux kernel lock style for mailbox
|
||||
delivery is changed from flock() to fcntl(). This has no impact if
|
||||
your system uses procmail for local delivery, if you use maildir-style
|
||||
mailboxes, or when mailbox access software locks mailboxes with
|
||||
username.lock files (which is usually the case with non-maildir
|
||||
mailboxes).
|
||||
|
||||
Address classes
|
||||
===============
|
||||
|
||||
[Feature 20021209] This release introduces the concept of address
|
||||
domain classes, each having its own default mail delivery transport:
|
||||
|
||||
Destination matches Default transport Default name
|
||||
==============================================================
|
||||
$mydestination or
|
||||
$inet_interfaces $local_transport local
|
||||
$virtual_alias_domains (not applicable) (not applicable)
|
||||
$virtual_mailbox_domains $virtual_transport virtual
|
||||
$relay_domains $relay_transport relay
|
||||
other $default_transport smtp
|
||||
|
||||
The benefits of these changes are:
|
||||
|
||||
- You no longer need to specify all the virtual(8) domains in the
|
||||
Postfix transport map. The virtual(8) delivery agent has
|
||||
become a first-class citizen just like local(8) or smtp(8).
|
||||
|
||||
- On mail gateway systems, separation of inbound mail relay traffic
|
||||
from outbound traffic. This eliminates a problem where inbound
|
||||
mail deliveries could become resource starved in the presence of
|
||||
a high volume of outbound mail.
|
||||
|
||||
- The SMTP server rejects unknown recipients in a more consistent
|
||||
manner than was possible with previous Postfix versions.
|
||||
|
||||
See the ADDRESS_CLASS_README file for a description of address
|
||||
classes, their benefits, and their incompatibilities.
|
||||
|
||||
New relay transport in master.cf
|
||||
================================
|
||||
|
||||
[Incompat 20021209] Postfix no longer defaults to the "smtp"
|
||||
transport for all non-local destinations. In particular, Postfix
|
||||
now uses the "relay" mail delivery transport for delivery to domains
|
||||
matching $relay_domains. This may affect your defer_transports
|
||||
settings.
|
||||
|
||||
On mail gateway systems, this allows us to separate inbound mail
|
||||
relay traffic from outbound traffic, and thereby eliminate a problem
|
||||
where inbound mail deliveries could become resource starved in the
|
||||
presence of a high volume of outbound mail.
|
||||
|
||||
[Incompat 20021209] This release adds a new "relay" service to the
|
||||
Postfix master.cf file. This is a clone of the "smtp" service. If
|
||||
your Postfix is unable to connect to the "relay" service then you
|
||||
have not properly followed the installation procedure.
|
||||
|
||||
Revision of RBL blacklisting code
|
||||
=================================
|
||||
|
||||
[Feature 20020923] Complete rewrite of the RBL blacklisting code.
|
||||
The names of RBL restrictions are now based on a suggestion that
|
||||
was made by Liviu Daia in October 2001. See conf/sample-smtpd.cf
|
||||
or html/uce.html for details.
|
||||
|
||||
[Feature 20020923] "reject_rbl_client rbl.domain.tld" for client
|
||||
IP address blacklisting. Based on code by LaMont Jones. The old
|
||||
"reject_maps_rbl" is now implemented as a wrapper around the
|
||||
reject_rbl_client code, and logs a warning that "reject_maps_rbl"
|
||||
is going away. To upgrade, specify "reject_rbl_client domainname"
|
||||
once for each domain name that is listed in maps_rbl_domains.
|
||||
|
||||
[Feature 20020923] "reject_rhsbl_sender rbl.domain.tld" for sender
|
||||
domain blacklisting. Also: reject_rhsbl_client and reject_rhsbl_recipient
|
||||
for client and recipient domain blacklisting.
|
||||
|
||||
[Feature 20020923] "rbl_reply_maps" configuration parameter for
|
||||
lookup tables with template responses per RBL server. Based on code
|
||||
by LaMont Jones. If no reply template is found the default template
|
||||
is used as specified with the default_rbl_reply configuration
|
||||
parameter. The template responses support $name expansion of
|
||||
client, helo, sender, recipient and RBL related attributes.
|
||||
|
||||
[Incompat 20020923] The default RBL "reject" server reply now
|
||||
includes an indication of *what* is being rejected: Client host,
|
||||
Helo command, Sender address, or Recipient address. This also
|
||||
changes the logfile format.
|
||||
|
||||
[Feature 20020923] "smtpd_expansion_filter" configuration parameter
|
||||
to control what characters are allowed in the expansion of template
|
||||
RBL reply $name macros. Characters outside the allowed set are
|
||||
replaced by "_".
|
||||
|
||||
More sophisticated handling of UCE-related DNS lookup errors
|
||||
============================================================
|
||||
|
||||
[Feature 20020906] More sophisticated handling of UCE-related DNS
|
||||
lookup errors. These cause Postfix to not give up so easily, so
|
||||
that some deliveries will not have to be deferred after all.
|
||||
|
||||
[Feature 20020906] The SMTP server sets a defer_if_permit flag when
|
||||
an UCE reject restriction fails due to a temporary (DNS) problem,
|
||||
to prevent unwanted mail from slipping through. The defer_if_permit
|
||||
flag is tested at the end of the ETRN and recipient restrictions.
|
||||
|
||||
[Feature 20020906] A similar flag, defer_if_reject, is maintained
|
||||
to prevent mail from being rejected because a whitelist operation
|
||||
(such as permit_mx_backup) fails due to a temporary (DNS) problem.
|
||||
|
||||
[Feature 20020906] The permit_mx_backup restriction is made more
|
||||
strict. With older versions, some DNS failures would cause mail to
|
||||
be accepted anyway, and some DNS failures would cause mail to be
|
||||
rejected by later restrictions in the same restriction list. The
|
||||
improved version will defer delivery when Postfix could make the
|
||||
wrong decision.
|
||||
|
||||
- After DNS lookup failure, permit_mx_backup will now accept the
|
||||
request if a subsequent restriction would cause the request to be
|
||||
accepted anyway, and will defer the request if a subsequent
|
||||
restriction would cause the request to be rejected.
|
||||
|
||||
- After DNS lookup failure, reject_unknown_hostname (the hostname
|
||||
given in HELO/EHLO commands) reject_unknown_sender_domain and
|
||||
reject_unknown_recipient_domain will now reject the request if a
|
||||
subsequent restriction would cause the request to be rejected
|
||||
anyway, and will defer the request if a subsequent restriction
|
||||
would cause the request to be accepted.
|
||||
|
||||
[Feature 20020906] Specify "smtpd_data_restrictions =
|
||||
reject_unauth_pipelining" to block mail from SMTP clients that send
|
||||
message content before Postfix has replied to the SMTP DATA command.
|
||||
|
||||
Other UCE related changes
|
||||
=========================
|
||||
|
||||
[Feature 20020717] The SMTP server reject_unknown_{sender,recipient}_domain
|
||||
etc. restrictions now also attempt to look up AAAA (IPV6 address)
|
||||
records.
|
||||
|
||||
[Incompat 20020513] In order to allow user@domain@domain addresses
|
||||
from untrusted systems, specify "allow_untrusted_routing = yes" in
|
||||
main.cf. This opens opportunities for mail relay attacks when
|
||||
Postfix provides backup MX service for Sendmail systems.
|
||||
|
||||
[Incompat 20020514] For safety reasons, the permit_mx_backup
|
||||
restriction no longer accepts mail for user@domain@domain. To
|
||||
recover the old behavior, specify "allow_untrusted_routing = yes"
|
||||
and live with the risk of becoming a relay victim.
|
||||
|
||||
[Incompat 20020509] The Postfix SMTP server no longer honors OK
|
||||
access rules for user@domain@postfix-style.virtual.domain, to close
|
||||
a relaying loophole with postfix-style virtual domains that have
|
||||
@domain.name catch-all patterns.
|
||||
|
||||
[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
|
||||
uses <> as the default lookup key for the null address, in order
|
||||
to work around bugs in some Berkeley DB implementations. This
|
||||
behavior is controlled with the smtpd_null_access_lookup_key
|
||||
configuration parameter.
|
||||
|
||||
Changes in transport table lookups
|
||||
==================================
|
||||
|
||||
[Feature 20020610] user@domain address lookups in the transport
|
||||
map. This feature also understands address extensions. Transport
|
||||
maps still support lookup keys in the form of domain names, but
|
||||
only with non-regexp tables. Specify mailer-daemon@my.host.name
|
||||
in order to match the null address. More in the transport(5) manual
|
||||
page.
|
||||
|
||||
[Feature 20020505] Friendlier behavior of Postfix transport tables.
|
||||
There is a new "*" wildcard pattern that always matches. The
|
||||
meaning of null delivery transport AND nexhop information field
|
||||
has changed to "do not modify": use the information that would be
|
||||
used if the transport table did not exist. This change makes it
|
||||
easier to route intranet mail (everything under my.domain) directly:
|
||||
you no longer need to specify explicit "local" transport table
|
||||
entries for every domain name that resolves to the local machine.
|
||||
For more information, including examples, see the updated transport(5)
|
||||
manual page.
|
||||
|
||||
[Incompat 20020610] Regexp/PCRE-based transport maps now see the
|
||||
entire recipient address instead of only the destination domain
|
||||
name.
|
||||
|
||||
[Incompat 20020505, 20021215] The meaning of null delivery transport
|
||||
and nexhop fields has changed incompatibly.
|
||||
|
||||
- A null delivery transport AND nexthop information field means
|
||||
"do not modify": use the delivery transport or nexthop information
|
||||
that would be used if no transport table did not exist.
|
||||
|
||||
- The delivery transport is not changed with a null delivery
|
||||
transport field and non-null nexthop field.
|
||||
|
||||
- The nexthop is reset to the recipient domain with a non-null
|
||||
transport field and a null nexthop information field.
|
||||
|
||||
Address manipulation changes
|
||||
============================
|
||||
|
||||
[Incompat 20020717] Postfix no longer strips multiple '.' characters
|
||||
from the end of an email address or domain name. Only one '.' is
|
||||
tolerated.
|
||||
|
||||
[Feature 20020717] The masquerade_domains feature now supports
|
||||
exceptions. Prepend a ! character to a domain name in order to
|
||||
not strip its subdomain structure. More information in
|
||||
conf/sample-rewrite.cf.
|
||||
|
||||
[Feature 20020717] The Postfix virtual delivery agent supports
|
||||
catch-all entries (@domain.tld) in lookup tables. These match users
|
||||
that do not have a specific user@domain.tld entry. The virtual
|
||||
delivery agent now ignores address extensions (user+foo@domain.tld)
|
||||
when searching its lookup tables, but displays the extensions in
|
||||
Delivered-To: message headers.
|
||||
|
||||
[Feature 20020610] user@domain address lookups in the transport
|
||||
map. This feature also understands address extensions. Transport
|
||||
maps still support lookup keys in the form of domain names, but
|
||||
only with non-regexp tables. Specify mailer-daemon@my.host.name
|
||||
in order to match the null address. More in the transport(5) manual
|
||||
page.
|
||||
|
||||
[Incompat 20020610] Regexp/PCRE-based transport maps now see the
|
||||
entire recipient address instead of only the destination domain
|
||||
name.
|
||||
|
||||
[Incompat 20020513] In order to allow user@domain@domain addresses
|
||||
from untrusted systems, specify "allow_untrusted_routing = yes" in
|
||||
main.cf. This opens opportunities for mail relay attacks when
|
||||
Postfix provides backup MX service for Sendmail systems.
|
||||
|
||||
[Incompat 20020509] The Postfix SMTP server no longer honors OK
|
||||
access rules for user@domain@postfix-style.virtual.domain, to close
|
||||
a relaying loophole with postfix-style virtual domains that have
|
||||
@domain.name catch-all patterns.
|
||||
|
||||
[Incompat 20020509] The appearance of user@domain1@domain2 addresses
|
||||
has changed. In mail headers, such addresses are now properly
|
||||
quoted as "user@domain1"@domain2. As a side effect, this quoted
|
||||
form is now also expected on the left-hand side of virtual and
|
||||
canonical lookup tables, but only by some of the Postfix components.
|
||||
For now, it is better not to use user@domain1@domain2 address forms
|
||||
on the left-hand side of lookup tables.
|
||||
|
||||
Regular expression and PCRE related changes
|
||||
===========================================
|
||||
|
||||
[Feature 20021209] Regular expression maps are now allowed with
|
||||
local delivery agent alias tables and with all virtual delivery
|
||||
agent lookup tables. However, regular expression substitution of
|
||||
$1 etc. is still forbidden for security reasons.
|
||||
|
||||
[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
|
||||
is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
|
||||
form. The old form still exists but is no longer documented, and
|
||||
causes a warning (suggesting to use the new format) to be logged.
|
||||
|
||||
[Incompat 20020610] Regexp/PCRE-based transport maps now see the
|
||||
entire recipient address instead of only the destination domain
|
||||
name.
|
||||
|
||||
[Incompat 20020528] With PCRE pattern matching, the `.' metacharacter
|
||||
now matches all characters including newline characters. This makes
|
||||
PCRE pattern matching more convenient to use with multi-line message
|
||||
headers, and also makes PCRE more compatible with regexp pattern
|
||||
matching. The pcre_table(5) manual page has been greatly revised.
|
||||
|
||||
New mail "HOLD" action and "hold" queue
|
||||
=======================================
|
||||
|
||||
[Feature 20020819] New "hold" queue for mail that should not be
|
||||
delivered. "postsuper -h" puts mail on hold, and "postsuper -H"
|
||||
releases mail, moving mail that was "on hold" to the deferred queue.
|
||||
|
||||
[Feature 20020821] HOLD and DISCARD actions in SMTPD access tables.
|
||||
As with the header/body version of the same, these actions apply
|
||||
to all recipients of the same queue file.
|
||||
|
||||
[Feature 20020819] New header/body HOLD action that causes mail to
|
||||
be placed on the "hold" queue. Presently, all you can do with mail
|
||||
"on hold" is to examine it with postcat, to take it "off hold" with
|
||||
"postsuper -H", or to destroy it with "postsuper -d". See
|
||||
conf/sample-filter.cf.
|
||||
|
||||
[Incompat 20020819] In mailq output, the queue ID is followed by
|
||||
the ! character when the message is in the "hold" queue (see below).
|
||||
This may break programs that process mailq output.
|
||||
|
||||
Content filtering
|
||||
=================
|
||||
|
||||
[Feature 20020823] Selective content filtering. In in SMTPD access
|
||||
tables, specify "FILTER transport:nexthop" for mail that needs
|
||||
filtering. More info about content filtering is in the Postfix
|
||||
FILTER_README file. This feature overrides the main.cf content_filter
|
||||
setting. Presently, this applies to all the recipients of a queue
|
||||
file.
|
||||
|
||||
[Feature 20020527] Selective content filtering. In header/body_check
|
||||
patterns, specify "FILTER transport:nexthop" for mail that needs
|
||||
filtering. This requires different cleanup servers before and after
|
||||
the filter, with header/body checks turned off in the second cleanup
|
||||
server. More info about content filtering is in the Postfix
|
||||
FILTER_README file. This feature overrides the main.cf content_filter
|
||||
setting. Presently, this applies to all the recipients of a queue
|
||||
file.
|
||||
|
||||
[Feature 20020527] Postfix now has real MIME support. This improves
|
||||
content filtering efficiency and accuracy, and improves inter-operability
|
||||
with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
|
||||
for details.
|
||||
|
||||
[Feature 20020527] Postfix header_checks now properly recognize
|
||||
MIME headers in attachments. This is much more efficient than
|
||||
previous versions that recognized MIME headers via body_checks.
|
||||
MIME headers are now processed one multi-line header at a time,
|
||||
instead of one body line at a time. To get the old behavior,
|
||||
specify "disable_mime_input_processing = yes". More details in
|
||||
conf/sample-filter.cf.
|
||||
|
||||
[Feature 20020527] Postfix now has three classes of header patterns:
|
||||
header_checks (for primary message headers except MIME headers),
|
||||
mime_header_checks (for MIME headers), and nested_header_checks
|
||||
(for headers of attached email messages except MIME headers). By
|
||||
default, all headers are matched with header_checks.
|
||||
|
||||
[Feature 20021013] The body_checks_size_limit parameter limits the
|
||||
amount of text per message body segment (or attachment, if you
|
||||
prefer to use that term) that is subjected to body_checks inspection.
|
||||
The default limit is 50 kbytes. This speeds up the processing of
|
||||
mail with large attachments.
|
||||
|
||||
[Feature 20020917] Speedups of regexp table lookups by optimizing
|
||||
for the $number substitutions that are actually present in the
|
||||
right-hand side. Based on a suggestion by Liviu Daia.
|
||||
|
||||
[Feature 20020917] Speedups of regexp and pcre tables, using
|
||||
IF..ENDIF support. Based on an idea by Bert Driehuis. To protect
|
||||
a block of patterns, use:
|
||||
|
||||
if /pattern1/
|
||||
/pattern2/ result2
|
||||
/pattern3/ result3
|
||||
endif
|
||||
|
||||
IF..ENDIF can nest. Don't specify blanks at the beginning of lines
|
||||
inside IF..ENDIF, because lines beginning with whitespace are
|
||||
appended to the previous line. More details about the syntax are
|
||||
given in the pcre_table(5) and regexp_table(5) manual pages.
|
||||
|
||||
Postmap/postalias/newaliases changes
|
||||
====================================
|
||||
|
||||
[Incompat 20020505] The postalias command now copies the source
|
||||
file read permissions to the result file when creating a table for
|
||||
the first time. Until now, the result file was created with default
|
||||
read permissions. This change makes postalias more similar to
|
||||
postmap.
|
||||
|
||||
[Incompat 20020505] The postalias and postmap commands now drop
|
||||
super-user privileges when processing a non-root source file. The
|
||||
file is now processed as the source file owner, and the owner must
|
||||
therefore have permission to update the result file. Specify the
|
||||
"-o" flag to get the old behavior (process non-root files with root
|
||||
privileges).
|
||||
|
||||
[Incompat 20020122] When the postmap command creates a non-existent
|
||||
result file, the new file inherits the group/other read permissions
|
||||
of the source file.
|
||||
|
||||
Assorted changes
|
||||
================
|
||||
|
||||
[Feature 20021028] The local(8) and virtual(8) delivery agents now record
|
||||
the original recipient address in the X-Original-To: message header.
|
||||
This header can also be emitted by the pipe(8) delivery agent.
|
||||
|
||||
[Incompat 20021028] With "domain in one mailbox", one message with
|
||||
multiple recipients is no longer delivered only once. It is now
|
||||
delivered as one copy for each original recipient, with the original
|
||||
recipient address listed in the X-Original-To: message header.
|
||||
|
||||
[Feature 20021024] New proxy_interfaces parameter, for sites behind a
|
||||
network address translation gateway or other type of proxy. You
|
||||
should specify all the proxy network addresses here, to avoid avoid
|
||||
mail delivery loops.
|
||||
|
||||
[Feature 20021013] Updated MacOS X support by Gerben Wierda. See
|
||||
the auxiliary/MacOSX directory.
|
||||
|
||||
[Incompat 20021013] Subtle change in ${name?result} macro expansions:
|
||||
the expansion no longer happens when $name is an empty string. This
|
||||
probably makes more sense than the old behavior.
|
||||
|
||||
[Incompat 20020917] The relayhost setting now behaves as documented,
|
||||
i.e. you can no longer specify multiple destinations.
|
||||
|
||||
[Incompatibility 20021219] The use of the XVERP extension in the
|
||||
SMTP MAIL FROM command is now restricted to SMTP clients that match
|
||||
the hostnames, domains or networks listed with the authorized_verp_clients
|
||||
parameter (default: $mynetworks).
|
||||
|
||||
[Feature 20020819] When the Postfix local delivery agent detects
|
||||
a mail delivery loop (usually the result of mis-configured mail
|
||||
pickup software), the undeliverable mail is now sent to the mailing
|
||||
list owner instead of the envelope sender address (usually the
|
||||
original poster who has no guilt, and who cannot fix the problem).
|
||||
|
||||
[Warning 20020819] The Postfix queue manager now warns when mail
|
||||
for some destination is piling up in the active queue, and suggests
|
||||
a variety of remedies to speed up delivery (increase per-destination
|
||||
concurrency limit, increase active queue size, use a separate
|
||||
delivery transport, increase per-transport process limit). The
|
||||
qmgr_clog_warn_time parameter controls the time between warnings.
|
||||
To disable these warnings, specify "qmgr_clog_warn_time = 0".
|
||||
|
||||
[Warning 20020717] The Postfix SMTP client now logs a warning when
|
||||
the same domain is listed in main.cf:mydestination as well as a
|
||||
Postfix-style virtual map. Such a mis-configuration may cause mail
|
||||
for users to be rejected with "user unknown".
|
||||
|
||||
[Feature 20020331] A new smtp_helo_name parameter that specifies
|
||||
the hostname to be used in HELO or EHLO commands; this can be more
|
||||
convenient than changing the myhostname parameter setting.
|
||||
|
||||
[Feature 20020331] Choice between multiple instances of internal
|
||||
services: bounce, cleanup, defer, error, flush, pickup, queue,
|
||||
rewrite, showq. This allows you to use different cleanup server
|
||||
settings for different SMTP server instances. For example, specify
|
||||
in the master.cf file:
|
||||
|
||||
localhost:10025 ... smtpd -o cleanup_service_name=cleanup2 ...
|
||||
cleanup2 ... cleanup -o header_checks= body_checks= ...
|
||||
|
||||
Logfile format changes
|
||||
======================
|
||||
|
||||
[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
|
||||
in MAIL FROM addresses (as permitted by RFC 2821) before logging
|
||||
the recipient address.
|
||||
|
||||
[Incompat 20021028] The Postfix SMTP server UCE reject etc. logging
|
||||
now includes the queue ID, the mail protocol (SMTP or ESMTP), and
|
||||
the hostname that was received with the HELO or EHLO command, if
|
||||
available.
|
||||
|
||||
[Incompat 20021028] The Postfix header/body_checks logging now
|
||||
includes the mail protocol (SMTP, ESMTP, QMQP) and the hostname
|
||||
that was received with the SMTP HELO or EHLO command, if available.
|
||||
|
||||
[Incompat 20021028] The Postfix status=sent/bounced/deferred logging
|
||||
now shows the original recipient address (as received before any
|
||||
address rewriting or aliasing). The original recipient address is
|
||||
logged only when it differs from the final recipient address.
|
||||
|
||||
[Incompat 20020923] The default RBL "reject" server reply now
|
||||
includes an indication of *what* is being rejected: Client host,
|
||||
Helo command, Sender address, or Recipient address. This also
|
||||
changes the logfile format.
|
||||
|
||||
LDAP related changes
|
||||
====================
|
||||
|
||||
[Incompat 20020819] LDAP API version 1 is no longer supported. The
|
||||
memory allocation and deallocation strategy has changed too much
|
||||
to maintain both version 1 and 2 at the same time.
|
||||
|
||||
[Feature 20020513] Updated LDAP client module with better handling
|
||||
of dead LDAP servers, and with configurable filtering of query
|
||||
results.
|
||||
|
||||
SASL related changes
|
||||
====================
|
||||
|
||||
[Incompat 20020819] The smtpd_sasl_local_domain setting now defaults
|
||||
to the null string, rather than $myhostname. This seems to work
|
||||
better with Cyrus SASL version 2. This change may cause incompatibility
|
||||
with the saslpasswd2 command.
|
||||
|
||||
[Feature 20020331] Support for the Cyrus SASL version 2 library,
|
||||
contributed by Jason Hoos. This adds some new functionality that
|
||||
was not available in Cyrus SASL version 1, and provides bit-rot
|
||||
insurance for the time when Cyrus SASL version 1 eventually stops
|
||||
working.
|
||||
|
||||
Berkeley DB related changes
|
||||
===========================
|
||||
|
||||
[Feature 20020505] Finer control over Berkeley DB memory usage,
|
||||
The parameter "berkeley_db_create_buffer_size" (default: 16 MBytes)
|
||||
specifies the buffer size for the postmap and postalias commands.
|
||||
The parameter "berkeley_db_read_buffer_size" (default: 256 kBytes)
|
||||
specifies the buffer size for all other applications. Specify
|
||||
"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
|
||||
size. For more information, see the last paragraphs of the DB_README
|
||||
file.
|
||||
|
||||
[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
|
||||
uses <> as the default lookup key for the null address, in order
|
||||
to work around bugs in some Berkeley DB implementations. This
|
||||
behavior is controlled with the smtpd_null_access_lookup_key
|
||||
configuration parameter.
|
||||
|
||||
[Incompat 20020201] Postfix now detects if the run-time Berkeley
|
||||
DB library routines do not match the major version number of the
|
||||
compile-time include file that was used for compiling Postfix. The
|
||||
software issues a warning and aborts in case of a discrepancy. If
|
||||
it didn't, the software was certain to crash with a segmentation
|
||||
violation.
|
||||
|
||||
Assorted workarounds
|
||||
====================
|
||||
|
||||
[Incompat 20020201] On SCO 3.2 UNIX, the input rate flow control
|
||||
is now turned off by default, because of limitations in the SCO
|
||||
UNIX kernel.
|
||||
581
RELEASE_NOTES-2.1
Normal file
581
RELEASE_NOTES-2.1
Normal file
|
|
@ -0,0 +1,581 @@
|
|||
In the text below, incompatible changes are labeled with the Postfix
|
||||
snapshot that introduced the change. If you upgrade from a later
|
||||
Postfix version, then you do not have to worry about that particular
|
||||
incompatibility.
|
||||
|
||||
The official Postfix release is called 2.1.x where 2=major release
|
||||
number, 1=minor release number, x=patchlevel. Snapshot releases
|
||||
are called 2.2-yyyymmdd where yyyymmdd is the release date (yyyy=year,
|
||||
mm=month, dd=day). The mail_release_date configuration parameter
|
||||
contains the release date (both for official release and snapshot
|
||||
release). Patches are issued for the official release and change
|
||||
the patchlevel and the release date. Patches are never issued for
|
||||
snapshot releases.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
If you run Postfix 2.0 or earlier then you must stop Postfix before
|
||||
upgrading. The master-child protocols have changed between Postfix
|
||||
1.1 and 2.0, and version 2.1 sometimes writes queue files that the
|
||||
2.0 and earlier queue managers complain about. If this happens move
|
||||
the files from the corrupt directory to the maildrop directory and
|
||||
give them another chance.
|
||||
|
||||
[Incompat 20021119] The Postfix upgrade procedure will add two new
|
||||
services to your master.cf file: "trace" and "verify". These servers
|
||||
can run inside a chroot jail, have no interaction with users, and
|
||||
don't talk to the network. If Postfix complains that "trace" and
|
||||
"verify" are not found, you made the error of copying your old
|
||||
Postfix configuration files over the new ones. Execute "postfix
|
||||
upgrade-configuration" to repair the Postfix configuration files.
|
||||
|
||||
[Incompat 20040331] Support for the non-standard Errors-To: message
|
||||
header is removed. This also helps to stop potential attacks that
|
||||
rely on bouncing mail to a destination that is not directly reachable
|
||||
by the attacker. Specify "enable_errors_to = yes" to get the old
|
||||
behavior.
|
||||
|
||||
Queue files written by Postfix 2.1 may contain information that
|
||||
is incompatible with older Postfix versions:
|
||||
|
||||
[Incompat 20040120] Queue files creates with "sendmail -v" are no
|
||||
longer compatible with Postfix versions 2.0 and earlier. A new
|
||||
record type, "killed", was introduced in order to avoid repeated
|
||||
mail delivery reports from mail that could not be delivered due to
|
||||
a temporary error condition.
|
||||
|
||||
[Incompat 20030125] This release adds a new queue file record type
|
||||
for the address specified in "REDIRECT user@domain" actions in
|
||||
access maps or header/body_checks. Queue files with these records
|
||||
will be rejected by older Postfix versions.
|
||||
|
||||
[Feature 20040120] The new queue manager nqmgr has become the
|
||||
default qmgr queue manager. For a limited time the old queue manager
|
||||
remains available under the name oqmgr. The name nqmgr still works
|
||||
but will cause a warning to be logged.
|
||||
|
||||
[Incompat 20040413] The Postfix SMTP server no longer accepts mail
|
||||
from or to an address ending in "@", including address forms that
|
||||
rewrite into an address that ends in "@"). Specify "resolve_null_domain
|
||||
= yes" to get the old behavior.
|
||||
|
||||
[Incompat 20031226] Postfix no longer allows mail addresses with
|
||||
bare numeric IP addresses (user@1.2.3.4). This is not configurable.
|
||||
The form user@[ipaddress] is still allowed.
|
||||
|
||||
[Incompat 20031226] Bounce messages now have a separate queue life
|
||||
time. This is controlled by the bounce_queue_lifetime parameter.
|
||||
|
||||
[Incompat 20031019] The authorized_verp_clients parameter was
|
||||
renamed to smtpd_authorized_verp_clients, and the default value
|
||||
was changed to disable this feature. You now have to turn it on
|
||||
explicitly.
|
||||
|
||||
Major changes - build environment
|
||||
---------------------------------
|
||||
|
||||
[Incompat 20030112] The Postfix build procedure now uses the
|
||||
pcre-config utility (part of PCRE version 3) to find out the
|
||||
pathnames of the PCRE include file and object library, instead of
|
||||
probing /usr/include and/or /usr/lib. To build with PCRE version
|
||||
2 support you will have to specify pathnames as described in
|
||||
PCRE_README. To build without PCRE support, specify: make Makefiles
|
||||
CCARGS="-DNO_PRCE".
|
||||
|
||||
Major changes - documentation
|
||||
-----------------------------
|
||||
|
||||
[Feature 20040331] Complete documentation rewrite. All parameters
|
||||
are now described in postconf(5), and all commands and daemons are
|
||||
shown in their proper context in the OVERVIEW document.
|
||||
- All documents come as HTML and ASCII text.
|
||||
- All HTML documents have hyperlinks for every parameter name,
|
||||
for every Postfix manual page, and for every README file.
|
||||
- All documents specify what feature is available in what release.
|
||||
- The sample-*.cf configuration files no longer exist. The information
|
||||
is now available in HTML documents, README files and UNIX man pages).
|
||||
- The mumble_table example configuration files no longer exist.
|
||||
|
||||
[Incompat 20040413] The LMTP, Cyrus and Qmail related README files will
|
||||
not be included in the Postfix version 2.1 distribution. They will
|
||||
be made available via http://www.postfix.org/, and in Postfix 2.2
|
||||
snapshots.
|
||||
|
||||
[Feature 20040413] You can install documentation in HTML format
|
||||
besides the README files. Installation of README files is now
|
||||
optional.
|
||||
|
||||
Major changes - access control
|
||||
------------------------------
|
||||
|
||||
[Feature 20031215] Easier debugging of SMTPD access restrictions.
|
||||
The SMTP command "xclient name=xxx addr=yyy" changes Postfix's idea
|
||||
of the remote client name and address, so that you can pretend to
|
||||
connect from anywhere on the Internet. Use of this command is
|
||||
restricted to clients that match the list of names or addresses
|
||||
specified with the smtpd_authorized_xclient_hosts parameter. By
|
||||
default, XCLIENT is not accepted from anywhere. More details are
|
||||
in the XCLIENT_README file.
|
||||
|
||||
[Feature 20030715] Support for multi-valued RBL lookup results.
|
||||
For example, specify "reject_rbl_client foo.bar.tld=127.0.0.3" to
|
||||
reject clients that are listed with a "127.0.0.3" address record.
|
||||
More information is in the postconf(5) manual page.
|
||||
|
||||
[Feature 20030917] New "check_{helo,sender,recipient}_{ns,mx}_access
|
||||
type:table" restrictions that apply the specified access table to
|
||||
the NS or MX hosts of the host/domain given in HELO, EHLO, MAIL
|
||||
FROM or RCPT TO commands. More information is in the postconf(5)
|
||||
manual page.
|
||||
|
||||
This can be used to block mail from so-called spammer havens (all
|
||||
domains that are served by the same DNS server, all domains that
|
||||
resolve to the same MX host), from sender addresses that resolve
|
||||
to Verisign's wild-card mail responder, or from domains that claim
|
||||
to have mail servers in reserved networks such as 127.0.0.1.
|
||||
|
||||
Note: OK actions are not allowed for security reasons. Instead of
|
||||
OK, use DUNNO in order to exclude specific hosts from blacklists.
|
||||
If an OK result is found for an NS or MX host, Postfix rejects the
|
||||
SMTP command with "451 Server configuration error".
|
||||
|
||||
[Feature 20040413] Support for a "WARN text..." feature in SMTPD
|
||||
access tables, just like the WARN feature in header/body_checks.
|
||||
|
||||
[Feature 20040122] New "PREPEND headername: headervalue" action in
|
||||
Postfix access maps. Primarily intended for tagging mail by for
|
||||
example, an external SMTPD policy server. See access(5).
|
||||
|
||||
[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
|
||||
maps. This action prepends a header or body line immediately before
|
||||
the line that triggers the action. See header_checks(5) for details.
|
||||
|
||||
[Feature 20030125] New "REDIRECT user@domain" action for access
|
||||
maps and header/body_checks that overrides all the originally
|
||||
specified recipients of a message. Wietse would never recommend
|
||||
that people use this to redirect (bounced) SPAM to the beneficiaries
|
||||
of an advertisement campaign. See access(5) and header_checks(5).
|
||||
|
||||
[Feature 20031215] The reject_sender_login_mismatch feature (used
|
||||
with SASL authenticated logins) is now implemented in terms of more
|
||||
basic restrictions: reject_unauth_sender_login_mismatch (reject
|
||||
mail when $sender_login_maps lists an owner for the sender address
|
||||
but the SMTP client is not SASL authenticated) and
|
||||
reject_auth_sender_login_mismatch (reject mail when the sender
|
||||
address is not owned by the SASL authenticated user). The
|
||||
sender_login_maps now support multiple owners per sender address.
|
||||
See postconf(5) for details.
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Feature 20021119] Address verification blocks mail from or to
|
||||
addresses that are not deliverable. This is turned on with the
|
||||
reject_unverified_sender UCE restriction. Addresses are verified
|
||||
by probing, that is, by sending mail that is not actually delivered
|
||||
(SMTP interruptus). Detailed information is in the
|
||||
ADDRESS_VERIFICATION_README file.
|
||||
|
||||
Address verification can follow a different route than ordinary
|
||||
mail, typically to avoid sending probes to a relay host. To make
|
||||
this possible, the address resolver supports multiple personalities.
|
||||
For more detail see the ADDRESS_VERIFICATION_README file.
|
||||
|
||||
New "sendmail -bv" option. Postfix probes the specified recipient
|
||||
addresses without actually delivering mail, and sends back an email
|
||||
delivery report. This is useful for testing address rewriting and
|
||||
address routing, and shows the final envelope and header addresses.
|
||||
This feature currently does not access or update the sender address
|
||||
verification database.
|
||||
|
||||
Major changes - content inspection
|
||||
----------------------------------
|
||||
|
||||
[Feature 20030704] The Postfix SMTP server can be configured to
|
||||
send all mail into a real-time content filter that inspects mail
|
||||
BEFORE it is queued. See the SMTPD_PROXY_README file for details.
|
||||
|
||||
[Feature 20031022] Improved logging by Postfix daemons behind an
|
||||
SMTP-based proxy filter. The logging now shows the remote client
|
||||
name and address, instead of localhost[127.0.0.1]. This uses the
|
||||
new SMTP command "XFORWARD addr=client-address name=client-hostname",
|
||||
which specifies remote client information for logging purposes.
|
||||
This command is restricted to clients that match the list of names
|
||||
or addresses specified with the smtpd_authorized_xforward_hosts
|
||||
parameter. By default, XFORWARD is not accepted from anywhere.
|
||||
For an example, see the SMTPD_PROXY_README file.
|
||||
|
||||
[Feature 20030706] New receive_override_options parameter that
|
||||
eliminates the need for different cleanup service instances before
|
||||
and after an external content filter. One parameter controls what
|
||||
happens before or after the content filter: rejecting unknown
|
||||
recipients, canonical mapping, virtual alias expansion, masquerading,
|
||||
automatic BCC recipients and header/body checks. See postconf(5)
|
||||
for the fine details.
|
||||
|
||||
[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
|
||||
maps. This action prepends a header or body line immediately before
|
||||
the line that triggers the action. See header_checks(5) for details.
|
||||
|
||||
[Feature 20030125] New "REDIRECT user@domain" action for access maps
|
||||
and header/body_checks that overrides all the originally specified
|
||||
recipients of a message. Wietse would never recommend that people
|
||||
use this to redirect (bounced) SPAM to the beneficiaries of an
|
||||
advertisement campaign. See header_checks(5) and access(5).
|
||||
|
||||
[Incompat 20030915] In header/body_checks actions, the OK action
|
||||
is being phased out, and the DUNNO action is being phased in. Both
|
||||
actions still work and do the same thing, but hopefully DUNNO causes
|
||||
less confusion. See header_checks(5) for details.
|
||||
|
||||
Major changes - policy delegation
|
||||
---------------------------------
|
||||
|
||||
[Feature 20030715] Support for SMTP access policy delegation to an
|
||||
external server. Greylisting and SPF are provided as examples.
|
||||
See the SMTPD_POLICY_README file for further information.
|
||||
|
||||
Major changes - client rate limiting
|
||||
------------------------------------
|
||||
|
||||
Note: this feature is not included with Postfix 2.1, but it is
|
||||
documented here so that the information will not be lost.
|
||||
|
||||
[Feature 20031111] Preliminary defense against SMTP clients that
|
||||
hammer an SMTP server with too many connections. By default, the
|
||||
number of simultaneous connections per client is limited to half
|
||||
the default process limit, and no limit is imposed on the number
|
||||
of successive connections per time unit that a client is allowed
|
||||
to make.
|
||||
|
||||
The new anvil server maintains the connection statistics, and logs
|
||||
the maximum connection count and connection rate per client every
|
||||
anvil_status_update_time seconds (10 minutes), or when it terminates
|
||||
(when there is no work to be done, or when "postfix reload" was
|
||||
issued). Once you have an idea what the numbers look like, you can
|
||||
clamp down the limits for your system.
|
||||
|
||||
The relevant main.cf configuration parameters are: smtpd_client-
|
||||
connection_count_limit for the number of simultaneous connections
|
||||
per client, and smtpd_client_connection_rate_limit for the number
|
||||
of successive connections per unit time and client. The time unit
|
||||
is specified with the anvil_rate_time_unit parameter, and is one
|
||||
minute by default.
|
||||
|
||||
When Postfix rejects a client, it sends a 450 status code and
|
||||
disconnects, and logs a warning with the client name/address and
|
||||
the service name from master.cf. You can, for example, capture this
|
||||
information with a logfile watching program that updates a firewall
|
||||
rule (such a watcher program is not included with Postfix).
|
||||
|
||||
To avoid rejecting authorized hosts, the smtpd_client_connection-
|
||||
limit_exceptions parameter takes a list of network/netmask expressions,
|
||||
hostnames or .domain names that are excluded from these restrictions.
|
||||
By default, all clients in $mynetworks are excluded; you will
|
||||
probably want to use a more restrictive setting.
|
||||
|
||||
For further information, see: smtpd(8) and anvil(8).
|
||||
|
||||
Major changes - configuration management
|
||||
----------------------------------------
|
||||
|
||||
[Feature 20040413] New postfix(1) command features:
|
||||
|
||||
- "postfix set-permissions" corrects Postfix file and directory
|
||||
permissions and allows you to change mail_owner or setgid_group
|
||||
settings after Postfix is installed.
|
||||
|
||||
- "postfix upgrade-configuration" fixes Postfix systems after people
|
||||
copy over their old configuration files after installing a new
|
||||
Postfix system.
|
||||
|
||||
See postfix(1) for details.
|
||||
|
||||
[Incompat 20040120] The format of the postfix-files file has changed.
|
||||
There is a new type for hard links. With hard or symbolic link
|
||||
entries, the first field is now the destination pathname and the
|
||||
"owner" field is now the origin pathname, while "group" and
|
||||
"permissions" are ignored.
|
||||
|
||||
Major changes - core functionality
|
||||
----------------------------------
|
||||
|
||||
[Feature 20030704] New enable_original_recipient parameter (default:
|
||||
yes) to control whether Postfix keeps track of original recipient
|
||||
address information. If this is turned off Postfix produces no
|
||||
X-Original-To: headers and ignores the original recipient when
|
||||
eliminating duplicates after virtual alias expansion. Code by Victor
|
||||
Duchovni.
|
||||
|
||||
[Feature 20030417] Automatic BCC recipients depending on sender or
|
||||
recipient address. The configuration parameters in question are
|
||||
"sender_bcc_maps" and "recipient_bcc_maps". See postconf(5).
|
||||
|
||||
[Incompat 20030415] Too many people mess up their net/mask patterns,
|
||||
causing open mail relay problems. Postfix processes now abort when
|
||||
given a net/mask pattern with a non-zero host portion (for example,
|
||||
168.100.189.2/28), and suggest to specify the proper net/mask
|
||||
pattern instead (for example, 168.100.189.0/28).
|
||||
|
||||
[Feature 20030415] Workaround for file system clock drift that
|
||||
caused Postfix to ignore new mail (this could happen with file
|
||||
systems mounted from a server). Postfix now logs a warning and
|
||||
proceeds with only slightly reduced performance, instead of ignoring
|
||||
new mail.
|
||||
|
||||
Major changes - database support
|
||||
--------------------------------
|
||||
|
||||
Liviu Daia took the lead in a revision of the LDAP, MySQL and
|
||||
PostgreSQL clients. Credits also go to Victor Duchovni and to
|
||||
Lamont Jones.
|
||||
|
||||
[Feature 20030915] LDAP parameters can now be defined in external
|
||||
files. Specify the LDAP maps in main.cf as
|
||||
ldap:/path/to/ldap.cf
|
||||
and write the LDAP parameters in /path/to/ldap.cf, without the
|
||||
"ldapsource_" prefix. This makes it possible to securely store
|
||||
bind passwords for plain auth outside of main.cf (which must be
|
||||
world readable). The old syntax still works, for backwards
|
||||
compatibility.
|
||||
|
||||
[Feature 20030915] Support for LDAP URLs in the LDAP parameter
|
||||
"server_host", if Postfix is linked against OpenLDAP. LDAP hosts,
|
||||
ports, and connection protocols to be used as LDAP sources can be
|
||||
specified as a blank-separated list of LDAP URLs in "server_host".
|
||||
As with OpenLDAP, specifying a port in a LDAP URL overrides
|
||||
"server_port". Examples:
|
||||
server_host = ldap://ldap.itd.umich.edu
|
||||
server_host = ldaps://ldap.itd.umich.edu:636
|
||||
server_host = ldapi://%2Fsome%2Fpath
|
||||
|
||||
[Feature 20030915] The LDAP SSL scheme ldaps:// is available if
|
||||
OpenLDAP was compiled with SSL support. New parameters "tls_ca_cert_dir",
|
||||
"tls_ca_cert_file", "tls_cert", "tls_key", "tls_require_cert",
|
||||
"tls_random_file", "tls_cipher_suite" control the certificates,
|
||||
source of random numbers, and cipher suites used for SSL connections.
|
||||
See LDAP_README for further information.
|
||||
|
||||
[Feature 20030915] Support for STARTTLS command in LDAP, if Postfix
|
||||
is linked against OpenLDAP and OpenLDAP was compiled with SSL
|
||||
support. STARTTLS is controlled by the "start_tls" parameter.
|
||||
The above parameters for certificates, source of random numbers,
|
||||
and cipher suites also apply. See LDAP_README for further information.
|
||||
|
||||
[Incompat 20030704] Support for client side LDAP caching is gone.
|
||||
OpenLDAP 2.1.13 and later no longer support it, and the feature
|
||||
never worked well. Postfix now ignores cache controlling parameters
|
||||
in an LDAP configuration file and logs a warning.
|
||||
|
||||
[Feature 20030415] PostgreSQL table lookups. Specify "pgsql:/file/name"
|
||||
where "/file/name" defines the database. See "man pgsql_table" for
|
||||
examples, and the PGSQL_README file for general information.
|
||||
|
||||
Major changes - internals
|
||||
-------------------------
|
||||
|
||||
[Incompat 20040120] The format of the postfix-files file has changed.
|
||||
There is a new type for hard links. With hard or symbolic link
|
||||
entries, the first field is now the destination pathname and the
|
||||
"owner" field is now the origin pathname, while "group" and
|
||||
"permissions" are ignored.
|
||||
|
||||
[Incompat 20040120] The LDAP and SQL client source code is moved
|
||||
to the global directory in order to eliminate reversed dependencies.
|
||||
|
||||
[Feature 20030606] Complete rewrite of the queue file record reading
|
||||
loops in the pickup, cleanup and in the queue manager daemons. This
|
||||
code had deteriorated over time. The new code eliminates an old
|
||||
problem where the queue manager had to read most queue file records
|
||||
twice in the case of an alias/include file expansion with more than
|
||||
qmgr_message_recipient_limit recipients.
|
||||
|
||||
[Feature 20030125] Code cleanup up of queue manager internals.
|
||||
Queue names are no longer mixed up with the next-hop destination,
|
||||
and the address resolver loop is now easier to understand.
|
||||
|
||||
[Feature 20030104] Multi-server daemons (servers that accept
|
||||
simultaneous connections from multiple clients) will now stop
|
||||
accepting new connections after serving $max_use clients. This
|
||||
allows multi-server daemons to automatically restart even on busy
|
||||
mail systems.
|
||||
|
||||
[Feature 20030104] Clients of multi-server daemons such as
|
||||
trivial-rewrite and the new proxymap service now automatically
|
||||
disconnect after $ipc_ttl seconds of activity (default: 1000s).
|
||||
This allows multi-server daemons to automatically restart even on
|
||||
busy mail systems.
|
||||
|
||||
[Incompat 20021119] The file format of bounce/defer logfiles has
|
||||
changed from the old one-line ad-hoc format to a more structured
|
||||
multi-line format. For backwards compatibility, Postfix now creates
|
||||
bounce/defer logfile entries that contain both the old and the new
|
||||
format, so that you can go back to an older Postfix release without
|
||||
losing information. Old Postfix versions will warn about malformed
|
||||
logfile entries, but should work properly. To disable backwards
|
||||
compatibility specify "backwards_bounce_logfile_compatibility =
|
||||
no" in main.cf.
|
||||
|
||||
[Feature 20021119] Both "sendmail -bv" and "sendmail -v" use the
|
||||
new "trace" daemon that is automatically added to master.cf when
|
||||
you upgrade.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20040413] The postmap and postalias commands now report
|
||||
errors to syslogd in addition to reporting them to the standard
|
||||
error output. This makes logfile analysis easier.
|
||||
|
||||
[Incompat 20031203] Many SMTPD "reject" logfile entries now show
|
||||
NOQUEUE instead of a queue ID. This is because Postfix no longer
|
||||
creates a queue file before the SMTP server has received a valid
|
||||
recipient.
|
||||
|
||||
Major changes - lookup table support
|
||||
------------------------------------
|
||||
|
||||
[Feature 20030704] New CIDR-based lookup table, remotely based on
|
||||
code by Jozsef Kadlecsik. For details and examples, see "man
|
||||
cidr_table".
|
||||
|
||||
[Feature 20030704] The TCP-based table lookup protocol is finished.
|
||||
For details and examples, see "man tcp_table". This will allow you
|
||||
to implement your own greylisting, or to do your own open proxy
|
||||
tests before accepting mail. This table will not be included with
|
||||
Postfix 2.1 because the protocol is obsoleted by the policy delegation
|
||||
(see elsewhere in this document) which does a much better job.
|
||||
|
||||
[Feature 20030704] Support for !/pattern/ (negative matches) in
|
||||
PCRE lookup tables by Victor Duchovni. See "man pcre_table" and
|
||||
"man regexp_table" for more.
|
||||
|
||||
Major changes - resource control
|
||||
--------------------------------
|
||||
|
||||
[Incompat 20031022] The Postfix SMTP server no longer accepts mail
|
||||
when the amount of free queue space is less than 1.5 times the
|
||||
message_size_limit value.
|
||||
|
||||
Major changes - security
|
||||
------------------------
|
||||
|
||||
[Incompat 20040413] The Postfix SMTP server no longer accepts mail
|
||||
from or to an address ending in "@", including address forms that
|
||||
rewrite into an address that ends in "@"). Specify "resolve_null_domain
|
||||
= yes" to get the old behavior.
|
||||
|
||||
[Incompat 20040331] Support for the non-standard Errors-To: message
|
||||
header is removed. This also helps to stop potential attacks that
|
||||
rely on bouncing mail to a destination that is not directly reachable
|
||||
by the attacker. Specify ""enable_errors_to = yes" to get the old
|
||||
behavior.
|
||||
|
||||
[Incompat 20040331] Tarpit delays are reduced. The Postfix SMTP
|
||||
server no longer delays responses until the client has made
|
||||
$smtpd_soft_error_limit errors, and the delay is fixed at
|
||||
$smtpd_error_sleep_time seconds. Postfix still disconnects after
|
||||
$smtpd_hard_error_limit errors.
|
||||
|
||||
[Incompat 20040120] The SMTP server can reject non-existent sender
|
||||
addresses in a local, virtual or relay domain; specify
|
||||
"reject_unlisted_sender=yes" in order to require that a sender
|
||||
address passes the same "user unknown" test as a recipient would
|
||||
have to pass. This is optional in Postfix 2.1, likely to be turned
|
||||
on by default in Postfix 2.2.
|
||||
|
||||
[Incompat 20031226] Postfix no longer allows mail addresses with
|
||||
bare numeric IP addresses (user@1.2.3.4). This is not configurable.
|
||||
The form user@[ipaddress] is still allowed.
|
||||
|
||||
[Incompat 20030305] Postfix truncates non-address information in message
|
||||
address headers (comments, etc.) to 250 characters per address, in
|
||||
order to protect vulnerable Sendmail systems against exploitation
|
||||
of a remote buffer overflow problem (CERT advisory CA-2003-07).
|
||||
|
||||
[Incompat 20030227] The smtpd_hard_error_limit and smtpd_soft_error_limit
|
||||
values now behave as documented, that is, smtpd_hard_error_limit=1
|
||||
causes Postfix to disconnect upon the first client error. Previously,
|
||||
there was an off-by-one error causing Postfix to change behavior
|
||||
after smtpd_hard/soft_error_limit+1 errors.
|
||||
|
||||
Major changes - smtp client
|
||||
---------------------------
|
||||
|
||||
[Incompat 20031223] The SMTP client now tries to connect to an
|
||||
alternate MX address when a delivery attempt fails **after the
|
||||
initial SMTP handshake**. This includes both broken connections
|
||||
and 4XX SMTP replies. To get the old behavior, specify
|
||||
"smtp_mx_session_limit = 1" in main.cf.
|
||||
|
||||
[Feature 20031223] The SMTP client now tries to connect to an
|
||||
alternate MX address when a delivery attempt fails after the
|
||||
initial SMTP handshake. This includes both broken connections
|
||||
and 4XX SMTP replies.
|
||||
|
||||
As a benefit, fallback_relay now works as promised, not just for
|
||||
sessions that fail during the initial handshake.
|
||||
|
||||
The new SMTP client connection management is controlled by two new
|
||||
configuration parameters:
|
||||
|
||||
- smtp_mx_address_limit (default unlimited): the number of MX (mail
|
||||
exchanger) IP addresses that can result from mail exchanger
|
||||
lookups.
|
||||
|
||||
- smtp_mx_session_limit (default 2): the number of SMTP sessions
|
||||
per delivery request before giving up or delivering to a fall-back
|
||||
relay, ignoring IP addresses that fail to complete the SMTP
|
||||
initial handshake.
|
||||
|
||||
[Incompat 20031022] Postfix no longer retries delivery when no MX
|
||||
host has a valid A record, for compatibility with many other MTAs.
|
||||
This change is made in anticipation of a possible Verisign "wild-card
|
||||
MX record without A record" for unregistered domains. To get the
|
||||
old behavior, specify "smtp_defer_if_no_mx_address_found = yes".
|
||||
|
||||
[Incompat 20031022] The Postfix SMTP client no longer looks in
|
||||
/etc/hosts by default. To get the old behavior, specify
|
||||
"smtp_host_lookup = dns, native".
|
||||
|
||||
[Feature 20030417] Support for sending mail to hosts not in the
|
||||
DNS, without having to turn off DNS lookups. The "smtp_host_lookup"
|
||||
parameter controls how the Postfix SMTP client looks up hosts. In
|
||||
order to use /etc/hosts besides DNS, specify "smtp_host_lookup =
|
||||
dns, native". The default is to use DNS only.
|
||||
|
||||
Major changes - user interface
|
||||
------------------------------
|
||||
|
||||
[Incompat 20040418] The non-delivery report format has changed.
|
||||
The "sorry" message and the DSN formatted report now include the
|
||||
original recipient address, when that address is different from
|
||||
the final recipient address. This makes it easier to diagnose some
|
||||
mail delivery problems that happen after mail forwarding.
|
||||
|
||||
[Incompat 20031223] In mailq (queue listing) output, there no longer
|
||||
is space between a short queue ID and the "*" (delivery in progress)
|
||||
or ! (mail on hold) status indicator. This makes the output easier
|
||||
to parse.
|
||||
|
||||
[Incompat 20030417] "sendmail -t" no longer complains when recipients
|
||||
are given on the command line. Instead, it now adds recipients from
|
||||
headers to the recipients from the command-line.
|
||||
|
||||
[Incompat 20030126] The maildir file naming algorithm has changed
|
||||
according to an updated version of http://cr.yp.to/proto/maildir.html.
|
||||
The name is now TIME.VdevIinum.HOST
|
||||
|
||||
[Incompat 20021119] The behavior of "sendmail -v" has changed. One
|
||||
-v option now produces one email report with the status of each
|
||||
recipient. Multiple -v options behave as before: turn on verbose
|
||||
logging in the sendmail and postdrop commands.
|
||||
|
||||
[Feature 20021119] New "sendmail -bv" option. Postfix probes the
|
||||
specified recipient addresses without actually delivering mail,
|
||||
and sends back an email delivery report. This is useful for testing
|
||||
address rewriting and address routing of both envelope and header
|
||||
addresses. This feature currently does not access or update the
|
||||
sender address verification database.
|
||||
|
||||
268
RELEASE_NOTES-2.10
Normal file
268
RELEASE_NOTES-2.10
Normal file
|
|
@ -0,0 +1,268 @@
|
|||
The stable Postfix release is called postfix-2.10.x where 2=major
|
||||
release number, 10=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.11-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.8 or earlier, read RELEASE_NOTES-2.9
|
||||
before proceeding.
|
||||
|
||||
Major changes - laptop-friendliness
|
||||
-----------------------------------
|
||||
|
||||
[Incompat 20120924] Postfix no longer uses FIFOs to emulate UNIX-domain
|
||||
sockets on Solaris 9 (Vintage 2002!) and later. If you install
|
||||
Postfix for the first time on an older Solaris system, edit the
|
||||
master.cf file and replace "unix" with "fifo" for the pickup and
|
||||
qmgr services.
|
||||
|
||||
[Feature 20120924] the default master.cf file now uses "unix" instead
|
||||
of "fifo" for the pickup and qmgr services. This avoids periodic
|
||||
disk drive spin-up.
|
||||
|
||||
Major changes - permit logging
|
||||
------------------------------
|
||||
|
||||
[Feature 20120303] [Feature 20120303] New control for "permit"
|
||||
logging in smtpd_mumble_restrictions (by default, the SMTP server
|
||||
logs "reject" actions but not "permit" actions). Specify
|
||||
"smtpd_log_access_permit_actions = static:all" to log all "permit"-style
|
||||
actions, or specify a list of explicit action names. More details
|
||||
are in the postconf(5) manpage.
|
||||
|
||||
Major changes - postconf
|
||||
------------------------
|
||||
|
||||
[Incompat 20121224] The postconf command produces more warnings:
|
||||
|
||||
- An attempt to modify a read-only parameter (process_name, process_id)
|
||||
in main.cf or master.cf.
|
||||
|
||||
- An undefined $name in a parameter value in main.cf or master.cf
|
||||
(except for backwards-compatibility parameters such as $virtual_maps).
|
||||
|
||||
[Feature 20121224] The postconf command has been updated to make
|
||||
trouble-shooting (and support) easier. In summary, use "postconf
|
||||
-Mxf" and "postconf -nxf" to review master.cf and main.cf parameter
|
||||
settings with expanded parameter values.
|
||||
|
||||
- "postconf -x" now expands $name in main.cf and master.cf parameter
|
||||
values.
|
||||
|
||||
- postconf warns about attempts to modify a read-only parameter
|
||||
(process_name, process_id) in main.cf or master.cf.
|
||||
|
||||
- postconf warns about an undefined $name in a parameter value in
|
||||
main.cf or master.cf (except for backwards-compatibility parameters
|
||||
such as $virtual_maps).
|
||||
|
||||
[Feature 20121227]
|
||||
|
||||
- "postconf -o name=value" overrides main.cf parameter settings.
|
||||
This can be used, for example, to examine stress-dependent settings
|
||||
with "postconf -x -o stress=yes".
|
||||
|
||||
Major changes - postscreen
|
||||
--------------------------
|
||||
|
||||
[Incompat 20121123] The postscreen deep protocol tests now log the
|
||||
last command before a protocol error ("UNIMPLEMENTED" when the last
|
||||
command is not implemented, "CONNECT" when there was no prior
|
||||
command). The changed logfile messages are:
|
||||
|
||||
NON-SMTP COMMAND from [address]:port after command: text
|
||||
BARE NEWLINE from [address]:port after command
|
||||
COMMAND TIME LIMIT from [address]:port after command
|
||||
COMMAND COUNT LIMIT from [address]:port after command
|
||||
COMMAND LENGTH LIMIT from [address]:port after command
|
||||
|
||||
Major changes - load-balancer support
|
||||
-------------------------------------
|
||||
|
||||
[Incompat 20120625] The postscreen(8)-to-smtpd(8) protocol has
|
||||
changed. To avoid "cannot receive connection attributes" warnings
|
||||
and dropped connections, execute the command "postfix reload". No
|
||||
mail will be lost as long as the remote SMTP client tries again
|
||||
later.
|
||||
|
||||
[Feature 20120625] Support for upstream proxy agent in the postscreen(8)
|
||||
and smtpd(8) daemons. To enable the haproxy protocol, specify one
|
||||
of the following:
|
||||
|
||||
postscreen_upstream_proxy_protocol = haproxy
|
||||
smtpd_upstream_proxy_protocol = haproxy
|
||||
|
||||
Note 1: smtpd_upstream_proxy_protocol can't be used in smtpd processes
|
||||
that are behind postscreen. Configure postscreen_upstream_proxy_protocol
|
||||
instead.
|
||||
|
||||
Note 2: To use the nginx proxy with smtpd(8), enable the XCLIENT
|
||||
protocol with smtpd_authorized_xclient_hosts. This supports SASL
|
||||
authentication in the proxy agent (Postfix 2.9 and later).
|
||||
|
||||
Major changes - relay safety
|
||||
----------------------------
|
||||
|
||||
[Incompat 20130613] New smtpd_relay_restrictions parameter built-in
|
||||
default settings:
|
||||
|
||||
smtpd_relay_restrictions =
|
||||
permit_mynetworks
|
||||
permit_sasl_authenticated
|
||||
defer_unauth_destination
|
||||
|
||||
This safety net prevents open relay problems due to mistakes
|
||||
with spam filter rules in smtpd_recipient_restrictions.
|
||||
|
||||
If your site has a complex mail relay policy configured under
|
||||
smtpd_recipient_restrictions, this safety net may defer mail that
|
||||
Postfix should accept.
|
||||
|
||||
To fix this safety net, take one of the following actions:
|
||||
|
||||
- Set smtpd_relay_restrictions empty, and keep using the existing
|
||||
mail relay authorization policy in smtpd_recipient_restrictions.
|
||||
|
||||
- Copy the existing mail relay authorization policy from
|
||||
smtpd_recipient_restrictions to smtpd_relay_restrictions.
|
||||
|
||||
There is no need to change the value of smtpd_recipient_restrictions.
|
||||
|
||||
[Feature 20130613] This version introduces the smtpd_relay_restrictions
|
||||
feature for mail relay control. The new built-in default settings
|
||||
are:
|
||||
|
||||
smtpd_relay_restrictions =
|
||||
permit_mynetworks
|
||||
permit_sasl_authenticated
|
||||
defer_unauth_destination
|
||||
|
||||
smtpd_recipient_restrictions =
|
||||
( optional spam blocking rules would go here )
|
||||
|
||||
For comparison, this is the Postfix before 2.10 default:
|
||||
|
||||
smtpd_recipient_restrictions =
|
||||
permit_mynetworks
|
||||
reject_unauth_destination
|
||||
( optional spam blocking rules would go here )
|
||||
|
||||
With Postfix versions before 2.10, the mail relay policy and spam
|
||||
blocking policy were combined under smtpd_recipient_restrictions,
|
||||
resulting in error-prone configuration.
|
||||
|
||||
As of Postfix 2.10, the mail relay policy is preferably implemented
|
||||
with smtpd_relay_restrictions, so that a permissive spam blocking
|
||||
policy under smtpd_recipient_restrictions will not unexpectedly
|
||||
result in a permissive mail relay policy.
|
||||
|
||||
As of Postfix 2.10.0 the smtpd_relay_restrictions parameter built-in
|
||||
default settings are:
|
||||
|
||||
smtpd_relay_restrictions =
|
||||
permit_mynetworks
|
||||
permit_sasl_authenticated
|
||||
defer_unauth_destination
|
||||
|
||||
If your site has a complex mail relay policy configured under
|
||||
smtpd_recipient_restrictions, this safety net may defer mail that
|
||||
Postfix should accept.
|
||||
|
||||
To migrate from an earlier Postfix release with the least amount
|
||||
of pain:
|
||||
|
||||
- Set smtpd_relay_restrictions empty, and keep using the existing
|
||||
mail relay authorization policy in smtpd_recipient_restrictions.
|
||||
|
||||
- There is no need to change the value of smtpd_recipient_restrictions.
|
||||
|
||||
To take advantage of the new smtpd_relay_restrictions feature:
|
||||
|
||||
- Copy the existing mail relay authorization policy from
|
||||
smtpd_recipient_restrictions to smtpd_relay_restrictions.
|
||||
|
||||
- There is no need to change the value of smtpd_recipient_restrictions.
|
||||
|
||||
Major changes - start-up
|
||||
------------------------
|
||||
|
||||
[Feature 20120306] New master "-w" option, to wait for master daemon
|
||||
process initialization to complete. This feature returns an error
|
||||
exit status if master daemon initialization fails, or if it does
|
||||
not complete in a reasonable amount of time. The exit status is
|
||||
used by "postfix start" to provide more accurate information to
|
||||
system start-up scripts.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Incompat 20130203] Thanks to OpenSSL documentation, the Postfix
|
||||
2.9.0..2.9.5 SMTP client and server server used an incorrect procedure
|
||||
to compute TLS certificate PUBLIC-KEY fingerprints (these may be
|
||||
used in the check_ccert_access and in smtp_tls_policy_maps features).
|
||||
Support for certificate PUBLIC-KEY finger prints was introduced
|
||||
with Postfix 2.9; there is no known problem with the certificate
|
||||
fingerprint algorithms available since Postfix 2.2.
|
||||
|
||||
Certificate PUBLIC-KEY finger prints may be used in the Postfix
|
||||
SMTP server (with "check_ccert_access") and in the Postfix SMTP
|
||||
client (with the "fingerprint" security level).
|
||||
|
||||
Specify "tls_legacy_public_key_fingerprints = yes" temporarily,
|
||||
pending a migration from configuration files with incorrect Postfix
|
||||
2.9.0..2.9.5 certificate PUBLIC-KEY finger prints, to the correct
|
||||
fingerprints used by Postfix 2.9.6 and later.
|
||||
|
||||
To compute the correct PUBLIC-KEY finger prints:
|
||||
|
||||
# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
|
||||
$ openssl x509 -in cert.pem -noout -pubkey | \
|
||||
openssl pkey -pubin -outform DER | \
|
||||
openssl dgst -sha1 -c
|
||||
|
||||
# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
|
||||
$ openssl x509 -in cert.pem -noout -pubkey | \
|
||||
openssl rsa -pubin -outform DER | \
|
||||
openssl dgst -md5 -c
|
||||
|
||||
[Feature 20120422] This release adds support to turn off the TLSv1.1
|
||||
and TLSv1.2 protocols. Introduced with OpenSSL version 1.0.1, these
|
||||
are known to cause inter-operability problems with for example
|
||||
hotmail.
|
||||
|
||||
The radical workaround is to temporarily turn off problematic
|
||||
protocols globally:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
|
||||
smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
|
||||
|
||||
smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
|
||||
smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
|
||||
|
||||
However, it may be better to temporarily turn off problematic
|
||||
protocols for broken sites only:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
|
||||
|
||||
/etc/postfix/tls_policy:
|
||||
example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2
|
||||
|
||||
Important:
|
||||
|
||||
- Note the use of ":" instead of comma or space. Also, note that
|
||||
there is NO space around the "=" in "protocols=".
|
||||
|
||||
- The smtp_tls_policy_maps lookup key must match the "next-hop"
|
||||
destination that is given to the Postfix SMTP client. If you
|
||||
override the next-hop destination with transport_maps, relayhost,
|
||||
sender_dependent_relayhost_maps, or otherwise, you need to specify
|
||||
the same destination for the smtp_tls_policy_maps lookup key.
|
||||
280
RELEASE_NOTES-2.11
Normal file
280
RELEASE_NOTES-2.11
Normal file
|
|
@ -0,0 +1,280 @@
|
|||
The stable Postfix release is called postfix-2.11.x where 2=major
|
||||
release number, 11=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.12-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.9 or earlier, read RELEASE_NOTES-2.10
|
||||
before proceeding.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Documentation 20131218] The new FORWARD_SECRECY_README document
|
||||
conveniently presents all information about Postfix "perfect" forward
|
||||
secrecy support in one place: what forward secrecy is, how to tweak
|
||||
settings, and what you can expect to see when Postfix uses ciphers
|
||||
with forward secrecy.
|
||||
|
||||
[Feature 20130602] Support for PKI-less TLS server certificate
|
||||
verification, where the CA public key or the server certificate is
|
||||
identified via DNSSEC lookup.
|
||||
|
||||
This feature introduces new TLS security levels called "dane" and
|
||||
"dane-only" (DNS-based Authentication of Named Entities) that use
|
||||
DNSSEC to look up CA or server certificate information. The details
|
||||
of DANE core protocols are still evolving, as are the details of
|
||||
how DANE should be used in the context of SMTP. Postfix implements
|
||||
what appears to be a "rational" subset of the DANE profiles that
|
||||
is suitable for SMTP.
|
||||
|
||||
The problem with conventional PKI is that there are literally
|
||||
hundreds of organizations world-wide that can provide a certificate
|
||||
in anyone's name. There have been widely-published incidents in
|
||||
recent history where a certificate authority gave out an inappropriate
|
||||
certificate (e.g., a certificate in the name of Microsoft to someone
|
||||
who did not represent Microsoft), where a CA was compromised (e.g.,
|
||||
DigiNotar, Comodo), or where a CA made operational mistakes (e.g.,
|
||||
TURKTRUST). Another concern is that a legitimate CA might be coerced
|
||||
to provide a certificate that allows its government to play
|
||||
man-in-the-middle on TLS traffic and observe the plaintext.
|
||||
|
||||
Major changes - LMDB database support
|
||||
-------------------------------------
|
||||
|
||||
LMDB is a memory-mapped database that was originally developed as
|
||||
part of OpenLDAP. The Postfix LMDB driver was originally contributed
|
||||
by Howard Chu, LMDB's creator.
|
||||
|
||||
LMDB can be used for all Postfix lookup tables and caches. It is
|
||||
the first persistent Postfix database that can be shared among
|
||||
multiple writers such as postscreen daemons (Postfix already supported
|
||||
shared non-persistent memcached caches). See lmdb_table(5) and
|
||||
LMDB_README for further information, including how to access Postfix
|
||||
LMDB databases with non-Postfix programs.
|
||||
|
||||
Postfix currently requires LMDB version 0.9.11 or later. The minimum
|
||||
version may change over time in the light of deployment experience.
|
||||
|
||||
Major changes - postscreen whitelisting
|
||||
---------------------------------------
|
||||
|
||||
[Feature 20130512] Allow a remote SMTP client to skip postscreen(8)
|
||||
tests based on its postscreen_dnsbl_sites score.
|
||||
|
||||
Specify a negative "postscreen_dnsbl_whitelist_threshold" value to
|
||||
enable this feature. When a client passes the threshold value
|
||||
without having failed other tests, all pending or disabled tests
|
||||
are flagged as completed.
|
||||
|
||||
This feature can mitigate the email delays due to "after 220 greeting"
|
||||
protocol tests, which otherwise require that a client reconnects
|
||||
before it can deliver mail. Some providers such as Google don't
|
||||
retry from the same IP address. This can result in large email
|
||||
delivery delays.
|
||||
|
||||
Major changes - recipient_delimiter
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20130405] The recipient_delimiter parameter can now specify
|
||||
a set of characters. A user name is now separated from its address
|
||||
extension by the first character that matches the recipient_delimiter
|
||||
set.
|
||||
|
||||
For example, specify "recipient_delimiter = +-" to support both the
|
||||
Postfix-style "+" and the qmail-style "-" extension delimiter.
|
||||
|
||||
As before, this implementation recognizes one delimiter character
|
||||
per email address, and one address extension per email address.
|
||||
|
||||
Major changes - smtpd access control
|
||||
------------------------------------
|
||||
|
||||
[Feature 20131031] The check_sasl_access feature can be used to
|
||||
block hijacked logins. Like other check_mumble_access features it
|
||||
queries a lookup table (in this case with the SASL login name), and
|
||||
it supports the same actions as any Postfix access(5) table.
|
||||
|
||||
[Feature 20130924] The reject_known_sender_login_mismatch feature
|
||||
applies reject_sender_login_mismatch only to MAIL FROM addresses
|
||||
that are known in $smtpd_sender_login_maps.
|
||||
|
||||
Major changes - MacOS X
|
||||
-----------------------
|
||||
|
||||
[Feature 20130325] Full support for kqueue() event handling which
|
||||
scales better with large numbers of file handles, plus a workaround
|
||||
for timeout handling on file handles (such as /dev/urandom) that
|
||||
still do not correctly support poll().
|
||||
|
||||
Major changes - master
|
||||
----------------------
|
||||
|
||||
[Incompat 20131217] The master_service_disable parameter value
|
||||
syntax has changed: use "service/type" instead of "service.type".
|
||||
The new form is consistent with postconf(1) namespaces for master.cf.
|
||||
The old form is still supported to avoid breaking existing
|
||||
configurations.
|
||||
|
||||
Major changes - milter
|
||||
----------------------
|
||||
|
||||
[Feature 20131126] Support for ESMTP parameters "NOTIFY" and "ORCPT"
|
||||
in the SMFIR_ADDRCPT_PAR (add recipient with parameters) request.
|
||||
Credits: Andrew Ayer.
|
||||
|
||||
Major changes - mysql
|
||||
---------------------
|
||||
|
||||
[Feature 20131117] MySQL client support for option_file, option_group,
|
||||
tls_cert_file, tls_key_file, tls_CAfile, tls_CApath, tls_verify_cert.
|
||||
Credits: Gareth Palmer.
|
||||
|
||||
Major changes - postconf
|
||||
------------------------
|
||||
|
||||
[Feature 20131217] Support for advanced master.cf query and update
|
||||
operations. This was implemented primarily to support automated
|
||||
system management tools.
|
||||
|
||||
The goal is to make all Postfix master.cf details accessible as
|
||||
lists of "name=value" pairs, where the names are organized into
|
||||
structured name spaces. This allows other programs to query
|
||||
information or request updates, without having to worry about the
|
||||
exact layout of master.cf files.
|
||||
|
||||
Managing master.cf service attributes
|
||||
-------------------------------------
|
||||
|
||||
First, an example that shows the smtp/inet service in the traditional
|
||||
form:
|
||||
|
||||
$ postconf -M smtp/inet
|
||||
smtp inet n - n - - smtpd
|
||||
|
||||
Different variants of this command show different amounts of output.
|
||||
For example, "postconf -M smtp" enumerates all services that have
|
||||
a name "smtp" and any service type ("inet", "unix", etc.), and
|
||||
"postconf -M" enumerates all master.cf services.
|
||||
|
||||
General rule: each name component that is not present becomes a "*"
|
||||
wildcard.
|
||||
|
||||
Coming back to the above example, the postconf -F option can now
|
||||
enumerate the smtp/inet service fields as follows:
|
||||
|
||||
$ postconf -F smtp/inet
|
||||
smtp/inet/service = smtp
|
||||
smtp/inet/type = inet
|
||||
smtp/inet/private = n
|
||||
smtp/inet/unprivileged = -
|
||||
smtp/inet/chroot = n
|
||||
smtp/inet/wakeup = -
|
||||
smtp/inet/process_limit = -
|
||||
smtp/inet/command = smtpd
|
||||
|
||||
This form makes it very easy to change one field in master.cf.
|
||||
For example to turn on chroot on the smtp/inet service you use:
|
||||
|
||||
$ postconf -F smtp/inet/chroot=y
|
||||
$ postfix reload
|
||||
|
||||
Moreover, with "-F" you can specify "*" for service name or service
|
||||
type to get a wild-card match. For example, to turn off chroot on
|
||||
all Postfix daemons, use this:
|
||||
|
||||
$ postconf -F '*/*/chroot=n'
|
||||
$ postfix reload
|
||||
|
||||
Managing master.cf service "-o parameter=value" settings
|
||||
--------------------------------------------------------
|
||||
|
||||
For a second example, let's look at the submission service. This
|
||||
service typically has multiple "-o parameter=value" overrides. First
|
||||
the traditional view:
|
||||
|
||||
$ postconf -Mf submission
|
||||
submission inet n - n - - smtpd
|
||||
-o smtpd_tls_security_level=encrypt
|
||||
-o smtpd_sasl_auth_enable=yes
|
||||
...
|
||||
|
||||
The postconf -P option can now enumerate these parameters as follows:
|
||||
|
||||
$ postconf -P submission
|
||||
submission/inet/smtpd_sasl_auth_enable = yes
|
||||
submission/inet/smtpd_tls_security_level = encrypt
|
||||
...
|
||||
|
||||
Again, this form makes it very easy to modify one parameter
|
||||
setting. For example, to change the smtpd_tls_security_level setting
|
||||
for the submission/inet service:
|
||||
|
||||
$ postconf -P 'submission/inet/smtpd_tls_security_level=may'
|
||||
|
||||
You can create or remove a parametername=parametervalue setting:
|
||||
|
||||
Create:
|
||||
$ postconf -P 'submission/inet/parametername=parametervalue'
|
||||
|
||||
Remove:
|
||||
$ postconf -PX submission/inet/parametername
|
||||
|
||||
Finally, always execute "postfix reload" after updating master.cf.
|
||||
|
||||
Managing master.cf service entries
|
||||
----------------------------------
|
||||
|
||||
Finally, adding master.cf entries is possible, but currently this
|
||||
does not yet have "advanced" support. It can only be done at the
|
||||
level of the traditional master.cf file format.
|
||||
|
||||
Suppose that you need to configure a Postfix SMTP client that will
|
||||
handle slow email deliveries. To implement this you need to clone
|
||||
the smtp/unix service settings and create a new delay/unix service.
|
||||
|
||||
First, you would enumerate the smtp/unix service like this:
|
||||
|
||||
$ postconf -M smtp/unix
|
||||
smtp unix - - n - - smtp
|
||||
|
||||
Then you would copy those fields (except the first field) by hand
|
||||
to create the delay/unix service:
|
||||
|
||||
$ postconf -M delay/unix="delay unix - - n - - smtp"
|
||||
|
||||
To combine the above steps in one command:
|
||||
|
||||
$ postconf -M delay/unix="`postconf -M smtp/unix|awk '{$1 = "delay"}'`"
|
||||
|
||||
This is perhaps not super-convenient for manual cloning, but it
|
||||
should be sufficient for programmatic configuration management.
|
||||
|
||||
Again, always execute "postfix reload" after updating master.cf.
|
||||
|
||||
Deleting or commenting out master.cf entries
|
||||
--------------------------------------------
|
||||
|
||||
The -X (delete entry) and -# (comment out entry) options already
|
||||
exist for main.cf, and they now also work work for entire master.cf
|
||||
entries:
|
||||
|
||||
Remove main.cf or master.cf entry:
|
||||
$ postconf -X parametername
|
||||
$ postconf -MX delay/unix
|
||||
|
||||
Comment out main.cf or master.cf entry:
|
||||
$ postconf -# parametername
|
||||
$ postconf -M# delay/unix
|
||||
|
||||
As with main.cf, there is no support to "undo" master.cf changes
|
||||
that are made with -X or -#.
|
||||
|
||||
Again, always execute "postfix reload" after updating master.cf.
|
||||
443
RELEASE_NOTES-2.2
Normal file
443
RELEASE_NOTES-2.2
Normal file
|
|
@ -0,0 +1,443 @@
|
|||
The stable Postfix release is called postfix-2.2.x where 2=major
|
||||
release number, 2=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.3-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.
|
||||
|
||||
Main changes with Postfix version 2.2
|
||||
-------------------------------------
|
||||
|
||||
This is a summary of the changes. These and more are detailed in
|
||||
the following sections of this document.
|
||||
|
||||
- TLS and IPv6 support are now built into Postfix, based on code
|
||||
from third-party patches.
|
||||
|
||||
- Extended query interface for LDAP, MySQL and PostgreSQL with free
|
||||
form SQL queries, and domain filters to reduce unnecessary lookups.
|
||||
|
||||
- SMTP client-side connection reuse. This can dramatically speed
|
||||
up deliveries to high-volume destinations that have some servers
|
||||
that respond, and some non-responding mail servers.
|
||||
|
||||
- By default, Postfix no longer rewrites message headers in mail
|
||||
from remote clients. This includes masquerading, canonical mapping,
|
||||
replacing "!" and "%" by "@", and appending the local domain to
|
||||
incomplete addresses. Thus, spam from poorly written software no
|
||||
longer looks like it came from a local user.
|
||||
|
||||
- When your machine does not have its own domain name, Postfix can
|
||||
now replace your "home network" email address by your ISP account
|
||||
in outgoing SMTP mail, while leaving your email address unchanged
|
||||
when sending mail to someone on the local machine.
|
||||
|
||||
- Compatibility workarounds: you can now selectively turn off ESMTP
|
||||
features such as AUTH or STARTTLS in the Postfix SMTP client or
|
||||
server, without having to "dumb down" other mail deliveries, and
|
||||
without having to use transport maps for outgoing mail.
|
||||
|
||||
- Remote SMTP client resource control (the anvil server). This
|
||||
allows you to limit the number of connections, or the number of
|
||||
MAIL FROM and RCPT TO commands that an SMTP client can send per
|
||||
unit time.
|
||||
|
||||
- Support for CDB, SDBM and NIS+ databases is now built into Postfix
|
||||
(but the CDB and SDBM libraries are not).
|
||||
|
||||
- New SMTP access control features, and more.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
BEFORE upgrading from an older release you MUST stop Postfix, unless
|
||||
you're running a Postfix 2.2 snapshot release that already has
|
||||
Postfix 2.2 IPV6 and TLS support.
|
||||
|
||||
AFTER upgrading from an older release DO NOT copy the old
|
||||
master.cf/main.cf files over the new files. Instead, you MUST let
|
||||
the Postfix installation procedure update the existing configuration
|
||||
files with new service entries.
|
||||
|
||||
[Incompat 20041118] The master-child protocol has changed. The
|
||||
Postfix master daemon will log warnings about partial status updates
|
||||
if you don't stop and start Postfix.
|
||||
|
||||
[Incompat 20041023, 20041009] The queue manager to delivery agent
|
||||
protocol has changed. Mail will remain queued if you do not restart
|
||||
the queue manager.
|
||||
|
||||
[Incompat 20050111] The upgrade procedure adds the tlsmgr service
|
||||
to the master.cf file. This service entry is not compatible with
|
||||
the Postfix/TLS patch.
|
||||
|
||||
[Feature 20040919] The upgrade procedure adds the discard service
|
||||
to the master.cf file.
|
||||
|
||||
[Feature 20040720] The upgrade procedure adds the scache (shared
|
||||
connection cache) service to the master.cf file.
|
||||
|
||||
Major changes - IPv6 support
|
||||
----------------------------
|
||||
|
||||
[Feature 20050111] Postfix version 2.2 IP version 6 support based
|
||||
on the Postfix/IPv6 patch by Dean Strik and others. IPv6 support
|
||||
is always compiled into Postfix on systems that have Postfix
|
||||
compatible IPv6 support. On other systems Postfix will simply use
|
||||
IP version 4 just like it did before. See the IPV6_README document
|
||||
for what systems are supported, and how to turn on IPv6 in main.cf.
|
||||
|
||||
[Incompat 20050111] Postfix version 2.2 IPv6 support differs from
|
||||
the Postfix/IPv6 patch by Dean Strik in a few minor ways.
|
||||
|
||||
- Network protocol support including DNS lookup is selected with
|
||||
the inet_protocols parameter instead of the inet_interfaces parameter.
|
||||
This is needed so that Postfix will not attempt to deliver mail via
|
||||
IPv6 when the system has no IPv6 connectivity.
|
||||
|
||||
- The lmtp_bind_address6 feature was omitted. The Postfix LMTP
|
||||
client will be absorbed into the SMTP client, so there is no reason
|
||||
to keep adding features to the LMTP client.
|
||||
|
||||
- The CIDR-based address matching code was rewritten. The new
|
||||
behavior is believed to be closer to expectation. The results may
|
||||
be incompatible with that of the Postfix/IPv6 patch.
|
||||
|
||||
[Incompat 20050117] The Postfix SMTP server now requires that IPv6
|
||||
addresses in SMTP commands are specified as [ipv6:ipv6address], as
|
||||
described in RFC 2821.
|
||||
|
||||
Major changes - TLS support
|
||||
---------------------------
|
||||
|
||||
[Feature 20041210] Postfix version 2.2 TLS support, based on the
|
||||
Postfix/TLS patch by Lutz Jaenicke. TLS support is not compiled
|
||||
in by default. For more information about Postfix 2.2 TLS support,
|
||||
see the TLS_README document.
|
||||
|
||||
[Incompat 20041210] Postfix version 2.2 TLS support differs from
|
||||
the Postfix/TLS patch by Lutz Jaenicke in a few minor ways.
|
||||
|
||||
- main.cf: Use btree instead of sdbm for TLS session cache databases.
|
||||
|
||||
Session caches are now accessed only by the tlsmgr(8) process,
|
||||
so there are no concurrency issues. Although Postfix still has
|
||||
an SDBM client, the SDBM library (1000 lines of code) is no longer
|
||||
included with Postfix.
|
||||
|
||||
TLS session caches can use any database that can store objects
|
||||
of several kbytes or more, and that implements the sequence
|
||||
operation. In most cases, btree databases should be adequate.
|
||||
|
||||
NOTE: You cannot use dbm databases. TLS session objects are too
|
||||
large.
|
||||
|
||||
- master.cf: Specify unix instead of fifo for the tlsmgr service type.
|
||||
This change is automatically made by the Postfix upgrade procedure.
|
||||
|
||||
The smtp(8) and smtpd(8) processes use a client-server protocol
|
||||
in order to access the tlsmgr(8)'s pseudo-random number generation
|
||||
(PRNG) pool, and in order to access the TLS session cache databases.
|
||||
Such a protocol cannot be run across fifos.
|
||||
|
||||
[Feature 20050209] The Postfix SMTP server policy delegation protocol
|
||||
now supplies TLS client certificate information after successful
|
||||
verification. The new policy delegation protocol attribute names
|
||||
are ccert_subject, ccert_issuer and ccert_fingerprint.
|
||||
|
||||
[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
|
||||
to enforce access control based on hexadecimal client certificate
|
||||
fingerprints.
|
||||
|
||||
Major changes - SMTP client connection cache
|
||||
--------------------------------------------
|
||||
|
||||
[Feature 20040720] SMTP client-side connection caching. Instead of
|
||||
disconnecting immediately after a mail transaction, the Postfix
|
||||
SMTP client can save the open connection to the scache(8) connection
|
||||
cache daemon, so that any SMTP client process can reuse that session
|
||||
for another mail transaction. See the CONNECTION_CACHE_README
|
||||
document for a description of configuration and implementation.
|
||||
|
||||
This feature introduces the scache (connection cache) server, which
|
||||
is added to your master.cf file when you upgrade Postfix.
|
||||
|
||||
[Feature 20040729] Opportunistic SMTP connection caching. When a
|
||||
destination has a high volume of mail in the active queue, SMTP
|
||||
connection caching is enabled automatically. This is controlled
|
||||
with a new configuration parameter "smtp_connection_cache_on_demand"
|
||||
(default: yes).
|
||||
|
||||
[Feature 20040723] Per-destination SMTP connection caching. This
|
||||
is enabled with the smtp_connection_cache_destinations parameter.
|
||||
The parameter requires "bare" domain names or IP addresses without
|
||||
"[]" or TCP port, to avoid a syntax conflict between host:port and
|
||||
maptype:mapname entries.
|
||||
|
||||
[Feature 20040721] The scache(8) connection cache manager logs cache
|
||||
hit and miss statistics every $connection_cache_status_update_time
|
||||
seconds (default: 600s). It reports the hit and miss rates for
|
||||
lookups by domain, as well as for lookups by network address.
|
||||
|
||||
Major changes - address rewriting
|
||||
---------------------------------
|
||||
|
||||
[Feature 20050206] Support for address rewriting in outgoing SMTP
|
||||
mail (headers and envelopes). This is useful for sites that have a
|
||||
fantasy Internet domain name such as localdomain.local. Mail
|
||||
addresses that use fantasy domain names are often rejected by mail
|
||||
servers.
|
||||
|
||||
The smtp_generic_maps feature allows you to replace a local mail
|
||||
address (user@localdomain.local) by a valid Internet address
|
||||
(account@isp.example) when mail is sent across the Internet. The
|
||||
feature has no effect on mail that is sent between accounts on the
|
||||
local machine. The syntax is described in generic(5) and a detailed
|
||||
example is in the STANDARD_CONFIGURATION_README document, the section
|
||||
titled "Postfix on hosts without a real Internet hostname".
|
||||
|
||||
[Feature 20041023] By default, Postfix no longer rewrites message
|
||||
headers in mail from remote clients. This includes masquerading,
|
||||
canonical mapping, replacing "!" and "%" by "@", and appending the
|
||||
local domain to incomplete addresses. Thus, spam from poorly written
|
||||
software no longer looks like it came from a local user.
|
||||
|
||||
By default, Postfix rewrites message header addresses only when the
|
||||
client IP address matches the local machine's interface addresses,
|
||||
or when mail is submitted with the Postfix sendmail(1) command.
|
||||
|
||||
Postfix rewrites message headers in mail from other clients only
|
||||
when the remote_header_rewrite_domain parameter specifies a domain
|
||||
name (such as "domain.invalid"); this domain is appended to incomplete
|
||||
addresses. Rewriting also includes masquerading, canonical mapping,
|
||||
and replacing "!" and "%" by "@".
|
||||
|
||||
To get the behavior before Postfix 2.2 (always append Postfix's own
|
||||
domain to incomplete addresses in message headers, always subject
|
||||
message headers to canonical mapping, address masquerading, and
|
||||
always replace "!" and "%" by "@") specify:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_header_rewrite_clients = static:all
|
||||
|
||||
If you must rewrite headers in mail from specific clients then you
|
||||
can specify, for example,
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
local_header_rewrite_clients = permit_mynetworks,
|
||||
permit_sasl_authenticated, permit_tls_clientcerts,
|
||||
check_address_map hash:/etc/postfix/pop-before-smtp
|
||||
|
||||
Postfix always appends local domain information to envelope addresses
|
||||
(as opposed to header addresses), because an unqualified envelope
|
||||
address is effectively local for the purpose of delivery, and for
|
||||
the purpose of replying to it.
|
||||
|
||||
Full details are given in ADDRESS_REWRITING_README, and in the
|
||||
postconf(5) manual. For best results, point your browser at the
|
||||
ADDRESS_REWRITING_README.html file and navigate to the section
|
||||
titled " To rewrite message headers or not, or to label as invalid".
|
||||
|
||||
[Incompat 20050212] When header address rewriting is enabled, Postfix
|
||||
now updates a message header only when at least one address in that
|
||||
header is modified. Older Postfix versions first parse and then
|
||||
un-parse a header so that there may be subtle changes in formatting,
|
||||
such as the amount of whitespace between tokens.
|
||||
|
||||
[Incompat 20050227] Postfix no longer changes message header labels.
|
||||
Thus, FROM: or CC: are no longer replaced by From: or Cc:.
|
||||
|
||||
[Feature 20040827] Finer control over canonical mapping with
|
||||
canonical_classes, sender_canonical_classes and
|
||||
recipient_canonical_classes. These specify one or more of
|
||||
envelope_sender, header_sender, envelope_recipient or header_recipient.
|
||||
The default settings are backwards compatible.
|
||||
|
||||
Major changes - SMTP compatibility controls
|
||||
-------------------------------------------
|
||||
|
||||
[Feature 20041218] Fine control for SMTP inter-operability problems,
|
||||
by discarding keywords that are sent or received with the EHLO
|
||||
handshake. Typically one would discard "pipelining", "starttls",
|
||||
or "auth" to work around systems with a broken implementation.
|
||||
Specify a list of EHLO keywords with the smtp(d)_discard_ehlo_keywords
|
||||
parameters, or specify one or more lookup tables, indexed by remote
|
||||
network address, with the smtp(d)_discard_ehlo_keyword_address_maps
|
||||
parameters.
|
||||
|
||||
Note: this feature only discards words from the EHLO conversation;
|
||||
it does not turn off the actual features in the SMTP server.
|
||||
|
||||
Major changes - database support
|
||||
--------------------------------
|
||||
|
||||
[Feature 20050209] Extended LDAP, MySQL and PgSQL query interface
|
||||
with free form SQL queries, the domain filter optimization that was
|
||||
already available with LDAP and more. This code was worked on by
|
||||
many people but Victor Duchovni took the lead. See the respective
|
||||
{LDAP,MYSQL,PGSQL}_README and {ldap,mysql,pgsql}_table documents.
|
||||
|
||||
[Feature 20041210] You can now dump an entire database with the new
|
||||
postmap/postalias "-s" option. This works only for database types
|
||||
with Postfix sequence operator support: hash, btree, dbm, and sdbm.
|
||||
|
||||
[Feature 20041208] Support for CDB databases by Michael Tokarev.
|
||||
This supports both Michael's tinycdb and Daniel Bernstein's cdb
|
||||
implementations, but neither of the two implementations is bundled
|
||||
with Postfix.
|
||||
|
||||
[Feature 20041023] The NIS+ client by Geoff Gibbs is now part of
|
||||
the Postfix source tree. Details are given in the nisplus_table(5)
|
||||
manual page.
|
||||
|
||||
[Feature 20040827] Easier use of the proxymap(8) service with the
|
||||
virtual(8) delivery agent. The virtual(8) delivery agent will
|
||||
silently open maps directly when those maps can't be proxied for
|
||||
security reasons. This means you can now specify "virtual_mailbox_maps
|
||||
= proxy:mysql:whatever" without triggering a fatal error in the
|
||||
virtual(8) delivery agent.
|
||||
|
||||
Major changes - remote SMTP client resource control
|
||||
---------------------------------------------------
|
||||
|
||||
[Incompat 20041009] The smtpd_client_connection_limit_exceptions
|
||||
parameter is renamed to smtpd_client_event_limit_exceptions. Besides
|
||||
connections it now also applies to per-client message rate and
|
||||
recipient rate limits.
|
||||
|
||||
[Feature 20041009] Per SMTP client message rate and recipient rate
|
||||
limits. These limit the number of MAIL FROM or RCPT TO requests
|
||||
regardless of whether or not Postfix would have accepted them
|
||||
otherwise. The user interface (smtpd_client_message_rate_limit and
|
||||
smtpd_client_recipient_rate_limit) is similar to that of the existing
|
||||
per SMTP client connection rate limit, and the same warnings apply:
|
||||
these features are to be used to stop abuse, and must not be used
|
||||
to regulate legitimate mail. More details can be found in the
|
||||
postconf(5) manual.
|
||||
|
||||
Major changes - remote SMTP client access control
|
||||
-------------------------------------------------
|
||||
|
||||
[Feature 20050209] The Postfix SMTP server policy delegation protocol
|
||||
now supplies TLS client certificate information after successful
|
||||
verification. The new policy delegation protocol attribute names
|
||||
are ccert_subject, ccert_issuer and ccert_fingerprint.
|
||||
|
||||
[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
|
||||
to enforce access control based on hexadecimal client certificate
|
||||
fingerprints.
|
||||
|
||||
[Feature 20050203] New "permit_inet_interfaces" access restriction
|
||||
to allow access from local IP addresses only. This is used for the
|
||||
default, purist, setting of local_header_rewrite_clients (rewrite
|
||||
only headers in mail from this machine).
|
||||
|
||||
[Feature 20050203] New "sleep time-in-seconds" pseudo access
|
||||
restriction to block zombie clients with reject_unauthorized_pipelining
|
||||
before the Postfix SMTP server sends the SMTP greeting. See postconf(5)
|
||||
for example. This feature is not available the stable Postfix 2.2
|
||||
release, but it is documented here so that it will not get lost.
|
||||
|
||||
[Feature 20041118] New "smtpd_end_of_data_restrictions" feature
|
||||
that is invoked after the client terminates the SMTP DATA command.
|
||||
The syntax is the same as with "smtpd_data_restrictions". In the
|
||||
SMTPD policy delegation request, the message size is the actual
|
||||
byte count of the message content, instead of the message size
|
||||
announced by the client in the MAIL FROM command.
|
||||
|
||||
Major changes - SASL authentication
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20040827] Better SMTP client control over the use of SASL
|
||||
mechanisms. New smtp_sasl_mechanism_filter mechanism to shorten the
|
||||
list of SASL mechanisms from a remote server to just those that the
|
||||
local SASL library can actually use.
|
||||
|
||||
Major changes - header/body patterns
|
||||
------------------------------------
|
||||
|
||||
[Feature 20050205] REPLACE action in header_checks and body_checks,
|
||||
to replace a message header or body line. See header_checks(5) for
|
||||
details.
|
||||
|
||||
Major changes - local delivery
|
||||
------------------------------
|
||||
|
||||
[Feature 20040621] Control over the working directory when executing
|
||||
an external command. With the pipe(8) mailer, specify directory=pathname,
|
||||
and with local(8) specify "command_execution_directory = expression"
|
||||
where "expression" is subject to $home etc. macro expansion. The
|
||||
result of macro expansion is restricted by the set of characters
|
||||
specified with execution_directory_expansion_filter.
|
||||
|
||||
Major changes - mail delivery attributes
|
||||
----------------------------------------
|
||||
|
||||
[Feature 20041218] More client attributes for delivery to command
|
||||
with the local(8) and pipe(8) delivery agents: client_hostname,
|
||||
client_address, client_protocol, client_helo, sasl_method, sasl_sender,
|
||||
and sasl_username. With local(8), attribute names must be specified
|
||||
in upper case.
|
||||
|
||||
Major changes - package creation
|
||||
--------------------------------
|
||||
|
||||
[Feature 20050203] To create a ready-to-install package for
|
||||
distribution to other systems you can now use "make package" or
|
||||
"make non-interactive-package", instead of invoking the internal
|
||||
postfix-install script by hand. See the PACKAGE_README file for
|
||||
details.
|
||||
|
||||
Major changes - performance
|
||||
---------------------------
|
||||
|
||||
[Incompat 20050117] Only the deferred and defer queue directories
|
||||
are now hashed by default, instead of eight queue directories. This
|
||||
may speed up Postfix boot time on low-traffic systems without
|
||||
compromising performance under high load too much. Hashing must be
|
||||
turned on for the defer and deferred queue directories, because
|
||||
those directories contain lots of files when undeliverable mail is
|
||||
backing up.
|
||||
|
||||
[Incompat 20040720] The default SMTP/LMTP timeouts for sending RSET
|
||||
are reduced to 20s.
|
||||
|
||||
Major changes - miscellaneous
|
||||
-----------------------------
|
||||
|
||||
[Feature 20050203] Safety: Postfix no longer tries to send mail to
|
||||
the fallback_relay when the local machine is MX host for the mail
|
||||
destination. See the postconf(5) description of the fallback_relay
|
||||
feature for details.
|
||||
|
||||
[Incompat 20041023] Support for the non-standard Errors-To: return
|
||||
addresses is now removed from Postfix. It was already disabled by
|
||||
default with Postfix version 2.1. Since Errors-To: is non-standard,
|
||||
there was no guarantee that it would have the desired effect with
|
||||
other MTAs.
|
||||
|
||||
[Feature 20040919] A new discard(8) mail delivery agent that makes
|
||||
throwing away mail easier and more efficient. It's the Postfix
|
||||
equivalent of /dev/null for mail deliveries. On the mail receiving
|
||||
side, Postfix already has a /dev/null equivalent in the form of the
|
||||
DISCARD action in access maps and header_body_checks.
|
||||
|
||||
[Feature 20040919] Access control for local mail submission, for
|
||||
listing the queue, and for flushing the queue. These features are
|
||||
controlled with authorized_submit_users, authorized_mailq_users,
|
||||
and with authorized_flush_users, respectively. The last two controls
|
||||
are always permitted for the super-user and for the mail system
|
||||
owner. More information is in the postconf(5) manual.
|
||||
|
||||
[Incompat 20040829] When no recipients are specified on the command
|
||||
line or via the -t option, the Postfix sendmail command terminates
|
||||
with status EX_USAGE and produces an error message instead of
|
||||
accepting the mail first and bouncing it later. This gives more
|
||||
direct feedback in case of a common client configuration error.
|
||||
|
||||
761
RELEASE_NOTES-2.3
Normal file
761
RELEASE_NOTES-2.3
Normal file
|
|
@ -0,0 +1,761 @@
|
|||
The stable Postfix release is called postfix-2.3.x where 2=major
|
||||
release number, 3=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.4-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.
|
||||
|
||||
Critical notes
|
||||
--------------
|
||||
|
||||
See RELEASE_NOTES_2.2 if you upgrade from Postfix 2.1 or earlier.
|
||||
|
||||
Some Postfix internal protocols have changed. You need to "postfix
|
||||
reload" or restart Postfix, otherwise many servers will log warning
|
||||
messages like "unexpected attribute xxx" or "problem talking to
|
||||
service yyy", and mail will not be delivered.
|
||||
|
||||
The Sendmail-compatible Milter support introduces three new queue
|
||||
file record types. As long as you leave this feature turned off,
|
||||
you can still go back to Postfix version 2.2 without losing mail
|
||||
that was received by Postfix 2.3.
|
||||
|
||||
Major changes - DNS lookups
|
||||
---------------------------
|
||||
|
||||
[Incompat 20050726] Name server replies that contain a malformed
|
||||
hostname are now flagged as permanent errors instead of transient
|
||||
errors. This change works around a questionable proposal to use
|
||||
syntactically invalid hostnames in MX records.
|
||||
|
||||
Major changes - DSN
|
||||
-------------------
|
||||
|
||||
[Feature 20050615] DSN support as described in RFC 3461 .. RFC 3464.
|
||||
This gives senders control over successful and failed delivery
|
||||
notifications. DSN involves extra parameters to the SMTP "MAIL
|
||||
FROM" and "RCPT TO" commands, as well as extra Postfix sendmail
|
||||
command line options for mail submission.
|
||||
|
||||
See DSN_README for details. Some implementation notes can be found
|
||||
in implementation-notes/DSN.
|
||||
|
||||
[Incompat 20050615] The new DSN support conflicts with VERP support.
|
||||
For Sendmail compatibility, Postfix now uses the sendmail -V command
|
||||
line option for DSN. To request VERP style delivery, you must now
|
||||
specify -XV instead of -V. The Postfix sendmail command will
|
||||
recognize if you try to use -V for VERP-style delivery. It will
|
||||
usually do the right thing, and remind you of the new syntax.
|
||||
|
||||
[Incompat 20050828] Postfix no longer sends DSN SUCCESS notification
|
||||
after virtual alias expansions when the cleanup server rejects the
|
||||
content or size of mail that was submitted with the Postfix sendmail
|
||||
command, mail that was forwarded with the local(8) delivery agent,
|
||||
or mail that was re-queued with "postsuper -r". Since all the
|
||||
recipients are reported as failed, the SUCCESS notification seems
|
||||
redundant.
|
||||
|
||||
Major changes - LMTP client
|
||||
---------------------------
|
||||
|
||||
See the "SASL authentication" and "TLS" sections for changes related
|
||||
to SASL authentication and TLS support, respectively.
|
||||
|
||||
[Feature 20051208] The SMTP client now implements the LMTP protocol.
|
||||
Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
|
||||
This means there are lot of new LMTP features, including support
|
||||
for TLS and for the shared connection cache. See the "SMTP client"
|
||||
section for details.
|
||||
|
||||
[Incompat 20051208] The LMTP client now reports the server as
|
||||
"myhostname[/path/name]". With the real server hostname in delivery
|
||||
status reports, the information will be more useful.
|
||||
|
||||
Major changes - Milter support
|
||||
------------------------------
|
||||
|
||||
[Feature 20060515] Milter (mail filter) application support,
|
||||
compatible with Sendmail version 8.13.6 and earlier. This allows
|
||||
you to run a large number of plug-ins to reject unwanted mail, and
|
||||
to sign mail with for example domain keys. All Milter functions are
|
||||
implemented except replacing the message body, which will be added
|
||||
later. Milters are before-queue filters, so they don't change the
|
||||
queue ID.
|
||||
|
||||
See the MILTER_README document for a discussion of how to use Milter
|
||||
support with Postfix, and limitations of the current implementation.
|
||||
|
||||
The Sendmail-compatible Milter support introduces three new queue
|
||||
file record types. As long as you leave this feature turned off,
|
||||
you can still go back to Postfix version 2.2 without losing mail
|
||||
that was received by Postfix 2.3.
|
||||
|
||||
[Incompat 20060515] Milter support introduces new logfile event
|
||||
types: milter-reject, milter-discard and milter-hold, that identify
|
||||
actions from Milter applications. This may affect logfile processing
|
||||
software.
|
||||
|
||||
Major changes - SASL authentication
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20051220] Plug-in support for SASL authentication in the
|
||||
SMTP server and in the SMTP/LMTP client. With this, Postfix can
|
||||
support multiple SASL implementations without source code patches.
|
||||
Some distributors may even make SASL support a run-time linking
|
||||
option, just like they already do with Postfix lookup tables.
|
||||
|
||||
Hints and tips for plug-in developers are in the xsasl/README file.
|
||||
|
||||
For backwards compatibility the default plug-in type is Cyrus SASL,
|
||||
so everything should behave like it did before. Some error messages
|
||||
are slightly different, but these are generally improvements.
|
||||
|
||||
The "postconf -a" command shows what plug-in implementations are
|
||||
available for the SMTP server, and "postconf -A" does the same for
|
||||
the SMTP/LMTP client. Plug-in implementations are selected with
|
||||
the smtpd_sasl_type, smtp_sasl_type and lmtp_sasl_type configuration
|
||||
parameters.
|
||||
|
||||
Other new configuration parameters are smtpd_sasl_path, smtp_sasl_path
|
||||
and lmtp_sasl_path. These are better left alone; they are introduced
|
||||
for the convenience of other SASL implementations.
|
||||
|
||||
[Feature 20051222] Dovecot SASL support (SMTP server only). Details
|
||||
can be found in the SASL_README document.
|
||||
|
||||
[Incompat 20051220] The Postfix-with-Cyrus-SASL build procedure has
|
||||
changed. You now need to specify -DUSE_CYRUS_SASL in addition to
|
||||
-DUSE_SASL_AUTH or else you end up without any Cyrus SASL support.
|
||||
The error messages are:
|
||||
|
||||
unsupported SASL server implementation: cyrus
|
||||
unsupported SASL client implementation: cyrus
|
||||
|
||||
[Feature 20051125] This snapshot adds support for sender-dependent
|
||||
ISP accounts.
|
||||
|
||||
- Sender-dependent smarthost lookup tables. The maps are searched
|
||||
with the sender address and with the sender @domain. The result
|
||||
overrides the global relayhost setting, but otherwise has identical
|
||||
behavior. See the postconf(5) manual page for more details.
|
||||
|
||||
Example:
|
||||
/etc/postfix/main.cf:
|
||||
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
|
||||
|
||||
- Sender-dependent SASL authentication support. This disables SMTP
|
||||
connection caching to ensure that mail from different senders
|
||||
will use the correct authentication credentials. The SMTP SASL
|
||||
password file is first searched by sender address, and then by
|
||||
the remote domain and hostname as usual.
|
||||
|
||||
Example:
|
||||
/etc/postfix/main.cf:
|
||||
smtp_sasl_auth_enable = yes
|
||||
smtp_sender_dependent_authentication = yes
|
||||
smtp_sasl_password_maps = hash:/etc/postfix/sasl_pass
|
||||
|
||||
[Incompat 20060707] The SMTP/LMTP client now defers delivery when
|
||||
a SASL password exists but the server does not announce support for
|
||||
SASL authentication. This can happen with servers that announce
|
||||
SASL support only when TLS is turned on. When an opportunistic TLS
|
||||
handshake fails, Postfix >= 2.3 retries delivery in plaintext, and
|
||||
the remote server rejects mail from the unauthenticated client.
|
||||
Specify "smtp_sasl_auth_enforce = no" to deliver mail anyway.
|
||||
|
||||
Major changes - SMTP client
|
||||
---------------------------
|
||||
|
||||
See the "SASL authentication" and "TLS" sections for changes related
|
||||
to SASL authentication and TLS support, respectively.
|
||||
|
||||
[Feature 20051208] The SMTP client now implements the LMTP protocol.
|
||||
Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
|
||||
This means there are lot of new LMTP features, including support
|
||||
for TLS and for the shared connection cache.
|
||||
|
||||
[Incompat 20060112] The Postfix SMTP/LMTP client by default no
|
||||
longer allows DNS CNAME records to override the server hostname
|
||||
that is used for logging, SASL password lookup, TLS policy selection
|
||||
and TLS server certificate verification. Specify
|
||||
"smtp_cname_overrides_servername = yes" to get the old behavior.
|
||||
|
||||
[Incompat 20060103] The Postfix SMTP/LMTP client no longer defers
|
||||
mail delivery when it receives a malformed SMTP server reply in a
|
||||
session with command pipelining. When helpful warnings are enabled,
|
||||
it will suggest that command pipelining be disabled for the affected
|
||||
destination.
|
||||
|
||||
[Incompat 20051208] The fallback_relay feature is renamed to
|
||||
smtp_fallback_relay, to make clear that the combined SMTP/LMTP
|
||||
client uses this setting only for SMTP deliveries. The old name
|
||||
still works.
|
||||
|
||||
[Incompat 20051106] The relay=... logging has changed and now
|
||||
includes the remote SMTP server port number as hostname[hostaddr]:port.
|
||||
|
||||
[Incompat 20051026] The smtp_connection_cache_reuse_limit parameter
|
||||
(which limits the number of deliveries per SMTP connection) is
|
||||
replaced by the new smtp_connection_reuse_time_limit parameter (the
|
||||
time after which a connection is no longer stored into the connection
|
||||
cache).
|
||||
|
||||
[Feature 20051026] This snapshot addresses a performance stability
|
||||
problem with remote SMTP servers. The problem is not specific to
|
||||
Postfix: it can happen when any MTA sends large amounts of SMTP
|
||||
email to a site that has multiple MX hosts. The insight that led
|
||||
to the solution, as well as an initial implementation, are due to
|
||||
Victor Duchovni.
|
||||
|
||||
The problem starts when one of a set of MX hosts becomes slower
|
||||
than the rest. Even though SMTP clients connect to fast and slow
|
||||
MX hosts with equal probability, the slow MX host ends up with more
|
||||
simultaneous inbound connections than the faster MX hosts, because
|
||||
the slow MX host needs more time to serve each client request.
|
||||
|
||||
The slow MX host becomes a connection attractor. If one MX host
|
||||
becomes N times slower than the rest, it dominates mail delivery
|
||||
latency unless there are more than N fast MX hosts to counter the
|
||||
effect. And if the number of MX hosts is smaller than N, the mail
|
||||
delivery latency becomes effectively that of the slowest MX host
|
||||
divided by the total number of MX hosts.
|
||||
|
||||
The solution uses connection caching in a way that differs from
|
||||
Postfix 2.2. By limiting the amount of time during which a connection
|
||||
can be used repeatedly (instead of limiting the number of deliveries
|
||||
over that connection), Postfix not only restores fairness in the
|
||||
distribution of simultaneous connections across a set of MX hosts,
|
||||
it also favors deliveries over connections that perform well, which
|
||||
is exactly what we want.
|
||||
|
||||
The smtp_connection_reuse_time_limit feature implements the connection
|
||||
reuse time limit as discussed above. It limits the amount of time
|
||||
after which an SMTP connection is no longer stored into the connection
|
||||
cache. The default limit, 300s, can result in a huge number of
|
||||
deliveries over a single connection.
|
||||
|
||||
This solution will be complete when Postfix logging is updated to
|
||||
include information about the number of times that a connection was
|
||||
used. This information is needed to diagnose inter-operability
|
||||
problems with servers that exhibit bugs when they receive multiple
|
||||
messages over the same connection.
|
||||
|
||||
[Incompat 20050627] The Postfix SMTP client no longer applies the
|
||||
smtp_mx_session_limit to non-permanent errors during the TCP, SMTP,
|
||||
HELO or TLS handshake. Previous versions did that only with TCP
|
||||
and SMTP handshake errors.
|
||||
|
||||
[Incompat 20050622] The Postfix SMTP client by default limits the
|
||||
number of MX server addresses to smtp_mx_address_limit=5. Previously
|
||||
this limit was disabled by default. The new limit prevents Postfix
|
||||
from spending lots of time trying to connect to lots of bogus MX
|
||||
servers.
|
||||
|
||||
Major changes - SMTP server
|
||||
---------------------------
|
||||
|
||||
See the "SASL authentication" and "TLS" sections for changes related
|
||||
to SASL authentication and TLS support, respectively.
|
||||
|
||||
[Feature 20051222] To accept the non-compliant user@ipaddress form,
|
||||
specify "resolve_numeric_domain = yes". Postfix will deliver the
|
||||
mail to user@[ipaddress] instead.
|
||||
|
||||
[Incompat 20051202] The Postfix SMTP server now refuses to receive
|
||||
mail from the network if it isn't running with postfix mail_owner
|
||||
privileges. This prevents surprises when, for example, "sendmail
|
||||
-bs" is configured to run as root from xinetd.
|
||||
|
||||
[Incompat 20051121] Although the permit_mx_backup feature still
|
||||
accepts mail for authorized destinations (see permit_mx_backup for
|
||||
definition), with all other destinations it now requires that the
|
||||
local MTA is listed as non-primary MX server. This prevents mail
|
||||
loop problems when someone points their primary MX record at a
|
||||
Postfix system.
|
||||
|
||||
[Feature 20051011] Optional suppression of remote SMTP client
|
||||
hostname lookup and hostname verification. Specify "smtpd_peername_lookup
|
||||
= no" to eliminate DNS lookup latencies, but do so only under extreme
|
||||
conditions, as it makes Postfix logging less informative.
|
||||
|
||||
[Feature 20050724] SMTPD Access control based on the existence of
|
||||
an address->name mapping, with reject_unknown_reverse_client_hostname.
|
||||
There is no corresponding access table lookup feature, because the
|
||||
name is not validated in any way (except that it has proper syntax).
|
||||
|
||||
Several confusing SMTPD access restrictions were renamed:
|
||||
|
||||
reject_unknown_client -> reject_unknown_client_hostname,
|
||||
reject_unknown_hostname -> reject_unknown_helo_hostname,
|
||||
reject_invalid_hostname -> reject_invalid_helo_hostname,
|
||||
reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname.
|
||||
|
||||
The old names are still recognized and documented.
|
||||
|
||||
Major changes - TLS
|
||||
-------------------
|
||||
|
||||
Major revisions were made to Postfix TLS support; see TLS_README
|
||||
for the details. For backwards compatibility, the old TLS policy
|
||||
user interface will be kept intact for a few releases so that sites
|
||||
can upgrade Postfix without being forced to use a different TLS
|
||||
policy mechanism.
|
||||
|
||||
[Feature 20060614] New concept: TLS security levels ("none", "may",
|
||||
"encrypt", "verify" or "secure") in the Postfix SMTP client. You
|
||||
can specify the TLS security level via the smtp_tls_security_level
|
||||
parameter. This is more convenient than controlling TLS with the
|
||||
multiple smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername,
|
||||
parameters.
|
||||
|
||||
[Feature 20060709] TLS security levels ("none", "may", "encrypt")
|
||||
in the Postfix SMTP server. You specify the security level with the
|
||||
smtpd_tls_security_level parameter. This overrides the multiple
|
||||
smtpd_use_tls and smtpd_enforce_tls parameters. When one of the
|
||||
unimplemented "verify" or "secure" levels is specified, the Postfix
|
||||
SMTP server logs a warning and uses "encrypt" instead.
|
||||
|
||||
[Feature 20060123] A new per-site TLS policy mechanism for the
|
||||
Postfix SMTP client that supports the new TLS security levels,
|
||||
and that eliminates DNS spoofing attacks more effectively.
|
||||
|
||||
[Feature 20060626] Both the Postfix SMTP client and server can be
|
||||
configured without a client or server certificate. An SMTP server
|
||||
without certificate can use only anonymous ciphers, and will not
|
||||
inter-operate with most clients.
|
||||
|
||||
The Postfix SMTP server supports anonymous ciphers when 1) no client
|
||||
certificates are requested or required, and 2) the administrator
|
||||
has not excluded the "aNULL" OpenSSL cipher type with the
|
||||
smtpd_tls_exclude_ciphers parameter.
|
||||
|
||||
The Postfix SMTP client supports anonymous ciphers when 1) no server
|
||||
certificate is required and 2) the administrator has not excluded
|
||||
the "aNULL" OpenSSL cipher type with the smtp_tls_exclude_ciphers
|
||||
parameter.
|
||||
|
||||
[Incompat 20060707] The SMTPD policy client now encodes the
|
||||
ccert_subject and ccert_issuer attributes as xtext. Some characters
|
||||
are represented by +XX, where XX is the two-digit hexadecimal
|
||||
representation of the character value.
|
||||
|
||||
[Feature 20060614] The smtpd_tls_protocols parameter restricts the
|
||||
list of TLS protocols supported by the SMTP server. This is
|
||||
recommended for use with MSA configurations only. It should not
|
||||
be used with MX hosts that receive mail from the Internet, as it
|
||||
reduces inter-operability.
|
||||
|
||||
[Incompat 20060614] The smtp_tls_cipherlist parameter only applies
|
||||
when TLS is mandatory. It is ignored with opportunistic TLS sessions.
|
||||
|
||||
[Incompat 20060614] At (lmtp|smtp|smtpd)_tls_loglevel >= 2, Postfix
|
||||
now also logs TLS session cache activity. Use level 2 and higher
|
||||
for debugging only; use levels 0 or 1 as production settings.
|
||||
|
||||
[Incompat 20060207] The Postfix SMTP server no longer complains
|
||||
when TLS support is not compiled in while permit_tls_clientcerts,
|
||||
permit_tls_all_clientcerts, or check_ccert_access are specified in
|
||||
main.cf. These features now are effectively ignored. However, the
|
||||
reject_plaintext_session feature is not ignored and will reject
|
||||
plain-text mail.
|
||||
|
||||
[Feature 20060123] Some obscure behavior was eliminated from the
|
||||
smtp_tls_per_site feature, without changes to the user interface.
|
||||
Some Postfix internals had to be re-structured for the new TLS
|
||||
policy mechanism; for this, smtp_tls_per_site had to be re-implemented.
|
||||
The obscure behavior was found during compatibility testing.
|
||||
|
||||
[Feature 20051011] Optional protection against SMTP clients that
|
||||
hammer the server with too many new (i.e. uncached) SMTP-over-TLS
|
||||
sessions. Cached sessions are much less expensive in terms of CPU
|
||||
cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
|
||||
to specify a limit that is at least the inbound client concurrency
|
||||
limit, or else you may deny legitimate service requests.
|
||||
|
||||
Major changes - VERP
|
||||
--------------------
|
||||
|
||||
[Incompat 20050615] The new DSN support conflicts with VERP support.
|
||||
For Sendmail compatibility, Postfix now uses the sendmail -V command
|
||||
line option for DSN. In order to request VERP style delivery, you
|
||||
must now specify -XV instead of -V. The Postfix sendmail command
|
||||
will recognize if you try to use -V for VERP-style delivery. It
|
||||
will do the right thing and will remind you of the new syntax.
|
||||
|
||||
Major changes - XCLIENT and XFORWARD
|
||||
------------------------------------
|
||||
|
||||
[Incompat 20060611] The SMTP server XCLIENT implementation has
|
||||
changed. The SMTP server now resets state to the initial server
|
||||
greeting stage, immediately before the EHLO/HELO greeting. This
|
||||
was needed to correctly simulate the effect of connection-level
|
||||
access restrictions. Without this change, XCLIENT would not work
|
||||
at all with Milter applications.
|
||||
|
||||
[Incompat 20060611] The SMTP server XCLIENT and XFORWARD commands
|
||||
now expect that attributes are xtext encoded (RFC 1891). For backwards
|
||||
compatibility they will also accept unencoded attribute values. The
|
||||
XFORWARD client code in the SMTP client and in the SMTPD_PROXY
|
||||
client now always encode attribute values. This change will have a
|
||||
visible effect only for malformed hostname and helo parameter values.
|
||||
|
||||
For more details, see the XCLIENT_README and XFORWARD_README
|
||||
documents.
|
||||
|
||||
Major changes - address manipulation
|
||||
------------------------------------
|
||||
|
||||
[Incompat 20060123] Postfix now preserves uppercase information
|
||||
while mapping addresses with canonical, virtual, relocated or generic
|
||||
maps; this happens even with $number substitutions in regular
|
||||
expression maps. However, the local(8) and virtual(8) delivery
|
||||
agents still fold addresses to lower case.
|
||||
|
||||
As a side effect, Postfix now also does a better job at being case
|
||||
insensitive where it should be, for example while searching per-host
|
||||
TLS policies or SASL passwords.
|
||||
|
||||
By default, Postfix now folds the search string to lowercase only
|
||||
with tables that have fixed-case lookup fields such as btree:,
|
||||
hash:, dbm:, ldap:, or *sql:. The search string is no longer case
|
||||
folded with tables whose lookup fields can match both upper or lower
|
||||
case, such as regexp:, pcre:, or cidr:.
|
||||
|
||||
For safety reasons, Postfix no longer allows $number substitution
|
||||
in regexp: or pcre: transport tables or per-sender relayhost tables.
|
||||
|
||||
Major changes - bounce message templates
|
||||
----------------------------------------
|
||||
|
||||
[Feature 20051113] Configurable bounce messages, based on a format
|
||||
that was developed by Nicolas Riendeau. The file with templates is
|
||||
specified with the bounce_template_file parameter. Details are in
|
||||
the bounce(5) manual page, and examples of the built-in templates
|
||||
can be found in $config_directory/bounce.cf.default. The template
|
||||
for the default bounce message looks like this:
|
||||
|
||||
failure_template = <<EOF
|
||||
Charset: us-ascii
|
||||
From: MAILER-DAEMON (Mail Delivery System)
|
||||
Subject: Undelivered Mail Returned to Sender
|
||||
Postmaster-Subject: Postmaster Copy: Undelivered Mail
|
||||
|
||||
This is the $mail_name program at host $myhostname.
|
||||
|
||||
I'm sorry to have to inform you that your message could not
|
||||
be delivered to one or more recipients. It's attached below.
|
||||
|
||||
For further assistance, please send mail to <postmaster>
|
||||
|
||||
If you do so, please include this problem report. You can
|
||||
delete your own text from the attached returned message.
|
||||
|
||||
The $mail_name program
|
||||
EOF
|
||||
|
||||
Major changes - built-in filters
|
||||
--------------------------------
|
||||
|
||||
[Feature 20050828] Configurable filters to reject or remove unwanted
|
||||
characters in email content. The message_reject_characters and
|
||||
message_strip_characters parameters understand the usual C-like
|
||||
escape sequences: \a \b \f \n \r \t \v \ddd (up to three octal
|
||||
digits) and \\.
|
||||
|
||||
[Incompat 20050828] When a header/body_checks rule or when
|
||||
message_reject_characters rejects mail that was submitted with the
|
||||
Postfix sendmail command (or re-queued with "postsuper -r"), the
|
||||
returned message is now limited to just the message headers, to
|
||||
avoid the risk of exposure to harmful content in the message body
|
||||
or attachments.
|
||||
|
||||
Major changes - database support
|
||||
--------------------------------
|
||||
|
||||
[Incompat 20060611] The PostgreSQL client was updated after the
|
||||
PostgreSQL developers made major database API changes in response
|
||||
to SQL injection problems. This breaks support for PGSQL versions
|
||||
prior to 8.1.4, 8.0.8, 7.4.13, and 7.3.15. Support for these requires
|
||||
major code changes which are not possible in the time that is left
|
||||
for completing the Postfix 2.3 stable release.
|
||||
|
||||
Major changes - enhanced status codes
|
||||
-------------------------------------
|
||||
|
||||
[Feature 20050328] This release introduces support for RFC 3463
|
||||
enhanced status codes. For example, status code 5.1.1 means
|
||||
"recipient unknown". Postfix recognizes enhanced status codes in
|
||||
remote server replies, generates enhanced status codes while handling
|
||||
email, and reports enhanced status codes in non-delivery notifications.
|
||||
This improves the user experience with mail clients that translate
|
||||
enhanced status codes into text in the user's own language.
|
||||
|
||||
You can, but don't have to, specify RFC 3463 enhanced status codes
|
||||
in the output from commands that receive mail from a pipe. If a
|
||||
command terminates with non-zero exit status, and an enhanced status
|
||||
code is present at the beginning of the command output, then that
|
||||
status code takes precedence over the non-zero exit status.
|
||||
|
||||
You can, but don't have to, specify RFC 3463 enhanced status codes
|
||||
in Postfix access maps, header/body_checks REJECT actions, or in
|
||||
RBL replies. For example:
|
||||
|
||||
REJECT 5.7.1 You can't go here from there
|
||||
|
||||
The status 5.7.1 means "no authorization, message refused", and is
|
||||
the default for access maps, header/body_checks REJECT actions, and
|
||||
for RBL replies.
|
||||
|
||||
[Feature 20050328] If you specify your own enhanced status code,
|
||||
the Postfix SMTP server will automatically change a leading '5'
|
||||
digit (hard error) into '4' where appropriate. This is needed, for
|
||||
example, with soft_bounce=yes.
|
||||
|
||||
[Feature 20050510] This release improves usability of enhanced
|
||||
status codes in Postfix access tables, RBL reply templates and in
|
||||
transport maps that use the error(8) delivery agent.
|
||||
|
||||
- When the SMTP server rejects a sender address, it transforms a
|
||||
recipient DSN status (e.g., 4.1.1-4.1.6) into the corresponding
|
||||
sender DSN status, and vice versa.
|
||||
|
||||
- When the SMTP server rejects non-address information (such as the
|
||||
HELO command parameter or the client hostname/address), it
|
||||
transforms a sender or recipient DSN status into a generic
|
||||
non-address DSN status (e.g., 4.0.0).
|
||||
|
||||
These transformations are needed when the same access table or RBL
|
||||
reply template are used for client, helo, sender, or recipient
|
||||
restrictions; or when the same error(8) mailer information is used
|
||||
for both senders and recipients.
|
||||
|
||||
Major changes - local alias expansion
|
||||
-------------------------------------
|
||||
|
||||
[Incompat 20051011] The Postfix local(8) delivery agent no longer
|
||||
updates its idea of the Delivered-To: address while it expands
|
||||
aliases or .forward files. With deeply nested aliases or .forward
|
||||
files, this can greatly reduce the number of queue files and cleanup
|
||||
process instances. To get the earlier behavior, specify
|
||||
"frozen_delivered_to = no".
|
||||
|
||||
The frozen_delivered_to feature can help to alleviate a long-standing
|
||||
problem with multiple deliveries to recipients that are listed
|
||||
multiple times in a hierarchy of nested aliases. For this to work,
|
||||
only the top-level alias should have an owner- alias, and none of
|
||||
the subordinate aliases.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20060515] Milter support introduces new logfile event
|
||||
types: milter-reject, milter-discard and milter-hold, that identify
|
||||
actions from Milter applications. This may affect logfile processing
|
||||
software.
|
||||
|
||||
[Incompat 20051106] The relay=... logging has changed and now
|
||||
includes the remote SMTP server port number as hostname[hostaddr]:port.
|
||||
|
||||
[Incompat 20060112] The Postfix SMTP/LMTP client by default no
|
||||
longer allows DNS CNAME records to override the server hostname
|
||||
that is used for logging, SASL password lookup, TLS policy selection
|
||||
and TLS server certificate verification. Specify
|
||||
"smtp_cname_overrides_servername = yes" to get the old behavior.
|
||||
|
||||
[Incompat 20051105] All delay logging now has sub-second resolution,
|
||||
including the over-all "delay=nnn" logging. A patch is available
|
||||
for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
|
||||
has been updated (auxiliary/qshape/qshape.pl).
|
||||
|
||||
[Feature 20051103] This release makes a beginning with a series of
|
||||
new attributes in Postfix logfile records.
|
||||
|
||||
- Better insight into the nature of performance bottle necks, with
|
||||
detailed logging of delays in various stages of message delivery.
|
||||
Postfix logs additional delay information as "delays=a/b/c/d"
|
||||
where a=time before queue manager, including message transmission;
|
||||
b=time in queue manager; c=connection setup time including DNS,
|
||||
HELO and TLS; d=message transmission time.
|
||||
|
||||
- Logging of the connection reuse count when SMTP connections are
|
||||
used for more than one message delivery. This information is
|
||||
needed because Postfix can now reuse connections hundreds of times
|
||||
or more. Logging of the connection reuse count can help to diagnose
|
||||
inter-operability problems with servers that suffer from memory
|
||||
leaks or other resource leaks.
|
||||
|
||||
At this point the Postfix logging for a recipient looks like this:
|
||||
|
||||
Nov 3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
|
||||
to=<wietse@test.example.com>, orig_to=<wietse@test>,
|
||||
relay=mail.example.com[1.2.3.4], conn_use=2, delay=0,
|
||||
delays=0/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
|
||||
|
||||
The following two logfile fields may or may not be present:
|
||||
|
||||
orig_to This is omitted when the address did not change.
|
||||
conn_use This is omitted when a connection is used once.
|
||||
|
||||
[Incompat 20050503] The format of some "warning:" messages in the
|
||||
maillog has changed so that they are easier to sort:
|
||||
|
||||
- The logging now talks about "access table", instead of using three
|
||||
different expressions "access table", "access map" and "SMTPD
|
||||
access map" for the same thing.
|
||||
|
||||
- "non-SMTP command" is now logged BEFORE the client name/address
|
||||
and the offending client input, instead of at the end.
|
||||
|
||||
[Incompat 20050328] The logging format has changed. Postfix delivery
|
||||
agents now log the RFC 3463 enhanced status code as "dsn=x.y.z"
|
||||
where y and z can be up to three digits each.
|
||||
|
||||
[Incompat 20051208] The LMTP client now reports the server as
|
||||
"myhostname[/path/name]". With the real server hostname in delivery
|
||||
status reports, the information will be more useful.
|
||||
|
||||
Major changes - performance
|
||||
---------------------------
|
||||
|
||||
[Incompat 20051105] All delay logging now has sub-second resolution,
|
||||
including the over-all "delay=nnn" logging. A patch is available
|
||||
for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
|
||||
has been updated (auxiliary/qshape/qshape.pl).
|
||||
|
||||
[Incompat 20050622] The Postfix SMTP client by default limits the
|
||||
number of MX server addresses to smtp_mx_address_limit=5. Previously
|
||||
this limit was disabled by default. The new limit prevents Postfix
|
||||
from spending lots of time trying to connect to lots of bogus MX
|
||||
servers.
|
||||
|
||||
[Feature 20051026] This snapshot addresses a performance stability
|
||||
problem with remote SMTP servers. The problem is not specific to
|
||||
Postfix: it can happen when any MTA sends large amounts of SMTP
|
||||
email to a site that has multiple MX hosts. The insight that led
|
||||
to the solution, as well as an initial implementation, are due to
|
||||
Victor Duchovni.
|
||||
|
||||
The problem starts when one of a set of MX hosts becomes slower
|
||||
than the rest. Even though SMTP clients connect to fast and slow
|
||||
MX hosts with equal probability, the slow MX host ends up with more
|
||||
simultaneous inbound connections than the faster MX hosts, because
|
||||
the slow MX host needs more time to serve each client request.
|
||||
|
||||
The slow MX host becomes a connection attractor. If one MX host
|
||||
becomes N times slower than the rest, it dominates mail delivery
|
||||
latency unless there are more than N fast MX hosts to counter the
|
||||
effect. And if the number of MX hosts is smaller than N, the mail
|
||||
delivery latency becomes effectively that of the slowest MX host
|
||||
divided by the total number of MX hosts.
|
||||
|
||||
The solution uses connection caching in a way that differs from
|
||||
Postfix 2.2. By limiting the amount of time during which a connection
|
||||
can be used repeatedly (instead of limiting the number of deliveries
|
||||
over that connection), Postfix not only restores fairness in the
|
||||
distribution of simultaneous connections across a set of MX hosts,
|
||||
it also favors deliveries over connections that perform well, which
|
||||
is exactly what we want.
|
||||
|
||||
The smtp_connection_reuse_time_limit feature implements the connection
|
||||
reuse time limit as discussed above. It limits the amount of time
|
||||
after which an SMTP connection is no longer stored into the connection
|
||||
cache. The default limit, 300s, can result in a huge number of
|
||||
deliveries over a single connection.
|
||||
|
||||
This solution will be complete when Postfix logging is updated to
|
||||
include information about the number of times that a connection was
|
||||
used. This information is needed to diagnose inter-operability
|
||||
problems with servers that exhibit bugs when they receive multiple
|
||||
messages over the same connection.
|
||||
|
||||
[Feature 20051011] Optional protection against SMTP clients that
|
||||
hammer the server with too many new (i.e. uncached) SMTP-over-TLS
|
||||
sessions. Cached sessions are much less expensive in terms of CPU
|
||||
cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
|
||||
to specify a limit that is at least the inbound client concurrency
|
||||
limit, or else you may deny legitimate service requests.
|
||||
|
||||
[Feature 20051011] Optional suppression of remote SMTP client
|
||||
hostname lookup and hostname verification. Specify "smtpd_peername_lookup
|
||||
= no" to eliminate DNS lookup latencies, but do so only under extreme
|
||||
conditions, as it makes Postfix logging less informative.
|
||||
|
||||
Major changes - portability
|
||||
---------------------------
|
||||
|
||||
[Incompat 20050716] Internal interfaces have changed; this may break
|
||||
third-party patches because the types of function arguments and of
|
||||
result values have changed. The types of buffer lengths and offsets
|
||||
were changed from "int" or "unsigned int" (32 bit on 32-bit and
|
||||
LP64 systems) to "ssize_t" or "size_t" (64 bit on LP64 systems, 32
|
||||
bit on 32-bit systems).
|
||||
|
||||
This change makes no difference in Postfix behavior on 32-bit
|
||||
systems. On LP64 systems, however, this change not only eliminates
|
||||
some obscure portability bugs, it also eliminates unnecessary
|
||||
conversions between 32/64 bit integer types, because many system
|
||||
library routines take "(s)size_t" arguments or return "(s)size_t"
|
||||
values.
|
||||
|
||||
This change may break software on LP64 systems 1) when Postfix is
|
||||
linked with pre-compiled code that was compiled with old Postfix
|
||||
interface definitions and 2) when compiling Postfix source that was
|
||||
modified by a third-party patch: incorrect code will be generated
|
||||
when the patch passes the wrong integer argument type in contexts
|
||||
that disable automatic argument type conversions. Examples of such
|
||||
contexts are formatting with printf-like arguments, and invoking
|
||||
functions that write Postfix request or reply attributes across
|
||||
inter-process communication channels. Unfortunately, gcc reports
|
||||
"(unsigned) int" versus "(s)size_t" format string argument mis-matches
|
||||
only on LP64 systems.
|
||||
|
||||
Major changes - safety
|
||||
----------------------
|
||||
|
||||
[Incompat 20051121] Although the permit_mx_backup feature still
|
||||
accepts mail for authorized destinations (see permit_mx_backup for
|
||||
definition), with all other destinations it now requires that the
|
||||
local MTA is listed as non-primary MX. This prevents mail loop
|
||||
problems when someone points the primary MX record at a Postfix
|
||||
system.
|
||||
|
||||
[Incompat 20051011] The Postfix local(8) delivery agent no longer
|
||||
updates its idea of the Delivered-To: address while it expands
|
||||
aliases or .forward files. With deeply nested aliases or .forward
|
||||
files, this can greatly reduce the number of queue files and cleanup
|
||||
process instances. To get the earlier behavior, specify
|
||||
"frozen_delivered_to = no".
|
||||
|
||||
The frozen_delivered_to feature can help to alleviate a long-standing
|
||||
problem with multiple deliveries to recipients that are listed
|
||||
multiple times in a hierarchy of nested aliases. For this to work,
|
||||
only the top-level alias should have an owner- alias, and none of
|
||||
the subordinate aliases.
|
||||
|
||||
[Incompat 20050828] When a header/body_checks rule or when
|
||||
message_reject_characters rejects mail that was submitted with the
|
||||
Postfix sendmail command (or re-queued with "postsuper -r"), the
|
||||
returned message is now limited to just the message headers, to
|
||||
avoid the risk of exposure to harmful content in the message body
|
||||
or attachments.
|
||||
|
||||
[Incompat 20051202] The Postfix SMTP server now refuses to receive
|
||||
mail from the network if it isn't running with postfix mail_owner
|
||||
privileges. This prevents surprises when, for example, "sendmail
|
||||
-bs" is configured to run as root from xinetd.
|
||||
|
||||
[Incompat 20060123] For safety reasons, Postfix no longer allows
|
||||
$number substitution in regexp: or pcre: transport tables or
|
||||
per-sender relayhost tables.
|
||||
|
||||
[Incompat 20060112] The Postfix SMTP/LMTP client by default no
|
||||
longer allows DNS CNAME records to override the server hostname
|
||||
that is used for logging, SASL password lookup, TLS policy selection
|
||||
and TLS server certificate verification. Specify
|
||||
"smtp_cname_overrides_servername = yes" to get the old behavior.
|
||||
198
RELEASE_NOTES-2.4
Normal file
198
RELEASE_NOTES-2.4
Normal file
|
|
@ -0,0 +1,198 @@
|
|||
The stable Postfix release is called postfix-2.4.x where 2=major
|
||||
release number, 4=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.5-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.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
See RELEASE_NOTES-2.3 if you upgrade from Postfix 2.2 or earlier.
|
||||
|
||||
[Incompat 20070122] To take advantage of the new support for BSD
|
||||
kqueue, Linux epoll, or Solaris /dev/poll, you must restart (not
|
||||
reload) Postfix after upgrading from Postfix 2.3.
|
||||
|
||||
[Incompat 20061209] If you upgrade Postfix without restarting, you
|
||||
MUST execute "postfix reload", otherwise the queue manager may log
|
||||
a warnings with:
|
||||
|
||||
warning: connect to transport retry: Connection refused
|
||||
|
||||
[Incompat 20061209] The upgrade procedure adds a new "retry" service
|
||||
to the master.cf file. If you make the mistake of copying old
|
||||
Postfix configuration files over the new files, the queue manager
|
||||
may log warnings with:
|
||||
|
||||
warning: connect to transport retry: Connection refused
|
||||
|
||||
To fix your master.cf file, use "postfix upgrade-configuration"
|
||||
followed by "postfix reload".
|
||||
|
||||
Major changes - safety
|
||||
----------------------
|
||||
|
||||
[Incompat 20070222] As a safety measure, Postfix now by default
|
||||
creates mailbox dotlock files on all systems. This prevents problems
|
||||
with GNU POP3D which subverts kernel locking by creating a new
|
||||
mailbox file and deleting the old one.
|
||||
|
||||
Major changes - Milter support
|
||||
------------------------------
|
||||
|
||||
[Feature 20070121] The support for Milter header modification
|
||||
requests was revised. With minimal change in the on-disk representation,
|
||||
the code was greatly simplified, and regression tests were updated
|
||||
to ensure that old errors were not re-introduced. The queue file
|
||||
format is entirely backwards compatible with Postfix 2.3.
|
||||
|
||||
[Feature 20070116] Support for Milter requests to replace the message
|
||||
body. Postfix now implements all the header/body modification
|
||||
requests that are available with Sendmail 8.13.
|
||||
|
||||
[Incompat 20070116] A new field is added to the queue file "size"
|
||||
record that specifies the message content length. Postfix 2.3 and
|
||||
older Postfix 2.4 snapshots will ignore this field, and will report
|
||||
the message size as it was before the body was replaced.
|
||||
|
||||
Major changes - TLS support
|
||||
---------------------------
|
||||
|
||||
[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
|
||||
attributes (client ccert_subject, ccert_issuer) only after successful
|
||||
client certificate verification. The reason is that the certification
|
||||
verification status itself is not available in the policy request.
|
||||
|
||||
[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
|
||||
fingerprint information even when the certificate itself was not
|
||||
verified.
|
||||
|
||||
[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
|
||||
can be used for access control even when the certificate itself was
|
||||
not verified.
|
||||
|
||||
[Incompat 20061006] The format of SMTP server TLS session cache
|
||||
lookup keys has changed. The lookup key now includes the master.cf
|
||||
service name.
|
||||
|
||||
Major changes - performance
|
||||
---------------------------
|
||||
|
||||
[Feature 20070212] Better support for systems that run thousands
|
||||
of Postfix processes. Postfix now supports FreeBSD kqueue(2),
|
||||
Solaris poll(7d) and Linux epoll(4) as more scalable alternatives
|
||||
to the traditional select(2) system call, and uses poll(2) when
|
||||
examining a single file descriptor for readability or writability.
|
||||
These features are supported on sufficiently recent versions of
|
||||
FreeBSD, NetBSD, OpenBSD, Solaris and Linux; support for other
|
||||
systems will be added as evidence becomes available that usable
|
||||
implementations exist.
|
||||
|
||||
[Incompat 20070201] Some default settings have been adjusted to
|
||||
better match contemporary requirements:
|
||||
|
||||
- queue_run_delay and minimal_backoff_time were reduced from 1000s
|
||||
to 300s so that deliveries are retried earlier after the first
|
||||
failure.
|
||||
|
||||
- ipc_idle was reduced from 100s to 5s, so that tlsmgr and scache
|
||||
clients will more quickly release unused file handles.
|
||||
|
||||
[Feature 20061209] Improved worst-case (old and new) queue manager
|
||||
performance when deferring or bouncing large amounts of mail. Instead
|
||||
of talking to the bounce or defer service synchronously, this work
|
||||
is now done in the background by the error or retry service.
|
||||
|
||||
[Feature 20061209] Improved worst-case (new) queue manager performance
|
||||
when delivering multi-recipient mail. The queue manager now proactively
|
||||
reads recipients from the queue file, instead of waiting for the
|
||||
slowest deliveries to complete before reading in new recipients.
|
||||
This introduces two parameters: default_recipient_refill_limit (how
|
||||
many recipient slots to refill at a time) and
|
||||
default_recipient_refill_delay (how long to wait between refill
|
||||
operations). These two parameters act as defaults for optional
|
||||
per-transport settings.
|
||||
|
||||
Major changes - delivery status notifications
|
||||
---------------------------------------------
|
||||
|
||||
[Incompat 20061209] Small changes were made to the default bounce
|
||||
message templates, to prevent HTML-aware software from hiding or
|
||||
removing the text "<postmaster>", and producing misleading text.
|
||||
|
||||
[Incompat 20060806] Postfix no longer announces its name in delivery
|
||||
status notifications. Users believe that Wietse provides a free
|
||||
help desk service that solves all their email problems.
|
||||
|
||||
Major changes - ETRN support
|
||||
----------------------------
|
||||
|
||||
[Feature 20061217] More precise queue flushing with the ETRN,
|
||||
"postqueue -s site", and "sendmail -qRsite" commands, after
|
||||
minimization of race conditions. New per-queue-file flushing with
|
||||
"postqueue -i queueid" and "sendmail -qIqueueid".
|
||||
|
||||
Major changes - small office/home office support
|
||||
------------------------------------------------
|
||||
|
||||
[Incompat 20061217] Postfix no longer requires a domain name. It
|
||||
uses "localdomain" as the default Internet domain name when no
|
||||
domain is specified via main.cf or via the machine's hostname.
|
||||
|
||||
Major changes - SMTP access control
|
||||
-----------------------------------
|
||||
|
||||
[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
|
||||
attributes (client ccert_subject, ccert_issuer) only after successful
|
||||
client certificate verification. The reason is that the certification
|
||||
verification status itself is not available in the policy request.
|
||||
|
||||
[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
|
||||
fingerprint information even when the certificate itself was not
|
||||
verified.
|
||||
|
||||
[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
|
||||
can be used for
|
||||
access control even when the certificate itself was not verified.
|
||||
|
||||
[Incompat 20061209] The Postfix installation procedure no longer
|
||||
updates main.cf with "unknown_local_recipient_reject_code = 450".
|
||||
Four years after the introduction of mandatory recipient validation,
|
||||
this transitional tool is no longer neeed.
|
||||
|
||||
Major changes - workarounds
|
||||
---------------------------
|
||||
|
||||
[Incompat 20070222] As a safety measure, Postfix now by default
|
||||
creates mailbox dotlock files on all systems. This prevents problems
|
||||
with GNU POP3D which subverts kernel locking by creating a new
|
||||
mailbox file and deleting the old one.
|
||||
|
||||
[Feature 20061209] Better interoperability with non-conforming SMTP
|
||||
servers that reply and disconnect before Postfix has sent the
|
||||
complete message content.
|
||||
|
||||
[Feature 20061209] Better support for queue file systems on file
|
||||
servers with drifting clocks. Clock skew can be a problem, because
|
||||
Postfix does not deliver mail until the local clock catches up with
|
||||
the queue file's last modification time stamp. On systems with
|
||||
usable futimes() or equivalent (Solaris, *BSD, MacOS, but not Linux),
|
||||
Postfix now always explicitly sets the queue file last modification
|
||||
time stamps while creating a queue file. On systems without usable
|
||||
futimes() (Linux, and ancient versions of Solaris, SunOS and *BSD)
|
||||
Postfix keeps using the slower utime() system call to update queue
|
||||
file time stamps when the file system clock is off with respect to
|
||||
the local system clock, and logs a warning.
|
||||
|
||||
[Feature 20061006] Individual CISCO PIX bug workarounds are now
|
||||
on/off configurable. This introduces new parameters: smtp_pix_workarounds
|
||||
(default: disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
|
||||
(workarounds indexed by server IP address). The default settings
|
||||
are backwards compatible.
|
||||
376
RELEASE_NOTES-2.5
Normal file
376
RELEASE_NOTES-2.5
Normal file
|
|
@ -0,0 +1,376 @@
|
|||
The stable Postfix release is called postfix-2.5.x where 2=major
|
||||
release number, 5=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.6-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.
|
||||
|
||||
Incompatibility with Postfix 2.3 and earlier
|
||||
--------------------------------------------
|
||||
|
||||
If you upgrade from Postfix 2.3 or earlier, read RELEASE_NOTES-2.4
|
||||
before proceeding.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
[Incompat 20071224] The protocol to send Milter information from
|
||||
smtpd(8) to cleanup(8) processes was cleaned up. If you use the
|
||||
Milter feature, and upgrade a live Postfix system, you may see an
|
||||
"unexpected record type" warning from a cleanup(8) server process.
|
||||
To prevent this, execute the command "postfix reload". The
|
||||
incompatibility affects only systems that use the Milter feature.
|
||||
It does not cause loss of mail, just a minor delay until the remote
|
||||
SMTP client retries.
|
||||
|
||||
[Incompat 20071212] The allow_min_user feature now applies to both
|
||||
sender and recipient addresses in SMTP commands. With earlier Postfix
|
||||
versions, only recipients were subject to the allow_min_user feature,
|
||||
and the restriction took effect at mail delivery time, causing mail
|
||||
to be bounced later instead of being rejected immediately.
|
||||
|
||||
[Incompat 20071206] The "make install" and "make upgrade" procedures
|
||||
now create a Postfix-owned directory for Postfix-writable data files
|
||||
such as caches and random numbers. The location is specified with
|
||||
the "data_directory" parameter (default: "/var/lib/postfix"), and
|
||||
the ownership is specified with the "mail_owner" parameter.
|
||||
|
||||
[Incompat 20071206] The tlsmgr(8) and verify(8) servers no longer
|
||||
use root privileges when opening the address_verify_map,
|
||||
*_tls_session_cache_database, and tls_random_exchange_name cache
|
||||
files. This avoids a potential security loophole where the ownership
|
||||
of a file (or directory) does not match the trust level of the
|
||||
content of that file (or directory).
|
||||
|
||||
[Incompat 20071206] The tlsmgr(8) and verify(8) cache files should
|
||||
now be stored as Postfix-owned files under the Postfix-owned
|
||||
data_directory. As a migration aid, attempts to open these files
|
||||
under a non-Postfix directory are redirected to the Postfix-owned
|
||||
data_directory, and a warning is logged.
|
||||
|
||||
This is an example of the warning messages:
|
||||
|
||||
Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: request
|
||||
to update file /etc/postfix/prng_exch in non-postfix directory
|
||||
/etc/postfix
|
||||
|
||||
Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: redirecting
|
||||
the request to postfix-owned data_directory /var/lib/postfix
|
||||
|
||||
If you wish to continue using a pre-existing tls_random_exchange_name
|
||||
or address_verify_map file, move it to the Postfix-owned data_directory
|
||||
and change ownership from root to Postfix (that is, change ownership
|
||||
to the account specified with the mail_owner configuration parameter).
|
||||
|
||||
[Feature 20071205] The "make install" and "make upgrade" procedures
|
||||
now create a Postfix-owned directory for Postfix-writable data files
|
||||
such as caches and random numbers. The location is specified with
|
||||
the "data_directory" parameter (default: "/var/lib/postfix"), and
|
||||
the ownership is specified with the "mail_owner" parameter.
|
||||
|
||||
[Incompat 20071203] The "make upgrade" procedure adds a new service
|
||||
"proxywrite" to the master.cf file, for read/write lookup table
|
||||
access. If you copy your old configuration file over the updated
|
||||
one, you may see warnings in the maillog file like this:
|
||||
|
||||
connect #xx to subsystem private/proxywrite: No such file or directory
|
||||
|
||||
To recover, run "postfix upgrade-configuration" again.
|
||||
|
||||
[Incompat 20070613] The pipe(8) delivery agent no longer allows
|
||||
delivery with the same group ID as the main.cf postdrop group.
|
||||
|
||||
Major changes - malware defense
|
||||
-------------------------------
|
||||
|
||||
[Feature 20080107] New "pass" service type in master.cf. Written
|
||||
years ago, this allows future front-end daemons to accept all
|
||||
connections from the network, and to hand over connections from
|
||||
well-behaved clients to Postfix. Since this feature uses file
|
||||
descriptor passing, it imposes no overhead once a connection is
|
||||
handed over to Postfix. See master(5) for a few details.
|
||||
|
||||
[Feature 20070911] Stress-adaptive behavior. When a "public" network
|
||||
service runs into an "all processes are busy" condition, the master(8)
|
||||
daemon logs a warning, restarts the service, and runs it with "-o
|
||||
stress=yes" on the command line (under normal conditions it runs
|
||||
the service with "-o stress=" on the command line). This can be
|
||||
used to make main.cf parameter settings stress dependent, for
|
||||
example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_timeout = ${stress?10}${stress:300}
|
||||
smtpd_hard_error_limit = ${stress?1}${stress:20}
|
||||
|
||||
Translation: under conditions of stress, use an smtpd_timeout value
|
||||
of 10 seconds instead of 300, and use smtpd_hard_error_limit of 1
|
||||
instead of 20. The syntax is explained in the postconf(5) manpage.
|
||||
|
||||
The STRESS_README file gives examples of how to mitigate flooding
|
||||
problems.
|
||||
|
||||
Major changes - tls support
|
||||
---------------------------
|
||||
|
||||
[Incompat 20080109] TLS logging output has changed to make it more
|
||||
useful. Existing logfile parser regular expressions may need
|
||||
adjustment.
|
||||
|
||||
- More log entries include the "hostnamename[ipaddress]" of the
|
||||
remote SMTP peer.
|
||||
|
||||
- Certificate trust chain error reports show only the first
|
||||
error certificate (closest to the trust chain root), and the
|
||||
reporting is more human-readable for the most likely errors.
|
||||
|
||||
- After the completion of the TLS handshake, the session is logged
|
||||
with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
|
||||
"Verified" (SMTP client only).
|
||||
- "Untrusted" means that the certificate trust chain is invalid,
|
||||
or that the root CA is not trusted.
|
||||
- "Trusted" means that the certificate trust chain is valid, and
|
||||
that the root CA is trusted.
|
||||
- "Verified" means that the certificate meets the SMTP client's
|
||||
matching criteria for the destination:
|
||||
- In the case of a destination name match, "Verified" also
|
||||
implies "Trusted".
|
||||
- In the case of a fingerprint match, CA trust is not applicable.
|
||||
|
||||
- The logging of protocol states with TLS loglevel >= 2 no longer
|
||||
reports bogus error conditions when OpenSSL asks Postfix to refill
|
||||
(or flush) network I/O buffers. This loglevel is for debugging
|
||||
only; use 0 or 1 in production configurations.
|
||||
|
||||
[Feature 20080109] The Postfix SMTP client has a new "fingerprint"
|
||||
security level. This avoids dependencies on CAs, and relies entirely
|
||||
on bi-lateral exchange of public keys (really self-signed or private
|
||||
CA signed X.509 public key certificates). Scalability is clearly
|
||||
limited. For details, see the fingerprint discussion in TLS_README.
|
||||
|
||||
[Feature 20080109] The Postfix SMTP server can now use SHA1 instead
|
||||
of MD5 to compute remote SMTP client certificate fingerprints. For
|
||||
backwards compatibility, the default algorithm is MD5. For details,
|
||||
see the "smtpd_tls_fingerprint_digest" parameter in the postconf(5)
|
||||
manual.
|
||||
|
||||
[Feature 20080109] The maximum certificate trust chain depth
|
||||
(verifydepth) is finally implemented in the Postfix TLS library.
|
||||
Previously, the parameter had no effect. The default depth was
|
||||
changed to 9 (the OpenSSL default) for backwards compatibility.
|
||||
|
||||
If you have explicity limited the verification depth in main.cf,
|
||||
check that the configured limit meets your needs. See the
|
||||
"lmtp_tls_scert_verifydepth", "smtp_tls_scert_verifydepth" and
|
||||
"smtpd_tls_ccert_verifydepth" parameters in the postconf(5) manual.
|
||||
|
||||
[Feature 20080109] The selection of SSL/TLS protocols for mandatory
|
||||
TLS can now use exclusion rather than inclusion. Either form is
|
||||
acceptable; see the "lmtp_tls_mandatory_protocols",
|
||||
"smtp_tls_mandatory_protocols" and "smtpd_tls_mandatory_protocols"
|
||||
parameters in the postconf(5) manual.
|
||||
|
||||
Major changes - scheduler
|
||||
-------------------------
|
||||
|
||||
[Feature 20071130] Revised queue manager with separate mechanisms
|
||||
for per-destination concurrency control and for dead destination
|
||||
detection. The concurrency control supports less-than-1 feedback
|
||||
to allow for more gradual concurrency adjustments, and uses hysteresis
|
||||
to avoid rapid oscillations. A destination is declared "dead" after
|
||||
a configurable number of pseudo-cohorts(*) reports connection or
|
||||
handshake failure.
|
||||
|
||||
(*) A pseudo-cohort is a number of delivery requests equal to a
|
||||
destination's delivery concurrency.
|
||||
|
||||
The drawbacks of the old +/-1 feedback scheduler are a) overshoot
|
||||
due to exponential delivery concurrency growth with each pseudo-cohort(*)
|
||||
(5-10-20...); b) throttling down to zero concurrency after a single
|
||||
pseudo-cohort(*) failure. The latter was especially an issue with
|
||||
low-concurrency channels where a single failure could be sufficient
|
||||
to mark a destination as "dead", and suspend further deliveries.
|
||||
|
||||
New configuration parameters: destination_concurrency_feedback_debug,
|
||||
default_destination_concurrency_positive_feedback,
|
||||
default_destination_concurrency_negative_feedback,
|
||||
default_destination_concurrency_failed_cohort_limit, as well as
|
||||
transport-specific versions of the same.
|
||||
|
||||
The default parameter settings are backwards compatible with older
|
||||
Postfix versions. This may change after better defaults are field
|
||||
tested.
|
||||
|
||||
The updated SCHEDULER_README document describes the theory behind
|
||||
the new concurrency scheduler, as well as Patrik Rak's preemptive
|
||||
job scheduler. See postconf(5) for more extensive descriptions of
|
||||
the configuration parameters.
|
||||
|
||||
Major changes - small/home office
|
||||
---------------------------------
|
||||
|
||||
[Feature 20080115] Preliminary SOHO_README document that combines
|
||||
bits and pieces from other document in one place, so that it is
|
||||
easier to find. This document describes the "mail sending" side
|
||||
only.
|
||||
|
||||
[Feature 20071202] Output rate control in the queue manager. For
|
||||
example, specify "smtp_destination_rate_delay = 5m", to pause five
|
||||
minutes between message deliveries. More information in the postconf(5)
|
||||
manual under "default_destination_rate_delay".
|
||||
|
||||
Major changes - smtp client
|
||||
---------------------------
|
||||
|
||||
[Incompat 20080114] The Postfix SMTP client now by default defers
|
||||
mail after a remote SMTP server rejects a SASL authentication
|
||||
attempt. Specify "smtp_sasl_auth_soft_bounce = no" for the old
|
||||
behavior.
|
||||
|
||||
[Feature 20080114] The Postfix SMTP client can now avoid making
|
||||
repeated SASL login failures with the same server, username and
|
||||
password. To enable this safety feature, specify for example
|
||||
"smtp_sasl_auth_cache_name = proxy:btree:/var/lib/postfix/sasl_auth_cache"
|
||||
(access through the proxy service is required). Instead of trying
|
||||
to SASL authenticate, the Postfix SMTP client defers or bounces
|
||||
mail as controlled with the new smtp_sasl_auth_soft_bounce configuration
|
||||
parameter.
|
||||
|
||||
[Feature 20071111] Header/body checks are now available in the SMTP
|
||||
client, after the implementation was moved from the cleanup server
|
||||
to a library module. The SMTP client provides only actions that
|
||||
don't change the message delivery time or destination: warn, replace,
|
||||
prepend, ignore, dunno, ok.
|
||||
|
||||
[Incompat 20070614] By default, the Postfix Cyrus SASL client no
|
||||
longer sends a SASL authoriZation ID (authzid); it sends only the
|
||||
SASL authentiCation ID (authcid) plus the authcid's password. Specify
|
||||
"send_cyrus_sasl_authzid = yes" to get the old behavior.
|
||||
|
||||
Major changes - smtp server
|
||||
---------------------------
|
||||
|
||||
[Feature 20070724] Not really major. New support for RFC 3848
|
||||
(Received: headers with ESMTPS, ESMTPA, or ESMTPSA); updated SASL
|
||||
support according to RFC 4954, resulting in small changes to SMTP
|
||||
reply codes and (DSN) enhanced status codes.
|
||||
|
||||
Major changes - milter
|
||||
----------------------
|
||||
|
||||
[Incompat 20071224] The protocol to send Milter information from
|
||||
smtpd(8) to cleanup(8) processes was cleaned up. If you use the
|
||||
Milter feature, and upgrade a live Postfix system, you may see an
|
||||
"unexpected record type" warning from a cleanup(8) server process.
|
||||
To prevent this, execute the command "postfix reload". The
|
||||
incompatibility affects only systems that use the Milter feature.
|
||||
It does not cause loss of mail, just a minor delay until the remote
|
||||
SMTP client retries.
|
||||
|
||||
[Feature 20071221] Support for most of the Sendmail 8.14 Milter
|
||||
protocol features.
|
||||
|
||||
To enable the new features specify "milter_protocol = 6" and link
|
||||
the filter application with a libmilter library from Sendmail 8.14
|
||||
or later.
|
||||
|
||||
Sendmail 8.14 Milter features supported at this time:
|
||||
|
||||
- NR_CONN, NR_HELO, NR_MAIL, NR_RCPT, NR_DATA, NR_UNKN, NR_HDR,
|
||||
NR_EOH, NR_BODY: The filter can tell Postfix that it won't reply
|
||||
to some of the SMTP events that Postfix sends. This makes the
|
||||
protocol less chatty and improves performance.
|
||||
|
||||
- SKIP: The filter can tell Postfix to skip sending the rest of
|
||||
the message body, which also improves performance.
|
||||
|
||||
- HDR_LEADSPC: The filter can request that Postfix does not delete
|
||||
the first space character between header name and header value
|
||||
when sending a header to the filter, and that Postfix does not
|
||||
insert a space character between header name and header value
|
||||
when receiving a header from the filter. This fixes a limitation
|
||||
in the old Milter protocol that can break DKIM and DK signatures.
|
||||
|
||||
- SETSYMLIST: The filter can override one or more of the main.cf
|
||||
milter_xxx_macros parameter settings.
|
||||
|
||||
Sendmail 8.14 Milter features not supported at this time:
|
||||
|
||||
- RCPT_REJ: report rejected recipients to the mail filter.
|
||||
|
||||
- CHGFROM: replace sender, with optional ESMTP command parameters.
|
||||
|
||||
- ADDRCPT_PAR: add recipient, with optional ESMTP command parameters.
|
||||
|
||||
It is unclear when (if ever) the missing features will be implemented.
|
||||
SMFIP_RCPT_REJ requires invasive changes in the SMTP server recipient
|
||||
processing and error handling. SMFIR_CHGFROM and SMFIR_ADDRCPT_PAR
|
||||
require ESMTP command-line parsing in the cleanup server. Unfortunately,
|
||||
Sendmail's documentation does not specify what ESMTP options are
|
||||
supported, but only discusses examples of things that don't work.
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Incompat 20070514] The default sender address for address verification
|
||||
probes was changed from "postmaster" to "double-bounce", so that
|
||||
the Postfix SMTP server no longer causes surprising behavior by
|
||||
excluding "postmaster" from SMTP server access controls.
|
||||
|
||||
Major changes - ldap
|
||||
--------------------
|
||||
|
||||
[Incompat 20071216] Due to an incompatible API change between
|
||||
OpenLDAP 2.0.11 and 2.0.12, an LDAP client compiled for OpenLDAP
|
||||
version <= 2.0.11 will refuse to work with an OpenLDAP library
|
||||
version >= 2.0.12 and vice versa.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20080109] TLS logging output has changed to make it more
|
||||
useful. Existing logfile parser regular expressions may need
|
||||
adjustment.
|
||||
|
||||
- More log entries include the "hostnamename[ipaddress]" of the
|
||||
remote SMTP peer.
|
||||
|
||||
- Certificate trust chain error reports show only the first
|
||||
error certificate (closest to the trust chain root), and the
|
||||
reporting is more human-readable for the most likely errors.
|
||||
|
||||
- After the completion of the TLS handshake, the session is logged
|
||||
with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
|
||||
"Verified" (SMTP client only).
|
||||
- "Untrusted" means that the certificate trust chain is invalid,
|
||||
or that the root CA is not trusted.
|
||||
- "Trusted" means that the certificate trust chain is valid, and
|
||||
that the root CA is trusted.
|
||||
- "Verified" means that the certificate meets the SMTP client's
|
||||
matching criteria for the destination:
|
||||
- In the case of a destination name match, "Verified" also
|
||||
implies "Trusted".
|
||||
- In the case of a fingerprint match, CA trust is not applicable.
|
||||
|
||||
- The logging of protocol states with TLS loglevel >= 2 no longer
|
||||
reports bogus error conditions when OpenSSL asks Postfix to refill
|
||||
(or flush) network I/O buffers. This loglevel is for debugging
|
||||
only; use 0 or 1 in production configurations.
|
||||
|
||||
[Incompat 20071216] The SMTP "transcript of session" email now
|
||||
includes the remote SMTP server TCP port number.
|
||||
|
||||
Major changes - loop detection
|
||||
------------------------------
|
||||
|
||||
[Incompat 20070422] [Incompat 20070422] When the pipe(8) delivery
|
||||
agent is configured to create the optional Delivered-To: header,
|
||||
it now first checks if that same header is already present in the
|
||||
message. If so, the message is returned as undeliverable. This test
|
||||
should have been included with Postfix 2.0 when Delivered-To: support
|
||||
was added to the pipe(8) delivery agent.
|
||||
300
RELEASE_NOTES-2.6
Normal file
300
RELEASE_NOTES-2.6
Normal file
|
|
@ -0,0 +1,300 @@
|
|||
The stable Postfix release is called postfix-2.6.x where 2=major
|
||||
release number, 6=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.7-yyyymmdd where yyyymmdd is the release date (yyyy=year,
|
||||
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.4 or earlier, read RELEASE_NOTES-2.5
|
||||
before proceeding.
|
||||
|
||||
Major changes - multi-instance support
|
||||
--------------------------------------
|
||||
|
||||
[Feature 20090121] Support for managing multiple Postfix instances.
|
||||
This can automatically apply your "postfix start" etc. command to
|
||||
multiple Postfix instances, including upgrades to new Postfix
|
||||
versions. Multi-instance support allows you to do the following
|
||||
and more:
|
||||
|
||||
- Simplify post-queue content filter configuration by using separate
|
||||
Postfix instances before and after the filter. This simplifies
|
||||
trouble shooting and performance tuning.
|
||||
|
||||
- Implement per-user content filters (or no filter) via transport
|
||||
map lookups instead of content_filter settings. Mail for some
|
||||
users can be sent directly from the before-filter instance to the
|
||||
after-filter instance.
|
||||
|
||||
- Test new configuration settings (on a different server IP address
|
||||
or TCP port) without disturbing production instances.
|
||||
|
||||
- Each additional Postfix instance uses a few files and directories,
|
||||
plus memory for an extra master daemon and queue manager. The
|
||||
pickup daemon is needed only if you use local submission or
|
||||
"postsuper -r".
|
||||
|
||||
Best of all, nothing changes when you use only one Postfix instance.
|
||||
|
||||
The MULTI_INSTANCE_README file presents an introduction to
|
||||
multi-instance management. Multi-instance support is based on an
|
||||
API that is described in the postfix-wrapper(5) manual page.
|
||||
|
||||
Major changes - milter support
|
||||
------------------------------
|
||||
|
||||
[Feature 20090428] The following improvements have been made to the
|
||||
Milter implementation:
|
||||
|
||||
- Improved compatibility of the {mail_addr} and {rcpt_addr} macros.
|
||||
|
||||
- Support for the {mail_host}, {mail_mailer}, {rcpt_host} and
|
||||
{rcpt_mailer} macros.
|
||||
|
||||
- Milter applications can now request rejected recipients with the
|
||||
SMFIP_RCPT_REJ feature. Rejected recipients are reported with
|
||||
{rcpt_mailer} = "error", {rcpt_host} = enhanced status code, and
|
||||
{rcpt_addr} = descriptive text. This feature requires "milter_protocol
|
||||
= 6" or higher (default as of Postfix 2.6).
|
||||
|
||||
- Milters can now replace the envelope sender address with the
|
||||
SMFIR_CHGFROM request, and can add recipients with SMFIR_ADDRCPT_PAR.
|
||||
These implementations ignore ESMTP command parameters and log a
|
||||
warning message as follows:
|
||||
|
||||
warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "whatever"
|
||||
warning: 100B22B3293: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
|
||||
|
||||
[Incompat 20090428] The default milter_protocol setting is increased
|
||||
from 2 to 6; this enables all available features up to and including
|
||||
Sendmail 8.14.0. The new milter_protocol setting may break
|
||||
compatibility with older Milter libraries or applications, and may
|
||||
cause Postfix to log warning messages such as:
|
||||
|
||||
warning: milter inet:host:port: can't read packet header: Unknown error : 0
|
||||
|
||||
warning: milter inet:host:port: can't read packet header: Success
|
||||
|
||||
warning: milter inet:host:port: can't read SMFIC_DATA reply
|
||||
packet header: No such file or directory
|
||||
|
||||
To restore compatibility, specify "milter_protocol = 2" in main.cf.
|
||||
|
||||
Major changes - security
|
||||
------------------------
|
||||
|
||||
[Incompat 20080726] When a mailbox file is not owned by its recipient,
|
||||
the local and virtual delivery agents now log a warning and defer
|
||||
delivery. Specify "strict_mailbox_ownership = no" to ignore such
|
||||
ownership discrepancies.
|
||||
|
||||
Major changes - smtp server
|
||||
---------------------------
|
||||
|
||||
[Feature 20080212] check_reverse_client_hostname_access, to make
|
||||
access decisions based on the unverified client hostname. For
|
||||
safety reasons an OK result is not allowed.
|
||||
|
||||
[Feature 20090210] With "reject_tempfail_action = defer", the Postfix
|
||||
SMTP server immediately replies with a 4xx status after some temporary
|
||||
error, instead of executing an implicit "defer_if_permit" action.
|
||||
|
||||
[Feature 20090215] The Postfix SMTP server automatically hangs up
|
||||
after replying with "521". This makes overload handling more
|
||||
effective. See also RFC 1846 for prior art on this topic.
|
||||
|
||||
[Feature 20090228] The Postfix SMTP server maintains a per-session
|
||||
"improper command pipelining detected" flag. This flag can be tested
|
||||
at any time with reject_unauth_pipelining, and is raised whenever
|
||||
a client command is followed by unexpected commands or message
|
||||
content. The Postfix SMTP server logs the first command pipelining
|
||||
transgression as "improper command pipelining after <command> from
|
||||
<hostname>[<hostaddress>]".
|
||||
|
||||
[Feature 20090212] Stress-dependent behavior is enabled by default.
|
||||
Under conditions of overload, smtpd_timeout is reduced from 300s
|
||||
to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
|
||||
smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
|
||||
the impact of overload for most legitimate mail.
|
||||
|
||||
[Feature 20080629] The Postfix SMTP server's SASL authentication
|
||||
was re-structured. With "smtpd_tls_auth_only = yes", SASL support
|
||||
is now activated only after a successful TLS handshake. Earlier
|
||||
Postfix SMTP server versions could complain about unavailable SASL
|
||||
mechanisms during the plaintext phase of the SMTP protocol.
|
||||
|
||||
[Incompat 20080510] In the policy delegation protocol, certificate
|
||||
common name attributes are now xtext encoded UTF-8. The xtext decoded
|
||||
attributes may contain any UTF-8 value except non-printable ASCII
|
||||
characters.
|
||||
|
||||
Major changes - performance
|
||||
---------------------------
|
||||
|
||||
[Feature 20090215] The Postfix SMTP server automatically hangs up
|
||||
after replying with "521". This makes overload handling more
|
||||
effective. See also RFC 1846 for prior art on this topic.
|
||||
|
||||
[Feature 20090212] Stress-dependent behavior is enabled by default.
|
||||
Under conditions of overload, smtpd_timeout is reduced from 300s
|
||||
to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
|
||||
smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
|
||||
the negative impact of server overload for most legitimate mail.
|
||||
|
||||
[Feature 20090109] Specify "tcp_windowsize = 65535" (or less) to
|
||||
work around routers with broken TCP window scaling implementations.
|
||||
This is perhaps more convenient than collecting tcpdump output and
|
||||
tuning kernel parameters by hand. With Postfix TCP servers (smtpd(8),
|
||||
qmqpd(8)), this feature is implemented by the Postfix master(8)
|
||||
daemon.
|
||||
|
||||
To change this parameter without stopping Postfix, you need to first
|
||||
terminate all Postfix TCP servers:
|
||||
|
||||
# postconf -e master_service_disable=inet
|
||||
# postfix reload
|
||||
|
||||
This immediately terminates all processes that accept network
|
||||
connections. Then you enable Postfix TCP servers with the updated
|
||||
tcp_windowsize setting:
|
||||
|
||||
# postconf -e tcp_windowsize=65535 master_service_disable=
|
||||
# postfix reload
|
||||
|
||||
If you skip these steps with a running Postfix system, then the
|
||||
tcp_windowsize change will work only for Postfix TCP clients (smtp(8),
|
||||
lmtp(8)).
|
||||
|
||||
Of course you can also do "postfix stop" and "postfix start",
|
||||
but that is more disruptive.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Incompat 20090428] The Postfix SMTP client(!) no longer tries to
|
||||
use the obsolete SSLv2 protocol by default, as this may prevent the
|
||||
use of modern SSL features. Lack of SSLv2 support should never be
|
||||
a problem, since SSLv3 was defined in 1996, and TLSv1 in 1999. You
|
||||
can undo the change by specifying empty main.cf values for
|
||||
smtp_tls_protocols and lmtp_tls_protocols. The Postfix SMTP server
|
||||
maintains SSLv2 support for backwards compatibility with ancient
|
||||
clients.
|
||||
|
||||
[Feature 20081010] Controls for the protocols and ciphers that
|
||||
Postfix will use with opportunistic TLS. The smtp_tls_protocols,
|
||||
smtp_tls_ciphers, and equivalent parameters for lmtp and smtpd
|
||||
provide global settings; the SMTP client TLS policy table provides
|
||||
ciphers and protocols settings for specific peers. Code by Victor
|
||||
Duchovni. Details are given in the TLS_README and postconf(5)
|
||||
documents.
|
||||
|
||||
[Feature 20081108] Elliptic curve support. This requires OpenSSL
|
||||
version 0.9.9 or later.
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Incompat 20080428] Postfix SMTP server replies for address
|
||||
verification have changed. unverified_recipient_reject_code and
|
||||
unverified_sender_reject_code now handle "5XX" rejects only. The
|
||||
"4XX" rejects are now controlled with unverified_sender_defer_code
|
||||
and unverified_recipient_defer_code.
|
||||
|
||||
[Feature 20080428] Finer control over the way Postfix reports address
|
||||
verification failures to remote SMTP clients.
|
||||
|
||||
- unverified_sender/recipient_defer_code: the numerical Postfix
|
||||
SMTP server reply code when address verification failed due
|
||||
to some temporary error.
|
||||
|
||||
- unverified_sender/recipient_reject_reason: fixed text that Postfix
|
||||
will send to the remote SMTP client, instead of sending actual
|
||||
address verification details.
|
||||
|
||||
Major changes - dsn
|
||||
-------------------
|
||||
|
||||
[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
|
||||
DSN "success" notifications when LMTP delivery is "final" as opposed
|
||||
to delivery into a content filter.
|
||||
|
||||
Major changes - file organization
|
||||
---------------------------------
|
||||
|
||||
[Incompat 20080207] According to discussions on the mailing list,
|
||||
too many people are breaking newly installed Postfix by overwriting
|
||||
the new /etc/postfix files with versions from an older release, and
|
||||
end up with a broken configuration that cannot repair itself. For
|
||||
this reason, postfix-script, postfix-files and post-install are
|
||||
moved away from /etc/postfix to $daemon_directory.
|
||||
|
||||
Major changes - header rewriting
|
||||
--------------------------------
|
||||
|
||||
[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
|
||||
Message-ID: or To: headers only when clients match
|
||||
$local_header_rewrite_clients. Specify "always_add_missing_headers
|
||||
= yes" for backwards compatibility. Adding such headers can break
|
||||
DKIM signatures that cover headers that are not present. For
|
||||
compatibility with existing logfile processing software, Postfix
|
||||
will log ``message-id=<>'' for messages without Message-Id header.
|
||||
|
||||
Major changes - lmtp client
|
||||
---------------------------
|
||||
|
||||
[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
|
||||
DSN "success" notifications when LMTP delivery is "final" as opposed
|
||||
to delivery into a content filter.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
|
||||
Message-ID: or To: headers only when clients match
|
||||
$local_header_rewrite_clients. Specify "always_add_missing_headers
|
||||
= yes" for backwards compatibility. Adding such headers can break
|
||||
DKIM signatures that cover headers that are not present.
|
||||
|
||||
This changes the appearance of Postfix logging: to preserve
|
||||
compatibility with existing logfile processing software, Postfix
|
||||
will log ``message-id=<>'' for messages without Message-Id header.
|
||||
|
||||
Major changes - mime
|
||||
--------------------
|
||||
|
||||
[Feature 20080324] When the "postmap -q -" command reads lookup
|
||||
keys from standard input, it now understands RFC822 and MIME message
|
||||
format. Specify -h or -b to use headers or body lines as lookup
|
||||
keys, and specify -hm or -bm to simulate header_checks or body_checks.
|
||||
|
||||
Major changes - miscellaneous
|
||||
-----------------------------
|
||||
|
||||
[Feature 20090109] Support to selectively disable master(8) listener
|
||||
ports by service type or by service name + type. Specify a list of
|
||||
service types ("inet", "unix", "fifo", or "pass") or "name.type"
|
||||
tuples, where "name" is the first field of a master.cf entry and
|
||||
"type" is a service type. Examples: to turn off the main SMTP
|
||||
listener port, use "master_service_disable = smtp.inet"; to turn
|
||||
off all TCP/IP listeners, use "master_service_disable = inet".
|
||||
Changing this parameter requires "postfix reload".
|
||||
|
||||
Major changes - sasl
|
||||
--------------------
|
||||
|
||||
[Feature 20090418] The Postfix SMTP server passes more information
|
||||
to the Dovecot authentication server: the "TLS is active" flag, the
|
||||
server IP address, and the client IP address.
|
||||
|
||||
[Feature 20080629] The Postfix SMTP server's SASL authentication
|
||||
was re-structured. With "smtpd_tls_auth_only = yes", SASL support
|
||||
is now activated only after a successful TLS handshake. Earlier
|
||||
Postfix SMTP server versions could complain about unavailable SASL
|
||||
mechanisms during the plaintext phase of the SMTP protocol.
|
||||
|
||||
175
RELEASE_NOTES-2.7
Normal file
175
RELEASE_NOTES-2.7
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
The stable Postfix release is called postfix-2.7.x where 2=major
|
||||
release number, 7=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
|
||||
mm=month, dd=day). Patches are never issued for snapshot releases;
|
||||
instead, a new snapshot is released.
|
||||
|
||||
The mail_release_date configuration parameter (format: yyyymmdd)
|
||||
specifies the release date of a stable release or snapshot release.
|
||||
|
||||
If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6
|
||||
before proceeding.
|
||||
|
||||
Major changes - performance
|
||||
---------------------------
|
||||
|
||||
[Feature 20100101] Periodic cache cleanup for the verify(8) cache
|
||||
database. The time between cache cleanup runs is controlled with
|
||||
the address_verify_cache_cleanup_interval (default: 12h) parameter.
|
||||
Cache cleanup increases the database access latency, so this should
|
||||
not be run more often than necessary.
|
||||
|
||||
[Feature 20091109] Improved before-queue filter performance. With
|
||||
"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
|
||||
receives the entire message before it connects to a before-queue
|
||||
content filter. This means you can run more SMTP server processes
|
||||
with the same number of running content filter processes, and thus,
|
||||
handle more mail. This feature is off by default until it is proven
|
||||
to create no new problems.
|
||||
|
||||
This addresses a concern of people in Europe who want to reject all
|
||||
bad mail with a before-queue filter. The alternative, an after-queue
|
||||
filter, means they would have to discard bad mail (which is illegal)
|
||||
or bounce bad mail (which violates good network citizenship).
|
||||
|
||||
NOTE 1: When this feature is turned on, a filter cannot selectively
|
||||
reject recipients of a multi-recipient message. It is OK to reject
|
||||
all recipients of the same multi-recipient message, as is deferring
|
||||
or accepting all recipients of the same multi-recipient message.
|
||||
|
||||
NOTE 2: This feature increases the minimum amount of free queue
|
||||
space by $message_size_limit. The extra space is needed to save the
|
||||
message to a temporary file.
|
||||
|
||||
To keep the performance overhead low, the same temporary file is
|
||||
reused with successive mail transactions (the file is of course
|
||||
truncated before reuse, so there is no information leakage).
|
||||
|
||||
Major changes - sender reputation
|
||||
---------------------------------
|
||||
|
||||
[Feature 20100117] The FILTER action in access maps or header/body_checks
|
||||
now supports sender reputation schemes that dynamically choose the
|
||||
SMTP source IP address. Typically, mail is split into classes, and
|
||||
all mail in class X is sent out from an SMTP client IP address that
|
||||
is reserved for class X.
|
||||
|
||||
This is implemented by specifying FILTER actions with empty next-hop
|
||||
destinations in access maps or header/body_checks, and by configuring
|
||||
in master.cf one Postfix SMTP client for each SMTP source IP address,
|
||||
where each client has its own "-o myhostname" and "-o smtp_bind_address"
|
||||
settings.
|
||||
|
||||
[Feature 20091209] sender_dependent_default_transport_maps, a
|
||||
per-sender override for default_transport. The original motivation
|
||||
is to use different output channels (with different source IP
|
||||
addresses) for different sender addresses, in order to keep their
|
||||
IP-based reputations separate from each other.
|
||||
|
||||
The result value syntax is that of default_transport, not transport_maps.
|
||||
Thus, sender_dependent_default_transport_maps does not support the
|
||||
special transport_maps result value syntax for null transport, null
|
||||
nexthop, or null email address.
|
||||
|
||||
This feature makes sender_dependent_relayhost_maps pretty much
|
||||
redundant (though sender_dependent_relayhost_maps will often be
|
||||
easier to use because that is the only thing people want to override).
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Incompat 20100101] The verify(8) service now uses a persistent
|
||||
cache by default (address_verify_map = btree:$data_directory/verify_cache).
|
||||
To disable, specify "address_verify_map =" in main.cf.
|
||||
|
||||
When periodic cache cleanup is enabled (the default), the verify(8)
|
||||
server now requires that the cache database supports the "delete"
|
||||
and "sequence" operations. To disable periodic cache cleanup specify
|
||||
a zero address_verify_cache_cleanup_interval value.
|
||||
|
||||
[Feature 20100101] Periodic cache cleanup for the verify(8) cache
|
||||
database. The time between cache cleanup runs is controlled with
|
||||
the address_verify_cache_cleanup_interval (default: 12h) parameter.
|
||||
Cache cleanup increases the database access latency, so this should
|
||||
not be run more often than necessary.
|
||||
|
||||
Major changes - content filter
|
||||
------------------------------
|
||||
|
||||
[Incompat 20100117] The meaning of an empty filter next-hop destination
|
||||
has changed (for example, "content_filter = foo:" or "FILTER foo:").
|
||||
Postfix now uses the recipient domain, instead of using $myhostname
|
||||
as in Postfix 2.6 and earlier. To restore the old behavior specify
|
||||
"default_filter_nexthop = $myhostname", or specify a non-empty
|
||||
next-hop content filter destination.
|
||||
|
||||
This compatibility option is not needed with SMTP-based content
|
||||
filters, because these always have an explicit next-hop destination.
|
||||
|
||||
With pipe-based filters that specify no next-hop destination, the
|
||||
compatibility option restores the FIFO order of deliveries. Without
|
||||
the compatibility option, the delivery order for filters without
|
||||
next-hop destination changes to round-robin domain selection.
|
||||
|
||||
[Feature 20100117] The FILTER action in access maps or header/body_checks
|
||||
now supports sender reputation schemes that dynamically choose the
|
||||
SMTP source IP address. Typically, mail is split into classes, and
|
||||
all mail in class X is sent out from an SMTP client IP address that
|
||||
is reserved for class X.
|
||||
|
||||
This is implemented by specifying FILTER actions with empty next-hop
|
||||
destinations in access maps or header/body_checks, and by configuring
|
||||
in master.cf one Postfix SMTP client for each SMTP source IP address,
|
||||
where each client has its own "-o myhostname" and "-o smtp_bind_address"
|
||||
settings.
|
||||
|
||||
[Feature 20091109] Improved before-queue filter performance. With
|
||||
"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
|
||||
receives the entire message before it connects to a before-queue
|
||||
content filter. This means you can run more SMTP server processes
|
||||
with the same number of running content filter processes, and thus,
|
||||
handle more mail. This feature is off by default until it is proven
|
||||
to create no new problems.
|
||||
|
||||
This addresses a concern of people in Europe who want to reject all
|
||||
bad mail with a before-queue filter. The alternative, an after-queue
|
||||
filter, means they would have to discard bad mail (which is illegal)
|
||||
or bounce bad mail (which violates good network citizenship).
|
||||
|
||||
NOTE 1: When this feature is turned on, a filter cannot selectively
|
||||
reject recipients of a multi-recipient message. It is OK to reject
|
||||
all recipients of the same multi-recipient message, as is deferring
|
||||
or accepting all recipients of the same multi-recipient message.
|
||||
|
||||
NOTE 2: This feature increases the minimum amount of free queue
|
||||
space by $message_size_limit. The extra space is needed to save the
|
||||
message to a temporary file.
|
||||
|
||||
To keep the performance overhead low, the same temporary file is
|
||||
reused with successive mail transactions (the file is of course
|
||||
truncated before reuse, so there is no information leakage).
|
||||
|
||||
Major changes - milter
|
||||
----------------------
|
||||
|
||||
[Feature 20090606] Support for header checks on Milter-generated
|
||||
message headers. This can be used, for example, to control mail
|
||||
flow with Milter-generated headers that carry indicators for badness
|
||||
or goodness. For details, see the postconf(5) section for
|
||||
"milter_header_checks". Currently, all header_checks features are
|
||||
implemented except PREPEND.
|
||||
|
||||
Major changes - multi-instance support
|
||||
--------------------------------------
|
||||
|
||||
[Incompat 20090606] The "postmulti -e destroy" command no longer
|
||||
attempts to remove files that are created AFTER "postmulti -e
|
||||
create". It still works as expected immediately after creating an
|
||||
instance by mistake. Trying to automatically remove other files
|
||||
is too risky because Postfix-owned directories are by design not
|
||||
trusted.
|
||||
|
||||
383
RELEASE_NOTES-2.8
Normal file
383
RELEASE_NOTES-2.8
Normal file
|
|
@ -0,0 +1,383 @@
|
|||
The stable Postfix release is called postfix-2.8.x where 2=major
|
||||
release number, 8=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.9-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.6 or earlier, read RELEASE_NOTES-2.7
|
||||
before proceeding.
|
||||
|
||||
Major changes - restart Postfix
|
||||
-------------------------------
|
||||
|
||||
If you upgrade from Postfix 2.6 or earlier, you must execute "postfix
|
||||
stop" and "postfix start" before you can use the postscreen(8)
|
||||
daemon. This is needed because the Postfix 2.6 "pass" master service
|
||||
type did not work reliably on some systems.
|
||||
|
||||
If you upgrade from Postfix 2.7, or from Postfix 2.8 before July
|
||||
25, 2010, you must execute "postfix reload" (or "postfix stop"
|
||||
followed by "postfix start"). This is needed because the queue
|
||||
manager to delivery agent protocol has changed. Failure to do this
|
||||
results in repeated logging of warnings with:
|
||||
|
||||
warning: unexpected attribute rewrite_context ...
|
||||
|
||||
If the warning does not go away after restarting Postfix, examine
|
||||
the output from this command:
|
||||
|
||||
strings -af /usr/libexec/postfix/* | grep mail_version=
|
||||
|
||||
(where /usr/libexec/postfix is the value of main.cf:daemon_directory)
|
||||
and update the executables that have a version string that differs
|
||||
from the other programs.
|
||||
|
||||
Major changes - DNSBL/DNSWL support
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20101126] Support for address patterns in DNS blacklist
|
||||
and whitelist lookup results.
|
||||
|
||||
For example, "reject_rbl_client example.com=127.0.0.[2;4;6..8]"
|
||||
will reject clients when the lookup result is 127.0.0.2, 127.0.0.4,
|
||||
127.0.0.6, 127.0.0.7, or 127.0.0.8.
|
||||
|
||||
The setting "postscreen_dnsbl_sites = example.com=127.0.0.[2;4;6..8]"
|
||||
rejects the same clients.
|
||||
|
||||
An IPv4 address pattern has four fields separated by ".". Each
|
||||
field is either a decimal number, or a sequence inside "[]" that
|
||||
contains one or more ";"-separated decimal numbers or number..number
|
||||
ranges.
|
||||
|
||||
Thus, any pattern field can be a sequence inside "[]", but a "[]"
|
||||
sequence cannot span multiple address fields, and a pattern field
|
||||
cannot contain both a number and a "[]" sequence at the same time.
|
||||
|
||||
This means that the pattern 1.2.[3.4] is not valid (the sequence
|
||||
[3.4] cannot span two address fields) and the pattern 1.2.3.3[6..9]
|
||||
is also not valid (the last field cannot be both number 3 and
|
||||
sequence [6..9] at the same time).
|
||||
|
||||
The syntax for IPv4 patterns is as follows:
|
||||
|
||||
v4pattern = v4field "." v4field "." v4field "." v4field
|
||||
v4field = v4octet | "[" v4sequence "]"
|
||||
v4octet = any decimal number in the range 0 through 255
|
||||
v4sequence = v4seq_member | v4sequence ";" v4seq_member
|
||||
v4seq_member = v4octet | v4octet ".." v4octet
|
||||
|
||||
[Feature 20101105] The Postfix SMTP server now supports DNS-based
|
||||
whitelisting with several safety features: permit_dnswl_client
|
||||
whitelists a client by IP address, and permit_rhswl_client whitelists
|
||||
a client by its hostname. These features use the same syntax as
|
||||
reject_rbl_client and reject_rhsbl_client, respectively. The main
|
||||
difference is that they return PERMIT instead of REJECT.
|
||||
|
||||
Whitelisting is primarily a tool to reduce the false positive rate
|
||||
of DNS blocklist lookups. Client name whitelisting should not be
|
||||
used to make exceptions to access rules. The reason is that client
|
||||
name lookup can fail unpredictably due to some temporary outage.
|
||||
|
||||
For safety reasons, permit_dnswl_client and permit_rhswl_client are
|
||||
silently ignored when they would override reject_unauth_destination.
|
||||
Also for safety reasons, the result is DEFER_IF_REJECT when DNS
|
||||
whitelist lookup fails (this result will be made configurable).
|
||||
|
||||
Major changes - sqlite support
|
||||
------------------------------
|
||||
|
||||
[Feature 20100617] Support for read-only sqlite database access,
|
||||
with code by Axel Steiner and documentation by Jesus Garcia Crespo.
|
||||
See SQLITE_README and sqlite_table(5) for details.
|
||||
|
||||
Major changes - Milter support
|
||||
-------------------------------
|
||||
|
||||
[Incompat 20101103] Postfix now requests default delivery status
|
||||
notifications when adding a recipient with the Milter smfi_addrcpt
|
||||
action, instead of "never notify" as with Postfix automatically-added
|
||||
recipients (always_bcc and sender/recipient_bcc_maps).
|
||||
|
||||
Major changes - alias expansion
|
||||
-------------------------------
|
||||
|
||||
[Incompat 20101202] Postfix now reports a temporary delivery error
|
||||
when the result of virtual alias expansion would exceed the
|
||||
virtual_alias_recursion_limit or virtual_alias_expansion_limit.
|
||||
Previously, Postfix would silently drop the excess recipients and
|
||||
deliver the message.
|
||||
|
||||
[Incompat 20101006] To avoid repeated delivery to mailing lists
|
||||
with pathological nested alias configurations, the local(8) delivery
|
||||
agent now keeps the owner-alias attribute of a parent alias, when
|
||||
delivering mail to a child alias that does not have its own owner
|
||||
alias.
|
||||
|
||||
With this change, local addresses from that child alias will be
|
||||
written to a new queue file, and a temporary error with one local
|
||||
address will no longer result in repeated delivery to other mailing
|
||||
list members. Specify "reset_owner_alias = yes" for the older,
|
||||
more fragile, behavior.
|
||||
|
||||
The postconf(5) manpage entry for "reset_owner_alias" has more
|
||||
background information on this issue.
|
||||
|
||||
Major changes - dns lookup
|
||||
--------------------------
|
||||
|
||||
[Incompat 20100827] The Postfix SMTP client no longer appends the
|
||||
local domain when looking up a DNS name without ".". Specify
|
||||
"smtp_dns_resolver_options = res_defnames" to get the old behavior,
|
||||
which may produce unexpected results.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20100728] The format of the "postfix/smtpd[pid]: queueid:
|
||||
client=host[addr]" logfile record has changed. When available, the
|
||||
before-filter client information and the before-filter queue ID are
|
||||
now appended to the end of the record.
|
||||
|
||||
[Feature 20100728] Improved message tracking across SMTP-based
|
||||
content filters. The logging example below is from an after-filter
|
||||
SMTP server. Here, 951F692462F is a before-filter queue ID,
|
||||
hades.porcupine.org is a before-filter SMTP client, while 6B4A9924782
|
||||
is the after-filter queue ID, and localhost[127.0.0.1] is the
|
||||
SMTP-based content filter that sends mail into the after-filter
|
||||
SMTP server.
|
||||
|
||||
postfix/smtpd[4074]: 6B4A9924782:
|
||||
client=localhost[127.0.0.1],
|
||||
orig_queue_id=951F692462F
|
||||
orig_client=hades.porcupine.org[168.100.189.10]
|
||||
|
||||
Major changes - reply footer
|
||||
----------------------------
|
||||
|
||||
[Feature 20110105] The SMTP server now supports contact information
|
||||
that is appended to "reject" responses. This includes SMTP server
|
||||
responses that aren't logged to the maillog file, such as responses
|
||||
to syntax errors, or unsupported commands.
|
||||
|
||||
Example:
|
||||
smtpd_reject_footer = For assistance, call 800-555-0101.
|
||||
|
||||
Server response:
|
||||
550-5.5.1 <user@example> Recipient address rejected: User unknown
|
||||
550 5.5.1 For assistance, call 800-555-0101.
|
||||
|
||||
This feature supports macro expansion ($client_address, $localtime,
|
||||
etc.), as documented in the postconf(5) manpage.
|
||||
|
||||
This feature is also supported as postscreen_reject_footer using
|
||||
the same setting as smtpd_reject_footer by default.
|
||||
|
||||
Major changes - rfc compliance
|
||||
------------------------------
|
||||
|
||||
[Incompat 20101206] Postfix by default no longer adds a "To:
|
||||
undisclosed-recipients:;" header when no recipient specified in the
|
||||
message header. The Internet mail RFCs have supported messages
|
||||
without recipient header for almost 10 years now.
|
||||
|
||||
For backwards compatibility, specify:
|
||||
|
||||
/etc/postfix/main.cf
|
||||
undisclosed_recipients_header = To: undisclosed-recipients:;
|
||||
|
||||
Note: both the ":" and ";" are required.
|
||||
|
||||
Major changes - tls support
|
||||
---------------------------
|
||||
|
||||
[Incompat 20110102] The Postfix SMTP server now always re-computes
|
||||
the SASL mechanism list after successful completion of the STARTTLS
|
||||
command. Earlier versions only re-computed the mechanism list when
|
||||
the values of smtp_sasl_tls_security_options and smtp_sasl_security_options
|
||||
differ. This could produce incorrect results, because the Dovecot
|
||||
authentication server may change responses when the SMTP session
|
||||
is encrypted.
|
||||
|
||||
[Incompat 20110102] The smtpd_starttls_timeout default value is now
|
||||
stress-dependent. By default, TLS negotiations must now complete
|
||||
under overload in 10s instead of 300s.
|
||||
|
||||
[Feature 20101223] The new tls_disable_workarounds parameter specifies
|
||||
a list or bit-mask of OpenSSL bug work-arounds to disable. This may
|
||||
be necessary if one of the work-arounds enabled by default in OpenSSL
|
||||
proves to pose a security risk, or introduces an unexpected
|
||||
interoperability issue. Some bug work-arounds known to be problematic
|
||||
are disabled in the default value of the parameter when linked with
|
||||
an OpenSSL library that could be vulnerable. See postconf(5) and
|
||||
TLS_README for details.
|
||||
|
||||
With "tls_preempt_cipherlist = yes" the Postfix SMTP server will
|
||||
choose its most preferred cipher that is supported (offered) by the
|
||||
client. This can lead to a more secure or performant cipher choice,
|
||||
but may also introduce interoperability problems when a client
|
||||
announces support for a cipher that does not work. See postconf(5)
|
||||
and TLS_README for details.
|
||||
|
||||
[Feature 20101217] The lower-level code in the TLS engine was
|
||||
simplified by removing an unnecessary layer of data copying. OpenSSL
|
||||
now writes directly to the network. The difference in performance
|
||||
should be hardly noticeable.
|
||||
|
||||
[Incompat 20100610] Postfix no longer appends the system-supplied
|
||||
default CA certificates to the lists specified with *_tls_CAfile
|
||||
or with *_tls_CApath. This prevents third-party certificates from
|
||||
getting mail relay permission with the permit_tls_all_clientcerts
|
||||
feature.
|
||||
|
||||
Unfortunately this change may cause compatibility problems when
|
||||
configurations rely on certificate verification for other purposes.
|
||||
Specify "tls_append_default_CA = yes" for backwards compatibility.
|
||||
|
||||
Major changes - postscreen
|
||||
--------------------------
|
||||
|
||||
See html/POSTSCREEN_README.html for an introduction to postscreen
|
||||
(or the text version, README_FILES/POSTSCREEN_README). The text
|
||||
below summarizes milestones in reverse chronological order.
|
||||
|
||||
[Incompat 20110111] The postscreen_access_list feature replaces the
|
||||
postscreen_whitelist_networks and postscreen_blacklist_networks
|
||||
features. Reason: CIDR-style access maps are some 100x faster than
|
||||
the code that implemented the postscreen_white/blacklist_networks
|
||||
support. CIDR maps can match about 100 million CIDR patterns/second
|
||||
on a modern CPU, which is not blindingly fast but adequate for the
|
||||
near future.
|
||||
|
||||
[Feature 20110102] STARTTLS support for the postscreen(8) daemon.
|
||||
This is implemented by a new tlsproxy(8) daemon that you will need
|
||||
to enable in master.cf (see POSTSCREEN_README for instructions).
|
||||
tlsproxy(8) implements its own tlsproxy_mumble versions of TLS-related
|
||||
smtpd_mumble parameters. This leaves no confusion about which
|
||||
parameters will affect tlsproxy(8) behavior, but it adds another
|
||||
25 parameters to the documentation.
|
||||
|
||||
[Incompat 20100912] If your DNSBL queries have a "secret" in the
|
||||
domain name, you must now censor this information from the postscreen(8)
|
||||
SMTP replies. For example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
|
||||
|
||||
/etc/postfix/dnsbl_reply:
|
||||
# Secret DNSBL name Name in postscreen(8) replies
|
||||
secret.zen.spamhaus.org zen.spamhaus.org
|
||||
|
||||
The texthash: format is similar to hash: except that there is no need to
|
||||
run postmap(1) before the file can be used, and that it does not detect
|
||||
changes after the file is read. It is new with Postfix version 2.8.
|
||||
|
||||
[Incompat 20100912] The postscreen "continue" action is now called
|
||||
"ignore". The old name is still supported but no longer documented.
|
||||
|
||||
[Incompat 20100912] The postscreen_hangup_action parameter was
|
||||
removed. Postscreen now always behaves as if "postscreen_hangup_action
|
||||
= drop".
|
||||
|
||||
[Incompat 20100912] The postscreen_cache_retention_time default was
|
||||
increased from 1d to 7d, to avoid deleting results from expensive
|
||||
deep SMTP protocol tests too quickly.
|
||||
|
||||
[Feature 20100912] SMTP protocol engine for deep protocol tests,
|
||||
and for logging the helo/sender/recipient information when postscreen
|
||||
rejects an attempt to deliver mail.
|
||||
|
||||
The postscreen SMTP protocol engine implements a number of deep
|
||||
protocol tests and defers or rejects all attempts to deliver mail.
|
||||
The first test detects unauthorized SMTP command pipelining (an
|
||||
SMTP client sends multiple commands, instead of sending one command
|
||||
and waiting for the server response); a second deep protocol test
|
||||
implements the Postfix SMTP server's smtpd_forbidden_commands feature
|
||||
(a client sends commands such as CONNECT, GET, POST); and a third
|
||||
deep protocol test detects spambots that send SMTP commands that
|
||||
end in newline instead of carriage-return/newline. Real spambots
|
||||
rarely make this mistake, but poorly-written software often does.
|
||||
|
||||
Deep protocol tests are disabled by default, because the built-in
|
||||
SMTP engine cannot not hand off the "live" connection from a good
|
||||
SMTP client to a Postfix SMTP server process. To work around this,
|
||||
postscreen(8) defers attempts to deliver mail with a 4XX status,
|
||||
and waits for the client to disconnect. The next time a good client
|
||||
connects, it will be allowed to talk to a Postfix SMTP server process
|
||||
to deliver mail.
|
||||
|
||||
[Feature 20100830] Postscreen DNSBL support is extended with optional
|
||||
fixed-string filters, with optional integral weight factors, and
|
||||
with an adjustable threshold to block SMTP clients with DNSBL score
|
||||
>= that threshold. Reply filters will be implemented later.
|
||||
|
||||
The updated postscreen configuration syntax is:
|
||||
|
||||
postscreen_dnsbl_sites = domain[=ipaddr][*weight] ...
|
||||
postscreen_dnsbl_threshold = score
|
||||
|
||||
Elements inside [] are optional, ipaddr is an IPv4 address, and
|
||||
weight and score are integral numbers. The [] are not part of the
|
||||
postscreen_dnsbl_sites input. By default, weight and score are
|
||||
equal to 1, and entries without filter will match any non-error
|
||||
DNSBL reply. Use a negative weight value for whitelisting.
|
||||
|
||||
Examples:
|
||||
|
||||
To use example.com as a high-confidence blocklist, and to block
|
||||
mail with example.net and example.org only when both agree, use:
|
||||
|
||||
postscreen_dnsbl_threshold = 2
|
||||
postscreen_dnsbl_sites = example.com*2, example.net, example.org
|
||||
|
||||
To filter only DNSBL replies containing 127.0.0.4, use:
|
||||
|
||||
postscreen_dnsbl_sites = example.com=127.0.0.4
|
||||
|
||||
See also postconf(5) for the fine details.
|
||||
|
||||
[Incompat 20100101] When periodic cache cleanup is enabled (the
|
||||
default), the postscreen(8) server now requires that the cache
|
||||
database supports the "delete" and "sequence" operations. To disable
|
||||
periodic cache cleanup specify a zero postscreen_cache_cleanup_interval
|
||||
value.
|
||||
|
||||
[Feature 20100101] Periodic cache cleanup for the postscreen(8)
|
||||
cache database. The time between cache cleanup runs is controlled
|
||||
with the postscreen_cache_cleanup_interval (default: 12h) parameter.
|
||||
Cache cleanup increases the database access latency, so this should
|
||||
not be run more often than necessary.
|
||||
|
||||
In addition, the postscreen_cache_retention_time (default: 1d)
|
||||
parameter specifies how long to keep an expired entry in the cache.
|
||||
This prevents a client from being logged as "NEW" after its record
|
||||
expired only a little while ago.
|
||||
|
||||
[Feature 20091008] Prototype postscreen(8) server that runs a number
|
||||
of time-consuming checks in parallel for all incoming SMTP connections,
|
||||
before clients are allowed to talk to a real Postfix SMTP server.
|
||||
It detects clients that start talking too soon, or clients that
|
||||
appear on DNS blocklists, or clients that hang up without sending
|
||||
any command.
|
||||
|
||||
By doing these checks in a single postscreen(8) process, Postfix
|
||||
can avoid wasting one SMTP server process per connection. A side
|
||||
benefit of postscreen(8)'s DNSBL lookups is that DNS records are
|
||||
already cached before the Postfix SMTP server looks them up later.
|
||||
|
||||
postscreen(8) maintains a temporary whitelist of positive decisions.
|
||||
Once an SMTP client is whitelisted, it is immediately forwarded to
|
||||
a real Postfix SMTP server process without further checking.
|
||||
|
||||
By default, the program logs only statistics, and it does not run
|
||||
any checks on clients in mynetworks (primarily, to avoid problems
|
||||
with buggy SMTP implementations in network appliances). The logging
|
||||
function alone is already useful for research.
|
||||
|
||||
352
RELEASE_NOTES-2.9
Normal file
352
RELEASE_NOTES-2.9
Normal file
|
|
@ -0,0 +1,352 @@
|
|||
The stable Postfix release is called postfix-2.9.x where 2=major
|
||||
release number, 9=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-2.10-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.7 or earlier, read RELEASE_NOTES-2.8
|
||||
before proceeding.
|
||||
|
||||
Major changes - critical
|
||||
------------------------
|
||||
|
||||
[Incompat 20110321] You need to "postfix reload" after upgrade from
|
||||
snapshot 20110320 or earlier. The hash_queue_names algorithm was
|
||||
changed to provide better performance with long queue IDs.
|
||||
|
||||
[Incompat 20110313] Use "postfix reload" after "make upgrade" on a
|
||||
running Postfix system. This is needed because the protocol between
|
||||
postscreen(8) and dnsblog(8) has changed.
|
||||
|
||||
Major changes - library API
|
||||
---------------------------
|
||||
|
||||
[Incompat 20110130] The VSTREAM error flags are now split into
|
||||
separate read and write error flags. As a result of this change,
|
||||
all programs that use Postfix VSTREAMs MUST be recompiled.
|
||||
|
||||
Major changes - compatibility
|
||||
-----------------------------
|
||||
|
||||
[Incompat 20111012] For consistency with the SMTP standard, the
|
||||
(client-side) smtp_line_length_limit default value was increased
|
||||
from 990 characters to 999 (i.e. 1000 characters including <CR><LF>).
|
||||
Specify "smtp_line_length_limit = 990" to restore historical Postfix
|
||||
behavior.
|
||||
|
||||
[Incompat 20111012] To simplify integration with third-party
|
||||
applications, the Postfix sendmail command now always transforms
|
||||
all input lines ending in <CR><LF> into UNIX format (lines ending
|
||||
in <LF>). Specify "sendmail_fix_line_endings = strict" to restore
|
||||
historical Postfix behavior (i.e. convert all input lines ending
|
||||
in <CR><LF> only if the first line ends in <CR><LF>).
|
||||
|
||||
[Incompat 20111106] To work around broken remote SMTP servers, the
|
||||
Postfix SMTP client by default no longer appends the "AUTH=<>"
|
||||
option to the MAIL FROM command. Specify "smtp_send_dummy_mail_auth
|
||||
= yes" to restore the old behavior.
|
||||
|
||||
Major changes - gradual degradation
|
||||
-----------------------------------
|
||||
|
||||
[Incompat 20120114] Logfile-based alerting systems may need to be
|
||||
updated to look for "error" messages in addition to "fatal" messages.
|
||||
Specify "daemon_table_open_error_is_fatal = yes" to get the historical
|
||||
behavior (immediate termination with "fatal" message).
|
||||
|
||||
[Feature 20120114] Instead of terminating immediately with a "fatal"
|
||||
message when a database file can't be opened, a Postfix daemon
|
||||
program now logs an "error" message, and continues execution with
|
||||
reduced functionality. For the sake of sanity, the number of
|
||||
"errors" over the life of a process is limited to 13.
|
||||
|
||||
Features that don't depend on the unavailable table will continue
|
||||
to work; attempts to use features that depend on the table will
|
||||
fail, and will be logged with a "warning" message.
|
||||
|
||||
[Feature 20120108] Instead of terminating with a fatal error, the
|
||||
LDAP, *SQL and memcache clients now handle table lookup errors in
|
||||
the "domain" feature, instead of terminating with a fatal error.
|
||||
|
||||
[Feature 20120102] Degrade gradually when some or all network
|
||||
protocols specified with inet_protocols are unavailable, instead
|
||||
of terminating with a fatal error. This eliminates build errors on
|
||||
non-standard systems where opening an IPv4 socket results in an
|
||||
error, and on non-standard systems where opening an IPv6 socket
|
||||
results in an error. In the worst case, the master daemon will log
|
||||
a message that it disables all type "inet" services. This will still
|
||||
allow local submission and local delivery.
|
||||
|
||||
[Feature 20111222] Instead of terminating with a fatal error, the
|
||||
Postfix SMTP server now handles errors with database lookups in
|
||||
mynetworks, TLS client certificate tables, debug_peer_list,
|
||||
smtpd_client_event_limit_exceptions, permit_mx_backup_networks and
|
||||
local_header_rewrite_clients, and reports "server local data error"
|
||||
or "temporary lookup error".
|
||||
|
||||
[Feature 20111229] Instead of terminating with a fatal error, the
|
||||
trivial-rewrite server now handles errors with database lookups in
|
||||
virtual_alias_domains, relay_domains, virtual_mailbox_domains. This
|
||||
means fewer occasions where trivial-rewrite clients (such as the
|
||||
SMTP server) will appear to hang.
|
||||
|
||||
Major changes - long queue IDs
|
||||
------------------------------
|
||||
|
||||
Postfix 2.9 introduces support for non-repeating queue IDs (also
|
||||
used as queue file names). These names are encoded in a mix of upper
|
||||
case, lower case and decimal digit characters. Long queue IDs are
|
||||
disabled by default to avoid breaking tools that parse logfiles and
|
||||
that expect queue IDs with the smaller [A-F0-9] character set.
|
||||
|
||||
[Incompat 20110320] If you enable support for long queue file names,
|
||||
you need to be aware that these file names are not compatible with
|
||||
Postfix <= 2.8. If you must migrate back to Postfix <= 2.8, you
|
||||
must first convert all long queue file names into short names,
|
||||
otherwise the old Postfix version will complain.
|
||||
|
||||
The conversion procedure before migration to Postfix <= 2.8 is:
|
||||
|
||||
# postfix stop
|
||||
# postconf enable_long_queue_ids=no
|
||||
# postsuper
|
||||
|
||||
Run the postsuper command repeatedly until it no longer reports
|
||||
queue file name changes.
|
||||
|
||||
[Feature 20110320] Support for long, non-repeating, queue IDs (queue
|
||||
file names). The benefit of non-repeating names is simpler logfile
|
||||
analysis, and easier queue migration (if you don't merge different
|
||||
queues, there is no need to run "postsuper" to change queue file
|
||||
names that don't match their message file inode number).
|
||||
|
||||
Specify "enable_long_queue_ids = yes" to enable the feature. This
|
||||
does not change the names of existing queue files. See postconf(5)
|
||||
or postconf.5.html#enable_long_queue_ids for a detailed description
|
||||
of the differences with the old short queue IDs.
|
||||
|
||||
This changes new Postfix queue IDs from the short form 0FCEE9247A9
|
||||
into the longer form 3Ps0FS1Zhtz1PFjb, and changes new Message-ID
|
||||
header values from YYMMDDHHMMSS.queueid@myhostname into the shorter
|
||||
form queueid@myhostname.
|
||||
|
||||
Major changes - memcache
|
||||
------------------------
|
||||
|
||||
[Feature 20111209] memcache lookup and update support. This provides
|
||||
a way to share postscreen(8) or verify(8) caches between Postfix
|
||||
instances. See MEMCACHE_README and memcache_table(5) for details
|
||||
and limitations.
|
||||
|
||||
[Feature 20111213] Support for a persistent backup database in the
|
||||
memcache client. The memcache client updates the memcache whenever
|
||||
it looks up or modifies information in the persistent database.
|
||||
|
||||
Major changes - postconf
|
||||
------------------------
|
||||
|
||||
The postconf command was restructured - it now warns about unused
|
||||
parameter name=value settings in main.cf or master.cf (likely to
|
||||
be mistakes), it now understands "dynamic" parameter names such as
|
||||
parameters whose name depends on the name of a master.cf entry, and
|
||||
it can display main.cf and master.cf in a more user-friendly format.
|
||||
|
||||
[Feature 20120117] support for legacy database parameter names
|
||||
(main.cf parameter names that are generated by prepending a suffix
|
||||
to the database name).
|
||||
|
||||
[Feature 20111118] The "postconf -M" (display master.cf) command
|
||||
now supports filtering. For example, specify "postconf -M inet"
|
||||
to display only services that listen on the network.
|
||||
|
||||
[Feature 20111113] postconf support to warn about unused "name=value"
|
||||
entries in main.cf, and about unused "-o name=value" entries in
|
||||
master.cf. This should help to eliminate common errors with mis-typed
|
||||
names.
|
||||
|
||||
[Feature 20111108] postconf support for parameter names that are
|
||||
generated automatically from master.cf entries (delivery agents,
|
||||
spawn services), and for parameter names that are defined with
|
||||
main.cf smtpd_restriction_classes.
|
||||
|
||||
[Feature 20111106] "postconf -M" support to print master.cf entries,
|
||||
and "postconf -f" support to fold long main.cf or master.cf lines
|
||||
for human readability.
|
||||
|
||||
Major changes - trickle defense
|
||||
-------------------------------
|
||||
|
||||
[Feature 20110212] Support for per-record deadlines. These change
|
||||
the behavior of Postfix timeout parameters, from a time limit per
|
||||
read or write system call, to a time limit to send or receive a
|
||||
complete record (an SMTP command line, SMTP response line, SMTP
|
||||
message content line, or TLS protocol message). This limits the
|
||||
impact from hostile peers that trickle data one byte at a time.
|
||||
|
||||
The new configuration parameters and their default settings are:
|
||||
smtpd_per_record_deadline (normal: no, overload: yes),
|
||||
smtp_per_record_deadline (no), and lmtp_per_record_deadline (no).
|
||||
|
||||
Note: when per-record deadlines are enabled, a short time limit may
|
||||
cause problems with TLS over very slow network connections. The
|
||||
reason is that a TLS protocol message can be up to 16 kbytes long
|
||||
(with TLSv1), and that an entire TLS protocol message must be sent
|
||||
or received within the per-record deadline.
|
||||
|
||||
Per-record deadlines were introduced with postscreen(8) in Postfix
|
||||
2.8. This program does not receive mail, and therefore it has no
|
||||
problems with TLS over slow connections.
|
||||
|
||||
Major changes - postscreen
|
||||
--------------------------
|
||||
|
||||
[Feature 20111211] The proxymap(8) server can now be used to share
|
||||
postscreen(8) or verify(8) caches between Postfix instances. Support
|
||||
for proxymap-over-TCP, to share a Postfix database between hosts,
|
||||
is expected to be completed in the Postfix 2.10 development cycle.
|
||||
|
||||
[Feature 20111209] memcache lookup and update support. This provides
|
||||
a way to share postscreen(8) or verify(8) caches between Postfix
|
||||
instances.
|
||||
|
||||
[Feature 20110228] postscreen(8) support to force remote SMTP clients
|
||||
to implement proper MX lookup policy. By listening on both primary
|
||||
and backup MX addresses, postscreen(8) can deny the temporary
|
||||
whitelist status to clients that connect only to backup MX hosts,
|
||||
and prevent them from talking to a Postfix SMTP server process.
|
||||
|
||||
Example: when 1.2.3.4 is a local backup IP address, specify
|
||||
"postscreen_whitelist_interfaces = !1.2.3.4 static:all".
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Incompat 20111205] Postfix now logs the result of successful TLS
|
||||
negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
|
||||
and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
|
||||
other minor differences.
|
||||
|
||||
[Feature 20111205] Support for TLS public key fingerprint matching
|
||||
in the Postfix SMTP client (in smtp_tls_policy_maps) and server (in
|
||||
check_ccert access maps). Public key fingerprints are inherently
|
||||
more specific than fingerprints over the entire certificate.
|
||||
|
||||
[Feature 20111205] Revision of Postfix TLS logging. The main
|
||||
difference is that Postfix now logs the result of successful TLS
|
||||
negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
|
||||
and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
|
||||
other minor differences.
|
||||
|
||||
Major changes - sasl authentication
|
||||
-----------------------------------
|
||||
|
||||
[Incompat 20111218] To support external SASL authentication, e.g.,
|
||||
in an NGINX proxy daemon, the Postfix SMTP server now always checks
|
||||
the smtpd_sender_login_maps table, even without having
|
||||
"smtpd_sasl_auth_enable = yes" in main.cf.
|
||||
|
||||
[Feature 20111218] Support for external SASL authentication via the
|
||||
XCLIENT command. This is used to accept SASL authentication from
|
||||
an SMTP proxy such as NGINX. This support works even without having
|
||||
to specify "smtpd_sasl_auth_enable = yes" in main.cf.
|
||||
|
||||
[Incompat 20111106] To work around broken remote SMTP servers, the
|
||||
Postfix SMTP client by default no longer appends the "AUTH=<>"
|
||||
option to the MAIL FROM command. Specify "smtp_send_dummy_mail_auth
|
||||
= yes" to restore the old behavior.
|
||||
|
||||
Major changes - large file support
|
||||
----------------------------------
|
||||
|
||||
[Feature 20110219] Postfix now uses long integers for message_size_limit,
|
||||
mailbox_size_limit and virtual_mailbox_limit. On LP64 systems (64-bit
|
||||
long and pointer, but 32-bit integer), these limits can now exceed
|
||||
2GB.
|
||||
|
||||
Major changes - ipv6
|
||||
--------------------
|
||||
|
||||
[Incompat 20110918] The following changes were made in default
|
||||
settings, in preparation for general availability of IPv6:
|
||||
|
||||
- The default inet_protocols value is now "all" instead of "ipv4",
|
||||
meaning use both IPv4 and IPv6.
|
||||
|
||||
To avoid an unexpected loss of performance for sites without
|
||||
global IPv6 connectivity, the commands "make upgrade" and "postfix
|
||||
upgrade-configuration" now append "inet_protocols = ipv4" to
|
||||
main.cf when no explicit inet_protocols setting is already present.
|
||||
This workaround will be removed in a future release.
|
||||
|
||||
- The default smtp_address_preference value is now "any" instead
|
||||
of "ipv6", meaning choose randomly between IPv6 and IPv4. With
|
||||
this the Postfix SMTP client will have more success delivering
|
||||
mail to sites that have problematic IPv6 configurations.
|
||||
|
||||
Major changes - address verification
|
||||
------------------------------------
|
||||
|
||||
[Feature 20111211] The proxymap(8) server can now be used to share
|
||||
postscreen(8) or verify(8) caches between Postfix instances. Support
|
||||
for proxymap-over-TCP, to share a Postfix database between hosts,
|
||||
is expected to be completed in the Postfix 2.10 development cycle.
|
||||
|
||||
[Feature 20111209] memcache lookup and update support. This provides
|
||||
a way to share postscreen(8) or verify(8) caches between Postfix
|
||||
instances.
|
||||
|
||||
[Feature 20111203] Support for time-dependent sender addresses
|
||||
of address verification probes. The default address, double-bounce,
|
||||
may end up on spammer blacklists. Although Postfix discards mail
|
||||
for this address, such mail still uses up network bandwidth and
|
||||
server resources. Specify an address_verify_sender_ttl value of
|
||||
several hours or more to frustrate address harvesting.
|
||||
|
||||
Major changes - session transcript notification
|
||||
-----------------------------------------------
|
||||
|
||||
[Incompat 20120114] By default the Postfix SMTP server no longer
|
||||
reports transcripts of sessions where a client command is rejected
|
||||
because a lookup table is unavailable. Postfix now implements gradual
|
||||
degradation, for example, the SMTP server keeps running instead of
|
||||
terminating with a fatal error. This change in error handling would
|
||||
result in a very large number of "transcript of session" email
|
||||
notifications when an LDAP or *SQL server goes down).
|
||||
|
||||
To receive such reports, add the new "data" class to the notify_classes
|
||||
parameter value. The reports will be sent to the error_notice_recipient
|
||||
address as before. This class is also used by the Postfix SMTP
|
||||
client to report about sessions that fail because a table is
|
||||
unavailable.
|
||||
|
||||
Major changes - logging
|
||||
----------------------------------------
|
||||
|
||||
[Incompat 20120114] Logfile-based alerting systems may need to be
|
||||
updated to look for "error" messages in addition to "fatal" messages.
|
||||
Specify "daemon_table_open_error_is_fatal = yes" to get the historical
|
||||
behavior (immediate termination with "fatal" message).
|
||||
|
||||
[Incompat 20111214] Logfile-based analysis tools may need to be
|
||||
updated. The submission and smtps examples in the sample master.cf
|
||||
file were updated to make their logging easier to distinguish.
|
||||
|
||||
See the source file pflogsumm_quickfix.txt for a "quick fix".
|
||||
|
||||
[Incompat 20111205] Postfix now logs the result of successful TLS
|
||||
negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
|
||||
and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
|
||||
other minor differences.
|
||||
|
||||
[Incompat 20110219] The Postfix SMTP and QMQP servers now log
|
||||
"hostname X does not resolve to address Y", when a "reverse hostname"
|
||||
lookup result does not resolve to the client IP address. Until now
|
||||
these servers logged "Y: hostname X verification failed" or "Y:
|
||||
address not listed for hostname X" which people found confusing.
|
||||
628
RELEASE_NOTES-3.0
Normal file
628
RELEASE_NOTES-3.0
Normal file
|
|
@ -0,0 +1,628 @@
|
|||
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.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, while Postfix daemons log
|
||||
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 concatenates non-empty
|
||||
results, 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 - position-independent executables
|
||||
------------------------------------------------
|
||||
|
||||
[Feature 20150205] Preliminary support for building position-independent
|
||||
executables (PIE), tested on Fedora Core 20, Ubuntu 14.04, FreeBSD
|
||||
9 and 10, and NetBSD 6. Specify:
|
||||
|
||||
$ make makefiles pie=yes ...other arguments...
|
||||
|
||||
On some systems, PIE is used by the ASLR exploit mitigation technique
|
||||
(ASLR = Address-Space Layout Randomization). Whether specifying
|
||||
"pie=yes" has any effect at all depends on the compiler. Reportedly,
|
||||
some compilers always produce PIE executables.
|
||||
|
||||
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, while Postfix daemons log
|
||||
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.
|
||||
186
RELEASE_NOTES-3.1
Normal file
186
RELEASE_NOTES-3.1
Normal file
|
|
@ -0,0 +1,186 @@
|
|||
This is the Postfix 3.1 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.1.x where 3=major
|
||||
release number, 1=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.2-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.11 or earlier, read RELEASE_NOTES-3.0
|
||||
before proceeding.
|
||||
|
||||
Major changes - address verification safety
|
||||
-------------------------------------------
|
||||
|
||||
[Feature 20151227] The new address_verify_pending_request_limit
|
||||
parameter introduces a safety limit for the number of address
|
||||
verification probes in the active queue. The default limit is 1/4
|
||||
of the active queue maximum size. The queue manager enforces the
|
||||
limit by tempfailing probe messages that exceed the limit. This
|
||||
design avoids dependencies on global counters that get out of sync
|
||||
after a process or system crash.
|
||||
|
||||
Tempfailing verify requests is not as bad as one might think. The
|
||||
Postfix verify cache proactively updates active addresses weeks
|
||||
before they expire. The address_verify_pending_request_limit affects
|
||||
only unknown addresses, and inactive addresses that have expired
|
||||
from the address verify cache (by default, after 31 days).
|
||||
|
||||
Major changes - json support
|
||||
----------------------------
|
||||
|
||||
[Feature 20151129] Machine-readable, JSON-formatted queue listing
|
||||
with "postqueue -j" (no "mailq" equivalent). The output is a stream
|
||||
of JSON objects, one per queue file. To simplify parsing, each
|
||||
JSON object is formatted as one text line followed by one newline
|
||||
character. See the postqueue(1) manpage for a detailed description
|
||||
of the output format.
|
||||
|
||||
Major changes - milter support
|
||||
------------------------------
|
||||
|
||||
[Feature 20150523] The milter_macro_defaults feature provides an
|
||||
optional list of macro name=value pairs. These specify default
|
||||
values for Milter macros when no value is available from the SMTP
|
||||
session context.
|
||||
|
||||
For example, with "milter_macro_defaults = auth_type=TLS", the
|
||||
Postfix SMTP server will send an auth_type of "TLS" to a Milter,
|
||||
unless the remote client authenticates with SASL.
|
||||
|
||||
This feature was originally implemented for a submission service
|
||||
that may authenticate clients with a TLS certificate, without having
|
||||
to make changes to the code that implements TLS support.
|
||||
|
||||
Major changes - output rate control
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20150710] Destination-independent delivery rate delay
|
||||
|
||||
Support to enforce a destination-independent delay between email
|
||||
deliveries. The following example inserts 20 seconds of delay
|
||||
between all deliveries with the SMTP transport, limiting the delivery
|
||||
rate to at most three messages per minute.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtp_transport_rate_delay = 20s
|
||||
|
||||
For details, see the description of default_transport_rate_delay
|
||||
and transport_transport_rate_delay in the postconf(5) manpage.
|
||||
|
||||
Major changes - postscreen dnsbl
|
||||
--------------------------------
|
||||
|
||||
[Feature 20150710] postscreen support for the TTL of DNSBL and DNSWL
|
||||
lookup results
|
||||
|
||||
Historically, the default setting "postscreen_dnsbl_ttl = 1h" assumes
|
||||
that a "not found" result from a DNSBL server will be valid for one
|
||||
hour. This may have been adequate five years ago when postscreen
|
||||
was first implemented, but nowadays, that one hour can result in
|
||||
missed opportunities to block new spambots.
|
||||
|
||||
To address this, postscreen now respects the TTL of DNSBL "not
|
||||
found" replies, as well as the TTL of DNSWL replies (both "found"
|
||||
and "not found"). The TTL for a "not found" reply is determined
|
||||
according to RFC 2308 (the TTL of an SOA record in the reply).
|
||||
|
||||
Support for DNSBL or DNSWL reply TTL values is controlled by two
|
||||
configuration parameters:
|
||||
|
||||
postscreen_dnsbl_min_ttl (default: 60 seconds).
|
||||
|
||||
This parameter specifies a minimum for the amount of time that
|
||||
a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
|
||||
This prevents an excessive number of postscreen cache updates
|
||||
when a DNSBL or DNSWL server specifies a very small reply TTL.
|
||||
|
||||
postscreen_dnsbl_max_ttl (default: $postscreen_dnsbl_ttl or 1 hour)
|
||||
|
||||
This parameter specifies a maximum for the amount of time that
|
||||
a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
|
||||
This prevents cache pollution when a DNSBL or DNSWL server
|
||||
specifies a very large reply TTL.
|
||||
|
||||
The postscreen_dnsbl_ttl parameter is now obsolete, and has become
|
||||
the default value for the new postscreen_dnsbl_max_ttl parameter.
|
||||
|
||||
Major changes - sasl auth safety
|
||||
--------------------------------
|
||||
|
||||
[Feature 20151031] New "smtpd_client_auth_rate_limit" feature, to
|
||||
enforce an optional rate limit on AUTH commands per SMTP client IP
|
||||
address. Similar to other smtpd_client_*_rate_limit features, this
|
||||
enforces a limit on the number of requests per $anvil_rate_time_unit.
|
||||
|
||||
Major changes - smtpd policy
|
||||
----------------------------
|
||||
|
||||
[Feature 20150913] New SMTPD policy service attribute "policy_context",
|
||||
with a corresponding "smtpd_policy_service_policy_context" configuration
|
||||
parameter. Originally, this was implemented to share the same SMTPD
|
||||
policy service endpoint among multiple check_policy_service clients.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Feature 20160207] A new "postfix tls" command to quickly enable
|
||||
opportunistic TLS in the Postfix SMTP client or server, and to
|
||||
manage SMTP server keys and certificates, including certificate
|
||||
signing requests and TLSA DNS records for DANE. See the postfix-tls(1)
|
||||
manpage for a detailed description.
|
||||
|
||||
[Feature 20160103] The Postfix SMTP client by default enables DANE
|
||||
policies when an MX host has a (DNSSEC) secure TLSA DNS record,
|
||||
even if the MX DNS record was obtained with insecure lookups. The
|
||||
existence of a secure TLSA record implies that the host wants to
|
||||
talk TLS and not plaintext. For details see the
|
||||
smtp_tls_dane_insecure_mx_policy configuration parameter.
|
||||
|
||||
[Incompat 20150721] As of the middle of 2015, all supported Postfix
|
||||
releases no longer enable "export" grade ciphers for opportunistic
|
||||
TLS, and no longer use the deprecated SSLv2 and SSLv3 protocols for
|
||||
mandatory or opportunistic TLS.
|
||||
|
||||
These changes are very unlikely to cause problems with server-to-server
|
||||
communication over the Internet, but they may result in interoperability
|
||||
problems with ancient client or server implementations on internal
|
||||
networks. To address this problem, you can revert the changes with:
|
||||
|
||||
Postfix SMTP client settings:
|
||||
|
||||
lmtp_tls_ciphers = export
|
||||
smtp_tls_ciphers = export
|
||||
lmtp_tls_protocols = !SSLv2
|
||||
smtp_tls_protocols = !SSLv2
|
||||
lmtp_tls_mandatory_protocols = !SSLv2
|
||||
smtp_tls_mandatory_protocols = !SSLv2
|
||||
|
||||
Postfix SMTP server settings:
|
||||
|
||||
smtpd_tls_ciphers = export
|
||||
smtpd_tls_protocols =
|
||||
smtpd_tls_mandatory_protocols = !SSLv2
|
||||
|
||||
These settings, if put in main.cf, affect all Postfix SMTP client
|
||||
or server communication, which may be undesirable. To be more
|
||||
selective, use "-o name=value" parameter overrides on specific
|
||||
services in master.cf. Execute the command "postfix reload" to make
|
||||
the changes effective.
|
||||
|
||||
[Incompat 20150719] The default Diffie-Hellman non-export prime was
|
||||
updated from 1024 to 2048 bits, because SMTP clients are starting
|
||||
to reject TLS handshakes with primes smaller than 2048 bits.
|
||||
|
||||
Historically, this prime size is not negotiable, and each site needs
|
||||
to determine which prime size works best for the majority of its
|
||||
clients. See FORWARD_SECRECY_README for some hints in the quick-start
|
||||
section.
|
||||
|
||||
180
RELEASE_NOTES-3.2
Normal file
180
RELEASE_NOTES-3.2
Normal file
|
|
@ -0,0 +1,180 @@
|
|||
This is the Postfix 3.2 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.2.x where 3=major
|
||||
release number, 2=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.3-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 3.0 or earlier, read RELEASE_NOTES-3.1
|
||||
before proceeding.
|
||||
|
||||
Invisible changes
|
||||
-----------------
|
||||
|
||||
In addition to the visible changes described below, there is an
|
||||
ongoing overhaul of low-level code. With each change come updated
|
||||
tests to ensure that future changes will not 'break' compatibility
|
||||
with past behavior.
|
||||
|
||||
Major changes - address mapping
|
||||
-------------------------------
|
||||
|
||||
[Feature 20170128] Postfix 3.2 fixes the handling of address
|
||||
extensions with email addresses that contain spaces. For example,
|
||||
the virtual_alias_maps, canonical_maps, and smtp_generic_maps
|
||||
features now correctly propagate an address extension from "aa
|
||||
bb+ext"@example.com to "cc dd+ext"@other.example, instead of
|
||||
producing broken output.
|
||||
|
||||
Major changes - header/body_checks
|
||||
----------------------------------
|
||||
|
||||
[Feature 20161008] "PASS" and "STRIP" actions in header/body_checks.
|
||||
"STRIP" is similar to "IGNORE" but also logs the action, and "PASS"
|
||||
disables header, body, and Milter inspection for the remainder of
|
||||
the message content. Contributed by Hobbit.
|
||||
|
||||
Major changes - log analysis
|
||||
----------------------------
|
||||
|
||||
[Feature 20160330] The collate.pl script by Viktor Dukhovni for
|
||||
grouping Postfix logfile records into "sessions" based on queue ID
|
||||
and process ID information. It's in the auxiliary/collate directory
|
||||
of the Postfix source tree.
|
||||
|
||||
Major changes - maps support
|
||||
----------------------------
|
||||
|
||||
[Feature 20160527] Postfix 3.2 cidr tables support if/endif and
|
||||
negation (by prepending ! to a pattern), just like regexp and pcre
|
||||
tables. The primarily purpose is to improve readability of complex
|
||||
tables. See the cidr_table(5) manpage for syntax details.
|
||||
|
||||
[Incompat 20160925] In the Postfix MySQL database client, the default
|
||||
option_group value has changed to "client", to enable reading of
|
||||
"client" option group settings in the MySQL options file. This fixes
|
||||
a "not found" problem with Postfix queries that contain UTF8-encoded
|
||||
non-ASCII text. Specify an empty option_group value (option_group
|
||||
=) to get backwards-compatible behavior.
|
||||
|
||||
[Feature 20161217] Stored-procedure support for MySQL databases.
|
||||
Contributed by John Fawcett. See mysql_table(5) for instructions.
|
||||
|
||||
[Feature 20170128] The postmap command, and the inline: and texthash:
|
||||
maps now support spaces in left-hand field of the lookup table
|
||||
"source text". Use double quotes (") around a left-hand field that
|
||||
contains spaces, and use backslash (\) to protect embedded quotes
|
||||
in a left-hand field. There is no change in the processing of the
|
||||
right-hand field.
|
||||
|
||||
Major changes - milter support
|
||||
------------------------------
|
||||
|
||||
[Feature 20160611] The Postfix SMTP server local IP address and
|
||||
port are available in the policy delegation protocol (attribute
|
||||
names: server_address, server_port), in the Milter protocol (macro
|
||||
names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
|
||||
(attribute names: DESTADDR, DESTPORT).
|
||||
|
||||
[Feature 20161024] smtpd_milter_maps support for per-client Milter
|
||||
configuration that overrides smtpd_milters, and that has the same
|
||||
syntax. A lookup result of "DISABLE" turns off Milter support. See
|
||||
MILTER_README.html for details.
|
||||
|
||||
Major changes - policy delegation
|
||||
---------------------------------
|
||||
|
||||
[Feature 20160611] The Postfix SMTP server local IP address and
|
||||
port are available in the policy delegation protocol (attribute
|
||||
names: server_address, server_port), in the Milter protocol (macro
|
||||
names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
|
||||
(attribute names: DESTADDR, DESTPORT).
|
||||
|
||||
Major changes - postqueue
|
||||
-------------------------
|
||||
|
||||
[Incompat 20170129] The postqueue command no longer forces all
|
||||
message arrival times to be reported in UTC. To get the old behavior,
|
||||
set TZ=UTC in main.cf:import_environment (this override is not
|
||||
recommended, as it affects all Postfix utities and daemons).
|
||||
|
||||
Major changes - safety
|
||||
----------------------
|
||||
|
||||
[Incompat 20161227] For safety reasons, the sendmail -C option must
|
||||
specify an authorized directory: the default configuration directory,
|
||||
a directory that is listed in the default main.cf file with
|
||||
alternate_config_directories or multi_instance_directories, or the
|
||||
command must be invoked with root privileges (UID 0 and EUID 0).
|
||||
This mitigates a recurring problem with the PHP mail() function.
|
||||
|
||||
Major changes - sasl
|
||||
--------------------
|
||||
|
||||
[Feature 20160625] The Postfix SMTP server now passes remote client
|
||||
and local server network address and port information to the Cyrus
|
||||
SASL library. Build with ``make makefiles "CCARGS=$CCARGS
|
||||
-DNO_IP_CYRUS_SASL_AUTH"'' for backwards compatibility.
|
||||
|
||||
Major changes - smtputf8
|
||||
------------------------
|
||||
|
||||
[Feature 20161103] Postfix 3.2 disables the 'transitional' compatibility
|
||||
between the IDNA2003 and IDNA2008 standards for internationalized
|
||||
domain names (domain names beyond the limits of US-ASCII).
|
||||
|
||||
This change makes Postfix behavior consistent with contemporary web
|
||||
browsers. It affects the handling of some corner cases such as
|
||||
German sz and Greek zeta. See http://unicode.org/cldr/utility/idna.jsp
|
||||
for more examples.
|
||||
|
||||
Specify "enable_idna2003_compatibility = yes" to restore historical
|
||||
behavior (but keep in mind that the rest of the world may not make
|
||||
that same choice).
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Feature 20160828] Fixes for deprecated OpenSSL 1.1.0 API features,
|
||||
so that Postfix will build without depending on backwards-compatibility
|
||||
support.
|
||||
|
||||
[Incompat 20161204] Postfix 3.2 removes tentative features that
|
||||
were implemented before the DANE spec was finalized:
|
||||
|
||||
- Support for certificate usage PKIX-EE(1),
|
||||
|
||||
- The ability to disable digest agility (Postfix now behaves as if
|
||||
"tls_dane_digest_agility = on"), and
|
||||
|
||||
- The ability to disable support for "TLSA 2 [01] [12]" records
|
||||
that specify the digest of a trust anchor (Postfix now behaves
|
||||
as if "tls_dane_trust_anchor_digest_enable = yes).
|
||||
|
||||
[Feature 20161217] Postfix 3.2 enables elliptic curve negotiation
|
||||
with OpenSSL >= 1.0.2. This changes the default smtpd_tls_eecdh_grade
|
||||
setting to "auto", and introduces a new parameter tls_eecdh_auto_curves
|
||||
with the names of curves that may be negotiated.
|
||||
|
||||
The default tls_eecdh_auto_curves setting is determined at compile
|
||||
time, and depends on the Postfix and OpenSSL versions. At runtime,
|
||||
Postfix will skip curve names that aren't supported by the OpenSSL
|
||||
library.
|
||||
|
||||
Major changes - xclient
|
||||
-----------------------
|
||||
|
||||
[Feature 20160611] The Postfix SMTP server local IP address and
|
||||
port are available in the policy delegation protocol (attribute
|
||||
names: server_address, server_port), in the Milter protocol (macro
|
||||
names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
|
||||
(attribute names: DESTADDR, DESTPORT).
|
||||
|
||||
124
RELEASE_NOTES-3.3
Normal file
124
RELEASE_NOTES-3.3
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
This is the Postfix 3.3 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.3.x where 3=major
|
||||
release number, 3=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.4-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 3.1 or earlier, read RELEASE_NOTES-3.2
|
||||
before proceeding.
|
||||
|
||||
License change
|
||||
---------------
|
||||
|
||||
This software is distributed with a dual license: in addition to the
|
||||
historical IBM Public License 1.0, it is now also distributed with the
|
||||
more recent Eclipse Public License 2.0. Recipients can choose to take
|
||||
the software under the license of their choice. Those who are more
|
||||
comfortable with the IPL can continue with that license.
|
||||
|
||||
Major changes - compatibility safety net
|
||||
----------------------------------------
|
||||
|
||||
[20180106] With compatibility_level < 1, the Postfix SMTP server
|
||||
now warns for mail that would be blocked by the Postfix 2.10
|
||||
smtpd_relay_restrictions feature, without blocking that mail. This
|
||||
extends the compatibility safety net for sites that upgrade from
|
||||
earlier Postfix versions (questions on the postfix-users list show
|
||||
there is a steady trickle). See COMPATIBILITY_README for details.
|
||||
|
||||
Major changes - configuration
|
||||
-----------------------------
|
||||
|
||||
[20170617] The postconf command now warns about unknown parameter
|
||||
names in a Postfix database configuration file. As with other unknown
|
||||
parameter names, these warnings can help to find typos early.
|
||||
|
||||
[20180113] New read-only service_name parameter that contains the
|
||||
master.cf service name of a Postfix daemon process (it that is empty
|
||||
in a non-daemon process). This can make Postfix SMTP server logging
|
||||
logging distinct by setting the syslog_name in master.cf with "-o
|
||||
syslog_name=postfix/$service_name" for the "submission" and "smtps"
|
||||
services, and can make Postfix SMTP client distinct by setting "-o
|
||||
syslog_name=postfix/$service_name" for the "relay" service.
|
||||
|
||||
Major changes - container support
|
||||
---------------------------------
|
||||
|
||||
[20171218] Preliminary support to run Postfix in the foreground,
|
||||
with "postfix start-fg". This requires that Postfix multi-instance
|
||||
support is disabled. To receive Postfix syslog information on the
|
||||
container's host, mount the host's /dev/log socket inside the
|
||||
container (example: "docker run -v /dev/log:/dev/log ..."), and
|
||||
specify a distinct Postfix "syslog_name" prefix that identifies the
|
||||
logging from the Postfix instance. Postfix does not log systemd
|
||||
events.
|
||||
|
||||
Major changes - database support
|
||||
---------------------------------
|
||||
|
||||
[20170617] The postconf command warns about unknown parameter names
|
||||
in a Postfix database configuration file.
|
||||
|
||||
[20171227] The pgsql_table(5) hosts parameter now supports the
|
||||
postgresql:// URI syntax. Contributed by Magosányi Árpád.
|
||||
|
||||
Major changes - header format
|
||||
-----------------------------
|
||||
|
||||
[20180010] This release changes the format of 'full name' information
|
||||
in Postfix-generated From: headers, when a local program such as
|
||||
/bin/mail submits a message without From: header.
|
||||
|
||||
Postfix-generated From: headers with 'full name' information are
|
||||
now formatted as "From: name <address>" by default. Specify
|
||||
"header_from_format = obsolete" to get the earlier form "From:
|
||||
address (name)". See the postconf(5) manpage for more details.
|
||||
|
||||
Major changes - invisible changes
|
||||
---------------------------------
|
||||
|
||||
[20170617] Additional paranoia in the VSTRING implementation: a
|
||||
null byte after the end of vstring buffers (this is a safety net
|
||||
so that C-style string operations won't scribble past the end);
|
||||
earlier detection of bad length and precision format string specifiers
|
||||
(these are the result of programming error, as Postfix format strings
|
||||
cannot be specified externally).
|
||||
|
||||
Major changes - milter support
|
||||
------------------------------
|
||||
|
||||
[20171223] Milter applications can now send RET and ENVID parameters
|
||||
in SMFIR_CHGFROM (change envelope sender) requests.
|
||||
|
||||
Major changes - mixed IPv6/IPv4 support
|
||||
---------------------------------------
|
||||
|
||||
[20170505] Workaround for mail delivery problems when 1) both Postfix
|
||||
IPv6 and IPv4 support are enabled, 2) some destination announces
|
||||
more primary IPv6 MX addresses than primary IPv4 MX addresses, 3)
|
||||
the destination is unreachable over IPv6, and 4) Postfix runs into
|
||||
the smtp_mx_address_limit before it can try to deliver over IPv4.
|
||||
|
||||
When both Postfix IPv6 and IPv4 support are enabled, the Postfix
|
||||
SMTP client will now relax MX preferences so that it can schedule
|
||||
similar numbers of IPv4 and IPv6 destination addresses. This ensures
|
||||
that an IPv6 connectivity problem will not prevent mail from being
|
||||
delivered over IPv4 (and vice versa). Specify "smtp_balance_inet_protocols
|
||||
= no" to disable this workaround.
|
||||
|
||||
Major changes - xclient
|
||||
-----------------------
|
||||
|
||||
[20171218] The Postfix SMTP server now allows the XCLIENT command
|
||||
before STARTTLS when TLS is required. This is useful for servers
|
||||
that run behind a reverse proxy server such as nginx.
|
||||
|
||||
208
RELEASE_NOTES-3.4
Normal file
208
RELEASE_NOTES-3.4
Normal file
|
|
@ -0,0 +1,208 @@
|
|||
This is the Postfix 3.4 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.4.x where 3=major
|
||||
release number, 4=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.5-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 3.2 or earlier, read RELEASE_NOTES-3.3
|
||||
before proceeding.
|
||||
|
||||
License change
|
||||
---------------
|
||||
|
||||
This software is distributed with a dual license: in addition to the
|
||||
historical IBM Public License 1.0, it is now also distributed with the
|
||||
more recent Eclipse Public License 2.0. Recipients can choose to take
|
||||
the software under the license of their choice. Those who are more
|
||||
comfortable with the IPL can continue with that license.
|
||||
|
||||
Summary of changes
|
||||
------------------
|
||||
|
||||
Incompatible changes, bdat support, containers, database support,
|
||||
logging, safety, tls connection pooling, tls support, usability,
|
||||
|
||||
Incompatible changes
|
||||
--------------------
|
||||
|
||||
[Incompat 20180826] The Postfix SMTP server announces CHUNKING (BDAT
|
||||
command) by default. In the unlikely case that this breaks some
|
||||
important remote SMTP client, disable the feature as follows:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# The logging alternative:
|
||||
smtpd_discard_ehlo_keywords = chunking
|
||||
# The non-logging alternative:
|
||||
smtpd_discard_ehlo_keywords = chunking, silent_discard
|
||||
|
||||
See BDAT_README for more.
|
||||
|
||||
[Incompat 20190126] This introduces a new master.cf service 'postlog'
|
||||
with type 'unix-dgram' that is used by the new postlogd(8) daemon.
|
||||
Before backing out to an older Postfix version, edit the master.cf
|
||||
file and remove the postlog entry.
|
||||
|
||||
[Incompat 20190106] Postfix 3.4 drops support for OpenSSL 1.0.1
|
||||
(end-of-life was December 31, 2016) and all earlier releases.
|
||||
|
||||
[Incompat 20180701] To avoid performance loss under load, the
|
||||
tlsproxy(8) daemon now requires a zero process limit in master.cf
|
||||
(this setting is provided with the default master.cf file). By
|
||||
default, a tlsproxy(8) process will retire after several hours.
|
||||
|
||||
To set the tlsproxy process limit to zero:
|
||||
|
||||
# postconf -F tlsproxy/unix/process_limit=0
|
||||
# postfix reload
|
||||
|
||||
Major changes - bdat support
|
||||
--------------------
|
||||
|
||||
[Feature 20180826] Postfix SMTP server support for RFC 3030 CHUNKING
|
||||
(the BDAT command) without BINARYMIME, in both smtpd(8) and
|
||||
postscreen(8). This has no effect on Milters, smtpd_mumble_restrictions,
|
||||
and smtpd_proxy_filter. See BDAT_README for more.
|
||||
|
||||
Major changes - containers
|
||||
--------------------------
|
||||
|
||||
[Feature 20190126] Support for logging to file or stdout, instead
|
||||
of using syslog.
|
||||
|
||||
- Logging to file solves a usability problem for MacOS, and
|
||||
eliminates multiple problems with systemd-based systems.
|
||||
|
||||
- Logging to stdout is useful when Postfix runs in a container, as
|
||||
it eliminates a syslogd dependency.
|
||||
|
||||
See MAILLOG_README for configuration examples and logfile rotation.
|
||||
|
||||
[Feature 20180422] Better handling of undocumented(!) Linux behavior
|
||||
whether or not signals are delivered to a PID=1 process.
|
||||
|
||||
Major changes - database support
|
||||
--------------------------------
|
||||
|
||||
[Feature 20181105] Support for (key, list of filenames) in map
|
||||
source text.
|
||||
|
||||
- Currently, this feature is used only by tls_server_sni_maps.
|
||||
|
||||
- When a map is created from source with "postmap -F maptype:mapname",
|
||||
the command processes each key as usual and processes each value
|
||||
as a list of filenames, concatenates the content of those files
|
||||
(with one newline character in-between files), and stores an entry
|
||||
with (key, base64-encoded result).
|
||||
|
||||
- When a map is queried with "postmap -F -q ...", the command
|
||||
base64-decodes each value. It reports an error when a value is
|
||||
not in base64 form.
|
||||
|
||||
This "postmap -F -q ..." behavior also works when querying the
|
||||
memory-resident map types cidr:, inline:, pcre:, randmap:, regexp:,
|
||||
and static:. Postfix reads the files specified as table values,
|
||||
stores base64-encoded content, and base64-decodes content upon
|
||||
table lookup.
|
||||
|
||||
Internally, Postfix will turn on this behavior for lookups (not
|
||||
updates) when a map is opened with the DICT_FLAG_RHS_IS_FILE flag.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Feature 20190126] Support for logging to file or stdout, instead
|
||||
of using syslog.
|
||||
|
||||
- Logging to file solves a usability problem for MacOS, and
|
||||
eliminates multiple problems with systemd-based systems.
|
||||
|
||||
- Logging to stdout is useful when Postfix runs in a container, as
|
||||
it eliminates a syslogd dependency.
|
||||
|
||||
See MAILLOG_README for configuration examples and logfile rotation.
|
||||
|
||||
Major changes - safety
|
||||
----------------------
|
||||
|
||||
[Feature 20180623] Automatic retirement: dnsblog(8) and tlsproxy(8) process
|
||||
will now voluntarily retire after after max_idle*max_use, or some
|
||||
sane limit if either limit is disabled. Without this, a process
|
||||
could stay busy for days or more.
|
||||
|
||||
Major changes - tls connection pooling
|
||||
--------------------------------------
|
||||
|
||||
[Feature 20180617] Postfix SMTP client support for multiple deliveries
|
||||
per TLS-encrypted connection. This is primarily to improve mail
|
||||
delivery performance for destinations that throttle clients when
|
||||
they don't combine deliveries.
|
||||
|
||||
This feature is enabled with "smtp_tls_connection_reuse=yes" in
|
||||
main.cf, or with "tls_connection_reuse=yes" in smtp_tls_policy_maps.
|
||||
It supports all Postfix TLS security levels including dane and
|
||||
dane-only.
|
||||
|
||||
The implementation of TLS connection reuse relies on the same
|
||||
scache(8) service as used for delivering plaintext SMTP mail, the
|
||||
same tlsproxy(8) daemon as used by the postscreen(8) service for
|
||||
inbound connections, and relies on the same hints from the qmgr(8)
|
||||
daemon. It reuses the configuration parameters described in
|
||||
CONNECTION_CACHE_README.
|
||||
|
||||
The Postfix SMTP client now logs whether an SMTP-over-TLS connection
|
||||
is newly established ("TLS connection established") or whether the
|
||||
connection is reused ("TLS connection reused").
|
||||
|
||||
The following illustrates how TLS connections are reused:
|
||||
|
||||
Initial plaintext SMTP handshake:
|
||||
smtp(8) -> remote SMTP server
|
||||
|
||||
Reused SMTP/TLS connection, or new SMTP/TLS connection:
|
||||
smtp(8) -> tlsproxy(8) -> remote SMTP server
|
||||
|
||||
Cached SMTP/TLS connection:
|
||||
scache(8) -> tlsproxy(8) -> remote SMTP server
|
||||
|
||||
Major changes - tls support
|
||||
---------------------------
|
||||
|
||||
[Feature 20190106] SNI support in the Postfix SMTP server, the
|
||||
Postfix SMTP client, and in the tlsproxy(8) daemon (both server and
|
||||
client roles). See the postconf(5) documentation for the new
|
||||
tls_server_sni_maps and smtp_tls_servername parameters.
|
||||
|
||||
[Feature 20190106] Support for files that contain multiple (key,
|
||||
certificate, trust chain) instances. This was required to implement
|
||||
server-side SNI table lookups, but it also eliminates the need for
|
||||
separate cert/key files for RSA, DSA, Elliptic Curve, and so on.
|
||||
The file format is documented in the TLS_README sections "Server-side
|
||||
certificate and private key configuration" and "Client-side certificate
|
||||
and private key configuration", and in the postconf(5) documentation
|
||||
for the parameters smtp_tls_chain_files, smtpd_tls_chain_files,
|
||||
tlsproxy_client_chain_files, and tlsproxy_tls_chain_files.
|
||||
|
||||
Note: the command "postfix tls" does not yet support the new
|
||||
consolidated certificate chain format. If you switch to the new
|
||||
format, you'll need to manage your keys and certificates directly,
|
||||
rather than via postfix-tls(1).
|
||||
|
||||
Major changes - usability
|
||||
-------------------------
|
||||
|
||||
[Feature 20180812] Support for smtpd_reject_footer_maps (as well
|
||||
as the postscreen variant postscreen_reject_footer_maps) for more
|
||||
informative reject messages. This is indexed with the Postfix SMTP
|
||||
server response text, and overrides the footer specified with
|
||||
smtpd_reject_footer. One will want to use a pcre: or regexp: map
|
||||
with this.
|
||||
|
||||
157
RELEASE_NOTES-3.5
Normal file
157
RELEASE_NOTES-3.5
Normal file
|
|
@ -0,0 +1,157 @@
|
|||
This is the Postfix 3.5 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.5.x where 3=major
|
||||
release number, 5=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.6-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 3.3 or earlier, read RELEASE_NOTES-3.4
|
||||
before proceeding.
|
||||
|
||||
License change
|
||||
---------------
|
||||
|
||||
This software is distributed with a dual license: in addition to the
|
||||
historical IBM Public License 1.0, it is now also distributed with the
|
||||
more recent Eclipse Public License 2.0. Recipients can choose to take
|
||||
the software under the license of their choice. Those who are more
|
||||
comfortable with the IPL can continue with that license.
|
||||
|
||||
Major changes - multiple relayhost in SMTP
|
||||
------------------------------------------
|
||||
|
||||
[Feature 20200111] the Postfix SMTP and LMTP client support a list
|
||||
of nexthop destinations separated by comma or whitespace. These
|
||||
destinations will be tried in the specified order.
|
||||
|
||||
The list form can be specified in relayhost, transport_maps,
|
||||
default_transport, and sender_dependent_default_transport_maps.
|
||||
|
||||
Examples:
|
||||
/etc/postfix/main.cf:
|
||||
relayhost = foo.example, bar.example
|
||||
default_transport = smtp:foo.example, bar.example.
|
||||
|
||||
NOTE: this is an SMTP and LMTP client feature. It does not work for
|
||||
other Postfix delivery agents.
|
||||
|
||||
Major changes - certificate access
|
||||
----------------------------------
|
||||
|
||||
[Feature 20190517] Search order support for check_ccert_access.
|
||||
Search order support for other tables is in design (canonical_maps,
|
||||
virtual_alias_maps, transport_maps, etc.).
|
||||
|
||||
The following check_ccert_access setting uses the built-in search
|
||||
order: it first looks up the client certificate fingerprint, then
|
||||
the client certificate public-key fingerprint, and it stops when a
|
||||
decision is made.
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_mumble_restrictions =
|
||||
...
|
||||
check_ccert_access hash:/etc/postfix/ccert-access
|
||||
...
|
||||
|
||||
The following setting, with explicit search order, produces the
|
||||
exact same result:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_mumble_restrictions =
|
||||
...
|
||||
check_ccert_access {
|
||||
hash:/etc/postfix/ccert-access {
|
||||
search_order = cert_fingerprint, pubkey_fingerprint } }
|
||||
...
|
||||
|
||||
Support is planned for other certificate features.
|
||||
|
||||
Major changes - dovecot usability
|
||||
---------------------------------
|
||||
|
||||
[Feature 20190615] The SMTP+LMTP delivery agent can now prepend
|
||||
Delivered-To, X-Original-To and Return-Path headers, just like the
|
||||
pipe(8) and local(8) delivery agents.
|
||||
|
||||
This uses the "flags=DORX" command-line flags in master.cf. See the
|
||||
smtp(8) manpage for details.
|
||||
|
||||
This obsoletes the "lmtp_assume_final = yes" setting, and replaces
|
||||
it with "flags=...X...", for consistency with the pipe(8) delivery
|
||||
agent.
|
||||
|
||||
Major changes - forced expiration
|
||||
---------------------------------
|
||||
|
||||
[Feature 20200202] Support to force-expire email messages. This
|
||||
introduces new postsuper(1) command-line options to request expiration,
|
||||
and additional information in mailq(1) or postqueue(1) output.
|
||||
|
||||
The forced-to-expire status is stored in a queue file attribute.
|
||||
An expired message is returned to the sender when the queue manager
|
||||
attempts to deliver that message (note that Postfix will never
|
||||
deliver messages in the hold queue).
|
||||
|
||||
The postsuper(1) -e and -f options both set the forced-to-expire
|
||||
queue file attribute. The difference is that -f will also release
|
||||
a message if it is in the hold queue. With -e, such a message would
|
||||
not be returned to the sender until it is released with -f or -H.
|
||||
|
||||
In the mailq(1) or postqueue(1) -p output, a forced-to-expire message
|
||||
is indicated with # after the queue file name. In postqueue(1) JSON
|
||||
output, there is a new per-message field "forced_expire" (with value
|
||||
true or false) that shows the forced-to-expire status.
|
||||
|
||||
Major changes - haproxy2 protocol
|
||||
---------------------------------
|
||||
|
||||
[Feature 20200112] Support for the haproxy v2 protocol. The Postfix
|
||||
implementation supports TCP over IPv4 and IPv6, as well as non-proxied
|
||||
connections; the latter are typically used for heartbeat tests.
|
||||
|
||||
The haproxy v2 protocol introduces no additional Postfix configuration.
|
||||
The Postfix smtpd(8) and postscreen(8) daemons accept both v1 and
|
||||
v2 protocol versions.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Incompat 20191109] Postfix daemon processes now log the from= and
|
||||
to= addresses in external (quoted) form in non-debug logging (info,
|
||||
warning, etc.). This means that when an address localpart contains
|
||||
spaces or other special characters, the localpart will be quoted,
|
||||
for example:
|
||||
|
||||
from=<"name with spaces"@example.com>
|
||||
|
||||
Older Postfix versions would log the internal (unquoted) form:
|
||||
|
||||
from=<name with spaces@example.com>
|
||||
|
||||
The external and internal forms are identical for the vast majority
|
||||
of email addresses that contain no spaces or other special characters
|
||||
in the localpart.
|
||||
|
||||
Specify "info_log_address_format = internal" for backwards
|
||||
compatibility.
|
||||
|
||||
The logging in external form is consistent with the address form
|
||||
that Postfix 3.2 and later prefer for table lookups. It is therefore
|
||||
the more useful form for non-debug logging.
|
||||
|
||||
Major changes - IP address normalization
|
||||
----------------------------------------
|
||||
|
||||
[Incompat 20190427] Postfix now normalizes IP addresses received
|
||||
with XCLIENT, XFORWARD, or with the HaProxy protocol, for consistency
|
||||
with direct connections to Postfix. This may change the appearance
|
||||
of logging, and the way that check_client_access will match subnets
|
||||
of an IPv6 address.
|
||||
277
RELEASE_NOTES-3.6
Normal file
277
RELEASE_NOTES-3.6
Normal file
|
|
@ -0,0 +1,277 @@
|
|||
This is the Postfix 3.6 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.6.x where 3=major
|
||||
release number, 6=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.7-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 3.4 or earlier, read RELEASE_NOTES-3.5
|
||||
before proceeding.
|
||||
|
||||
License change
|
||||
---------------
|
||||
|
||||
This software is distributed with a dual license: in addition to the
|
||||
historical IBM Public License 1.0, it is now also distributed with the
|
||||
more recent Eclipse Public License 2.0. Recipients can choose to take
|
||||
the software under the license of their choice. Those who are more
|
||||
comfortable with the IPL can continue with that license.
|
||||
|
||||
Major changes - internal protocol identification
|
||||
------------------------------------------------
|
||||
|
||||
[Incompat 20200920] Internal protocols have changed. You need to
|
||||
"postfix stop" before updating, or before backing out to an earlier
|
||||
release, otherwise long-running daemons (pickup, qmgr, verify, tlsproxy,
|
||||
postscreen) may fail to communicate with the rest of Postfix, causing
|
||||
mail delivery delays until Postfix is restarted.
|
||||
|
||||
This change does not affect message files in Postfix queue directories,
|
||||
only the communication between running Postfix programs.
|
||||
|
||||
With this change, every Postfix internal service, including the postdrop
|
||||
command, announces the name of its protocol before doing any other I/O.
|
||||
Every Postfix client program, including the Postfix sendmail command,
|
||||
will verify that the protocol name matches what it is supposed to be.
|
||||
|
||||
The purpose of this change is to produce better error messages, for
|
||||
example, when someone configures the discard daemon as a bounce
|
||||
service in master.cf, or vice versa.
|
||||
|
||||
This change may break third-party programs that implement a
|
||||
Postfix-internal protocol such as qpsmtpd. Such programs have never
|
||||
been supported. Fortunately, this will be an easy fix: look at the
|
||||
first data from the cleanup daemon: if it is a protocol announcement,
|
||||
you're talking to Postfix 3.6 or later. That's the only real change.
|
||||
|
||||
Major changes - tls
|
||||
-------------------
|
||||
|
||||
[Incompat 20200705] The minimum supported OpenSSL version is 1.1.1,
|
||||
which will reach the end of life by 2023-09-11. Postfix 3.6 is
|
||||
expected to reach the end of support in 2025. Until then, Postfix
|
||||
will be updated as needed for compatibility with OpenSSL.
|
||||
|
||||
The default fingerprint digest has changed from md5 to sha256 (Postfix
|
||||
3.6 with compatibility_level >= 3.6). With a lower compatibility_level
|
||||
setting, Postfix defaults to using md5, and logs a warning when a Postfix
|
||||
configuration specifies no explicit digest type.
|
||||
|
||||
Export-grade Diffie-Hellman key exchange is no longer supported,
|
||||
and the tlsproxy_tls_dh512_param_file parameter is ignored,
|
||||
|
||||
[Feature 20200906] The tlstype.pl helper script by Viktor Dukhovni
|
||||
reports TLS information per message delivery. This processes output
|
||||
from the collate.pl script. See auxiliary/collate/README.tlstype and
|
||||
auxiliary/collate/tlstype.pl.
|
||||
|
||||
Major changes - compatibility level
|
||||
-----------------------------------
|
||||
|
||||
[Feature 20210109] Starting with Postfix version 3.6, the compatibility
|
||||
level is "3.6". In future Postfix releases, the compatibility level will
|
||||
be the Postfix version that introduced the last incompatible change. The
|
||||
level is formatted as 'major.minor.patch', where 'patch' is usually
|
||||
omitted and defaults to zero. Earlier compatibility levels are 0, 1 and 2.
|
||||
|
||||
This also introduces main.cf and master.cf support for the <=level,
|
||||
<level, and other operators to compare compatibility levels. With the
|
||||
standard <=, <, etc. operators, compatibility level 3.10 would be less
|
||||
than 3.9, which is undesirable.
|
||||
|
||||
Major changes - services(5) override
|
||||
------------------------------------
|
||||
|
||||
[Feature 20210418] Postfix no longer uses the services(5) database
|
||||
to look up the TCP ports for SMTP and LMTP services. Instead, this
|
||||
information is configured with the new known_tcp_ports configuration
|
||||
parameter (default: lmtp=24, smtp=25, smtps=submissions=465,
|
||||
submission=587). When a service is not specified in known_tcp_ports,
|
||||
Postfix will still query the services(5) database.
|
||||
|
||||
Major changes - local_login_sender_maps
|
||||
---------------------------------------
|
||||
|
||||
[Feature 20201025] Fine-grained control over the envelope sender address
|
||||
for submission with the Postfix sendmail (or postdrop) commands.
|
||||
|
||||
The local_login_sender_maps parameter (default: static:*) specifies
|
||||
a list of lookup tables that are searched by the UNIX login name, and
|
||||
that return a list of allowed envelope sender patterns separated by
|
||||
space or comma. The default is backwards-compatible: every user may
|
||||
specify any sender envelope address.
|
||||
|
||||
This feature is enforced by the postdrop command. When no UNIX login
|
||||
name is available, the postdrop command will prepend "uid:" to the
|
||||
numerical UID and use that instead.
|
||||
|
||||
This feature ignores address extensions in the user-specified
|
||||
envelope sender address.
|
||||
|
||||
Besides the special pattern "*" which allows any sender address,
|
||||
there are "<>" which matches an empty sender address, and the
|
||||
"@domain" wildcard pattern. More information about those can be found
|
||||
in the postconf(5) manpage.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
# Allow root and postfix full control, anyone else can only
|
||||
# send mail as themselves. Use "uid:" followed by the numerical
|
||||
# UID when the UID has no entry in the UNIX password file.
|
||||
local_login_sender_maps =
|
||||
inline:{ { root = *}, { postfix = * } },
|
||||
pcre:/etc/postfix/login_senders
|
||||
|
||||
/etc/postfix/login_senders:
|
||||
# Allow both the bare username and the user@domain forms.
|
||||
/(.+)/ $1 $1@example.com
|
||||
|
||||
Major changes - order of relay and recipient restrictions
|
||||
---------------------------------------------------------
|
||||
|
||||
[Incompat 20210131] With smtpd_relay_before_recipient_restrictions=yes,
|
||||
the Postfix SMTP server will evaluate smtpd_relay_restrictions before
|
||||
smtpd_recipient_restrictions. This is the default behavior with
|
||||
compatibility_level >= 3.6.
|
||||
|
||||
This change makes the implemented behavior consistent with existing
|
||||
documentation. There is a backwards-compatibility warning that allows
|
||||
users to freeze historical behavior. See COMPATIBILITY_README for
|
||||
details.
|
||||
|
||||
Major changes - respectful logging
|
||||
----------------------------------
|
||||
|
||||
[Feature 20210220] Postfix version 3.6 deprecates terminology
|
||||
that implies white is better than black. Instead, Postfix prefers
|
||||
'allowlist', 'denylist', and variations on those words. This change
|
||||
affects Postfix documentation, and postscreen parameters and logging.
|
||||
|
||||
To keep the old postscreen logging set "respectful_logging = no"
|
||||
in main.cf.
|
||||
|
||||
Noel Jones assisted with the initial transition.
|
||||
|
||||
Changes in documentation
|
||||
------------------------
|
||||
|
||||
Postfix documentation was updated to use 'allowlist', 'denylist', etc.
|
||||
These documentation changes do not affect Postfix behavior.
|
||||
|
||||
Changes in parameter names
|
||||
--------------------------
|
||||
|
||||
The following postscreen parameters replace names that contain 'blacklist'
|
||||
or 'whitelist':
|
||||
|
||||
postscreen_allowlist_interfaces
|
||||
postscreen_denylist_action
|
||||
postscreen_dnsbl_allowlist_threshold
|
||||
|
||||
These new parameters have backwards-compatible default settings
|
||||
that support the old parameter names, so that the name change should
|
||||
not affect Postfix behavior. This means that existing management tools
|
||||
that use the old parameter names should keep working as before.
|
||||
|
||||
This compatibility safety net may break when some management tools
|
||||
use the new parameter names, and some use the old names, such that
|
||||
different tools will disagree on how Postfix works.
|
||||
|
||||
Changes in logging
|
||||
------------------
|
||||
|
||||
The following logging replaces forms that contain 'blacklist' or
|
||||
'whitelist':
|
||||
|
||||
postfix/postscreen[pid]: ALLOWLIST VETO [address]:port
|
||||
postfix/postscreen[pid]: ALLOWLISTED [address]:port
|
||||
postfix/postscreen[pid]: DENYLISTED [address]:port
|
||||
|
||||
To avoid breaking logfile analysis tools, Postfix keeps logging the old
|
||||
forms by default, as long as the compatibility_level parameter setting
|
||||
is less than 3.6, and the respectful_logging parameter is not explicitly
|
||||
configured. As a reminder, Postfix will log the following:
|
||||
|
||||
postfix/postscreen[pid]: Using backwards-compatible default setting
|
||||
respectful_logging=no for client [address]:port
|
||||
|
||||
To keep logging the old form, make the setting "respectful_logging =
|
||||
no" permanent in main.cf, for example:
|
||||
|
||||
# postconf "respectful_logging = no"
|
||||
# postfix reload
|
||||
|
||||
To stop the reminder, configure the respectful_logging parameter to
|
||||
"yes" or "no", or configure "compatibility_level = 3.6".
|
||||
|
||||
Major changes - threaded bounces
|
||||
--------------------------------
|
||||
|
||||
[Feature 20201205] Support for threaded bounces. This allows mail
|
||||
readers to present a non-delivery, delayed delivery, or successful
|
||||
delivery notification in the same email thread as the original
|
||||
message.
|
||||
|
||||
Unfortunately, this also makes it easy for users to mistakenly delete
|
||||
the whole email thread (all related messages), instead of deleting
|
||||
only the delivery status notification.
|
||||
|
||||
To enable, specify "enable_threaded_bounces = yes".
|
||||
|
||||
Other changes - smtpd_sasl_mechanism_list
|
||||
-----------------------------------------
|
||||
|
||||
[Feature 20200906] The smtpd_sasl_mechanism_list parameter (default:
|
||||
!external, static:rest) prevents confusing errors when a SASL backend
|
||||
announces EXTERNAL support which Postfix does not support.
|
||||
|
||||
Other changes - delivery logging
|
||||
--------------------------------
|
||||
|
||||
[Incompat 20200531] Postfix delivery agents now log an explicit record
|
||||
when delegating delivery to a different Postfix delivery agent.
|
||||
|
||||
For example, with "best_mx_transport = local", an SMTP delivery
|
||||
agent will now log when a recipient will be delivered locally. This
|
||||
makes the delegating delivery agent visible, where it would otherwise
|
||||
have remained invisible, which would complicate troubleshooting.
|
||||
|
||||
postfix/smtp[pid]: queueid: passing <recipient> to transport=local
|
||||
|
||||
This will usually be followed by logging for an actual delivery:
|
||||
|
||||
postfix/local[pid]: queueid: to=<recipient>, relay=local, ...
|
||||
|
||||
Other examples: the local delivery agent will log a record that it
|
||||
defers mailbox delivery through mailbox_transport or through
|
||||
fallback_transport.
|
||||
|
||||
Other changes - error logging
|
||||
-----------------------------
|
||||
|
||||
[Incompat 20200531] Postfix programs will now log "Application error"
|
||||
instead of "Success" or "Unknown error: 0" when an operation fails with
|
||||
errno == 0, i.e., the error originates from non-kernel code.
|
||||
|
||||
Other changes - dns lookups
|
||||
---------------------------
|
||||
|
||||
[Feature 20200509] The threadsafe resolver API (res_nxxx() calls)
|
||||
is now the default, not because the API is threadsafe, but because
|
||||
this is the API where new features are being added.
|
||||
|
||||
To build old style, build with:
|
||||
|
||||
make makefiles CCARGS="-DNO_RES_NCALLS..."
|
||||
|
||||
This is the default for systems that are known not to support the
|
||||
threadsafe resolver API.
|
||||
179
RELEASE_NOTES-3.7
Normal file
179
RELEASE_NOTES-3.7
Normal file
|
|
@ -0,0 +1,179 @@
|
|||
This is the Postfix 3.7 (stable) release.
|
||||
|
||||
The stable Postfix release is called postfix-3.7.x where 3=major
|
||||
release number, 7=minor release number, x=patchlevel. The stable
|
||||
release never changes except for patches that address bugs or
|
||||
emergencies. Patches change the patchlevel and the release date.
|
||||
|
||||
New features are developed in snapshot releases. These are called
|
||||
postfix-3.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
|
||||
mm=month, dd=day). Patches are never issued for snapshot releases;
|
||||
instead, a new snapshot is released.
|
||||
|
||||
The mail_release_date configuration parameter (format: yyyymmdd)
|
||||
specifies the release date of a stable release or snapshot release.
|
||||
|
||||
If you upgrade from Postfix 3.5 or earlier, read RELEASE_NOTES-3.6
|
||||
before proceeding.
|
||||
|
||||
License change
|
||||
---------------
|
||||
|
||||
This software is distributed with a dual license: in addition to the
|
||||
historical IBM Public License 1.0, it is now also distributed with the
|
||||
more recent Eclipse Public License 2.0. Recipients can choose to take
|
||||
the software under the license of their choice. Those who are more
|
||||
comfortable with the IPL can continue with that license.
|
||||
|
||||
Major changes - configuration
|
||||
-----------------------------
|
||||
|
||||
[Feature 20210605] Support to inline the content of small cidr:,
|
||||
pcre:, and regexp: tables in Postfix parameter values.
|
||||
|
||||
Example:
|
||||
|
||||
smtpd_forbidden_commands =
|
||||
CONNECT GET POST regexp:{{/^[^A-Z]/ Thrash}}
|
||||
|
||||
This is the new smtpd_forbidden_commands default value. It will
|
||||
immediately disconnect a remote SMTP client when a command does not
|
||||
start with a letter (a-z or A-Z).
|
||||
|
||||
The basic syntax is:
|
||||
|
||||
/etc/postfix/main.cf:
|
||||
parameter = .. map-type:{ { rule-1 }, { rule-2 } .. } ..
|
||||
|
||||
/etc/postfix/master.cf:
|
||||
.. -o { parameter = .. map-type:{ { rule-1 }, { rule-2 } .. } .. } ..
|
||||
|
||||
where map-type is one of cidr, pcre, or regexp.
|
||||
|
||||
Postfix ignores whitespace after '{' and before '}', and writes each
|
||||
rule as one text line to a nameless in-memory file:
|
||||
|
||||
in-memory file:
|
||||
rule-1
|
||||
rule-2
|
||||
..
|
||||
|
||||
Postfix parses the result as if it is a file in /etc/postfix.
|
||||
|
||||
Note: if a rule contains $, specify $$ to keep Postfix from trying
|
||||
to do $name expansion as it evaluates the parameter value.
|
||||
|
||||
Major changes - lmdb support
|
||||
----------------------------
|
||||
|
||||
[Feature 20210605] Overhauled the LMDB client's error handling, and
|
||||
added integration tests for future-proofing. There are no visible
|
||||
changes in documented behavior.
|
||||
|
||||
Major changes - logging
|
||||
-----------------------
|
||||
|
||||
[Feature 20210815] To make the maillog_file feature more useful,
|
||||
the postlog(1) command is now set-gid postdrop, so that unprivileged
|
||||
programs can use it to write logging through the postlogd(8) daemon.
|
||||
This required hardening the postlog(1) command against privilege
|
||||
escalation attacks. DO NOT turn on the set-gid bit with older
|
||||
postlog(1) implementations.
|
||||
|
||||
Major changes - pcre2 support
|
||||
-----------------------------
|
||||
|
||||
[Feature 20211127] Support for the pcre2 library (the legacy pcre
|
||||
library is no longer maintained). The Postfix build procedure
|
||||
automatically detects if the pcre2 library is installed, and if it
|
||||
is unavailable, the Postfix build procedure will detect if the
|
||||
legacy pcre library is installed. See PCRE_README if you need to
|
||||
build Postfix with a specific library.
|
||||
|
||||
Visible differences: some error messages may have a different text,
|
||||
and the 'X' pattern flag is no longer supported with pcre2.
|
||||
|
||||
Major changes - security
|
||||
------------------------
|
||||
|
||||
[Feature 20220102] Postfix programs now randomize the initial state
|
||||
of in-memory hash tables, to defend against hash collision attacks
|
||||
involving a large number of attacker-chosen lookup keys. Presently,
|
||||
the only known opportunity for such attacks involves remote SMTP
|
||||
client IPv6 addresses in the anvil(8) service. The attack would
|
||||
require making hundreds of short-lived connections per second from
|
||||
thousands of different IP addresses, because the anvil(8) service
|
||||
drops inactive counters after 100s. Other in-memory hash tables
|
||||
with attacker-chosen lookup keys are by design limited in size. The
|
||||
fix is cheap, and therefore implemented for all Postfix in-memory
|
||||
hash tables. Problem reported by Pascal Junod.
|
||||
|
||||
[Feature 20211030] The postqueue command now sanitizes non-printable
|
||||
characters (such as newlines) in strings before they are formatted
|
||||
as json or as legacy output. These outputs are piped into other
|
||||
programs that are run by administrative users. This closes a
|
||||
hypothetical opportunity for privilege escalation.
|
||||
|
||||
[Feature 20210815] Updated defense against remote clients or servers
|
||||
that 'trickle' SMTP or LMTP traffic, based on per-request deadlines
|
||||
and minimum data rates.
|
||||
|
||||
Per-request deadlines:
|
||||
|
||||
The new {smtpd,smtp,lmtp}_per_request_deadline parameters replace
|
||||
{smtpd,smtp,lmtp}_per_record_deadline, with backwards compatible
|
||||
default settings. This defense is enabled by default in the Postfix
|
||||
SMTP server in case of overload.
|
||||
|
||||
The new smtpd_per_record_deadline parameter limits the combined
|
||||
time for the Postfix SMTP server to receive a request and to send
|
||||
a response, while the new {smtp,lmtp}_per_record_deadline parameters
|
||||
limit the combined time for the Postfix SMTP or LMTP client to send
|
||||
a request and to receive a response.
|
||||
|
||||
Minimum data rates:
|
||||
|
||||
The new smtpd_min_data_rate parameter enforces a minimum plaintext
|
||||
data transfer rate for DATA and BDAT requests, but only when
|
||||
smtpd_per_record_deadline is enabled. After a read operation transfers
|
||||
N plaintext bytes (possibly after TLS decryption), and after the
|
||||
DATA or BDAT request deadline is decreased by the elapsed time of
|
||||
that read operation, the DATA or BDAT request deadline is increased
|
||||
by N/smtpd_min_data_rate seconds. However, the deadline is never
|
||||
increased beyond the smtpd_timeout value. The default minimum data
|
||||
rate is 500 (bytes/second) but is still subject to change.
|
||||
|
||||
The new {smtp,lmtp}_min_data_rate parameters enforce the corresponding
|
||||
minimum DATA transfer rates for the Postfix SMTP and LMTP client.
|
||||
|
||||
Major changes - tls support
|
||||
---------------------------
|
||||
|
||||
[Cleanup 20220121] The new tlsproxy_client_security_level parameter
|
||||
replaces tlsproxy_client_level, and the new tlsproxy_client_policy_maps
|
||||
parameter replaces tlsproxy_client_policy. This is for consistent
|
||||
parameter naming (tlsproxy_client_xxx corresponds to smtp_tls_xxx).
|
||||
This change was made with backwards-compatible default settings.
|
||||
|
||||
[Feature 20210926] Postfix was updated to support OpenSSL 3.0.0 API
|
||||
features, and to work around OpenSSL 3.0.0 bit-rot (avoid using
|
||||
deprecated API features).
|
||||
|
||||
Other code health
|
||||
-----------------
|
||||
|
||||
[typos] Typo fixes by raf.
|
||||
|
||||
[pre-release checks] Added pre-release checks to detect a) new typos
|
||||
in documentation and source-code comments, b) missing entries in
|
||||
the postfix-files file (some documentation would not be installed),
|
||||
c) missing rules in the postlink script (some text would not have
|
||||
a hyperlink in documentation), and d) missing map-based $parameter
|
||||
names in the proxy_read_maps default value (the proxymap daemon
|
||||
would not automatically authorize some proxied maps).
|
||||
|
||||
[memory stream] Improved support for memory-based streams made it
|
||||
possible to inline small cidr:, pcre:, and regexp: maps in Postfix
|
||||
parameter values, and to eliminate some ad-hoc code that converted
|
||||
tlsproxy(8) protocol data to or from serialized form.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue