Resent: SUMMARY: sendmail.mx

[This did not come back to me from the list, so I assume it was lost
somewhere.]

Hello,

last week I posted a question to the list:

Michael> maybe I missed something in the manuals, but can anybody
Michael> explain to me how the sendmail.mx works? I know it uses the
Michael> MX-Records from the nameserver, but what does it query for? A
Michael> particular host? Subnets? What happens if there is no
Michael> information available for that host? And does sendmail.cf
Michael> have any signaficance if I use sendmail.mx? If yes, when is
Michael> it consulted? If the nameserver query fails? Or are the
Michael> results from the query available in some $Xs?

It turned out to be quiet a popular question, as I got many requests
to forward the answers directly. I'm glad to say that there were
answers. I'll give a compiled summary below and append the originals.

Thanks very much to all who replied.

Michael

Compiled Summary:
-----------------

The vanilla sendmail does not know or care about the name server. It
merely attempts to connect to Internet machines via the standard
methods: calling "gethostent" and its friends to obtain an internet
address, then connecting to the SMTP port, etc. It is up to
gethostent to use YP, the name server, or a static table. [phil]

sendmail.mx queries whichever nameserver it can reach, checking them
in order as listed in /etc/resolv.conf. [bob]

With Sun's sendmail.mx, there are (as far as I know) only three cases when
it will query the name server [per]:

a) To find it's own name for the $w macro, I believe it does a lookup on
what gethostname() returns to get the full, official name.

b) when you do a "canonicalization": $[ $] operation, what is inside the
brackets is used to query the nameserver, and is replaced by the
"official name" returned, unchanged if the query fails.

c) when an SMTP mailer is selected for delivery: the name given as
"host", i.e. $@, is used to query the name server, actual delivery is
to the host the MX record refers to if there is one, otherwise the A
record (i.e. the IP address) is used. This lookup *should* be able to
differentiate between a temporary failure (i.e. nameserver couldn't
find information about the name) => retry later, and a permanent one
(i.e. nameserver says "there is no such name") => bounce it - don't
know if it does...

[mnl: I can confirm this. I set up a nameserver and searched through
its debug output what sendmail was asking for. Be careful using (b):
if you use as a simple test rule (as I did), preceed it with $: or
you'll get a loop (as I did). The standard sendmail (without .mx)
hangs if used with this rule. Also note that the MX-query will be done
for delivery only, i.e. it does not show up if you call `sendmail.mx
-bt'.]

Briefly, all domain names which represent classes of machines
rather than individual machines should have MX records pointing
to some machine that accept email for that domain. All diskless
clients (indeed any machines that use "client" type sendmail
and mount /var/spool/mail from a server) should probably have
MX records pointing to their mail server rather than the
individual machine. [bob]

An MX record indicates that the machine is available for "mail exchange" for
the queried domain. For example, since the machine that handles E-mail for
the domain WA.COM is not on the Internet, a machine that is on the Internet
needs to handle the forwarding of E-mail on my machine's behalf. In this
case, an MX record is put into The Nameserver showing uunet.uu.net as being
the forwarder for all E-mail to the WA.COM domain. A sendmail configuration
file that is set up to use MX records will take advantage of this feature and
do a better job of routing E-mail as it will be able to recognize domains not
on the Internet and forward them appropriately.

The vanilla sendmail does not know or care about the name server. IT
merely attempts to connect to Internet machines via the standard
methods: calling "gethostent" and its friends to obtain an internet
address, then connecting to the SMTP port, etc. It is up to
gethostent to use YP, the name server, or a static table.

sendmail.mx knows how to talk directly to a name server. I believe
(but am not certain) that it does all its own queries, and never calls
"gethostent" or "gethostby*". Here's what happens:

sendmail.mx decides that it needs to send this mail message to
host X via SMTP.

it asks the name server to resolve the name X. it gets back a
bunch of name server records, perhaps some A records and perhaps some
MX records.

if it sees an MX record for host X, it looks at the host name
contained in the MX record---let's call it host Y---and attempts to
send the message (WITHOUT altering it) to Y. "MX" is short for "Mail
eXchanger" and is intended to indicate a host that acts as a mail
forwarder for host X. Upon receipt, host Y uses whatever method it
needs to to deliver the message to host X (could be UUCP, could be a
different type of network, could even be SMTP).

if it does not see an MX record, then sendmail.mx uses the
address found in the A record to open an SMTP connection as usual.

Many sites that are not directly on the Internet will designate a host
which IS on the net as its mail exchanger. Then they find someone on
the Inetnet (usually the same host as the mail exchanger) to act as
the name server, telling all name servers that host X has an MX record
that points to host Y. This is why it is important for Internet hosts
to run sendmail.mx. If you aren't running it, then there is a large
body of hosts for which you cannot write a direct mail address.

Given a domain name (e.g., "soest.hawaii.edu"), sendmail.mx--as
specified in /etc/sendmail.cf--queries whichever nameserver
it can reach, checking them in order as listed in /etc/resolv.conf,
for an "MX record" (see "man named"), which gives the
domain name of the system to which the email is actually
supposed to be sent (e.g., for "soest.hawaii.edu", that's
"kahala.soest.hawaii.edu").

Then the "A record" for that second name is retrieved, which gives the
resulting system's internet number (net.subnet...host), which is what
SMTP uses to actually start the connection.

If the first query found no MX record, an attempt is made to
use tha A record internet number instead.

If nothing is found, you'll get the "host not found" error.

Briefly, all domain names which represent classes of machines
rather than individual machines should have MX records pointing
to some machine that accept email for that domain. All diskless
clients (indeed any machines that use "client" type sendmail
and mount /var/spool/mail from a server) should probably have
MX records pointing to their mail server rather than the
individual machine.

On Mar 27, 5:44pm, "Michael N. Lipp" wrote:
> maybe I missed something in the manuals, but can anybody explain to me
> how the sendmail.mx works? I know it uses the MX-Records from the
> nameserver, but what does it query for? A particular host? Subnets?

MX records, & then A records

> What happens if there is no information available for that host? And

Depends on why no info was available -- if the "server failed" message
is returned, the mail will be queued for another time. If it just
plain don't exist, according to the nameserver, the message is
bounced.

> does sendmail.cf have any signaficance if I use sendmail.mx? If yes,
Yes
> when is it consulted? If the nameserver query fails? Or are the
No, same as in regular sendmail. There are macro calls in
a properly-written sendmail.cf that invoke the nameserver;
stuff like this:
R<@$+>$* $@<@$[$1$]>$2 resolve <route-addr>

In article <9103271644.AA21507@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE> you write:
|> maybe I missed something in the manuals, but can anybody explain to me
|> how the sendmail.mx works? I know it uses the MX-Records from the
|> nameserver, but what does it query for? A particular host?

Yes, more or less - i.e. typically what is on the right hand side of the
'@' sign - but this is totally up to the sendmail.cf.

|> Subnets?

Don't know what you mean by this, I don't think it's common to send mail
to networks, sub- or other...?:-)

|> What happens if there is no information available for that host?

Typically the mail is bounced with "Host unknown".

|> And
|> does sendmail.cf have any signaficance if I use sendmail.mx?

Certainly, sendmail.cf is always the primary source governing sendmail's
behaviour. In fact, it is quite possible (but not very useful:-) to run
sendmail.mx and not have it query the nameserver for mail destinations,
if the sendmail.cf doesn't (explicitly or implicitly) tell it to.

With Sun's sendmail.mx, there are (as far as I know) only three cases when
it will query the name server:

a) To find it's own name for the $w macro, I believe it does a lookup on
what gethostname() returns to get the full, official name.

b) when you do a "canonicalization": $[ $] operation, what is inside the
brackets is used to query the nameserver, and is replaced by the
"official name" returned, unchanged if the query fails.

c) when an SMTP mailer is selected for delivery: the name given as
"host", i.e. $@, is used to query the name server, actual delivery is
to the host the MX record refers to if there is one, otherwise the A
record (i.e. the IP address) is used. This lookup *should* be able to
differentiate between a temporary failure (i.e. nameserver couldn't
find information about the name) => retry later, and a permanent one
(i.e. nameserver says "there is no such name") => bounce it - don't
know if it does...