HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.lstsrv-l
Date:         Wed, 2 Sep 1992 10:56:48 CST
Comments:     Converted from PROFS to RFC822 format by PUMP V2.2X
From:         Adam Floro <CA1225@SIUCVMB.SIU.EDU>
Subject:      LISTSERV Questions

From:  Adam Floro

I am providing technical assistance to our local LISTSERV
administrator.  I need help with a few problems I've been
encountering with LISTSERV and was hoping someone could help me.

First of all, I am trying to 'get' LSVPUT EXEC from LISTSERV
and it won't send it to me.  LISTSERV says LSVPUT EXEC is
unknown.  What's wrong?  Should I add this to a FILELIST
such as TOOLS FILELIST?

I'm also trying to get and put LOCAL SYSVARS and that will
not work either.  Presumably for the same reasons as the
above problem.  Any ideas?

Also, we defined a 200 disk following Ben Chi's doc.
We added the following to LOCAL SYSVARS as instructed
by Ben Chi:

  MDISK.200 = '* N W L 85 95 //200: public file library.'
  CHECKMDISK = CHECKMDISK '200'

We told LISTSERV to link to 200, did a STOP REBOOT, and then
a QUERY DISK, and there's no 200 disk accessed.  Ben, are
you listening?  Any ideas on this one?

Finally, where can I find the LISTSERV Library mentioned in
Appendix A of some of documents I am using for LISTSERV.
I seem to be missing some of the documents and need to retrieve
the rest.  Where are they?

Any assistance is greatly appreciated.

-------------------------------------------------------------------------

Adam Floro                                Bitnet:  CA1225@SIUCVMB
Systems Programmer                      Internet:  CA1225@SIUCVMB.SIU.EDU
Southern Illinois University                  IP:  CA1225@131.230.1.2
Carbondale, IL 62901                       Voice:  (618) 453-6238
From: USDGK@VTVM1.BITNET (Greg Kroll)
Newsgroups: bit.listserv.lstsrv-l
Subject: getting a filelist 80 column or less format
Date: 28 Aug 92 17:21:25 GMT
Organization: Computing Center, Virginia Tech.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

I'm not used to working in a non-VM environment when it comes to LISTSERV
but I got a question about the format files are sent in, specifically,
the filelist file, if it contains records greater than 80 bytes.  I tested
this and sure enough LISTSERV sends the file in Listserv-Punch format
no matter what you specify on the "F=fformat" option of the get command,
IF the file contains records greater than 80 bytes.  Won't a list keeping
notebooks ALWAYS have a filelist greater than 80 bytes?
Is there anyway to override this?  Is there a way to send the filelist
truncated to 80 bytes or less?  Thanks in advance for you help.


--Greg Kroll
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-From: The MITRE Corporation, Bedford, MA
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 09:16:37 -0400
From:         MacFarland.Hale@HECKLE.MITRE.ORG
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: "Electronic Data Interchange Issues" <EDI-L@uccvma.ucop.edu>
              25 Aug 92 18:45:00 -1100. <9208260007.AA25574@mbunix.mitre.org>

True, Dave, the code must be executed, but I don't think this would be too
tough for the person in Bill's example.  This person has an intimate knowledge
of the EDI software in use on the trading partners' PCs.  Some EDI packages are
organized into separate executable modules that call one another.  A virus
could be passed using the 841 transaction with a file name equivalent to one of
these modules.  If the EDI software doesn't check the file name, it could
overwrite this module and, once that module is next called, the virus is off
and running.  The virus could, among other things, perform the functions of the
original module so as to hide itself as long as it pleases.

In this scenario, the virus is spread without using any direct system utilities
(e.g., cron) at all.  Even a security-conscious PC owner could be stung this
way, unless the EDI software is configurable to prevent overwriting its own
modules (I doubt many are at this time).

This is just off the top of my head, but it seems all too possible to me.
Thanks, Bill, for looking into this - it's important stuff.  However, I'm not
looking forward to dealing with this issue!!  :-(

	Mac

	MacFarland Hale			machale@mitre.org
	The MITRE Corporation		(617) 271-3703
	202 Burlington Road, MS K331	(617) 271-2352 FAX
	Bedford, MA  01730-1420

> A good treatise, Bill, but I think you're overlooking the fact that a
> worm or virus must be initiated (i.e., run) before anything can happen.
> There is no code that can start itself.

> Given a thorough understanding of the OS to which the code is shipped, a
> malefactor could attempt to make use of a facility which might be present
> at that site (i.e., CRON) as a 'kickoff' mechanism. But the number of
> sites with loose enough security on these facilities should be tiny.

> -dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-From: The MITRE Corporation, Bedford, MA
Newsgroups: bit.listserv.edi-l
Date:         Sun, 30 Aug 1992 13:38:42 -0400
From:         MacFarland.Hale@HECKLE.MITRE.ORG
Subject:      UNIX Security and Manageability
Comments: To: EDI-L@uccvma.ucop.edu

Regarding John Nagle's reference to my UNIX security "joke":

I didn't mean UNIX is the best choice for an "orange book" environment - my
comment was relative to a discussion of DOS security features.  UNIX certainly
does have more security tools than DOS.  By the way, UNIX was not designed to
be secure, but it was designed with the necessary characteristics to make
security serviceable.  Whether a sysadmin uses these services properly is a
different matter.

Which leads me to Randall Smith's comments about the manageability of UNIX.  I
agree wholeheartedly that UNIX is a bear to manage.  However, there are some
programs and tools that I use in a lab setting that, as written, require UNIX
to run.  I believe most of them could be re-written to run on other platforms
but, for one reason or another, the developers have not done so.  When it comes
to my day-to-day business (non-lab) tasks, I use a Macintosh. :-)

Overall, I don't think there are good "generic" reasons to choose one
operating system over another.  If you've got a job to do, you should first
find the application software that meets your needs.  THEN select an operating
system based on the software's requirements.  Same goes for hardware.  Making
generalities like "UNIX is better than DOS" or "a Macintosh is better than a
standard PC" is hogwash.  It all depends on what you're trying to do.

The above paragraph applies directly to EDI software as well.  Yes, I know we
all can't buy a new system each time we have a new application.  In such a
case, the system is one of your SPECIFIC requirements in evaluating software
to meet your needs.  It still doesn't mean your system is the "generic best
choice" for EDI.

	Mac

	MacFarland Hale			machale@mitre.org
	The MITRE Corporation		(617) 271-3703
	202 Burlington Road, MS K331	(617) 271-2352 FAX
	Bedford, MA  01730-1420
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Fri, 4 Sep 1992 09:57:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      RE: more 841's
Comments: To: MWebster <EDI-L@uccvma.ucop.edu>

>>>I would question whether or not it would be real Texas smart to allow
>>>updates recieved in that matter to replace existing modules anyway.
>>>Surely you would want to insure recoverability in case the upgrade got
>>>damaged
>
>>That's what backups are for.....
>
>Unfortunately, not all end users DO backups.  As has been already noted
>many desk top users, especially in a DOS based environment, are not
>sophisticated.  Counting on user back-ups to cover transmission problems
>of software updates is IMHO a major weakness of any system.
>
>EDI, especially PC based, is beginning to proliferate to a lot of SMALL
>shops.  Places who have never even considered data security, backup or
>any other related issues.  They are using EDI because their largest
>customer said "DO it or else, and here's the software to use".
>
>
>
>>>Anyway, the whole issue reminds me of the reason we put locks on doors,
>>>to keep the honest people out.  Those who would create and distribute
>>>virus, worm, or other destruction-for-no-cause mechanisms would
>>>probably be well served if they were given a dose of that good ol'
>>>Texas justice I grew up with.  My methods are simply this:  treat the
>>>honest people with respect, give the dishonest ones enough rope to hang
>>>themselves with, then sue their pants off just before you kick the
>>>horse out from under them.
>>
>>I believe that anyone who operates a potentially destructive piece of
>>machinery (car, PC, etc.) should be fully qualified and licensed. But
>>then, I also think that voters should be qualified........<g>
>
>Nice sentiment, but it won't happen in our lifetimes.  In the meantime,
>we need to at least consider how to deal with worst case situations.
>(Sort of like defensive driving, but Texans wouldn't understand that
>idea <g> )

Sorry, but I don't believe its a vendor's place to protect me from myself.
Warn me about dangerous consequences, tell me about protective measures,
even nag me about them. Otherwise, let me use my system the way I want to.
If I think the 841 is a dandy way to trasmit software upgrades (I don't,
email is much better) then don't do anything in your software to prevent
me.

-dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-Receipt-To: DKEARNS.TCC@klaven.tci.com
Newsgroups: bit.listserv.edi-l
Date:         Tue, 25 Aug 1992 18:45:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      RE: Viruses, worms, wildlife & EDI
Comments: To: BLaidley <EDI-L@uccvma.ucop.edu>

A good treatise, Bill, but I think you're overlooking the fact that a
worm or virus must be initiated (i.e., run) before anything can happen.
There is no code that can start itself.

Given a thorough understanding of the OS to which the code is shipped, a
malefactor could attempt to make use of a facility which might be present
at that site (i.e., CRON) as a 'kickoff' mechanism. But the number of
sites with loose enough security on these facilities should be tiny.

-dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: EDI-L@UCCVMA.BITNET
X-VMS-To: MAILER%"EDI-L@UCCVMA.BITNET"
Newsgroups: bit.listserv.edi-l
Date:         Mon, 31 Aug 1992 12:10:00 EDT
From:         BAUM@HULAW1.BITNET
Subject:      Bar Asso. Adopts EDI/Security Policy

****AMERICAN BAR ASSOCIATION RESOLUTION ADOPTED****

             AFFECTING ELECTRONIC COMMERCE AND
                    INFORMATION SECURITY

The House of Delegates of the American Bar Association  (ABA)
approved the first ABA Resolution that is addressed to the
critical legal issues affecting electronic data interchange and
electronic commerce, of assuring the authenticity and integrity
of data in electronic form. Developed and proposed by the
Section of Science and Technology of the American Bar
Association, the Resolution (number 115) was approved by
voice vote on August 19, 1992. The resolution provides:

------------------------------------------------


The American Bar Association supports action by
federal and state governments, international
organizations, and private entities to:

a) facilitate and promote the orderly development
of legal standards to encourage the use of
information in electronic form, including
appropriate legal and professional education;

b) encourage the use of appropriate and properly
implemented security techniques, procedures and
practices to assure the authenticity and integrity
of information in electronic form; and

c) recognize that information in electronic form,
where appropriate, may be considered to
satisfy legal requirements regarding a
writing or signature to the same extent as
information on paper or in other conventional
forms, when appropriate security techniques,
practices, and procedures have been adopted.

------------------------------------------------

Current legal rules generally do not fully recognize or accommodate
the fact that data may be represented in electronic form. It is
anticipated that this ABA Resolution will serve as a catalyst for
legislators, courts, and private entities to advocate legal recognition
of EDI and corresponding reliable information security.

The EDI and Information Technology Division of the Section of
Science and Technology is undertaking diverse projects related to
information security, commercial EDI, judicial EDI, healthcare
informatics, financial EDI and other matters.

For further information, contact:
  Susan Walkowski, Section Manager
  Section of Science and Technology
  American Bar Association
  750 North Lake Shore Drive
  Chicago, IL 60611-4497
  Phone: 312-988-5599  Fax: 312-988-6281


                                               *****
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Via: uk.ac.east-anglia.cpc865; Wed, 26 Aug 1992 16:36:18 +0100
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 16:36:00 GMT
From:         "J.CHEN" <A096@CPC865.EAST-ANGLIA.AC.UK>
Subject:      RE: EDI-92
Comments: To: EDI-L <EDI-L@UCCVMA.UCOP.EDU>

Hi,
Could you please tell me some more details of EDI-92 conference?
I would like to attend, if it is not too late.
Thank you.

J-C Chen
University of East Anglia, Norwich
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 15:55:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: MacFarla <EDI-L@uccvma.ucop.edu>

<much deleted>

>> That scenario has nothing to do with EDI, but everything to do with
>> system security. Any sysadmin who'd allow the possibility of program
>> code being overwritten should be given a one-way ticket to the
>> unemployment line. Every desktop OS I know of is able to implement this
>> minimum security.

>In an environment that provides real security features, such as UNIX, I
>agree with you completely - a sysadmin should protect program code.  But
>we're talking about PCs here - the "sysadmin" (user) often isn't
>conscious of security at all.  You say every desktop OS can prevent
>program code from being overwritten?  DOS certainly does NOT have this
>feature.

Its as easy as changing the attribute of any EXE or Overlay file to READ
ONLY. Now, a piece of software could modify this on a standalone PC, but
(again) it would have to be RUN. Path and file name information in the
transaction which attempted to overwrite a RO file when simply cause an
error message.........


-dave
From: af041@cleveland.Freenet.Edu (Mark Webster)
Newsgroups: bit.listserv.edi-l
Subject: RE: more 841's
Date: 3 Sep 1992 19:24:19 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


 
>>I would question whether or not it would be real Texas smart to allow
>>updates recieved in that matter to replace existing modules anyway.
>>Surely you would want to insure recoverability in case the upgrade got
>>damaged
 
>That's what backups are for.....
 
Unfortunately, not all end users DO backups.  As has been already noted
many desk top users, especially in a DOS based environment, are not
sophisticated.  Counting on user back-ups to cover transmission problems of
software updates is IMHO a major weakness of any system.
 
EDI, especially PC based, is beginning to proliferate to a lot of SMALL
shops.  Places who have never even considered data security, backup or
any other related issues.  They are using EDI because their largest
customer said "DO it or else, and here's the software to use".
 
 
 
>>Anyway, the whole issue reminds me of the reason we put locks on doors, to
>>keep the honest people out.  Those who would create and distribute virus,
>>worm, or other destruction-for-no-cause mechanisms would probably be well
>>served if they were given a dose of that good ol' Texas justice I grew up
>>with.  My methods are simply this:  treat the honest people with respect,
>>give the dishonest ones enough rope to hang themselves with, then sue
>>their pants off just before you kick the horse out from under them.
 
>I believe that anyone who operates a potentially destructive piece of
>machinery (car, PC, etc.) should be fully qualified and licensed. But
>then, I also think that voters should be qualified........<g>
 
Nice sentiment, but it won't happen in our lifetimes.  In the meantime,
we need to at least consider how to deal with worst case situations.
(Sort of like defensive driving, but Texans wouldn't understand that
 idea <g> )
 
 
-- 
Mark Webster                   |  mwebster@reach.com    or
Cleveland, OH                  |  af041@cleveland.Freenet.Edu


Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Phone: +49 231 5599 200
X-Organization: Dr. Materna GmbH
Newsgroups: bit.listserv.edi-l
Date:         Mon, 31 Aug 1992 09:47:39 N
From:         Michael Kuschke <mk@MATERNA.DE>
Subject:      unscribe
Comments: To: edi-l@uccvma.ucop.edu

Hello,

please unscribe "mk@*materna.de" from the edi-l mailinglist.

	Thanks,
	  -Michael

  Michael Kuschke				uucp: mk@materna.de
  Dr. Materna GmbH
  D-4600 Dortmund 1				FAX:    +49 231 5599 100
  Vosskuhle 37, Germany  			voice:  +49 231 5599 200

	Man muss mit allem rechnen,  sogar mit dem Schoensten.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Thu, 27 Aug 1992 13:09:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      RE: more 841's
Comments: To: randalls <EDI-L@uccvma.ucop.edu>

>Good to hear from Texas, Dave.
>
>God's chosen country...the great republic of Texas (and all its
>sub-republics) May the glory live on.  I'm sitting here listening to CW
>music with my boots on and wishing every time I hear "Boot Skootin'
>Boogie" that I was back. People here in Michgan have some real funny ideas
>about Texas, and Texans. That works both ways, I have some valid
>suspicions about these folks, too.

Gosh, Randall, then you can commiserate with a friend of ours who just
started grad school at Michigan State. He's never before been north of
Austin. Had some wierd ideas about what snow was like.......


>I would question whether or not it would be real Texas smart to allow
>updates recieved in that matter to replace existing modules anyway.
>Surely you would want to insure recoverability in case the upgrade got
>'zapped' somewhere along the way or just didn't perform maybe.

That's what backups are for.....

>Anyway, the whole issue reminds me of the reason we put locks on doors, to
>keep the honest people out.  Those who would create and distribute virus,
>worm, or other destruction-for-no-cause mechanisms would probably be well
>served if they were given a dose of that good ol' Texas justice I grew up
>with.  My methods are simply this:  treat the honest people with respect,
>give the dishonest ones enough rope to hang themselves with, then sue
>their pants off just before you kick the horse out from under them.

I believe that anyone who operates a potentially destructive piece of
machinery (car, PC, etc.) should be fully qualified and licensed. But
then, I also think that voters should be qualified........<g>

-dave
From: nagle@netcom.com (John Nagle)
Newsgroups: bit.listserv.edi-l
Subject: Re: Viruses, worms, wildlife & EDI
Date: 27 Aug 92 17:15:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

>>In an environment that provides real security features, such as UNIX,
    
       My nomination for joke of the week.

						John Nagle
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 13:26:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: MacFarla <EDI-L@uccvma.ucop.edu>

>True, Dave, the code must be executed, but I don't think this would be too
>tough for the person in Bill's example.  This person has an intimate
>knowledge of the EDI software in use on the trading partners' PCs.  Some
>EDI packages are organized into separate executable modules that call one
>another.  A virus could be passed using the 841 transaction with a file
>name equivalent to one of these modules.  If the EDI software doesn't
>check the file name, it could overwrite this module and, once that module
>is next called, the virus is off and running.  The virus could, among
>other things, perform the functions of the original module so as to hide
>itself as long as it pleases.

That scenario has nothing to do with EDI, but everything to do with
system security. Any sysadmin who'd allow the possibility of program code
being overwritten should be given a one-way ticket to the unemployment
line. Every desktop OS I know of is able to implement this minimum
security.

-dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Fri, 28 Aug 1992 13:55:03 -0700
Comments:     <Parser> W: Field "Subject:" duplicated. Last occurrence was
              retained.
Comments:     Resent-From: hde4790@dsacg2.dsac.dla.mil (Scott Ligon)
Comments:     Originally-From: pmosl@lee3b2f.deca.mil (Scott Ligon)
From:         Scott Ligon <hde4790@DSACG2.DSAC.DLA.MIL>
Subject:      X12 Rejection/Refusal Transaction
Comments: To: EDI-L%uccvma.bitnet@cunyvm.cuny.edu

(forwarding comment)
--------------------------
--------------------------
(original message follows)

Forwarded message:

>From MAILER-DAEMON Wed Aug 26 18:27:03 1992
Date: Wed, 26 Aug 92 18:19:47 EDT
>From: MAILER-DAEMON (Mail Delivery Subsystem)
Full-Name: Mail Delivery Subsystem
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <9208262219.AB12880@lee3b2f.deca.mil>
To: pmosl

   ----- Transcript of session follows -----
421 uccvma.ucop.edu.tcp... Deferred: Connection timed out

   ----- Unsent message follows -----
Return-Path: <pmosl>
Received: by lee3b2f.deca.mil (5.59/1.34+)
	id AA26881; Sun, 23 Aug 92 18:01:32 EDT
>From: pmosl (Scott Ligon)
Message-Id: <9208232201.AA26881@lee3b2f.deca.mil>
Subject: X12 Appl Rejection Trans
To: EDI-L@uccvma.ucop.edu
Date: Sun, 23 Aug 92 18:01:30 EDT
X-Mailer: ELM [version 2.2 PL15]

First, let me tell you that I am impressed at the level of dialog
that your group has been conducting.  I have used UCS standard
transactions for ordering for many years but am just now getting
into X12 with an invoicing/payment enhancement effort.  I have gone
through your archived message history and learned a lot, but not the
answer to this question.

In the 9203/9204 Log files there appeared to have been a rather
spirited discussion on the idea of a "Notice" transaction.

I am interested to know if anyone is working on an application level
rejection transaction.  Presuming that an order or invoice passes
all of the translator edits and a functional acknowledgement is
sent, a company may still wish to reject the order or invoice for
cause.  In the case of an invoice, we may need to return it to the
submitter due to incorrect terms, quantities, ...

I have asked this question of many people in the retail industry
active in EDI, both UCS and X12.  It appears that most people are
using the 824, Application Advice or the NTE(note) to perform this
function.  This does not really address the problem, but simply
treats it.

As your forum previously discussed, when a transaction is used that
must go offline for human interpretation, we aren't doing our people
any favors.  If a standard set of Invoice Reject codes(and orders)
were developed, we could pass this between our applications.

Your thoughts and even "flames" are most cordially invited.

thanks!

Scott Ligon
Electronic Commerce Manager
Defense Commissary Agency
sligon@lee3b2f.deca.mil
Newsgroups: bit.listserv.edi-l