Mailfromd |
|
General-Purpose Mail Filter |
Sergey Poznyakoff |
Mailfromd Manual (split by node): | ? |
Depending on its operation mode, mailfromd
tries to guess
whether it is appropriate to print its diagnostics and informational
messages on standard error or to send them to syslog. By default
standard error is used if the program is given one of the database
management options (see section Databases, or ‘--test’ option
(see section Testing Filter Scripts. Otherwise, syslog is used. To alter
these defaults, two command line options are provided:
‘--stderr’ to print everything to standard error and
‘--syslog’ to output all diagnostics to syslog.
The data can be sent to syslog using two ways: the syslog
function from the system ‘libc’ library, which is a blocking
implementation in most cases, and the internal, asynchronous,
syslog implementation. See Using non-blocking syslog,
for more information on these implementations and for information on
how to select the default one. Two options are provided to select the
implementation to use at run time: the ‘--syslog-async’ option
instructs mailfromd
to use asynchronous version, and the
‘--no-syslog-async’ option instructs it to use the blocking
version.
The default syslog facility is ‘mail’, and it can be changed with the ‘--log-facility’ option. Argument to this option is a valid syslog facility name, i.e. one of: ‘user’, ‘daemon’, ‘auth’, ‘authpriv’(11), ‘mail’, and ‘local0’ through ‘local7’. The argument can be given in upper, lower or mixed cases, and it can be prefixed with ‘log_’
Another syslog-related parameter that can be configured is the
tag used to identify mailfromd
messages. By default the
program name is used. The ‘--log-tag’ option can
be used to change it.
As all UNIX utilities, mailfromd
is very quiet unless it
has something important to communicate, for example an error condition
or something similar. A set of command line options is provided for
controlling the verbosity of its output.
The ‘--trace’ option enables tracing the Sendmail actions
executed during the message verification. When this option is given,
any accept
, discard
, continue
, etc. triggered
during the execution of your filter program will leave their traces in
the log file. Here is an example of how it looks like (syslog time
stamp, tag and PID removed for readability):
k8DHxvO9030656: /etc/mailfromd.mf:45: reject 550 5.1.1 Sender validity not confirmed |
This shows that while verifying the message with ID
‘k8DHxvO9030656’ the reject
action was executed by filter
script ‘/etc/mailfromd.mf’ at line 45.
The appearance of the message ID in the log deserves a special
notice. The program will always identify its log messages with
the ‘Message-Id’, when it is available. Your responsibility as an
administrator is to make sure it is available by configuring
your MTA to export the macro ‘i’ to mailfromd
.
The rule of thumb is: make ‘i’ available to the very first
handler mailfromd
executes. It is not necessary to export
it to the rest of the handlers, since mailfromd
will cache
it. For example, if your filter script contains ‘envfrom’ and
‘envrcpt’ handlers, export ‘i’ for ‘envfrom’.
The exact instructions on how to ensure it depend on the
MTA. For ‘Sendmail’, refer to Using mailfromd
with Sendmail..
To push the log verbosity further, use the debug
configuration statement (see section Logging and Debugging configuration) or its command line
equivalent, ‘--debug’ (‘-d’, see –debug). It takes
a numeric argument specifying the relative verbosity level in the
range between 0 and 100. Zero means disabling verbose output, while
100 produces impractically verbose output, suitable only for the
developers of mailfromd
.
There is a more sophisticated form of the ‘--debug’ option,
that allows to set debugging levels individually for a set of
source modules. In this form, the argument to the option
consists of a comma-separated list of debug specifications, each
of which has the following form: source[=level]
.
Here, source is the mailfromd
source name, without the
suffix, and optional level is the debugging level (an integer
between 0 and 100), that you wish to assign to this module. The
default level is 100.
For example, the following invocation sets the global debugging level to 1, the level for functions from ‘prog.c’ to 10, and for ‘engine.c’ to 100:
$ mailfromd --debug=100,prog=10,engine |
You need to have sufficient knowledge about mailfromd
internal structure to use this form of the ‘--debug’ option.
To control the execution of the sender verification functions (see section Polling Functions), you may use ‘--transcript’ (‘-X’) command line option which enables the transcript of SMTP sessions in the logs. Here is an example of the output produced running mailfromd --debug=1 --transcript:
k8DHxlCa001774: RECV: 220 spf-jail1.us4.outblaze.com ESMTP Postfix k8DHxlCa001774: SEND: HELO mail.gnu.org.ua k8DHxlCa001774: RECV: 250 spf-jail1.us4.outblaze.com k8DHxlCa001774: SEND: MAIL FROM: <> k8DHxlCa001774: RECV: 250 Ok k8DHxlCa001774: SEND: RCPT TO: <t1Kmx17Q@malaysia.net> k8DHxlCa001774: RECV: 550 <>: No thank you rejected: Account Unavailable: Possible Forgery k8DHxlCa001774: poll exited with status: not_found; sent "RCPT TO: <t1Kmx17Q@malaysia.net>", got "550 <>: No thank you rejected: Account Unavailable: Possible Forgery" k8DHxlCa001774: SEND: QUIT |
Mailfromd Manual (split by node): | ? |
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.