RFC 974:MAIL ROUTING AND THE DOMAIN SYSTEM
RFC-Ref

domain


Click on the red underlined text to get to the source

... to route a message addressed to a given Internet domain name. This involves a discussion of how mailers interpret MX RRs ...
... Under domains, one cannot simply open a connection to LOKI.BBN.COM, but must instead ask the domain ...
... domains, one cannot simply open a connection to LOKI.BBN.COM, but must instead ask the domain system where messages to LOKI.BBN.COM are to be delivered. And the domain system may direct a mailer to ...
... but must instead ask the domain system where messages to LOKI.BBN.COM are to be delivered. And the domain system may direct a mailer to deliver messages to an entirely different host, such as SH.CS ...


... What the Domain Servers Know ...
... The domain servers store information as a series of resource records (RRs ...
... (RRs), each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of a RR ...
... host). The simplest way to think of a RR is as a typed pair of datum, a domain name matched with relevant data, and stored with some additional type information to help systems determine when the RR is relevant. For ...
... RRs known as MX RRs. Each MX matches a domain name with two pieces of data, a preference value (an unsigned 16-bit integer ...
... CNAME) RR, which simply states that the domain name queried for is actually an alias for another domain name, which is the proper, or canonical ...
... RR, which simply states that the domain name queried for is actually an alias for another domain name, which is the proper, or canonical, name; and the Well Known Service ...
... network services (such as SMTP) a given domain name supports. ...


... routing information is out of date or incomplete. Out of date information is only a problem when domain tables are changed. The changes will not be known to all affected hosts until their resolver caches ...
... caches flushed. In other words, given proper precautions, mail looping as a result of domain information should be avoidable, without requiring mailers to query authoritative servers. (The appropriate precaution ...
... The incomplete data problem also requires some care when handling domain queries. If the answer section of a query is incomplete ...
... RRs may be left out. This may result in mail looping, or in a message being mistakenly labelled undeliverable. As a result, mailers may only accept responses from the domain system which have complete answer sections. Note that this entire problem can be avoided by only using virtual circuits ...
... situation is likely to be very rare and datagrams are the preferred way to interact with the domain system, implementors should probably just ensure that their mailer will repeat a query ...


... is discussed in terms of the problem of a mailer on a host with domain name LOCAL trying to deliver a message addressed to the domain name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically ...
... host with domain name LOCAL trying to deliver a message addressed to the domain name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically correct domain names ...
... domain name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically correct domain names. Furthermore, LOCAL is assumed to be the official name for the host on which the mailer resides (i.e., it is ...


... for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain ...
... the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route ...
... route in-transit messages for defective hosts by simply changing their domain databases. ...
... Getting no response to the query. The domain server the mailer queried never sends anything back. (This is distinct from an answer which contains no answers to the query, which is not an ...
... probably be treated differently. For example, a response code of "non-existent domain" should probably cause the message to be returned to the sender as invalid, while a response code ...
... RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical ...
... query should be repeated with the canonical domain name. ...
... aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias ...
... RRs for domain name REMOTE (or REMOTE's true domain name if REMOTE was a alias). The next section describes how this list is interpreted. ...


... delivering a message is mentioned, all that is meant is that the mailer should do whatever it needs to do to transfer a message to a remote site, given a domain name for that site. (For example, an SMTP mailer will try to get an address ...
... SMTP mailer will try to get an address for the domain name, which involves another query to the domain ...
... domain name, which involves another query to the domain system, and then, if it gets an address, connect to the SMTP ...
... network to the address associated with a given domain name is not within the scope of this memo. ...
... MX). In addition, the mailer should do no further processing on the list, but should attempt to deliver the message to REMOTE. The idea here is that if a domain fails to advertise any information about a particular name we will give it the benefit of the doubt and attempt delivery ...
... For each MX, a WKS query should be issued to see if the domain name listed actually supports the mail service desired. MX RRs ...
... service desired. MX RRs which list domain names which do not support the service should be discarded. This step is optional, but strongly encouraged. ...
... If the domain name LOCAL is listed as an MX RR, all MX RRs with 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 ...
... 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 ...
... 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 ...


... network which simply state that any mail to a domain is to be routed through a relay. For example, at the time that this RFC is being written, all mail to hosts ...
... a relay. For example, at the time that this RFC is being written, all mail to hosts in the domain IL is routed through RELAY.CS.NET. This is done by creating a wildcard ...
... of RELAY.CS.NET. This should be transparent to the mailer since the domain servers will hide this wildcard match. (If it matches *.IL with HUJI.IL for example, a domain ...
... domain servers will hide this wildcard match. (If it matches *.IL with HUJI.IL for example, a domain server will return an RR containing HUJI.IL, not *.IL). If by some accident a mailer receives ...
... an RR with a wildcard domain name in its name or data section it should discard the RR. ...
... route through. This decision making is outside the scope of this memo, although mailers may well use the domain system to help them decide. However, once a mailer decides to deliver a message via the Internet ...



Google
Web
RFC-Ref