mirror of
https://github.com/vdukhovni/postfix
synced 2025-08-30 05:38:06 +00:00
postfix-2.0.13-20030704
This commit is contained in:
Wietse Venema
Viktor Dukhovni
parent
5884ef624c
commit
4d17a8158b
@ -8335,6 +8335,11 @@ Apologies for any names omitted.
|
||||
Feature: TCP lookup table support, finally finished. Files:
|
||||
proto/tcp_table, proto/dict_tcp.[hc].
|
||||
|
||||
20030703
|
||||
|
||||
Non-prod: the SMTPD proxy client lost the reply to ".".
|
||||
Amazing.
|
||||
|
||||
Open problems:
|
||||
|
||||
Low: smtp-source may block when sending large test messages.
|
||||
|
||||
@ -12,12 +12,16 @@ recipients, for example on mail relay hosts that do not have a copy
|
||||
of all the relayed recipient addresses.
|
||||
|
||||
With address verification turned on, normal mail will suffer only
|
||||
a short delay of up to 9 seconds while an address is verified for
|
||||
a short delay of up to 6 seconds while an address is verified for
|
||||
the first time. Once an address status is known, the status is
|
||||
cached and Postfix replies immediately. When verification takes
|
||||
longer than 9 seconds the Postfix SMTP server defers the sender or
|
||||
recipient address with a 450 reply. Normal mail clients will connect
|
||||
again after some delay.
|
||||
too long the Postfix SMTP server defers the sender or recipient
|
||||
address with a 450 reply. Normal mail clients will connect again
|
||||
after some delay.
|
||||
|
||||
The address verification delay is configurable with the main.cf
|
||||
address_verify_poll_count and address_verify_poll_delay parameters.
|
||||
See the sample-verify.cf file for details.
|
||||
|
||||
Limitations
|
||||
===========
|
||||
|
||||
@ -16,6 +16,12 @@ This feature is meant to be used as follows:
|
||||
Internet -> smtpd -> proxy -> smtpd -> cleanup -> queue
|
||||
Postfix Postfix Postfix Postfix
|
||||
|
||||
For reference, this is the normal path from network to mail queue:
|
||||
|
||||
Internet -> smtpd -> cleanup -> queue
|
||||
Postfix Postfix Postfix
|
||||
|
||||
|
||||
Limitations
|
||||
===========
|
||||
|
||||
@ -72,7 +78,9 @@ process.
|
||||
/etc/postfix/master.cf
|
||||
smtp inet n - n - - smtpd
|
||||
-o smtpd_proxy_filter=26
|
||||
26 inet n - n - - smtpd
|
||||
:26 inet n - n - - smtpd
|
||||
|
||||
The ":26" causes Postfix to listen on the localhost address only.
|
||||
|
||||
The result is as follows:
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ snapshot release). Patches change the patchlevel and the release
|
||||
date. Snapshots change only the release date, unless they include
|
||||
the same bugfixes as a patch release.
|
||||
|
||||
Incompatible changes with Postfix snapshot 2.0.13-20030702
|
||||
Incompatible changes with Postfix snapshot 2.0.13-20030704
|
||||
==========================================================
|
||||
|
||||
Support for client side LDAP caching is gone. OpenLDAP 2.1.13 and
|
||||
@ -31,7 +31,7 @@ Postfix now ignores cache controlling parameters in an LDAP
|
||||
configuration file and logs a warning. Credits to Victor Duchovni
|
||||
and Lamont Jones.
|
||||
|
||||
Major changes with Postfix snapshot 2.0.13-20030702
|
||||
Major changes with Postfix snapshot 2.0.13-20030704
|
||||
===================================================
|
||||
|
||||
The Postfix SMTP server can be configured to send all mail into a
|
||||
|
||||
@ -29,8 +29,10 @@
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-
|
||||
# expression map where patterns are given as regular expres-
|
||||
# sions. In that case, the lookups are done in a slightly
|
||||
# different way as described below.
|
||||
# sions, or lookups can be directed to TCP-based server. In
|
||||
# that case, the lookups are done in a slightly different
|
||||
# way as described below under "REGULAR EXPRESSION TABLES"
|
||||
# and "TCP-BASED TABLES".
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# The format of the access table is as follows:
|
||||
@ -77,7 +79,7 @@
|
||||
# specified with the smtpd_null_access_lookup_key parameter
|
||||
# in the Postfix main.cf file.
|
||||
#
|
||||
# ADDRESS EXTENSION
|
||||
# EMAIL 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@,
|
||||
@ -108,75 +110,76 @@
|
||||
# A network address is a sequence of one or more
|
||||
# octets separated by ".".
|
||||
#
|
||||
# NOTE: use the cidr lookup table type if you want to
|
||||
# specify arbitrary network blocks.
|
||||
# NOTE: use the cidr lookup table type if to specify
|
||||
# network/netmask patterns. See cidr_table(5) for
|
||||
# details.
|
||||
#
|
||||
# ACTIONS
|
||||
# [45]NN text
|
||||
# Reject the address etc. that matches the pattern,
|
||||
# Reject the address etc. that matches the pattern,
|
||||
# and respond with the numerical code and text.
|
||||
#
|
||||
# REJECT
|
||||
#
|
||||
# REJECT optional text...
|
||||
# Reject the address etc. that matches the pattern.
|
||||
# Reply with $reject_code optional text... when the
|
||||
# optional text is specified, otherwise reply with a
|
||||
# Reject the address etc. that matches the pattern.
|
||||
# Reply with $reject_code optional text... when the
|
||||
# optional text is specified, otherwise reply with a
|
||||
# generic error response message.
|
||||
#
|
||||
# OK Accept the address etc. that matches the pattern.
|
||||
#
|
||||
# all-numerical
|
||||
# An all-numerical result is treated as OK. This for-
|
||||
# mat is generated by address-based relay authoriza-
|
||||
# mat is generated by address-based relay authoriza-
|
||||
# tion schemes.
|
||||
#
|
||||
# DUNNO Pretend that the lookup key was not found in this
|
||||
# DUNNO Pretend that the lookup key was not found in this
|
||||
# table. This prevents Postfix from trying substrings
|
||||
# of the lookup key (such as a subdomain name, or a
|
||||
# of the lookup key (such as a subdomain name, or a
|
||||
# network address subnetwork).
|
||||
#
|
||||
# HOLD
|
||||
#
|
||||
# HOLD optional text...
|
||||
# Place the message on the hold queue, where it will
|
||||
# sit until someone either deletes it or releases it
|
||||
# for delivery. Log the optional text if specified,
|
||||
# Place the message on the hold queue, where it will
|
||||
# sit until someone either deletes it or releases it
|
||||
# for delivery. Log the optional text if specified,
|
||||
# otherwise log a generic message.
|
||||
#
|
||||
# Mail that is placed on hold can be examined with
|
||||
# the postcat(1) command, and can be destroyed or
|
||||
# Mail that is placed on hold can be examined with
|
||||
# the postcat(1) command, and can be destroyed or
|
||||
# released with the postsuper(1) command.
|
||||
#
|
||||
# Note: this action currently affects all recipients
|
||||
# Note: this action currently affects all recipients
|
||||
# of the message.
|
||||
#
|
||||
# DISCARD
|
||||
#
|
||||
# DISCARD optional text...
|
||||
# Claim successful delivery and silently discard the
|
||||
# message. Log the optional text if specified, oth-
|
||||
# Claim successful delivery and silently discard the
|
||||
# message. Log the optional text if specified, oth-
|
||||
# erwise log a generic message.
|
||||
#
|
||||
# Note: this action currently affects all recipients
|
||||
# Note: this action currently affects all recipients
|
||||
# of the message.
|
||||
#
|
||||
# FILTER transport:destination
|
||||
# After the message is queued, send the entire mes-
|
||||
# sage through a content filter. More information
|
||||
# After the message is queued, send the entire mes-
|
||||
# sage through a content filter. More information
|
||||
# about content filters is in the Postfix FIL-
|
||||
# TER_README file.
|
||||
#
|
||||
# Note: this action overrides the main.cf con-
|
||||
# Note: this action overrides the main.cf con-
|
||||
# tent_filter setting, and currently affects all
|
||||
# recipients of the message.
|
||||
#
|
||||
# REDIRECT user@domain
|
||||
# After the message is queued, send the message to
|
||||
# After the message is queued, send the message to
|
||||
# the specified address instead of the intended
|
||||
# recipient(s).
|
||||
#
|
||||
# Note: this action overrides the FILTER action, and
|
||||
# Note: this action overrides the FILTER action, and
|
||||
# currently affects all recipients of the message.
|
||||
#
|
||||
# restriction...
|
||||
@ -184,28 +187,44 @@
|
||||
# reject_unauth_destination, and so on).
|
||||
#
|
||||
# REGULAR EXPRESSION TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# This section describes how the table lookups change when
|
||||
# the table is given in the form of regular expressions. For
|
||||
# a description of regular expression lookup table syntax,
|
||||
# a description of regular expression lookup table syntax,
|
||||
# see regexp_table(5) or pcre_table(5).
|
||||
#
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# the entire string being looked up. Depending on the appli-
|
||||
# cation, that string is an entire client hostname, an
|
||||
# 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,
|
||||
# user@domain mail addresses are not broken up into their
|
||||
# user@domain mail addresses are not broken up into their
|
||||
# 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
|
||||
# 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 indexed file lookups, with
|
||||
# the additional feature that parenthesized substrings from
|
||||
# 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.
|
||||
#
|
||||
# TCP-BASED TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# lookups are directed to a TCP-based server. For a descrip-
|
||||
# tion of the TCP client/server lookup protocol, see
|
||||
# tcp_table(5).
|
||||
#
|
||||
# Each lookup operation uses the entire query string once.
|
||||
# Depending on the application, that string is an entire
|
||||
# client hostname, an entire client IP address, or an entire
|
||||
# mail address. Thus, no parent domain or parent network
|
||||
# search is done, user@domain mail addresses are not broken
|
||||
# up into their user@ and domain constituent parts, nor is
|
||||
# user+foo broken up into user and foo.
|
||||
#
|
||||
# Actions are the same as with indexed file lookups.
|
||||
#
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
#
|
||||
@ -215,6 +234,7 @@
|
||||
# cidr_table(5) format of CIDR tables
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
|
||||
@ -28,8 +28,10 @@
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-
|
||||
# expression map where patterns are given as regular expres-
|
||||
# sions. In that case, the lookups are done in a slightly
|
||||
# different way as described below.
|
||||
# sions, or lookups can be directed to TCP-based server. In
|
||||
# that case, the lookups are done in a slightly different
|
||||
# way as described below under "REGULAR EXPRESSION TABLES"
|
||||
# and "TCP-BASED TABLES".
|
||||
#
|
||||
# The canonical mapping affects both message header
|
||||
# addresses (i.e. addresses that appear inside messages) and
|
||||
@ -119,6 +121,19 @@
|
||||
# the additional feature that parenthesized substrings from
|
||||
# the pattern can be interpolated as $1, $2 and so on.
|
||||
#
|
||||
# TCP-BASED TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# lookups are directed to a TCP-based server. For a descrip-
|
||||
# tion of the TCP client/server lookup protocol, see
|
||||
# tcp_table(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# user@domain mail addresses are not broken up into their
|
||||
# user and @domain constituent parts, nor is user+foo broken
|
||||
# up into user and foo.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
#
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
#
|
||||
@ -176,6 +191,7 @@
|
||||
# virtual(5) virtual domain mapping
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
|
||||
@ -41,15 +41,16 @@
|
||||
# line that starts with whitespace continues a logi-
|
||||
# cal line.
|
||||
#
|
||||
# SEARCH ORDER
|
||||
# Patterns are applied in the order as specified in the
|
||||
# table, until a pattern is found that matches the search
|
||||
# string.
|
||||
#
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# /etc/postfix/main.cf:
|
||||
# smtpd_client_restrictions = ... cidr:/etc/postfix/client_cidr ...
|
||||
# smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
|
||||
#
|
||||
# /etc/postfix/client_cidr:
|
||||
# /etc/postfix/client.cidr:
|
||||
# # Rule order matters. Put more specific whitelist entries
|
||||
# # before more general blacklist entries.
|
||||
# 192.168.1.1 OK
|
||||
|
||||
@ -20,6 +20,7 @@
|
||||
# To test lookup tables, use the postmap command as
|
||||
# described in the SYNOPSIS above.
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# The general form of a PCRE table is:
|
||||
#
|
||||
# /pattern/flags result
|
||||
@ -118,6 +119,11 @@
|
||||
# thus reserving these combinations for future expan-
|
||||
# sion.
|
||||
#
|
||||
# SEARCH ORDER
|
||||
# Patterns are applied in the order as specified in the
|
||||
# table, until a pattern is found that matches the search
|
||||
# string.
|
||||
#
|
||||
# Each pattern is applied to the entire lookup key string.
|
||||
# Depending on the application, that string is an entire
|
||||
# client hostname, an entire client IP address, or an entire
|
||||
@ -126,18 +132,16 @@
|
||||
# broken up into their 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.
|
||||
#
|
||||
# TEXT SUBSTITUTION
|
||||
# Substitution of substrings from the matched expression
|
||||
# into the result string is possible using the conventional
|
||||
# perl syntax ($1, $2, etc.). The macros in the result
|
||||
# string may need to be written as ${n} or $(n) if they
|
||||
# aren't followed by whitespace. Since negated patterns
|
||||
# (those preceded by !) return a result when the expression
|
||||
# does not match, substitutions are not available for
|
||||
# negated patterns.
|
||||
# aren't followed by whitespace.
|
||||
#
|
||||
# Note: since negated patterns (those preceded by !) return
|
||||
# a result when the expression does not match, substitutions
|
||||
# are not available for negated patterns.
|
||||
#
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# # Protect your outgoing majordomo exploders
|
||||
|
||||
@ -20,6 +20,7 @@
|
||||
# To test lookup tables, use the postmap command as
|
||||
# described in the SYNOPSIS above.
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# The general form of a Postfix regular expression table is:
|
||||
#
|
||||
# /pattern/flags result
|
||||
@ -60,6 +61,11 @@
|
||||
# and `m' (enable multi-line mode, that is, treat newline
|
||||
# characters as special).
|
||||
#
|
||||
# TABLE SEARCH ORDER
|
||||
# Patterns are applied in the order as specified in the
|
||||
# table, until a pattern is found that matches the search
|
||||
# string.
|
||||
#
|
||||
# Each pattern is applied to the entire lookup key string.
|
||||
# Depending on the application, that string is an entire
|
||||
# client hostname, an entire client IP address, or an entire
|
||||
@ -68,17 +74,15 @@
|
||||
# broken up into their 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.
|
||||
#
|
||||
# TEXT SUBSTITUTION
|
||||
# Substitution of substrings from the matched expression
|
||||
# into the result string is possible using $1, $2, etc.. The
|
||||
# macros in the result string may need to be written as ${n}
|
||||
# or $(n) if they aren't followed by whitespace. Since
|
||||
# negated patterns (those preceded by !) return a result
|
||||
# when the expression does not match, substitutions are not
|
||||
# available for negated patterns.
|
||||
# or $(n) if they aren't followed by whitespace.
|
||||
#
|
||||
# Note: since negated patterns (those preceded by !) return
|
||||
# a result when the expression does not match, substitutions
|
||||
# are not available for negated patterns.
|
||||
#
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# # Disallow sender-specified routing. This is a must if you relay mail
|
||||
|
||||
@ -24,8 +24,10 @@
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-
|
||||
# expression map where patterns are given as regular expres-
|
||||
# sions. In that case, the lookups are done in a slightly
|
||||
# different way as described below.
|
||||
# sions, or lookups can be directed to TCP-based server. In
|
||||
# that case, the lookups are done in a slightly different
|
||||
# way as described below under "REGULAR EXPRESSION TABLES"
|
||||
# and "TCP-BASED TABLES".
|
||||
#
|
||||
# Table lookups are case insensitive.
|
||||
#
|
||||
@ -70,31 +72,46 @@
|
||||
#
|
||||
# REGULAR EXPRESSION TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# the table is given in the form of regular expressions. For
|
||||
# a description of regular expression lookup table syntax,
|
||||
# see regexp_table(5) or pcre_table(5).
|
||||
# the table is given in the form of regular expressions or
|
||||
# when lookups are directed to a TCP-based server. For a
|
||||
# description of regular expression lookup table syntax, see
|
||||
# regexp_table(5) or pcre_table(5). For a description of the
|
||||
# TCP client/server table lookup protocol, see tcp_table(5).
|
||||
#
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# the entire address being looked up. Thus, user@domain mail
|
||||
# addresses are not broken up into their user and @domain
|
||||
# addresses are not broken up into their 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
|
||||
# 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 indexed file lookups, with
|
||||
# the additional feature that parenthesized substrings from
|
||||
# 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.
|
||||
#
|
||||
# TCP-BASED TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# lookups are directed to a TCP-based server. For a descrip-
|
||||
# tion of the TCP client/server lookup protocol, see
|
||||
# tcp_table(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# user@domain mail addresses are not broken up into their
|
||||
# user and @domain constituent parts, nor is user+foo broken
|
||||
# up into user and foo.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
#
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
# The table format does not understand quoting conventions.
|
||||
#
|
||||
# CONFIGURATION PARAMETERS
|
||||
# The following main.cf parameters are especially relevant
|
||||
# to this topic. See the Postfix main.cf file for syntax
|
||||
# details and for default values. Use the postfix reload
|
||||
# The following main.cf parameters are especially relevant
|
||||
# to this topic. See the Postfix main.cf file for syntax
|
||||
# details and for default values. Use the postfix reload
|
||||
# command after a configuration change.
|
||||
#
|
||||
# relocated_maps
|
||||
@ -103,12 +120,12 @@
|
||||
# Other parameters of interest:
|
||||
#
|
||||
# inet_interfaces
|
||||
# The network interface addresses that this system
|
||||
# The network interface addresses that this system
|
||||
# receives mail on. You need to stop and start Post-
|
||||
# fix when this parameter changes.
|
||||
#
|
||||
# mydestination
|
||||
# List of domains that this mail system considers
|
||||
# List of domains that this mail system considers
|
||||
# local.
|
||||
#
|
||||
# myorigin
|
||||
@ -118,9 +135,10 @@
|
||||
# postmap(1) create lookup table
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
# The Secure Mailer license must be distributed with this
|
||||
# software.
|
||||
#
|
||||
# AUTHOR(S)
|
||||
|
||||
@ -24,18 +24,25 @@ address_verify_sender = postmaster
|
||||
|
||||
# The address_verify_poll_count parameter specifies how many times
|
||||
# to query the address verification service for completion of an
|
||||
# address verification request. Specify 0 to implement a simple form
|
||||
# of greylisting, that is, always defer the first delivery request
|
||||
# from an unknown sender address.
|
||||
# address verification request.
|
||||
#
|
||||
#address_verify_poll_count = 0
|
||||
# The default poll count is 3.
|
||||
#
|
||||
# Specify 1 to implement a crude form of greylisting, that is, always
|
||||
# defer the first delivery request for a never seen before address.
|
||||
#
|
||||
#address_verify_poll_count = 1
|
||||
address_verify_poll_count = 3
|
||||
|
||||
# The address_verify_poll_delay parameter specifies how long to wait
|
||||
# after querying the address verification service for completion of
|
||||
# an address verification request.
|
||||
#
|
||||
address_verify_poll_delay = 3
|
||||
# The default polling delay is 3 seconds.
|
||||
#
|
||||
# Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
|
||||
#
|
||||
address_verify_poll_delay = 3s
|
||||
|
||||
#
|
||||
# CACHE CONTROL
|
||||
|
||||
@ -6,13 +6,13 @@
|
||||
# SYNOPSIS
|
||||
# postmap -q "string" tcp:host:port
|
||||
#
|
||||
# postmap -q - regexp:host:port <inputfile
|
||||
# postmap -q - tcp:host:port <inputfile
|
||||
#
|
||||
# DESCRIPTION
|
||||
# The Postfix mail system uses optional tables for address
|
||||
# rewriting or mail routing. These tables are usually in dbm
|
||||
# or db format. Alternatively, lookup tables can be speci-
|
||||
# fied as a TCP client/server pair.
|
||||
# or db format. Alternatively, table lookups can be directed
|
||||
# to a TCP server.
|
||||
#
|
||||
# To find out what types of lookup tables your Postfix sys-
|
||||
# tem supports use the postconf -m command.
|
||||
@ -27,16 +27,9 @@
|
||||
# terminated by the ASCII newline character. Request and
|
||||
# reply parameters (see below) are separated by whitespace.
|
||||
#
|
||||
# ENCODING
|
||||
# In request and reply parameters, the character % and any
|
||||
# non-printing and whitespace characters must be replaced by
|
||||
# %XX, XX being the corresponding ASCII hexadecimal charac-
|
||||
# ter value. The hexadecimal codes can be specified in any
|
||||
# case (upper, lower, mixed).
|
||||
#
|
||||
# REQUEST FORMAT
|
||||
# Requests are strings that serve as lookup key in the simu-
|
||||
# lated table.
|
||||
# Each request specifies a command, a lookup key, and possi-
|
||||
# bly a lookup result.
|
||||
#
|
||||
# get SPACE key NEWLINE
|
||||
# Look up data under the specified key.
|
||||
@ -45,24 +38,41 @@
|
||||
# This request is currently not implemented.
|
||||
#
|
||||
# REPLY FORMAT
|
||||
# Replies must be no longer than 4096 characters including
|
||||
# the newline terminator, and must have the following form:
|
||||
# Each reply specifies a status code and text. Replies must
|
||||
# be no longer than 4096 characters including the newline
|
||||
# terminator.
|
||||
#
|
||||
# 500 SPACE optional-text NEWLINE
|
||||
# In case of a lookup request, the requested data
|
||||
# does not exist. In case of an update request, the
|
||||
# request was rejected.
|
||||
# 500 SPACE text NEWLINE
|
||||
# In case of a lookup request, the requested data
|
||||
# does not exist. In case of an update request, the
|
||||
# request was rejected. The text describes the
|
||||
# nature of the problem.
|
||||
#
|
||||
# 400 SPACE optional-text NEWLINE
|
||||
# This indicates an error condition. The text gives
|
||||
# the nature of the problem. The client should retry
|
||||
# the request later.
|
||||
# 400 SPACE text NEWLINE
|
||||
# This indicates an error condition. The text
|
||||
# describes the nature of the problem. The client
|
||||
# should retry the request later.
|
||||
#
|
||||
# 200 SPACE text NEWLINE
|
||||
# The request was successful. In the case of a lookup
|
||||
# request, the text contains an encoded version of
|
||||
# the requested data. Otherwise the text is
|
||||
# optional.
|
||||
# the requested data.
|
||||
#
|
||||
# ENCODING
|
||||
# In request and reply parameters, the character %, each
|
||||
# non-printing character, and each whitespace character must
|
||||
# be replaced by %XX, where XX is the corresponding ASCII
|
||||
# hexadecimal character value. The hexadecimal codes can be
|
||||
# specified in any case (upper, lower, mixed).
|
||||
#
|
||||
# The Postfix client always encodes a request. The server
|
||||
# may omit the encoding as long as the reply is guaranteed
|
||||
# to not contain the % or NEWLINE character.
|
||||
#
|
||||
# SECURITY
|
||||
# Do not use TCP lookup tables for security critical purposes.
|
||||
# The client-server connection is not protected and the server
|
||||
# is not authenticated.
|
||||
#
|
||||
# SEE ALSO
|
||||
# regexp_table(5) format of regular expression tables
|
||||
@ -72,6 +82,9 @@
|
||||
# BUGS
|
||||
# Only the lookup method is currently implemented.
|
||||
#
|
||||
# The client does not hang up when the connection is idle
|
||||
# for a long time.
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
# software.
|
||||
|
||||
@ -48,9 +48,10 @@
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-
|
||||
# expression map where patterns are given as regular expres-
|
||||
# sions. In that case, the lookups are done in a slightly
|
||||
# different way as described in section "REGULAR EXPRESSION
|
||||
# TABLES".
|
||||
# sions, or lookups can be directed to TCP-based server. In
|
||||
# that case, the lookups are done in a slightly different
|
||||
# way as described below under "REGULAR EXPRESSION TABLES"
|
||||
# and "TCP-BASED TABLES".
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# The format of the transport table is as follows:
|
||||
@ -60,28 +61,28 @@
|
||||
# domain, use the corresponding result.
|
||||
#
|
||||
# blank lines and comments
|
||||
# Empty lines and whitespace-only lines are ignored,
|
||||
# as are lines whose first non-whitespace character
|
||||
# Empty lines and whitespace-only lines are ignored,
|
||||
# as are lines whose first non-whitespace character
|
||||
# is a `#'.
|
||||
#
|
||||
# multi-line text
|
||||
# A logical line starts with non-whitespace text. A
|
||||
# line that starts with whitespace continues a logi-
|
||||
# A logical line starts with non-whitespace text. A
|
||||
# line that starts with whitespace continues a logi-
|
||||
# cal line.
|
||||
#
|
||||
# The pattern specifies an email address, a domain name, or
|
||||
# a domain name hierarchy, as described in section "TABLE
|
||||
# The pattern specifies an email address, a domain name, or
|
||||
# a domain name hierarchy, as described in section "TABLE
|
||||
# LOOKUP".
|
||||
#
|
||||
# The result is of the form transport:nexthop. The trans-
|
||||
# port field specifies a mail delivery transport such as
|
||||
# smtp or local. The nexthop field specifies where and how
|
||||
# The result is of the form transport:nexthop. The trans-
|
||||
# port field specifies a mail delivery transport such as
|
||||
# smtp or local. The nexthop field specifies where and how
|
||||
# to deliver mail. More details are given in section "RESULT
|
||||
# FORMAT".
|
||||
#
|
||||
# TABLE LOOKUP
|
||||
# With lookups from indexed files such as DB or DBM, or from
|
||||
# networked tables such as NIS, LDAP or SQL, patterns are
|
||||
# networked tables such as NIS, LDAP or SQL, patterns are
|
||||
# tried in the order as listed below:
|
||||
#
|
||||
# user+extension@domain transport:nexthop
|
||||
@ -93,134 +94,148 @@
|
||||
# to nexthop.
|
||||
#
|
||||
# domain transport:nexthop
|
||||
# Mail for domain is delivered through transport to
|
||||
# Mail for domain is delivered through transport to
|
||||
# nexthop.
|
||||
#
|
||||
# .domain transport:nexthop
|
||||
# Mail for any subdomain of domain is delivered
|
||||
# through transport to nexthop. This applies only
|
||||
# Mail for any subdomain of domain is delivered
|
||||
# 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
|
||||
# ting. Otherwise, a domain name matches itself and
|
||||
# its subdomains.
|
||||
#
|
||||
# Note 1: the special pattern * represents any address (i.e.
|
||||
# it functions as the wild-card pattern).
|
||||
#
|
||||
# Note 2: the null recipient address is looked up as
|
||||
# Note 2: the null recipient address is looked up as
|
||||
# $empty_address_recipient@$myhostname (default: mailer-dae-
|
||||
# mon@hostname).
|
||||
#
|
||||
# RESULT FORMAT
|
||||
# The transport field specifies the name of a mail delivery
|
||||
# The transport field specifies the name of a mail delivery
|
||||
# transport (the first name of a mail delivery service entry
|
||||
# in the Postfix master.cf file).
|
||||
#
|
||||
# The interpretation of the nexthop field is transport
|
||||
# The interpretation of the nexthop field is transport
|
||||
# dependent. In the case of SMTP, specify host:service for a
|
||||
# non-default server port, and use [host] or [host]:port in
|
||||
# order to disable MX (mail exchanger) DNS lookups. The []
|
||||
# non-default server port, and use [host] or [host]:port in
|
||||
# order to disable MX (mail exchanger) DNS lookups. The []
|
||||
# form is required when you specify an IP address instead of
|
||||
# a hostname.
|
||||
#
|
||||
# A null transport and null nexthop result means "do not
|
||||
# change": use the delivery transport and nexthop informa-
|
||||
# tion that would be used when the entire transport table
|
||||
# A null transport and null nexthop result means "do not
|
||||
# change": use the delivery transport and nexthop informa-
|
||||
# tion that would be used when the entire transport table
|
||||
# did not exist.
|
||||
#
|
||||
# A non-null transport field with a null nexthop field
|
||||
# A non-null transport field with a null nexthop field
|
||||
# resets the nexthop information to the recipient domain.
|
||||
#
|
||||
# A null transport field with non-null nexthop field does
|
||||
# A null transport field with non-null nexthop field does
|
||||
# not modify the transport information.
|
||||
#
|
||||
# EXAMPLES
|
||||
# In order to deliver internal mail directly, while using a
|
||||
# mail relay for all other mail, specify a null entry for
|
||||
# internal destinations (do not change the delivery trans-
|
||||
# port or the nexthop information) and specify a wildcard
|
||||
# In order to deliver internal mail directly, while using a
|
||||
# mail relay for all other mail, specify a null entry for
|
||||
# internal destinations (do not change the delivery trans-
|
||||
# port or the nexthop information) and specify a wildcard
|
||||
# for all other destinations.
|
||||
#
|
||||
# my.domain :
|
||||
# .my.domain :
|
||||
# * smtp:outbound-relay.my.domain
|
||||
# * smtp:outbound-relay.my.domain
|
||||
#
|
||||
# In order to send mail for foo.org and its subdomains via
|
||||
# In order to send mail for foo.org and its subdomains via
|
||||
# the uucp transport to the UUCP host named foo:
|
||||
#
|
||||
# foo.org uucp:foo
|
||||
# .foo.org uucp:foo
|
||||
#
|
||||
# When no nexthop host name is specified, the destination
|
||||
# domain name is used instead. For example, the following
|
||||
# directs mail for user@foo.org via the slow transport to a
|
||||
# mail exchanger for foo.org. The slow transport could be
|
||||
# something that runs at most one delivery process at a
|
||||
# When no nexthop host name is specified, the destination
|
||||
# domain name is used instead. For example, the following
|
||||
# directs mail for user@foo.org via the slow transport to a
|
||||
# mail exchanger for foo.org. The slow transport could be
|
||||
# something that runs at most one delivery process at a
|
||||
# time:
|
||||
#
|
||||
# foo.org slow:
|
||||
#
|
||||
# When no transport is specified, Postfix uses the transport
|
||||
# that matches the address domain class (see TRANSPORT FIELD
|
||||
# discussion above). The following sends all mail for
|
||||
# discussion above). The following sends all mail for
|
||||
# foo.org and its subdomains to host gateway.foo.org:
|
||||
#
|
||||
# foo.org :[gateway.foo.org]
|
||||
# .foo.org :[gateway.foo.org]
|
||||
#
|
||||
# In the above example, the [] are used to suppress MX
|
||||
# lookups. The result would likely point to your local
|
||||
# In the above example, the [] are used to suppress MX
|
||||
# lookups. The result would likely point to your local
|
||||
# machine.
|
||||
#
|
||||
# In the case of delivery via SMTP, one may specify host-
|
||||
# In the case of delivery via SMTP, one may specify host-
|
||||
# name:service instead of just a host:
|
||||
#
|
||||
# foo.org smtp:bar.org:2025
|
||||
#
|
||||
# This directs mail for user@foo.org to host bar.org port
|
||||
# 2025. Instead of a numerical port a symbolic name may be
|
||||
# used. Specify [] around the hostname in order to disable
|
||||
# This directs mail for user@foo.org to host bar.org port
|
||||
# 2025. Instead of a numerical port a symbolic name may be
|
||||
# used. Specify [] around the hostname in order to disable
|
||||
# MX lookups.
|
||||
#
|
||||
# The error mailer can be used to bounce mail:
|
||||
#
|
||||
# .foo.org error:mail for *.foo.org is not deliv-
|
||||
# .foo.org error:mail for *.foo.org is not deliv-
|
||||
# erable
|
||||
#
|
||||
# This causes all mail for user@anything.foo.org to be
|
||||
# This causes all mail for user@anything.foo.org to be
|
||||
# bounced.
|
||||
#
|
||||
# REGULAR EXPRESSION TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# This section describes how the table lookups change when
|
||||
# the table is given in the form of regular expressions. For
|
||||
# a description of regular expression lookup table syntax,
|
||||
# a description of regular expression lookup table syntax,
|
||||
# see regexp_table(5) or pcre_table(5).
|
||||
#
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# the entire domain being looked up. Thus, some.domain.hier-
|
||||
# archy is not broken up into parent domains.
|
||||
# Each pattern is a regular expression that is applied to
|
||||
# the entire address being looked up. Thus,
|
||||
# some.domain.hierarchy is not looked up up via its parent
|
||||
# domains, nor is user+foo@domain looked up as user@domain.
|
||||
#
|
||||
# Patterns are applied in the order as specified in the
|
||||
# table, until a pattern is found that matches the search
|
||||
# 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 indexed file lookups, with
|
||||
# the additional feature that parenthesized substrings from
|
||||
# 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.
|
||||
#
|
||||
# TCP-BASED TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# lookups are directed to a TCP-based server. For a descrip-
|
||||
# tion of the TCP client/server lookup protocol, see
|
||||
# tcp_table(5).
|
||||
#
|
||||
# Each lookup operation uses the entire recipient address
|
||||
# once. Thus, some.domain.hierarchy is not looked up via
|
||||
# its parent domains, nor is user+foo@domain looked up as
|
||||
# user@domain.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
#
|
||||
# CONFIGURATION PARAMETERS
|
||||
# The following main.cf parameters are especially relevant
|
||||
# to this topic. See the Postfix main.cf file for syntax
|
||||
# details and for default values. Use the postfix reload
|
||||
# The following main.cf parameters are especially relevant
|
||||
# to this topic. See the Postfix main.cf file for syntax
|
||||
# details and for default values. Use the postfix reload
|
||||
# command after a configuration change.
|
||||
#
|
||||
# empty_address_recipient
|
||||
# The address that is looked up instead of the null
|
||||
# The address that is looked up instead of the null
|
||||
# sender address.
|
||||
#
|
||||
# parent_domain_matches_subdomains
|
||||
# List of Postfix features that use domain.tld pat-
|
||||
# terns to match sub.domain.tld (as opposed to
|
||||
# List of Postfix features that use domain.tld pat-
|
||||
# terns to match sub.domain.tld (as opposed to
|
||||
# requiring .domain.tld patterns).
|
||||
#
|
||||
# transport_maps
|
||||
@ -231,9 +246,10 @@
|
||||
# trivial-rewrite(8) rewrite and resolve addresses
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
# The Secure Mailer license must be distributed with this
|
||||
# software.
|
||||
#
|
||||
# AUTHOR(S)
|
||||
|
||||
@ -49,8 +49,10 @@
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-
|
||||
# expression map where patterns are given as regular expres-
|
||||
# sions. In that case, the lookups are done in a slightly
|
||||
# different way as described below.
|
||||
# sions, or lookups can be directed to TCP-based server. In
|
||||
# that case, the lookups are done in a slightly different
|
||||
# way as described below under "REGULAR EXPRESSION TABLES"
|
||||
# and "TCP-BASED TABLES".
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# The format of the virtual table is as follows, mappings
|
||||
@ -175,6 +177,19 @@
|
||||
# the additional feature that parenthesized substrings from
|
||||
# the pattern can be interpolated as $1, $2 and so on.
|
||||
#
|
||||
# TCP-BASED TABLES
|
||||
# This section describes how the table lookups change when
|
||||
# lookups are directed to a TCP-based server. For a descrip-
|
||||
# tion of the TCP client/server lookup protocol, see
|
||||
# tcp_table(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# user@domain mail addresses are not broken up into their
|
||||
# user and @domain constituent parts, nor is user+foo broken
|
||||
# up into user and foo.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
#
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
#
|
||||
@ -215,6 +230,7 @@
|
||||
# postmap(1) create mapping table
|
||||
# regexp_table(5) POSIX regular expression table format
|
||||
# pcre_table(5) Perl Compatible Regular Expression table format
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
#
|
||||
# LICENSE
|
||||
# The Secure Mailer license must be distributed with this
|
||||
|
||||
@ -12,7 +12,8 @@ COMMANDS= mailq.1.html newaliases.1.html postalias.1.html postcat.1.html \
|
||||
postlog.1.html postdrop.1.html postmap.1.html sendmail.1.html \
|
||||
postqueue.1.html postsuper.1.html
|
||||
CONFIG = access.5.html aliases.5.html canonical.5.html relocated.5.html \
|
||||
transport.5.html virtual.5.html pcre_table.5.html regexp_table.5.html
|
||||
transport.5.html virtual.5.html pcre_table.5.html regexp_table.5.html \
|
||||
cidr_table.5.html tcp_table.5.html
|
||||
|
||||
AWK = awk '{ print; if (NR == 1) print ".pl 9999" }'
|
||||
|
||||
@ -186,6 +187,10 @@ aliases.5.html: ../proto/aliases
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
|
||||
cidr_table.5.html: ../proto/cidr_table
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
|
||||
canonical.5.html: ../proto/canonical
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
@ -202,6 +207,10 @@ relocated.5.html: ../proto/relocated
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
|
||||
tcp_table.5.html: ../proto/tcp_table
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
|
||||
transport.5.html: ../proto/transport
|
||||
PATH=../mantools:$$PATH; \
|
||||
srctoman - $? | $(AWK) | nroff -man | uniq | man2html | postlink >$@
|
||||
|
||||
@ -5,11 +5,11 @@ ACCESS(5) ACCESS(5)
|
||||
access - format of Postfix access table
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>/etc/postfix/access</b>
|
||||
<b>postmap /etc/postfix/access</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>/etc/postfix/access</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" /etc/postfix/access</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>/etc/postfix/access</b> <<i>inputfile</i>
|
||||
<b>postmap -q - /etc/postfix/access</b> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The optional <b>access</b> table directs the Postfix SMTP server
|
||||
@ -21,7 +21,7 @@ ACCESS(5) ACCESS(5)
|
||||
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
||||
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
||||
fast searching by the mail system. Execute the command
|
||||
<b>postmap</b> <b>/etc/postfix/access</b> in order to rebuild the
|
||||
<b>postmap /etc/postfix/access</b> in order to rebuild the
|
||||
indexed file after changing the access table.
|
||||
|
||||
When the table is provided via other means such as NIS,
|
||||
@ -30,13 +30,15 @@ ACCESS(5) ACCESS(5)
|
||||
|
||||
Alternatively, the table can be provided as a regular-
|
||||
expression map where patterns are given as regular expres-
|
||||
sions. In that case, the lookups are done in a slightly
|
||||
different way as described below.
|
||||
sions, or lookups can be directed to TCP-based server. In
|
||||
that case, the lookups are done in a slightly different
|
||||
way as described below under "REGULAR EXPRESSION TABLES"
|
||||
and "TCP-BASED TABLES".
|
||||
|
||||
<b>TABLE</b> <b>FORMAT</b>
|
||||
<b>TABLE FORMAT</b>
|
||||
The format of the access table is as follows:
|
||||
|
||||
<i>pattern</i> <i>action</i>
|
||||
<i>pattern action</i>
|
||||
When <i>pattern</i> matches a mail address, domain or host
|
||||
address, perform the corresponding <i>action</i>.
|
||||
|
||||
@ -50,7 +52,7 @@ ACCESS(5) ACCESS(5)
|
||||
line that starts with whitespace continues a logi-
|
||||
cal line.
|
||||
|
||||
<b>EMAIL</b> <b>ADDRESS</b> <b>PATTERNS</b>
|
||||
<b>EMAIL ADDRESS 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:
|
||||
@ -78,13 +80,13 @@ ACCESS(5) ACCESS(5)
|
||||
specified with the <b>smtpd</b><i>_</i><b>null</b><i>_</i><b>access</b><i>_</i><b>lookup</b><i>_</i><b>key</b> parameter
|
||||
in the Postfix <b>main.cf</b> file.
|
||||
|
||||
<b>ADDRESS</b> <b>EXTENSION</b>
|
||||
<b>EMAIL ADDRESS 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>
|
||||
<b>HOST NAME/ADDRESS 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:
|
||||
@ -109,113 +111,131 @@ ACCESS(5) ACCESS(5)
|
||||
A network address is a sequence of one or more
|
||||
octets separated by ".".
|
||||
|
||||
NOTE: use the <b>cidr</b> lookup table type if you want to
|
||||
specify arbitrary network blocks.
|
||||
NOTE: use the <b>cidr</b> lookup table type if to specify
|
||||
network/netmask patterns. See <a href="cidr_table.5.html">cidr_table(5)</a> for
|
||||
details.
|
||||
|
||||
<b>ACTIONS</b>
|
||||
[<b>45</b>]<i>NN</i> <i>text</i>
|
||||
Reject the address etc. that matches the pattern,
|
||||
[<b>45</b>]<i>NN text</i>
|
||||
Reject the address etc. that matches the pattern,
|
||||
and respond with the numerical code and text.
|
||||
|
||||
<b>REJECT</b>
|
||||
|
||||
<b>REJECT</b> <i>optional</i> <i>text...</i>
|
||||
Reject the address etc. that matches the pattern.
|
||||
Reply with <i>$reject_code</i> <i>optional</i> <i>text...</i> when the
|
||||
optional text is specified, otherwise reply with a
|
||||
<b>REJECT</b> <i>optional text...</i>
|
||||
Reject the address etc. that matches the pattern.
|
||||
Reply with <i>$reject_code optional text...</i> when the
|
||||
optional text is specified, otherwise reply with a
|
||||
generic error response message.
|
||||
|
||||
<b>OK</b> Accept the address etc. that matches the pattern.
|
||||
|
||||
<i>all-numerical</i>
|
||||
An all-numerical result is treated as OK. This for-
|
||||
mat is generated by address-based relay authoriza-
|
||||
mat is generated by address-based relay authoriza-
|
||||
tion schemes.
|
||||
|
||||
<b>DUNNO</b> Pretend that the lookup key was not found in this
|
||||
<b>DUNNO</b> Pretend that the lookup key was not found in this
|
||||
table. This prevents Postfix from trying substrings
|
||||
of the lookup key (such as a subdomain name, or a
|
||||
of the lookup key (such as a subdomain name, or a
|
||||
network address subnetwork).
|
||||
|
||||
<b>HOLD</b>
|
||||
|
||||
<b>HOLD</b> <i>optional</i> <i>text...</i>
|
||||
Place the message on the <b>hold</b> queue, where it will
|
||||
sit until someone either deletes it or releases it
|
||||
for delivery. Log the optional text if specified,
|
||||
<b>HOLD</b> <i>optional text...</i>
|
||||
Place the message on the <b>hold</b> queue, where it will
|
||||
sit until someone either deletes it or releases it
|
||||
for delivery. Log the optional text if specified,
|
||||
otherwise log a generic message.
|
||||
|
||||
Mail that is placed on hold can be examined with
|
||||
the <a href="postcat.1.html"><b>postcat</b>(1)</a> command, and can be destroyed or
|
||||
Mail that is placed on hold can be examined with
|
||||
the <a href="postcat.1.html"><b>postcat</b>(1)</a> command, and can be destroyed or
|
||||
released with the <a href="postsuper.1.html"><b>postsuper</b>(1)</a> command.
|
||||
|
||||
Note: this action currently affects all recipients
|
||||
of the message.
|
||||
|
||||
<b>DISCARD</b>
|
||||
|
||||
<b>DISCARD</b> <i>optional</i> <i>text...</i>
|
||||
Claim successful delivery and silently discard the
|
||||
message. Log the optional text if specified, oth-
|
||||
erwise log a generic message.
|
||||
|
||||
Note: this action currently affects all recipients
|
||||
of the message.
|
||||
|
||||
<b>DISCARD</b>
|
||||
|
||||
<b>DISCARD</b> <i>optional text...</i>
|
||||
Claim successful delivery and silently discard the
|
||||
message. Log the optional text if specified, oth-
|
||||
erwise log a generic message.
|
||||
|
||||
Note: this action currently affects all recipients
|
||||
of the message.
|
||||
|
||||
<b>FILTER</b> <i>transport:destination</i>
|
||||
After the message is queued, send the entire mes-
|
||||
sage through a content filter. More information
|
||||
After the message is queued, send the entire mes-
|
||||
sage through a content filter. More information
|
||||
about content filters is in the Postfix FIL-
|
||||
TER_README file.
|
||||
|
||||
Note: this action overrides the <b>main.cf</b> <b>con-</b>
|
||||
Note: this action overrides the <b>main.cf con-</b>
|
||||
<b>tent</b><i>_</i><b>filter</b> setting, and currently affects all
|
||||
recipients of the message.
|
||||
|
||||
<b>REDIRECT</b> <i>user@domain</i>
|
||||
After the message is queued, send the message to
|
||||
After the message is queued, send the message to
|
||||
the specified address instead of the intended
|
||||
recipient(s).
|
||||
|
||||
Note: this action overrides the FILTER action, and
|
||||
Note: this action overrides the FILTER action, and
|
||||
currently affects all recipients of the message.
|
||||
|
||||
<i>restriction...</i>
|
||||
Apply the named UCE restriction(s) (<b>permit</b>, <b>reject</b>,
|
||||
<b>reject</b><i>_</i><b>unauth</b><i>_</i><b>destination</b>, and so on).
|
||||
|
||||
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
<b>REGULAR EXPRESSION TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
the table is given in the form of regular expressions. For
|
||||
a description of regular expression lookup table syntax,
|
||||
a description of regular expression lookup table syntax,
|
||||
see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
|
||||
|
||||
Each pattern is a regular expression that is applied to
|
||||
Each pattern is a regular expression that is applied to
|
||||
the entire string being looked up. Depending on the appli-
|
||||
cation, that string is an entire client hostname, an
|
||||
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,
|
||||
<i>user@domain</i> mail addresses are not broken up into their
|
||||
<i>user@domain</i> mail addresses are not broken up into their
|
||||
<i>user@</i> and <i>domain</i> constituent parts, nor is <i>user+foo</i> broken
|
||||
up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
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 indexed file lookups, with
|
||||
the additional feature that parenthesized substrings from
|
||||
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>TCP-BASED TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
lookups are directed to a TCP-based server. For a descrip-
|
||||
tion of the TCP client/server lookup protocol, see
|
||||
<b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
Each lookup operation uses the entire query string once.
|
||||
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, <i>user@domain</i> mail addresses are not broken
|
||||
up into their <i>user@</i> and <i>domain</i> constituent parts, nor is
|
||||
<i>user+foo</i> broken up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Actions are the same as with indexed file lookups.
|
||||
|
||||
<b>BUGS</b>
|
||||
The table format does not understand quoting conventions.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="postmap.1.html">postmap(1)</a> create lookup table
|
||||
<a href="smtpd.8.html">smtpd(8)</a> smtp server
|
||||
cidr_table(5) format of CIDR tables
|
||||
<a href="cidr_table.5.html">cidr_table(5)</a> format of CIDR tables
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
|
||||
@ -5,11 +5,11 @@ CANONICAL(5) CANONICAL(5)
|
||||
canonical - format of Postfix canonical table
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>/etc/postfix/canonical</b>
|
||||
<b>postmap /etc/postfix/canonical</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>/etc/postfix/canonical</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" /etc/postfix/canonical</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>/etc/postfix/canonical</b> <<i>inputfile</i>
|
||||
<b>postmap -q - /etc/postfix/canonical</b> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The optional <b>canonical</b> table specifies an address mapping
|
||||
@ -20,7 +20,7 @@ CANONICAL(5) CANONICAL(5)
|
||||
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
||||
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
||||
fast searching by the mail system. Execute the command
|
||||
<b>postmap</b> <b>/etc/postfix/canonical</b> in order to rebuild the
|
||||
<b>postmap /etc/postfix/canonical</b> in order to rebuild the
|
||||
indexed file after changing the text file.
|
||||
|
||||
When the table is provided via other means such as NIS,
|
||||
@ -29,8 +29,10 @@ CANONICAL(5) CANONICAL(5)
|
||||
|
||||
Alternatively, the table can be provided as a regular-
|
||||
expression map where patterns are given as regular expres-
|
||||
sions. In that case, the lookups are done in a slightly
|
||||
different way as described below.
|
||||
sions, or lookups can be directed to TCP-based server. In
|
||||
that case, the lookups are done in a slightly different
|
||||
way as described below under "REGULAR EXPRESSION TABLES"
|
||||
and "TCP-BASED TABLES".
|
||||
|
||||
The <b>canonical</b> mapping affects both message header
|
||||
addresses (i.e. addresses that appear inside messages) and
|
||||
@ -48,10 +50,10 @@ CANONICAL(5) CANONICAL(5)
|
||||
The <b>canonical</b> mapping is not to be confused with local
|
||||
aliasing. Use the <a href="aliases.5.html"><b>aliases</b>(5)</a> map for that purpose.
|
||||
|
||||
<b>TABLE</b> <b>FORMAT</b>
|
||||
<b>TABLE FORMAT</b>
|
||||
The format of the <b>canonical</b> table is as follows:
|
||||
|
||||
<i>pattern</i> <i>result</i>
|
||||
<i>pattern result</i>
|
||||
When <i>pattern</i> matches a mail address, replace it by
|
||||
the corresponding <i>result</i>.
|
||||
|
||||
@ -69,7 +71,7 @@ CANONICAL(5) CANONICAL(5)
|
||||
networked tables such as NIS, LDAP or SQL, patterns are
|
||||
tried in the order as listed below:
|
||||
|
||||
<i>user</i>@<i>domain</i> <i>address</i>
|
||||
<i>user</i>@<i>domain address</i>
|
||||
<i>user</i>@<i>domain</i> is replaced by <i>address</i>. This form has
|
||||
the highest precedence.
|
||||
|
||||
@ -78,7 +80,7 @@ CANONICAL(5) CANONICAL(5)
|
||||
duce <i>Firstname.Lastname</i> style addresses, but see
|
||||
below for a simpler solution.
|
||||
|
||||
<i>user</i> <i>address</i>
|
||||
<i>user address</i>
|
||||
<i>user</i>@<i>site</i> is replaced by <i>address</i> when <i>site</i> is equal
|
||||
to $<b>myorigin</b>, when <i>site</i> is listed in $<b>mydestina-</b>
|
||||
<b>tion</b>, or when it is listed in $<b>inet</b><i>_</i><b>interfaces</b>.
|
||||
@ -86,21 +88,21 @@ CANONICAL(5) CANONICAL(5)
|
||||
This form is useful for replacing login names by
|
||||
<i>Firstname.Lastname</i>.
|
||||
|
||||
@<i>domain</i> <i>address</i>
|
||||
@<i>domain address</i>
|
||||
Every address in <i>domain</i> is replaced by <i>address</i>.
|
||||
This form has the lowest precedence.
|
||||
|
||||
In all the above forms, when <i>address</i> has the form @<i>other-</i>
|
||||
<i>domain</i>, the result is the same user in <i>otherdomain</i>.
|
||||
|
||||
<b>ADDRESS</b> <b>EXTENSION</b>
|
||||
<b>ADDRESS 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>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>
|
||||
<b>REGULAR EXPRESSION TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
the table is given in the form of regular expressions. For
|
||||
a description of regular expression lookup table syntax,
|
||||
@ -120,13 +122,26 @@ CANONICAL(5) CANONICAL(5)
|
||||
the additional feature that parenthesized substrings from
|
||||
the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
|
||||
|
||||
<b>TCP-BASED TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
lookups are directed to a TCP-based server. For a descrip-
|
||||
tion of the TCP client/server lookup protocol, see
|
||||
<b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
<i>user@domain</i> mail addresses are not broken up into their
|
||||
<i>user</i> and <i>@domain</i> constituent parts, nor is <i>user+foo</i> broken
|
||||
up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
|
||||
<b>BUGS</b>
|
||||
The table format does not understand quoting conventions.
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>canonical</b><i>_</i><b>maps</b>
|
||||
@ -171,12 +186,13 @@ CANONICAL(5) CANONICAL(5)
|
||||
Give special treatment to <b>owner-</b><i>xxx</i> and <i>xxx</i><b>-request</b>
|
||||
addresses.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="cleanup.8.html">cleanup(8)</a> canonicalize and enqueue mail
|
||||
<a href="postmap.1.html">postmap(1)</a> create mapping table
|
||||
<a href="virtual.5.html">virtual(5)</a> virtual domain mapping
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
|
||||
80
postfix/html/cidr_table.5.html
Normal file
80
postfix/html/cidr_table.5.html
Normal file
@ -0,0 +1,80 @@
|
||||
<html> <head> </head> <body> <pre>
|
||||
CIDR_TABLE(5) CIDR_TABLE(5)
|
||||
|
||||
<b>NAME</b>
|
||||
cidr_table - format of Postfix CIDR tables
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" cidr:/etc/postfix/</b><i>filename</i>
|
||||
|
||||
<b>postmap -q - cidr:/etc/postfix/</b><i>filename</i> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The Postfix mail system uses optional access control
|
||||
tables. These tables are usually in <b>dbm</b> or <b>db</b> format.
|
||||
Alternatively, access control tables can be specified in
|
||||
CIDR form.
|
||||
|
||||
To find out what types of lookup tables your Postfix sys-
|
||||
tem supports use the <b>postconf -m</b> command.
|
||||
|
||||
To test lookup tables, use the <b>postmap</b> command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
<b>TABLE FORMAT</b>
|
||||
The general form of a Postfix CIDR table is:
|
||||
|
||||
<i>network_address</i><b>/</b><i>network_mask result</i>
|
||||
When a search string matches the specified network
|
||||
block, use the corresponding <i>result</i> value.
|
||||
|
||||
<i>network_address result</i>
|
||||
When a search string matches the specified network
|
||||
address, use the corresponding <i>result</i> value.
|
||||
|
||||
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 logical line starts with non-whitespace text. A
|
||||
line that starts with whitespace continues a logi-
|
||||
cal line.
|
||||
|
||||
<b>SEARCH ORDER</b>
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
string.
|
||||
|
||||
<b>EXAMPLE SMTPD ACCESS MAP</b>
|
||||
/etc/postfix/main.cf:
|
||||
smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
|
||||
|
||||
/etc/postfix/client.cidr:
|
||||
# Rule order matters. Put more specific whitelist entries
|
||||
# before more general blacklist entries.
|
||||
192.168.1.1 OK
|
||||
192.168.0.0/16 REJECT
|
||||
|
||||
<b>SEE ALSO</b>
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of regular expression tables
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
The CIDR table lookup code was originally written by:
|
||||
Jozsef Kadlecsik
|
||||
kadlec@blackhole.kfki.hu
|
||||
KFKI Research Institute for Particle and Nuclear Physics
|
||||
POB. 49
|
||||
1525 Budapest, Hungary
|
||||
|
||||
Adopted and adapted by:
|
||||
Wietse Venema
|
||||
IBM T.J. Watson Research
|
||||
P.O. Box 704
|
||||
Yorktown Heights, NY 10598, USA
|
||||
|
||||
CIDR_TABLE(5)
|
||||
</pre> </body> </html>
|
||||
@ -63,15 +63,15 @@ CLEANUP(8) CLEANUP(8)
|
||||
|
||||
<b>BUGS</b>
|
||||
Table-driven rewriting rules make it hard to express <b>if</b>
|
||||
<b>then</b> <b>else</b> and other logical relationships.
|
||||
<b>then else</b> and other logical relationships.
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this program. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>Content</b> <b>filtering</b>
|
||||
<b>Content filtering</b>
|
||||
<b>body</b><i>_</i><b>checks</b>
|
||||
Lookup tables with content filters for message body
|
||||
lines. These filters see physical lines one at a
|
||||
@ -94,7 +94,7 @@ CLEANUP(8) CLEANUP(8)
|
||||
sages. These filters see logical headers one at a
|
||||
time, including headers that span multiple lines.
|
||||
|
||||
<b>MIME</b> <b>Processing</b>
|
||||
<b>MIME Processing</b>
|
||||
<b>disable</b><i>_</i><b>mime</b><i>_</i><b>input</b><i>_</i><b>processing</b>
|
||||
While receiving, give no special treatment to <b>Con-</b>
|
||||
<b>tent-Type:</b> message headers; all text after the ini-
|
||||
@ -153,6 +153,14 @@ CLEANUP(8) CLEANUP(8)
|
||||
recipient address. The BCC address is added when
|
||||
the message enters the system.
|
||||
|
||||
<b>enable</b><i>_</i><b>original</b><i>_</i><b>recipient</b>
|
||||
Enable support for the <b>X-Original-To:</b> message
|
||||
header, which is needed for multi-recipient mail-
|
||||
boxes. When this is enabled, Postfix performs
|
||||
duplicate elimination on (original recipient,
|
||||
rewritten recipient) pairs, instead of looking at
|
||||
the rewritten recipient only.
|
||||
|
||||
<b>hopcount</b><i>_</i><b>limit</b>
|
||||
Limit the number of <b>Received:</b> message headers.
|
||||
|
||||
@ -161,24 +169,16 @@ CLEANUP(8) CLEANUP(8)
|
||||
were specified in (Resent-)To: or (Resent-)Cc: mes-
|
||||
sage headers.
|
||||
|
||||
<b>Address</b> <b>transformations</b>
|
||||
<b>Address transformations</b>
|
||||
<b>empty</b><i>_</i><b>address</b><i>_</i><b>recipient</b>
|
||||
The destination for undeliverable mail from <>.
|
||||
This substitution is done before all other address
|
||||
The destination for undeliverable mail from <>.
|
||||
This substitution is done before all other address
|
||||
rewriting.
|
||||
|
||||
<b>canonical</b><i>_</i><b>maps</b>
|
||||
Address mapping lookup table for sender and recipi-
|
||||
ent addresses in envelopes and headers.
|
||||
|
||||
<b>enable</b><i>_</i><b>original</b><i>_</i><b>recipient</b>
|
||||
Enable support for the X-Original-To message
|
||||
header, which is needed for multi-recipient mail-
|
||||
boxes. When this is enabled, Postfix performs
|
||||
duplicate elimination on (original recipient,
|
||||
rewritten recipient) pairs, instead of looking at
|
||||
the rewritten recipient only.
|
||||
|
||||
<b>recipient</b><i>_</i><b>canonical</b><i>_</i><b>maps</b>
|
||||
Address mapping lookup table for envelope and
|
||||
header recipient addresses.
|
||||
@ -204,7 +204,7 @@ CLEANUP(8) CLEANUP(8)
|
||||
Address mapping lookup table for envelope recipient
|
||||
addresses.
|
||||
|
||||
<b>Resource</b> <b>controls</b>
|
||||
<b>Resource controls</b>
|
||||
<b>duplicate</b><i>_</i><b>filter</b><i>_</i><b>limit</b>
|
||||
Limits the number of envelope recipients that are
|
||||
remembered.
|
||||
@ -231,7 +231,7 @@ CLEANUP(8) CLEANUP(8)
|
||||
Limit the recursion depth of virtual alias expan-
|
||||
sion.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="canonical.5.html">canonical(5)</a> canonical address lookup table format
|
||||
<a href="qmgr.8.html">qmgr(8)</a> queue manager daemon
|
||||
syslogd(8) system logging
|
||||
|
||||
@ -5,9 +5,9 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
pcre_table - format of Postfix PCRE tables
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>pcre:/etc/postfix/</b><i>filename</i>
|
||||
<b>postmap -q "</b><i>string</i><b>" pcre:/etc/postfix/</b><i>filename</i>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>pcre:/etc/postfix/</b><i>filename</i> <<i>inputfile</i>
|
||||
<b>postmap -q - pcre:/etc/postfix/</b><i>filename</i> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The Postfix mail system uses optional tables for address
|
||||
@ -16,16 +16,17 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
fied in Perl Compatible Regular Expression form.
|
||||
|
||||
To find out what types of lookup tables your Postfix sys-
|
||||
tem supports use the <b>postconf</b> <b>-m</b> command.
|
||||
tem supports use the <b>postconf -m</b> command.
|
||||
|
||||
To test lookup tables, use the <b>postmap</b> command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
<b>TABLE FORMAT</b>
|
||||
The general form of a PCRE table is:
|
||||
|
||||
<b>/</b><i>pattern</i><b>/</b><i>flags</i> <i>result</i>
|
||||
<b>/</b><i>pattern</i><b>/</b><i>flags result</i>
|
||||
|
||||
<b>!/</b><i>pattern</i><b>/</b><i>flags</i> <i>result</i>
|
||||
<b>!/</b><i>pattern</i><b>/</b><i>flags result</i>
|
||||
When <i>pattern</i> matches (does not match) a search
|
||||
string, use the corresponding <i>result</i> value.
|
||||
|
||||
@ -39,9 +40,9 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
line that starts with whitespace continues a logi-
|
||||
cal line.
|
||||
|
||||
<b>if</b> <b>/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
<b>if /</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
|
||||
<b>if</b> <b>!/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
<b>if !/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
|
||||
<b>endif</b> Examine the lines between <b>if</b>..<b>endif</b> only if <i>pattern</i>
|
||||
matches (does not match). The <b>if</b>..<b>endif</b> can nest.
|
||||
@ -119,6 +120,11 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
thus reserving these combinations for future expan-
|
||||
sion.
|
||||
|
||||
<b>SEARCH ORDER</b>
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
string.
|
||||
|
||||
Each pattern is applied to the entire lookup key string.
|
||||
Depending on the application, that string is an entire
|
||||
client hostname, an entire client IP address, or an entire
|
||||
@ -127,20 +133,18 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
broken up into their <i>user</i> and <i>domain</i> constituent parts,
|
||||
nor is <i>user+foo</i> broken up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
string.
|
||||
|
||||
<b>TEXT SUBSTITUTION</b>
|
||||
Substitution of substrings from the matched expression
|
||||
into the result string is possible using the conventional
|
||||
perl syntax ($1, $2, etc.). The macros in the result
|
||||
string may need to be written as ${n} or $(n) if they
|
||||
aren't followed by whitespace. Since negated patterns
|
||||
(those preceded by <b>!</b>) return a result when the expression
|
||||
does not match, substitutions are not available for
|
||||
negated patterns.
|
||||
aren't followed by whitespace.
|
||||
|
||||
<b>EXAMPLE</b> <b>SMTPD</b> <b>ACCESS</b> <b>MAP</b>
|
||||
Note: since negated patterns (those preceded by <b>!</b>) return
|
||||
a result when the expression does not match, substitutions
|
||||
are not available for negated patterns.
|
||||
|
||||
<b>EXAMPLE SMTPD ACCESS MAP</b>
|
||||
# Protect your outgoing majordomo exploders
|
||||
/^(?!owner-)(.*)-outgoing@(.*)/ 550 Use ${1}@${2} instead
|
||||
|
||||
@ -154,21 +158,21 @@ PCRE_TABLE(5) PCRE_TABLE(5)
|
||||
550 This user is a funny one. You really don't want to send mail to
|
||||
them as it only makes their head spin.
|
||||
|
||||
<b>EXAMPLE</b> <b>HEADER</b> <b>FILTER</b> <b>MAP</b>
|
||||
<b>EXAMPLE HEADER FILTER MAP</b>
|
||||
/^Subject: make money fast/ REJECT
|
||||
/^To: friend@public\.com/ REJECT
|
||||
|
||||
<b>EXAMPLE</b> <b>BODY</b> <b>FILTER</b> <b>MAP</b>
|
||||
<b>EXAMPLE BODY FILTER MAP</b>
|
||||
# First skip over base 64 encoded text to save CPU cycles.
|
||||
# Requires PCRE version 3.
|
||||
~^[[:alnum:]+/]{60,}$~ OK
|
||||
|
||||
# Put your own body patterns here.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
||||
cidr_table(5) format of CIDR tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
<a href="cidr_table.5.html">cidr_table(5)</a> format of CIDR tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
The PCRE table lookup code was originally written by:
|
||||
|
||||
@ -5,9 +5,9 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
regexp_table - format of Postfix regular expression tables
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>regexp:/etc/postfix/</b><i>filename</i>
|
||||
<b>postmap -q "</b><i>string</i><b>" regexp:/etc/postfix/</b><i>filename</i>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>regexp:/etc/postfix/</b><i>filename</i> <<i>inputfile</i>
|
||||
<b>postmap -q - regexp:/etc/postfix/</b><i>filename</i> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The Postfix mail system uses optional tables for address
|
||||
@ -16,16 +16,17 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
fied in POSIX regular expression form.
|
||||
|
||||
To find out what types of lookup tables your Postfix sys-
|
||||
tem supports use the <b>postconf</b> <b>-m</b> command.
|
||||
tem supports use the <b>postconf -m</b> command.
|
||||
|
||||
To test lookup tables, use the <b>postmap</b> command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
<b>TABLE FORMAT</b>
|
||||
The general form of a Postfix regular expression table is:
|
||||
|
||||
<b>/</b><i>pattern</i><b>/</b><i>flags</i> <i>result</i>
|
||||
<b>/</b><i>pattern</i><b>/</b><i>flags result</i>
|
||||
|
||||
<b>!/</b><i>pattern</i><b>/</b><i>flags</i> <i>result</i>
|
||||
<b>!/</b><i>pattern</i><b>/</b><i>flags result</i>
|
||||
When <i>pattern</i> matches (does not match) a search
|
||||
string, use the corresponding <i>result</i> value.
|
||||
|
||||
@ -39,9 +40,9 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
line that starts with whitespace continues a logi-
|
||||
cal line.
|
||||
|
||||
<b>if</b> <b>/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
<b>if /</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
|
||||
<b>if</b> <b>!/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
<b>if !/</b><i>pattern</i><b>/</b><i>flags</i>
|
||||
|
||||
<b>endif</b> Examine the lines between <b>if</b>..<b>endif</b> only if <i>pattern</i>
|
||||
matches (does not match). The <b>if</b>..<b>endif</b> can nest.
|
||||
@ -61,6 +62,11 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
and `m' (enable multi-line mode, that is, treat newline
|
||||
characters as special).
|
||||
|
||||
<b>TABLE SEARCH ORDER</b>
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
string.
|
||||
|
||||
Each pattern is applied to the entire lookup key string.
|
||||
Depending on the application, that string is an entire
|
||||
client hostname, an entire client IP address, or an entire
|
||||
@ -69,19 +75,17 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
broken up into their <i>user</i> and <i>domain</i> constituent parts,
|
||||
nor is <i>user+foo</i> broken up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
string.
|
||||
|
||||
<b>TEXT SUBSTITUTION</b>
|
||||
Substitution of substrings from the matched expression
|
||||
into the result string is possible using $1, $2, etc.. The
|
||||
macros in the result string may need to be written as ${n}
|
||||
or $(n) if they aren't followed by whitespace. Since
|
||||
negated patterns (those preceded by <b>!</b>) return a result
|
||||
when the expression does not match, substitutions are not
|
||||
available for negated patterns.
|
||||
or $(n) if they aren't followed by whitespace.
|
||||
|
||||
<b>EXAMPLE</b> <b>SMTPD</b> <b>ACCESS</b> <b>MAP</b>
|
||||
Note: since negated patterns (those preceded by <b>!</b>) return
|
||||
a result when the expression does not match, substitutions
|
||||
are not available for negated patterns.
|
||||
|
||||
<b>EXAMPLE SMTPD ACCESS MAP</b>
|
||||
# Disallow sender-specified routing. This is a must if you relay mail
|
||||
# for other domains.
|
||||
/[%!@].*[%!@]/ 550 Sender-specified routing rejected
|
||||
@ -95,21 +99,21 @@ REGEXP_TABLE(5) REGEXP_TABLE(5)
|
||||
/^(.*)-outgoing@(.*)$/ 550 Use ${1}@${2} instead
|
||||
endif
|
||||
|
||||
<b>EXAMPLE</b> <b>HEADER</b> <b>FILTER</b> <b>MAP</b>
|
||||
<b>EXAMPLE HEADER FILTER MAP</b>
|
||||
# These were once common in junk mail.
|
||||
/^Subject: make money fast/ REJECT
|
||||
/^To: friend@public\.com/ REJECT
|
||||
|
||||
<b>EXAMPLE</b> <b>BODY</b> <b>FILTER</b> <b>MAP</b>
|
||||
<b>EXAMPLE BODY FILTER MAP</b>
|
||||
# First skip over base 64 encoded text to save CPU cycles.
|
||||
~^[[:alnum:]+/]{60,}$~ OK
|
||||
|
||||
# Put your own body patterns here.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
cidr_table(5) format of CIDR tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
<a href="cidr_table.5.html">cidr_table(5)</a> format of CIDR tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
The regexp table lookup code was originally written by:
|
||||
|
||||
@ -5,7 +5,7 @@ RELOCATED(5) RELOCATED(5)
|
||||
relocated - format of Postfix relocated table
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>/etc/postfix/relocated</b>
|
||||
<b>postmap /etc/postfix/relocated</b>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The optional <b>relocated</b> table provides the information that
|
||||
@ -16,7 +16,7 @@ RELOCATED(5) RELOCATED(5)
|
||||
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
||||
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
||||
fast searching by the mail system. Execute the command
|
||||
<b>postmap</b> <b>/etc/postfix/relocated</b> in order to rebuild the
|
||||
<b>postmap /etc/postfix/relocated</b> in order to rebuild the
|
||||
indexed file after changing the relocated table.
|
||||
|
||||
When the table is provided via other means such as NIS,
|
||||
@ -25,16 +25,18 @@ RELOCATED(5) RELOCATED(5)
|
||||
|
||||
Alternatively, the table can be provided as a regular-
|
||||
expression map where patterns are given as regular expres-
|
||||
sions. In that case, the lookups are done in a slightly
|
||||
different way as described below.
|
||||
sions, or lookups can be directed to TCP-based server. In
|
||||
that case, the lookups are done in a slightly different
|
||||
way as described below under "REGULAR EXPRESSION TABLES"
|
||||
and "TCP-BASED TABLES".
|
||||
|
||||
Table lookups are case insensitive.
|
||||
|
||||
<b>TABLE</b> <b>FORMAT</b>
|
||||
<b>TABLE FORMAT</b>
|
||||
The format of the table is as follows:
|
||||
|
||||
<b>o</b> An entry has one of the following form:
|
||||
<i>key</i> <i>new_location</i>
|
||||
<i>key new_location</i>
|
||||
Where <i>new_location</i> specifies contact information
|
||||
such as an email address, or perhaps a street
|
||||
address or telephone number.
|
||||
@ -63,39 +65,54 @@ RELOCATED(5) RELOCATED(5)
|
||||
Matches every address in <i>domain</i>. This form has the
|
||||
lowest precedence.
|
||||
|
||||
<b>ADDRESS</b> <b>EXTENSION</b>
|
||||
<b>ADDRESS 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>user+foo</i>, <i>user</i>, and
|
||||
@<i>domain</i>.
|
||||
|
||||
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
|
||||
<b>REGULAR EXPRESSION TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
the table is given in the form of regular expressions. For
|
||||
a description of regular expression lookup table syntax,
|
||||
see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
|
||||
the table is given in the form of regular expressions or
|
||||
when lookups are directed to a TCP-based server. For a
|
||||
description of regular expression lookup table syntax, see
|
||||
<a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>. For a description of the
|
||||
TCP client/server table lookup protocol, see <b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
Each pattern is a regular expression that is applied to
|
||||
Each pattern is a regular expression that is applied to
|
||||
the entire address being looked up. Thus, <i>user@domain</i> mail
|
||||
addresses are not broken up into their <i>user</i> and <i>@domain</i>
|
||||
addresses are not broken up into their <i>user</i> and <i>@domain</i>
|
||||
constituent parts, nor is <i>user+foo</i> broken up into <i>user</i> and
|
||||
<i>foo</i>.
|
||||
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
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 indexed file lookups, with
|
||||
the additional feature that parenthesized substrings from
|
||||
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.
|
||||
<b>TCP-BASED TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
lookups are directed to a TCP-based server. For a descrip-
|
||||
tion of the TCP client/server lookup protocol, see
|
||||
<b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
<i>user@domain</i> mail addresses are not broken up into their
|
||||
<i>user</i> and <i>@domain</i> constituent parts, nor is <i>user+foo</i> broken
|
||||
up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
|
||||
<b>BUGS</b>
|
||||
The table format does not understand quoting conventions.
|
||||
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>relocated</b><i>_</i><b>maps</b>
|
||||
@ -104,24 +121,25 @@ RELOCATED(5) RELOCATED(5)
|
||||
Other parameters of interest:
|
||||
|
||||
<b>inet</b><i>_</i><b>interfaces</b>
|
||||
The network interface addresses that this system
|
||||
The network interface addresses that this system
|
||||
receives mail on. You need to stop and start Post-
|
||||
fix when this parameter changes.
|
||||
|
||||
<b>mydestination</b>
|
||||
List of domains that this mail system considers
|
||||
List of domains that this mail system considers
|
||||
local.
|
||||
|
||||
<b>myorigin</b>
|
||||
The domain that is appended to locally-posted mail.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="postmap.1.html">postmap(1)</a> create lookup table
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
The Secure Mailer license must be distributed with this
|
||||
software.
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
|
||||
@ -22,8 +22,8 @@ SMTPD(8) SMTPD(8)
|
||||
system is not running.
|
||||
|
||||
The SMTP server implements a variety of policies for con-
|
||||
nection requests, and for parameters given to <b>HELO,</b> <b>ETRN,</b>
|
||||
<b>MAIL</b> <b>FROM,</b> <b>VRFY</b> and <b>RCPT</b> <b>TO</b> commands. They are detailed
|
||||
nection requests, and for parameters given to <b>HELO, ETRN,</b>
|
||||
<b>MAIL FROM, VRFY</b> and <b>RCPT TO</b> commands. They are detailed
|
||||
below and in the <b>main.cf</b> configuration file.
|
||||
|
||||
<b>SECURITY</b>
|
||||
@ -49,13 +49,13 @@ SMTPD(8) SMTPD(8)
|
||||
the postmaster is notified of bounces, protocol problems,
|
||||
policy violations, and of other trouble.
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this program. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>Compatibility</b> <b>controls</b>
|
||||
<b>Compatibility controls</b>
|
||||
<b>strict</b><i>_</i><b>rfc821</b><i>_</i><b>envelopes</b>
|
||||
Disallow non-<a href="http://www.faqs.org/rfcs/rfc821.html">RFC 821</a> style addresses in SMTP com-
|
||||
mands. For example, the RFC822-style address forms
|
||||
@ -72,7 +72,7 @@ SMTPD(8) SMTPD(8)
|
||||
checking and without any state change. This list
|
||||
overrides built-in command definitions.
|
||||
|
||||
<b>Content</b> <b>inspection</b> <b>controls</b>
|
||||
<b>Content inspection controls</b>
|
||||
<b>content</b><i>_</i><b>filter</b>
|
||||
The name of a mail delivery transport that filters
|
||||
mail and that either bounces mail or re-injects the
|
||||
@ -80,7 +80,7 @@ SMTPD(8) SMTPD(8)
|
||||
same syntax as the right-hand side of a Postfix
|
||||
transport table.
|
||||
|
||||
<b>Authentication</b> <b>controls</b>
|
||||
<b>Authentication controls</b>
|
||||
<b>enable</b><i>_</i><b>sasl</b><i>_</i><b>authentication</b>
|
||||
Enable per-session authentication as per <a href="http://www.faqs.org/rfcs/rfc2554.html">RFC 2554</a>
|
||||
(SASL). This functionality is available only when
|
||||
@ -114,7 +114,7 @@ SMTPD(8) SMTPD(8)
|
||||
<b>reject</b><i>_</i><b>sender</b><i>_</i><b>login</b><i>_</i><b>mismatch</b> sender anti-spoofing
|
||||
restriction.
|
||||
|
||||
<b>Pass-through</b> <b>proxy</b>
|
||||
<b>Pass-through proxy</b>
|
||||
Optionally, the Postfix SMTP server can be configured to
|
||||
forward all mail to a proxy server, for example a real-
|
||||
time content filter. This proxy server should support the
|
||||
@ -199,7 +199,7 @@ SMTPD(8) SMTPD(8)
|
||||
The characters that Postfix accepts as VERP delim-
|
||||
iter characters.
|
||||
|
||||
<b>Known</b> <b>versus</b> <b>unknown</b> <b>recipients</b>
|
||||
<b>Known versus unknown recipients</b>
|
||||
<b>show</b><i>_</i><b>user</b><i>_</i><b>unknown</b><i>_</i><b>table</b><i>_</i><b>name</b>
|
||||
Whether or not to reveal the table name in the
|
||||
"User unknown" responses. The extra detail makes
|
||||
@ -231,7 +231,7 @@ SMTPD(8) SMTPD(8)
|
||||
while the recipient is not listed in <b>$virtual</b><i>_</i><b>mail-</b>
|
||||
<b>box</b><i>_</i><b>maps</b>.
|
||||
|
||||
<b>Resource</b> <b>controls</b>
|
||||
<b>Resource controls</b>
|
||||
<b>line</b><i>_</i><b>length</b><i>_</i><b>limit</b>
|
||||
Limit the amount of memory in bytes used for the
|
||||
handling of partial input lines.
|
||||
@ -270,7 +270,7 @@ SMTPD(8) SMTPD(8)
|
||||
SMTP session before it is penalized with tarpit
|
||||
delays.
|
||||
|
||||
<b>UCE</b> <b>control</b> <b>restrictions</b>
|
||||
<b>UCE control restrictions</b>
|
||||
<b>parent</b><i>_</i><b>domain</b><i>_</i><b>matches</b><i>_</i><b>subdomains</b>
|
||||
List of Postfix features that use <i>domain.tld</i> pat-
|
||||
terns to match <i>sub.domain.tld</i> (as opposed to
|
||||
@ -294,7 +294,7 @@ SMTPD(8) SMTPD(8)
|
||||
|
||||
<b>smtpd</b><i>_</i><b>recipient</b><i>_</i><b>restrictions</b>
|
||||
Restrict what recipient addresses are allowed in
|
||||
<b>RCPT</b> <b>TO</b> commands.
|
||||
<b>RCPT TO</b> commands.
|
||||
|
||||
<b>smtpd</b><i>_</i><b>etrn</b><i>_</i><b>restrictions</b>
|
||||
Restrict what domain names can be used in <b>ETRN</b> com-
|
||||
@ -337,7 +337,7 @@ SMTPD(8) SMTPD(8)
|
||||
mail to. The domains are routed to the delivery
|
||||
agent specified with the <b>relay</b><i>_</i><b>transport</b> setting.
|
||||
|
||||
<b>Sender/recipient</b> <b>address</b> <b>verification</b>
|
||||
<b>Sender/recipient address verification</b>
|
||||
Address verification is implemented by sending probe email
|
||||
messages that are not actually delivered, and is enabled
|
||||
via the reject_unverified_{sender,recipient} access
|
||||
@ -347,49 +347,50 @@ SMTPD(8) SMTPD(8)
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>poll</b><i>_</i><b>count</b>
|
||||
How many times to query the address verification
|
||||
service for completion of an address verification
|
||||
request. Specify 0 to implement a simple form of
|
||||
greylisting.
|
||||
request. Specify 1 to implement a simple form of
|
||||
greylisting, that is, always defer the request for
|
||||
a new sender or recipient address.
|
||||
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>poll</b><i>_</i><b>delay</b>
|
||||
Time to wait after querying the address verifica-
|
||||
Time to wait after querying the address verifica-
|
||||
tion service for completion of an address verifica-
|
||||
tion request.
|
||||
|
||||
<b>UCE</b> <b>control</b> <b>responses</b>
|
||||
<b>UCE control responses</b>
|
||||
<b>access</b><i>_</i><b>map</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a client violates an access
|
||||
Response code when a client violates an access
|
||||
database restriction.
|
||||
|
||||
<b>default</b><i>_</i><b>rbl</b><i>_</i><b>reply</b>
|
||||
Default template reply when a request is RBL black-
|
||||
listed. This template is used by the <b>reject</b><i>_</i><b>rbl</b><i>_</i><b>*</b>
|
||||
and <b>reject</b><i>_</i><b>rhsbl</b><i>_</i><b>*</b> restrictions. See also:
|
||||
listed. This template is used by the <b>reject</b><i>_</i><b>rbl</b><i>_</i><b>*</b>
|
||||
and <b>reject</b><i>_</i><b>rhsbl</b><i>_</i><b>*</b> restrictions. See also:
|
||||
<b>rbl</b><i>_</i><b>reply</b><i>_</i><b>maps</b> and <b>smtpd</b><i>_</i><b>expansion</b><i>_</i><b>filter</b>.
|
||||
|
||||
<b>defer</b><i>_</i><b>code</b>
|
||||
Response code when a client request is rejected by
|
||||
Response code when a client request is rejected by
|
||||
the <b>defer</b> restriction.
|
||||
|
||||
<b>invalid</b><i>_</i><b>hostname</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a client violates the
|
||||
Response code when a client violates the
|
||||
<b>reject</b><i>_</i><b>invalid</b><i>_</i><b>hostname</b> restriction.
|
||||
|
||||
<b>maps</b><i>_</i><b>rbl</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a request is RBL blacklisted.
|
||||
|
||||
<b>multi</b><i>_</i><b>recipient</b><i>_</i><b>bounce</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a multi-recipient bounce is
|
||||
Response code when a multi-recipient bounce is
|
||||
blocked.
|
||||
|
||||
<b>rbl</b><i>_</i><b>reply</b><i>_</i><b>maps</b>
|
||||
Table with template responses for RBL blacklisted
|
||||
requests, indexed by RBL domain name. These tem-
|
||||
Table with template responses for RBL blacklisted
|
||||
requests, indexed by RBL domain name. These tem-
|
||||
plates are used by the <b>reject</b><i>_</i><b>rbl</b><i>_</i><b>*</b> and
|
||||
<b>reject</b><i>_</i><b>rhsbl</b><i>_</i><b>*</b> restrictions. See also:
|
||||
<b>reject</b><i>_</i><b>rhsbl</b><i>_</i><b>*</b> restrictions. See also:
|
||||
<b>default</b><i>_</i><b>rbl</b><i>_</i><b>reply</b> and <b>smtpd</b><i>_</i><b>expansion</b><i>_</i><b>filter</b>.
|
||||
|
||||
<b>reject</b><i>_</i><b>code</b>
|
||||
Response code when the client matches a <b>reject</b>
|
||||
Response code when the client matches a <b>reject</b>
|
||||
restriction.
|
||||
|
||||
<b>relay</b><i>_</i><b>domains</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
@ -397,7 +398,7 @@ SMTPD(8) SMTPD(8)
|
||||
mail relay policy.
|
||||
|
||||
<b>unknown</b><i>_</i><b>address</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a client violates the
|
||||
Response code when a client violates the
|
||||
<b>reject</b><i>_</i><b>unknown</b><i>_</i><b>address</b> restriction.
|
||||
|
||||
<b>unknown</b><i>_</i><b>client</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
@ -406,18 +407,18 @@ SMTPD(8) SMTPD(8)
|
||||
tion.
|
||||
|
||||
<b>unknown</b><i>_</i><b>hostname</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a client violates the
|
||||
Response code when a client violates the
|
||||
<b>reject</b><i>_</i><b>unknown</b><i>_</i><b>hostname</b> restriction.
|
||||
|
||||
<b>unverified</b><i>_</i><b>sender</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a sender address is known to be
|
||||
Response code when a sender address is known to be
|
||||
undeliverable.
|
||||
|
||||
<b>unverified</b><i>_</i><b>recipient</b><i>_</i><b>reject</b><i>_</i><b>code</b>
|
||||
Response code when a recipient address is known to
|
||||
Response code when a recipient address is known to
|
||||
be undeliverable.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="cleanup.8.html">cleanup(8)</a> message canonicalization
|
||||
<a href="master.8.html">master(8)</a> process manager
|
||||
syslogd(8) system logging
|
||||
@ -425,7 +426,7 @@ SMTPD(8) SMTPD(8)
|
||||
<a href="verify.8.html">verify(8)</a> address verification service
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
The Secure Mailer license must be distributed with this
|
||||
software.
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
|
||||
100
postfix/html/tcp_table.5.html
Normal file
100
postfix/html/tcp_table.5.html
Normal file
@ -0,0 +1,100 @@
|
||||
<html> <head> </head> <body> <pre>
|
||||
TCP_TABLE(5) TCP_TABLE(5)
|
||||
|
||||
<b>NAME</b>
|
||||
tcp_table - Postfix client/server table lookup protocol
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" tcp:</b><i>host:port</i>
|
||||
|
||||
<b>postmap -q - tcp:</b><i>host:port</i> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The Postfix mail system uses optional tables for address
|
||||
rewriting or mail routing. These tables are usually in <b>dbm</b>
|
||||
or <b>db</b> format. Alternatively, table lookups can be directed
|
||||
to a TCP server.
|
||||
|
||||
To find out what types of lookup tables your Postfix sys-
|
||||
tem supports use the <b>postconf -m</b> command.
|
||||
|
||||
To test lookup tables, use the <b>postmap</b> command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
<b>PROTOCOL DESCRIPTION</b>
|
||||
The TCP map class implements a very simple protocol: the
|
||||
client sends a request, and the server sends one reply.
|
||||
Requests and replies are sent as one line of ASCII text,
|
||||
terminated by the ASCII newline character. Request and
|
||||
reply parameters (see below) are separated by whitespace.
|
||||
|
||||
<b>REQUEST FORMAT</b>
|
||||
Each request specifies a command, a lookup key, and possi-
|
||||
bly a lookup result.
|
||||
|
||||
<b>get</b> SPACE <i>key</i> NEWLINE
|
||||
Look up data under the specified key.
|
||||
|
||||
<b>put</b> SPACE <i>key</i> SPACE <i>value</i> NEWLINE
|
||||
This request is currently not implemented.
|
||||
|
||||
<b>REPLY FORMAT</b>
|
||||
Each reply specifies a status code and text. Replies must
|
||||
be no longer than 4096 characters including the newline
|
||||
terminator.
|
||||
|
||||
<b>500</b> SPACE <i>text</i> NEWLINE
|
||||
In case of a lookup request, the requested data
|
||||
does not exist. In case of an update request, the
|
||||
request was rejected. The text describes the
|
||||
nature of the problem.
|
||||
|
||||
<b>400</b> SPACE <i>text</i> NEWLINE
|
||||
This indicates an error condition. The text
|
||||
describes the nature of the problem. The client
|
||||
should retry the request later.
|
||||
|
||||
<b>200</b> SPACE <i>text</i> NEWLINE
|
||||
The request was successful. In the case of a lookup
|
||||
request, the text contains an encoded version of
|
||||
the requested data.
|
||||
|
||||
<b>ENCODING</b>
|
||||
In request and reply parameters, the character %, each
|
||||
non-printing character, and each whitespace character must
|
||||
be replaced by %XX, where XX is the corresponding ASCII
|
||||
hexadecimal character value. The hexadecimal codes can be
|
||||
specified in any case (upper, lower, mixed).
|
||||
|
||||
The Postfix client always encodes a request. The server
|
||||
may omit the encoding as long as the reply is guaranteed
|
||||
to not contain the % or NEWLINE character.
|
||||
|
||||
<b>SECURITY</b>
|
||||
Do not use TCP lookup tables for security critical purposes.
|
||||
The client-server connection is not protected and the server
|
||||
is not authenticated.
|
||||
|
||||
<b>SEE ALSO</b>
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of regular expression tables
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="cidr_table.5.html">cidr_table(5)</a> format of CIDR tables
|
||||
|
||||
<b>BUGS</b>
|
||||
Only the lookup method is currently implemented.
|
||||
|
||||
The client does not hang up when the connection is idle
|
||||
for a long time.
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
software.
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
Wietse Venema
|
||||
IBM T.J. Watson Research
|
||||
P.O. Box 704
|
||||
Yorktown Heights, NY 10598, USA
|
||||
|
||||
TCP_TABLE(5)
|
||||
</pre> </body> </html>
|
||||
@ -5,11 +5,11 @@ TRANSPORT(5) TRANSPORT(5)
|
||||
transport - format of Postfix transport table
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>/etc/postfix/transport</b>
|
||||
<b>postmap /etc/postfix/transport</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>/etc/postfix/transport</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" /etc/postfix/transport</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>/etc/postfix/transport</b> <<i>inputfile</i>
|
||||
<b>postmap -q - /etc/postfix/transport</b> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The optional <b>transport</b> table specifies a mapping from
|
||||
@ -40,7 +40,7 @@ TRANSPORT(5) TRANSPORT(5)
|
||||
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
||||
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
||||
fast searching by the mail system. Execute the command
|
||||
<b>postmap</b> <b>/etc/postfix/transport</b> in order to rebuild the
|
||||
<b>postmap /etc/postfix/transport</b> in order to rebuild the
|
||||
indexed file after changing the transport table.
|
||||
|
||||
When the table is provided via other means such as NIS,
|
||||
@ -49,192 +49,208 @@ TRANSPORT(5) TRANSPORT(5)
|
||||
|
||||
Alternatively, the table can be provided as a regular-
|
||||
expression map where patterns are given as regular expres-
|
||||
sions. In that case, the lookups are done in a slightly
|
||||
different way as described in section "REGULAR EXPRESSION
|
||||
TABLES".
|
||||
sions, or lookups can be directed to TCP-based server. In
|
||||
that case, the lookups are done in a slightly different
|
||||
way as described below under "REGULAR EXPRESSION TABLES"
|
||||
and "TCP-BASED TABLES".
|
||||
|
||||
<b>TABLE</b> <b>FORMAT</b>
|
||||
<b>TABLE FORMAT</b>
|
||||
The format of the transport table is as follows:
|
||||
|
||||
<i>pattern</i> <i>result</i>
|
||||
<i>pattern result</i>
|
||||
When <i>pattern</i> matches the recipient address or
|
||||
domain, use the corresponding <i>result</i>.
|
||||
|
||||
blank lines and comments
|
||||
Empty lines and whitespace-only lines are ignored,
|
||||
as are lines whose first non-whitespace character
|
||||
Empty lines and whitespace-only lines are ignored,
|
||||
as are lines whose first non-whitespace character
|
||||
is a `#'.
|
||||
|
||||
multi-line text
|
||||
A logical line starts with non-whitespace text. A
|
||||
line that starts with whitespace continues a logi-
|
||||
A logical line starts with non-whitespace text. A
|
||||
line that starts with whitespace continues a logi-
|
||||
cal line.
|
||||
|
||||
The <i>pattern</i> specifies an email address, a domain name, or
|
||||
a domain name hierarchy, as described in section "TABLE
|
||||
The <i>pattern</i> specifies an email address, a domain name, or
|
||||
a domain name hierarchy, as described in section "TABLE
|
||||
LOOKUP".
|
||||
|
||||
The <i>result</i> is of the form <i>transport</i><b>:</b><i>nexthop</i>. The <i>trans-</i>
|
||||
<i>port</i> field specifies a mail delivery transport such as
|
||||
<b>smtp</b> or <b>local</b>. The <i>nexthop</i> field specifies where and how
|
||||
The <i>result</i> is of the form <i>transport</i><b>:</b><i>nexthop</i>. The <i>trans-</i>
|
||||
<i>port</i> field specifies a mail delivery transport such as
|
||||
<b>smtp</b> or <b>local</b>. The <i>nexthop</i> field specifies where and how
|
||||
to deliver mail. More details are given in section "RESULT
|
||||
FORMAT".
|
||||
|
||||
<b>TABLE</b> <b>LOOKUP</b>
|
||||
<b>TABLE LOOKUP</b>
|
||||
With lookups from indexed files such as DB or DBM, or from
|
||||
networked tables such as NIS, LDAP or SQL, patterns are
|
||||
networked tables such as NIS, LDAP or SQL, patterns are
|
||||
tried in the order as listed below:
|
||||
|
||||
<i>user+extension@domain</i> <i>transport</i>:<i>nexthop</i>
|
||||
<i>user+extension@domain transport</i>:<i>nexthop</i>
|
||||
Mail for <i>user+extension@domain</i> is delivered through
|
||||
<i>transport</i> to <i>nexthop</i>.
|
||||
|
||||
<i>user@domain</i> <i>transport</i>:<i>nexthop</i>
|
||||
<i>user@domain transport</i>:<i>nexthop</i>
|
||||
Mail for <i>user@domain</i> is delivered through <i>transport</i>
|
||||
to <i>nexthop</i>.
|
||||
|
||||
<i>domain</i> <i>transport</i>:<i>nexthop</i>
|
||||
Mail for <i>domain</i> is delivered through <i>transport</i> to
|
||||
<i>domain transport</i>:<i>nexthop</i>
|
||||
Mail for <i>domain</i> is delivered through <i>transport</i> to
|
||||
<i>nexthop</i>.
|
||||
|
||||
<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>. This applies only
|
||||
<i>.domain transport</i>:<i>nexthop</i>
|
||||
Mail for any subdomain of <i>domain</i> is delivered
|
||||
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
|
||||
ting. Otherwise, a domain name matches itself and
|
||||
its subdomains.
|
||||
|
||||
Note 1: the special pattern <b>*</b> represents any address (i.e.
|
||||
it functions as the wild-card pattern).
|
||||
|
||||
Note 2: the null recipient address is looked up as
|
||||
Note 2: the null recipient address is looked up as
|
||||
<b>$empty</b><i>_</i><b>address</b><i>_</i><b>recipient</b>@<b>$myhostname</b> (default: mailer-dae-
|
||||
mon@hostname).
|
||||
|
||||
<b>RESULT</b> <b>FORMAT</b>
|
||||
The transport field specifies the name of a mail delivery
|
||||
<b>RESULT FORMAT</b>
|
||||
The transport field specifies the name of a mail delivery
|
||||
transport (the first name of a mail delivery service entry
|
||||
in the Postfix <b>master.cf</b> file).
|
||||
|
||||
The interpretation of the nexthop field is transport
|
||||
The interpretation of the nexthop field is transport
|
||||
dependent. In the case of SMTP, specify <i>host</i>:<i>service</i> for a
|
||||
non-default server port, and use [<i>host</i>] or [<i>host</i>]:<i>port</i> in
|
||||
order to disable MX (mail exchanger) DNS lookups. The []
|
||||
non-default server port, and use [<i>host</i>] or [<i>host</i>]:<i>port</i> in
|
||||
order to disable MX (mail exchanger) DNS lookups. The []
|
||||
form is required when you specify an IP address instead of
|
||||
a hostname.
|
||||
|
||||
A null <i>transport</i> and null <i>nexthop</i> result means "do not
|
||||
change": use the delivery transport and nexthop informa-
|
||||
tion that would be used when the entire transport table
|
||||
A null <i>transport</i> and null <i>nexthop</i> result means "do not
|
||||
change": use the delivery transport and nexthop informa-
|
||||
tion that would be used when the entire transport table
|
||||
did not exist.
|
||||
|
||||
A non-null <i>transport</i> field with a null <i>nexthop</i> field
|
||||
A non-null <i>transport</i> field with a null <i>nexthop</i> field
|
||||
resets the nexthop information to the recipient domain.
|
||||
|
||||
A null <i>transport</i> field with non-null <i>nexthop</i> field does
|
||||
A null <i>transport</i> field with non-null <i>nexthop</i> field does
|
||||
not modify the transport information.
|
||||
|
||||
<b>EXAMPLES</b>
|
||||
In order to deliver internal mail directly, while using a
|
||||
mail relay for all other mail, specify a null entry for
|
||||
internal destinations (do not change the delivery trans-
|
||||
port or the nexthop information) and specify a wildcard
|
||||
In order to deliver internal mail directly, while using a
|
||||
mail relay for all other mail, specify a null entry for
|
||||
internal destinations (do not change the delivery trans-
|
||||
port or the nexthop information) and specify a wildcard
|
||||
for all other destinations.
|
||||
|
||||
<b>my.domain</b> <b>:</b>
|
||||
<b>.my.domain</b> <b>:</b>
|
||||
<b>*</b> <b>smtp:outbound-relay.my.domain</b>
|
||||
<b>my.domain :</b>
|
||||
<b>.my.domain :</b>
|
||||
<b>* smtp:outbound-relay.my.domain</b>
|
||||
|
||||
In order to send mail for <b>foo.org</b> and its subdomains via
|
||||
In order to send mail for <b>foo.org</b> and its subdomains via
|
||||
the <b>uucp</b> transport to the UUCP host named <b>foo</b>:
|
||||
|
||||
<b>foo.org</b> <b>uucp:foo</b>
|
||||
<b>.foo.org</b> <b>uucp:foo</b>
|
||||
<b>foo.org uucp:foo</b>
|
||||
<b>.foo.org uucp:foo</b>
|
||||
|
||||
When no nexthop host name is specified, the destination
|
||||
domain name is used instead. For example, the following
|
||||
directs mail for <i>user</i>@<b>foo.org</b> via the <b>slow</b> transport to a
|
||||
mail exchanger for <b>foo.org</b>. The <b>slow</b> transport could be
|
||||
something that runs at most one delivery process at a
|
||||
When no nexthop host name is specified, the destination
|
||||
domain name is used instead. For example, the following
|
||||
directs mail for <i>user</i>@<b>foo.org</b> via the <b>slow</b> transport to a
|
||||
mail exchanger for <b>foo.org</b>. The <b>slow</b> transport could be
|
||||
something that runs at most one delivery process at a
|
||||
time:
|
||||
|
||||
<b>foo.org</b> <b>slow:</b>
|
||||
<b>foo.org slow:</b>
|
||||
|
||||
When no transport is specified, Postfix uses the transport
|
||||
that matches the address domain class (see TRANSPORT FIELD
|
||||
discussion above). The following sends all mail for
|
||||
discussion above). The following sends all mail for
|
||||
<b>foo.org</b> and its subdomains to host <b>gateway.foo.org</b>:
|
||||
|
||||
<b>foo.org</b> <b>:[gateway.foo.org]</b>
|
||||
<b>.foo.org</b> <b>:[gateway.foo.org]</b>
|
||||
<b>foo.org :[gateway.foo.org]</b>
|
||||
<b>.foo.org :[gateway.foo.org]</b>
|
||||
|
||||
In the above example, the [] are used to suppress MX
|
||||
lookups. The result would likely point to your local
|
||||
In the above example, the [] are used to suppress MX
|
||||
lookups. The result would likely point to your local
|
||||
machine.
|
||||
|
||||
In the case of delivery via SMTP, one may specify <i>host-</i>
|
||||
In the case of delivery via SMTP, one may specify <i>host-</i>
|
||||
<i>name</i>:<i>service</i> instead of just a host:
|
||||
|
||||
<b>foo.org</b> <b>smtp:bar.org:2025</b>
|
||||
<b>foo.org smtp:bar.org:2025</b>
|
||||
|
||||
This directs mail for <i>user</i>@<b>foo.org</b> to host <b>bar.org</b> port
|
||||
<b>2025</b>. Instead of a numerical port a symbolic name may be
|
||||
used. Specify [] around the hostname in order to disable
|
||||
This directs mail for <i>user</i>@<b>foo.org</b> to host <b>bar.org</b> port
|
||||
<b>2025</b>. Instead of a numerical port a symbolic name may be
|
||||
used. Specify [] around the hostname in order to disable
|
||||
MX lookups.
|
||||
|
||||
The error mailer can be used to bounce mail:
|
||||
|
||||
<b>.foo.org</b> <b>error:mail</b> <b>for</b> <b>*.foo.org</b> <b>is</b> <b>not</b> <b>deliv-</b>
|
||||
<b>.foo.org error:mail for *.foo.org is not deliv-</b>
|
||||
<b>erable</b>
|
||||
|
||||
This causes all mail for <i>user</i>@<i>anything</i><b>.foo.org</b> to be
|
||||
This causes all mail for <i>user</i>@<i>anything</i><b>.foo.org</b> to be
|
||||
bounced.
|
||||
|
||||
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
<b>REGULAR EXPRESSION TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
the table is given in the form of regular expressions. For
|
||||
a description of regular expression lookup table syntax,
|
||||
a description of regular expression lookup table syntax,
|
||||
see <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
|
||||
|
||||
Each pattern is a regular expression that is applied to
|
||||
the entire domain being looked up. Thus, <i>some.domain.hier-</i>
|
||||
<i>archy</i> is not broken up into parent domains.
|
||||
Each pattern is a regular expression that is applied to
|
||||
the entire address being looked up. Thus,
|
||||
<i>some.domain.hierarchy</i> is not looked up up via its parent
|
||||
domains, nor is <i>user+foo@domain</i> looked up as <i>user@domain</i>.
|
||||
|
||||
Patterns are applied in the order as specified in the
|
||||
table, until a pattern is found that matches the search
|
||||
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 indexed file lookups, with
|
||||
the additional feature that parenthesized substrings from
|
||||
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
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
<b>TCP-BASED TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
lookups are directed to a TCP-based server. For a descrip-
|
||||
tion of the TCP client/server lookup protocol, see
|
||||
<b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
Each lookup operation uses the entire recipient address
|
||||
once. Thus, <i>some.domain.hierarchy</i> is not looked up via
|
||||
its parent domains, nor is <i>user+foo@domain</i> looked up as
|
||||
<i>user@domain</i>.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>empty</b><i>_</i><b>address</b><i>_</i><b>recipient</b>
|
||||
The address that is looked up instead of the null
|
||||
The address that is looked up instead of the null
|
||||
sender address.
|
||||
|
||||
<b>parent</b><i>_</i><b>domain</b><i>_</i><b>matches</b><i>_</i><b>subdomains</b>
|
||||
List of Postfix features that use <i>domain.tld</i> pat-
|
||||
terns to match <i>sub.domain.tld</i> (as opposed to
|
||||
List of Postfix features that use <i>domain.tld</i> pat-
|
||||
terns to match <i>sub.domain.tld</i> (as opposed to
|
||||
requiring <i>.domain.tld</i> patterns).
|
||||
|
||||
<b>transport</b><i>_</i><b>maps</b>
|
||||
List of transport lookup tables.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="postmap.1.html">postmap(1)</a> create mapping table
|
||||
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> rewrite and resolve addresses
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
The Secure Mailer license must be distributed with this
|
||||
software.
|
||||
|
||||
<b>AUTHOR(S)</b>
|
||||
|
||||
@ -29,13 +29,13 @@ VERIFY(8) VERIFY(8)
|
||||
|
||||
This server implements the following requests:
|
||||
|
||||
<b>VRFY</b><i>_</i><b>ADDR</b><i>_</i><b>UPDATE</b> <i>address</i> <i>status</i> <i>text</i>
|
||||
<b>VRFY</b><i>_</i><b>ADDR</b><i>_</i><b>UPDATE</b> <i>address status text</i>
|
||||
Update the status of the specified address.
|
||||
|
||||
<b>VRFY</b><i>_</i><b>ADDR</b><i>_</i><b>QUERY</b> <i>address</i>
|
||||
Look up the <i>status</i>, <i>last</i> <i>update</i> <i>time</i> and <i>text</i> of
|
||||
the specified address. If the status is unknown, a
|
||||
probe is sent and a default status is returned.
|
||||
Look up the <i>status</i> and <i>text</i> of the specified
|
||||
address. If the status is unknown, a probe is sent
|
||||
and a default status is returned.
|
||||
|
||||
The server reply status is one of:
|
||||
|
||||
@ -84,26 +84,26 @@ VERIFY(8) VERIFY(8)
|
||||
world comes to an end and human intervention is needed.
|
||||
This violates a basic Postfix principle.
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
See the Postfix <b>main.cf</b> file for syntax details and for
|
||||
default values. Use the <b>postfix</b> <b>reload</b> command after a
|
||||
default values. Use the <b>postfix reload</b> command after a
|
||||
configuration change.
|
||||
|
||||
<b>Cache</b> <b>control</b>
|
||||
<b>Cache control</b>
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>map</b>
|
||||
Optional table for persistent recipient status
|
||||
storage. The file is opened before the process
|
||||
enters a chroot jail and before it drops root priv-
|
||||
ileges. By default, the information is kept in
|
||||
volatile memory, and is lost after <b>postfix</b> <b>reload</b>
|
||||
or <b>postfix</b> <b>stop</b>.
|
||||
volatile memory, and is lost after <b>postfix reload</b>
|
||||
or <b>postfix stop</b>.
|
||||
|
||||
To recover from a corrupted address verification
|
||||
database, delete the file and do <b>postfix</b> <b>reload</b>.
|
||||
database, delete the file and do <b>postfix reload</b>.
|
||||
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>sender</b>
|
||||
The sender address to use for probe messages. Spec-
|
||||
ify an empty value (<b>address</b><i>_</i><b>verify</b><i>_</i><b>sender</b> <b>=</b>) or <>
|
||||
ify an empty value (<b>address</b><i>_</i><b>verify</b><i>_</i><b>sender =</b>) or <>
|
||||
if you want to use the null sender address.
|
||||
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>positive</b><i>_</i><b>expire</b><i>_</i><b>time</b>
|
||||
@ -132,7 +132,7 @@ VERIFY(8) VERIFY(8)
|
||||
probe is sent to verify that a known to be bad
|
||||
address is still bad.
|
||||
|
||||
<b>Probe</b> <b>message</b> <b>routing</b>
|
||||
<b>Probe message routing</b>
|
||||
By default, probe messages are delivered via the same
|
||||
route as regular messages. The following parameters can
|
||||
be used to override specific message routing mechanisms.
|
||||
@ -155,7 +155,7 @@ VERIFY(8) VERIFY(8)
|
||||
<b>address</b><i>_</i><b>verify</b><i>_</i><b>default</b><i>_</i><b>transport</b>
|
||||
Overrides the <b>default</b><i>_</i><b>transport</b> setting.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> address rewriting and resolving
|
||||
|
||||
<b>LICENSE</b>
|
||||
|
||||
@ -5,11 +5,11 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
virtual - format of Postfix virtual alias table
|
||||
|
||||
<b>SYNOPSIS</b>
|
||||
<b>postmap</b> <b>/etc/postfix/virtual</b>
|
||||
<b>postmap /etc/postfix/virtual</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>"</b><i>string</i><b>"</b> <b>/etc/postfix/virtual</b>
|
||||
<b>postmap -q "</b><i>string</i><b>" /etc/postfix/virtual</b>
|
||||
|
||||
<b>postmap</b> <b>-q</b> <b>-</b> <b>/etc/postfix/virtual</b> <<i>inputfile</i>
|
||||
<b>postmap -q - /etc/postfix/virtual</b> <<i>inputfile</i>
|
||||
|
||||
<b>DESCRIPTION</b>
|
||||
The optional <b>virtual</b> alias table specifies address alias-
|
||||
@ -41,7 +41,7 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
file that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
||||
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
||||
fast searching by the mail system. Execute the command
|
||||
<b>postmap</b> <b>/etc/postfix/virtual</b> in order to rebuild the
|
||||
<b>postmap /etc/postfix/virtual</b> in order to rebuild the
|
||||
indexed file after changing the text file.
|
||||
|
||||
When the table is provided via other means such as NIS,
|
||||
@ -50,14 +50,16 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
|
||||
Alternatively, the table can be provided as a regular-
|
||||
expression map where patterns are given as regular expres-
|
||||
sions. In that case, the lookups are done in a slightly
|
||||
different way as described below.
|
||||
sions, or lookups can be directed to TCP-based server. In
|
||||
that case, the lookups are done in a slightly different
|
||||
way as described below under "REGULAR EXPRESSION TABLES"
|
||||
and "TCP-BASED TABLES".
|
||||
|
||||
<b>TABLE</b> <b>FORMAT</b>
|
||||
<b>TABLE FORMAT</b>
|
||||
The format of the virtual table is as follows, mappings
|
||||
being tried in the order as listed in this manual page:
|
||||
|
||||
<i>pattern</i> <i>result</i>
|
||||
<i>pattern result</i>
|
||||
When <i>pattern</i> matches a mail address, replace it by
|
||||
the corresponding <i>result</i>.
|
||||
|
||||
@ -75,11 +77,11 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
networked tables such as NIS, LDAP or SQL, patterns are
|
||||
tried in the order as listed below:
|
||||
|
||||
<i>user</i>@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
|
||||
<i>user</i>@<i>domain address, address, ...</i>
|
||||
Mail for <i>user</i>@<i>domain</i> is redirected to <i>address</i>.
|
||||
This form has the highest precedence.
|
||||
|
||||
<i>user</i> <i>address,</i> <i>address,</i> <i>...</i>
|
||||
<i>user address, address, ...</i>
|
||||
Mail for <i>user</i>@<i>site</i> is redirected to <i>address</i> when
|
||||
<i>site</i> is equal to $<b>myorigin</b>, when <i>site</i> is listed in
|
||||
$mydestination, or when it is listed in
|
||||
@ -90,7 +92,7 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
that <b>virtual</b> mapping can be applied to non-local
|
||||
addresses.
|
||||
|
||||
@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
|
||||
@<i>domain address, address, ...</i>
|
||||
Mail for any user in <i>domain</i> is redirected to
|
||||
<i>address</i>. This form has the lowest precedence.
|
||||
|
||||
@ -98,14 +100,14 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
<i>domain</i>, the result is the same user in <i>otherdomain</i>. This
|
||||
works for the first address in the expansion only.
|
||||
|
||||
<b>ADDRESS</b> <b>EXTENSION</b>
|
||||
<b>ADDRESS 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>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>VIRTUAL</b> <b>ALIAS</b> <b>DOMAINS</b>
|
||||
<b>VIRTUAL ALIAS DOMAINS</b>
|
||||
Besides virtual aliases, the virtual alias table can also
|
||||
be used to implement virtual alias domains. With a virtual
|
||||
alias domain, all recipient addresses are aliased to
|
||||
@ -128,19 +130,19 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
virtual_alias_maps = hash:/etc/postfix/virtual
|
||||
|
||||
Note: some systems use <b>dbm</b> databases instead of <b>hash</b>.
|
||||
See the output from <b>postconf</b> <b>-m</b> for available database
|
||||
See the output from <b>postconf -m</b> for available database
|
||||
types.
|
||||
|
||||
/etc/postfix/virtual:
|
||||
<i>virtual-alias.domain</i> <i>anything</i> (right-hand content does not matter)
|
||||
<i>postmaster@virtual-alias.domain</i> <i>postmaster</i>
|
||||
<i>user1@virtual-alias.domain</i> <i>address1</i>
|
||||
<i>user2@virtual-alias.domain</i> <i>address2,</i> <i>address3</i>
|
||||
<i>virtual-alias.domain anything</i> (right-hand content does not matter)
|
||||
<i>postmaster@virtual-alias.domain postmaster</i>
|
||||
<i>user1@virtual-alias.domain address1</i>
|
||||
<i>user2@virtual-alias.domain address2, address3</i>
|
||||
|
||||
The <i>virtual-alias.domain</i> <i>anything</i> entry is required for a
|
||||
virtual alias domain. <b>Without</b> <b>this</b> <b>entry,</b> <b>mail</b> <b>is</b> <b>rejected</b>
|
||||
<b>with</b> <b>"relay</b> <b>access</b> <b>denied",</b> <b>or</b> <b>bounces</b> <b>with</b> <b>"mail</b> <b>loops</b>
|
||||
<b>back</b> <b>to</b> <b>myself".</b>
|
||||
The <i>virtual-alias.domain anything</i> entry is required for a
|
||||
virtual alias domain. <b>Without this entry, mail is rejected</b>
|
||||
<b>with "relay access denied", or bounces with "mail loops</b>
|
||||
<b>back to myself".</b>
|
||||
|
||||
Do not specify virtual alias domain names in the <b>main.cf</b>
|
||||
<b>mydestination</b> or <b>relay</b><i>_</i><b>domains</b> configuration parameters.
|
||||
@ -152,11 +154,11 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
|
||||
Instead of specifying the virtual alias domain name via
|
||||
the <b>virtual</b><i>_</i><b>alias</b><i>_</i><b>maps</b> table, you may also specify it via
|
||||
the <b>main.cf</b> <b>virtual</b><i>_</i><b>alias</b><i>_</i><b>domains</b> configuration parameter.
|
||||
the <b>main.cf virtual</b><i>_</i><b>alias</b><i>_</i><b>domains</b> configuration parameter.
|
||||
This latter parameter uses the same syntax as the <b>main.cf</b>
|
||||
<b>mydestination</b> configuration parameter.
|
||||
|
||||
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
|
||||
<b>REGULAR EXPRESSION TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
the table is given in the form of regular expressions. For
|
||||
a description of regular expression lookup table syntax,
|
||||
@ -176,13 +178,26 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
the additional feature that parenthesized substrings from
|
||||
the pattern can be interpolated as <b>$1</b>, <b>$2</b> and so on.
|
||||
|
||||
<b>TCP-BASED TABLES</b>
|
||||
This section describes how the table lookups change when
|
||||
lookups are directed to a TCP-based server. For a descrip-
|
||||
tion of the TCP client/server lookup protocol, see
|
||||
<b>tcp</b><i>_</i><b>table</b>(5).
|
||||
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
<i>user@domain</i> mail addresses are not broken up into their
|
||||
<i>user</i> and <i>@domain</i> constituent parts, nor is <i>user+foo</i> broken
|
||||
up into <i>user</i> and <i>foo</i>.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
|
||||
<b>BUGS</b>
|
||||
The table format does not understand quoting conventions.
|
||||
|
||||
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
||||
<b>CONFIGURATION PARAMETERS</b>
|
||||
The following <b>main.cf</b> parameters are especially relevant
|
||||
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
||||
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
||||
details and for default values. Use the <b>postfix reload</b>
|
||||
command after a configuration change.
|
||||
|
||||
<b>virtual</b><i>_</i><b>alias</b><i>_</i><b>maps</b>
|
||||
@ -211,11 +226,12 @@ VIRTUAL(5) VIRTUAL(5)
|
||||
Give special treatment to <b>owner-</b><i>xxx</i> and <i>xxx</i><b>-request</b>
|
||||
addresses.
|
||||
|
||||
<b>SEE</b> <b>ALSO</b>
|
||||
<b>SEE ALSO</b>
|
||||
<a href="cleanup.8.html">cleanup(8)</a> canonicalize and enqueue mail
|
||||
<a href="postmap.1.html">postmap(1)</a> create mapping table
|
||||
<a href="regexp_table.5.html">regexp_table(5)</a> POSIX regular expression table format
|
||||
<a href="pcre_table.5.html">pcre_table(5)</a> Perl Compatible Regular Expression table format
|
||||
<a href="tcp_table.5.html">tcp_table(5)</a> TCP client/server table lookup protocol
|
||||
|
||||
<b>LICENSE</b>
|
||||
The Secure Mailer license must be distributed with this
|
||||
|
||||
@ -32,8 +32,10 @@ When the table is provided via other means such as NIS, LDAP
|
||||
or SQL, the same lookups are done as for ordinary indexed files.
|
||||
|
||||
Alternatively, the table can be provided as a regular-expression
|
||||
map where patterns are given as regular expressions. In that case,
|
||||
the lookups are done in a slightly different way as described below.
|
||||
map where patterns are given as regular expressions, or lookups
|
||||
can be directed to TCP-based server. In that case, the lookups are
|
||||
done in a slightly different way as described below under
|
||||
"REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
.SH TABLE FORMAT
|
||||
.na
|
||||
.nf
|
||||
@ -75,7 +77,7 @@ some types of lookup table. By default, Postfix uses \fB<>\fR
|
||||
as the lookup key for such addresses. The value is specified with
|
||||
the \fBsmtpd_null_access_lookup_key\fR parameter in the Postfix
|
||||
\fBmain.cf\fR file.
|
||||
.SH ADDRESS EXTENSION
|
||||
.SH EMAIL ADDRESS EXTENSION
|
||||
.na
|
||||
.nf
|
||||
.fi
|
||||
@ -107,8 +109,8 @@ order to match subdomains.
|
||||
Matches any host address in the specified network. A network
|
||||
address is a sequence of one or more octets separated by ".".
|
||||
|
||||
NOTE: use the \fBcidr\fR lookup table type if you want to
|
||||
specify arbitrary network blocks.
|
||||
NOTE: use the \fBcidr\fR lookup table type if to specify
|
||||
network/netmask patterns. See cidr_table(5) for details.
|
||||
.SH ACTIONS
|
||||
.na
|
||||
.nf
|
||||
@ -190,6 +192,24 @@ pattern is found that matches the search string.
|
||||
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 TCP-BASED TABLES
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when lookups
|
||||
are directed to a TCP-based server. For a description of the TCP
|
||||
client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each lookup operation uses the entire query string once.
|
||||
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,
|
||||
\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.
|
||||
|
||||
Actions are the same as with indexed file lookups.
|
||||
.SH BUGS
|
||||
.ad
|
||||
.fi
|
||||
@ -202,6 +222,7 @@ smtpd(8) smtp server
|
||||
cidr_table(5) format of CIDR tables
|
||||
pcre_table(5) format of PCRE tables
|
||||
regexp_table(5) format of POSIX regular expression tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -31,8 +31,10 @@ When the table is provided via other means such as NIS, LDAP
|
||||
or SQL, the same lookups are done as for ordinary indexed files.
|
||||
|
||||
Alternatively, the table can be provided as a regular-expression
|
||||
map where patterns are given as regular expressions. In that case,
|
||||
the lookups are done in a slightly different way as described below.
|
||||
map where patterns are given as regular expressions, or lookups
|
||||
can be directed to TCP-based server. In that case, the lookups are
|
||||
done in a slightly different way as described below under
|
||||
"REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
|
||||
The \fBcanonical\fR mapping affects both message header addresses
|
||||
(i.e. addresses that appear inside messages) and message envelope
|
||||
@ -118,6 +120,21 @@ pattern is found that matches the search string.
|
||||
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 TCP-BASED TABLES
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when lookups
|
||||
are directed to a TCP-based server. For a description of the TCP
|
||||
client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
\fIuser@domain\fR mail addresses are not broken up into their
|
||||
\fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
.SH BUGS
|
||||
.ad
|
||||
.fi
|
||||
@ -167,6 +184,7 @@ postmap(1) create mapping table
|
||||
virtual(5) virtual domain mapping
|
||||
pcre_table(5) format of PCRE tables
|
||||
regexp_table(5) format of POSIX regular expression tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -41,7 +41,11 @@ 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.
|
||||
.PP
|
||||
.SH SEARCH ORDER
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
.SH EXAMPLE SMTPD ACCESS MAP
|
||||
@ -49,9 +53,9 @@ pattern is found that matches the search string.
|
||||
.nf
|
||||
/etc/postfix/main.cf:
|
||||
.ti +4
|
||||
smtpd_client_restrictions = ... cidr:/etc/postfix/client_cidr ...
|
||||
smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
|
||||
|
||||
/etc/postfix/client_cidr:
|
||||
/etc/postfix/client.cidr:
|
||||
.in +4
|
||||
# Rule order matters. Put more specific whitelist entries
|
||||
# before more general blacklist entries.
|
||||
|
||||
@ -24,7 +24,11 @@ supports use the \fBpostconf -m\fR command.
|
||||
|
||||
To test lookup tables, use the \fBpostmap\fR command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
.SH TABLE FORMAT
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
The general form of a PCRE table is:
|
||||
.IP "\fB/\fIpattern\fB/\fIflags result\fR"
|
||||
.IP "\fB!/\fIpattern\fB/\fIflags result\fR"
|
||||
@ -100,7 +104,14 @@ Toggles the PCRE_EXTRA flag.
|
||||
When this flag is on, any backslash in a pattern that is
|
||||
followed by a letter that has no special meaning causes an
|
||||
error, thus reserving these combinations for future expansion.
|
||||
.PP
|
||||
.SH SEARCH ORDER
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
|
||||
Each pattern is applied to the entire lookup key string.
|
||||
Depending on the application, that string is an entire client
|
||||
hostname, an entire client IP address, or an entire mail address.
|
||||
@ -108,16 +119,19 @@ Thus, no parent domain or parent network search is done, and
|
||||
\fIuser@domain\fR mail addresses are not broken up into their
|
||||
\fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
|
||||
broken up into \fIuser\fR and \fIfoo\fR.
|
||||
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
|
||||
.SH TEXT SUBSTITUTION
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Substitution of substrings from the matched expression into the result
|
||||
string is possible using the conventional perl syntax ($1, $2, etc.).
|
||||
The macros in the result string may need to be written as ${n}
|
||||
or $(n) if they aren't followed by whitespace. Since negated patterns
|
||||
(those preceded by \fB!\fR) return a result when the expression does
|
||||
not match, substitutions are not available for negated patterns.
|
||||
or $(n) if they aren't followed by whitespace.
|
||||
|
||||
Note: since negated patterns (those preceded by \fB!\fR) return a
|
||||
result when the expression does not match, substitutions are not
|
||||
available for negated patterns.
|
||||
.SH EXAMPLE SMTPD ACCESS MAP
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -24,7 +24,11 @@ supports use the \fBpostconf -m\fR command.
|
||||
|
||||
To test lookup tables, use the \fBpostmap\fR command as
|
||||
described in the SYNOPSIS above.
|
||||
|
||||
.SH TABLE FORMAT
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
The general form of a Postfix regular expression table is:
|
||||
.IP "\fB/\fIpattern\fB/\fIflags result\fR"
|
||||
.IP "\fB!/\fIpattern\fB/\fIflags result\fR"
|
||||
@ -54,6 +58,13 @@ By default, matching is case-insensitive, although following
|
||||
the second slash with an `i' flag will reverse this. Other flags
|
||||
are `x' (disable extended expression syntax), and `m' (enable
|
||||
multi-line mode, that is, treat newline characters as special).
|
||||
.SH TABLE SEARCH ORDER
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
|
||||
Each pattern is applied to the entire lookup key string.
|
||||
Depending on the application, that string is an entire client
|
||||
@ -62,16 +73,19 @@ Thus, no parent domain or parent network search is done, and
|
||||
\fIuser@domain\fR mail addresses are not broken up into their
|
||||
\fIuser\fR and \fIdomain\fR constituent parts, nor is \fIuser+foo\fR
|
||||
broken up into \fIuser\fR and \fIfoo\fR.
|
||||
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
|
||||
.SH TEXT SUBSTITUTION
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Substitution of substrings from the matched expression into the result
|
||||
string is possible using $1, $2, etc.. The macros in the result string
|
||||
may need to be written as ${n} or $(n) if they aren't followed
|
||||
by whitespace. Since negated patterns (those preceded by \fB!\fR)
|
||||
return a result when the expression does not match, substitutions are
|
||||
not available for negated patterns.
|
||||
by whitespace.
|
||||
|
||||
Note: since negated patterns (those preceded by \fB!\fR) return a
|
||||
result when the expression does not match, substitutions are not
|
||||
available for negated patterns.
|
||||
.SH EXAMPLE SMTPD ACCESS MAP
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -26,8 +26,10 @@ When the table is provided via other means such as NIS, LDAP
|
||||
or SQL, the same lookups are done as for ordinary indexed files.
|
||||
|
||||
Alternatively, the table can be provided as a regular-expression
|
||||
map where patterns are given as regular expressions. In that case,
|
||||
the lookups are done in a slightly different way as described below.
|
||||
map where patterns are given as regular expressions, or lookups
|
||||
can be directed to TCP-based server. In that case, the lookups are
|
||||
done in a slightly different way as described below under
|
||||
"REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
|
||||
Table lookups are case insensitive.
|
||||
.SH TABLE FORMAT
|
||||
@ -78,9 +80,11 @@ When a mail address localpart contains the optional recipient delimiter
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when the table
|
||||
is given in the form of regular expressions. For a description of
|
||||
regular expression lookup table syntax, see \fBregexp_table\fR(5)
|
||||
or \fBpcre_table\fR(5).
|
||||
is given in the form of regular expressions or when lookups are
|
||||
directed to a TCP-based server. For a description of regular
|
||||
expression lookup table syntax, see \fBregexp_table\fR(5) or
|
||||
\fBpcre_table\fR(5). For a description of the TCP client/server
|
||||
table lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each pattern is a regular expression that is applied to the entire
|
||||
address being looked up. Thus, \fIuser@domain\fR mail addresses are not
|
||||
@ -93,6 +97,21 @@ pattern is found that matches the search string.
|
||||
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 TCP-BASED TABLES
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when lookups
|
||||
are directed to a TCP-based server. For a description of the TCP
|
||||
client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
\fIuser@domain\fR mail addresses are not broken up into their
|
||||
\fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
.SH BUGS
|
||||
.ad
|
||||
.fi
|
||||
@ -123,6 +142,7 @@ The domain that is appended to locally-posted mail.
|
||||
postmap(1) create lookup table
|
||||
pcre_table(5) format of PCRE tables
|
||||
regexp_table(5) format of POSIX regular expression tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -10,14 +10,14 @@ Postfix client/server table lookup protocol
|
||||
.nf
|
||||
\fBpostmap -q "\fIstring\fB" tcp:\fIhost:port\fR
|
||||
|
||||
\fBpostmap -q - regexp:\fIhost:port\fR <\fIinputfile\fR
|
||||
\fBpostmap -q - tcp:\fIhost:port\fR <\fIinputfile\fR
|
||||
.SH DESCRIPTION
|
||||
.ad
|
||||
.fi
|
||||
The Postfix mail system uses optional tables for address
|
||||
rewriting or mail routing. These tables are usually in
|
||||
\fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
|
||||
can be specified as a TCP client/server pair.
|
||||
\fBdbm\fR or \fBdb\fR format. Alternatively, table lookups
|
||||
can be directed to a TCP server.
|
||||
|
||||
To find out what types of lookup tables your Postfix system
|
||||
supports use the \fBpostconf -m\fR command.
|
||||
@ -34,22 +34,13 @@ sends a request, and the server sends one reply. Requests and
|
||||
replies are sent as one line of ASCII text, terminated by the
|
||||
ASCII newline character. Request and reply parameters (see below)
|
||||
are separated by whitespace.
|
||||
.SH ENCODING
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
In request and reply parameters, the character % and any non-printing
|
||||
and whitespace characters must be replaced by %XX, XX being the
|
||||
corresponding ASCII hexadecimal character value. The hexadecimal codes
|
||||
can be specified in any case (upper, lower, mixed).
|
||||
.SH REQUEST FORMAT
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Requests are strings that serve as lookup key in the simulated
|
||||
table.
|
||||
Each request specifies a command, a lookup key, and possibly a
|
||||
lookup result.
|
||||
.IP "\fBget\fR SPACE \fIkey\fR NEWLINE"
|
||||
Look up data under the specified key.
|
||||
.IP "\fBput\fR SPACE \fIkey\fR SPACE \fIvalue\fR NEWLINE"
|
||||
@ -59,18 +50,37 @@ This request is currently not implemented.
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
Replies must be no longer than 4096 characters including the
|
||||
newline terminator, and must have the following form:
|
||||
.IP "\fB500\fR SPACE \fIoptional-text\fR NEWLINE"
|
||||
Each reply specifies a status code and text. Replies must be no
|
||||
longer than 4096 characters including the newline terminator.
|
||||
.IP "\fB500\fR SPACE \fItext\fR NEWLINE"
|
||||
In case of a lookup request, the requested data does not exist.
|
||||
In case of an update request, the request was rejected.
|
||||
.IP "\fB400\fR SPACE \fIoptional-text\fR NEWLINE"
|
||||
This indicates an error condition. The text gives the nature of
|
||||
The text describes the nature of the problem.
|
||||
.IP "\fB400\fR SPACE \fItext\fR NEWLINE"
|
||||
This indicates an error condition. The text describes the nature of
|
||||
the problem. The client should retry the request later.
|
||||
.IP "\fB200\fR SPACE \fItext\fR NEWLINE"
|
||||
The request was successful. In the case of a lookup request,
|
||||
the text contains an encoded version of the requested data.
|
||||
Otherwise the text is optional.
|
||||
.SH ENCODING
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
In request and reply parameters, the character %, each non-printing
|
||||
character, and each whitespace character must be replaced by %XX,
|
||||
where XX is the corresponding ASCII hexadecimal character value. The
|
||||
hexadecimal codes can be specified in any case (upper, lower, mixed).
|
||||
|
||||
The Postfix client always encodes a request.
|
||||
The server may omit the encoding as long as the reply
|
||||
is guaranteed to not contain the % or NEWLINE character.
|
||||
.SH SECURITY
|
||||
.na
|
||||
.nf
|
||||
Do not use TCP lookup tables for security critical purposes.
|
||||
The client-server connection is not protected and the server
|
||||
is not authenticated.
|
||||
.SH SEE ALSO
|
||||
.na
|
||||
.nf
|
||||
@ -81,6 +91,9 @@ cidr_table(5) format of CIDR tables
|
||||
.ad
|
||||
.fi
|
||||
Only the lookup method is currently implemented.
|
||||
|
||||
The client does not hang up when the connection is idle for
|
||||
a long time.
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -46,9 +46,10 @@ When the table is provided via other means such as NIS, LDAP
|
||||
or SQL, the same lookups are done as for ordinary indexed files.
|
||||
|
||||
Alternatively, the table can be provided as a regular-expression
|
||||
map where patterns are given as regular expressions. In that case,
|
||||
the lookups are done in a slightly different way as described
|
||||
in section "REGULAR EXPRESSION TABLES".
|
||||
map where patterns are given as regular expressions, or lookups
|
||||
can be directed to TCP-based server. In that case, the lookups are
|
||||
done in a slightly different way as described below under
|
||||
"REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
.SH TABLE FORMAT
|
||||
.na
|
||||
.nf
|
||||
@ -144,7 +145,7 @@ destinations.
|
||||
.ti +5
|
||||
\fB\&.my.domain :\fR
|
||||
.ti +5
|
||||
\fB* smtp:outbound-relay.my.domain\fR
|
||||
\fB* smtp:outbound-relay.my.domain\fR
|
||||
|
||||
In order to send mail for \fBfoo.org\fR and its subdomains
|
||||
via the \fBuucp\fR transport to the UUCP host named \fBfoo\fR:
|
||||
@ -204,8 +205,9 @@ regular expression lookup table syntax, see \fBregexp_table\fR(5)
|
||||
or \fBpcre_table\fR(5).
|
||||
|
||||
Each pattern is a regular expression that is applied to the entire
|
||||
domain being looked up. Thus, \fIsome.domain.hierarchy\fR is not
|
||||
broken up into parent domains.
|
||||
address being looked up. Thus, \fIsome.domain.hierarchy\fR is not
|
||||
looked up up via its parent domains,
|
||||
nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR.
|
||||
|
||||
Patterns are applied in the order as specified in the table, until a
|
||||
pattern is found that matches the search string.
|
||||
@ -213,6 +215,20 @@ pattern is found that matches the search string.
|
||||
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 TCP-BASED TABLES
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when lookups
|
||||
are directed to a TCP-based server. For a description of the TCP
|
||||
client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each lookup operation uses the entire recipient address once. Thus,
|
||||
\fIsome.domain.hierarchy\fR is not looked up via its parent domains,
|
||||
nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
.SH CONFIGURATION PARAMETERS
|
||||
.na
|
||||
.nf
|
||||
@ -237,6 +253,7 @@ postmap(1) create mapping table
|
||||
trivial-rewrite(8) rewrite and resolve addresses
|
||||
pcre_table(5) format of PCRE tables
|
||||
regexp_table(5) format of POSIX regular expression tables
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -48,8 +48,10 @@ When the table is provided via other means such as NIS, LDAP
|
||||
or SQL, the same lookups are done as for ordinary indexed files.
|
||||
|
||||
Alternatively, the table can be provided as a regular-expression
|
||||
map where patterns are given as regular expressions. In that case,
|
||||
the lookups are done in a slightly different way as described below.
|
||||
map where patterns are given as regular expressions, or lookups
|
||||
can be directed to TCP-based server. In that case, the lookups are
|
||||
done in a slightly different way as described below under
|
||||
"REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
.SH TABLE FORMAT
|
||||
.na
|
||||
.nf
|
||||
@ -178,6 +180,21 @@ pattern is found that matches the search string.
|
||||
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 TCP-BASED TABLES
|
||||
.na
|
||||
.nf
|
||||
.ad
|
||||
.fi
|
||||
This section describes how the table lookups change when lookups
|
||||
are directed to a TCP-based server. For a description of the TCP
|
||||
client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
|
||||
Each lookup operation uses the entire address once. Thus,
|
||||
\fIuser@domain\fR mail addresses are not broken up into their
|
||||
\fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
|
||||
Results are the same as with indexed file lookups.
|
||||
.SH BUGS
|
||||
.ad
|
||||
.fi
|
||||
@ -215,6 +232,7 @@ cleanup(8) canonicalize and enqueue mail
|
||||
postmap(1) create mapping table
|
||||
regexp_table(5) POSIX regular expression table format
|
||||
pcre_table(5) Perl Compatible Regular Expression table format
|
||||
tcp_table(5) TCP client/server table lookup protocol
|
||||
.SH LICENSE
|
||||
.na
|
||||
.nf
|
||||
|
||||
@ -136,6 +136,11 @@ The BCC address is added when the message enters the system.
|
||||
.IP \fBrecipient_bcc_maps\fR
|
||||
Automatic BCC recipient lookup table, indexed by recipient address.
|
||||
The BCC address is added when the message enters the system.
|
||||
.IP \fBenable_original_recipient\fR
|
||||
Enable support for the \fBX-Original-To:\fR message header, which is
|
||||
needed for multi-recipient mailboxes. When this is enabled, Postfix
|
||||
performs duplicate elimination on (original recipient, rewritten
|
||||
recipient) pairs, instead of looking at the rewritten recipient only.
|
||||
.IP \fBhopcount_limit\fR
|
||||
Limit the number of \fBReceived:\fR message headers.
|
||||
.IP \fBundisclosed_recipients_header\fR
|
||||
@ -150,11 +155,6 @@ substitution is done before all other address rewriting.
|
||||
.IP \fBcanonical_maps\fR
|
||||
Address mapping lookup table for sender and recipient addresses
|
||||
in envelopes and headers.
|
||||
.IP \fBenable_original_recipient\fR
|
||||
Enable support for the X-Original-To message header, which is
|
||||
needed for multi-recipient mailboxes. When this is enabled, Postfix
|
||||
performs duplicate elimination on (original recipient, rewritten
|
||||
recipient) pairs, instead of looking at the rewritten recipient only.
|
||||
.IP \fBrecipient_canonical_maps\fR
|
||||
Address mapping lookup table for envelope and header recipient
|
||||
addresses.
|
||||
|
||||
@ -288,7 +288,8 @@ verification service.
|
||||
.IP \fBaddress_verify_poll_count\fR
|
||||
How many times to query the address verification service
|
||||
for completion of an address verification request.
|
||||
Specify 0 to implement a simple form of greylisting.
|
||||
Specify 1 to implement a simple form of greylisting, that is,
|
||||
always defer the request for a new sender or recipient address.
|
||||
.IP \fBaddress_verify_poll_delay\fR
|
||||
Time to wait after querying the address verification service
|
||||
for completion of an address verification request.
|
||||
|
||||
@ -35,8 +35,7 @@ This server implements the following requests:
|
||||
.IP "\fBVRFY_ADDR_UPDATE\fI address status text\fR"
|
||||
Update the status of the specified address.
|
||||
.IP "\fBVRFY_ADDR_QUERY\fI address\fR"
|
||||
Look up the \fIstatus\fR, \fIlast update time\fR and \fItext\fR
|
||||
of the specified address.
|
||||
Look up the \fIstatus\fR and \fItext\fR of the specified address.
|
||||
If the status is unknown, a probe is sent and a default status is
|
||||
returned.
|
||||
.PP
|
||||
|
||||
@ -11,8 +11,8 @@ sed '
|
||||
s/>/\>/g
|
||||
s;_\(.\);<i>\1</i>;g
|
||||
s;.\(.\);<b>\1</b>;g
|
||||
s;</i><i>;;g
|
||||
s;</b><b>;;g
|
||||
s;</i>\( *\)<i>;\1;g
|
||||
s;</b>\( *\)<b>;\1;g
|
||||
' "$@"
|
||||
|
||||
echo '</pre> </body> </html>'
|
||||
|
||||
@ -52,6 +52,8 @@ exec sed '
|
||||
s/[<bB>]*verify[</bB>]*(8)/<a href="verify.8.html">&<\/a>/
|
||||
s/[<bB>]*virtual[</bB>]*(5)/<a href="virtual.5.html">&<\/a>/
|
||||
s/[<bB>]*virtual[</bB>]*(8)/<a href="virtual.8.html">&<\/a>/
|
||||
s/[<bB>]*cidr_table[</bB>]*(5)/<a href="cidr_table.5.html">&<\/a>/
|
||||
s/[<bB>]*tcp_table[</bB>]*(5)/<a href="tcp_table.5.html">&<\/a>/
|
||||
s/\(<a href="[^"]*">\)\([<bB>]*[a-z0-9-]*[-</bB>]*\)\(\n *\)\([<bB>]*[a-z0-9-]*[</bB>]*([0-9])\)\(<\/a>\)/\1\2\5\3\1\4\5/
|
||||
s/http:\/\/[^ ,]*/<a href="&">&<\/a>/
|
||||
s/RFC *\([0-9]*\)/<a href="http:\/\/www.faqs.org\/rfcs\/rfc\1.html">&<\/a>/
|
||||
|
||||
@ -6,9 +6,9 @@
|
||||
# SYNOPSIS
|
||||
# \fBpostmap /etc/postfix/access\fR
|
||||
#
|
||||
# \fBpostmap -q "\fIstring\fB" /etc/postfix/access\fR
|
||||
# \fBpostmap -q "\fIstring\fB" /etc/postfix/access\fR
|
||||
#
|
||||
# \fBpostmap -q - /etc/postfix/access <\fIinputfile\fR
|
||||
# \fBpostmap -q - /etc/postfix/access <\fIinputfile\fR
|
||||
# DESCRIPTION
|
||||
# The optional \fBaccess\fR table directs the Postfix SMTP server
|
||||
# to selectively reject or accept mail. Access can be allowed or
|
||||
@ -26,8 +26,10 @@
|
||||
# or SQL, the same lookups are done as for ordinary indexed files.
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-expression
|
||||
# map where patterns are given as regular expressions. In that case,
|
||||
# the lookups are done in a slightly different way as described below.
|
||||
# map where patterns are given as regular expressions, or lookups
|
||||
# can be directed to TCP-based server. In that case, the lookups are
|
||||
# done in a slightly different way as described below under
|
||||
# "REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
# TABLE FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
@ -65,7 +67,7 @@
|
||||
# as the lookup key for such addresses. The value is specified with
|
||||
# the \fBsmtpd_null_access_lookup_key\fR parameter in the Postfix
|
||||
# \fBmain.cf\fR file.
|
||||
# ADDRESS EXTENSION
|
||||
# EMAIL ADDRESS EXTENSION
|
||||
# .fi
|
||||
# .ad
|
||||
# When a mail address localpart contains the optional recipient delimiter
|
||||
@ -93,8 +95,8 @@
|
||||
# Matches any host address in the specified network. A network
|
||||
# address is a sequence of one or more octets separated by ".".
|
||||
#
|
||||
# NOTE: use the \fBcidr\fR lookup table type if you want to
|
||||
# specify arbitrary network blocks.
|
||||
# NOTE: use the \fBcidr\fR lookup table type if to specify
|
||||
# network/netmask patterns. See cidr_table(5) for details.
|
||||
# ACTIONS
|
||||
# .ad
|
||||
# .fi
|
||||
@ -172,6 +174,22 @@
|
||||
# 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.
|
||||
# TCP-BASED TABLES
|
||||
# .ad
|
||||
# .fi
|
||||
# This section describes how the table lookups change when lookups
|
||||
# are directed to a TCP-based server. For a description of the TCP
|
||||
# client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each lookup operation uses the entire query string once.
|
||||
# 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,
|
||||
# \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.
|
||||
#
|
||||
# Actions are the same as with indexed file lookups.
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
# SEE ALSO
|
||||
@ -180,6 +198,7 @@
|
||||
# cidr_table(5) format of CIDR tables
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -25,8 +25,10 @@
|
||||
# or SQL, the same lookups are done as for ordinary indexed files.
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-expression
|
||||
# map where patterns are given as regular expressions. In that case,
|
||||
# the lookups are done in a slightly different way as described below.
|
||||
# map where patterns are given as regular expressions, or lookups
|
||||
# can be directed to TCP-based server. In that case, the lookups are
|
||||
# done in a slightly different way as described below under
|
||||
# "REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
#
|
||||
# The \fBcanonical\fR mapping affects both message header addresses
|
||||
# (i.e. addresses that appear inside messages) and message envelope
|
||||
@ -106,6 +108,19 @@
|
||||
# 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.
|
||||
# TCP-BASED TABLES
|
||||
# .ad
|
||||
# .fi
|
||||
# This section describes how the table lookups change when lookups
|
||||
# are directed to a TCP-based server. For a description of the TCP
|
||||
# client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# \fIuser@domain\fR mail addresses are not broken up into their
|
||||
# \fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
# CONFIGURATION PARAMETERS
|
||||
@ -149,6 +164,7 @@
|
||||
# virtual(5) virtual domain mapping
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -33,15 +33,17 @@
|
||||
# .IP "multi-line text"
|
||||
# A logical line starts with non-whitespace text. A line that
|
||||
# starts with whitespace continues a logical line.
|
||||
# .PP
|
||||
# SEARCH ORDER
|
||||
# .ad
|
||||
# .fi
|
||||
# Patterns are applied in the order as specified in the table, until a
|
||||
# pattern is found that matches the search string.
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# /etc/postfix/main.cf:
|
||||
# .ti +4
|
||||
# smtpd_client_restrictions = ... cidr:/etc/postfix/client_cidr ...
|
||||
# smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
|
||||
#
|
||||
# /etc/postfix/client_cidr:
|
||||
# /etc/postfix/client.cidr:
|
||||
# .in +4
|
||||
# # Rule order matters. Put more specific whitelist entries
|
||||
# # before more general blacklist entries.
|
||||
|
||||
@ -18,7 +18,9 @@
|
||||
#
|
||||
# To test lookup tables, use the \fBpostmap\fR command as
|
||||
# described in the SYNOPSIS above.
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
# The general form of a PCRE table is:
|
||||
# .IP "\fB/\fIpattern\fB/\fIflags result\fR"
|
||||
# .IP "\fB!/\fIpattern\fB/\fIflags result\fR"
|
||||
@ -94,7 +96,12 @@
|
||||
# When this flag is on, any backslash in a pattern that is
|
||||
# followed by a letter that has no special meaning causes an
|
||||
# error, thus reserving these combinations for future expansion.
|
||||
# .PP
|
||||
# SEARCH ORDER
|
||||
# .ad
|
||||
# .fi
|
||||
# Patterns are applied in the order as specified in the table, until a
|
||||
# pattern is found that matches the search string.
|
||||
#
|
||||
# Each pattern is applied to the entire lookup key string.
|
||||
# Depending on the application, that string is an entire client
|
||||
# hostname, an entire client IP address, or an entire mail address.
|
||||
@ -102,16 +109,17 @@
|
||||
# \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.
|
||||
#
|
||||
# TEXT SUBSTITUTION
|
||||
# .ad
|
||||
# .fi
|
||||
# Substitution of substrings from the matched expression into the result
|
||||
# string is possible using the conventional perl syntax ($1, $2, etc.).
|
||||
# The macros in the result string may need to be written as ${n}
|
||||
# or $(n) if they aren't followed by whitespace. Since negated patterns
|
||||
# (those preceded by \fB!\fR) return a result when the expression does
|
||||
# not match, substitutions are not available for negated patterns.
|
||||
# or $(n) if they aren't followed by whitespace.
|
||||
#
|
||||
# Note: since negated patterns (those preceded by \fB!\fR) return a
|
||||
# result when the expression does not match, substitutions are not
|
||||
# available for negated patterns.
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# # Protect your outgoing majordomo exploders
|
||||
# /^(?!owner-)(.*)-outgoing@(.*)/ 550 Use ${1}@${2} instead
|
||||
|
||||
@ -18,7 +18,9 @@
|
||||
#
|
||||
# To test lookup tables, use the \fBpostmap\fR command as
|
||||
# described in the SYNOPSIS above.
|
||||
#
|
||||
# TABLE FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
# The general form of a Postfix regular expression table is:
|
||||
# .IP "\fB/\fIpattern\fB/\fIflags result\fR"
|
||||
# .IP "\fB!/\fIpattern\fB/\fIflags result\fR"
|
||||
@ -48,6 +50,11 @@
|
||||
# the second slash with an `i' flag will reverse this. Other flags
|
||||
# are `x' (disable extended expression syntax), and `m' (enable
|
||||
# multi-line mode, that is, treat newline characters as special).
|
||||
# TABLE SEARCH ORDER
|
||||
# .ad
|
||||
# .fi
|
||||
# Patterns are applied in the order as specified in the table, until a
|
||||
# pattern is found that matches the search string.
|
||||
#
|
||||
# Each pattern is applied to the entire lookup key string.
|
||||
# Depending on the application, that string is an entire client
|
||||
@ -56,16 +63,17 @@
|
||||
# \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.
|
||||
#
|
||||
# TEXT SUBSTITUTION
|
||||
# .ad
|
||||
# .fi
|
||||
# Substitution of substrings from the matched expression into the result
|
||||
# string is possible using $1, $2, etc.. The macros in the result string
|
||||
# may need to be written as ${n} or $(n) if they aren't followed
|
||||
# by whitespace. Since negated patterns (those preceded by \fB!\fR)
|
||||
# return a result when the expression does not match, substitutions are
|
||||
# not available for negated patterns.
|
||||
# by whitespace.
|
||||
#
|
||||
# Note: since negated patterns (those preceded by \fB!\fR) return a
|
||||
# result when the expression does not match, substitutions are not
|
||||
# available for negated patterns.
|
||||
# EXAMPLE SMTPD ACCESS MAP
|
||||
# # Disallow sender-specified routing. This is a must if you relay mail
|
||||
# # for other domains.
|
||||
|
||||
@ -20,8 +20,10 @@
|
||||
# or SQL, the same lookups are done as for ordinary indexed files.
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-expression
|
||||
# map where patterns are given as regular expressions. In that case,
|
||||
# the lookups are done in a slightly different way as described below.
|
||||
# map where patterns are given as regular expressions, or lookups
|
||||
# can be directed to TCP-based server. In that case, the lookups are
|
||||
# done in a slightly different way as described below under
|
||||
# "REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
#
|
||||
# Table lookups are case insensitive.
|
||||
# TABLE FORMAT
|
||||
@ -58,17 +60,19 @@
|
||||
# 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, \fIuser+foo\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
|
||||
# This section describes how the table lookups change when the table
|
||||
# is given in the form of regular expressions. For a description of
|
||||
# regular expression lookup table syntax, see \fBregexp_table\fR(5)
|
||||
# or \fBpcre_table\fR(5).
|
||||
# is given in the form of regular expressions or when lookups are
|
||||
# directed to a TCP-based server. For a description of regular
|
||||
# expression lookup table syntax, see \fBregexp_table\fR(5) or
|
||||
# \fBpcre_table\fR(5). For a description of the TCP client/server
|
||||
# table lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each pattern is a regular expression that is applied to the entire
|
||||
# address being looked up. Thus, \fIuser@domain\fR mail addresses are not
|
||||
@ -81,6 +85,19 @@
|
||||
# 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.
|
||||
# TCP-BASED TABLES
|
||||
# .ad
|
||||
# .fi
|
||||
# This section describes how the table lookups change when lookups
|
||||
# are directed to a TCP-based server. For a description of the TCP
|
||||
# client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# \fIuser@domain\fR mail addresses are not broken up into their
|
||||
# \fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
# CONFIGURATION PARAMETERS
|
||||
@ -105,6 +122,7 @@
|
||||
# postmap(1) create lookup table
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -6,12 +6,12 @@
|
||||
# SYNOPSIS
|
||||
# \fBpostmap -q "\fIstring\fB" tcp:\fIhost:port\fR
|
||||
#
|
||||
# \fBpostmap -q - regexp:\fIhost:port\fR <\fIinputfile\fR
|
||||
# \fBpostmap -q - tcp:\fIhost:port\fR <\fIinputfile\fR
|
||||
# DESCRIPTION
|
||||
# The Postfix mail system uses optional tables for address
|
||||
# rewriting or mail routing. These tables are usually in
|
||||
# \fBdbm\fR or \fBdb\fR format. Alternatively, lookup tables
|
||||
# can be specified as a TCP client/server pair.
|
||||
# \fBdbm\fR or \fBdb\fR format. Alternatively, table lookups
|
||||
# can be directed to a TCP server.
|
||||
#
|
||||
# To find out what types of lookup tables your Postfix system
|
||||
# supports use the \fBpostconf -m\fR command.
|
||||
@ -26,18 +26,11 @@
|
||||
# replies are sent as one line of ASCII text, terminated by the
|
||||
# ASCII newline character. Request and reply parameters (see below)
|
||||
# are separated by whitespace.
|
||||
# ENCODING
|
||||
# .ad
|
||||
# .fi
|
||||
# In request and reply parameters, the character % and any non-printing
|
||||
# and whitespace characters must be replaced by %XX, XX being the
|
||||
# corresponding ASCII hexadecimal character value. The hexadecimal codes
|
||||
# can be specified in any case (upper, lower, mixed).
|
||||
# REQUEST FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
# Requests are strings that serve as lookup key in the simulated
|
||||
# table.
|
||||
# Each request specifies a command, a lookup key, and possibly a
|
||||
# lookup result.
|
||||
# .IP "\fBget\fR SPACE \fIkey\fR NEWLINE"
|
||||
# Look up data under the specified key.
|
||||
# .IP "\fBput\fR SPACE \fIkey\fR SPACE \fIvalue\fR NEWLINE"
|
||||
@ -45,24 +38,42 @@
|
||||
# REPLY FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
# Replies must be no longer than 4096 characters including the
|
||||
# newline terminator, and must have the following form:
|
||||
# .IP "\fB500\fR SPACE \fIoptional-text\fR NEWLINE"
|
||||
# Each reply specifies a status code and text. Replies must be no
|
||||
# longer than 4096 characters including the newline terminator.
|
||||
# .IP "\fB500\fR SPACE \fItext\fR NEWLINE"
|
||||
# In case of a lookup request, the requested data does not exist.
|
||||
# In case of an update request, the request was rejected.
|
||||
# .IP "\fB400\fR SPACE \fIoptional-text\fR NEWLINE"
|
||||
# This indicates an error condition. The text gives the nature of
|
||||
# The text describes the nature of the problem.
|
||||
# .IP "\fB400\fR SPACE \fItext\fR NEWLINE"
|
||||
# This indicates an error condition. The text describes the nature of
|
||||
# the problem. The client should retry the request later.
|
||||
# .IP "\fB200\fR SPACE \fItext\fR NEWLINE"
|
||||
# The request was successful. In the case of a lookup request,
|
||||
# the text contains an encoded version of the requested data.
|
||||
# Otherwise the text is optional.
|
||||
# ENCODING
|
||||
# .ad
|
||||
# .fi
|
||||
# In request and reply parameters, the character %, each non-printing
|
||||
# character, and each whitespace character must be replaced by %XX,
|
||||
# where XX is the corresponding ASCII hexadecimal character value. The
|
||||
# hexadecimal codes can be specified in any case (upper, lower, mixed).
|
||||
#
|
||||
# The Postfix client always encodes a request.
|
||||
# The server may omit the encoding as long as the reply
|
||||
# is guaranteed to not contain the % or NEWLINE character.
|
||||
# SECURITY
|
||||
# Do not use TCP lookup tables for security critical purposes.
|
||||
# The client-server connection is not protected and the server
|
||||
# is not authenticated.
|
||||
# SEE ALSO
|
||||
# regexp_table(5) format of regular expression tables
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# cidr_table(5) format of CIDR tables
|
||||
# BUGS
|
||||
# Only the lookup method is currently implemented.
|
||||
#
|
||||
# The client does not hang up when the connection is idle for
|
||||
# a long time.
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -40,9 +40,10 @@
|
||||
# or SQL, the same lookups are done as for ordinary indexed files.
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-expression
|
||||
# map where patterns are given as regular expressions. In that case,
|
||||
# the lookups are done in a slightly different way as described
|
||||
# in section "REGULAR EXPRESSION TABLES".
|
||||
# map where patterns are given as regular expressions, or lookups
|
||||
# can be directed to TCP-based server. In that case, the lookups are
|
||||
# done in a slightly different way as described below under
|
||||
# "REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
# TABLE FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
@ -130,7 +131,7 @@
|
||||
# .ti +5
|
||||
# \fB\&.my.domain :\fR
|
||||
# .ti +5
|
||||
# \fB* smtp:outbound-relay.my.domain\fR
|
||||
# \fB* smtp:outbound-relay.my.domain\fR
|
||||
#
|
||||
# In order to send mail for \fBfoo.org\fR and its subdomains
|
||||
# via the \fBuucp\fR transport to the UUCP host named \fBfoo\fR:
|
||||
@ -188,8 +189,9 @@
|
||||
# or \fBpcre_table\fR(5).
|
||||
#
|
||||
# Each pattern is a regular expression that is applied to the entire
|
||||
# domain being looked up. Thus, \fIsome.domain.hierarchy\fR is not
|
||||
# broken up into parent domains.
|
||||
# address being looked up. Thus, \fIsome.domain.hierarchy\fR is not
|
||||
# looked up up via its parent domains,
|
||||
# nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR.
|
||||
#
|
||||
# Patterns are applied in the order as specified in the table, until a
|
||||
# pattern is found that matches the search string.
|
||||
@ -197,6 +199,18 @@
|
||||
# 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.
|
||||
# TCP-BASED TABLES
|
||||
# .ad
|
||||
# .fi
|
||||
# This section describes how the table lookups change when lookups
|
||||
# are directed to a TCP-based server. For a description of the TCP
|
||||
# client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each lookup operation uses the entire recipient address once. Thus,
|
||||
# \fIsome.domain.hierarchy\fR is not looked up via its parent domains,
|
||||
# nor is \fIuser+foo@domain\fR looked up as \fIuser@domain\fR.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
# CONFIGURATION PARAMETERS
|
||||
# .ad
|
||||
# .fi
|
||||
@ -217,6 +231,7 @@
|
||||
# trivial-rewrite(8) rewrite and resolve addresses
|
||||
# pcre_table(5) format of PCRE tables
|
||||
# regexp_table(5) format of POSIX regular expression tables
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -42,8 +42,10 @@
|
||||
# or SQL, the same lookups are done as for ordinary indexed files.
|
||||
#
|
||||
# Alternatively, the table can be provided as a regular-expression
|
||||
# map where patterns are given as regular expressions. In that case,
|
||||
# the lookups are done in a slightly different way as described below.
|
||||
# map where patterns are given as regular expressions, or lookups
|
||||
# can be directed to TCP-based server. In that case, the lookups are
|
||||
# done in a slightly different way as described below under
|
||||
# "REGULAR EXPRESSION TABLES" and "TCP-BASED TABLES".
|
||||
# TABLE FORMAT
|
||||
# .ad
|
||||
# .fi
|
||||
@ -164,6 +166,19 @@
|
||||
# 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.
|
||||
# TCP-BASED TABLES
|
||||
# .ad
|
||||
# .fi
|
||||
# This section describes how the table lookups change when lookups
|
||||
# are directed to a TCP-based server. For a description of the TCP
|
||||
# client/server lookup protocol, see \fBtcp_table\fR(5).
|
||||
#
|
||||
# Each lookup operation uses the entire address once. Thus,
|
||||
# \fIuser@domain\fR mail addresses are not broken up into their
|
||||
# \fIuser\fR and \fI@domain\fR constituent parts, nor is
|
||||
# \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR.
|
||||
#
|
||||
# Results are the same as with indexed file lookups.
|
||||
# BUGS
|
||||
# The table format does not understand quoting conventions.
|
||||
# CONFIGURATION PARAMETERS
|
||||
@ -195,6 +210,7 @@
|
||||
# postmap(1) create mapping table
|
||||
# regexp_table(5) POSIX regular expression table format
|
||||
# pcre_table(5) Perl Compatible Regular Expression table format
|
||||
# tcp_table(5) TCP client/server table lookup protocol
|
||||
# LICENSE
|
||||
# .ad
|
||||
# .fi
|
||||
|
||||
@ -126,10 +126,9 @@ int bounce_append_service(char *service, char *queue_id,
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_RECIP, *recipient ?
|
||||
printable(vstring_str(quote_822_local(in_buf, recipient)), '?') :
|
||||
"<>");
|
||||
if (strcasecmp(recipient, orig_rcpt) != 0)
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_ORCPT, *orig_rcpt ?
|
||||
printable(vstring_str(quote_822_local(in_buf, orig_rcpt)), '?') :
|
||||
"<>");
|
||||
if (*orig_rcpt && strcasecmp(recipient, orig_rcpt) != 0)
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_ORCPT,
|
||||
printable(vstring_str(quote_822_local(in_buf, orig_rcpt)), '?'));
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_STATUS, printable(status, '?'));
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_ACTION, printable(action, '?'));
|
||||
vstream_fprintf(log, "%s=%s\n", MAIL_ATTR_WHY, printable(why, '?'));
|
||||
|
||||
@ -122,6 +122,11 @@
|
||||
/* .IP \fBrecipient_bcc_maps\fR
|
||||
/* Automatic BCC recipient lookup table, indexed by recipient address.
|
||||
/* The BCC address is added when the message enters the system.
|
||||
/* .IP \fBenable_original_recipient\fR
|
||||
/* Enable support for the \fBX-Original-To:\fR message header, which is
|
||||
/* needed for multi-recipient mailboxes. When this is enabled, Postfix
|
||||
/* performs duplicate elimination on (original recipient, rewritten
|
||||
/* recipient) pairs, instead of looking at the rewritten recipient only.
|
||||
/* .IP \fBhopcount_limit\fR
|
||||
/* Limit the number of \fBReceived:\fR message headers.
|
||||
/* .IP \fBundisclosed_recipients_header\fR
|
||||
@ -136,11 +141,6 @@
|
||||
/* .IP \fBcanonical_maps\fR
|
||||
/* Address mapping lookup table for sender and recipient addresses
|
||||
/* in envelopes and headers.
|
||||
/* .IP \fBenable_original_recipient\fR
|
||||
/* Enable support for the X-Original-To message header, which is
|
||||
/* needed for multi-recipient mailboxes. When this is enabled, Postfix
|
||||
/* performs duplicate elimination on (original recipient, rewritten
|
||||
/* recipient) pairs, instead of looking at the rewritten recipient only.
|
||||
/* .IP \fBrecipient_canonical_maps\fR
|
||||
/* Address mapping lookup table for envelope and header recipient
|
||||
/* addresses.
|
||||
|
||||
@ -89,7 +89,11 @@
|
||||
/* .PP
|
||||
/* Results:
|
||||
/* .IP recipient
|
||||
/* The final recipient address.
|
||||
/* The final recipient address in RFC 822 external form, or <>
|
||||
/* in case of the null recipient address.
|
||||
/* .IP orig_rcpt
|
||||
/* Null pointer or the original recipient address in RFC 822
|
||||
/* external form.
|
||||
/* .IP text
|
||||
/* The text that explains why the recipient was undeliverable.
|
||||
/* .IP dsn_status
|
||||
|
||||
@ -126,6 +126,10 @@ int header_token(HEADER_TOKEN *token, int token_len,
|
||||
|
||||
/*
|
||||
* Main parsing loop.
|
||||
*
|
||||
* XXX What was the reason to continue parsing when user_terminator is
|
||||
* specified? Perhaps this was needed at some intermediate stage of
|
||||
* development?
|
||||
*/
|
||||
while ((ch = *cp) != 0 && (user_terminator != 0 || tok_count < token_len)) {
|
||||
cp++;
|
||||
|
||||
@ -20,7 +20,7 @@
|
||||
* Patches change the patchlevel and the release date. Snapshots change the
|
||||
* release date only, unless they include the same bugfix as a patch release.
|
||||
*/
|
||||
#define MAIL_RELEASE_DATE "20030702"
|
||||
#define MAIL_RELEASE_DATE "20030704"
|
||||
|
||||
#define VAR_MAIL_VERSION "mail_version"
|
||||
#define DEF_MAIL_VERSION "2.0.13-" MAIL_RELEASE_DATE
|
||||
|
||||
@ -186,9 +186,11 @@ int forward_append(DELIVER_ATTR attr)
|
||||
}
|
||||
|
||||
/*
|
||||
* Append the recipient to the message envelope.
|
||||
* Append the recipient to the message envelope. Don't send the original
|
||||
* recipient if it was reset due to mailing list expansion.
|
||||
*/
|
||||
rec_fputs(info->cleanup, REC_TYPE_ORCP, attr.orig_rcpt);
|
||||
if (*attr.orig_rcpt)
|
||||
rec_fputs(info->cleanup, REC_TYPE_ORCP, attr.orig_rcpt);
|
||||
rec_fputs(info->cleanup, REC_TYPE_RCPT, attr.recipient);
|
||||
|
||||
return (vstream_ferror(info->cleanup));
|
||||
|
||||
@ -274,7 +274,8 @@
|
||||
/* .IP \fBaddress_verify_poll_count\fR
|
||||
/* How many times to query the address verification service
|
||||
/* for completion of an address verification request.
|
||||
/* Specify 0 to implement a simple form of greylisting.
|
||||
/* Specify 1 to implement a simple form of greylisting, that is,
|
||||
/* always defer the request for a new sender or recipient address.
|
||||
/* .IP \fBaddress_verify_poll_delay\fR
|
||||
/* Time to wait after querying the address verification service
|
||||
/* for completion of an address verification request.
|
||||
@ -617,9 +618,10 @@ static void helo_reset(SMTPD_STATE *state)
|
||||
state->helo_name = 0;
|
||||
}
|
||||
|
||||
/* mail_open_stream - open mail destination */
|
||||
/* mail_open_stream - open mail queue file or IPC stream */
|
||||
|
||||
static void mail_open_stream(SMTPD_STATE *state)
|
||||
static void mail_open_stream(SMTPD_STATE *state, SMTPD_TOKEN *argv,
|
||||
const char *encoding, const char *verp_delims)
|
||||
{
|
||||
char *postdrop_command;
|
||||
|
||||
@ -666,6 +668,45 @@ static void mail_open_stream(SMTPD_STATE *state)
|
||||
}
|
||||
state->cleanup = state->dest->stream;
|
||||
state->queue_id = mystrdup(state->dest->id);
|
||||
|
||||
/*
|
||||
* Log the queue ID with the message origin.
|
||||
*/
|
||||
#ifdef USE_SASL_AUTH
|
||||
if (var_smtpd_sasl_enable)
|
||||
smtpd_sasl_mail_log(state);
|
||||
else
|
||||
#endif
|
||||
msg_info("%s: client=%s[%s]", state->queue_id, state->name, state->addr);
|
||||
|
||||
/*
|
||||
* Record the time of arrival, the sender envelope address, some session
|
||||
* information, and some additional attributes.
|
||||
*/
|
||||
if (SMTPD_STAND_ALONE(state) == 0) {
|
||||
rec_fprintf(state->cleanup, REC_TYPE_TIME, "%ld", state->time);
|
||||
if (*var_filter_xport)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_FILT, "%s", var_filter_xport);
|
||||
}
|
||||
rec_fputs(state->cleanup, REC_TYPE_FROM, argv[2].strval);
|
||||
if (encoding != 0)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_ENCODING, encoding);
|
||||
if (SMTPD_STAND_ALONE(state) == 0) {
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_CLIENT_NAME, state->name);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_CLIENT_ADDR, state->addr);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_ORIGIN, state->namaddr);
|
||||
if (state->helo_name != 0)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_HELO_NAME, state->helo_name);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_PROTO_NAME, state->protocol);
|
||||
}
|
||||
if (verp_delims)
|
||||
rec_fputs(state->cleanup, REC_TYPE_VERP, verp_delims);
|
||||
}
|
||||
|
||||
/* extract_addr - extract address from rubble */
|
||||
@ -876,64 +917,35 @@ static int mail_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *argv)
|
||||
VERP_CMD);
|
||||
return (-1);
|
||||
}
|
||||
state->time = time((time_t *) 0);
|
||||
if (SMTPD_STAND_ALONE(state) == 0
|
||||
&& var_smtpd_delay_reject == 0
|
||||
&& (err = smtpd_check_mail(state, argv[2].strval)) != 0) {
|
||||
smtpd_chat_reply(state, "%s", err);
|
||||
return (-1);
|
||||
}
|
||||
state->time = time((time_t *) 0);
|
||||
|
||||
/*
|
||||
* Open connection to SMTP proxy server.
|
||||
*/
|
||||
if (SMTPD_STAND_ALONE(state) == 0 && *var_smtpd_proxy_filt) {
|
||||
if (smtpd_proxy_open(state, var_smtpd_proxy_filt, var_smtpd_proxy_tmout,
|
||||
var_smtpd_proxy_ehlo, STR(state->buffer)) != 0) {
|
||||
smtpd_chat_reply(state, "%s", STR(state->proxy_buffer));
|
||||
return (-1);
|
||||
}
|
||||
} else {
|
||||
}
|
||||
|
||||
/*
|
||||
* Open queue file, or open connection to queue file writing process.
|
||||
* Check for queue file space first.
|
||||
*/
|
||||
else {
|
||||
if ((err = smtpd_check_size(state, state->msg_size)) != 0) {
|
||||
smtpd_chat_reply(state, "%s", err);
|
||||
return (-1);
|
||||
}
|
||||
|
||||
/*
|
||||
* Open queue file or IPC stream.
|
||||
*/
|
||||
mail_open_stream(state);
|
||||
#ifdef USE_SASL_AUTH
|
||||
if (var_smtpd_sasl_enable)
|
||||
smtpd_sasl_mail_log(state);
|
||||
else
|
||||
#endif
|
||||
msg_info("%s: client=%s[%s]", state->queue_id, state->name, state->addr);
|
||||
|
||||
/*
|
||||
* Record the time of arrival and the sender envelope address.
|
||||
*/
|
||||
if (SMTPD_STAND_ALONE(state) == 0) {
|
||||
rec_fprintf(state->cleanup, REC_TYPE_TIME, "%ld",
|
||||
(long) time((time_t *) 0));
|
||||
if (*var_filter_xport)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_FILT, "%s", var_filter_xport);
|
||||
}
|
||||
rec_fputs(state->cleanup, REC_TYPE_FROM, argv[2].strval);
|
||||
if (encoding != 0)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_ENCODING, encoding);
|
||||
if (SMTPD_STAND_ALONE(state) == 0) {
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_CLIENT_NAME, state->name);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_CLIENT_ADDR, state->addr);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_ORIGIN, state->namaddr);
|
||||
if (state->helo_name != 0)
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_HELO_NAME, state->helo_name);
|
||||
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
|
||||
MAIL_ATTR_PROTO_NAME, state->protocol);
|
||||
}
|
||||
if (verp_delims)
|
||||
rec_fputs(state->cleanup, REC_TYPE_VERP, verp_delims);
|
||||
mail_open_stream(state, argv, encoding, verp_delims);
|
||||
}
|
||||
state->sender = mystrdup(argv[2].strval);
|
||||
smtpd_chat_reply(state, "250 Ok");
|
||||
@ -969,8 +981,14 @@ static void mail_reset(SMTPD_STATE *state)
|
||||
smtpd_sasl_mail_reset(state);
|
||||
#endif
|
||||
state->discard = 0;
|
||||
if (state->proxy)
|
||||
|
||||
/*
|
||||
* Try to be nice. Don't bother when we lost the connection.
|
||||
*/
|
||||
if (state->proxy) {
|
||||
(void) smtpd_proxy_cmd(state, SMTPD_PROX_WANT_ANY, "QUIT");
|
||||
smtpd_proxy_close(state);
|
||||
}
|
||||
}
|
||||
|
||||
/* rcpt_cmd - process RCPT TO command */
|
||||
@ -1030,7 +1048,7 @@ static int rcpt_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *argv)
|
||||
return (-1);
|
||||
}
|
||||
}
|
||||
if (state->proxy && smtpd_proxy_cmd(state, SMTPD_PROX_STAT_OK,
|
||||
if (state->proxy && smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK,
|
||||
"%s", STR(state->buffer)) != 0) {
|
||||
smtpd_chat_reply(state, "%s", STR(state->proxy_buffer));
|
||||
return (-1);
|
||||
@ -1099,7 +1117,7 @@ static int data_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *unused_argv)
|
||||
smtpd_chat_reply(state, "%s", err);
|
||||
return (-1);
|
||||
}
|
||||
if (state->proxy && smtpd_proxy_cmd(state, SMTPD_PROX_STAT_MORE,
|
||||
if (state->proxy && smtpd_proxy_cmd(state, SMTPD_PROX_WANT_MORE,
|
||||
"%s", STR(state->buffer)) != 0) {
|
||||
smtpd_chat_reply(state, "%s", STR(state->proxy_buffer));
|
||||
return (-1);
|
||||
@ -1196,25 +1214,32 @@ static int data_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *unused_argv)
|
||||
}
|
||||
|
||||
/*
|
||||
* Send the end-of-segment markers.
|
||||
* Send the end of DATA and finish the proxy connection. Set the
|
||||
* CLEANUP_STAT_PROXY error flag in case of trouble.
|
||||
*/
|
||||
if (state->proxy) {
|
||||
if (state->err == CLEANUP_STAT_OK)
|
||||
(void) smtpd_proxy_cmd(state, SMTPD_PROX_STAT_ANY, ".");
|
||||
if (state->err == CLEANUP_STAT_OK) {
|
||||
(void) smtpd_proxy_cmd(state, SMTPD_PROX_WANT_ANY, ".");
|
||||
if (*STR(state->proxy_buffer) != '2')
|
||||
state->err = CLEANUP_STAT_PROXY;
|
||||
}
|
||||
smtpd_proxy_close(state);
|
||||
} else {
|
||||
}
|
||||
|
||||
/*
|
||||
* Send the end-of-segment markers and finish the queue file record
|
||||
* stream.
|
||||
*/
|
||||
else {
|
||||
if (state->err == CLEANUP_STAT_OK)
|
||||
if (rec_fputs(state->cleanup, REC_TYPE_XTRA, "") < 0
|
||||
|| rec_fputs(state->cleanup, REC_TYPE_END, "") < 0
|
||||
|| vstream_fflush(state->cleanup))
|
||||
state->err = CLEANUP_STAT_WRITE;
|
||||
|
||||
/*
|
||||
* Finish the queue file or finish the cleanup conversation.
|
||||
*/
|
||||
if (state->err == 0)
|
||||
state->err = mail_stream_finish(state->dest, why = vstring_alloc(10));
|
||||
else
|
||||
if (state->err == 0) {
|
||||
why = vstring_alloc(10);
|
||||
state->err = mail_stream_finish(state->dest, why);
|
||||
} else
|
||||
mail_stream_cleanup(state->dest);
|
||||
state->dest = 0;
|
||||
state->cleanup = 0;
|
||||
@ -1253,7 +1278,7 @@ static int data_cmd(SMTPD_STATE *state, int argc, SMTPD_TOKEN *unused_argv)
|
||||
smtpd_chat_reply(state, "451 Error: queue file write error");
|
||||
} else if ((state->err & CLEANUP_STAT_PROXY) != 0) {
|
||||
state->error_mask |= MAIL_ERROR_SOFTWARE;
|
||||
smtpd_chat_reply(state, "451 Error: queue file write error");
|
||||
smtpd_chat_reply(state, "%s", STR(state->proxy_buffer));
|
||||
} else {
|
||||
state->error_mask |= MAIL_ERROR_SOFTWARE;
|
||||
smtpd_chat_reply(state, "451 Error: internal error %d", state->err);
|
||||
@ -1622,8 +1647,8 @@ static void smtpd_proto(SMTPD_STATE *state)
|
||||
continue;
|
||||
}
|
||||
if (cmdp->flags & SMTPD_CMD_FLAG_FORBIDDEN) {
|
||||
msg_warn("%s sent %s instead of SMTP command: %.100s",
|
||||
state->namaddr, cmdp->name, vstring_str(state->buffer));
|
||||
msg_warn("%s sent non-SMTP command: %.100s",
|
||||
state->namaddr, vstring_str(state->buffer));
|
||||
smtpd_chat_reply(state, "221 Error: I can break rules, too. Goodbye.");
|
||||
break;
|
||||
}
|
||||
|
||||
@ -2591,7 +2591,7 @@ static int reject_maps_rbl(SMTPD_STATE *state)
|
||||
if (warned == 0) {
|
||||
warned++;
|
||||
msg_warn("support for restriction \"%s\" will be removed from %s; "
|
||||
"use \"%s <domain-name>\" instead",
|
||||
"use \"%s domain-name\" instead",
|
||||
REJECT_MAPS_RBL, var_mail_name, REJECT_RBL_CLIENT);
|
||||
}
|
||||
while ((rbl_domain = mystrtok(&bp, " \t\r\n,")) != 0) {
|
||||
@ -3599,6 +3599,7 @@ static STRING_TABLE string_table[] = {
|
||||
VAR_DEF_RBL_REPLY, DEF_DEF_RBL_REPLY, &var_def_rbl_reply,
|
||||
VAR_RELAY_RCPT_MAPS, DEF_RELAY_RCPT_MAPS, &var_relay_rcpt_maps,
|
||||
VAR_VERIFY_SENDER, DEF_VERIFY_SENDER, &var_verify_sender,
|
||||
VAR_MAIL_NAME, DEF_MAIL_NAME, &var_mail_name,
|
||||
0,
|
||||
};
|
||||
|
||||
|
||||
@ -139,7 +139,7 @@ OK
|
||||
>>> client foo 123.123.123.123
|
||||
OK
|
||||
>>> rcpt foo@watson.ibm.com
|
||||
./smtpd_check: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
|
||||
./smtpd_check: warning: support for restriction "check_relay_domains" will be removed from Postfix; use "reject_unauth_destination" instead
|
||||
./smtpd_check: <queue id>: reject: RCPT from foo[123.123.123.123]: 554 <foo@watson.ibm.com>: Recipient address rejected: Relay access denied; from=<foo@friend.bad.domain> to=<foo@watson.ibm.com> proto=SMTP helo=<123.123.123.123>
|
||||
554 <foo@watson.ibm.com>: Recipient address rejected: Relay access denied
|
||||
>>> rcpt foo@porcupine.org
|
||||
@ -183,7 +183,7 @@ OK
|
||||
>>> client_restrictions reject_maps_rbl
|
||||
OK
|
||||
>>> client spike.porcupine.org 168.100.189.2
|
||||
./smtpd_check: warning: restriction reject_maps_rbl is going away. Please use reject_rbl_client <domain> instead
|
||||
./smtpd_check: warning: support for restriction "reject_maps_rbl" will be removed from Postfix; use "reject_rbl_client domain-name" instead
|
||||
OK
|
||||
>>> client foo 127.0.0.2
|
||||
./smtpd_check: <queue id>: reject: CONNECT from foo[127.0.0.2]: 554 Service unavailable; Client host [127.0.0.2] blocked using relays.mail-abuse.org; from=<foo@friend.bad.domain> proto=SMTP helo=<123.123.123.123>
|
||||
|
||||
@ -129,7 +129,7 @@ OK
|
||||
>>> client foo 123.123.123.123
|
||||
OK
|
||||
>>> rcpt foo@watson.ibm.com
|
||||
./smtpd_check: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
|
||||
./smtpd_check: warning: support for restriction "check_relay_domains" will be removed from Postfix; use "reject_unauth_destination" instead
|
||||
./smtpd_check: <queue id>: reject: RCPT from foo[123.123.123.123]: 554 <foo@watson.ibm.com>: Recipient address rejected: Relay access denied; from=<foo@friend.bad.domain> to=<foo@watson.ibm.com> proto=SMTP helo=<friend.bad.domain>
|
||||
554 <foo@watson.ibm.com>: Recipient address rejected: Relay access denied
|
||||
>>> rcpt foo@porcupine.org
|
||||
@ -173,7 +173,7 @@ OK
|
||||
>>> client_restrictions reject_maps_rbl
|
||||
OK
|
||||
>>> client spike.porcupine.org 168.100.189.2
|
||||
./smtpd_check: warning: restriction reject_maps_rbl is going away. Please use reject_rbl_client <domain> instead
|
||||
./smtpd_check: warning: support for restriction "reject_maps_rbl" will be removed from Postfix; use "reject_rbl_client domain-name" instead
|
||||
OK
|
||||
>>> client foo 127.0.0.2
|
||||
./smtpd_check: <queue id>: reject: CONNECT from foo[127.0.0.2]: 554 Service unavailable; Client host [127.0.0.2] blocked using relays.mail-abuse.org; from=<foo@friend.bad.domain> proto=SMTP helo=<friend.bad.domain>
|
||||
|
||||
@ -25,7 +25,7 @@ OK
|
||||
>>> client spike.porcupine.org 168.100.189.2
|
||||
OK
|
||||
>>> rcpt rname@rdomain
|
||||
./smtpd_check: warning: restriction reject_maps_rbl is going away. Please use reject_rbl_client <domain> instead
|
||||
./smtpd_check: warning: support for restriction "reject_maps_rbl" will be removed from Postfix; use "reject_rbl_client domain-name" instead
|
||||
OK
|
||||
>>> client foo 127.0.0.2
|
||||
OK
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
/* /* other fields... */
|
||||
/* .in -4
|
||||
/* } SMTPD_STATE;
|
||||
/*
|
||||
/* SMTP-LEVEL ROUTINES
|
||||
/* int smtpd_proxy_open(state, service, timeout, ehlo_name, mail_from)
|
||||
/* SMTPD_STATE *state;
|
||||
/* const char *service;
|
||||
@ -28,7 +28,7 @@
|
||||
/* int expect;
|
||||
/* cont char *format;
|
||||
/*
|
||||
/* void smtpd_proxy_open(state)
|
||||
/* void smtpd_proxy_close(state)
|
||||
/* SMTPD_STATE *state;
|
||||
/* RECORD-LEVEL ROUTINES
|
||||
/* int smtpd_proxy_rec_put(stream, rec_type, data, len)
|
||||
@ -100,16 +100,12 @@
|
||||
/* Expected proxy server reply status code range. A warning is logged
|
||||
/* when an unexpected reply is received. Specify one of the following:
|
||||
/* .RS
|
||||
/* .IP SMTPD_PROX_STAT_ANY
|
||||
/* .IP SMTPD_PROX_WANT_ANY
|
||||
/* The caller has no expectation. Do not warn for unexpected replies.
|
||||
/* .IP SMTPD_PROX_STAT_OK
|
||||
/* .IP SMTPD_PROX_WANT_OK
|
||||
/* The caller expects a reply in the 200 range.
|
||||
/* .IP SMTPD_PROX_STAT_MORE
|
||||
/* .IP SMTPD_PROX_WANT_MORE
|
||||
/* The caller expects a reply in the 300 range.
|
||||
/* .IP SMTPD_PROX_STAT_DEFER
|
||||
/* .IP SMTPD_PROX_STAT_FAIL
|
||||
/* The caller perversely expects a reply in the 400 and 500 range,
|
||||
/* respectively.
|
||||
/* .RE
|
||||
/* .IP format
|
||||
/* A format string.
|
||||
@ -168,6 +164,7 @@
|
||||
*/
|
||||
#define STR(x) vstring_str(x)
|
||||
#define LEN(x) VSTRING_LEN(x)
|
||||
#define SMTPD_PROXY_CONNECT ((char *) 0)
|
||||
|
||||
/* smtpd_proxy_open - open proxy connection after MAIL FROM */
|
||||
|
||||
@ -202,10 +199,10 @@ int smtpd_proxy_open(SMTPD_STATE *state, const char *service,
|
||||
/*
|
||||
* Get server greeting banner.
|
||||
*
|
||||
* XXX If this fails then we should not send the initial reply when the
|
||||
* client expects the MAIL FROM reply.
|
||||
* If this fails then we have a problem because the proxy should always
|
||||
* accept our connection.
|
||||
*/
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_STAT_OK, (char *) 0) != 0) {
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, SMTPD_PROXY_CONNECT) != 0) {
|
||||
vstring_sprintf(state->proxy_buffer,
|
||||
"451 Error: queue file write error");
|
||||
smtpd_proxy_close(state);
|
||||
@ -215,10 +212,10 @@ int smtpd_proxy_open(SMTPD_STATE *state, const char *service,
|
||||
/*
|
||||
* Send our own EHLO command.
|
||||
*
|
||||
* XXX If this fails then we should not send the EHLO reply when the client
|
||||
* expects the MAIL FROM reply.
|
||||
* If this fails then we have a problem because the proxy should always
|
||||
* accept our EHLO command.
|
||||
*/
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_STAT_OK, "EHLO %s", ehlo_name) != 0) {
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "EHLO %s", ehlo_name) != 0) {
|
||||
vstring_sprintf(state->proxy_buffer,
|
||||
"451 Error: queue file write error");
|
||||
smtpd_proxy_close(state);
|
||||
@ -226,9 +223,11 @@ int smtpd_proxy_open(SMTPD_STATE *state, const char *service,
|
||||
}
|
||||
|
||||
/*
|
||||
* Pass-through the client's MAIL FROM command.
|
||||
* Pass-through the client's MAIL FROM command. If this fails, then we
|
||||
* have a problem because the proxy should always accept any MAIL FROM
|
||||
* command that was accepted by us.
|
||||
*/
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_STAT_OK, "%s", mail_from) != 0) {
|
||||
if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "%s", mail_from) != 0) {
|
||||
smtpd_proxy_close(state);
|
||||
return (-1);
|
||||
}
|
||||
@ -265,7 +264,8 @@ static void smtpd_proxy_cmd_error(SMTPD_STATE *state, const char *fmt,
|
||||
* because it is used only internally to this module.
|
||||
*/
|
||||
buf = vstring_alloc(100);
|
||||
vstring_vsprintf(buf, fmt && *fmt ? fmt : "connection request", ap);
|
||||
vstring_vsprintf(buf, fmt == SMTPD_PROXY_CONNECT ?
|
||||
"connection request" : fmt, ap);
|
||||
msg_warn("proxy %s rejected \"%s\": \"%s\"", VSTREAM_PATH(state->proxy),
|
||||
STR(buf), STR(state->proxy_buffer));
|
||||
vstring_free(buf);
|
||||
@ -296,11 +296,11 @@ int smtpd_proxy_cmd(SMTPD_STATE *state, int expect, const char *fmt,...)
|
||||
}
|
||||
|
||||
/*
|
||||
* The command can be omitted at the start of an SMTP session. A null
|
||||
* format string is not documented as part of the official interface
|
||||
* because it is used only internally to this module.
|
||||
* The command can be omitted at the start of an SMTP session. This is
|
||||
* not documented as part of the official interface because it is used
|
||||
* only internally to this module.
|
||||
*/
|
||||
if (fmt && *fmt) {
|
||||
if (fmt != SMTPD_PROXY_CONNECT) {
|
||||
|
||||
/*
|
||||
* Format the command.
|
||||
@ -362,7 +362,7 @@ int smtpd_proxy_cmd(SMTPD_STATE *state, int expect, const char *fmt,...)
|
||||
* Log a warning in case the proxy does not send the expected response.
|
||||
* Silently accept any response when the client expressed no expectation.
|
||||
*/
|
||||
if (expect != SMTPD_PROX_STAT_ANY
|
||||
if (expect != SMTPD_PROX_WANT_ANY
|
||||
&& expect != (STR(state->proxy_buffer)[0] - '0')) {
|
||||
va_start(ap, fmt);
|
||||
smtpd_proxy_cmd_error(state, fmt, ap);
|
||||
@ -394,8 +394,10 @@ int smtpd_proxy_rec_put(VSTREAM *stream, int rec_type,
|
||||
*/
|
||||
if (rec_type == REC_TYPE_NORM)
|
||||
smtp_fputs(data, len, stream);
|
||||
else
|
||||
else if (rec_type == REC_TYPE_CONT)
|
||||
smtp_fwrite(data, len, stream);
|
||||
else
|
||||
msg_panic("smtpd_proxy_rec_put: need REC_TYPE_NORM or REC_TYPE_CONT");
|
||||
return (rec_type);
|
||||
}
|
||||
|
||||
@ -421,9 +423,10 @@ int smtpd_proxy_rec_fprintf(VSTREAM *stream, int rec_type,
|
||||
* rec_fprintf().
|
||||
*/
|
||||
va_start(ap, fmt);
|
||||
if (rec_type != REC_TYPE_NORM)
|
||||
if (rec_type == REC_TYPE_NORM)
|
||||
smtp_vprintf(stream, fmt, ap);
|
||||
else
|
||||
msg_panic("smtpd_proxy_rec_fprintf: need REC_TYPE_NORM");
|
||||
smtp_vprintf(stream, fmt, ap);
|
||||
va_end(ap);
|
||||
return (rec_type);
|
||||
}
|
||||
|
||||
@ -18,11 +18,9 @@
|
||||
/*
|
||||
* Application-specific.
|
||||
*/
|
||||
#define SMTPD_PROX_STAT_ANY 0
|
||||
#define SMTPD_PROX_STAT_OK 2
|
||||
#define SMTPD_PROX_STAT_MORE 3
|
||||
#define SMTPD_PROX_STAT_DEFER 4
|
||||
#define SMTPD_PROX_STAT_FAIL 5
|
||||
#define SMTPD_PROX_WANT_ANY 0
|
||||
#define SMTPD_PROX_WANT_OK 2
|
||||
#define SMTPD_PROX_WANT_MORE 3
|
||||
|
||||
extern int smtpd_proxy_open(SMTPD_STATE *, const char *, int, const char *, const char *);
|
||||
extern int smtpd_proxy_cmd(SMTPD_STATE *, int, const char *,...);
|
||||
|
||||
@ -58,10 +58,12 @@ extern DICT *dict_debug(DICT *);
|
||||
#define DICT_FLAG_SYNC_UPDATE (1<<8) /* if file, sync updates */
|
||||
#define DICT_FLAG_DEBUG (1<<9) /* log access */
|
||||
#define DICT_FLAG_FOLD_KEY (1<<10) /* lowercase the lookup key */
|
||||
#define DICT_FLAG_NO_REGSUB (1<<11) /* no lhs->rhs regexp substitution */
|
||||
#define DICT_FLAG_NO_PROXY (1<<12) /* no proxy mapping */
|
||||
#define DICT_FLAG_NO_REGSUB (1<<11) /* disallow regexp substitution */
|
||||
#define DICT_FLAG_NO_PROXY (1<<12) /* disallow proxy mapping */
|
||||
#define DICT_FLAG_NO_UNAUTH (1<<13) /* disallow unauthenticated data */
|
||||
|
||||
#define DICT_FLAG_PARANOID (DICT_FLAG_NO_REGSUB | DICT_FLAG_NO_PROXY)
|
||||
#define DICT_FLAG_PARANOID \
|
||||
(DICT_FLAG_NO_REGSUB | DICT_FLAG_NO_PROXY | DICT_FLAG_NO_UNAUTH)
|
||||
|
||||
extern int dict_unknown_allowed;
|
||||
extern int dict_errno;
|
||||
|
||||
@ -6,9 +6,9 @@
|
||||
/* SYNOPSIS
|
||||
/* #include <dict_cidr.h>
|
||||
/*
|
||||
/* DICT *dict_cidr_open(name, dummy, dict_flags)
|
||||
/* DICT *dict_cidr_open(name, open_flags, dict_flags)
|
||||
/* const char *name;
|
||||
/* int dummy;
|
||||
/* int open_flags;
|
||||
/* int dict_flags;
|
||||
/* DESCRIPTION
|
||||
/* dict_cidr_open() opens the named file and stores
|
||||
@ -127,9 +127,9 @@ static DICT_CIDR_ENTRY *dict_cidr_parse_rule(const char *mapname, int lineno,
|
||||
struct in_addr net_addr;
|
||||
|
||||
/*
|
||||
* Split into key and value. We already eliminated leading whitespace,
|
||||
* comments, empty lines or lines with whitespace only. This means a null
|
||||
* key can't happen but we will handle this anyway.
|
||||
* Split the rule into key and value. We already eliminated leading
|
||||
* whitespace, comments, empty lines or lines with whitespace only. This
|
||||
* means a null key can't happen but we will handle this anyway.
|
||||
*/
|
||||
key = p;
|
||||
while (*p && !ISSPACE(*p)) /* Skip over key */
|
||||
@ -182,6 +182,9 @@ static DICT_CIDR_ENTRY *dict_cidr_parse_rule(const char *mapname, int lineno,
|
||||
mask_bits = htonl(0xffffffff);
|
||||
}
|
||||
|
||||
/*
|
||||
* Bundle up the result.
|
||||
*/
|
||||
rule = (DICT_CIDR_ENTRY *) mymalloc(sizeof(DICT_CIDR_ENTRY));
|
||||
rule->net_bits = net_bits;
|
||||
rule->mask_bits = mask_bits;
|
||||
@ -197,7 +200,7 @@ static DICT_CIDR_ENTRY *dict_cidr_parse_rule(const char *mapname, int lineno,
|
||||
|
||||
/* dict_cidr_open - parse CIDR table */
|
||||
|
||||
DICT *dict_cidr_open(const char *mapname, int unused_flags, int dict_flags)
|
||||
DICT *dict_cidr_open(const char *mapname, int open_flags, int dict_flags)
|
||||
{
|
||||
DICT_CIDR *dict_cidr;
|
||||
VSTREAM *map_fp;
|
||||
@ -206,6 +209,13 @@ DICT *dict_cidr_open(const char *mapname, int unused_flags, int dict_flags)
|
||||
DICT_CIDR_ENTRY *last_rule = 0;
|
||||
int lineno = 0;
|
||||
|
||||
/*
|
||||
* Sanity checks.
|
||||
*/
|
||||
if (open_flags != O_RDONLY)
|
||||
msg_fatal("%s:%s map requires O_RDONLY access mode",
|
||||
DICT_TYPE_CIDR, mapname);
|
||||
|
||||
/*
|
||||
* XXX Eliminate unnecessary queries by setting a flag that says "this
|
||||
* map matches network addresses only".
|
||||
|
||||
@ -6,14 +6,13 @@
|
||||
/* SYNOPSIS
|
||||
/* #include <dict_nis.h>
|
||||
/*
|
||||
/* DICT *dict_nis_open(map, dummy, dict_flags)
|
||||
/* DICT *dict_nis_open(map, open_flags, dict_flags)
|
||||
/* const char *map;
|
||||
/* int dummy;
|
||||
/* int open_flags;
|
||||
/* int dict_flags;
|
||||
/* DESCRIPTION
|
||||
/* dict_nis_open() makes the specified NIS map accessible via
|
||||
/* the generic dictionary operations described in dict_open(3).
|
||||
/* The \fIdummy\fR argument is not used.
|
||||
/* SEE ALSO
|
||||
/* dict(3) generic dictionary manager
|
||||
/* DIAGNOSTICS
|
||||
@ -204,10 +203,14 @@ static void dict_nis_close(DICT *dict)
|
||||
|
||||
/* dict_nis_open - open NIS map */
|
||||
|
||||
DICT *dict_nis_open(const char *map, int unused_flags, int dict_flags)
|
||||
DICT *dict_nis_open(const char *map, int open_flags, int dict_flags)
|
||||
{
|
||||
DICT_NIS *dict_nis;
|
||||
|
||||
if (open_flags != O_RDONLY)
|
||||
msg_fatal("%s:%s map requires O_RDONLY access mode",
|
||||
DICT_TYPE_NIS, map);
|
||||
|
||||
dict_nis = (DICT_NIS *) dict_alloc(DICT_TYPE_NIS, map, sizeof(*dict_nis));
|
||||
dict_nis->dict.lookup = dict_nis_lookup;
|
||||
dict_nis->dict.close = dict_nis_close;
|
||||
@ -216,7 +219,7 @@ DICT *dict_nis_open(const char *map, int unused_flags, int dict_flags)
|
||||
dict_nis->dict.flags |= (DICT_FLAG_TRY1NULL | DICT_FLAG_TRY0NULL);
|
||||
if (dict_nis_domain == 0)
|
||||
dict_nis_init();
|
||||
return (DICT_DEBUG(&dict_nis->dict));
|
||||
return (DICT_DEBUG (&dict_nis->dict));
|
||||
}
|
||||
|
||||
#endif
|
||||
|
||||
@ -19,3 +19,4 @@ if !/xyzzy/
|
||||
endif
|
||||
endif
|
||||
# trailing whitespace above
|
||||
!
|
||||
|
||||
@ -3,6 +3,7 @@
|
||||
./dict_open: warning: pcre map dict_pcre.map, line 8: unknown regexp option "!": skipping this rule
|
||||
./dict_open: warning: dict_pcre.map, line 9: no replacement text: using empty string
|
||||
./dict_open: warning: pcre map dict_pcre.map, line 17: $number found in negative match replacement text: skipping this rule
|
||||
./dict_open: warning: pcre map dict_pcre.map, line 22: no regexp: skipping this rule
|
||||
true: not found
|
||||
true1=1
|
||||
true2: not found
|
||||
|
||||
@ -19,3 +19,4 @@ if !/xyzzy/
|
||||
endif
|
||||
endif
|
||||
# trailing whitespace above
|
||||
!
|
||||
|
||||
@ -3,6 +3,7 @@
|
||||
./dict_open: warning: regexp map dict_regexp.map, line 9: using empty replacement string
|
||||
./dict_open: warning: regexp map dict_regexp.map, line 10: out of range replacement index "5": skipping this rule
|
||||
./dict_open: warning: regexp map dict_regexp.map, line 17: $number found in negative match replacement text: skipping this rule
|
||||
./dict_open: warning: regexp map dict_regexp.map, line 22: no regexp: skipping this rule
|
||||
true: not found
|
||||
true1=1
|
||||
true2: not found
|
||||
|
||||
@ -6,16 +6,15 @@
|
||||
/* SYNOPSIS
|
||||
/* #include <dict_tcp.h>
|
||||
/*
|
||||
/* DICT *dict_tcp_open(map, dummy, dict_flags)
|
||||
/* DICT *dict_tcp_open(map, open_flags, dict_flags)
|
||||
/* const char *map;
|
||||
/* int dummy;
|
||||
/* int open_flags;
|
||||
/* int dict_flags;
|
||||
/* DESCRIPTION
|
||||
/* dict_tcp_open() makes a TCP server accessible via the generic
|
||||
/* dictionary operations described in dict_open(3).
|
||||
/* The \fIdummy\fR argument is not used. The only implemented
|
||||
/* operation is dictionary lookup. This map type can be useful
|
||||
/* for simulating a dynamic lookup table.
|
||||
/* The only implemented operation is dictionary lookup. This map
|
||||
/* type can be useful for simulating a dynamic lookup table.
|
||||
/*
|
||||
/* Map names have the form host:port.
|
||||
/*
|
||||
@ -45,16 +44,19 @@
|
||||
/* .fi
|
||||
/* Replies must be no longer than 4096 characters including the
|
||||
/* newline terminator, and must have the following form:
|
||||
/* .IP "500 SPACE optional-text NEWLINE"
|
||||
/* .IP "500 SPACE text NEWLINE"
|
||||
/* In case of a lookup request, the requested data does not exist.
|
||||
/* In case of an update request, the request was rejected.
|
||||
/* .IP "400 SPACE optional-text NEWLINE"
|
||||
/* The text gives the nature of the problem.
|
||||
/* .IP "400 SPACE text NEWLINE"
|
||||
/* This indicates an error condition. The text gives the nature of
|
||||
/* the problem. The client should retry the request later.
|
||||
/* .IP "200 SPACE text NEWLINE"
|
||||
/* The request was successful. In the case of a lookup request,
|
||||
/* the text contains an encoded version of the requested data.
|
||||
/* Otherwise the text is optional.
|
||||
/* SECURITY
|
||||
/* This map must not be used for security sensitive information,
|
||||
/* because neither the connection nor the server are authenticated.
|
||||
/* SEE ALSO
|
||||
/* dict(3) generic dictionary manager
|
||||
/* hex_quote(3) http-style quoting
|
||||
@ -177,7 +179,7 @@ static const char *dict_tcp_lookup(DICT *dict, const char *key)
|
||||
hex_quote(dict_tcp->hex_buf, key);
|
||||
vstream_fprintf(dict_tcp->fp, "get %s\n", STR(dict_tcp->hex_buf));
|
||||
if (msg_verbose)
|
||||
msg_info("%s: send \"get %s\"", myname, STR(dict_tcp->hex_buf));
|
||||
msg_info("%s: send: get %s", myname, STR(dict_tcp->hex_buf));
|
||||
last_ch = vstring_get_nonl_bound(dict_tcp->hex_buf, dict_tcp->fp,
|
||||
DICT_TCP_MAXLEN);
|
||||
if (last_ch == '\n')
|
||||
@ -207,7 +209,7 @@ static const char *dict_tcp_lookup(DICT *dict, const char *key)
|
||||
sleep(1);
|
||||
}
|
||||
if (msg_verbose)
|
||||
msg_info("%s: recv: \"%s\"", myname, STR(dict_tcp->hex_buf));
|
||||
msg_info("%s: recv: %s", myname, STR(dict_tcp->hex_buf));
|
||||
|
||||
/*
|
||||
* Check the general reply syntax. If the reply is malformed, disconnect
|
||||
@ -217,7 +219,7 @@ static const char *dict_tcp_lookup(DICT *dict, const char *key)
|
||||
!ISDIGIT(start[0]) || !ISDIGIT(start[1])
|
||||
|| !ISDIGIT(start[2]) || !ISSPACE(start[3])
|
||||
|| !hex_unquote(dict_tcp->raw_buf, start + 4)) {
|
||||
msg_warn("read TCP map reply from %s: malformed reply %.100s",
|
||||
msg_warn("read TCP map reply from %s: malformed reply: %.100s",
|
||||
dict_tcp->dict.name, printable(STR(dict_tcp->hex_buf), '_'));
|
||||
dict_tcp_disconnect(dict_tcp);
|
||||
RETURN(DICT_ERR_RETRY, 0);
|
||||
@ -229,20 +231,20 @@ static const char *dict_tcp_lookup(DICT *dict, const char *key)
|
||||
*/
|
||||
switch (start[0]) {
|
||||
default:
|
||||
msg_warn("read TCP map reply from %s: bad status code %.100s",
|
||||
msg_warn("read TCP map reply from %s: bad status code: %.100s",
|
||||
dict_tcp->dict.name, printable(STR(dict_tcp->hex_buf), '_'));
|
||||
dict_tcp_disconnect(dict_tcp);
|
||||
RETURN(DICT_ERR_RETRY, 0);
|
||||
case '4':
|
||||
if (msg_verbose)
|
||||
msg_info("%s: soft error: %s",
|
||||
myname, printable(STR(dict_tcp->raw_buf), '_'));
|
||||
myname, printable(STR(dict_tcp->hex_buf), '_'));
|
||||
dict_tcp_disconnect(dict_tcp);
|
||||
RETURN(DICT_ERR_RETRY, 0);
|
||||
case '5':
|
||||
if (msg_verbose)
|
||||
msg_info("%s: not found: %s",
|
||||
myname, printable(STR(dict_tcp->raw_buf), '_'));
|
||||
myname, printable(STR(dict_tcp->hex_buf), '_'));
|
||||
RETURN(DICT_ERR_NONE, 0);
|
||||
case '2':
|
||||
if (msg_verbose)
|
||||
@ -269,17 +271,32 @@ static void dict_tcp_close(DICT *dict)
|
||||
|
||||
/* dict_tcp_open - open TCP map */
|
||||
|
||||
DICT *dict_tcp_open(const char *map, int unused_flags, int dict_flags)
|
||||
DICT *dict_tcp_open(const char *map, int open_flags, int dict_flags)
|
||||
{
|
||||
DICT_TCP *dict_tcp;
|
||||
|
||||
dict_errno = 0;
|
||||
|
||||
/*
|
||||
* Sanity checks.
|
||||
*/
|
||||
if (dict_flags & DICT_FLAG_NO_UNAUTH)
|
||||
msg_fatal("%s:%s map is not allowed for security sensitive data",
|
||||
DICT_TYPE_TCP, map);
|
||||
if (open_flags != O_RDONLY)
|
||||
msg_fatal("%s:%s map requires O_RDONLY access mode",
|
||||
DICT_TYPE_TCP, map);
|
||||
|
||||
/*
|
||||
* Create the dictionary handle. Do not open the connection until the
|
||||
* first request is made.
|
||||
*/
|
||||
dict_tcp = (DICT_TCP *) dict_alloc(DICT_TYPE_TCP, map, sizeof(*dict_tcp));
|
||||
dict_tcp->fp = 0;
|
||||
dict_tcp->raw_buf = dict_tcp->hex_buf = 0;
|
||||
dict_tcp->dict.lookup = dict_tcp_lookup;
|
||||
dict_tcp->dict.close = dict_tcp_close;
|
||||
dict_tcp->dict.flags = dict_flags | DICT_FLAG_FIXED;
|
||||
dict_tcp->dict.flags = dict_flags | DICT_FLAG_PATTERN;
|
||||
|
||||
return (DICT_DEBUG (&dict_tcp->dict));
|
||||
}
|
||||
|
||||
@ -105,7 +105,6 @@ static ARGV *match_list_parse(ARGV *list, char *string)
|
||||
char *delim = " ,\t\r\n";
|
||||
char *bp = string;
|
||||
char *pattern;
|
||||
char *cp;
|
||||
char *map_type_name;
|
||||
char *map_type_name_flags;
|
||||
|
||||
|
||||
@ -29,8 +29,7 @@
|
||||
/* .IP "\fBVRFY_ADDR_UPDATE\fI address status text\fR"
|
||||
/* Update the status of the specified address.
|
||||
/* .IP "\fBVRFY_ADDR_QUERY\fI address\fR"
|
||||
/* Look up the \fIstatus\fR, \fIlast update time\fR and \fItext\fR
|
||||
/* of the specified address.
|
||||
/* Look up the \fIstatus\fR and \fItext\fR of the specified address.
|
||||
/* If the status is unknown, a probe is sent and a default status is
|
||||
/* returned.
|
||||
/* .PP
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user