sendmail.mx
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]
Here, we also use MX records for networked PCs that don't accept
email themselves, pointed towards the mail server where the
PC user gets his/her mail. [bob]
Original Answers:
-----------------
Date: Wed, 27 Mar 91 08:17:57 PST
From:edm@MDI.COM(Ed@mvs.hrz.th-darmstadt.de Morin)
To:mnl@idtsun.e-technik.th-darmstadt.de
Subject: Re: sendmail.mx
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.
Anyway, that's what I think a sendmail.mx configuration file does!
Ed Morin
-------------------------------------------------------------------------------
Date: Wed, 27 Mar 91 11:18:55 CST
From:phil@PEX.EECS.NWU.EDU(William@mvs.hrz.th-darmstadt.de LeFebvre)
To:mnl@idtsun.e-technik.th-darmstadt.de
In-Reply-To: "Michael N. Lipp"'s message of Tue, 26 Mar 91 18:17:38 +0100
<9103261717.AA05004@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
Subject: Re: sendmail.mx
I don't know if this will answer your question or not.
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.
William LeFebvre
Computing Facilities Manager and Analyst
Department of Electrical Engineering and Computer Science
Northwestern University
-------------------------------------------------------------------------------
Date: Wed, 27 Mar 91 07:40:32 HST
From:bob@KAHALA.SOEST.HAWAII.EDU(Bob@mvs.hrz.th-darmstadt.de Cunningham)
To:mnl@idtsun.e-technik.th-darmstadt.de
Subject: Re: sendmail.mx
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.
Here, we also use MX records for networked PCs that don't accept
email themselves, pointed towards the mail server where the
PC user gets his/her mail.
-------------------------------------------------------------------------------
From:mike@INTI.LBL.GOV(Michael@mvs.hrz.th-darmstadt.de Helm)
Date: Wed, 27 Mar 1991 10:58:03 PST
In-Reply-To: "Michael N. Lipp"
<mnl%IDTSUN.E-TECHNIK.TH-DARMSTADT.DE@UNKNOWN.DOMAIN>
"sendmail.mx" (Mar 27, 5:44pm)
Reply-To:mike@INTI.LBL.GOV
X-Mailer: Mail User's Shell (7.1.2 7/11/90)
To: "Michael N. Lipp" <mnl%IDTSUN.E-TECHNIK.TH-DARMSTADT.DE@CUNYVM.CUNY.EDU>
Subject: Re: sendmail.mx
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>
The $[ stuff ]$ means "ask the nameserver about stuff".
-------------------------------------------------------------------------------
From:per@ERIX.ERICSSON.SE(Per@mvs.hrz.th-darmstadt.de Hedeland)
Date: Thu, 28 Mar 91 09:17:31 +0100
To: "Michael N. Lipp" <mnl%IDTSUN.E-TECHNIK.TH-DARMSTADT.DE@CUNYVM.CUNY.EDU>
Subject: Re: sendmail.mx
Return-Receipt-To:per@erix.ericsson.se
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...
|> Or are the results from the query available in some $Xs?
Don't think so.
Hope this helps...
--Per Hedeland
per%erix.ericsson.se@uunet.uu.net or
...uunet!erix.ericsson.se!per
-------------------------------------------------------------------------------
-----------------,------------------------------,------------------------------
Michael N. Lipp ! Institut fuer Datentechnik ! Phone: 49-6151-163776
! Merckstr. 25 ,----------' Fax: 49-6151-164976
! D-6100 Darmstadt ! E-Mail: xdatmnlx@ddathd21.bitnet
! (Germany) ! mnl@idtsun.e-technik.th-darmstadt.de
-----------------'-------------------'-----------------------------------------
