General-Purpose Mail Filter
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 ‘<email@example.com>’ is trying to
send mail to one of your local users. The remote machine connects to
your MTA and issues
MAIL FROM: <firstname.lastname@example.org>
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
‘<email@example.com>’. 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: <firstname.lastname@example.org> S: 220 <email@example.com>: 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: ‘<firstname.lastname@example.org>’ 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.
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.