time (see cleanup/cleanup_api.c); also got rid of the global
state variables and fixed a couple bugs that were introduced
with 20000115-22.
+
+20000204
+
+ Feature: in daemon mode, the MAIL FROM size check can be
+ postponed until RCPT TO so that Postfix can log sender and
+ recipient. Simon J Mudd. Files: smtpd/smtpd.c
+
+ Robustness: limit the number of recipient addresses that
+ can be extracted from message headers. Parameter:
+ extract_recipient_limit (default: 10240). Files:
+ cleaup/cleanup_message.c, cleanup/cleanup_extracted.c.
+
+ Cleanup: the message header reject logging now includes
+ sender and recipient address (if possible), so that the
+ logging looks more like the other reject logging. File:
+ cleanup/cleanup_message.c.
+
+ Documentation: added sections on regular expression tables
+ to the access, canonical, virtual, transport and relocated
+ man pages, and write new man pages that are specific to
+ regular expressions: pcre_table.5 and regexp_table.5.
-Incompatible changes with snapshot-20000203
+Incompatible changes with snapshot-20000204
===========================================
-None sofar.
+This release is mainly to have a reference point after reorganizing
+the cleanup daemon.
-Major changes with snapshot-20000203
+Major changes with snapshot-20000204
====================================
Questionable feature: with "smtp_skip_5xx_greeting = yes", Postfix
/* Limit the number of envelope recipients that are remembered.
/* .IP \fBheader_size_limit\fR
/* Limit the amount of memory in bytes used to process a message header.
+/* .IP \fBextract_recipient_limit\fR
+/* Limit the amount of recipients extracted from message headers.
/* SEE ALSO
/* canonical(5) canonical address lookup table format
/* qmgr(8) queue manager daemon
* throw away the input only in case of real show-stopper errors, such as
* unrecognizable data (which should never happen) or insufficient space
* for the queue file (which will happen occasionally). Otherwise,
- * discard input after any lethal error. See the CLEANUP_OUT_OK()
- * macro definition.
+ * discard input after any lethal error. See the CLEANUP_OUT_OK() macro
+ * definition.
*/
if ((state->flags = flags) & CLEANUP_FLAG_BOUNCE) {
state->err_mask =
* the execute bits on a file only when we really want the queue manager
* to process it.
*/
- if (state->recip == 0)
- state->errs |= CLEANUP_STAT_RCPT;
- if (state->end_seen == 0)
- state->errs |= CLEANUP_STAT_BAD;
+ if (CLEANUP_OUT_OK(state)) {
+ if (state->recip == 0)
+ state->errs |= CLEANUP_STAT_RCPT;
+ if (state->end_seen == 0)
+ state->errs |= CLEANUP_STAT_BAD;
+ }
/*
* If there are no errors, be very picky about queue file write errors
* message headers because we could not process all the message headers).
* However, cleanup_strerror() prioritizes errors so that it can report
* the cause (e.g., header buffer overflow), which is more useful.
+ *
+ * XXX When bouncing, should log sender because qmgr won't be able to.
*/
#define CAN_BOUNCE() \
((state->errs & (CLEANUP_STAT_BAD | CLEANUP_STAT_WRITE)) == 0 \
if (bounce_recip(BOUNCE_FLAG_CLEAN,
MAIL_QUEUE_INCOMING, state->queue_id,
state->sender, state->recip ?
- state->recip : "", "cleanup", state->time,
+ state->recip : "unknown", "cleanup", state->time,
"Message processing aborted: %s",
cleanup_strerror(state->errs)) == 0) {
state->errs = 0;
*/
if (state->recip == 0 && (state->errs & CLEANUP_STAT_HOVFL) == 0) {
rcpt = (state->resent[0] ? state->resent_recip : state->recipients);
- if (*var_always_bcc && rcpt->argv[0]) {
- clean_addr = vstring_alloc(100);
- cleanup_rewrite_internal(clean_addr, var_always_bcc);
- if (cleanup_rcpt_canon_maps)
- cleanup_map11_internal(state, clean_addr, cleanup_rcpt_canon_maps,
+ if (rcpt->argc >= var_extra_rcpt_limit) {
+ state->errs |= CLEANUP_STAT_ROVFL;
+ } else {
+ if (*var_always_bcc && rcpt->argv[0]) {
+ clean_addr = vstring_alloc(100);
+ cleanup_rewrite_internal(clean_addr, var_always_bcc);
+ if (cleanup_rcpt_canon_maps)
+ cleanup_map11_internal(state, clean_addr, cleanup_rcpt_canon_maps,
cleanup_ext_prop_mask & EXT_PROP_CANONICAL);
- if (cleanup_comm_canon_maps)
- cleanup_map11_internal(state, clean_addr, cleanup_comm_canon_maps,
+ if (cleanup_comm_canon_maps)
+ cleanup_map11_internal(state, clean_addr, cleanup_comm_canon_maps,
cleanup_ext_prop_mask & EXT_PROP_CANONICAL);
- argv_add(rcpt, STR(clean_addr), (char *) 0);
- vstring_free(clean_addr);
+ argv_add(rcpt, STR(clean_addr), (char *) 0);
+ vstring_free(clean_addr);
+ }
+ argv_terminate(rcpt);
+ for (cpp = rcpt->argv; CLEANUP_OUT_OK(state) && *cpp; cpp++)
+ cleanup_out_recipient(state, *cpp);
+ if (rcpt->argv[0])
+ state->recip = mystrdup(rcpt->argv[0]);
}
- argv_terminate(rcpt);
- for (cpp = rcpt->argv; CLEANUP_OUT_OK(state) && *cpp; cpp++)
- cleanup_out_recipient(state, *cpp);
- if (rcpt->argv[0])
- state->recip = mystrdup(rcpt->argv[0]);
}
/*
/* void cleanup_all()
/* DESCRIPTION
/* This module implements a callable interface to the cleanup service
-/* for one-time initializations that must be done before any message
+/* for one-time initializations that must be done before any message
/* processing can take place.
/*
/* cleanup_int_table[] and cleanup_str_table[] specify configuration
/*
/* cleanup_pre_jail() and cleanup_post_jail() perform mandatory
/* initializations before and after the process enters the optional
-/* chroot jail. These functions satisfy the interface as specified
+/* chroot jail. These functions satisfy the interface as specified
/* in single_service(3).
/*
/* cleanup_path is either a null pointer or it is the name of a queue
/*
/* cleanup_all() must be called in case of fatal error, in order
/* to remove an incomplete queue file. Normally, as part of process
-/* initialization, one registers a msg_cleanup() handler and a signal()
+/* initialization, one registers a msg_cleanup() handler and a signal()
/* handler that both call cleanup_all() before terminating the process.
/* DIAGNOSTICS
/* Problems and transactions are logged to \fBsyslogd\fR(8).
int var_delay_warn_time; /* delay that triggers warning */
char *var_prop_extension; /* propagate unmatched extension */
char *var_always_bcc; /* big brother */
+int var_extra_rcpt_limit; /* recipient extract limit */
CONFIG_INT_TABLE cleanup_int_table[] = {
VAR_HOPCOUNT_LIMIT, DEF_HOPCOUNT_LIMIT, &var_hopcount_limit, 1, 0,
VAR_HEADER_LIMIT, DEF_HEADER_LIMIT, &var_header_limit, 1, 0,
VAR_DUP_FILTER_LIMIT, DEF_DUP_FILTER_LIMIT, &var_dup_filter_limit, 0, 0,
VAR_DELAY_WARN_TIME, DEF_DELAY_WARN_TIME, &var_delay_warn_time, 0, 0,
+ VAR_EXTRA_RCPT_LIMIT, DEF_EXTRA_RCPT_LIMIT, &var_extra_rcpt_limit, 0, 0,
0,
};
+
CONFIG_STR_TABLE cleanup_str_table[] = {
VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, &var_canonical_maps, 0, 0,
VAR_SEND_CANON_MAPS, DEF_SEND_CANON_MAPS, &var_send_canon_maps, 0, 0,
TOK822 *tree;
TOK822 **addr_list;
TOK822 **tpp;
+ ARGV *rcpt;
if (msg_verbose)
msg_info("rewrite_recip: %s", hdr_opts->name);
if (cleanup_comm_canon_maps)
cleanup_map11_tree(state, *tpp, cleanup_comm_canon_maps,
cleanup_ext_prop_mask & EXT_PROP_CANONICAL);
- tok822_internalize(state->temp1, tpp[0]->head, TOK822_STR_DEFL);
- if (state->recip == 0 && (hdr_opts->flags & HDR_OPT_EXTRACT) != 0)
- argv_add((hdr_opts->flags & HDR_OPT_RR) ?
- state->resent_recip : state->recipients,
- vstring_str(state->temp1), (char *) 0);
+ if (state->recip == 0 && (hdr_opts->flags & HDR_OPT_EXTRACT) != 0) {
+ rcpt = (hdr_opts->flags & HDR_OPT_RR) ?
+ state->resent_recip : state->recipients;
+ if (rcpt->argc < var_extra_rcpt_limit) {
+ tok822_internalize(state->temp1, tpp[0]->head, TOK822_STR_DEFL);
+ argv_add(rcpt, vstring_str(state->temp1), (char *) 0);
+ }
+ }
if (cleanup_masq_domains)
cleanup_masquerade_tree(*tpp, cleanup_masq_domains);
if (hdr_opts->type == HDR_RETURN_RECEIPT_TO && !state->return_receipt)
if ((value = maps_find(cleanup_header_checks, header, 0)) != 0) {
if (strcasecmp(value, "REJECT") == 0) {
- msg_warn("%s: reject: header %.100s", state->queue_id, header);
+ msg_info("%s: reject: header %.100s; from=<%s> to=<%s>",
+ state->queue_id, header, state->sender,
+ state->recip ? state->recip : "unknown");
state->errs |= CLEANUP_STAT_CONT;
}
}
# PATTERNS
# .ad
# .fi
-# With lookups from indexed files, patterns are tried in the order as
+# With lookups from indexed files such as DB or DBM, or from networked
+# tables such as NIS, LDAP or SQL, patterns are tried in the order as
# listed below:
# .IP \fIuser\fR@\fIdomain\fR
# Matches the specified mail address.
# Each pattern is a regular expression that is applied to the entire
# string being looked up. Depending on the application, that string
# is an entire client hostname, an entire client IP address, or an
-# entire mail address. Patterns are applied in order as specified,
-# until a pattern is found that matches the search string.
+# entire mail address. Thus, no parent domain or parent network search
+# is done, and \fIuser@domain\fR mail addresses are not broken up into
+# their \fIuser@\fR and \fIdomain\fR constituent parts.
#
-# In contrast to lookups from indexed files, no parent domain or
-# parent network search is done with regular expression tables,
-# and \fIuser@domain\fR mail addresses are not broken up into their
-# \fIuser@\fR and \fIdomain\fR constituent parts.
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
#
# Actions are the same as with normal indexed file lookups, with
# the additional feature that parenthesized substrings from the
# postmap(1) create mapping table
# smtpd(8) smtp server
# pcre_table(5) format of PCRE tables
-# regexp_table(5) format of POSIX regexp tables
+# regexp_table(5) format of POSIX regular expression tables
# LICENSE
# .ad
# .fi
# local and non-local addresses. The mapping is used by the
# \fBcleanup\fR(8) daemon. The address mapping is recursive.
#
-# The file serves as input to the \fBpostmap\fR(1) command. The result,
-# an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-# fast searching by the mail system. After an update
+# Normally, the file serves as input to the \fBpostmap\fR(1) command.
+# The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+# is used for fast searching by the mail system. After an update
# it may take a minute or so before the change becomes visible.
# Issue a \fBpostfix reload\fR command to eliminate the delay.
#
+# When the table is provided via other means such as NIS, LDAP
+# or SQL, the same lookups are done as for ordinary indexed files.
+#
+# Alternatively, the table can be provided as a regular-expression
+# map where patterns are given as regular expressions. In that case,
+# the lookups are done in a slightly different way as described below.
+#
# The \fBcanonical\fR mapping affects both message header addresses
# (i.e. addresses that appear inside messages) and message envelope
# addresses (for example, the addresses that are used in SMTP protocol
#
# The \fBcanonical\fR mapping is not to be confused with local aliasing.
# Use the \fBaliases\fR(5) map for that purpose.
-#
-# The format of the \fBcanonical\fR table is as follows, mappings
-# being tried in the order as listed in this manual page:
+# TABLE FORMAT
+# .ad
+# .fi
+# The format of the \fBcanonical\fR table is as follows:
# .IP "blanks and comments"
# Blank lines are ignored, as are lines beginning with `#'.
+# .IP "\fIpattern result\fR"
+# When \fIpattern\fR matches a mail address, replace it by the
+# corresponding \fIresult\fR.
+# .PP
+# With lookups from indexed files such as DB or DBM, or from networked
+# tables such as NIS, LDAP or SQL, patterns are tried in the order as
+# listed below:
# .IP "\fIuser\fR@\fIdomain address\fR"
# \fIuser\fR@\fIdomain\fR is replaced by \fIaddress\fR. This form
# has the highest precedence.
# to the result of table lookup. The matching order is:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR,
# \fIuser+foo\fR, \fIuser\fR, and @\fIdomain\fR.
+# REGULAR EXPRESSION TABLES
+# .ad
+# .fi
+# This section describes how the table lookups change when the table
+# is given in the form of regular expressions. For a description of
+# regular expression lookup table syntax, see \fBregexp_table\fR(5)
+# or \fBpcre_table\fR(5).
+#
+# Each pattern is a regular expression that is applied to the entire
+# address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+# broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+# nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Results are the same as with normal indexed file lookups, with
+# the additional feature that parenthesized substrings from the
+# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
# BUGS
# The table format does not understand quoting conventions.
# CONFIGURATION PARAMETERS
# cleanup(8) canonicalize and enqueue mail
# postmap(1) create mapping table
# virtual(5) virtual domain mapping
+# pcre_table(5) format of PCRE tables
+# regexp_table(5) format of POSIX regular expression tables
# LICENSE
# .ad
# .fi
-THIS IS TODO
+#++
+# NAME
+# pcre_table 5
+# SUMMARY
+# format of Postfix PCRE tables
+# SYNOPSIS
+# pcre:/etc/postfix/filename
+# DESCRIPTION
+# The Postfix mail system uses optional tables for address
+# rewriting or mail routing. These tables usually are in
+# \fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
+# can be specified in Perl Compatible Regular Expression form.
+#
+# To find out what types of lookup tables your Postfix system
+# supports use the \fBpostconf -m\fR command.
+#
+# The general form of a PCRE table is:
+# .IP "blanks and comments"
+# Blank lines are ignored, as are lines beginning with `#'.
+# .IP "\fIpattern result\fR"
+# When \fIpattern\fR matches a search string, use the corresponding
+# \fIresult\fR. A line that starts with white space continues the
+# preceding line.
+# .PP
+# Each pattern is a perl-like regular expression. The expression
+# delimiter can be any character, except whitespace or characters
+# that have special meaning (traditionally the forward slash is used).
+# The regular expression can contain whitespace.
+#
+# By default, matching is case-insensitive, although following
+# the second slash with an `i' flag will reverse this. Other flags
+# are supported, but the only other useful one is `U', which makes
+# matching ungreedy (see PCRE documentation and source for more
+# info).
+#
+# Each pattern is applied to the entire string being looked up.
+# 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, and
+# \fIuser@domain\fR mail addresses are not broken up into their
+# \fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
+# broken up into \fIuser\fR and \fIfoo\fR.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Substitution of sub-strings from the matched expression is
+# possible using the conventional perl syntax ($1, $2, etc.). The
+# macros in the replacement string may need to be written as ${n}
+# or $(n) if they aren't followed by whitespace.
+# EXAMPLES
+# # Protect your outgoing majordomo exploders
+# /^(?!owner-)(.*)-outgoing@(my\.domain)$/ 550 Use ${1}@${2} instead
+#
+# # Bounce friend@whatever, except when whatever is our domain (you would
+# # be better just bouncing all friend@ mail - this is just an example).
+# /^friend@(?!my\.domain).*$/ 550 Stick this in your pipe $0
+#
+# # A multi-line entry. The text is sent as one line.
+# #
+# /^noddy@connect\.com\.au$/
+# \ 550 This user is a funny one. You really don't want to send mail to
+# \ them as it only makes their head spin.
+# SEE ALSO
+# regexp_table(5) format of POSIX regular expression tables
+# AUTHOR(S)
+# The PCRE table lookup code was originally written by:
+# Andrew McNamara
+# andrewm@connect.com.au
+# connect.com.au Pty. Ltd.
+# Level 3, 213 Miller St
+# North Sydney, NSW, Australia
+#
+# Adopted and adapted by:
+# Wietse Venema
+# IBM T.J. Watson Research
+# P.O. Box 704
+# Yorktown Heights, NY 10598, USA
+#--
-THIS IS TODO
+#++
+# NAME
+# regexp_table 5
+# SUMMARY
+# format of Postfix regular expression tables
+# SYNOPSIS
+# regexp:/etc/postfix/filename
+# DESCRIPTION
+# The Postfix mail system uses optional tables for address
+# rewriting or mail routing. These tables usually are in
+# \fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
+# can be specified in POSIX regular expression form.
+#
+# To find out what types of lookup tables your Postfix system
+# supports use the \fBpostconf -m\fR command.
+#
+# The general form of a Postfix regular expression table is:
+# .IP "blanks and comments"
+# Blank lines are ignored, as are lines beginning with `#'.
+# .IP "\fIpattern result\fR"
+# When \fIpattern\fR matches a search string, use the corresponding
+# \fIresult\fR. A line that starts with white space continues the
+# preceding line.
+# .IP "\fIpattern1!pattern2 result\fR"
+# Matches \fIpattern1\fR but not \fIpattern2\fR.
+# .PP
+# Each pattern is a regular expression enclosed by a pair of delimiters.
+# The regular expression syntax is described in \fIre_format\fR(7).
+# The expression delimiter can be any character, except whitespace
+# or characters that have special meaning (traditionally the forward
+# slash is used). The regular expression can contain whitespace.
+#
+# By default, matching is case-insensitive, although following
+# the second slash with an `i' flag will reverse this. Other flags
+# are `x' (disable extended expression syntax), and `m' (enable
+# multi-line mode).
+#
+# Each pattern is applied to the entire string being looked up.
+# 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, and
+# \fIuser@domain\fR mail addresses are not broken up into their
+# \fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
+# broken up into \fIuser\fR and \fIfoo\fR.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Substitution of sub-strings from the matched expression is
+# possible using $1, $2, etc.. The macros in the replacement string
+# may need to be written as ${n} or $(n) if they aren't followed
+# by whitespace.
+# EXAMPLES
+# # Disallow sender-specified routing. This is a must if you relay mail
+# # for other domains.
+# /[%!@].*[%!@]/ 550 Sender-specified routing rejected
+#
+# # Postmaster is OK, that way they can talk to us about how to fix
+# # their problem.
+# /^postmaster@.*$/ OK
+#
+# # Protect your outgoing majordomo exploders
+# /^(.*)-outgoing@(.*)$/!/^owner-.*/ 550 Use ${1}@${2} instead
+# SEE ALSO
+# pcre_table(5) format of PCRE tables
+# AUTHOR(S)
+# The regexp table lookup code was originally written by:
+# LaMont Jones
+# lamont@hp.com
+#
+# That code was based on the PCRE dictionary contributed by:
+# Andrew McNamara
+# andrewm@connect.com.au
+# connect.com.au Pty. Ltd.
+# Level 3, 213 Miller St
+# North Sydney, NSW, Australia
+#
+# Adopted and adapted by:
+# Wietse Venema
+# IBM T.J. Watson Research
+# P.O. Box 704
+# Yorktown Heights, NY 10598, USA
+#--
# The optional \fBrelocated\fR file provides the information that is
# used in "user has moved to \fInew_location\fR" bounce messages.
#
-# The file serves as input to the \fBpostmap\fR(1) command. The result,
-# an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-# fast searching by the mail system. After an update
+# Normally, the file serves as input to the \fBpostmap\fR(1) command.
+# The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+# is used for fast searching by the mail system. After an update
# issue a \fBpostfix reload\fR command to make the change visible.
#
-# Table lookups are case insensitive.
+# When the table is provided via other means such as NIS, LDAP
+# or SQL, the same lookups are done as for ordinary indexed files.
+#
+# Alternatively, the table can be provided as a regular-expression
+# map where patterns are given as regular expressions. In that case,
+# the lookups are done in a slightly different way as described below.
#
+# Table lookups are case insensitive.
+# TABLE FORMAT
+# .ad
+# .fi
# The format of the table is as follows:
# .IP \(bu
# Blank lines are ignored, as are lines beginning with `#'.
# Where \fInew_location\fR specifies contact information such as
# an email address, or perhaps a street address or telephone number.
# .PP
-# The \fIkey\fR field is one of the following:
+# With lookups from indexed files such as DB or DBM, or from networked
+# tables such as NIS, LDAP or SQL, the \fIkey\fR field is one of the
+# following:
# .IP \fIuser\fR@\fIdomain\fR
# Matches \fIuser\fR@\fIdomain\fR. This form has precedence over all
# other forms.
# optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
# the search is repeated for the unextended address (e.g.
# \fIuser\fR@\fIdomain\fR).
+# REGULAR EXPRESSION TABLES
+# .ad
+# .fi
+# This section describes how the table lookups change when the table
+# is given in the form of regular expressions. For a description of
+# regular expression lookup table syntax, see \fBregexp_table\fR(5)
+# or \fBpcre_table\fR(5).
+#
+# Each pattern is a regular expression that is applied to the entire
+# address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+# broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+# nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Results are the same as with normal indexed file lookups, with
+# the additional feature that parenthesized substrings from the
+# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
# BUGS
# The table format does not understand quoting conventions.
# CONFIGURATION PARAMETERS
# The domain that is appended to locally-posted mail.
# SEE ALSO
# postmap(1) create lookup table
+# pcre_table(5) format of PCRE tables
+# regexp_table(5) format of POSIX regular expression tables
# LICENSE
# .ad
# .fi
# P.O. Box 704
# Yorktown Heights, NY 10598, USA
#--
-
+
# By default, this file is not used. See sample-relocated.cf
# the forward slash is used). The regular expression can contain
# whitespace.
#
-# By default, matching is case-INsensative, although following
+# By default, matching is case-INsensitive, although following
# the second slash with an 'i' will reverse this. Other flags are
# supported, but the only other useful one is 'U', which makes
# matching ungreedy (see PCRE documentation and source for more
# hierarchies to message delivery transports and/or relay hosts. The
# mapping is used by the \fBtrivial-rewrite\fR(8) daemon.
#
-# The file serves as input to the \fBpostmap\fR(1) command. The result,
-# an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-# fast searching by the mail system. After updating this table,
+# Normally, the file serves as input to the \fBpostmap\fR(1) command.
+# The result, an indexed file in \fBdbm\fR or \fBdb\fR format, is used
+# for fast searching by the mail system. After updating this table,
# issue the \fBpostfix reload\fR command to make the change visible.
#
+# When the table is provided via other means such as NIS, LDAP
+# or SQL, the same lookups are done as for ordinary indexed files.
+#
+# Alternatively, the table can be provided as a regular-expression
+# map where patterns are given as regular expressions. In that case,
+# the lookups are done in a slightly different way as described below.
+# TABLE FORMAT
+# .ad
+# .fi
# The format of the transport table is as follows:
# .IP "blanks and comments"
# Blank lines are ignored, as are lines beginning with `#'.
+# .IP "\fIpattern result\fR"
+# When \fIpattern\fR matches the domain, use the corresponding
+# \fIresult\fR.
+# .PP
+# With lookups from indexed files such as DB or DBM, or from networked
+# tables such as NIS, LDAP or SQL, patterns are tried in the order as
+# listed below:
# .IP "\fIdomain transport\fR:\fInexthop\fR"
# Mail for \fIdomain\fR is delivered through \fItransport\fR to
# \fInexthop\fR.
# for example:
#
# .ti +5
-# \fBhostname.my.domain local:\fR
+# \fBhostname.my.domain local:\fR
# .ti +5
# \fBlocalhost.my.domain local:\fR
#
# .ti +5
# \fB\&.foo.org error:mail for *.foo.org is not deliverable\fR
#
-# This causes all mail for \fIuser\fR@\fIanything\fBfoo.org\fR
+# This causes all mail for \fIuser\fR@\fIanything\fBfoo.org\fR
# to be bounced.
+# REGULAR EXPRESSION TABLES
+# .ad
+# .fi
+# This section describes how the table lookups change when the table
+# is given in the form of regular expressions. For a description of
+# regular expression lookup table syntax, see \fBregexp_table\fR(5)
+# or \fBpcre_table\fR(5).
+#
+# Each pattern is a regular expression that is applied to the entire
+# domain being looked up. Thus, \fIsome.domain.hierarchy\fR is not
+# broken up into parent domains.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Results are the same as with normal indexed file lookups, with
+# the additional feature that parenthesized substrings from the
+# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
# CONFIGURATION PARAMETERS
# .ad
# .fi
# SEE ALSO
# postmap(1) create mapping table
# trivial-rewrite(8) rewrite and resolve addresses
+# pcre_table(5) format of PCRE tables
+# regexp_table(5) format of POSIX regular expression tables
# LICENSE
# .ad
# .fi
# Think Sendmail rule set \fBS0\fR, if you like. Use \fBcanonical\fR(5)
# mapping to rewrite header and envelope addresses in general.
#
-# The file serves as input to the \fBpostmap\fR(1) command. The
-# result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+# Normally, the file serves as input to the \fBpostmap\fR(1) command.
+# The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
# is used for fast searching by the mail system. After an update
# it may take a minute or so before the change becomes visible.
# Issue a \fBpostfix reload\fR command to eliminate the delay.
#
+# When the table is provided via other means such as NIS, LDAP
+# or SQL, the same lookups are done as for ordinary indexed files.
+#
+# Alternatively, the table can be provided as a regular-expression
+# map where patterns are given as regular expressions. In that case,
+# the lookups are done in a slightly different way as described below.
+# TABLE FORMAT
+# .ad
+# .fi
# Typical support for a virtual domain looks like the following:
#
# .in +4
# tried in the order as listed in this manual page:
# .IP "blanks and comments"
# Blank lines are ignored, as are lines beginning with `#'.
+# .IP "\fIpattern result\fR"
+# When \fIpattern\fR matches a mail address, replace it by the
+# corresponding \fIresult\fR.
+# .PP
+# With lookups from indexed files such as DB or DBM, or from networked
+# tables such as NIS, LDAP or SQL, patterns are tried in the order as
+# listed below:
# .IP "\fIuser\fR@\fIdomain address, address, ...\fR"
# Mail for \fIuser\fR@\fIdomain\fR is redirected to \fIaddress\fR.
# This form has the highest precedence.
# propagated to the result of expansion. The matching order is:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR,
# \fIuser+foo\fR, \fIuser\fR, and @\fIdomain\fR.
+# REGULAR EXPRESSION TABLES
+# .ad
+# .fi
+# This section describes how the table lookups change when the table
+# is given in the form of regular expressions. For a description of
+# regular expression lookup table syntax, see \fBregexp_table\fR(5)
+# or \fBpcre_table\fR(5).
+#
+# Each pattern is a regular expression that is applied to the entire
+# address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+# broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+# nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+#
+# Patterns are applied in the order as specified in the table, until a
+# pattern is found that matches the search string.
+#
+# Results are the same as with normal indexed file lookups, with
+# the additional feature that parenthesized substrings from the
+# pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
# BUGS
# The table format does not understand quoting conventions.
# CONFIGURATION PARAMETERS
# SEE ALSO
# cleanup(8) canonicalize and enqueue mail
# postmap(1) create mapping table
+# pcre_table(5) format of PCRE tables
+# regexp_table(5) format of POSIX regular expression tables
# LICENSE
# .ad
# .fi
static struct cleanup_stat_map cleanup_stat_map[] = {
CLEANUP_STAT_BAD, "Internal protocol error",
CLEANUP_STAT_HOVFL, "Message header too long",
+ CLEANUP_STAT_ROVFL, "Too many extracted recipients",
CLEANUP_STAT_RCPT, "No recipients specified",
CLEANUP_STAT_HOPS, "Too many hops",
CLEANUP_STAT_SIZE, "Message file too big",
#define CLEANUP_STAT_SYN (1<<5) /* Bad address syntax */
#define CLEANUP_STAT_RCPT (1<<6) /* No recipients found */
#define CLEANUP_STAT_HOVFL (1<<7) /* Header overflow */
+#define CLEANUP_STAT_ROVFL (1<<8) /* Recipient overflow */
-#define CLEANUP_STAT_LETHAL (~CLEANUP_STAT_HOVFL) /* lethal errors */
+#define CLEANUP_STAT_LETHAL ~(CLEANUP_STAT_HOVFL|CLEANUP_STAT_ROVFL)
extern const char *cleanup_strerror(unsigned);
#define DEF_HEADER_LIMIT 102400
extern int var_header_limit;
+#define VAR_EXTRA_RCPT_LIMIT "extract_recipient_limit"
+#define DEF_EXTRA_RCPT_LIMIT 10240
+extern int var_extra_rcpt_limit;
+
/*
* Message/queue size limits.
*/
* Version of this program.
*/
#define VAR_MAIL_VERSION "mail_version"
-#define DEF_MAIL_VERSION "Snapshot-20000203"
+#define DEF_MAIL_VERSION "Snapshot-20000204"
extern char *var_mail_version;
/* LICENSE
address, perform the corresponding <i>action</i>.
<b>PATTERNS</b>
- With lookups from indexed files, patterns are tried in the
- order as listed below:
+ With lookups from indexed files such as DB or DBM, or from
+ networked tables such as NIS, LDAP or SQL, patterns are
+ tried in the order as listed below:
<i>user</i>@<i>domain</i>
Matches the specified mail address.
<i>domain.name</i>
- Matches the <i>domain.name</i> itself and any subdomain
- thereof, either in hostnames or in mail addresses.
+ Matches the <i>domain.name</i> itself and any subdomain
+ thereof, either in hostnames or in mail addresses.
Top-level domains will never be matched.
- <i>user</i>@ Matches all mail addresses with the specified user
+ <i>user</i>@ Matches all mail addresses with the specified user
part.
-
1
<i>net.work</i>
- <i>net</i> Matches any host address in the specified network.
- A network address is a sequence of one or more
+ <i>net</i> Matches any host address in the specified network.
+ A network address is a sequence of one or more
octets separated by ".".
<b>ACTIONS</b>
[<b>45</b>]<i>XX</i> <i>text</i>
- Reject the address etc. that matches the pattern,
+ Reject the address etc. that matches the pattern,
and respond with the numerical code and text.
<b>REJECT</b> Reject the address etc. that matches the pattern. A
Accept the address etc. that matches the pattern.
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
- This section describes how the table lookups change when
+ This section describes how the table lookups change when
the table is given in the form of regular expressions. For
- a description of regular expression lookup table syntax,
- see <b>regexp</b><i>_</i><b>table</b>(5) or <b>pcre</b><i>_</i><b>table</b>(5).
+ a description of regular expression lookup table syntax,
+ see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
- Each pattern is a regular expression that is applied to
+ Each pattern is a regular expression that is applied to
the entire string being looked up. Depending on the appli-
- cation, that string is an entire client hostname, an
- entire client IP address, or an entire mail address. Pat-
- terns are applied in order as specified, until a pattern
- is found that matches the search string.
+ cation, 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, and
+ <i>user@domain</i> mail addresses are not broken up into their
+ <i>user@</i> and <i>domain</i> constituent parts.
- In contrast to lookups from indexed files, no parent
- domain or parent network search is done with regular
- expression tables, and <i>user@domain</i> mail addresses are not
- broken up into their <i>user@</i> and <i>domain</i> constituent parts.
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
- Actions are the same as with normal indexed file lookups,
- with the additional feature that parenthesized substrings
- from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
+ Actions are the same as with normal indexed file lookups,
+ with the additional feature that parenthesized substrings
+ from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
<b>BUGS</b>
- The table format does not understand quoting conventions.
+ The table format does not understand quoting conventions.
<b>SEE</b> <b>ALSO</b>
<a href="postmap.1.html">postmap(1)</a> create mapping table
<a href="smtpd.8.html">smtpd(8)</a> smtp server
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
- <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regexp tables
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
<b>LICENSE</b>
- The Secure Mailer license must be distributed with this
+ The Secure Mailer license must be distributed with this
software.
<b>AUTHOR(S)</b>
for local and non-local addresses. The mapping is used by
the <a href="cleanup.8.html"><b>cleanup</b>(8)</a> daemon. The address mapping is recursive.
- The file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
- result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
- fast searching by the mail system. After an update it may
- take a minute or so before the change becomes visible.
- Issue a <b>postfix</b> <b>reload</b> command to eliminate the delay.
+ Normally, the file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> com-
+ mand. The result, an indexed file in <b>dbm</b> or <b>db</b> format, is
+ used for fast searching by the mail system. After an
+ update it may take a minute or so before the change
+ becomes visible. Issue a <b>postfix</b> <b>reload</b> command to elimi-
+ nate the delay.
+
+ When the table is provided via other means such as NIS,
+ LDAP or SQL, the same lookups are done as for ordinary
+ indexed files.
+
+ Alternatively, the table can be provided as a regular-
+ expression map where patterns are given as regular expres-
+ sions. In that case, the lookups are done in a slightly
+ different way as described below.
The <b>canonical</b> mapping affects both message header
addresses (i.e. addresses that appear inside messages) and
The <b>canonical</b> mapping is not to be confused with local
aliasing. Use the <a href="aliases.5.html"><b>aliases</b>(5)</a> map for that purpose.
- The format of the <b>canonical</b> table is as follows, mappings
- being tried in the order as listed in this manual page:
+<b>TABLE</b> <b>FORMAT</b>
+ The format of the <b>canonical</b> table is as follows:
blanks and comments
- Blank lines are ignored, as are lines beginning
+ Blank lines are ignored, as are lines beginning
with `#'.
+ <i>pattern</i> <i>result</i>
+ When <i>pattern</i> matches a mail address, replace it by
+ the corresponding <i>result</i>.
+
+
+
+
+ 1
+
+
+
+
+
+CANONICAL(5) CANONICAL(5)
+
+
+ With lookups from indexed files such as DB or DBM, or from
+ networked tables such as NIS, LDAP or SQL, patterns are
+ tried in the order as listed below:
+
<i>user</i>@<i>domain</i> <i>address</i>
<i>user</i>@<i>domain</i> is replaced by <i>address</i>. This form has
the highest precedence.
to $<b>myorigin</b>, when <i>site</i> is listed in $<b>mydestina-</b>
<b>tion</b>, or when it is listed in $<b>inet</b><i>_</i><b>interfaces</b>.
-
-
-
- 1
-
-
-
-
-
-CANONICAL(5) CANONICAL(5)
-
-
This form is useful for replacing login names by
<i>Firstname.Lastname</i>.
matching order is: <i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>user+foo</i>,
<i>user</i>, and @<i>domain</i>.
+<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
+ This section describes how the table lookups change when
+ the table is given in the form of regular expressions. For
+ a description of regular expression lookup table syntax,
+ see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
+
+ Each pattern is a regular expression that is applied to
+ the entire address being looked up. Thus, <i>user@domain</i> mail
+ addresses are not broken up into their <i>user</i> and <i>@domain</i>
+ constituent parts, nor is <i>user+foo</i> broken up into <i>user</i> and
+ <i>foo</i>.
+
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+
+ Results are the same as with normal indexed file lookups,
+
+
+
+ 2
+
+
+
+
+
+CANONICAL(5) CANONICAL(5)
+
+
+ with the additional feature that parenthesized substrings
+ from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
+
<b>BUGS</b>
The table format does not understand quoting conventions.
List of user names that are not subject to address
masquerading.
-
-
-
-
- 2
-
-
-
-
-
-CANONICAL(5) CANONICAL(5)
-
-
<b>mydestination</b>
List of domains that this mail system considers
local.
<a href="cleanup.8.html">cleanup(8)</a> canonicalize and enqueue mail
<a href="postmap.1.html">postmap(1)</a> create mapping table
<a href="virtual.5.html">virtual(5)</a> virtual domain mapping
+ <a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
+
+
+
+ 3
+
+
+
+
+
+CANONICAL(5) CANONICAL(5)
+
<b>LICENSE</b>
The Secure Mailer license must be distributed with this
- 3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 4
</pre> </body> </html>
Limit the amount of memory in bytes used to process
a message header.
+ <b>extract</b><i>_</i><b>recipient</b><i>_</i><b>limit</b>
+ Limit the amount of recipients extracted from mes-
+ sage headers.
+
<b>SEE</b> <b>ALSO</b>
<a href="canonical.5.html">canonical(5)</a> canonical address lookup table format
<a href="qmgr.8.html">qmgr(8)</a> queue manager daemon
/etc/postfix/virtual*, virtual mapping table
<b>LICENSE</b>
- The Secure Mailer license must be distributed with this
+ The Secure Mailer license must be distributed with this
software.
<b>AUTHOR(S)</b>
-
-
-
-
<html> <head> </head> <body> <pre>
+
+
+
+PCRE_TABLE(5) PCRE_TABLE(5)
+
+
+<b>NAME</b>
+ pcre_table - format of Postfix PCRE tables
+
+<b>SYNOPSIS</b>
+ pcre:/etc/postfix/filename
+
+<b>DESCRIPTION</b>
+ The Postfix mail system uses optional tables for address
+ rewriting or mail routing. These tables usually are in <b>dbm</b>
+ or <b>db</b> format. Alternatively, lookup tables can be speci-
+ fied in Perl Compatible Regular Expression form.
+
+ To find out what types of lookup tables your Postfix sys-
+ tem supports use the <b>postconf</b> <b>-m</b> command.
+
+ The general form of a PCRE table is:
+
+ blanks and comments
+ Blank lines are ignored, as are lines beginning
+ with `#'.
+
+ <i>pattern</i> <i>result</i>
+ When <i>pattern</i> matches a search string, use the cor-
+ responding <i>result</i>. A line that starts with white
+ space continues the preceding line.
+
+ Each pattern is a perl-like regular expression. The
+ expression delimiter can be any character, except whites-
+ pace or characters that have special meaning (tradition-
+ ally the forward slash is used). The regular expression
+ can contain whitespace.
+
+ By default, matching is case-insensitive, although follow-
+ ing the second slash with an `i' flag will reverse this.
+ Other flags are supported, but the only other useful one
+ is `U', which makes matching ungreedy (see PCRE documenta-
+ tion and source for more info).
+
+ Each pattern is applied to the entire string being looked
+ up. 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, and <i>user@domain</i> mail addresses are
+ not broken up into their <i>user</i> and <i>domain</i> constituent
+ parts, nor is <i>user+foo</i> broken up into <i>user</i> and <i>foo</i>.
+
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+
+ Substitution of sub-strings from the matched expression is
+ possible using the conventional perl syntax ($1, $2,
+ etc.). The macros in the replacement string may need to be
+ written as ${n} or $(n) if they aren't followed by
+
+
+
+ 1
+
+
+
+
+
+PCRE_TABLE(5) PCRE_TABLE(5)
+
+
+ whitespace.
+
+<b>EXAMPLES</b>
+ # Protect your outgoing majordomo exploders
+ /^(?!owner-)(.*)-outgoing@(my.domain)$/ 550 Use ${1}@${2} instead
+
+ # Bounce friend@whatever, except when whatever is our domain (you would
+ # be better just bouncing all friend@ mail - this is just an example).
+ /^friend@(?!my.domain).*$/ 550 Stick this in your pipe $0
+
+ # A multi-line entry. The text is sent as one line.
+ #
+ /^noddy@connect.com.au$/
+ 550 This user is a funny one. You really don't want to send mail to
+ them as it only makes their head spin.
+
+<b>SEE</b> <b>ALSO</b>
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
+
+<b>AUTHOR(S)</b>
+ The PCRE table lookup code was originally written by:
+ Andrew McNamara
+ andrewm@connect.com.au
+ connect.com.au Pty. Ltd.
+ Level 3, 213 Miller St
+ North Sydney, NSW, Australia
+
+ Adopted and adapted by:
+ Wietse Venema
+ IBM T.J. Watson Research
+ P.O. Box 704
+ Yorktown Heights, NY 10598, USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 2
+
+
</pre> </body> </html>
execute commands with root privileges, or with the
privileges of the mail system owner. If <i>groupname</i>
is specified, the corresponding group ID is used
- instead of the group ID of of <i>username</i>.
+ instead of the group ID of <i>username</i>.
<html> <head> </head> <body> <pre>
+
+
+
+REGEXP_TABLE(5) REGEXP_TABLE(5)
+
+
+<b>NAME</b>
+ regexp_table - format of Postfix regular expression tables
+
+<b>SYNOPSIS</b>
+ regexp:/etc/postfix/filename
+
+<b>DESCRIPTION</b>
+ The Postfix mail system uses optional tables for address
+ rewriting or mail routing. These tables usually are in <b>dbm</b>
+ or <b>db</b> format. Alternatively, lookup tables can be speci-
+ fied in POSIX regular expression form.
+
+ To find out what types of lookup tables your Postfix sys-
+ tem supports use the <b>postconf</b> <b>-m</b> command.
+
+ The general form of a Postfix regular expression table is:
+
+ blanks and comments
+ Blank lines are ignored, as are lines beginning
+ with `#'.
+
+ <i>pattern</i> <i>result</i>
+ When <i>pattern</i> matches a search string, use the cor-
+ responding <i>result</i>. A line that starts with white
+ space continues the preceding line.
+
+ <i>pattern1!pattern2</i> <i>result</i>
+ Matches <i>pattern1</i> but not <i>pattern2</i>.
+
+ Each pattern is a regular expression enclosed by a pair of
+ delimiters. The regular expression syntax is described in
+ <i>re_format</i>(7). The expression delimiter can be any charac-
+ ter, except whitespace or characters that have special
+ meaning (traditionally the forward slash is used). The
+ regular expression can contain whitespace.
+
+ By default, matching is case-insensitive, although follow-
+ ing the second slash with an `i' flag will reverse this.
+ Other flags are `x' (disable extended expression syntax),
+ and `m' (enable multi-line mode).
+
+ Each pattern is applied to the entire string being looked
+ up. 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, and <i>user@domain</i> mail addresses are
+ not broken up into their <i>user</i> and <i>domain</i> constituent
+ parts, nor is <i>user+foo</i> broken up into <i>user</i> and <i>foo</i>.
+
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+
+ Substitution of sub-strings from the matched expression is
+
+
+
+ 1
+
+
+
+
+
+REGEXP_TABLE(5) REGEXP_TABLE(5)
+
+
+ possible using $1, $2, etc.. The macros in the replacement
+ string may need to be written as ${n} or $(n) if they
+ aren't followed by whitespace.
+
+<b>EXAMPLES</b>
+ # Disallow sender-specified routing. This is a must if you relay mail
+ # for other domains.
+ /[%!@].*[%!@]/ 550 Sender-specified routing rejected
+
+ # Postmaster is OK, that way they can talk to us about how to fix
+ # their problem.
+ /^postmaster@.*$/ OK
+
+ # Protect your outgoing majordomo exploders
+ /^(.*)-outgoing@(.*)$/!/^owner-.*/ 550 Use ${1}@${2} instead
+
+<b>SEE</b> <b>ALSO</b>
+ <a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
+
+<b>AUTHOR(S)</b>
+ The regexp table lookup code was originally written by:
+ LaMont Jones
+ lamont@hp.com
+
+ That code was based on the PCRE dictionary contributed by:
+ Andrew McNamara
+ andrewm@connect.com.au
+ connect.com.au Pty. Ltd.
+ Level 3, 213 Miller St
+ North Sydney, NSW, Australia
+
+ Adopted and adapted by:
+ Wietse Venema
+ IBM T.J. Watson Research
+ P.O. Box 704
+ Yorktown Heights, NY 10598, USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 2
+
+
</pre> </body> </html>
is used in "user has moved to <i>new_location</i>" bounce mes-
sages.
- The file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
- result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
- fast searching by the mail system. After an update issue a
- <b>postfix</b> <b>reload</b> command to make the change visible.
+ Normally, the file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> com-
+ mand. The result, an indexed file in <b>dbm</b> or <b>db</b> format, is
+ used for fast searching by the mail system. After an
+ update issue a <b>postfix</b> <b>reload</b> command to make the change
+ visible.
+
+ When the table is provided via other means such as NIS,
+ LDAP or SQL, the same lookups are done as for ordinary
+ indexed files.
+
+ Alternatively, the table can be provided as a regular-
+ expression map where patterns are given as regular expres-
+ sions. In that case, the lookups are done in a slightly
+ different way as described below.
Table lookups are case insensitive.
+<b>TABLE</b> <b>FORMAT</b>
The format of the table is as follows:
<b>o</b> Blank lines are ignored, as are lines beginning
such as an email address, or perhaps a street
address or telephone number.
- The <i>key</i> field is one of the following:
+ With lookups from indexed files such as DB or DBM, or from
+ networked tables such as NIS, LDAP or SQL, the <i>key</i> field
+ is one of the following:
<i>user</i>@<i>domain</i>
Matches <i>user</i>@<i>domain</i>. This form has precedence over
@<i>domain</i>
Matches every address in <i>domain</i>. This form has the
- lowest precedence.
-<b>ADDRESS</b> <b>EXTENSION</b>
- When the search fails, and the address localpart contains
- the optional recipient delimiter (e.g., <i>user+foo</i>@<i>domain</i>),
- the search is repeated for the unextended address (e.g.
- <i>user</i>@<i>domain</i>).
-<b>BUGS</b>
- The table format does not understand quoting conventions.
-<b>CONFIGURATION</b> <b>PARAMETERS</b>
- The following <b>main.cf</b> parameters are especially relevant
+ 1
- 1
+RELOCATED(5) RELOCATED(5)
+ lowest precedence.
-RELOCATED(5) RELOCATED(5)
+<b>ADDRESS</b> <b>EXTENSION</b>
+ When the search fails, and the address localpart contains
+ the optional recipient delimiter (e.g., <i>user+foo</i>@<i>domain</i>),
+ the search is repeated for the unextended address (e.g.
+ <i>user</i>@<i>domain</i>).
+
+<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
+ This section describes how the table lookups change when
+ the table is given in the form of regular expressions. For
+ a description of regular expression lookup table syntax,
+ see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
+
+ Each pattern is a regular expression that is applied to
+ the entire address being looked up. Thus, <i>user@domain</i> mail
+ addresses are not broken up into their <i>user</i> and <i>@domain</i>
+ constituent parts, nor is <i>user+foo</i> broken up into <i>user</i> and
+ <i>foo</i>.
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+ Results are the same as with normal indexed file lookups,
+ with the additional feature that parenthesized substrings
+ from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
+
+<b>BUGS</b>
+ The table format does not understand quoting conventions.
+
+<b>CONFIGURATION</b> <b>PARAMETERS</b>
+ The following <b>main.cf</b> parameters are especially relevant
to this topic. See the Postfix <b>main.cf</b> file for syntax
details and for default values. Use the <b>postfix</b> <b>reload</b>
command after a configuration change.
<b>myorigin</b>
The domain that is appended to locally-posted mail.
+
+
+
+
+ 2
+
+
+
+
+
+RELOCATED(5) RELOCATED(5)
+
+
<b>SEE</b> <b>ALSO</b>
<a href="postmap.1.html">postmap(1)</a> create lookup table
+ <a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
<b>LICENSE</b>
The Secure Mailer license must be distributed with this
- 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 3
</pre> </body> </html>
overflows into the message body. This limit is enforced by the <a
href="cleanup.8.html"> cleanup</a> header rewriting code.
+<p>
+
+<dt> <b>extract_recipient_limit</b> (default: 10240 recipients)
+
+<dd> How many recipients Postfix will extract from message headers
+before it gives up. This limits the damage that a run-away program
+can do with "sendmail -t".
+
</dl>
<p>
relay hosts. The mapping is used by the <a href="trivial-rewrite.8.html"><b>trivial-rewrite</b>(8)</a>
daemon.
- The file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
- result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
- fast searching by the mail system. After updating this
- table, issue the <b>postfix</b> <b>reload</b> command to make the change
- visible.
-
+ Normally, the file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> com-
+ mand. The result, an indexed file in <b>dbm</b> or <b>db</b> format, is
+ used for fast searching by the mail system. After updating
+ this table, issue the <b>postfix</b> <b>reload</b> command to make the
+ change visible.
+
+ When the table is provided via other means such as NIS,
+ LDAP or SQL, the same lookups are done as for ordinary
+ indexed files.
+
+ Alternatively, the table can be provided as a regular-
+ expression map where patterns are given as regular expres-
+ sions. In that case, the lookups are done in a slightly
+ different way as described below.
+
+<b>TABLE</b> <b>FORMAT</b>
The format of the transport table is as follows:
blanks and comments
- Blank lines are ignored, as are lines beginning
+ Blank lines are ignored, as are lines beginning
with `#'.
+ <i>pattern</i> <i>result</i>
+ When <i>pattern</i> matches the domain, use the corre-
+ sponding <i>result</i>.
+
+ With lookups from indexed files such as DB or DBM, or from
+ networked tables such as NIS, LDAP or SQL, patterns are
+ tried in the order as listed below:
+
<i>domain</i> <i>transport</i>:<i>nexthop</i>
Mail for <i>domain</i> is delivered through <i>transport</i> to
<i>nexthop</i>.
Note: transport map entries take precedence over domains
specified in the <b>mydestination</b> parameter. If you use the
optional transport map, it may be safer to specify
- explicit entries for all domains specified in <b>mydestina-</b>
- <b>tion</b>, for example:
+ explicit entries for all domains specified in
+
+
+
+ 1
+
+
+
+
+
+TRANSPORT(5) TRANSPORT(5)
+
+
+ <b>mydestination</b>, for example:
- <b>hostname.my.domain</b> <b>local:</b>
+ <b>hostname.my.domain</b> <b>local:</b>
<b>localhost.my.domain</b> <b>local:</b>
The interpretation of the <i>nexthop</i> field is transport
<b>foo.org</b> <b>uucp:foo</b>
<b>.foo.org</b> <b>uucp:foo</b>
-
-
- 1
-
-
-
-
-
-TRANSPORT(5) TRANSPORT(5)
-
-
When no <i>nexthop</i> host name is specified, the destination domain
name is used instead. For example, the following directs mail for
<i>user</i>@<b>foo.org</b> via the <b>slow</b> transport to a mail
This causes all mail for <i>user</i>@<i>anything</i><b>foo.org</b>
to be bounced.
+
+
+
+ 2
+
+
+
+
+
+TRANSPORT(5) TRANSPORT(5)
+
+
+<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
+ This section describes how the table lookups change when
+ the table is given in the form of regular expressions. For
+ a description of regular expression lookup table syntax,
+ see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
+
+ Each pattern is a regular expression that is applied to
+ the entire domain being looked up. Thus, <i>some.domain.hier-</i>
+ <i>archy</i> is not broken up into parent domains.
+
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+
+ Results are the same as with normal indexed file lookups,
+ with the additional feature that parenthesized substrings
+ from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
+
<b>CONFIGURATION</b> <b>PARAMETERS</b>
The following <b>main.cf</b> parameters are especially relevant
to this topic. See the Postfix <b>main.cf</b> file for syntax
The default host to send to when no transport table
entry matches.
-
-
-
- 2
-
-
-
-
-
-TRANSPORT(5) TRANSPORT(5)
-
-
<b>SEE</b> <b>ALSO</b>
<a href="postmap.1.html">postmap(1)</a> create mapping table
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> rewrite and resolve addresses
+ <a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
<b>LICENSE</b>
The Secure Mailer license must be distributed with this
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
3
mapping to rewrite header and envelope addresses in gen-
eral.
- The file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
- result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
- fast searching by the mail system. After an update it may
- take a minute or so before the change becomes visible.
- Issue a <b>postfix</b> <b>reload</b> command to eliminate the delay.
-
+ Normally, the file serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> com-
+ mand. The result, an indexed file in <b>dbm</b> or <b>db</b> format, is
+ used for fast searching by the mail system. After an
+ update it may take a minute or so before the change
+ becomes visible. Issue a <b>postfix</b> <b>reload</b> command to elimi-
+ nate the delay.
+
+ When the table is provided via other means such as NIS,
+ LDAP or SQL, the same lookups are done as for ordinary
+ indexed files.
+
+ Alternatively, the table can be provided as a regular-
+ expression map where patterns are given as regular expres-
+ sions. In that case, the lookups are done in a slightly
+ different way as described below.
+
+<b>TABLE</b> <b>FORMAT</b>
Typical support for a virtual domain looks like the fol-
lowing:
Blank lines are ignored, as are lines beginning
with `#'.
- <i>user</i>@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
- Mail for <i>user</i>@<i>domain</i> is redirected to <i>address</i>.
- This form has the highest precedence.
- <i>user</i> <i>address,</i> <i>address,</i> <i>...</i>
- Mail for <i>user</i>@<i>site</i> is redirected to <i>address</i> when
- <i>site</i> is equal to $<b>myorigin</b>, when <i>site</i> is listed in
- $mydestination, or when it is listed in
- $<i>inet_interfaces</i>.
-
- This functionality overlaps with functionality of
- the local <i>alias</i>(5) database. The difference is that
VIRTUAL(5) VIRTUAL(5)
- <b>virtual</b> mapping can be applied to non-local
+ <i>pattern</i> <i>result</i>
+ When <i>pattern</i> matches a mail address, replace it by
+ the corresponding <i>result</i>.
+
+ With lookups from indexed files such as DB or DBM, or from
+ networked tables such as NIS, LDAP or SQL, patterns are
+ tried in the order as listed below:
+
+ <i>user</i>@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
+ Mail for <i>user</i>@<i>domain</i> is redirected to <i>address</i>.
+ This form has the highest precedence.
+
+ <i>user</i> <i>address,</i> <i>address,</i> <i>...</i>
+ Mail for <i>user</i>@<i>site</i> is redirected to <i>address</i> when
+ <i>site</i> is equal to $<b>myorigin</b>, when <i>site</i> is listed in
+ $mydestination, or when it is listed in
+ $<i>inet_interfaces</i>.
+
+ This functionality overlaps with functionality of
+ the local <i>alias</i>(5) database. The difference is that
+ <b>virtual</b> mapping can be applied to non-local
addresses.
@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
- Mail for any user in <i>domain</i> is redirected to
+ Mail for any user in <i>domain</i> is redirected to
<i>address</i>. This form has the lowest precedence.
- In all the above forms, when <i>address</i> has the form @<i>other-</i>
- <i>domain</i>, the result is the same user in <i>otherdomain</i>. This
+ In all the above forms, when <i>address</i> has the form @<i>other-</i>
+ <i>domain</i>, the result is the same user in <i>otherdomain</i>. This
works for the first address in the expansion only.
<b>ADDRESS</b> <b>EXTENSION</b>
- When the search fails, and the address localpart contains
- the optional recipient delimiter (e.g., <i>user+foo</i>@<i>domain</i>),
- the search is repeated for the unextended address (e.g.
+ When the search fails, and the address localpart contains
+ the optional recipient delimiter (e.g., <i>user+foo</i>@<i>domain</i>),
+ the search is repeated for the unextended address (e.g.
<i>user</i>@<i>domain</i>), and the unmatched address extension is prop-
- agated to the result of expansion. The matching order is:
+ agated to the result of expansion. The matching order is:
<i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>user+foo</i>, <i>user</i>, and @<i>domain</i>.
+<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
+ This section describes how the table lookups change when
+ the table is given in the form of regular expressions. For
+ a description of regular expression lookup table syntax,
+ see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
+
+ Each pattern is a regular expression that is applied to
+ the entire address being looked up. Thus, <i>user@domain</i> mail
+ addresses are not broken up into their <i>user</i> and <i>@domain</i>
+ constituent parts, nor is <i>user+foo</i> broken up into <i>user</i> and
+ <i>foo</i>.
+
+ Patterns are applied in the order as specified in the
+ table, until a pattern is found that matches the search
+ string.
+
+
+
+ 2
+
+
+
+
+
+VIRTUAL(5) VIRTUAL(5)
+
+
+ Results are the same as with normal indexed file lookups,
+ with the additional feature that parenthesized substrings
+ from the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
+
<b>BUGS</b>
- The table format does not understand quoting conventions.
+ The table format does not understand quoting conventions.
<b>CONFIGURATION</b> <b>PARAMETERS</b>
- The following <b>main.cf</b> parameters are especially relevant
- to this topic. See the Postfix <b>main.cf</b> file for syntax
- details and for default values. Use the <b>postfix</b> <b>reload</b>
+ The following <b>main.cf</b> parameters are especially relevant
+ to this topic. See the Postfix <b>main.cf</b> file for syntax
+ details and for default values. Use the <b>postfix</b> <b>reload</b>
command after a configuration change.
<b>virtual</b><i>_</i><b>maps</b>
Other parameters of interest:
<b>inet</b><i>_</i><b>interfaces</b>
- The network interface addresses that this system
+ The network interface addresses that this system
receives mail on.
<b>mydestination</b>
- List of domains that this mail system considers
+ List of domains that this mail system considers
local.
<b>myorigin</b>
<b>SEE</b> <b>ALSO</b>
<a href="cleanup.8.html">cleanup(8)</a> canonicalize and enqueue mail
<a href="postmap.1.html">postmap(1)</a> create mapping table
+ <a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
+ <a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
<b>LICENSE</b>
- The Secure Mailer license must be distributed with this
-
-
-
- 2
-
-
-
-
-
-VIRTUAL(5) VIRTUAL(5)
-
-
+ The Secure Mailer license must be distributed with this
software.
<b>AUTHOR(S)</b>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
3
.nf
.ad
.fi
-With lookups from indexed files, patterns are tried in the order as
+With lookups from indexed files such as DB or DBM, or from networked
+tables such as NIS, LDAP or SQL, patterns are tried in the order as
listed below:
.IP \fIuser\fR@\fIdomain\fR
Matches the specified mail address.
Each pattern is a regular expression that is applied to the entire
string being looked up. Depending on the application, that string
is an entire client hostname, an entire client IP address, or an
-entire mail address. Patterns are applied in order as specified,
-until a pattern is found that matches the search string.
+entire mail address. Thus, no parent domain or parent network search
+is done, and \fIuser@domain\fR mail addresses are not broken up into
+their \fIuser@\fR and \fIdomain\fR constituent parts.
-In contrast to lookups from indexed files, no parent domain or
-parent network search is done with regular expression tables,
-and \fIuser@domain\fR mail addresses are not broken up into their
-\fIuser@\fR and \fIdomain\fR constituent parts.
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
Actions are the same as with normal indexed file lookups, with
the additional feature that parenthesized substrings from the
postmap(1) create mapping table
smtpd(8) smtp server
pcre_table(5) format of PCRE tables
-regexp_table(5) format of POSIX regexp tables
+regexp_table(5) format of POSIX regular expression tables
.SH LICENSE
.na
.nf
local and non-local addresses. The mapping is used by the
\fBcleanup\fR(8) daemon. The address mapping is recursive.
-The file serves as input to the \fBpostmap\fR(1) command. The result,
-an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-fast searching by the mail system. After an update
+Normally, the file serves as input to the \fBpostmap\fR(1) command.
+The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+is used for fast searching by the mail system. After an update
it may take a minute or so before the change becomes visible.
Issue a \fBpostfix reload\fR command to eliminate the delay.
+When the table is provided via other means such as NIS, LDAP
+or SQL, the same lookups are done as for ordinary indexed files.
+
+Alternatively, the table can be provided as a regular-expression
+map where patterns are given as regular expressions. In that case,
+the lookups are done in a slightly different way as described below.
+
The \fBcanonical\fR mapping affects both message header addresses
(i.e. addresses that appear inside messages) and message envelope
addresses (for example, the addresses that are used in SMTP protocol
The \fBcanonical\fR mapping is not to be confused with local aliasing.
Use the \fBaliases\fR(5) map for that purpose.
-
-The format of the \fBcanonical\fR table is as follows, mappings
-being tried in the order as listed in this manual page:
+.SH TABLE FORMAT
+.na
+.nf
+.ad
+.fi
+The format of the \fBcanonical\fR table is as follows:
.IP "blanks and comments"
Blank lines are ignored, as are lines beginning with `#'.
+.IP "\fIpattern result\fR"
+When \fIpattern\fR matches a mail address, replace it by the
+corresponding \fIresult\fR.
+.PP
+With lookups from indexed files such as DB or DBM, or from networked
+tables such as NIS, LDAP or SQL, patterns are tried in the order as
+listed below:
.IP "\fIuser\fR@\fIdomain address\fR"
\fIuser\fR@\fIdomain\fR is replaced by \fIaddress\fR. This form
has the highest precedence.
to the result of table lookup. The matching order is:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR,
\fIuser+foo\fR, \fIuser\fR, and @\fIdomain\fR.
+.SH REGULAR EXPRESSION TABLES
+.na
+.nf
+.ad
+.fi
+This section describes how the table lookups change when the table
+is given in the form of regular expressions. For a description of
+regular expression lookup table syntax, see \fBregexp_table\fR(5)
+or \fBpcre_table\fR(5).
+
+Each pattern is a regular expression that is applied to the entire
+address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Results are the same as with normal indexed file lookups, with
+the additional feature that parenthesized substrings from the
+pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
.SH BUGS
.ad
.fi
cleanup(8) canonicalize and enqueue mail
postmap(1) create mapping table
virtual(5) virtual domain mapping
+pcre_table(5) format of PCRE tables
+regexp_table(5) format of POSIX regular expression tables
.SH LICENSE
.na
.nf
+.TH PCRE_TABLE 5
+.ad
+.fi
+.SH NAME
+pcre_table
+\-
+format of Postfix PCRE tables
+.SH SYNOPSIS
+.na
+.nf
+pcre:/etc/postfix/filename
+.SH DESCRIPTION
+.ad
+.fi
+The Postfix mail system uses optional tables for address
+rewriting or mail routing. These tables usually are in
+\fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
+can be specified in Perl Compatible Regular Expression form.
+
+To find out what types of lookup tables your Postfix system
+supports use the \fBpostconf -m\fR command.
+
+The general form of a PCRE table is:
+.IP "blanks and comments"
+Blank lines are ignored, as are lines beginning with `#'.
+.IP "\fIpattern result\fR"
+When \fIpattern\fR matches a search string, use the corresponding
+\fIresult\fR. A line that starts with white space continues the
+preceding line.
+.PP
+Each pattern is a perl-like regular expression. The expression
+delimiter can be any character, except whitespace or characters
+that have special meaning (traditionally the forward slash is used).
+The regular expression can contain whitespace.
+
+By default, matching is case-insensitive, although following
+the second slash with an `i' flag will reverse this. Other flags
+are supported, but the only other useful one is `U', which makes
+matching ungreedy (see PCRE documentation and source for more
+info).
+
+Each pattern is applied to the entire string being looked up.
+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, and
+\fIuser@domain\fR mail addresses are not broken up into their
+\fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
+broken up into \fIuser\fR and \fIfoo\fR.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Substitution of sub-strings from the matched expression is
+possible using the conventional perl syntax ($1, $2, etc.). The
+macros in the replacement string may need to be written as ${n}
+or $(n) if they aren't followed by whitespace.
+.SH EXAMPLES
+.na
+.nf
+# Protect your outgoing majordomo exploders
+/^(?!owner-)(.*)-outgoing@(my\.domain)$/ 550 Use ${1}@${2} instead
+
+# Bounce friend@whatever, except when whatever is our domain (you would
+# be better just bouncing all friend@ mail - this is just an example).
+/^friend@(?!my\.domain).*$/ 550 Stick this in your pipe $0
+
+# A multi-line entry. The text is sent as one line.
+#
+/^noddy@connect\.com\.au$/
+\ 550 This user is a funny one. You really don't want to send mail to
+\ them as it only makes their head spin.
+.SH SEE ALSO
+.na
+.nf
+regexp_table(5) format of POSIX regular expression tables
+.SH AUTHOR(S)
+.na
+.nf
+The PCRE table lookup code was originally written by:
+Andrew McNamara
+andrewm@connect.com.au
+connect.com.au Pty. Ltd.
+Level 3, 213 Miller St
+North Sydney, NSW, Australia
+
+Adopted and adapted by:
+Wietse Venema
+IBM T.J. Watson Research
+P.O. Box 704
+Yorktown Heights, NY 10598, USA
+.TH REGEXP_TABLE 5
+.ad
+.fi
+.SH NAME
+regexp_table
+\-
+format of Postfix regular expression tables
+.SH SYNOPSIS
+.na
+.nf
+regexp:/etc/postfix/filename
+.SH DESCRIPTION
+.ad
+.fi
+The Postfix mail system uses optional tables for address
+rewriting or mail routing. These tables usually are in
+\fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
+can be specified in POSIX regular expression form.
+
+To find out what types of lookup tables your Postfix system
+supports use the \fBpostconf -m\fR command.
+
+The general form of a Postfix regular expression table is:
+.IP "blanks and comments"
+Blank lines are ignored, as are lines beginning with `#'.
+.IP "\fIpattern result\fR"
+When \fIpattern\fR matches a search string, use the corresponding
+\fIresult\fR. A line that starts with white space continues the
+preceding line.
+.IP "\fIpattern1!pattern2 result\fR"
+Matches \fIpattern1\fR but not \fIpattern2\fR.
+.PP
+Each pattern is a regular expression enclosed by a pair of delimiters.
+The regular expression syntax is described in \fIre_format\fR(7).
+The expression delimiter can be any character, except whitespace
+or characters that have special meaning (traditionally the forward
+slash is used). The regular expression can contain whitespace.
+
+By default, matching is case-insensitive, although following
+the second slash with an `i' flag will reverse this. Other flags
+are `x' (disable extended expression syntax), and `m' (enable
+multi-line mode).
+
+Each pattern is applied to the entire string being looked up.
+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, and
+\fIuser@domain\fR mail addresses are not broken up into their
+\fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
+broken up into \fIuser\fR and \fIfoo\fR.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Substitution of sub-strings from the matched expression is
+possible using $1, $2, etc.. The macros in the replacement string
+may need to be written as ${n} or $(n) if they aren't followed
+by whitespace.
+.SH EXAMPLES
+.na
+.nf
+# Disallow sender-specified routing. This is a must if you relay mail
+# for other domains.
+/[%!@].*[%!@]/ 550 Sender-specified routing rejected
+
+# Postmaster is OK, that way they can talk to us about how to fix
+# their problem.
+/^postmaster@.*$/ OK
+
+# Protect your outgoing majordomo exploders
+/^(.*)-outgoing@(.*)$/!/^owner-.*/ 550 Use ${1}@${2} instead
+.SH SEE ALSO
+.na
+.nf
+pcre_table(5) format of PCRE tables
+.SH AUTHOR(S)
+.na
+.nf
+The regexp table lookup code was originally written by:
+LaMont Jones
+lamont@hp.com
+
+That code was based on the PCRE dictionary contributed by:
+Andrew McNamara
+andrewm@connect.com.au
+connect.com.au Pty. Ltd.
+Level 3, 213 Miller St
+North Sydney, NSW, Australia
+
+Adopted and adapted by:
+Wietse Venema
+IBM T.J. Watson Research
+P.O. Box 704
+Yorktown Heights, NY 10598, USA
The optional \fBrelocated\fR file provides the information that is
used in "user has moved to \fInew_location\fR" bounce messages.
-The file serves as input to the \fBpostmap\fR(1) command. The result,
-an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-fast searching by the mail system. After an update
+Normally, the file serves as input to the \fBpostmap\fR(1) command.
+The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+is used for fast searching by the mail system. After an update
issue a \fBpostfix reload\fR command to make the change visible.
-Table lookups are case insensitive.
+When the table is provided via other means such as NIS, LDAP
+or SQL, the same lookups are done as for ordinary indexed files.
+
+Alternatively, the table can be provided as a regular-expression
+map where patterns are given as regular expressions. In that case,
+the lookups are done in a slightly different way as described below.
+Table lookups are case insensitive.
+.SH TABLE FORMAT
+.na
+.nf
+.ad
+.fi
The format of the table is as follows:
.IP \(bu
Blank lines are ignored, as are lines beginning with `#'.
Where \fInew_location\fR specifies contact information such as
an email address, or perhaps a street address or telephone number.
.PP
-The \fIkey\fR field is one of the following:
+With lookups from indexed files such as DB or DBM, or from networked
+tables such as NIS, LDAP or SQL, the \fIkey\fR field is one of the
+following:
.IP \fIuser\fR@\fIdomain\fR
Matches \fIuser\fR@\fIdomain\fR. This form has precedence over all
other forms.
optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
the search is repeated for the unextended address (e.g.
\fIuser\fR@\fIdomain\fR).
+.SH REGULAR EXPRESSION TABLES
+.na
+.nf
+.ad
+.fi
+This section describes how the table lookups change when the table
+is given in the form of regular expressions. For a description of
+regular expression lookup table syntax, see \fBregexp_table\fR(5)
+or \fBpcre_table\fR(5).
+
+Each pattern is a regular expression that is applied to the entire
+address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Results are the same as with normal indexed file lookups, with
+the additional feature that parenthesized substrings from the
+pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
.SH BUGS
.ad
.fi
.na
.nf
postmap(1) create lookup table
+pcre_table(5) format of PCRE tables
+regexp_table(5) format of POSIX regular expression tables
.SH LICENSE
.na
.nf
hierarchies to message delivery transports and/or relay hosts. The
mapping is used by the \fBtrivial-rewrite\fR(8) daemon.
-The file serves as input to the \fBpostmap\fR(1) command. The result,
-an indexed file in \fBdbm\fR or \fBdb\fR format, is used for
-fast searching by the mail system. After updating this table,
+Normally, the file serves as input to the \fBpostmap\fR(1) command.
+The result, an indexed file in \fBdbm\fR or \fBdb\fR format, is used
+for fast searching by the mail system. After updating this table,
issue the \fBpostfix reload\fR command to make the change visible.
+When the table is provided via other means such as NIS, LDAP
+or SQL, the same lookups are done as for ordinary indexed files.
+
+Alternatively, the table can be provided as a regular-expression
+map where patterns are given as regular expressions. In that case,
+the lookups are done in a slightly different way as described below.
+.SH TABLE FORMAT
+.na
+.nf
+.ad
+.fi
The format of the transport table is as follows:
.IP "blanks and comments"
Blank lines are ignored, as are lines beginning with `#'.
+.IP "\fIpattern result\fR"
+When \fIpattern\fR matches the domain, use the corresponding
+\fIresult\fR.
+.PP
+With lookups from indexed files such as DB or DBM, or from networked
+tables such as NIS, LDAP or SQL, patterns are tried in the order as
+listed below:
.IP "\fIdomain transport\fR:\fInexthop\fR"
Mail for \fIdomain\fR is delivered through \fItransport\fR to
\fInexthop\fR.
for example:
.ti +5
-\fBhostname.my.domain local:\fR
+\fBhostname.my.domain local:\fR
.ti +5
\fBlocalhost.my.domain local:\fR
This causes all mail for \fIuser\fR@\fIanything\fBfoo.org\fR
to be bounced.
+.SH REGULAR EXPRESSION TABLES
+.na
+.nf
+.ad
+.fi
+This section describes how the table lookups change when the table
+is given in the form of regular expressions. For a description of
+regular expression lookup table syntax, see \fBregexp_table\fR(5)
+or \fBpcre_table\fR(5).
+
+Each pattern is a regular expression that is applied to the entire
+domain being looked up. Thus, \fIsome.domain.hierarchy\fR is not
+broken up into parent domains.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Results are the same as with normal indexed file lookups, with
+the additional feature that parenthesized substrings from the
+pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
.SH CONFIGURATION PARAMETERS
.na
.nf
.nf
postmap(1) create mapping table
trivial-rewrite(8) rewrite and resolve addresses
+pcre_table(5) format of PCRE tables
+regexp_table(5) format of POSIX regular expression tables
.SH LICENSE
.na
.nf
Think Sendmail rule set \fBS0\fR, if you like. Use \fBcanonical\fR(5)
mapping to rewrite header and envelope addresses in general.
-The file serves as input to the \fBpostmap\fR(1) command. The
-result, an indexed file in \fBdbm\fR or \fBdb\fR format,
+Normally, the file serves as input to the \fBpostmap\fR(1) command.
+The result, an indexed file in \fBdbm\fR or \fBdb\fR format,
is used for fast searching by the mail system. After an update
it may take a minute or so before the change becomes visible.
Issue a \fBpostfix reload\fR command to eliminate the delay.
+When the table is provided via other means such as NIS, LDAP
+or SQL, the same lookups are done as for ordinary indexed files.
+
+Alternatively, the table can be provided as a regular-expression
+map where patterns are given as regular expressions. In that case,
+the lookups are done in a slightly different way as described below.
+.SH TABLE FORMAT
+.na
+.nf
+.ad
+.fi
Typical support for a virtual domain looks like the following:
.in +4
tried in the order as listed in this manual page:
.IP "blanks and comments"
Blank lines are ignored, as are lines beginning with `#'.
+.IP "\fIpattern result\fR"
+When \fIpattern\fR matches a mail address, replace it by the
+corresponding \fIresult\fR.
+.PP
+With lookups from indexed files such as DB or DBM, or from networked
+tables such as NIS, LDAP or SQL, patterns are tried in the order as
+listed below:
.IP "\fIuser\fR@\fIdomain address, address, ...\fR"
Mail for \fIuser\fR@\fIdomain\fR is redirected to \fIaddress\fR.
This form has the highest precedence.
propagated to the result of expansion. The matching order is:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR,
\fIuser+foo\fR, \fIuser\fR, and @\fIdomain\fR.
+.SH REGULAR EXPRESSION TABLES
+.na
+.nf
+.ad
+.fi
+This section describes how the table lookups change when the table
+is given in the form of regular expressions. For a description of
+regular expression lookup table syntax, see \fBregexp_table\fR(5)
+or \fBpcre_table\fR(5).
+
+Each pattern is a regular expression that is applied to the entire
+address being looked up. Thus, \fIuser@domain\fR mail addresses are not
+broken up into their \fIuser\fR and \fI@domain\fR constituent parts,
+nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
+
+Patterns are applied in the order as specified in the table, until a
+pattern is found that matches the search string.
+
+Results are the same as with normal indexed file lookups, with
+the additional feature that parenthesized substrings from the
+pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on.
.SH BUGS
.ad
.fi
.nf
cleanup(8) canonicalize and enqueue mail
postmap(1) create mapping table
+pcre_table(5) format of PCRE tables
+regexp_table(5) format of POSIX regular expression tables
.SH LICENSE
.na
.nf
Limit the number of envelope recipients that are remembered.
.IP \fBheader_size_limit\fR
Limit the amount of memory in bytes used to process a message header.
+.IP \fBextract_recipient_limit\fR
+Limit the amount of recipients extracted from message headers.
.SH SEE ALSO
.na
.nf
commands with root privileges, or with the privileges of the
mail system owner. If \fIgroupname\fR is specified, the
corresponding group ID is used instead of the group ID of
-of \fIusername\fR.
+\fIusername\fR.
.IP "\fBargv\fR=\fIcommand\fR... (required)"
The command to be executed. This must be specified as the
last command attribute.
# code; this has not been tested thoroughly, however.
#
# Will produce useless files when fed with anything that is
-# not C program text. This does not imply a judgement about
+# not C program text. This does not imply a judgment about
# C programs in general.
# AUTHOR(S)
# W.Z. Venema
*/
signal(SIGPIPE, SIG_IGN);
+ /*
+ * Don't die for frivolous reasons.
+ */
+#ifdef SIGXFSZ
+ signal(SIGXFSZ, SIG_IGN);
+#endif
+
/*
* May need this every now and then.
*/
*/
signal(SIGPIPE, SIG_IGN);
+ /*
+ * Don't die for frivolous reasons.
+ */
+#ifdef SIGXFSZ
+ signal(SIGXFSZ, SIG_IGN);
+#endif
+
/*
* May need this every now and then.
*/
*/
signal(SIGPIPE, SIG_IGN);
+ /*
+ * Don't die for frivolous reasons.
+ */
+#ifdef SIGXFSZ
+ signal(SIGXFSZ, SIG_IGN);
+#endif
+
/*
* May need this every now and then.
*/
/* commands with root privileges, or with the privileges of the
/* mail system owner. If \fIgroupname\fR is specified, the
/* corresponding group ID is used instead of the group ID of
-/* of \fIusername\fR.
+/* \fIusername\fR.
/* .IP "\fBargv\fR=\fIcommand\fR... (required)"
/* The command to be executed. This must be specified as the
/* last command attribute.
# Extract initialization tables from actual source code.
-/static CONFIG_INT_TABLE/,/};/ {
+/^(static| )*CONFIG_INT_TABLE .*{/,/};/ {
if ($1 ~ /VAR/) {
print "int " substr($3,2,length($3)-2) ";" > "int_vars.h"
print | "sort -u >int_table.h"
}
}
-/static CONFIG_STR_TABLE/,/};/ {
+/^(static| )*CONFIG_STR_TABLE .*{/,/};/ {
if ($1 ~ /VAR/) {
print "char *" substr($3,2,length($3)-2) ";" > "str_vars.h"
print | "sort -u >str_table.h"
}
}
-/static CONFIG_BOOL_TABLE/,/};/ {
+/^(static| )*CONFIG_BOOL_TABLE .*{/,/};/ {
if ($1 ~ /VAR/) {
print "int " substr($3,2,length($3)-2) ";" > "bool_vars.h"
print | "sort -u >bool_table.h"
* mkdir() operation is the main reason for this command to run
* with postfix privilege. The mail_queue_mkdirs() routine could
* be fixed to use the "right" privilege, but it is a good idea
- * to do everying with the postfix owner privileges regardless,
+ * to do everything with the postfix owner privileges regardless,
* in order to limit the amount of damage that we can do.
*/
(void) mail_queue_path(wanted_path, queue_name, path);
{
char *err;
int narg;
- off_t size = 0;
char *arg;
+ state->msg_size = 0;
+
/*
* Sanity checks. XXX Ignore bad SIZE= values until we can reliably and
* portably detect overflows while converting from string to off_t.
|| strcasecmp(arg, "BODY=7BIT") == 0) {
/* void */ ;
} else if (strncasecmp(arg, "SIZE=", 5) == 0) {
- if ((size = off_cvt_string(arg + 5)) < 0)
- size = 0;
+ if ((state->msg_size = off_cvt_string(arg + 5)) < 0)
+ state->msg_size = 0;
} else {
state->error_mask |= MAIL_ERROR_PROTOCOL;
smtpd_chat_reply(state, "555 Unsupported option: %s", arg);
smtpd_chat_reply(state, "%s", err);
return (-1);
}
- if ((err = smtpd_check_size(state, size)) != 0) {
+ if ((SMTPD_STAND_ALONE(state) || var_smtpd_delay_reject == 0)
+ && (err = smtpd_check_size(state, state->msg_size)) != 0) {
smtpd_chat_reply(state, "%s", err);
return (-1);
}
char *protocol;
char *where;
int recursion;
+ off_t msg_size;
} SMTPD_STATE;
extern void smtpd_state_init(SMTPD_STATE *, VSTREAM *);
/* .IP check_relay_domains
/* Allow the request when either the client hostname or the resolved
/* recipient domain matches the \fIrelay_domains\fR configuration
-/* parameter or a subdomain therereof, or when the destination somehow
+/* parameter or a subdomain thereof, or when the destination somehow
/* resolves locally ($inet_interfaces, $mydestination or $virtual_maps).
/* Reject the request otherwise.
/* The \fIrelay_domains_reject_code\fR configuration parameter specifies
/* the reject status code (default: 554).
/* .IP permit_auth_destination
/* Permit the request when the resolved recipient domain matches the
-/* \fIrelay_domains\fR configuration parameter or a subdomain therereof,
+/* \fIrelay_domains\fR configuration parameter or a subdomain thereof,
/* or when the destination somehow resolves locally ($inet_interfaces,
/* $mydestination or $virtual_maps).
/* .IP reject_unauth_destination
/* Reject the request when the resolved recipient domain does not match
/* the \fIrelay_domains\fR configuration parameter or a subdomain
-/* therereof, and when the destination does not somehow resolve locally
+/* thereof, and when the destination does not somehow resolve locally
/* ($inet_interfaces, $mydestination or $virtual_maps).
/* Same error code as check_relay_domains.
/* .IP reject_unauth_pipelining
if (var_smtpd_delay_reject)
if ((err = smtpd_check_client(state)) != 0
|| (err = smtpd_check_helo(state, state->helo_name)) != 0
- || (err = smtpd_check_mail(state, state->sender)) != 0)
+ || (err = smtpd_check_mail(state, state->sender)) != 0
+ || (err = smtpd_check_size(state, state->msg_size)) != 0)
SMTPD_CHECK_RCPT_RETURN(err);
/*
state->protocol = "SMTP";
state->where = SMTPD_AFTER_CONNECT;
state->recursion = 0;
+ state->msg_size = 0;
/*
* Initialize peer information.
/* answer already found */
if (res != 0 && host->stat == STATACTIVE) {
- msg_info("dict_mysql: closing unnessary connection to %s", host->hostname);
+ msg_info("dict_mysql: closing unnecessary connection to %s", host->hostname);
mysql_close(&(host->db)); /* also frees memory, have to
* reallocate it */
host->db = *((MYSQL *) mymalloc(sizeof(MYSQL)));
projects / thirdparty / postfix.git / commitdiff
