amrad email problems

[Howard Cunningham]

Hi

See my comments preceded by HC:

Howard Cunningham, MCP
Microsoft Small Business Specialist
Macro Systems, LLC
703-359-9211
howardc at macrollc.com - personal
service at macrollc.com - service



-----Original Message-----
From: Robert E. Seastrom [mailto:rs at seastrom.com] 
Sent: Sunday, October 14, 2007 11:54 PM
To: Howard Cunningham
Cc: Tacos; Maitland Bottoms
Subject: Re: amrad email problems


"Howard Cunningham" <howardc at macrollc.com> writes:

> Hi 
>
> At Tacos today there was a discussion about why some
emails
> are not delivered.  I looked at the email that Mike posted
> tonight and found that there are multiple problems with
the
> zone file setting for the amrad.org domain and email..
>
> Emails:
> The mx record specifies 204.29.138.195
> Emails are coming from: received: from atanasoff.rf.org
> ([204.29.138.196])
> That mismatch will cause more and more mail servers to not
> accept and/or reject emails.

Not well-configured nameservers unless there's SPF stuff
that says
only receive from mx ("v=spf1 mx -all").  If you are aware
of any mail
servers that come configured out of the box to refuse
everything that
doesn't come from the proper mx, I'd appreciate a pointer.

 [HC:] I have not seen this behavior out of the box, but I
am seeing more and more mail servers either reject or not
accept emails when the IP address of the sending server does
not match the MX record.  I am not saying that this practice
is correct or even good, we just keep running into it.  

> DNS Issue #1:
> Antanasoff.amrad.org is as an amrad name server but it is
> not listed with the registrar

This shouldn't cause a problem with resolving amrad.org (if
the
reverse were true, i.e. the authoritative servers were a
subset rather
than a superset of the registrar's records) it might cause
slowness.

It is an inconsistency that ought to be fixed.  It is
probably not the
source of mail slowness.

> DNS Issue #2:
> Antanasoff.amrad.org will do recursive lookups.  I
recommend
> that recursion be disabled
>
> 204.29.138.196 reports that it will do recursive lookups

This presents a DNS cache poisoning issue.  It shouldn't be
getting in
the way of resolution.  Agree with Howard that there should
be no
recursive nameservers should also be authoritative
nameservers, but
cavalierly disabling recursion on antanasoff without
ascertaining that
nothing is depending on it for resolution might result in
the IT
equivalent of having golf cleat marks on your tender bits.

So, I suspect that log analysis will help you divine what's
unhappy,
if anything.

                                        ---Rob