mirror of
https://github.com/vdukhovni/postfix
synced 2025-08-31 22:25:24 +00:00
snapshot-20020106
This commit is contained in:
committed by
Viktor Dukhovni
parent
ad0d1b5833
commit
83ba1719f2
@@ -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:
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
=================================
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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-
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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> <> in the
|
||||
Postfix <b>main.cf</b> file, and to specify <> 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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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 */
|
||||
|
@@ -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
|
||||
|
Reference in New Issue
Block a user