[comp.mail.sendmail] Local Configuration Error

gord@cs.UAlberta.CA (Gord Urquhart) (09/19/90)

  I am running sendmail 5.61 in conjunction with Bind. Everything works 
except for machines that are MX'ed to the local host. If there are 2 MX 
records for a host with the prefered one being the local host then in 
domain.c sendmail trips over a check that says he should have already 
recognized that this was a local delivery - specifically:

     if (seenlocal && prefer[i] >= localpref) {
            /*
             * truncate higher pref part of list; if we're
             * the best choice left, we should have realized
             * awhile ago that this was a local delivery.
             */
            if (i == 0) {
                *rcode = EX_CONFIG;
                return(-1);
            }

 So after pretending my head is a masonary hammer for a couple of days,
how do I set up my config file to recognize these hosts as local and still
use the TCP mailer.

gord u.

---------------------------------------------------------------------
Gord Urquhart				gord@atropos.ucs.ualberta.ca 
Technical Support 
University Computing Systems
University of Alberta

rickert@mp.cs.niu.edu (Neil Rickert) (09/19/90)

In article <gord.653697425@menaik> gord@cs.UAlberta.CA (Gord Urquhart) writes:
>
>  I am running sendmail 5.61 in conjunction with Bind. Everything works 
>except for machines that are MX'ed to the local host. If there are 2 MX 
>records for a host with the prefered one being the local host then in 

 This looks like a problem for which I posted a patch several weeks ago.
Since it is a simple patch, I will repeat it.

 What happens is this:
   With two or more MX records, the behavior is dependent on the order
in which the MX records are retrieved from the name server.  If the
best preference/local address entry comes first, it is rejected and
so are all other MX records.  There is then a lookup for an A-record
(in deliver.c).  But if the best preference does not come first, after
all MX records have been stored they are sorted.  In this case if the
best preference is local a configuration error is declared.

 Clearly the dependence on the order makes no sense.  Either it should
always be a configuration error, or it should always result in a search
for an A-record.  Since the second choice is more useful, the patch
implements it.

 Note: the patch is for sendmail 5.64, but there is probably very
       little difference in the code.

*** /tmp/,RCSt1025390	Thu Sep 13 14:39:07 1990
--- domain.c	Fri Aug 10 16:12:53 1990
***************
*** 161,170 ****
  			 * the best choice left, we should have realized
  			 * awhile ago that this was a local delivery.
  			 */
! 			if (i == 0) {
! 				*rcode = EX_CONFIG;
! 				return(-1);
! 			}
  			nmx = i;
  			break;
  		}
--- 161,168 ----
  			 * the best choice left, we should have realized
  			 * awhile ago that this was a local delivery.
  			 */
! 			if (i == 0)
! 				goto punt;
  			nmx = i;
  			break;
  		}

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

piet@cwi.nl (Piet Beertema) (09/20/90)

	>With two or more MX records, the behavior is dependent on the order
	>in which the MX records are retrieved from the name server.  If the
	>best preference/local address entry comes first, it is rejected and
	>so are all other MX records.  There is then a lookup for an A-record
	>(in deliver.c).  But if the best preference does not come first, after
	>all MX records have been stored they are sorted.  In this case if the
	>best preference is local a configuration error is declared.
	> Clearly the dependence on the order makes no sense.  Either it should
	>always be a configuration error, or it should always result in a search
	>for an A-record.  Since the second choice is more useful, the patch
	>implements it.
In both cases only the local MX record is discarded (but
marked) and all other MX records are stored and sorted.
Then, if the highest-preference MX record points to the
local host it's an error that should not be "solved" by
looking at an A record. After all, the presence of an MX
record indicates that, for whatever reason, the A record
should *not* be used (e.g. if the domain is used by a uucp
site). And if there is an A record, but the error occurs
due to a wrong DNS entry for the domain, it's the DNS entry
that should be fixed, not the way sendmail handles MX RR's.

--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)

rickert@mp.cs.niu.edu (Neil Rickert) (09/21/90)

In article <2199@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes:
>
>	>With two or more MX records, the behavior is dependent on the order
>	>in which the MX records are retrieved from the name server.  If the

     .....  and more quotes from my previous article.

>	>always be a configuration error, or it should always result in a search
>	>for an A-record.  Since the second choice is more useful, the patch
>	>implements it.
>In both cases only the local MX record is discarded (but
>marked) and all other MX records are stored and sorted.

  You must be looking at different source code to mine.  In the 5.64 release
from Berkeley, as soon as an MX record pointing to the local host is found
its preference is recorded, and any further MX records are only stored into
an array for sorting if they have a lower preference.  Thus if the local
preference is the best preference, and comes first, getmxrr() acts as if no
MX records were found.  If the local record is found later there are already
entries in that array which will ultimately be all rejected, and in this case
(unless the patch I supplied is used) a configuration error is declared.

>looking at an A record. After all, the presence of an MX
>record indicates that, for whatever reason, the A record
>should *not* be used (e.g. if the domain is used by a uucp
>site). And if there is an A record, but the error occurs
>due to a wrong DNS entry for the domain, it's the DNS entry
>that should be fixed, not the way sendmail handles MX RR's.

 Here I disagree.  I said in my previous article that giving an A-record is
more useful than declaring a configuration error.  Let me give a scenario
where that behavior is useful.

  Host X is on a private network, and cannot communicate with most
internet hosts.  Host Y is on both Internet and the private network.  Host Y
deliberately does not forward internet packets due to company policy, security
concerns, etc.  Host X has an A-record in the domain database to facilitate
communication by hosts which are on the private network.  There is an MX 
record directing email to host Y.  Host Y should be able to forward the mail
by SMTP; it should not have to set up a UUCP link just to circumvent the
inadequacies of your interpretation.  Of course the domain database could
set up two MX records, with the highest preference to X, second preference
to Y.  This would work.  But every host sending email to X would have to time
out on its attempt to send to X before it sent to Y.  This seems stupid, when
the other method works.  Namely, if there is not MX preference better than
the local host (which would be true for Y, but for no other host), use the A
record to forward mail.

 Although MX records are often used in association with UUCP forwarding of
mail, don't close your mind to other possibilities.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

andy@jhunix.HCF.JHU.EDU (Andy S Poling) (09/21/90)

In article <2199@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes:
>
>	>With two or more MX records, the behavior is dependent on the order
>	>in which the MX records are retrieved from the name server.  If the
>	>best preference/local address entry comes first, it is rejected and
>	>so are all other MX records.  There is then a lookup for an A-record
>	>(in deliver.c).  But if the best preference does not come first, after
>	>all MX records have been stored they are sorted.  In this case if the
>	>best preference is local a configuration error is declared.
>	> Clearly the dependence on the order makes no sense.  Either it should
>	>always be a configuration error, or it should always result in a search
>	>for an A-record.  Since the second choice is more useful, the patch
>	>implements it.
>In both cases only the local MX record is discarded (but
>marked) and all other MX records are stored and sorted.
>Then, if the highest-preference MX record points to the
>local host it's an error that should not be "solved" by
>looking at an A record. After all, the presence of an MX
>record indicates that, for whatever reason, the A record
>should *not* be used (e.g. if the domain is used by a uucp
>site). And if there is an A record, but the error occurs
>due to a wrong DNS entry for the domain, it's the DNS entry
>that should be fixed, not the way sendmail handles MX RR's.

Wrong, wrong, wrong.  I have a number of hosts that I would like to be able
to "back each other up".  That is, if hostA is down, hostB is a secondary MX
for hostA and will receive hostA's mail and queue it until hostA regains
consciousness.  This approach takes the burden of retry-ing off of the
far-away sender.

Nowhere does anything say that because I am an MX for another host, I cannot
choose to deliver mail to that host using SMTP.  According to your
interpretation, that is impossible and wrong.

Frankly, considering how configurable the rest of sendmail is, I would think
that this behavior ought to be controllable by setting an option.  That
behavior is more in the "spirit" of sendmail...

My $.02 worth.

-Andy

--
Andy Poling                              Internet: andy@gollum.hcf.jhu.edu
Systems Programmer                       Bitnet: ANDY@JHUNIX
Homewood Academic Computing              Voice: (301)338-8096    
Johns Hopkins University                 UUCP: uunet!mimsy!aplcen!jhunix!andy

Craig_Everhart@TRANSARC.COM (09/21/90)

Excerpts from netnews.comp.mail.sendmail: 20-Sep-90 Re: Local
Configuration Error Andy S Poling@jhunix.HCF (2399)

> Wrong, wrong, wrong.  I have a number of hosts that I would like to be able
> to "back each other up".  That is, if hostA is down, hostB is a secondary MX
> for hostA and will receive hostA's mail and queue it until hostA regains
> consciousness.  This approach takes the burden of retry-ing off of the
> far-away sender.

All the MX processing allows this to happen.

Let's say we have hosts A and B, and two MXs for A: one pointing to A
with preference 10, and one pointing to B with preference 20.  (MX(A) =
(10,A); MX(A) = (20,B).)  On host B (which is what we're concerned
with), all MXs with preference >= 20 will be discarded, but that will
nonetheless leave us with an MX pointing to domain A.  That's fine:
clearly, you need to do an address lookup on the targets for MX records.

All that Piet Beertema claims is that you shouldn't do address lookups
for host A just because you ran out of MX records, apparently a
debatable point.  The fact that the host name A is in both positions in
``MX(A) = (10,A)'' muddles the issue.

		Craig

rickert@mp.cs.niu.edu (Neil Rickert) (09/21/90)

In article <wayWTiX0BwwORNyX8k@transarc.com> Craig_Everhart@TRANSARC.COM writes:
>Let's say we have hosts A and B, and two MXs for A: one pointing to A
>with preference 10, and one pointing to B with preference 20.  (MX(A) =
>(10,A); MX(A) = (20,B).)  On host B (which is what we're concerned
>with), all MXs with preference >= 20 will be discarded, but that will
>nonetheless leave us with an MX pointing to domain A.  That's fine:
>clearly, you need to do an address lookup on the targets for MX records.
>
>All that Piet Beertema claims is that you shouldn't do address lookups
>for host A just because you ran out of MX records, apparently a
>debatable point.  The fact that the host name A is in both positions in
>``MX(A) = (10,A)'' muddles the issue.
>
   Right.  But what do you do when host A can only communicate on to its
local network.  Perhaps it has bad networking code.  Perhaps there is a
security concern.  However B can talk to the local network and the world.

  The possible solutions (using only SMTP) are:

   1.  Have two MX records for host A.  Preference 0 delivers to A, and
       preference 10 to B.  Anyone sending email from outside the local
       network will timeout on trying to send to A, and will (we hope)
       then send to B from where it will be forwarded.  I claim this is
       a poor choice, for it makes the whole Internet suffer the need to
       first time out on the primary MX record.

   2.  Have MX records for A pointing only to B (and to similarly capable
       hosts).   Make sure sendmail doesn't declare a configuration error
       when the best MX preference is for the local (i.e. B) host, but
       instead looks for an A-record.  This method works very simply and
       transparently.  Sendmail-5.64, as distributed by Berkeley already
       does this IF there is only a single MX record, but fumbles it if there
       are two or more MX records.  (This is what started the discussion).

   3.  Have 'sendmail' set to declare a configuration error, but bypass the
       problem with an ugly fudge in 'sendmail.cf' which directs the mail
       to A by internet address (as in [1.2.3.4]).  This will work if done
       with extreme care, but puts us back at the point of dependence on
       internet addresses that the domain naming system was meant to
       avoid.  The reason Internet addresses must be used with extreme
       care is that standard Berkeley versions of 'sendmail.cf' tend to
       mishandle them.  It the address is run through the $[ .. $] construct
       it is converted to a name, and the result will be that the name is
       used to find an MX record.  (This violates the RFC ??? specification
       that [...] addresses are to be used without interpretation).  (Of course
       if the address is not run through $[ ... $], 'sendmail.cf' may fail to
       recognize when an Internet address is local).

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

piet@cwi.nl (Piet Beertema) (09/25/90)

		In both cases only the local MX record is discarded (but
		marked) and all other MX records are stored and sorted.
	You must be looking at different source code to mine. In the
	5.64 release from Berkeley, as soon as an MX record pointing
	to the local host is found its preference is recorded, and any
	further MX records are only stored into an array for sorting
	if they have a lower preference.
I'm using sendmail-5.64+IDA. But here's the relevant part of
the original Berkeley version:

	......
	while (--ancount >= 0 && cp < eom && nmx < MAXMXHOSTS) {
		if ((n = dn_expand((char *)&answer, eom, cp, bp, buflen)) < 0)
			break;
		......
		if (!strcasecmp(bp, localhost)) {
			if (seenlocal == 0 || pref < localpref)
				localpref = pref;
			seenlocal = 1;
			continue;
		}
		prefer[nmx] = pref;
		mxhosts[nmx++] = bp;
		n = strlen(bp) + 1;
		bp += n;
		buflen -= n;
	}
	if (nmx == 0) {
punt:		mxhosts[0] = strcpy(hostbuf, host);
		return(1);
	}

	/* sort the records */
	for (i = 0; i < nmx; i++) {

The !strcasecmp() matches only for the MX record pointing to the
local host; that record is discarded, but marked in seenlocal.
All other (previous or later) MX records are stored in mxhosts[]
and sorted later on. Care is taken of multiple MX records pointing
to the local host: only the one with the lowest value (highest
priority) is taken into account.

If the above is wrong, please tell me where it is wrong.


As Brian Kantor pointed out, the match on localhost fails if for
one reason or another $w has not been set to the fully qualified
domain name of the local host (which can be useful if e.g. the
unqualified name is the uucp name). This can easily be corrected by
using `gethostbyname(localhost)->h_name' in the comparison instead
of localhost itself. This is in line with how localhost is obtained
elsewhere (via myhostname() which uses gethostbyname()). It is also
correct in the sense that, since $w defines the local host, it by
definition resides in the local domain and thus can be made fully
qualified with the local domain.


--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)

rickert@mp.cs.niu.edu (Neil Rickert) (09/25/90)

In article <2223@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes:
>
>		In both cases only the local MX record is discarded (but
>		marked) and all other MX records are stored and sorted.

 I stand corrected on this.

 The result is the equivalent.  With the only MX record pointing to the
local host, the action is to look up an A-record.  With two or more MX
records, but the best preference pointing to the localhost, you get
a configuration error message.  This still makes no sense.

 MX records with worse preference than the local host should always be
ignored.  They should not effect the way it works.

 It is still true that looking up an A-record is more useful than declaring
a configuration error, as I pointed out in message
<1990Sep21.161726.18266@mp.cs.niu.edu>.  The patch I posted on Sept 18th
achieves this effect.

>As Brian Kantor pointed out, the match on localhost fails if for
>one reason or another $w has not been set to the fully qualified
>domain name of the local host (which can be useful if e.g. the
>unqualified name is the uucp name). This can easily be corrected by

  There are 26 upper case letters of the alphabet available for macros,
and most configuration files use only a small number of them.  The
lower case letters have internal predefined meanings.  Why do you have
to violate the internal predefined meaning, and cause yourself trouble
when all that is necessary is something like ':g/$w/s//$W/g' in vi?

>unqualified name is the uucp name). This can easily be corrected by
>using `gethostbyname(localhost)->h_name' in the comparison instead

 Sendmail 5.64 already does this in its internal definition of $w.  It
is only because it is being incorrectly redefined that you have to do
this again.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

piet@cwi.nl (Piet Beertema) (09/25/90)

	With the only MX record pointing to the local host, the action
	is to look up an A-record.
Right. In my opinion that should give a "local configuration error"
too, but you won't agree with that.

	There are 26 upper case letters of the alphabet available for
	macros, and most configuration files use only a small number
	of them. The lower case letters have internal predefined meanings.
	Why do you have to violate the internal predefined meaning
The predefined meaning of $w is the "hostname of this site".
Redefining $w to be precisely the same but only with another
representation can be useful (if only to make $=w in the sample
config files work) and doesn't "violate" anything. I therefore
maintain that $w should *always* be made fully qualified before
comparing it to the contents of MX records.

--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)

piet@cwi.nl (Piet Beertema) (09/25/90)

	But what do you do when host A can only communicate on to its
	local network. Perhaps it has bad networking code. Perhaps there
	is a security concern. However B can talk to the local network
	and the world.

	  The possible solutions (using only SMTP) are:
	
	   1.  Have two MX records for host A.  Preference 0 delivers to A, and
	       preference 10 to B.  Anyone sending email from outside the local
	       network will timeout on trying to send to A, and will (we hope)
	       then send to B from where it will be forwarded.  I claim this is
	       a poor choice, for it makes the whole Internet suffer the need to
	       first time out on the primary MX record.
	
	   2.  Have MX records for A pointing only to B (and to similarly capable
	       hosts).   Make sure sendmail doesn't declare a configuration error
	       when the best MX preference is for the local (i.e. B) host, but
	       instead looks for an A-record.  This method works very simply and
	       transparently.  Sendmail-5.64, as distributed by Berkeley already
	       does this IF there is only a single MX record, but fumbles it if there
	       are two or more MX records.  (This is what started the discussion).
	
	   ......

That would all be fine iff DNS RR's would only represent hosts.
But they don't, they represent domains. Take this example:
cwi.nl.		MX 10	charon.cwi.nl.
		MX 20	piring.cwi.nl.
Here cwi.nl is not a host and thus it doesn't have an A record.
(The same would be true if cwi.nl would be a domain in the uucp
world and the MX records would point to a gateway).
If charon.cwi.nl wouldn't be able to deal with user@cwi.nl, that
would really be a local configuration error. Attempts to find an
A record would fail and lead to "550 Host unknown". That's what
I consider as unwanted because the MX record is there precisely
to avoid that. Besides, the error is less meaningful.

--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)

rickert@mp.cs.niu.edu (Neil Rickert) (09/25/90)

In article <2229@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes:

>The predefined meaning of $w is the "hostname of this site".

 Right.  But MX versions of sendmail go to great care to ensure this
means the fully qualified hostname.  The hostname is looked up in the
nameserver (with gethostbyname()) before assigning to $w.

>Redefining $w to be precisely the same but only with another

 Redefining is OK provided this gives the fully qualified host name.  It
might be necessary if hostname is something funny which does not lead to
the correct fully qualified value.

>representation can be useful (if only to make $=w in the sample
>config files work) and doesn't "violate" anything. I therefore

  There is a basic misunderstanding here.  Redefining $w (with a Dw line)
has absolutely no effect of $=w, which must be handled with a Cw (or Fw) line.

>maintain that $w should *always* be made fully qualified before
>comparing it to the contents of MX records.
>
  My personal preference, is to do the MX comparison with $j instead
of $w.  This is a trivial patch in deliver.c and is already in the IDA
versions of sendmail-5.64+IDA available at uxc.cso.uiuc.edu.  Since $j is
not normally used in the rewrite rules, there is no excuse for not getting
it right.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

piet@cwi.nl (Piet Beertema) (09/25/90)

	There is a basic misunderstanding here. Redefining $w (with a Dw
	line) has absolutely no effect of $=w, which must be handled with
	a Cw (or Fw) line.
Sorry, I wasn't clear. The point is that $=w doesn't work
if $w is a multi-token item like a fully qualified name.
In that case you can't use the construction Cw$w either.

	My personal preference, is to do the MX comparison with $j instead
	of $w.
That makes sense. And the manual is clear both about the
meaning of $j and about the fact that it MUST be defined.

	This is a trivial patch in deliver.c and is already in the IDA versions
	of sendmail-5.64+IDA available at uxc.cso.uiuc.edu.
True. But to have it take permanent effect it Berkeley
should make it part of the official distribution.

--
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)

rickert@mp.cs.niu.edu (Neil Rickert) (09/26/90)

In article <2238@charon.cwi.nl> piet@cwi.nl (Piet Beertema) writes:
>
>	There is a basic misunderstanding here. Redefining $w (with a Dw
>	line) has absolutely no effect of $=w, which must be handled with
>	a Cw (or Fw) line.
>Sorry, I wasn't clear. The point is that $=w doesn't work
>if $w is a multi-token item like a fully qualified name.

 Whether $=w works or not has nothing to do with whether $w is a
multi-token item.  It has nothing whatever to do with the value of
$w.  The 'Dx' and 'Cx' lines are completely separate.

>In that case you can't use the construction Cw$w either.

 Unless I am misreading the code, the construction Cw$w NEVER does what
you think, regardless of the value of $w.  The fact is, $macro expansion
DOES NOT OCCUR during the processing of 'Cx' lines.  When you use 'Cw$w',
you finish up with $=w matching the string '\001w' or something like that.

>
>	My personal preference, is to do the MX comparison with $j instead
>	of $w.
>That makes sense. And the manual is clear both about the
>meaning of $j and about the fact that it MUST be defined.
>
 At last, something we can agree on.

 Not only is $j unambiguously defined in the manual, but it is used in
the ultimate test.  Namely, when an SMTP connection is made, there is
a comparison of the values of $j (as exchanged in the SMTP greeting) to
see if the host is talking to itself.  From this reason alone you could
argue that $j is the correct comparison.

>	This is a trivial patch in deliver.c and is already in the IDA versions
>	of sendmail-5.64+IDA available at uxc.cso.uiuc.edu.
>True. But to have it take permanent effect it Berkeley
>should make it part of the official distribution.

 I did send email to Berkeley suggesting this change.  No reply of course.
I guess we will find out what they think in the next release.
-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

hubert@milton.u.washington.edu (Steve Hubert) (09/27/90)

>                    Namely, when an SMTP connection is made, there is
>a comparison of the values of $j (as exchanged in the SMTP greeting) to
>see if the host is talking to itself.  From this reason alone you could
>argue that $j is the correct comparison.


This is kind of off the subject but it seems to me that the "Local
configuration error" detection is flawed.  The method of detection
as it stands now prohibits any local smtp client from talking to the
local sendmail smtp server.  It should only be preventing instances of
itself from talking to itself, which is a configuration error.  It should
not prevent other unrelated smtp clients which happen to be local from
talking to it.  For example, we have IMAP clients that want to talk
to the local smtp server so that the smarter server can figure out
how to deliver the mail.

Steve Hubert
Networks and Distributed Computing, Univ. of Wash., Seattle
hubert@cac.washington.edu

rickert@mp.cs.niu.edu (Neil Rickert) (09/27/90)

In article <8187@milton.u.washington.edu> hubert@milton.u.washington.edu (Steve Hubert) writes:
>>                    Namely, when an SMTP connection is made, there is
>>a comparison of the values of $j (as exchanged in the SMTP greeting) to
>>see if the host is talking to itself.  From this reason alone you could
>>argue that $j is the correct comparison.
>
>
>This is kind of off the subject but it seems to me that the "Local
>configuration error" detection is flawed.  The method of detection
>as it stands now prohibits any local smtp client from talking to the
>local sendmail smtp server.  It should only be preventing instances of

 Strange.  I am using MH as a mail program, and it has no problem.  It
just calls itself 'localhost' and communicates on the loopback net.  This
causes no difficulty unless my fully qualified domain name is also
local host.

 A local SMTP client could always use a different value for its host name,
and pass the test alright.  The method doesn't seem flawed to me.
-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

del@thrush.mlb.semi.harris.com (Don Lewis) (10/03/90)

In article <1990Sep21.161726.18266@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <wayWTiX0BwwORNyX8k@transarc.com> Craig_Everhart@TRANSARC.COM writes:
>   Right.  But what do you do when host A can only communicate on to its
>local network.  Perhaps it has bad networking code.  Perhaps there is a
>security concern.  However B can talk to the local network and the world.
>
>  The possible solutions (using only SMTP) are:
>
>   1.  Have two MX records for host A.  Preference 0 delivers to A, and
>       preference 10 to B.  Anyone sending email from outside the local
>       network will timeout on trying to send to A, and will (we hope)
>       then send to B from where it will be forwarded.  I claim this is
>       a poor choice, for it makes the whole Internet suffer the need to
>       first time out on the primary MX record.
>
>   2.  Have MX records for A pointing only to B (and to similarly capable
>       hosts).   Make sure sendmail doesn't declare a configuration error
>       when the best MX preference is for the local (i.e. B) host, but
>       instead looks for an A-record.  This method works very simply and
>       transparently.  Sendmail-5.64, as distributed by Berkeley already
>       does this IF there is only a single MX record, but fumbles it if there
>       are two or more MX records.  (This is what started the discussion).

This has the disadvantage that other hosts on the same local net as A
will send all their A-bound mail via host B, unless you have MX records
pointing to them as well :-(.

>   3.  [deleted]

How about:

    4.  Add a mailer flag which causes sendmail to speak SMTP to host A
	directly (look for A records only, do not look for MX records,
        do not pass GO, do not collect $200).  Host B would have a rule
	in ruleset 0 which would direct mail to A using the [TCP] mailer
	with this flag set, rather than the default [TCP] mailer.
-- 
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901

jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (10/15/90)

In article <1990Sep19.002139.32095@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>   With two or more MX records, the behavior is dependent on the order
>in which the MX records are retrieved from the name server.  If the
>best preference/local address entry comes first, it is rejected and
>so are all other MX records.  There is then a lookup for an A-record
>(in deliver.c).  But if the best preference does not come first, after
>all MX records have been stored they are sorted.  In this case if the
>best preference is local a configuration error is declared.

Hmmm, this continues to confuse me.  You say you're working with 5.64,
but I can't find the logic you refer to.  In the reno 5.64 domain.c the
following occurs in getmxrr() as it expands the response from the
nameserver:

>		if ((n = dn_expand((char *)&answer, eom, cp, bp, buflen)) < 0)
>			break;
>		cp += n;
>		if (!strcasecmp(bp, localhost)) {
>			if (seenlocal == 0 || pref < localpref)
>				localpref = pref;
>			seenlocal = 1;
>			continue;
>		}
>		prefer[nmx] = pref;
>		mxhosts[nmx++] = bp;

As you can see, unless the domain name matches the local hostname, the
record is stored in the prefer and mxhosts arrays; if it matches the
local host, then localpref and seenlocal are set.  Unless I'm totally
off my rocker, I don't see anywhere where "all other MX records" are
rejected after the local one is seen, regardless of preference.

Later, when the records are sorted, the ones with a preference >=
localpref are discarded, as per rfc-974.  If there are none left, then
we've hit the "best is local" scenario and we get the EX_CONFIG
returned.

This is how the code reads, and this is how sendmail acts.  If there
are more than one MX records, and the highest pref is the localhost,
then regardless of which order the records come in I get an EX_CONFIG.
If there is only one MX and it is the localhost, then I get the "punt"
strategy of attempting delivery directly to the host.

To my mind, this is the only questionable conduct here, since a list
consisting only of localhost is not the same as an empty list, and I
think it should result in an EX_CONFIG instead of a punt.  In any case,
can someone please clarify where the above-described behavior is
supposed to occur?

I've shown you mine, now you show me yours :-)

-------------------------------------------------------------------------------
Peter Jeffe   ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe
        first they want a disclaimer, then they make you pee in a jar,
                   then they come for you in the night