Mailing List SIMS@mail.stalker.com Message #15336
From: Bill Cole <listbill@scconsult.com>
Subject: Re: Why is mail being sent to my webserver...
Date: Wed, 6 Sep 2006 21:21:59 -0400
To: SIMS Discussions <SIMS@mail.stalker.com>
At 4:27 PM -0700 9/6/06, Joe Wagner  imposed structure on a stream of electrons, yielding:
Hi folks,
I confess to being a bit sleep deprived these days, but I can't figure out why some mail servers are trying to send email to my web server rather than the mail servers. I.e. they are trying to send to the machine with the A record for hypertouch.com which is a webserver rather than to hypertouch.com's mail servers which are at other IP addresses.  Now the web server is running a rudimentary mail server but it shouldn't be getting any incoming email and so rejects the attempts as unauthorized relays.

You might want to just have it not answer to external traffic.


I'd credit this to badly setup third party mailers, but Stanford University's mail server recently bounced a message after trying to send to hypertouch.com and I'd hate to think their outgoing mail server is broken.

Are there any circumstances that a mail server should ever send to the A record of a domain when that domain has MX records pointing elsewhere?

No. Doing so is always wrong.

Note that if a mail server can't see those MX records but can see the A, fallback is normal and correct. Nameserver outages, inconsistencies between authoritative servers, and other uncommon but not unknown events can cause that.


We recently had a network outage so all mail servers were down. So if  Stanford couldn't get to the machines pointed to by the MX records, can it grab the A record as a legitimate destination for email (and cache that result).  I've turned off the mail server functionality of the webserver in the short term but I can't understand why I need to?

Any advise or illumination?

Falling back to the A record when none of the MX's are answering is not unknown, but it is bad behavior. Caching the need to do so is possible (e.g. with Sendmail's host status cache) but shouldn't persist for more than a few hours.

It could in theory be related that many places have historically configured their routers with static 'bogon' tables that include long-unallocated address space like 75.*. This started to become a serious problem when 69.* was allocated in 2003, but some people just never learn. For a few months after the initial allocation of new large blocks, it is still common to run into networks that just can't talk to the newly legitimate space.



--
Bill Cole                                  bill@scconsult.com

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster