The following (slightly acerbic) write-up was in response to a user of ERNET complaining about the (lack of) e-mail traffic between their domain and IMSc. In short,

ERNET did some messy things in order to deliver mail which are not compatible with the "Internet Way"!

Introduction on how e-mail is delivered in the Internet era

What follows is a somewhat short introduction to how e-mail is delivered in the Internet era (i.e. specifically not the ERNET/UUCP era) with an explanation of the why and how of DNS (or names and numbers).

What is supposed to happen after the user composes a message addressed to recip@dest.ac.in.

0. The user's mail program forwards this mail to the main mail server say mx.send.ac.in.

The important things to note are four header variables which are set in this process.

   Mail From <sender@send.ac.in>
   Rcpt To <recip@dest.ac.in>
   From: sender@send.ac.in but could be anything!
   To: recip@dest.ac.in but could be anything!

The second important thing to note is that the last two headers are irrelevant for mail delivery!

1. The server mx.send.ac.in uses DNS to find the IP addresses of the mail exchangers (MX records) which receive mail for dest.ac.in. If dest.ac.in has an IP address then it is added to this list.

2. The server mx.send.ac.in runs through the list of IP addresses so found and tries to connect to them in order to see which of these accepts the message.

3. Quite often the recipient machines will perform a reverse DNS lookup to make sure that send.ac.in is a valid mail receiving domain.

4. Quite often the recipient machines will try to find an MX record for send.ac.in to see if one of the machines will accept mail for sender@send.ac.in.

(The logic of 3 and 4 is that to defeat SPAM, dest.ac.in will not accept mail from sender@send.ac.in unless this is a valid sender/recipient of mail.)

5. If none of the MX records works then the mail will be queued and retried after some time for a certain maximum number of tries. The time for which mail is deferred and the number of tries differs from site to site. On the one hand the error may be temporary. On the other hand if the server is down then we want to give the remote site time to recover before bouncing the message back to the sender.

I hope it is clear that a proper DNS setup is not only important for rapid delivery of mail but that an improper DNS setup could render mail delivery impossible. Three out of the five "machine" steps depend on proper DNS. Non-authoritative DNS entries which are automatically short-lived will mean that step 1 will have to be repeated every time increasing delays.

Finally, therefore we come to DNS. There are some rules that govern IP address and Domain on the internet.

A. The adresses 10.x.x.x, 172.16.x.x - 172.31.x.x, 192.168.x.x where x ranges from 0 to 255 are reserved for internal use within organisations. These addresses should never be used on the internet. (They can however be used in an intranet that is "transparently" connected to the internet. This is what we do at the IMSc.)

B. Any address other than the above can only be used if it is assigned by suitable name service authorities. In particular, routing for these IP addresses must be assigned as well.

C. The domain names ending in .in, .edu, .com and so on (there is a list of 100 or so) are only available after applying to suitable authorities. Usually, such an application is only entertained after the applicant has provided IP address(es) of DNS server(s) that will respond to all DNS queries for that domain. Those who verify the application will in particular verify that these DNS servers are functioning correctly before approving the application.

How ERNET dealt with all of this

In a number of ways ERNET was a private subnet of the Internet in the sense that the term is understood now. Therefore it was able to go around A, B and C as well as 2-4.

Now ERNET was setup on the premise that except at the nodal machines of ERNET, all other setups would be rudimentary and would not be able to correctly manage DNS etc. So the ERNET maintained DNS records for everyone and distributed a heavily modified sendmail.cf file which was used to ensure that at steps 2-4 were bypassed. All mail from any ernet address was force-sent to ERNET's primary mail exchangers. In turn, these exchangers accepted mail for all ernet nodes and then force-sent it to the correct ernet sub-domain. Thus improper DNS setup at "user" nodes was irrelevant.

However, many former users of ERNET are perhaps unaware that when they move out of ERNET and into the internet domain and numbering system they must conform to what has been written above. (Though I must clarify that what I have written is a brief summary and not the authoritative version. For that you must refer to the relevant RFC's).