Mailfromd |
|
General-Purpose Mail Filter |
Sergey Poznyakoff |
Mailfromd Manual (split by node): | ? |
Sender address verification 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
10 | relay1.somedomain.net |
20 | relay2.somedomain.net |
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
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.
Mailfromd Manual (split by node): | ? |
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.