Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!computer-science.nottingham.ac.UK!j.onions
From: j.onions@computer-science.nottingham.ac.UK (Julian Onions)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Host requirements and SMTP
Message-ID: <4418.631880236@cs.nott.ac.uk>
Date: 9 Jan 90 10:17:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42


It all seems to me that there is a lot of effort going into brain
damaging protocols like RFC-822 just to work around broken DNS
implementations. In the end, DNS has to provide the service and whilst
pragmatic workarounds are OK for debugging, fixing them in concrete
seems silly.

Surely the solution is improving the DNS rather enforcing the use of
IP addresses in mail addresses. If you allow escapes all the time so
that the DNS can perform poorly, it will most likely continue to
perform poorly.  Yes - it may be occasionally useful to be able to
directly aim mail at an IP address - but is it worth enforcing this
capability. I might make the same claim that if I have a machine with
a broken ARP mechanism it would be useful to mail directly to an
ethernet address without requiring IP or names - but the solution is
to fix the ARP implementation.

In the UK, we had a similar situation for our registry, the NRS. A few
years ago, people were loath to use this database, rarely kept up to
date and only registered new hosts in it when they remembered.
Then in certain implementations of the mail software we started
refusing to accept mail from sites that were not registered (if you're
not willing to identify yourself, we dont want to know + its almost
trivial to loose email in such situations). I won't say this changed
things overnight, but people now realise if they want to be part of
this community, they better play by the rules and there are few sites
now unregistered and everyone makes use of the NRS now.

One of the problems I see with the IP d-lits is that it really isn't
smtp specific - no matter what the HR says. We run RFC-822 (which is
what the question is really about) over several networks, each
supporting their own style of d-lits. The natural course is to follow
the HR which means I need to understand lots of different styles of
d-lits now (IP, X.25, yellow book ...). Its painful after having split
up a system into SMTP and generic RFC-822 components to then have to
go and stick back into the generic components SMTP specific bits.

I guess if you'd split the HR into RFC-821 specific things and RFC-822
specific things maybe this wouldn't have arisen. Perhaps another idea
for a future HR.

Julian.