HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"Don.Rainwater@UC.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 9 Sep 92 22:22:33 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Limiting access to outgoing mail.
Newsgroups: bit.listserv.pmdf-l

>         I'd like to be able to limit access to non-local (off-node) email.
> I'm thinking that I can define a rights id, say 'NO_OUTMAIL' for example,
> and set the appropriate image with an ACL such that anyone holding that id
> cannot send internet mail messages.  My questions are simple:  Will this
> work?  and, which image(s) should be set this way?

This won't work since the users only run VMS MAIL or DECWindows MAIL.  They
don't run the actual images which send outbound mail.  Instead, you probably
want to associated this rightlist identifier with, say, your TCP/IP channel.
You do this by merely specifying the rightlist id as a channel keyword; e.g.,

        mtcp_local single smtp mx no_outmail

Then, only processes with the no_outmail rightslist id can queue mail to
the mtcp_local channel.  Be sure to grant this rightslist id to whatever
accounts PMDF may run under!

In PMDF V4.2, there will be a mapping file table which you can use to do very
elaborate channel access schemes which will even allow you to reject incoming
mail.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 9 Sep 92 08:52:21 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: GATES.RULES file does not look right.
Newsgroups: bit.listserv.pmdf-l

The GATES.RULES file you posted looks correct to me. The multiple entries
are a result of the need to hide BITNET addresses behind a route when
messages are relayed out to the Internet.

The results from PMDF TEST also look correct. The local channel reference
at the beginning is a chimera; it is the (correct) reference to bit_mailer
at the bottom you should be concerned with. The headers also look correct.

                                Ned
Newsgroups: bit.listserv.pmdf-l
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Problem with reprocess and defragment channel
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Fri, 11 Sep 1992 09:48:28 GMT

I did have the following problem:

Configure.com generated the following two channels:

!
! Channel to reassemble MIME message/partial parts
!
defragment nox_env_to
defragment.SNOOPY.BL.PHYSIK.TU-MUENCHEN.DE

!
! Channel to handling reprocessing jobs
!
reprocess nox_env_to
reprocess.SNOOPY.BL.PHYSIK.TU-MUENCHEN.DE

Pmdf cnbuild fails on these channels with the following error message:

snoopy> pmdf cnbuild/noimage/maximum/option
Error in mm_init -- official host is too long -- defragment -- line #311 in file

I realize that I'm falling over the 40 character limit, how could I work around?Shortening my hostnames isn't an option.

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@INNOSOFT.com"
X-VMS-Cc: IN%"jjc+@pitt.edu", IN%"IPMDF@YMIR.CLAREMONT.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 6 Sep 92 21:00:35 GMT
From:         "Craig R. Watkins" <CRW@ICF.HRB.COM>
Subject:      RE: BN_MASTER and SEND/FILE
Newsgroups: bit.listserv.pmdf-l

|> 2. Joiner Tech Support tells me it is safe to include "/OPTIONS="W=" to
|> have the external writer field filled in on each SEND.  Is that true?
|> Are there any NJE mail software packages that would not like this?
|
|There is no way to ever be sure of this. BITNET simply doesn't have any rules
|about this sort of thing. As a result you may find all sorts of bizarre usage
|out there. All I can say for sure is that I have never seen a mailer that's
|sensitive in this way. However, my experience also tells me that when it comes
|to BITNET there is almost certainly such a system out there.

This is about as safe as you can get.  Jnet does it by default on outgoing
mail.  Do it.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU"
X-VMS-Cc: UCCXJPS
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 11 Sep 92 16:02:42 GMT
From:         Systems <UCCXJPS@VMS.UCC.OKSTATE.EDU>
Subject:      unsubscribe
Newsgroups: bit.listserv.pmdf-l

Now that our news system is fully functional, I can get my pmdf notes from it.
Please unsubscribe me from your list.  Thank you.

Jim Strother
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Organization: Indiana University of Pennsylvania
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@ymir.claremont.edu"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 6 Sep 92 09:30:04 GMT
From:         "Mark_Strawcutter" <MJSTRAW@GROVE.IUP.EDU>
Subject:      bookreader setup
Newsgroups: bit.listserv.pmdf-l

Based on info from various sources and a fair amount of playing around,  I've
come up with two ways to integrate the bookreader docs from various sources.

Most come with a LIBRARY.DECW$BOOKSHELF file in the same directory as the
various book/bookshelf files.  I can define DECW$BOOK to be a searchlisted
logical pointing to an infoserver drive, pmdf_root:[doc], multinet_root:
[multinet.documentation] etc.  Bookreader appears to combine the contents
of all the LIBRARY files, and when you pick a shelf/book if finds it (via
the search list or perhaps by remembering which LIBRARY the thing came from).

I can also define DECW$BOOKSHELF as a searchlisted logical with each item
being the full filespec of a LIBRARY.DECW$BOOKSHELF file.  All the contents
are again combined, and it finds stuff in the right place (must be by knowing
which shelf/book came from which LIBRARY file)

I've seen the discussions about puting DECW$BOOK in the system logical name
table since it's searched before the decwindows table.  That's not my problem.
My question is if either of the above methods is to be preferred over the
other.

----------
Mark J Strawcutter                           BitNet:    MJSTRAW@IUP
Director, Systems and Communications         DNS (mx):  mjstraw@grove.iup.edu
Indiana University of Pennsylvania           Voice:     (412) 357-4000
Indiana, PA   15705                          "you can't nail jello to a tree"
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 9 Sep 92 06:14:07 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: GATES.RULES file does not look right.
Newsgroups: bit.listserv.pmdf-l

> As you can see it is trying to use the local channel to send to this node.

No, the PMDF TEST output clearly shows that it will send the message out
your bit_mailer channel:

> Submitted address list:
>   bit_mailer

>     k@alaska.BITNET (alaska.BITNET)

The instance of the local (l) channel which you saw mention of was the channel
which PMDF MMTEST was acting _as_ when rewriting the address.  Take a glance
at the PMDF TEST/REWRITE (a.k.a., PMDF MMTEST) documentation in the PMDF
System Manager's Guide.  In the example it describes some of the output of
PMDF TEST/REWRITE.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mts: smtp
Date:         Tue, 15 Sep 92 13:10:36 +1000
From:         andrewr@ITD.ADELAIDE.EDU.AU
Subject:      RE: Problems with cc:Mail channel.
Newsgroups: bit.listserv.pmdf-l
              <01GOSCR3YE0U8WVYKE@SUMMER.INNOSOFT.COM>

In message <01GOSCR3YE0U8WVYKE@SUMMER.INNOSOFT.COM> Kevin writes:

+ >>    ident="V4.1-A"
+ > Interesting -- I don't know of an instance where we used a letter as a
+ > dash number. Be that as it may, this is definitely a very early version
+ > and you need a more recent one.

+ V4.1-A is the ident applied to PMDFDISP.EXE after the mandatory security patch
+ has been applied.  All other images (and PMDF_ROOT:[EXE]IDENT.OPT) should
+ still contain the original ident after the patch has been applied.

$ TYPE PMDF_ROOT:[EXE]IDENT.OPT
ident="V4.1-3"

        I'll let you know how it goes when I get hold of V4.1-10 or greater.

Cya,
        Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"andrewr@itd.adelaide.edu.au"
X-VMS-Cc: info-pmdf
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 15 Sep 92 05:30:29 GMT
From:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject:      RE: Problems with cc:Mail channel.
Newsgroups: bit.listserv.pmdf-l

>>      ident="V4.1-A"
>>      Not sure what the latest release from our supplier is, will
>> contact service as requested if they don't dave -10 or greater.
>
> Interesting -- I don't know of an instance where we used a letter as a
> dash number. Be that as it may, this is definitely a very early version
> and you need a more recent one.

V4.1-A is the ident applied to PMDFDISP.EXE after the mandatory security patch
has been applied.  All other images (and PMDF_ROOT:[EXE]IDENT.OPT) should
still contain the original ident after the patch has been applied.

        /Kevin Carosso
         Innosoft
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-VMS-Cc: IN%"ipmdf@ymir.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 12 Sep 92 19:02:26 GMT
From:         "Daniel C. Newman" <DAN@SIGURD.INNOSOFT.COM>
Subject: RE: FAX pop-up form and VMS MAIL keypad keys: problem resolved
Newsgroups: bit.listserv.pmdf-l

>  Excuse me for being dumb if I'm missing something here, but it seems
> to me that there is another possible workaround.  The following is done
> from memory and can probably be improved upon, but wouldn't:
>
>  TRICKMAIL.COM:
>      $ oldkpd = F$GETDVI("SYS$INPUT","TT_APP_KEYPAD")
>      $ set term/application
>      $ mail
>      $ if .not. oldkpd then set term/numeric
>      $ exit
>and
>   $ MAIL :== @DEV:[DIR]TRICKMAIL
> do the job at a lower level of pain than /APPLIC/PERM ?

Yes, this will work.

On re-reading my posting I see that I inadvertently left the whole paragraph in
there on the /PERM/APPLICATION workaround.  (A half finished paragraph with
that dangerous phrase "the only work around".) I meant to leave that whole
paragraph out since the diagnosis of the problem, in the following paragraph,
brings to light the key issue (be in application mode before running VMS MAIL).
Sites troubled with this problem can then do as they  see fit prior to the
release of 4.2.

Since others may be interested in your suggestion, I'm posting this back to
info-pmdf.

Thanks,
Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"IPMDF@YMIR.CLAREMONT.EDU"
X-VMS-Cc: IN%"Don.Rainwater@UC.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 9 Sep 92 12:45:49 -0500
From:         Don.Rainwater@UC.EDU
Subject:      Limiting access to outgoing mail.
Newsgroups: bit.listserv.pmdf-l

        I'd like to be able to limit access to non-local (off-node) email.
I'm thinking that I can define a rights id, say 'NO_OUTMAIL' for example,
and set the appropriate image with an ACL such that anyone holding that id
cannot send internet mail messages.  My questions are simple:  Will this
work?  and, which image(s) should be set this way?

        Here's my reason for wanting to do this.  My system is used for
course work, and each person in a class that needs the VAX is given an
account for the quarter.  At the end of the quarter, all class accounts are
removed.  That's where the problem begins - once the accounts are removed,
my mailbox is flooded with postmaster messages because some of the class
users subscribe to mailing lists.

        It should be too fascist of me to do this, since a permanent
account is available to any student that wants one.

        If anyone has a better idea on how to handle this, I'm all ears.
Thanks in advance.
--
Don Rainwater, Systems Manager, Univ of Cincinnati Center for IT Services
Don.Rainwater@UC.Edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"cvm@NAUVAX.UCC.NAU.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 15 Sep 92 11:20:28 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Notifying POP3 users of new mail.
Newsgroups: bit.listserv.pmdf-l

This cannot be done efficiently in MASTER.COM -- it would require breaking
out of VMS MAIL for each message, and the overhead cost of doing this
is really huge. It is unfortunate that firing up VMS MAIL is expensive,
but it is and there's nothing we can do about it. It is also fairly
nontrivial to do the translation of local channel addresses into
meaningful usernames -- the rules for this are complex and far from
obvious.

The best way to do this would be for us to provide a hook in the local
delivery process to call some of your code. The best we could do
would be to give you the address we're passing to VMS MAIL (this is quite
different from the original recipient address). You could then go off
and do whatever you want with it.

Another possibility is for us to send out the notice ourselves. But
this requires some knowledge of the protocol used to ring up the
PC. POP is only a remote mail access protocol; it doesn't have remote
notification capability as far as I know. So what protocol do you use for
this?

We would probably just add the hook in any case; but we could also
write the specific module to deliver these notifications if, say,
Multinet is what you use as a transport.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"PJORGENSEN@COLGATEU.BITNET"
X-VMS-Cc: info-pmdf
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 13 Sep 92 04:39:28 GMT
From:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject: RE: Problem sending mail
Newsgroups: bit.listserv.pmdf-l

> This may not be a PMDF problem, but Digital is stumped and we have users who
> can't send mail.
>
> This problem only affects Mail for Macintosh users.
>
> This problem only affects non-priviledged users, users such as the system
> manager are not affected.

The first thing to do is to use one of these user accounts to send a message
using PMDF from VMS MAIL. See if you get any errors in that case.  I suspect
you are getting some sort of PMDF error, related either to incorrect file
ownership or protection in the PMDF_ROOT: tree or to insufficient disk quotas
for the PMDF or SYSTEM UIC on the PMDF_ROOT disk.  In the VMS MAIL environment
we don't ACCVIO when these errors occur.  The PCSA MAIL server, however, may
not handle the error properly.

You can also enable "master_debug" on the local channel in
PMDF_ROOT:[TABLE]PMDF.CNF.  This will produce debug output from PMDF
in the NETSERVER.LOG file.  Note that all VMS MAIL users who send to
a PMDF address while you have "master_debug" turned on will also see
debug messages on their terminals.  Keep that in mind when you try this.

        /Kevin Carosso
         Innosoft

ps. I forgot to mention that we (among others) use the Pathworks Mail for Mac
    all the time without seeing this problem, so it definitely can work.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID keaqsjryImS5/EBhNjOmeA)"
X-Mailer: Network Courier V2.1b
Date:         Sat, 12 Sep 92 06:09:28 GMT
From:         khatri@PCMAIL.INRE.ASU.EDU
Subject:      Question about TEST/REWRITE
Newsgroups: bit.listserv.pmdf-l


--Boundary (ID keaqsjryImS5/EBhNjOmeA)--
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"jjc+@pitt.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 6 Sep 92 19:52:38 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: BN_MASTER and SEND/FILE
Newsgroups: bit.listserv.pmdf-l

> I am running PMDF 4.0, JNET 3.4, Multinet 3.0, and VMS 5.4-3.

> We have a connection to an MVS machine on our campus via BITNET.  The
> mailer on that machine really wants the External Writer field to be set
> to the destination user.  If this is not done, it parses the headers for
> the "To:" line, which causes unpleasant results.

Mailers that parse the To: line for envelope information are fundamentally
busted. It is totally unacceptable to implement this even as an option.

> By default, the SEND/FILE command comes from Joiner with "/OPTIONS" set
> to "".   I see from the source that the Options file seems to be used to
> create a "/OPTIONS=blah" switch on the SEND/FILE that BN_MASTER performs.

> Here are my questions:

> 1. Can I add a "W=" to the options file to have it set use the options
> as follows:

>       SEND/FILE/OPTIONS="W="

Sure. Just add a line saying

    OPTIONS=W=

to the option file for the channel you use to connect to this system.

This isn't documented but it should work fine.

> 2. Joiner Tech Support tells me it is safe to include "/OPTIONS="W=" to
> have the external writer field filled in on each SEND.  Is that true?
> Are there any NJE mail software packages that would not like this?

There is no way to ever be sure of this. BITNET simply doesn't have any rules
about this sort of thing. As a result you may find all sorts of bizarre usage
out there. All I can say for sure is that I have never seen a mailer that's
sensitive in this way. However, my experience also tells me that when it comes
to BITNET there is almost certainly such a system out there.

> If there are, what is the best way to have this option apply to our
> specific host (or a specific queue)?

It is actually hard to have it any other way, since this is a per-channel
option. Most configurations usually have dozens of BITNET channels. I would
recommend setting up a special channel that is only used for this host
with an appropriate associated option file. This way there is no chance of
this option information ever messing up anyone else.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mts: smtp
Date:         Sat, 12 Sep 92 17:20:01 +1000
From:         andrewr@ITD.ADELAIDE.EDU.AU
Subject:      Problems with cc:Mail channel.
Newsgroups: bit.listserv.pmdf-l

        I'm having two problems with the cc:Mail channel under PMDF.
The first, of irritance value only, is that it manipulates spaces
inside quotes in names to underscores in it's output file namem,
including those around the "AT" which signifies the post office to go
to, so it's treated as one user. We've got around this with a small
program on the DOS side to change it back, and using cc:Mail's
directory propogation so we don't have to specify the post office.
        The second problem is that it only works one way. It creates
the output file just fine, in the correct format, but it doesn't seem
to look at the input file specified. EG:

$ type pmdf_root:[table]cc_local_option.
CC_GATEWAY_NAME=AARNet
CC_OUTPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.IMP
CC_INPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.EXP

$ dir /date=all DKA400:[POST_OFFICE]

Directory DKA400:[POST_OFFICE]

CCMAIL.EXP;1         11-SEP-1992 12:16:38.60  11-SEP-1992 12:16:39.07   <None sp
   ecified>   <No backup recorded>
CCMAIL.IMP;1         11-SEP-1992 13:37:49.78  11-SEP-1992 13:35:34.00   <None sp
   ecified>   <No backup recorded>
TEST.IMP;1           11-SEP-1992 13:37:01.18  11-SEP-1992 13:35:34.00   <None sp
   ecified>   <No backup recorded>

$ show time
  12-SEP-1992 17:16:29

ie, the file's been sitting there for over 24 hours.

        Obviously I'm doing something wrong as others have got this to
work - can anyone offer any suggestions? The PC accesses the
filesystem via PC-NFS through Multinet NFS on the VAX side.

Thanks,
        Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU