wales@ucla-locus.ARPA (Rich Wales) (09/18/85)
The following summary of invalid or questionable usage of host names in
outgoing mail is based on approximately 5,700 ARPANET messages received
at LOCUS.UCLA.EDU between 14-Aug-85 and 11-Sep-85.
I analyzed the host names used in the "return path" addresses of
incoming messages (SMTP "MAIL" commands), as well as the names which
the remote hosts used to identify themselves (SMTP "HELO" commands).
Specifically, I attempted to find two different usage patterns for
host names:
(1) Host names which did not appear in the official NIC host name table,
HOSTS.TXT -- since addresses with such names cannot be replied to.
(2) Non-domain-style "nicknames" which appear in the NIC table. Since
these names are not going to be carried over to the new distributed
domain data base, addresses with such names cannot be replied to
from hosts which have converted their software to use the data base.
For this study, I used Version 481 of the host name table (12-Sep-85).
I would make the following recommendations based on this study. Keep
in mind, please, that I am only a "private citizen" and do not hold any
net-wide position of responsibility; these are only suggestions, not
commands from on high.
(1) EVERY host responsible for one of the undefined return-path host
names in Section 1 below should take IMMEDIATE steps to correct the
situation -- either by using the correct host name in outgoing mail,
or by having their name of choice registered with the NIC so that it
will be added to the host name table.
Hosts whose names are in the domain data base, but not in the NIC
table, should consider the fact that -- whether we like it or not --
a sizable fraction of the net has not yet converted to the domain
data base, is not liable to do so for some time to come, and will
thus continue for the time being to be totally dependent on the NIC
table for name->address mappings. You may not like this fact --
indeed, you may consider it to be a bletcherous and utterly irre-
sponsible state of affairs -- but it is nevertheless the way things
are, at least right now. Refusals "on principle" by isolated indi-
vidual hosts to deal with those that are still using the NIC table
is unlikely to accomplish anything (except to make it harder for
people to send mail to each other).
(2) EVERY host responsible for one of the non-domain-style nicknames in
Section 2 below should convert over to the appropriate domain-style
name as soon as possible.
Since NO non-domain-style nicknames (i.e., host names without at
least one period) will EVER be listed in the domain data base, these
nicknames -- however near and dear they may be to the hearts of
their users -- will slowly become useless as more and more hosts
wean themselves from the NIC table and convert over to the domain
data base. No ifs, ands, or buts, folks -- this is REALITY.
(3) Hosts listed in Sections 3 and 4 below should take steps to make
their "SMTP sender" or "net mailer" programs use a correct, domain-
style host name in the SMTP HELO command. As in the case of return
addresses, it is probably advisable (for the time being, at least)
that new domain-style names be registered in the NIC table as well
as in the domain data base.
Although most SMTP servers in use today make no serious attempt to
validate the HELO argument, some people have proposed to check the
sending host's name and to reject the HELO command (thus blocking
mail transfer) if the name is unknown. It therefore makes sense to
ensure that the correct host name appears in the HELO.
(4) Hosts who have converted over to using the domain data base may want
to consider modifying their name->address mapping routines to try
adding ".ARPA" to the end of a non-domain-style host name if it can-
not be found in their tables "as is". (I.e.: if presented with the
host name "PODUNK", try looking up "PODUNK.ARPA" before giving up.)
This will let you make sense of most (though unfortunately not all)
non-domain-style nicknames.
I suggest this (admittedly disgusting) "hack" only because Murphy's
Law dictates that lots of hosts will probably continue to use their
old non-domain-style nicknames until the bitter end -- and maybe
even beyond. Again, our first priority should hopefully be to max-
imize the probabilities that mail will get through -- since large
numbers of users on many systems are mail-naive in the extreme and
will have absolutely not a clue as to what alternatives to try if
the return address on a piece of incoming mail can't be replied to.
Since much of the following summary was processed by hand, it may con-
tain some minor errors. I take full responsibility for these and apolo-
gize in advance to any hosts which I might have inadvertently pointed an
accusing finger at.
Also, I realize that many hosts listed below may already be aware of the
fact that they are using an incorrect host name in their mail -- and are
either at work on the problem, or are looking for a solution. Or, some
hosts may have been using an incorrect name until very recently, but
have now fixed things. My intent in posting this list is not to badger
or criticize anyone; I am simply trying to help make sure everyone is
aware of the problem and is doing whatever they can to resolve it.
Further, let me emphasize that this summary covers only those hosts
which have sent mail to LOCUS.UCLA.EDU during the past month. Just
because a host is not listed does not necessarily mean that they are
doing the right thing with regard to host names in mail.
Since many of the people who most need to read this message probably do
not subscribe to this list, I will also be sending individual messages
to "postmaster" at each affected host (where the identity of said host
can be determined). My apologies in advance to anyone who thereby gets
a "double whammy" (or even a "triple whammy") from me on this subject.
Unfortunately, I am not able to offer any specific help to anyone who is
trying to fix their mail software. In particular, I am not a "sendmail"
guru, and I do not have any fixes to "sendmail" which might be required
in order to make it conform to current name requirements. If anyone has
devised such fixes to various widely used mail systems, it might be nice
if said fixes (or pointers to them) could be posted.
========================================================================
(1) The host name in the return-path address (SMTP MAIL command) is not
in the NIC table.
Return-Path Host Name Host Sending Mail
EAERO2 AERO2.ARPA
EAR.BERKELEY.EDU UCB-VAX.BERKELEY.EDU
HOTDOG.ARPA DECWRL.ARPA
IC.BERKELEY.EDU UCB-VAX.BERKELEY.EDU
IPTO-VAX.ARPA IPTO.ARPA
ISI-DAWN.ARPA.ARPA ISI-DAWN.ARPA
MIRO.BERKELEY.EDU SEISMO.CSS.GOV
MIT-BORAX.MIT.EDU MORDRED.PURDUE.EDU,
SEISMO.CSS.GOV
MIT-CLIO.ARPA SEISMO.CSS.GOV
PLAYFAIR 36.10.0.171
SALLY.LOCAL SALLY.UTEXAS.EDU
TP4 192.5.14.154
NOTES:
(a) The names {EAR,IC,MIRO}.BERKELEY.EDU and MIT-BORAX.MIT.EDU do
appear in the domain data base (but not in the NIC table).
Hence, only hosts which have converted over to the domain data
base can send mail to these places. The wizards at these
places should seriously consider having these names listed in
the NIC table, as well as in the domain data base.
(b) In certain cases above, the "host sending mail" may have been
acting as a relay for the actual originating host. Hence, the
"host sending mail" is not necessarily the correct, official
substitute for the undefined "return-path host name".
(c) I have nary a clue as to the identity of "HOTDOG.ARPA". The
full address was "sci!kuo@HOTDOG.ARPA". Ideas, anyone?
(2) The host name in the return-path address (SMTP MAIL command) is
listed in the NIC table -- but it is a non-domain-style nickname
(and thus will never be in the domain data base).
AERO2 GE-CRD MITRE-BEDFORD SRI-UNIX
AERO3 GLACIER NLM-VAX SU-STAR
AIDS-UNIX GREGORIO NRL-CSS TALCOTT
BBN-UNIX IPTO-VAX NTA-VAX TOVE
BBNCCV ISI-ELVIRA NYU-CMCL2 UCI-ICSA
BERKELEY ISI-HOBGOBLIN OMNILAX UCI-ICSD
CCA-UNIX ISI-VAXA ORNL-MSR UCI-ICSE
CIT-750 JPL-MILVAX PESCADERO WHITNEY
CIT-VAX LLL-CRG ROCKEFELLER YALE-APVAX
DIABLO MARYLAND SAFE
EDN-VAX MIT-EDDIE SRI-SPAM
NOTES:
(a) Berkeley was using domain-style names for a time, but was forced
to switch back to using "Berkeley" for the time being due to
some kind of software problem. The last word I had from them
was that they were hoping to be using domain-style names again
in another month or so.
(b) Most of the above names can be converted to valid domain-style
host names simply by adding ".ARPA". Exceptions to this rule
are the Stanford hosts DIABLO, GLACIER, GREGORIO, PESCADERO,
SAFE, and WHITNEY (whose official domain-style names are,
respectively, SU-AIMVAX.ARPA, SU-GLACIER.ARPA, SU-GREGORIO.ARPA,
SU-PESCADERO.ARPA, SU-SAFE.ARPA, and SU-WHITNEY.ARPA); IPTO-VAX,
whose official domain-style name is IPTO.ARPA; and NYU-CMCL2,
whose official name is NYU.ARPA.
(c) Lots of messages relayed through mailing lists on YALE.ARPA
showed non-domain-style nicknames in return-path addresses --
even though mail arriving directly from the hosts in question
used the official names. I suspect the YALE.ARPA software may
be rewriting the addresses as the mail is relayed through. I
did not include any mail relayed through YALE.ARPA when putting
together the above list on non-domain-style nicknames.
(3) The host name given in the SMTP HELO command is not defined in the
NIC table. (Some of the hosts in this category are not in the NIC
table at all; one is listed only as a gateway.)
The "official name/address" info below is derived from the Internet
address of the host which actually made the SMTP connection.
Official Name/Address Name in HELO Command
AERO2.ARPA EAERO2.ARPA
AIDS-UNIX.ARPA AIDS-GRAPE.ARPA
IPTO.ARPA IPTO-VAX.ARPA
ISI-DAWN.ARPA ISI-DAWN.ARPA.ARPA
MIMSY.UMD.EDU MARYLAND.ARPA.ARPA
MIT-MC.ARPA MIT-OZ
MORDRED.PURDUE.EDU MORDRED.ARPA
NYU.ARPA NYU-CMCL2.ARPA
OMNILAX.ARPA OMNILAX.UUCP
RIACS.ARPA RIACS-GW.ARPA
THINK.COM GODOT.THINK.COM
UCSF-CGL.ARPA UCSF-CGL.UCSF
USC-OBERON.ARPA OBERON.ARPA
YALE-COMIX.ARPA YALE-COMIX.YALE.ARPA
YALE-MTRANS.ARPA YALE-MTRANS.YALE.ARPA
36.10.0.171 PLAYFAIR.ARPA
192.5.14.154 TP4.UUCP
NOTES:
(a) Despite their domain-like appearance, YALE-COMIX.YALE.ARPA and
YALE-MTRANS.YALE.ARPA do not appear in the domain data base.
(b) The name GODOT.THINK.COM is in the domain data base, but not in
the NIC table.
(d) As far as I can tell, MIT-MC.ARPA calls itself "MIT-MC.ARPA"
most of the time. We recorded only two instances in which it
called itself "MIT-OZ"; both times, it was acting as a mail
relay for MIT-OZ (an internal MIT site, not on the Internet).
(4) The host name in the SMTP HELO command is listed in the NIC table --
but it is a non-domain-style nickname (and thus will never be in the
domain data base).
As above, the "official name" info below is derived from the Inter-
net address of the host which actually made the SMTP connection.
Official Name Name in HELO Command
AEROSPACE.ARPA AEROSPACE
AMSAA.ARPA AMSAA
BBNCCM.ARPA BBNCCM
CSNET-RELAY.ARPA CSNET-RELAY
IPTO.ARPA IPTO-VAX
SU-AIMVAX.ARPA DIABLO
SU-GLACIER.ARPA GLACIER
SU-GREGORIO.ARPA GREGORIO
MITRE-BEDFORD.ARPA MITRE-BEDFORD
NRL-CSS.ARPA NRL-CSS
SU-PESCADERO.ARPA PESCADERO
SU-SAFE.ARPA SAFE
TYCHO.ARPA TYCHO
UCI-ICSA.ARPA UCI-ICSA
UCI-ICSD.ARPA UCI-ICSD
UCI-ICSE.ARPA UCI-ICSE
UCL-CS.ARPA UCL-CS
SU-WHITNEY.ARPA WHITNEY
YALE.ARPA YALE
========================================================================
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
3531 Boelter Hall // Los Angeles, California 90024 // USA
ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA
UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales