[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mail, Domain Names, NSLUG, and 7.2 and 8.0, and the coming ice age in Hell.



    Date: Tue, 15 Dec 87 09:21 EST
    From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>

    Resolution of "domain" names in Arpanet mail, names such as
    "symbolics.com", don't work well anywhere on the Arpanet as far as I
    know.

Kind of true, of course, Symbolics has not lifted an eyebrow to make
things any easier:

Mabry's problem is really two:

 1) How does mail get routed to the correct host, and
 2) What messages does a specific mailer accept.

Mabry offered one fix to problem 1, another is listed below.  As for
problem, 2, well this gets into my favorite flame:

Symbolics, to its credit, did try to implement domain addressing and
created domain resolvers and name servers.  A domain resolver takes the
request from a user concerning an address and formats it according to
spec, and ships it off to the name server to be answered.  The name
server determines the answer (it may determine someone else to ask) and
sends that information back to the resolver who sends it back to the
user.

Unfortunately, the RFCs were misunderstood (an easy thing to do) and
while all of the functionality seems to have been implemented, the
functionality was incorrectly split between the resolver and the name
server.  Essentially, a Symbolics domain resolver is expected to walk a
tree of all possible queries and the Symbolics name server is supposed
to simply answer each query, yes or no.  According to the RFC, the
resolver should only start the tree at the top node and the name server
should keep expanding the tree until an answer is found.  The net effect
(pun intended) is that if an ARPAnet domain resolver happens on the
exact question to ask the Symbolics name server all is well.  But, if it
doesn't ask the exact question, but asks instead any correct question,
the Symbolics name server will not take the initiative and follow the
search tree.

Now, a mistake is a mistake, but what really is upsetting is how
Symbolics has reacted to this problem.

A.  The problem has been known for a very long time.  We discussed it 
    prior to the National Slug Meeting in June and again at NSLUG.

B.  The problem is conceded to be serious and very important to
    Symbolics.  At NSLUG, a Symbolics network spokesman stated that
    domains were very important to Symbolics, and that it was crucial to
    get working code as quickly as possible.

C.  It appears that much of the code is there, it just needs to be
    rearranged.  If you poke around with what internals you can find (by
    hunting around in the source to mail) and watch what happens in the
    domain server log, it appears that the basic functionality is there.

D.  I am told that this will not be fixed in 7.2.

E.  I am told it doesn't seem as though in will be fixed in 8.0.

F.  Symbolics can create a kluge to fix the immediate problem posed by
    Mabry Tyson: they could make a local fix at Riverside to answer ANY
    query about mail sent to Symbolics.DIALNET.COM as if they knew the
    host (and they probably do -- they picked the domain address)

G.  It doesn't seem like it should take more than six months (from NSLUG
    to now) to fix this.  To implement the basic functionality from what
    they have should only take a few weeks.  (Days?  The stuff is there,
    but needs to be rearranged)  This would not yield the friendliest of
    domain systems, but it would produce a working version.

H.  They are very tight lipped about it all.  The code was at first
    restricted and now it is supposedly optional.  Well terrific, I have
    to buy the source so I can fix the problem.  And on another issue,
    just what is customer-reports for?  Several have told me on occasion
    that they are not allowed to fix code or issue patches.  Well if I
    can't get a patch or fix out of them, then I want to be paid for
    finding/documenting/reporting the problems.

I.  I have offered to take the code, fix the problem, return the code
    and all for free.  I have never heard a response to that.

J.  Customer Reports personnel and others have queried the local
    constabulary (some sort of review committe) about releasing the code
    to me for this person. I have been told they would contact me; I
    have never received a response.

Mabry offered one solution to problem one, here is a nasty kluge for
those sites on dialnet.  In essence, this takes any mail to a host which
is unknown at your site and forwards it to riverside.  (Change
YOUR-MAILER appropriately)

(defvar *squawk* t)
(advise NETI:FIND-DOMAIN-MAIL-HOSTS :around stomp-on-riverside nil
  (let ((host-address (first arglist))
	(values (multiple-value-list :do-it)))
    (when *squawk*
      (su:log-event :debug "Advise for find-domain-mail-host")
      (su:log-event :debug "  Arglist ~S" arglist)
      (su:log-event :debug "neti:find-domain-mail-hosts looking for ~A" host-address)
      (su:log-event :debug "First resolution: ~S" values))
    (if (and (stringp host-address)
	     (string-equal "YOUR-SITE.dialnet.symbolics.com" host-address))
	(setq values
	      (list
		(list
		  (net:parse-host "YOUR-MAILER.YOUR-SITE.dialnet.symbolics.com")) t))
	(when (equal values '(nil nil))
	  (let ((*squawk* nil))
	    (setq values
		  (multiple-value-list
		    (neti:find-domain-mail-hosts "riverside.scrc.symbolics.com"))))))
    (when *squawk*
      (su:log-event :debug "Resolution: ~S" values))
    (return (values-list values))))

I don't have a kluge for number 2 though.

All is not lost however, we have recently made use of a very cheap
product ($50 gets you executable and SOURCE to PMDF) to hook VMS up with
a domain mailer (not store and forward) which lets you use normal VMS
mail to send/receive mail over a phone line from VMS systems with PMDF
or UNIX systems with MMDF.  In fact, it allows VMS systems to hook up
over bitnet or tcp to anyone running the phonenet (?) protocol.  This
package is available for $50 from Harvey Mudd College.  For information,
send mail to <Ned@Ymir.Claremont.EDU>.

Jerry Bakin.
(213) 417-7997
<@Riverside.SCRC.Symbolics.COM:Jerry@Inference.Dialnet.Symbolics.COM>

Typical disclaimer about Inference and this message....