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
- The user's mail program forwards this mail to the main mail
The important things to note are four header variables which are set in this process.
Mail From <firstname.lastname@example.org> Rcpt To <email@example.com> From: firstname.lastname@example.org but could be anything! To: email@example.com but could be anything!
The second important thing to note is that the last two headers are irrelevant for mail delivery!
mx.send.ac.inuses DNS to find the IP addresses of the mail exchangers (MX records) which receive mail for
dest.ac.inhas an IP address then it is added to this list.
mx.send.ac.inruns through the list of IP addresses so found and tries to connect to them in order to see which of these accepts the message.
Quite often the recipient machines will perform a reverse DNS lookup to make sure that
send.ac.inis a valid mail receiving domain.
Quite often the recipient machines will try to find an MX record for
send.ac.into see if one of the machines will accept mail for
(The logic of 3 and 4 is that to defeat SPAM,
dest.ac.in will not accept mail from
firstname.lastname@example.org unless this is a valid
sender/recipient of mail.)
- 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
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
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
.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
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
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).