Computer systems blamed for feeble hurricane response?

Tue Sep 13 19:50:12 UTC 2005

On Tue, Sep 13, 2005 at 07:23:33AM -0700, william(at)elan.net wrote:
...
> Which indeed means they have no MX servers listed and that MAY be a 
> problem for some mail servers (though normally mail servers are supposed 
> to send email based on A record then).
> 
> Obviously not having MX record is not considered to be good email
> service setup in this century and it also means if they receive
> too many messages and their mail server can not handle all the
> connections, the mail will bounce (since there is no secondary
> mail server to go to).
...

Wrong ...

On Tue, Sep 13, 2005 at 09:36:39AM -0500, Larry Smith wrote:
...
> Actually it is worse than that.  fema.gov has an IP (205.128.1.44) which does 
> not respond for mail so most MTA will try the IP first, meaning that most 
> mail will fail even is ns.fema.gov or ns2.fema.gov do answer for mail.
...

Wrong ... in detail, anyway ...

On Tue, Sep 13, 2005 at 10:39:21AM -0400, Christian Kuhtz wrote:
...
> Uh, which mainstream mail server out there is ignorant enough not to 
> send to A record?
...

None, one may hope, although MS keeps amazing me ...

On Tue, Sep 13, 2005 at 10:44:56AM -0400, Mike Tancsa wrote:
...
> SOA said root.ns2.fema.gov. It might be someone actually read's roots mail ?
...

This [deliberate human intervention] is the ONLY WAY that mail might be
delivered to ns2.fema.gov ...

On Tue, Sep 13, 2005 at 08:06:57AM -0700, william(at)elan.net wrote:
...
> So having no MX server is really not such a good idea nowdays...
> 
> Obviously FEMA's problems are a lot worth since ip address 205.128.1.44
> is behind firewall and does not accept port 25 connections.
...

*sigh*

On Tue, Sep 13, 2005 at 11:51:27AM -0700, David Ulevitch wrote:
...

I want to comment that Dave's observations about backup reliable comms
opportunities seemed quite right.  If "the people who should" don't,
there should be some backup way for others with not quite the right
"in" to get through.

Mostly, I would like to invite all of the above to read RFC 2821, which
has specific comments on all of the above.  Any alleged mail server that
dosn't conform to RFC 2821 isn't doing its job.

If there are MX records, the server must try all IP addresses (from A
records) of all hosts listed in the MX records.  If there are no MX
records, the server must try all IP addresses associated with A records
of that domain.  If there are no MX records and no A records, no
delivery may be attempted.  NS records do NOT name candidates for mail
delivery.

If one of the mail servers responds, and indicates a permanent failure,
then a failure response gets delivered right away.  Otherwise, if the
delivery does not succeed right away, the message must be stored and
attempts made at reasonable intervals for a reasonable amount of time.
No distinction is made between addresses from MX record hosts or from A
records.

There is no requirement - even in this century - for MX records.  It is
a Good Idea(tm).  But not a requirement.  Lack of MX records does NOT
mean that you lose the store-and-forward capability of SMTP.  Lack of a
secondary server, while equally not a Good Idea(tm), does NOT mean that
you lose the store-and-forward capability, only that you exercise it
more often.

I know that there are books somewhere that expound in more literary
language on the concepts in RFC2821.  But this is the source.  Please
read it and refer to it during any discussion of e-mail service.

Thanks.

Oh, and also ... please consider that some firewalls try to discern
whether the connection on port 25 is from a mail server or from Telnet.
While I mourn the simplicity of manual debugging of such sites, it
remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean
that there's no mail service there.  (It could also be temporarily
down.)

-- 
Joe Yao
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.