philipp@GIPSI.GIPSI.FR (Philippe Prindeville) (03/16/90)
Is it time yet to decree that A records should not be used in lieu of the MX records when delivering mail? It would seem that the "transition" period is well commenced, and it is time to cut-over... -Philip
oberman@rogue.llnl.gov (Oberman, Kevin) (03/21/90)
In article <9003151416.AA13535@Gipsi.Gipsi.Fr>, philipp@GIPSI.GIPSI.FR (Philippe Prindeville) writes... >Is it time yet to decree that A records should not be used in >lieu of the MX records when delivering mail? It would seem >that the "transition" period is well commenced, and it is >time to cut-over... What exactly do you mean by "in lieu of MX records"? RFC-1123 does not talk about any transition period. It only describes the sequence of DNS queries and how they should be responded to. Certainly any mailer should make use of MX records. But I have never seen any suggestion that some magic "transition" will ever take place when A records will simply be ignored. Or am I mis-understanding the point? R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
craig@NNSC.NSF.NET (Craig Partridge) (03/22/90)
> Is it time yet to decree that A records should not be used in > lieu of the MX records when delivering mail? It would seem > that the "transition" period is well commenced, and it is > time to cut-over... Philip: Which of the following two cases are you proposing we stamp out? (1) Mailers that never look for MX RRs? [I think these folks have plenty of incentive to fix this -- their mailers can't get certain places otherwise]. (2) Mailers that follow RFC 974 and look for an A RR if an MX RR doesn't exist. [There are folks who say this is a convenient shorthand, that spares them the need to enter all those MX RRs when they aren't needed]. Craig
LARSON@CRVAX.SRI.COM (Alan Larson) (04/05/90)
Recently I wrote: >> Suprisingly, it is a technical error for the MXer of highest preference >> to not be the host itself. This would result in an empty MX list after >> removing irrelevant RRs in the MXer of highest preference. This is an >> error condition, although it is noted that "974 points out that "extremely >> persistent mail systems might want to try a delivery to REMOTE's address..." Michael Stein caught me for not stating one of my assumptions when he asked: >What about the case where there are "non-internet" paths to >the host from the MXer of highest preference? Michael is quite correct in noting this. RFC974 expects that the MXer of highest preference (which it calls LOCAL) will know how to deliver the mail without resorting to the domain name system. My assumption was that the last hop to the final destintion host was also a DNS resolved internet hop, which is clearly not always the case. I have attached the relevant paragraph from RFC974 at the end of this message for those who do not have a copy. Alan After removing irrelevant RRs, the list can again be empty. This is now an error condition and can occur in several ways. The simplest case is that the WKS queries have discovered that none of the hosts listed supports the mail service desired. The message is thus deemed undeliverable, though extremely persistent mail systems might want to try a delivery to REMOTE's address (if it exists) before returning the message. Another, more dangerous, possibility is that the domain system believes that LOCAL is handling message for REMOTE, but the mailer on LOCAL is not set up to handle mail for REMOTE. For example, if the domain system lists LOCAL as the only MX for REMOTE, LOCAL will delete all the entries in the list. But LOCAL is presumably querying the domain system because it didn't know what to do with a message addressed to REMOTE. Clearly something is wrong. How a mailer chooses to handle these situations is to some extent implementation dependent, and is thus left to the implementor's discretion. -------
LARSON@CRVAX.SRI.COM (Alan Larson) (04/07/90)
My apologies for accidently resending a quoted article, originally by
Christopher JS Vance. His article ended with the comment:
>When I specify both A and MX records for a name, I mean what I say...
By my reading of the RFC, things should behave as you described wanting.
I sense agreemenmt here.
Alan
-------WHITESID@McMaster.CA (Fred Whiteside) (04/09/90)
Christian Huitema <huitema@jerry.inria.fr> writes: > If the host has an A record, then the host is reachable directly via > the Internet. If one does not want to list that host as the MXer of > highest preference, it is probably that one does not want to receive > mail directly on that system, but rather feed the mail through some > "central" server. Indeed, there might be some good reasons for that, > like not wanting to receive mail directly on a PC.. BUT!! Invalid assumption. I have several machines which are directly on the network that _cannot_ process SMTP (the two that spring to mind are VMS vaxen with Bridge communications IVECS boards. These things look like DMF's to the Vax and process the TCP Telnet on the board). These machines want mail, but they *must* have it delivered via a decnet channel. The MX forwarders for these machines understand this so it all works. > Rather than prohibiting mailers to look at A records, Philip should > rather consider cleaning his own house, and not advertise the > addresses of PC or work stations as valid mail addresses! I can envision a scenario where I have seen an ftp connection from some machine to my site and I want to send mail to root@thatmachine for some logical reason. I reverse-lookup the IP address and send mail to POSTMASTER@TheLooked-upAddress. The machine may be a PC which won't handle inbound TCP connections and thus I should have an MX record for the machine that points to a mailer that Knows What To Do. The MX records are there for a good reason. Let's use them properly. A records are host addresses. MX records are where you want the mail delivered. It's quite simple. -Fred Whiteside McMaster PostMaster, DNS Maintainer and Guy Who Worries About Such Things