2
0
mirror of https://github.com/vdukhovni/postfix synced 2025-09-01 14:45:32 +00:00

snapshot-20020106

This commit is contained in:
Wietse Venema
2002-01-06 00:00:00 -05:00
committed by Viktor Dukhovni
parent ad0d1b5833
commit 83ba1719f2
47 changed files with 725 additions and 526 deletions

View File

@@ -103,6 +103,7 @@ wietse@porcupine.org to avoid duplication of effort.
Documentation:
README_FILES/ Instructions for specific Postfix features
html/ HTML format
man/ UNIX on-line manual page format
@@ -127,6 +128,7 @@ Command-line utilities:
src/postlock/ Postfix locking for shell scripts
src/postlog/ Postfix logging for shell scripts
src/postmap/ Postfix lookup table management
src/postqueue/ Postfix queue control program
src/postsuper/ Postfix house keeping program
src/sendmail/ Sendmail compatibility interface
@@ -151,7 +153,7 @@ Postfix daemons:
Test programs:
src/fsstone/ Measure file system overhead
src/smtpstone/ SMTP server torture test
src/smtpstone/ SMTP and QMQP server torture test
Miscellaneous:

View File

@@ -5902,6 +5902,16 @@ Apologies for any names omitted.
Security: additional run-time checks to discourage sharing
of Postfix user/group ID values with other accounts.
20020104
Cleanup: SMTPD access maps now return DUNNO (undetermined)
instead of OK when a recipient address contains multiple
domains (user@dom1@dom2, etcetera). Victor Duchovny, Morgan
Stanley. File: smtpd/smtpd_check.c.
Bugfix: SMTPD access maps did not handle address extensions.
File: smtpd/smtpd_check.c.
Open problems:
Low: don't do user@domain and @domain lookups in
@@ -5917,9 +5927,6 @@ Open problems:
Medium: make address rewriting on/off configurable for
envelopes and/or headers.
Medium: smtpd access maps don't understand the recipient
delimiter setting.
Low: generic showq protocol, to allow for more intelligent
processing than just mailq. Maybe marry this with postsuper.

View File

@@ -6,8 +6,8 @@ DIRS = src/util src/global src/dns src/master src/postfix src/smtpstone \
src/lmtp src/trivial-rewrite src/qmgr 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/nqmgr src/qmqpd src/spawn src/flush src/virtual \
# proto man html
src/postsuper src/nqmgr src/qmqpd src/spawn src/flush src/virtual
MANDIRS = proto man html
default: update
@@ -23,6 +23,11 @@ update printfck:
(set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
done
manpages:
set -e; for i in $(MANDIRS); do \
(set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
done
printfck: update
install: update

View File

@@ -2,60 +2,33 @@ This is a very first implementation of Postfix content filtering.
A Postfix content filter receives unfiltered mail from Postfix and
either bounces the mail or re-injects filtered mail back into Postfix.
It involves an incompatible change to queue file formats. Older
Postfix versions will reject mail that needs to be content filtered,
and will move the queue file to the "corrupt" mail queue subdirectory.
This document describes two approaches to content filtering.
Simple content filtering example
================================
The first example is simpler to set up, but is also more resource
intensive. With the shell script as shown 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 not as fast as SMTP transit mail.
The example assumes that only mail arriving via SMTP needs to be
content filtered.
The first example is simple to set up. It uses a shell script that
receives unfiltered mail from the Postfix pipe delivery agent, and
that feeds filtered mail back into the Postfix sendmail command.
Only mail arriving via SMTP will be content filtered.
..................................
: Postfix :
----->smtpd \ /local---->
Unfiltered mail----->smtpd \ /local---->Filtered mail
: -cleanup->queue- :
---->pickup / \smtp----->
---->pickup / \smtp----->Filtered mail
^ : | :
| : \pipe-----+
| .................................. |
| |
| |
+------sendmail<-------filter<---------+
1 - Create a dedicated local user account called "filter". 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.
2 - Create a directory /var/spool/filter that is accessible only
to the "filter" user. This is where the content filtering will
store its temporary files.
3 - Define a content filtering entry in the Postfix master file:
/etc/postfix/master.cf:
filter unix - n n - - pipe
flags=Rq user=filter argv=/somewhere/filter -f ${sender} -- ${recipient}
+-Postfix sendmail<----filter script<--+
The /some/where/filter program can be a simple shell script like this:
#!/bin/sh
# Localize these
# Localize these.
INSPECT_DIR=/var/spool/filter
SENDMAIL="/usr/sbin/sendmail -i"
@@ -88,21 +61,53 @@ exit status of the filter command is whatever exit status Postfix
sendmail produces.
I suggest that you play with this script for a while until you are
satisfied with the results. Run it as the filter user, with a real
message (headers+body) as input:
satisfied with the results. Run it with a real message (headers+body)
as input:
% /some/where/filter -f sender recipient... <message-file
Turn on content filtering for mail arriving via SMTP only, by
appending "-o content_filter=filter:dummy" to the master.cf
entry that defines the Postfix SMTP server:
Once you're satisfied with the content filtering script:
1 - 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". The user will
never log in, and can be given a "*" password and non-existent
shell and home directory.
2 - 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.
3 - Define the content filter in the Postfix master file:
/etc/postfix/master.cf:
filter unix - n n - - pipe
flags=Rq user=filter argv=/somewhere/filter -f ${sender} -- ${recipient}
To turn on content filtering for mail arriving via SMTP only, append
"-o content_filter=filter:" to the master.cf entry that defines
the Postfix SMTP server:
/etc/postfix/master.cf:
smtp inet ...stuff... smtpd
-o content_filter=filter:dummy
-o content_filter=filter:
The content_filter configuration parameter accepts the same
syntax as the right-hand side in a Postfix transport table.
Note the ":" at the end!! The content_filter configuration parameter
accepts the same syntax as the right-hand side in a Postfix transport
table. Execute "postfix reload" to complete the change.
To turn off content filtering, edit the master.cf file, remove the
"-o content_filter=filter:" text from the entry that defines the
Postfix SMTP server, and execute another "postfix reload".
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.
Simple content filter limitations
=================================

View File

@@ -1,4 +1,4 @@
Incompatible changes with snapshot-200201XX
Incompatible changes with snapshot-20020106
===========================================
Postfix will not run if it detects that the postfix user or group
@@ -23,7 +23,13 @@ main.cf file as "alternate_config_directories = /dir1 /dir2 ...".
Otherwise, some Postfix commands will no longer work (namely, the
ones that are now implemented by set-group ID client programs).
Major changes with snapshot-200201XX
Postfix SMTP access maps no longer return OK for non-local recipient
mail addresses that contain multiple domains (user@dom1@dom2,
user%dom1@dom2, etcetera); the lookup now returns DUNNO (undetermined).
Non-local multi-domain addresses were already prohibited from
matching the permit_mx_backup and the relay_domains-based restrictions.
Major changes with snapshot-20020106
====================================
Simplification of the local Postfix security model.
@@ -70,12 +76,6 @@ address will be looked up as <> instead.
Incompatible changes with snapshot-20011210
===========================================
Postfix SMTPD access maps no longer match non-local mail addresses
that contain multiple domains (user@dom1@dom2, user%dom1@dom2,
etcetera). This change prevents false or spurious matches.
Non-local multi-domain addresses are already prohibited from matching
permit_mx_backup and the relay_domains-based restrictions.
Stricter checking of Postfix chroot configurations. The Postfix
startup procedure now warns if "system" directories (etc, bin, lib,
usr) under the Postfix top-level queue directory are not owned by

View File

@@ -9,9 +9,9 @@
#
# DESCRIPTION
# The optional access table directs the Postfix SMTP server
# to selectively reject or accept mail from or to specific
# hosts, domains, networks, host addresses or mail
# addresses.
# to selectively reject or accept mail. Access can be
# allowed or denied for specific host names, domain names,
# networks, host network addresses or mail addresses.
#
# Normally, the access table is specified as a text file
# that serves as input to the postmap(1) command. The
@@ -36,37 +36,65 @@
# When pattern matches a mail address, domain or host
# address, perform the corresponding action.
#
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
#
# PATTERNS
# EMAIL ADDRESS PATTERNS
# 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:
# networked tables such as NIS, LDAP or SQL, the following
# lookup patterns are examined in the order as listed:
#
# user@domain
# Matches the specified mail address.
#
# domain.name
# Matches the domain.name itself and any subdomain
# thereof, either in hostnames or in mail addresses.
# Top-level domains will never be matched.
# Matches domain.name as the domain part of an email
# address.
#
# The pattern domain.name also matches subdomains,
# but only when the string smtpd_access_maps is
# listed in the Postfix parent_domain_matches_subdo-
# mains configuration setting. Otherwise, specify
# .domain.name (note the initial dot) in order to
# match subdomains.
#
# user@ Matches all mail addresses with the specified user
# part.
#
# Note: lookup of the null sender address may not be possi-
# ble with all supported types of lookup table. A workaround
# is to specify smtpd_null_access_lookup_key = <> in the
# Postfix main.cf file, and to specify <> as the left-hand
# field in the access table.
#
# ADDRESS EXTENSION
# When a mail address localpart contains the optional recip-
# ient delimiter (e.g., user+foo@domain), the lookup order
# becomes: user+foo@domain, user@domain, domain, user+foo@,
# and user@.
#
# HOST NAME/ADDRESS PATTERNS
# With lookups from indexed files such as DB or DBM, or from
# networked tables such as NIS, LDAP or SQL, the following
# lookup patterns are examined in the order as listed:
#
# domain.name
# Matches domain.name.
#
# The pattern domain.name also matches subdomains,
# but only when the string smtpd_access_maps is
# listed in the Postfix parent_domain_matches_subdo-
# mains configuration setting. Otherwise, specify
# .domain.name (note the initial dot) in order to
# match subdomains.
#
# net.work.addr.ess
#
# net.work.addr
@@ -101,17 +129,18 @@
# 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. Thus,
# no parent domain or parent network search is done, and
# no parent domain or parent network search is done,
# user@domain mail addresses are not broken up into their
# user@ and domain constituent parts.
# user@ and domain constituent parts, nor is user+foo broken
# up into user and foo.
#
# 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 $1, $2 and so on.
# Actions are the same as with indexed file lookups, with
# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# BUGS
# The table format does not understand quoting conventions.

View File

@@ -68,18 +68,13 @@ decode: root
#
# name: value1, value2, ...
#
# o A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# o Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# o The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# o A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# The name is a local address (no domain part). Use double
# quotes when the name contains any special characters such

View File

@@ -51,20 +51,15 @@
# When pattern matches a mail address, replace it by
# the corresponding result.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# multi-line text
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# With lookups from indexed files such as DB or DBM, or from
# networked tables such as NIS, LDAP or SQL, patterns are
@@ -95,13 +90,11 @@
# domain, the result is the same user in otherdomain.
#
# ADDRESS EXTENSION
# When table lookup fails, and the address localpart con-
# tains the optional recipient delimiter (e.g.,
# user+foo@domain), the search is repeated for the unex-
# tended address (e.g. user@domain), and the unmatched
# extension is propagated to the result of table lookup. The
# matching order is: user+foo@domain, user@domain, user+foo,
# user, and @domain.
# When a mail address localpart contains the optional recip-
# ient delimiter (e.g., user+foo@domain), the lookup order
# becomes: user+foo@domain, user@domain, user+foo, user, and
# @domain. An unmatched address extension (+foo) is propa-
# gated to the result of table lookup.
#
# REGULAR EXPRESSION TABLES
# This section describes how the table lookups change when
@@ -119,9 +112,9 @@
# 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 $1, $2 and so on.
# Results are the same as with indexed file lookups, with
# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# BUGS
# The table format does not understand quoting conventions.

View File

@@ -22,20 +22,15 @@
# When pattern matches a search string, use the cor-
# responding result.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# multi-line text
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# Each pattern is a perl-like regular expression. The
# expression delimiter can be any character, except whites-

View File

@@ -22,20 +22,15 @@
# When pattern matches a search string, use the cor-
# responding result.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# multi-line text
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# pattern1!pattern2 result
# Matches pattern1 but not pattern2.

View File

@@ -39,18 +39,13 @@
# such as an email address, or perhaps a street
# address or telephone number.
#
# o A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# o Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# o The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# o A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# With lookups from indexed files such as DB or DBM, or from
# networked tables such as NIS, LDAP or SQL, the key field
@@ -69,10 +64,10 @@
# lowest precedence.
#
# ADDRESS EXTENSION
# When the search fails, and the address localpart contains
# the optional recipient delimiter (e.g., user+foo@domain),
# the search is repeated for the unextended address (e.g.
# user@domain).
# When a mail address localpart contains the optional recip-
# ient delimiter (e.g., user+foo@domain), the lookup order
# becomes: user+foo@domain, user@domain, user+foo, user, and
# @domain.
#
# REGULAR EXPRESSION TABLES
# This section describes how the table lookups change when
@@ -90,9 +85,9 @@
# 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 $1, $2 and so on.
# Results are the same as with indexed file lookups, with
# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# BUGS
# The table format does not understand quoting conventions.

View File

@@ -36,20 +36,15 @@
# When pattern matches the domain, use the corre-
# sponding result.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# multi-line text
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# With lookups from indexed files such as DB or DBM, or from
# networked tables such as NIS, LDAP or SQL, patterns are
@@ -61,7 +56,11 @@
#
# .domain transport:nexthop
# Mail for any subdomain of domain is delivered
# through transport to nexthop.
# through transport to nexthop. This applies only
# when the string transport_maps is not listed in the
# parent_domain_matches_subdomains configuration set-
# ting. Otherwise, a domain name matches itself and
# its subdomains.
#
# Note: transport map entries take precedence over domains
# specified in the mydestination parameter. If you use the
@@ -139,9 +138,9 @@
# 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 $1, $2 and so on.
# Results are the same as with indexed file lookups, with
# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# CONFIGURATION PARAMETERS
# The following main.cf parameters are especially relevant

View File

@@ -107,20 +107,15 @@
# When pattern matches a mail address, replace it by
# the corresponding result.
#
# multi-line text
# A line that starts with whitespace (space or tab)
# is a continuation of the previous line. An empty
# line terminates the previous line, as does a line
# that starts with non-whitespace (text or comment).
# A comment line that starts with whitespace does not
# terminate multi-line text.
# blank lines and comments
# Empty lines and whitespace-only lines are ignored,
# as are lines whose first non-whitespace character
# is a `#'.
#
# comments
# The # is recognized as the start of a comment, but
# only when it is the first non-whitespace character
# on a line. A comment terminates at the end of the
# line, even when the next line starts with whites-
# pace.
# multi-line text
# A logical line starts with non-whitespace text. A
# line that starts with whitespace continues a logi-
# cal line.
#
# With lookups from indexed files such as DB or DBM, or from
# networked tables such as NIS, LDAP or SQL, patterns are
@@ -150,12 +145,11 @@
# works for the first address in the expansion only.
#
# ADDRESS EXTENSION
# When the search fails, and the address localpart contains
# the optional recipient delimiter (e.g., user+foo@domain),
# the search is repeated for the unextended address (e.g.
# user@domain), and the unmatched address extension is prop-
# agated to the result of expansion. The matching order is:
# user+foo@domain, user@domain, user+foo, user, and @domain.
# When a mail address localpart contains the optional recip-
# ient delimiter (e.g., user+foo@domain), the lookup order
# becomes: user+foo@domain, user@domain, user+foo, user, and
# @domain. An unmatched address extension (+foo) is propa-
# gated to the result of table lookup.
#
# REGULAR EXPRESSION TABLES
# This section describes how the table lookups change when
@@ -173,9 +167,9 @@
# 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 $1, $2 and so on.
# Results are the same as with indexed file lookups, with
# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# BUGS
# The table format does not understand quoting conventions.

View File

@@ -10,9 +10,9 @@ ACCESS(5) ACCESS(5)
<b>DESCRIPTION</b>
The optional <b>access</b> table directs the Postfix SMTP server
to selectively reject or accept mail from or to specific
hosts, domains, networks, host addresses or mail
addresses.
to selectively reject or accept mail. Access can be
allowed or denied for specific host names, domain names,
networks, host network addresses or mail addresses.
Normally, the <b>access</b> table is specified as a text file
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
@@ -47,22 +47,55 @@ ACCESS(5) ACCESS(5)
line that starts with whitespace continues a logi-
cal line.
<b>PATTERNS</b>
<b>EMAIL</b> <b>ADDRESS</b> <b>PATTERNS</b>
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:
networked tables such as NIS, LDAP or SQL, the following
lookup patterns are examined in the order as listed:
<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.
Top-level domains will never be matched.
Matches <i>domain.name</i> as the domain part of an email
address.
The pattern <i>domain.name</i> also matches subdomains,
but only when the string <b>smtpd</b><i>_</i><b>access</b><i>_</i><b>maps</b> is
listed in the Postfix <b>parent</b><i>_</i><b>domain</b><i>_</i><b>matches</b><i>_</i><b>subdo-</b>
<b>mains</b> configuration setting. Otherwise, specify
<i>.domain.name</i> (note the initial dot) in order to
match subdomains.
<i>user</i>@ Matches all mail addresses with the specified user
part.
Note: lookup of the null sender address may not be possi-
ble with all supported types of lookup table. A workaround
is to specify <b>smtpd</b><i>_</i><b>null</b><i>_</i><b>access</b><i>_</i><b>lookup</b><i>_</i><b>key</b> <b>=</b> &lt;&gt; in the
Postfix <b>main.cf</b> file, and to specify &lt;&gt; as the left-hand
field in the access table.
<b>ADDRESS</b> <b>EXTENSION</b>
When a mail address localpart contains the optional recip-
ient delimiter (e.g., <i>user+foo</i>@<i>domain</i>), the lookup order
becomes: <i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>domain</i>, <i>user+foo</i>@,
and <i>user</i>@.
<b>HOST</b> <b>NAME/ADDRESS</b> <b>PATTERNS</b>
With lookups from indexed files such as DB or DBM, or from
networked tables such as NIS, LDAP or SQL, the following
lookup patterns are examined in the order as listed:
<i>domain.name</i>
Matches <i>domain.name</i>.
The pattern <i>domain.name</i> also matches subdomains,
but only when the string <b>smtpd</b><i>_</i><b>access</b><i>_</i><b>maps</b> is
listed in the Postfix <b>parent</b><i>_</i><b>domain</b><i>_</i><b>matches</b><i>_</i><b>subdo-</b>
<b>mains</b> configuration setting. Otherwise, specify
<i>.domain.name</i> (note the initial dot) in order to
match subdomains.
<i>net.work.addr.ess</i>
<i>net.work.addr</i>
@@ -97,17 +130,18 @@ ACCESS(5) ACCESS(5)
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. Thus,
no parent domain or parent network search is done, and
no parent domain or parent network search is done,
<i>user@domain</i> mail addresses are not broken up into their
<i>user@</i> and <i>domain</i> constituent parts.
<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.
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 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.

View File

@@ -91,13 +91,11 @@ CANONICAL(5) CANONICAL(5)
<i>domain</i>, the result is the same user in <i>otherdomain</i>.
<b>ADDRESS</b> <b>EXTENSION</b>
When table lookup fails, and the address localpart con-
tains the optional recipient delimiter (e.g.,
<i>user+foo</i>@<i>domain</i>), the search is repeated for the unex-
tended address (e.g. <i>user</i>@<i>domain</i>), and the unmatched
extension is propagated to the result of table lookup. 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>.
When a mail address localpart contains the optional recip-
ient delimiter (e.g., <i>user+foo</i>@<i>domain</i>), the lookup order
becomes: <i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>user+foo</i>, <i>user</i>, and
@<i>domain</i>. An unmatched address extension (<i>+foo</i>) is propa-
gated to the result of table lookup.
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
This section describes how the table lookups change when
@@ -115,9 +113,9 @@ CANONICAL(5) CANONICAL(5)
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.
Results are the same as with 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.

View File

@@ -65,10 +65,10 @@ RELOCATED(5) RELOCATED(5)
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>).
When a mail address localpart contains the optional recip-
ient delimiter (e.g., <i>user+foo</i>@<i>domain</i>), the lookup order
becomes: <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
@@ -86,9 +86,9 @@ RELOCATED(5) RELOCATED(5)
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.
Results are the same as with 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.

View File

@@ -57,7 +57,11 @@ TRANSPORT(5) TRANSPORT(5)
<i>.domain</i> <i>transport</i>:<i>nexthop</i>
Mail for any subdomain of <i>domain</i> is delivered
through <i>transport</i> to <i>nexthop</i>.
through <i>transport</i> to <i>nexthop</i>. This applies only
when the string <b>transport</b><i>_</i><b>maps</b> is not listed in the
<b>parent</b><i>_</i><b>domain</b><i>_</i><b>matches</b><i>_</i><b>subdomains</b> configuration set-
ting. Otherwise, a domain name matches itself and
its subdomains.
Note: transport map entries take precedence over domains
specified in the <b>mydestination</b> parameter. If you use the
@@ -135,9 +139,9 @@ TRANSPORT(5) TRANSPORT(5)
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.
Results are the same as with 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

View File

@@ -146,12 +146,11 @@ VIRTUAL(5) VIRTUAL(5)
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.
<i>user</i>@<i>domain</i>), and the unmatched address extension is prop-
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>.
When a mail address localpart contains the optional recip-
ient delimiter (e.g., <i>user+foo</i>@<i>domain</i>), the lookup order
becomes: <i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>user+foo</i>, <i>user</i>, and
@<i>domain</i>. An unmatched address extension (<i>+foo</i>) is propa-
gated to the result of table lookup.
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
This section describes how the table lookups change when
@@ -169,9 +168,9 @@ VIRTUAL(5) VIRTUAL(5)
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.
Results are the same as with 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.

View File

@@ -13,8 +13,9 @@ format of Postfix access table
.ad
.fi
The optional \fBaccess\fR table directs the Postfix SMTP server
to selectively reject or accept mail from or to specific hosts,
domains, networks, host addresses or mail addresses.
to selectively reject or accept mail. Access can be allowed or
denied for specific host names, domain names, networks, host
network addresses or mail addresses.
Normally, the \fBaccess\fR table is specified as a text file
that serves as input to the \fBpostmap\fR(1) command.
@@ -44,22 +45,57 @@ are lines whose first non-whitespace character is a `#'.
.IP "multi-line text"
A logical line starts with non-whitespace text. A line that
starts with whitespace continues a logical line.
.SH PATTERNS
.SH EMAIL ADDRESS PATTERNS
.na
.nf
.ad
.fi
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:
tables such as NIS, LDAP or SQL, the following lookup patterns are
examined in the order as listed:
.IP \fIuser\fR@\fIdomain\fR
Matches the specified mail address.
.IP \fIdomain.name\fR
Matches the \fIdomain.name\fR itself and any subdomain thereof,
either in hostnames or in mail addresses. Top-level domains will
never be matched.
Matches \fIdomain.name\fR as the domain part of an email address.
.sp
The pattern \fIdomain.name\fR also matches subdomains, but only
when the string \fBsmtpd_access_maps\fR is listed in the Postfix
\fBparent_domain_matches_subdomains\fR configuration setting.
Otherwise, specify \fI.domain.name\fR (note the initial dot) in
order to match subdomains.
.IP \fIuser\fR@
Matches all mail addresses with the specified user part.
.PP
Note: lookup of the null sender address may not be possible with
all supported types of lookup table. A workaround is to specify
\fBsmtpd_null_access_lookup_key = <>\fR in the Postfix \fBmain.cf\fR
file, and to specify \fB<>\fR as the left-hand field in the access
table.
.SH ADDRESS EXTENSION
.na
.nf
.fi
.ad
When a mail address localpart contains the optional recipient delimiter
(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIdomain\fR,
\fIuser+foo\fR@, and \fIuser\fR@.
.SH HOST NAME/ADDRESS PATTERNS
.na
.nf
.ad
.fi
With lookups from indexed files such as DB or DBM, or from networked
tables such as NIS, LDAP or SQL, the following lookup patterns are
examined in the order as listed:
.IP \fIdomain.name\fR
Matches \fIdomain.name\fR.
.sp
The pattern \fIdomain.name\fR also matches subdomains, but only
when the string \fBsmtpd_access_maps\fR is listed in the Postfix
\fBparent_domain_matches_subdomains\fR configuration setting.
Otherwise, specify \fI.domain.name\fR (note the initial dot) in
order to match subdomains.
.IP \fInet.work.addr.ess\fR
.IP \fInet.work.addr\fR
.IP \fInet.work\fR
@@ -96,13 +132,14 @@ 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. 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.
is done, \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.
Actions are the same as with normal indexed file lookups, with
Actions are the same as with 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

View File

@@ -88,13 +88,11 @@ In all the above forms, when \fIaddress\fR has the form
.nf
.fi
.ad
When table lookup fails, and the address localpart contains the
optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR), the
search is repeated for the unextended address (e.g.
\fIuser\fR@\fIdomain\fR), and the unmatched extension is propagated
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.
When a mail address localpart contains the optional recipient delimiter
(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
\fIuser\fR, and @\fIdomain\fR. An unmatched address extension
(\fI+foo\fR) is propagated to the result of table lookup.
.SH REGULAR EXPRESSION TABLES
.na
.nf
@@ -113,7 +111,7 @@ 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
Results are the same as with 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

View File

@@ -68,10 +68,10 @@ precedence.
.nf
.fi
.ad
When the search fails, and the address localpart contains the
optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
the search is repeated for the unextended address (e.g.
\fIuser\fR@\fIdomain\fR).
When a mail address localpart contains the optional recipient delimiter
(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
\fIuser\fR, and @\fIdomain\fR.
.SH REGULAR EXPRESSION TABLES
.na
.nf
@@ -90,7 +90,7 @@ 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
Results are the same as with 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

View File

@@ -53,7 +53,10 @@ Mail for \fIdomain\fR is delivered through \fItransport\fR to
\fInexthop\fR.
.IP "\fI.domain transport\fR:\fInexthop\fR"
Mail for any subdomain of \fIdomain\fR is delivered through
\fItransport\fR to \fInexthop\fR.
\fItransport\fR to \fInexthop\fR. This applies only when the
string \fBtransport_maps\fR is not listed in the
\fBparent_domain_matches_subdomains\fR configuration setting.
Otherwise, a domain name matches itself and its subdomains.
.PP
Note: transport map entries take precedence over domains
specified in the \fBmydestination\fR parameter. If you use
@@ -140,7 +143,7 @@ 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
Results are the same as with 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

View File

@@ -158,13 +158,11 @@ This works for the first address in the expansion only.
.nf
.fi
.ad
When the search fails, and the address localpart contains the
optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
the search is repeated for the unextended address (e.g.
\fIuser\fR@\fIdomain\fR), and the unmatched address extension is
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.
When a mail address localpart contains the optional recipient delimiter
(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
\fIuser\fR, and @\fIdomain\fR. An unmatched address extension
(\fI+foo\fR) is propagated to the result of table lookup.
.SH REGULAR EXPRESSION TABLES
.na
.nf
@@ -183,7 +181,7 @@ 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
Results are the same as with 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

View File

@@ -7,8 +7,9 @@
# \fBpostmap /etc/postfix/access\fR
# DESCRIPTION
# The optional \fBaccess\fR table directs the Postfix SMTP server
# to selectively reject or accept mail from or to specific hosts,
# domains, networks, host addresses or mail addresses.
# to selectively reject or accept mail. Access can be allowed or
# denied for specific host names, domain names, networks, host
# network addresses or mail addresses.
#
# Normally, the \fBaccess\fR table is specified as a text file
# that serves as input to the \fBpostmap\fR(1) command.
@@ -36,20 +37,51 @@
# .IP "multi-line text"
# A logical line starts with non-whitespace text. A line that
# starts with whitespace continues a logical line.
# PATTERNS
# EMAIL ADDRESS PATTERNS
# .ad
# .fi
# 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:
# tables such as NIS, LDAP or SQL, the following lookup patterns are
# examined in the order as listed:
# .IP \fIuser\fR@\fIdomain\fR
# Matches the specified mail address.
# .IP \fIdomain.name\fR
# Matches the \fIdomain.name\fR itself and any subdomain thereof,
# either in hostnames or in mail addresses. Top-level domains will
# never be matched.
# Matches \fIdomain.name\fR as the domain part of an email address.
# .sp
# The pattern \fIdomain.name\fR also matches subdomains, but only
# when the string \fBsmtpd_access_maps\fR is listed in the Postfix
# \fBparent_domain_matches_subdomains\fR configuration setting.
# Otherwise, specify \fI.domain.name\fR (note the initial dot) in
# order to match subdomains.
# .IP \fIuser\fR@
# Matches all mail addresses with the specified user part.
# .PP
# Note: lookup of the null sender address may not be possible with
# all supported types of lookup table. A workaround is to specify
# \fBsmtpd_null_access_lookup_key = <>\fR in the Postfix \fBmain.cf\fR
# file, and to specify \fB<>\fR as the left-hand field in the access
# table.
# ADDRESS EXTENSION
# .fi
# .ad
# When a mail address localpart contains the optional recipient delimiter
# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIdomain\fR,
# \fIuser+foo\fR@, and \fIuser\fR@.
# HOST NAME/ADDRESS PATTERNS
# .ad
# .fi
# With lookups from indexed files such as DB or DBM, or from networked
# tables such as NIS, LDAP or SQL, the following lookup patterns are
# examined in the order as listed:
# .IP \fIdomain.name\fR
# Matches \fIdomain.name\fR.
# .sp
# The pattern \fIdomain.name\fR also matches subdomains, but only
# when the string \fBsmtpd_access_maps\fR is listed in the Postfix
# \fBparent_domain_matches_subdomains\fR configuration setting.
# Otherwise, specify \fI.domain.name\fR (note the initial dot) in
# order to match subdomains.
# .IP \fInet.work.addr.ess\fR
# .IP \fInet.work.addr\fR
# .IP \fInet.work\fR
@@ -82,13 +114,14 @@
# 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.
# is done, \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.
#
# Actions are the same as with normal indexed file lookups, with
# Actions are the same as with 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

View File

@@ -78,13 +78,11 @@
# ADDRESS EXTENSION
# .fi
# .ad
# When table lookup fails, and the address localpart contains the
# optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR), the
# search is repeated for the unextended address (e.g.
# \fIuser\fR@\fIdomain\fR), and the unmatched extension is propagated
# 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.
# When a mail address localpart contains the optional recipient delimiter
# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
# \fIuser\fR, and @\fIdomain\fR. An unmatched address extension
# (\fI+foo\fR) is propagated to the result of table lookup.
# REGULAR EXPRESSION TABLES
# .ad
# .fi
@@ -101,7 +99,7 @@
# 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
# Results are the same as with 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

View File

@@ -58,10 +58,10 @@
# ADDRESS EXTENSION
# .fi
# .ad
# When the search fails, and the address localpart contains the
# optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
# the search is repeated for the unextended address (e.g.
# \fIuser\fR@\fIdomain\fR).
# When a mail address localpart contains the optional recipient delimiter
# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
# \fIuser\fR, and @\fIdomain\fR.
# REGULAR EXPRESSION TABLES
# .ad
# .fi
@@ -78,7 +78,7 @@
# 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
# Results are the same as with 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

View File

@@ -45,7 +45,10 @@
# \fInexthop\fR.
# .IP "\fI.domain transport\fR:\fInexthop\fR"
# Mail for any subdomain of \fIdomain\fR is delivered through
# \fItransport\fR to \fInexthop\fR.
# \fItransport\fR to \fInexthop\fR. This applies only when the
# string \fBtransport_maps\fR is not listed in the
# \fBparent_domain_matches_subdomains\fR configuration setting.
# Otherwise, a domain name matches itself and its subdomains.
# .PP
# Note: transport map entries take precedence over domains
# specified in the \fBmydestination\fR parameter. If you use
@@ -128,7 +131,7 @@
# 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
# Results are the same as with 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

View File

@@ -144,13 +144,11 @@
# ADDRESS EXTENSION
# .fi
# .ad
# When the search fails, and the address localpart contains the
# optional recipient delimiter (e.g., \fIuser+foo\fR@\fIdomain\fR),
# the search is repeated for the unextended address (e.g.
# \fIuser\fR@\fIdomain\fR), and the unmatched address extension is
# 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.
# When a mail address localpart contains the optional recipient delimiter
# (e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes:
# \fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR,
# \fIuser\fR, and @\fIdomain\fR. An unmatched address extension
# (\fI+foo\fR) is propagated to the result of table lookup.
# REGULAR EXPRESSION TABLES
# .ad
# .fi
@@ -167,7 +165,7 @@
# 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
# Results are the same as with 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

View File

@@ -15,7 +15,7 @@
* Version of this program.
*/
#define VAR_MAIL_VERSION "mail_version"
#define DEF_MAIL_VERSION "Snapshot-20020104"
#define DEF_MAIL_VERSION "Snapshot-20020106"
extern char *var_mail_version;
/* LICENSE

View File

@@ -290,6 +290,7 @@
#include <maps.h>
#include <mail_addr_find.h>
#include <match_parent_style.h>
#include <split_addr.h>
/* Application-specific. */
@@ -736,6 +737,29 @@ static const char *check_mail_addr_find(SMTPD_STATE *state,
return (result);
}
/* resolve_final - do we do final delivery for the domain? */
static int resolve_final(SMTPD_STATE *state, const char *reply_name,
const char *domain)
{
/* If matches $mydestination or $inet_interfaces. */
if (resolve_local(domain))
return (1);
/* If Postfix-style virtual domain. */
if (*var_virtual_maps
&& check_maps_find(state, reply_name, virtual_maps, domain, 0))
return (1);
/* If virtual mailbox domain. */
if (*var_virt_mailbox_maps
&& check_maps_find(state, reply_name, virt_mailbox_maps, domain, 0))
return (1);
return (0);
}
/* reject_unknown_client - fail if client hostname is unknown */
static int reject_unknown_client(SMTPD_STATE *state)
@@ -997,14 +1021,10 @@ static int permit_auth_destination(SMTPD_STATE *state, char *recipient)
domain += 1;
/*
* Permit final delivery: the destination matches mydestination or
* virtual_maps.
* Permit final delivery: the destination matches mydestination,
* virtual_maps, or virtual_mailbox_maps.
*/
if (resolve_local(domain)
|| (*var_virtual_maps
&& check_maps_find(state, recipient, virtual_maps, domain, 0))
|| (*var_virt_mailbox_maps
&& check_maps_find(state, recipient, virt_mailbox_maps, domain, 0)))
if (resolve_final(state, recipient, domain))
return (SMTPD_CHECK_OK);
/*
@@ -1261,11 +1281,7 @@ static int permit_mx_backup(SMTPD_STATE *state, const char *recipient)
if ((domain = strrchr(CONST_STR(reply->recipient), '@')) == 0)
return (SMTPD_CHECK_OK);
domain += 1;
if (resolve_local(domain)
|| (*var_virtual_maps
&& check_maps_find(state, recipient, virtual_maps, domain, 0))
|| (*var_virt_mailbox_maps
&& check_maps_find(state, recipient, virt_mailbox_maps, domain, 0)))
if (resolve_final(state, recipient, domain))
return (SMTPD_CHECK_OK);
if (msg_verbose)
@@ -1397,11 +1413,7 @@ static int reject_unknown_address(SMTPD_STATE *state, const char *addr,
if ((domain = strrchr(CONST_STR(reply->recipient), '@')) == 0)
return (SMTPD_CHECK_DUNNO);
domain += 1;
if (resolve_local(domain)
|| (*var_virtual_maps
&& check_maps_find(state, reply_name, virtual_maps, domain, 0))
|| (*var_virt_mailbox_maps
&& check_maps_find(state, reply_name, virt_mailbox_maps, domain, 0)))
if (resolve_final(state, reply_name, domain))
return (SMTPD_CHECK_DUNNO);
if (domain[0] == '#')
return (SMTPD_CHECK_DUNNO);
@@ -1693,9 +1705,12 @@ static int check_mail_access(SMTPD_STATE *state, const char *table,
{
char *myname = "check_mail_access";
const RESOLVE_REPLY *reply;
const char *ratsign;
const char *domain;
int status;
char *local_at;
char *bare_addr;
char *bare_ext;
char *bare_at;
if (msg_verbose)
msg_info("%s: %s", myname, addr);
@@ -1709,50 +1724,114 @@ static int check_mail_access(SMTPD_STATE *state, const char *table,
* Garbage in, garbage out. Every address from canon_addr_internal() and
* from resolve_clnt_query() must be fully qualified.
*/
if ((ratsign = strrchr(CONST_STR(reply->recipient), '@')) == 0) {
msg_warn("%s: no @domain in address: %s", myname, CONST_STR(reply->recipient));
if ((domain = strrchr(CONST_STR(reply->recipient), '@')) == 0) {
msg_warn("%s: no @domain in address: %s", myname,
CONST_STR(reply->recipient));
return (0);
}
domain += 1;
/*
* Avoid surprise matches with source-routed, non-local addresses.
* In case of address extensions.
*/
if (var_allow_untrust_route == 0
&& (reply->flags & RESOLVE_FLAG_ROUTED)
&& !resolve_local(ratsign + 1))
return (SMTPD_CHECK_DUNNO);
if (*var_rcpt_delim == 0) {
bare_addr = 0;
} else {
bare_addr = mystrdup(addr);
if ((bare_at = strrchr(bare_addr, '@')) != 0)
*bare_at = 0;
if ((bare_ext = split_addr(bare_addr, *var_rcpt_delim)) != 0) {
if (bare_at != 0) {
*bare_at = '@';
memmove(bare_ext - 1, bare_at, strlen(bare_at) + 1);
bare_at = bare_ext - 1;
}
} else {
myfree(bare_addr);
bare_addr = 0;
}
}
#define CHECK_MAIL_ACCESS_RETURN(x) \
{ if (bare_addr) myfree(bare_addr); return(x); }
/*
* Look up the full address.
* Source-routed, non-local, recipient addresses are too suspicious for
* returning an "OK" result. The complicated expression below was brought
* to you by the keyboard of Victor Duchovny, Morgan Stanley and hacked
* up a bit by Wietse.
*/
#define SUSPICIOUS(domain, reply, state, reply_name, reply_class) \
(var_allow_untrust_route == 0 \
&& (reply->flags & RESOLVE_FLAG_ROUTED) \
&& strcmp(reply_class, SMTPD_NAME_RECIPIENT) == 0 \
&& !resolve_final(state, reply_name, domain))
/*
* Look up user+foo@domain if the address has an extension, user@domain
* otherwise.
*/
if ((status = check_access(state, table, CONST_STR(reply->recipient), FULL,
found, reply_name, reply_class, def_acl)) != 0
|| *found)
return (status);
CHECK_MAIL_ACCESS_RETURN(status == SMTPD_CHECK_OK
&& SUSPICIOUS(domain, reply, state, reply_name, reply_class) ?
SMTPD_CHECK_DUNNO : status);
/*
* Try user@domain if the address has an extension.
*/
if (bare_addr)
if ((status = check_access(state, table, bare_addr, PARTIAL,
found, reply_name, reply_class, def_acl)) != 0
|| *found)
CHECK_MAIL_ACCESS_RETURN(status == SMTPD_CHECK_OK
&& SUSPICIOUS(domain, reply, state, reply_name, reply_class) ?
SMTPD_CHECK_DUNNO : status);
/*
* Look up the domain name, or parent domains thereof.
*/
if ((status = check_domain_access(state, table, ratsign + 1, PARTIAL,
if ((status = check_domain_access(state, table, domain, PARTIAL,
found, reply_name, reply_class, def_acl)) != 0
|| *found)
return (status);
CHECK_MAIL_ACCESS_RETURN(status == SMTPD_CHECK_OK
&& SUSPICIOUS(domain, reply, state, reply_name, reply_class) ?
SMTPD_CHECK_DUNNO : status);
/*
* Look up localpart@
* Look up user+foo@ if the address has an extension, user@ otherwise.
* XXX This leaks a little memory if map lookup is aborted.
*/
local_at = mystrndup(CONST_STR(reply->recipient),
ratsign - CONST_STR(reply->recipient) + 1);
domain - CONST_STR(reply->recipient));
status = check_access(state, table, local_at, PARTIAL, found,
reply_name, reply_class, def_acl);
myfree(local_at);
if (status != 0 || *found)
return (status);
CHECK_MAIL_ACCESS_RETURN(status == SMTPD_CHECK_OK
&& SUSPICIOUS(domain, reply, state, reply_name, reply_class) ?
SMTPD_CHECK_DUNNO : status);
/*
* Look up user@ if the address has an extension. XXX Same problem here.
*/
if (bare_addr) {
local_at = (bare_at ? mystrndup(bare_addr, bare_at + 1 - bare_addr) :
mystrdup(bare_addr));
status = check_access(state, table, local_at, PARTIAL, found,
reply_name, reply_class, def_acl);
myfree(local_at);
if (status != 0 || *found)
CHECK_MAIL_ACCESS_RETURN(status == SMTPD_CHECK_OK
&& SUSPICIOUS(domain, reply, state, reply_name, reply_class) ?
SMTPD_CHECK_DUNNO : status);
}
/*
* Undecided when no match found.
*/
return (SMTPD_CHECK_DUNNO);
CHECK_MAIL_ACCESS_RETURN(SMTPD_CHECK_DUNNO);
}
/* reject_maps_rbl - reject if client address in real-time blackhole list */

View File

@@ -34,6 +34,9 @@
/* DIAGNOSTICS
/* Warning: a continuation line that does not continue preceding text.
/* The invalid input is ignored, to avoid complicating caller code.
/* SECURITY
/* readlline() imposes no logical line length limit therefore it
/* should be used for reading trusted information only.
/* LICENSE
/* .ad
/* .fi