I've noticed too this fast rate of changes in the PUCC NETNEWS (still
some patches in rdr) altough I'm not sure does it affect the userdefined
exec entry to preprocess incoming news. There's in the L.SYS file an entry
telling the name of an exec to preprocess the news which
could call the addnews exec (changing... ) to append new entries. There's
also an other entry for an exec to postprocess outgoing news if needed.
I hope that those hooks should be somewhat stable to place some mods.
Another possibility is the PSU netnews system which I haven't heard a long
time but it's apparently working somehow. Third and easiest method,
which we are currently using to input some mailing lists, is to use our
Bsd 4.3 unix machine with mailer aliases for each list (files not sent through
mailer will go to a bitbucket directory and forgotten there :-() and
recnews program which just eats the mail, makes new headers, cleans
old ones and finally adds it to the newsgroup given as a parameter.
The urep link there isn't very fast and my DACU ethernet interface is still
kaputt so I haven't hurried. If I'll use the unix system instead of the
VM/SP one I'll ftp those news back through ethernet when/if it works.
Anyway, in any case the bidirectional gateway is indeed a more difficult
problem because of the loop control. The usenet NEEDS and USES the msgid
and path information in the article header to detect loops.
Netnews admin manual ch. 2.22 says that the leftmost nodename of the path must
correspond to the host which sent the file. The file to be received
must be uniquely identifiable by fn, ft, forms, user, node and dist
which are matched against a template with wildcards, I guess that's in order
because I rely on TAMSEC et al and the listserv or mailer won't be sending
any too confusing files which couldn't be detected. Btw. the manual talks about
variable length files to prevent truncation which seems impossible with mail.
Path is the most probable one to be over 80 chars in the newnews -> listserv
direction but I think it could be folded using a comma as separator (REXX
style :-). The listserv -> netnews direction has worked nicely on the Unix
system for a long time because everything that comes out from the Crosswell
mailer is legal rfc-822 mail. Things bumbed to me from the mailer and listserv
are a completely different story...
I think we have already understood what's needed to insure a correct
and loop free gateway. I guess these would make Jacob Palme happy too ;-)
Let's try to summarize:
A loopfree interconference protocoll for the listserv
1) Date: and From: are already in the Internet format and need no changes.
2) Path: field should be always present and
the node actually delivering the note should be appended on the left.
On interpeer traffic this isn't needed because you already have
that kind of loop detection in the interserver protocoll.
3) Message-ID: should always be preserved if it exists, if not one should
be created. It's used by the history lookup algorithm in many netnews and
mailer implementations as well as the path information.
4) Subject: field is mandatory, one should be created from the first text
line, fortune collection or anywhere if not present (NOTE etc.)
5) Newsgroups: field refers to the newsgroups where the entries should
be appended and they must be created from the list name using a mapping
table. In the netnews -> listserv direction it should be used to
find the address of the list where the replies should be sent.
This task is specific to the listserv <-> netnews connection and
isn't probably needed by the other systems (COM?). It could be either
generated in the netnews server, a yadvm (Yet Another Disconnected
Virtual Machine; I have now > 40 ) or in the listserv using a simple
table lookup to change the listid to some userspecified string.
if not found on the tables it could be either set to the listname or
discarded. Maybe this 'additional tag' header field could be usefull
on some other systems after all. The name could even be a parameter
so that Jacob could have a Conferences: conf1,conf2 etc. field.
For the ease of management there should be only one file for all lists
per gateway server; No more keywords to listheaders, please.
6) All other headers are optional and should be preserved if they
exist already (Sender:, Dog-Type:...). Format should be valid
RFC-822 and converted or folded when necessary. The creation of
these headers is normally the responsibility of the user or user agent
(Summary,Keywords,Organisation,Distribution,Xref,Expires,Control,
Followup-To,Approved,Lines) but some of them would come from listserv
(Sender,Reply-To).
7) Everything even remotely looking like a human readable mail should be
converted to valid rfc-822 mail. How you possibly could determine
that Netmonth is a human readable magazine because it doesn't
have anything resembling headers from a XYZZY MODULE is probably
impossible and therefore I'm trying to use Send= Editor to manually catch
it (hmm... maybe an automagical yadvm as an editor would do...)
8) Something I must have missed :-)
These conversions, loopcheckings etc. could be done partly or completely in:
A) In the listserv (My preference, execept maybe item 5)
B) In the NETNEWS system (especially 5, less portable and general)
C) In a separate DVM interfacing through spool (Thomas, no problem with
versions but maybe hardest to do and unefficient)
Happy conferencing,
D) In a different Bsd 4.3 Unix machine (Unix gurus, Easiest to do, transfer
there and back (not a problem with a working DACU), hardest to port
if you don't have the hardware/sofware)
Happy conferencing,
Harri Salminen, systems analyst
Helsinki University of Technology Computing Centre alias HUTCC alias TeKoLa
Paper datagrams: | BITNET: LK-HS@FINHUTC
Otakaari 1 | UUCP: hks@santra (...mcvax|santra|hks)
02150 Espoo | EAN: [log in to unmask]
Finland | FUDEC: OPMVAX::SALMINEN
Voice Virtual Ciruit: | ARPA: [log in to unmask]
+358-0-4512632 | CSNET: Real Soon Now...
"Virtually, I don't work, I just netWORK :-)"
|
