>The message below is from the admin at the school where our
>mail is being returned undeliverable. What do you think ?
>Arcadia (all schools under "tusc.k12.al.us" for that matter) have three MX
>records for their domains:
>
>arc.tusc.k12.al.us. 4H IN MX 5 www.arcadia.tusc.k12.al.us.
>arc.tusc.k12.al.us. 4H IN MX 10 arcadia.tusc.k12.al.us.
>arc.tusc.k12.al.us. 4H IN MX 20 ns1.tusc.k12.al.us.
This means that their primary mail server is www.arcadia.tusc.k12.al.us,
and that arcadia.tusc.k12.al.us and ns1.tusc.k12.al.us are their backup
mail servers. They are telling the world that mail really should go to
www.arcadia.tusc.k12.al.us (but that the other 2 mail servers can be used
as backups).
>The first two MX records will never be accessible (207.79.237.11) via SMTP
>(port 25) or POP (port 110) - this is by design.
A terrible, wasteful design. Sorry, but it had to be said. It's a *huge*
waste of Internet resources.
First, a mail server will try reaching www.arcadia.tusc.k12.al.us. The
sending mail server will send out TCP packets that it doesn't get a
response to. It's going to tie up socket resources on the sending server
until it times out, sending numerous TCP packets. It's bad Internet
behavior to advertise a site that will silently drop connections (which I
believe violates the RFCs, but I'm not positive on that).
Then, it will have to look up the A record for arcadia.tusc.k12.al.us,
since it isn't sent in the DNS packet. That's going to take more
time. That's just plain bad Internet behavior to advertise a host name
that doesn't have an A record -- I can't see any valid reason to do that.
>Mailers will (should) query a DNS server, get a listing of all MX records
>for a site, and
>attempt to rotate thru the MX records for delivery.
True, but there is nothing in DNS or SMTP specs that talk about advertising
mail servers that don't exist, are intentionally down or unreachable, etc.
> >20011212 095518 127.0.0.1 SMTP (2016) 421 SMTP service not available,
> >closing transmission channel
>
>Any attempt to connect to port 25 (ie, telnet www.arc.tusc.k12.al.us 25)
>will not happen - it would be the same as attempting to telnet to an IP
>address with no machine on it. Thus the 421 error is _not_ being returned
>by www.arc.tusc.k12.al.us but rather by something else - I suspect the
>program running at 127.0.0.1
That's not coming from IMail. Either www.arc.tusc.k12.al.us is returning
it, or something (firewall or router, I would guess) is FUBAR (*nothing*
should be returning the 421 code except the mail server itself). Given all
the other "creative features" of the domain, it's tempting to say that
arc.tusc.k12.al.us should be considered guilty until proven innocent, but
that likely isn't the case.
>If a connection fails then 127.0.0.1 should query DNS, see all MX records
>involved, and round-robin down until all MX records have been tried. Your
>localhost guy (127.0.0.1) closes the initial connection attempt without
>attempting to go to any other MX records.
That's what it is supposed to do, since it's getting the 421 code.
So here's a summary of the issues so far:
arc.tusc.k12.al.us has screwy DNS records that they are happy with, that
although strange, unnecessary, and wasteful, shouldn't prevent mail from
being delivered (IE "Hopefully, they will consider changing their DNS
records, but a good mail server should be able to handle it."). This by
itself (or the missing reverse DNS entry) shouldn't be causing the problems.
The problem is coming from a mystery "421" error code that doesn't seem to
have an identifyable source. If everything is working the way it should
(IMail, routers, etc.), it's coming from www.arc.tusc.k12.al.us. If not,
there's a piece of software/hardware in between that is broken. Given that
these 421's are happening on other sites as well, I'm guessing something on
the sending end (the IMail side, not arc.tusc.k12.al.us) is returning the 421s.
To start debuging this, you should first try telneting to port 25 on
www.arc.tusc.k12.al.us -- if it doesn't return a 421, it would seem as
though IMail is causing the problem (which I highly doubt; it doesn't seem
to have the exact text that is being returned in it's .exe file). If
telneting does report a 421, the problem is somewhere between you and them
-- I've tried telneting to port 25 of that server, and it doesn't seem to
answer.
-Scott
---
Declude: Anti-virus, Anti-spam and Anti-hijacking solutions for
IMail. http://www.declude.com
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
