General-Purpose Mail Filter
Mailfromd is a general-purpose mail filtering daemon and a
suite of accompanying utilities for
Postfix3 or any other MTA that
Pmilter) protocol. It is able
to filter both incoming and outgoing messages using a filter program,
written in mail filtering language (MFL). The daemon
interfaces with the MTA using
mailfromd can be thought of as an abbreviation for
‘Mail Filtering and Runtime
Modification’ Daemon, with an ‘o’ for itself.
Historically, it stemmed from the fact that the original
implementation was a simple filter implementing the sender
address verification technique. Since then the program has changed
dramatically, and now it is actually a language translator and
run-time evaluator providing a set of built-in and library functions
for filtering electronic mail.
The first part of this manual is an overview, describing the features
mailfromd offers in general.
The second part is a tutorial, which provides an introduction for
those who have not used
mailfromd previously. It moves from
topic to topic in a logical, progressive order, building on
information already explained. It offers only the principal information
needed to master basic practical usage of
omitting many subtleties.
The other parts are meant to be used as a reference for those who
mailfromd well enough, but need to look up some notions
from time to time. Each chapter presents everything that needs to be
said about a specific topic.
The manual assumes that the reader has a good knowledge of the
SMTP protocol and the mail transport system he uses
This manual is written using Texinfo, the GNU documentation formatting language. The same set of Texinfo source files is used to produce both the printed and online versions of the documentation. Because of this, the typographical conventions may be slightly different than in other books you may have read.
Examples you would type at the command line are preceded by the common shell primary prompt, ‘$’. The command itself is printed in this font, and the output it produces ‘in this font’, for example:
$ mailfromd --version mailfromd (mailfromd 8.7)
In the text, the command names are printed
command line options are displayed in this font. Some
notions are emphasized like this, and if a point needs to be made
strongly, it is done this way. The first occurrence of
a new term is usually its definition and appears in the same
font as the previous occurrence of “definition” in this sentence.
File names are indicated like this: /path/to/ourfile.
The variable names are represented like this, keywords and
fragments of program text are written in
In contrast to the most existing milter filters,
mailfromd does not implement any default filtering
policies. Instead, it depends entirely on a filter script,
supplied to it by the administrator. The script, written in a
specialized and simple to use language, called MFL
(see MFL), is supposed to run a set of tests and to decide
whether the message should be accepted by the MTA or not.
To perform the tests, the script can examine the values of
Sendmail macros, use an extensive set of built-in
and library functions, and invoke user-defined functions.
Sender address verification, or callout, is one of the
basic mail verification techniques, implemented by
mailfromd. It consists in probing each MX server
for the given address, until one of them gives a definite (positive or
negative) reply. Using this technique you can block a sender address
if it is not deliverable, thereby cutting off a large amount of spam.
It can also be useful to block mail for undeliverable recipients, for
example on a mail relay host that does not have a list of all the
valid recipient addresses. This prevents undeliverable junk mail from
entering the queue, so that your MTA doesn’t have to waste
resources trying to send ‘MAILER-DAEMON’ messages back.
Let’s illustrate how it works on an example:
Suppose that the user ‘<firstname.lastname@example.org>’ is trying to
send mail to one of your local users. The remote machine connects to
your MTA and issues
MAIL FROM: <email@example.com>
command. However, your MTA does not have to take its word for it, so
mailfromd to verify the sender address
Mailfromd strips the domain name from the address
(‘somedomain.net’) and queries DNS about ‘MX’ records for that
domain. Suppose, it receives the following list
It then connects to first MX server, using SMTP
protocol, as if it were going to send a message to
‘<firstname.lastname@example.org>’. This is called sending a
probe message. If the server accepts the recipient address, the
mailfromd accepts the incoming mail. Otherwise, if the
server rejects the address, the mail is rejected as well. If the MX
server cannot be connected,
mailfromd selects next server
from the list and continues this process until it finds the
answer or the list of servers is exhausted.
The probe message is like a normal mail except that no data
are ever being sent. The probe message transaction in our example
might look as follows (‘S:’ meaning messages sent by remote
MTA, ‘C:’ meaning those sent by
C: HELO mydomain.net S: 220 OK, nice to meet you C: MAIL FROM: <> S: 220 <>: Sender OK C: RCPT TO: <email@example.com> S: 220 <firstname.lastname@example.org>: Recipient OK C: QUIT
Probe messages are never delivered, deferred or bounced; they are always discarded.
The described method of address verification is called
a standard method throughout this document.
also implements a method we call strict. When using strict
mailfromd first resolves IP address of sender
machine to a fully qualified domain name. Then it obtains ‘MX’ records
for this machine, and then proceeds with probing as described above.
So, the difference between the two methods is in the set of ‘MX’ records that are being probed: standard method queries ‘MX’s based on the sender email domain, strict method works with ‘MX’s for the sender IP address.
Strict method allows to cut off much larger amount of spam, although it does have many drawbacks. Returning to our example above, consider the following situation: ‘<email@example.com>’ is a perfectly normal address, but it is being used by a spammer from some other domain, say ‘otherdomain.com’. The standard method is not able to cope with such cases, whereas the strict one is.
An alert reader will ask: what happens if
not able to get a definite answer from any of MX servers? Actually,
it depends entirely on how you will instruct it to act in this case,
but the general practice is to return temporary failure, which will
urge the remote party to retry sending their message later.
After receiving a definite answer,
cache it in its database, so that next time your MTA receives a
message from that address (or from the sender IP/email address pair,
for strict method), it will not waste its time trying to reach MX
servers again. The records remain in the cache database for a certain
time, after which they are discarded.
Before deciding whether and how to use sender address verification, you should be aware of its limitations.
Both standard and strict methods suffer from the following limitations:
mailfromdoptions to find an optimal configuration.
Mailfromdeliminates this drawback by using a cache database, which keeps results of the recent callouts.
mailfromdassumes it is OK. However in reality, a mail for a remote address can bounce after the nearest MTA accepts the recipient address.
This drawback can often be avoided by combining sender address verification with greylisting (see Greylisting).
yahoo.com’ do not reject unknown addresses in reply to the ‘RCPT TO’ command, but report a delivery failure in response to end of ‘DATA’ after a message is transferred. Of course, sender address verification does not work with such sites. However, a combination of address verification and greylisting (see Greylisting) may be a good choice in such cases.
In addition, strict verification breaks forward mail delivery. This is obvious, since mail forwarding is based on delivering unmodified message to another location, so the sender address domain will most probably not be the same as that of the MTA doing the forwarding.
Mail Sending Rate for a given identity is defined as the number of messages with this identity received within a predefined interval of time.
MFL offers a set of functions for limiting mail sending rate (see Rate limiting functions), and for controlling broader rate aspects, such as data transfer rates (see TBF).
Sender Policy Framework, or SPF for short, is an
extension to SMTP protocol that allows to identify forged
identities supplied with the
MAIL FROM and
commands. The framework is explained in detail in RFC 4408
(http://tools.ietf.org/html/rfc4408) and on the
SPF Project Site.
Mailfromd provides a set of functions (see SPF Functions) for using SPF to control mail flow.
This document was generated on January 3, 2019 using makeinfo.Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.