Mailfromd Manual (split by section):   Section:   Chapter:FastBack: Intro   Up: Intro   FastForward: Building   Contents: Table of ContentsIndex: Concept Index

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

10relay1.somedomain.net
20relay2.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 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:

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.

Mailfromd Manual (split by section):   Section:   Chapter:FastBack: Intro   Up: SAV   FastForward: Building   Contents: Table of ContentsIndex: Concept Index