mdw
|
|
response 10 of 13:
| 
Jul 22 18:06 UTC 1996 |
Arbornet does indeed have "weird" MX records, but that's not the
problem. arbornet.org has two mx records, but they both point to m-net.
m-net also has one mx record, which points to m-net. The two records
for arbornet are redundant; only one is needed. The mx record for m-net
is superfluous, mail would be delivered just as well without it. In
fact, strictly speaking, none of the mx records are needed. The two
reasons one uses mx records are (1) to arrange for a backup site if the
primary site is down, and (2) to specify a host for a domain address
that does not have an A record, or to specify an alternate location for
a host that is not intended to directly receive e-mail. Neither of
these cases are true for m-net so, while the mx records are harmless,
they are not necessary.
The easiest way to see the problem is to say "telnet m-net.arbornet.org
smtp" (note that grex's ip block will deny this for non-members). You
will find you are disconnected nearly instaneously. If you can spy on
the internet traffic, you will find that your end sent a SYN packet to
m-net, and that m-net sent back a RST packet. The most likely cause is
that m-net is not, in fact, accepting smtp connections. The other
possible cause is that m-net's ISP has a firewall (actually, a filtering
router) that "fakes" RST's for smtp ports. This is not, in fact, real
likely, because such routers typically send ICMP packets with
"destination unreachable" error codes instead.
To verify that m-net is not, in fact, accepting connections, you can
say: "netstat -an | egrep 25" on m-net. You should not see a line that
reads:
tcp 0 0 *.25 *.* LISTEN
(Well, actually, you *should*, if m-net in fact accepting incoming mail,
but my guess is that you *won't*.) There are two reasons this could
happen, sendmail wasn't run with the right args, or sendmail has decided
the local host is "too busy" to accept mail. The normal way to have
sendmail receive incoming mail, is to run sendmail with args like this:
sendmail -bd -q31m
The "-bd" says to go into "daemon" mode, & listen for incomign mail.
The "-q31m" says to process the mqueue directory and do resends, every
31 minutes. When sendmail runs, it replaces its args with its current
status. Normally, the process that is accepting connections will say:
sendmail: accepting connections
If sendmail is rejecting incoming connections, it will say:
sendmail: rejecting connections: reason
where reason is normally "load average: %d". (%d will be replaced with
the system load average, according to sendmail's last measurement.) You
can also find other values, such as:
XAAA23523 coast.net: user open
(a sendmail which is sending mail to another site), or
running queue: /usr/spool/mqueue
(when it is processing the queue),
server coast.net cmd read
(a child process, which has accepted a connection from coast.net, and is
currently awaiting a command from there.)
If m-net is still running smail, then the above information on the "ps"
command name will be wrong, and the information on how "sendmail" should
be invoked is probably also incorrect. The information on "netstat"
will still be correct. As I recall, smail would normally be invoked
from /etc/inetd.conf, possibly via the tcp wrapper, and would nearly
immediately after invoke smail, possibly with a "-bs" argument. If the
tcp wrapper is being used, one of the things to check is that the
wrapper is in fact configured correctly, to receive mail from elsewhere.
My guess is that this is not a wrapper problem, from the speed at which
the connection was closed.
One other thing worth mention is that, because m-net has been down so
long, we have put a kludge into *our* sendmail which acts as if there
were a MX record for m-net, directing mail to Mail.coast.net instead.
The reason we've done this is because the extra retries were burdening
grex, and because many of the people who were sending mail either had
return addresses pointing back to m-net, or invalid return addresses,
and so this mail was all bouncing to the grex postmasters, who couldn't
do a thing to fix the problem. We will probably take this out again, if
mail to m-net ever starts working. It would be a Good Thing, if m-net
were to add Mail.coast.net (or another reliable site) as a backup mail
MX site. Until recently, m-net had vela.oakland.edu as a backup site,
but that seems to have disappeared (did oakland get pissed off?)
|