1 Introduction to mailfromd

Mailfromd is a general-purpose mail filtering daemon and a suite of accompanying utilities for Sendmail², MeTA1³, Postfix⁴ or any other MTA that supports Milter (or 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 Milter protocol.

The name 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 mailfromd, while omitting many subtleties.

The other parts are meant to be used as a reference for those who know 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 (Sendmail , Postfix or MeTA1).

1.1 Typographical conventions

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 9.0)

In the text, the command names are printed like this, 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 this font.

1.2 Overview of Mailfromd

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.

1.3 Sender Address Verification.

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 ‘<jsmith@somedomain.net>’ is trying to send mail to one of your local users. The remote machine connects to your MTA and issues MAIL FROM: <jsmith@somedomain.net> command. However, your MTA does not have to take its word for it, so it uses mailfromd to verify the sender address validity. 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 ‘<jsmith@somedomain.net>’. 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 mailfromd):

C: HELO mydomain.net
S: 220 OK, nice to meet you
C: MAIL FROM: <>
S: 220 <>: Sender OK
C: RCPT TO: <jsmith@somedomain.net>
S: 220 <jsmith@remote.net>: 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. Mailfromd also implements a method we call strict. When using strict method, 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: ‘<jsmith@somedomain.net>’ 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 mailfromd is 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, mailfromd will 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.

1.3.1 Limitations of Sender Address Verification

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:

• The sender verification methods will perform poorly on highly loaded sites. The traffic and/or resource usage overhead may not be feasible for you. However, you may experiment with various mailfromd options to find an optimal configuration.
• Some sites may blacklist your MTA if it probes them too often. Mailfromd eliminates this drawback by using a cache database, which keeps results of the recent callouts.
• When verifying the remote address, no attempt to actually deliver the message is made. If MTA accepts the address, mailfromd assumes 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).

• If the remote server rejects the address, no attempt is being made to discern between various reasons for rejection (client rejected, ‘HELO rejected’, ‘MAIL FROM’ rejected, etc.)
• Some major sites such as ‘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.

1.4 Controlling Mail Sending Rate.

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).

1.5 SPF, DKIM, and others

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 HELO 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 for using SPF to control mail flow. These are described in SPF Functions.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails. Mailfromd supports both DKIM signing and verification. See DKIM, for a detailed description of these features.

Mailfromd also provides support for some third-party spam-abatement programs, namely SpamAssassin, and ClamAV. These are discussed in Interfaces to Third-Party Programs.