Here is the text of a problem report submitted by Cornell University regarding
the CYBER/SYSTEMX user id problems. Any site running the UMASS mailer should
at least take note of this---it may explain why you receive some mysterious
rejections (such as 'YOU ARE A CHARLATAN'). Any IBM sites care to comment on
the proper interpretation of the various fields?
The text follows: (with thanks to Mark Bodenstein and Nick Gimbrone of Cornell)
Closed Log For RSCS Problem 1165 Through 1/30/89
Logger: Mark Bodenstein User: MAB @ CORNELLC Logged: 1/23/89
Reporter: Mark Bodenstein User: MAB @ CORNELLC Update: 1/30/89
Target: --------
Area: RSCS Site: All Stat: Closed Sev: 2 Assignee: No one
Keywords: ACCOUNTING CYBER DMTNHD DMTNJI LM270 LM405 MAIL MAILLOOP NJE NJEF
+-----------------------------------------------------------------------------+
º Bug in RSCS local mod 405 caused mail loop with a Cyber Bitnet site. º
+-----------------------------------------------------------------------------+
Problem Description and Possible Solutions or Bypasses
______________________________________________________
We experienced a mail loop with a file originating from Cal State, which is a
CYBER system running NJEF NJE emulation software. The root cause of the
problem is a mistake in RSCS local mod 405, for ACF2 in MVS, which results in
RSCS getting the wrong value for the originating userid from the NJE Job Header
created by the NJEF software.
Here's what happens:
1. Someone at Cal State sends mail to Cornell, using an Domain Name System
type of address. (If they use a Bitnet type of address, the problem
doesn't happen.)
2. This type of address causes the Cal State mailer to send the mailfile
using BSMTP. It codes the original userid in the BSMTP header.
3. The NJEF software at Cal State sets fields in the NJE Job Header correctly,
but unusually. RSCS sets both the NJGHORGR (origin remote) and NJHGUSID
(userid) fields to be the originating userid. NJEF sets NJHGUSID to be
the originating userid, but sets NJHGORGR to 'SYSTEMXA' - for what reason
I have no idea, but this is valid. (This was later changed to 'SYSTEMX'
which killed the loop, but still didn't fix the problem.)
4. The path from Cal State to here is such that we receive the file on the
CUNYVM link, which is an NJI link.
When our RSCS receives a file over an NJI link, it determines the
originating userid (TAGINVM) by the following algorithm:
TAGINVM = 'SYSTEM'
if NJHGORGR is set in received job header
then TAGINVM = NJHGORGR
if NJHGUSID is set in received job header, AND NJHGACCT IS ALSO SET
then TAGINVM = NJHGUSID
("is set" means has a value other than blank or null)
The test that NJHGACCT (the account field in the job header) is also set
is introduced by local mod 405 (the ACF2 mod). The motivation for this
additional test is lost in history; Gary speculates it may have had
something to do with the old userid preservation mod.
Since RSCS (and presumably most RSCS emulators) set both NJHGORGR and
NJHGUSID, we ordinarily pick up the originating userid from NJHGORGR, and
then ignore NJHGUSID since NJHGACCT is not set. But since NJHGORGR and
NJHGUSID are ordinarily set to the same value, this ordinarily doesn't
matter.
Since the Cyber NJEF NJE emulator sets these fields differently, with them
it does matter. We pick up the origin remote field as the originating
userid ('SYSTEMXA'), and then, since the account field is not set in the
Job Header, ignore the real originating userid in the NJHGUSID field.
5. RSCS puts the incorrect originating userid in the spoolfile tag it creates
for the received file.
6. Our mailer, upon receiving the BSMTP format mailfile, checks to see if it
was received from a trusted mailer. The Cal State mailer is not in the
list of trusted mailers. Since it isn't, the mailer then checks to make
sure that the originating userid recorded in the BSMTP header and in the
RSCS created spoolfile tag are the same. Because of the incorrect userid
picked up by RSCS, they are not. So our mailer rejects the file. It does
so to the userid from the tag, presumably since it trusts this more.
7. It turns out that SYSTEMXA is not a valid userid on a CYBER system (their
userids are limited to 7 characters.) So their mailer sends a rejection
to our mailer. Which sends a rejection to their mailer ... ad infinitum.
The solution is to get rid of the check of the NJHGACCT field in the algorithm
to set TAGINVM described in 4., above.
++++ Closed by Nick Gimbrone (NJG@CORNELLA) on 01/30/89 00:39:50.
Problem resolved w/ OTF of 25Jan.
+--- End of close on Monday January 30th, 1989.
|
