HDTenEightyP/NetNews huggingface dataset:
From: cudep@warwick.ac.uk (Ian Dickinson)
Subject: Re: nntpxmit problem <message-id syntax error>
Organization: Team Limpid's Meathead With Aptitude - Kunst und Wahnsinn
Date: Wed, 9 Sep 1992 11:14:00 GMT

In article <1992Sep5.205509.15802@news.ysu.edu> doug@cc.ysu.edu (Doug Sewell) writes:
>You're welcome.  However, if your version of nntpxmit is griping about
>Message-ID syntax, it's probably 1.5.11 and the 'n' flag (write the
>article location and message-id) is a better choice than the 'F' flag
>(write the article location).  If the message-id is in the batch-file
>then nntpxmit doesn't need to open the article to determine the message-
>id to offer the remote host.  This will make a difference in disk I/O,
>particularly if the remote host rejects a lot of what you offer.

Whilst on the subject of nntpxmit complaining about Message-ID syntax,
1.5.7 complains as well, but has one or two problems which make an upgrade
worthwhile.  A site which talks to me using nntpxmit 1.5.7 using the n flag
had a problem with a complaint about invalid Message-ID '1.0'.  Some
mail gatewayed message had a MIME-Version: header.  1.5.7 doesn't get the
check for Message-ID right and just takes any header beginning with [mM].*:
I dunno for sure if it's fixed in 1.5.11 (which I'm using) since Cnews
wrote the Message-ID into the batch file using the 'n' flag.  Beware.

Cheers,
--
Ian
-- 
\/ato - Ian Dickinson - NIC handle: ID17                   No-one is to molest
vato@csv.warwick.ac.uk  ...!mcsun!uknet!warwick!vato           the wombat when
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/            anyone is
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson  watching.
Newsgroups: news.software.nntp
From: greg@gagme.chi.il.us (Gregory Gulik)
Subject: NNTP tools posted to alt.sources
Originator: greg@gagme
Organization: Gagme Public Access UNIX, Chicago, Illinois.
Date: Tue, 8 Sep 1992 18:07:20 GMT


I just posted version 1.0 of the NNTP tools that were developed
here at GAGME.  This release includes the following tools:

nntpnew	- The original tool, which basically provides an interface
	  to the NNTP 'newnews' command.

nntplist - List (and optionally mark read) article summaries in
	   selected newsgroups.

nntpcat - Cat (display) articles listed with nntplist, or other
	  sources.

Anyway, you'll have to just check it out, and the man pages
do a much better job of explaining the use of the tools.

Enjoy!  We've been using them here for a couple months with
great results.  Hope you find them useful as well.

If you don't get alt.sources and want to check out the
tools, drop me a line and I'll send you the SHAR file.  It's
only about 32K.

-greg

-- 
Gregory A. Gulik                                 Call Gagme, a public access
       greg@serveme.chi.il.us                    UNIX system at 312-282-8606
   ||  gulik@rtsg.mot.com                        For information, drop a note
						 to info@gagme.chi.il.us
Newsgroups: news.software.nntp
From: cms@home.demon.co.uk (Cliff Stanford)
Subject: Control messages with a passive news client 
Distribution: world
Organization: Demon Systems Limited.
Date: Tue, 15 Sep 1992 22:05:47 +0000

In article <1992Sep14.135449.10986@osf.org> rsalz@osf.org writes:

>Another idea is to set up active feed batchfiles for all your customers,
>and then modify the NEWNEWS command to read those batchfiles rather than
>the history file.  It would require them to tell you when their subscription
>changed -- unless you got clever and shifted to the history file when they
>wanted groups not in your batchfile for them.

	That's what we're trying to avoid.  We don't want the manpower
overhead of (currently) 300 dialup Internet subscribers wanting to change
their sys file entries.  NEWNEWS/ARTICLE also allows them (a) flexiblity
and (b) the facility to perform interactive (automated) killing of
articles based on HEADER/BODY commands.

>I am amazed that someone actually supports clients using newnews/article.
>Have you looked at the implementation of the NEWNEWS command?  Unless you
>have modified your reference implementation, your system is getting killed...

	We've made a few, relatively minor changes to nntpd (caching the
NEWNEWS output, for example) but I agree, nntpd does kill the system.
		Regards,
			Cliff.
-- 
Cliff Stanford                              cliff@demon.co.uk
Demon Internet Services			    cms@home.demon.co.uk
42 Hendon Lane				    +44 81 349 0063
London N3 1TT                               +44 860 375870
Newsgroups: news.software.nntp,news.software.b
From: pasalvin@maytag.uwaterloo.ca (Paul A. Salvini)
Subject: Re: C-news cant keep up with NNTP - Also how to stop extra postings
Organization: University of Waterloo
Distribution: na
Date: Tue, 8 Sep 1992 15:46:03 GMT

In article <Bu8IqE.M6B@watdragon.uwaterloo.ca> pasalvin@maytag.uwaterloo.ca (Paul A. Salvini) writes:
>In article <Bu2tAL.2s8@world.std.com> geoff@world.std.com (Geoff Collyer) writes:
>>Paul A. Salvini:
>>>Our in.coming file is constantly growing. It seems that newsrun cant keep up
>>>with it.
>>
>>Something is wrong.  The new release has a faster newsrun, and that
>>should help, but first check doc/trouble and doc/problems to see if there
>>is another reason you are so far behind (you aren't running on a 386 are
>>you?).
>>-- 
>>Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff
>>
>>``Leave the evil grasping to us.'' - A. L. Arms, UNIX licensing, WECo.
>
>Well, the first half of the problem has been solved! I installed the new
>release of c-news and it processed 25000+ articles in one day! The previous
>nore was around 10000+. So, in less than 2 days we were caught up. I guess
>from postings and mailing (thanks), that once we fell behind, the NNTP feed
>kept sending duplicates and it  was downhill from there.
>
>
>Still no answer on the second halpf of the question. How come our
>out.nntp file contains all articles to be sent back to the feed? It should
>only contain the locally posted articles.Correct? Our sys file has the
>'n' flag set.
>
>Any pointers on this?

Solved. Thanks to the net for the answer -- look at the sys entry.
I thought it couldnt be this since I never changed
anything and it worked before. Well
our sending site changed something and alas the sys
entry was incorrect.

Thanks Once Again.
Newsgroups: news.software.nntp
From: jona@iscp.bellcore.com (Jon Alperin)
Subject: mail2news subject line missing
Organization: Bellcore
Distribution: usa
Date: Fri, 4 Sep 92 12:13:09 GMT

Does anyone have a patch to mail2news that accepts a mail message with no 
subject line? I can't get my users to stop sending out mail w/out subject lines.
I'm going to look at the code now, but I figured I'd ask first.

 Please e-mail replies, as I don't usually read this group..thanks.

-- 
Jon Alperin
Bell Communications Research

---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674
---> UUNET: uunet!bcr!jona

* All opinions and stupid questions are my own *
From: taka@fxis.fujixerox.co.jp (Takahiro Kanbe)
Newsgroups: news.software.nntp
Subject: INN 1.1 art.c bug and a request.
Date: 6 Sep 92 19:31:55
Organization: Fuji Xerox Information Systems Co., Ltd., Tokyo, Japan.
Distribution: inet
NNTP-Posting-Host: litra.nwt.fxis.fujixerox.co.jp

When I made ihave message, there was some message in news.err;

Sep  4 16:05:26 fxisms innd: not-for-mail bad_ihave in to.fxisns

After examining some codes, I found the reason in innd/art.c, and
fixed it like bellow.  After this change, I don't see the error
message any more.

And when innd receives several ihave control message, "ihave" shell
scripts run to try process immediately.  This immediate processing
increases machine's load too quickly.  In the worst case some sendme
messages were failed to post.  I want a way to process ihave and
sendme delayed or batched, like C news.

Thanks.

--
Takahiro Kanbe <taka@fxis.fujixerox.co.jp>	FXIS / Network Team.

*** innd/art.c.~1~	Wed Sep  2 16:44:48 1992
--- innd/art.c		Sun Sep  6 17:11:03 1992
***************
*** 239,245 ****
  
      /* Get our Path name, kill trailing !. */
      ARTpathme = COPY(Path.Data);
!     ARTpathme[Path.Used - 2] = '\0';
  }
  
  
--- 239,245 ----
  
      /* Get our Path name, kill trailing !. */
      ARTpathme = COPY(Path.Data);
!     ARTpathme[Path.Used - 1] = '\0';
  }
From: taka@fxis.fujixerox.co.jp (Takahiro Kanbe)
Newsgroups: news.software.nntp
Subject: Re: INN 1.1: A CRITICAL PROBLEM (and fix).
Date: 7 Sep 92 14:39:02
Organization: Fuji Xerox Information Systems Co., Ltd., Tokyo, Japan.
Distribution: inet
NNTP-Posting-Host: litra.nwt.fxis.fujixerox.co.jp
In-reply-to: taka@fxis.fujixerox.co.jp's message of 7 Sep 92 10:13:20

In article <18eakfINN6cs@fxisms.fxis.fujixerox.co.jp>
	taka@fxis.fujixerox.co.jp (Takahiro Kanbe) writes:
> There was a bug in innd/art.c, and this is simple fix.

And this is a simple and trivial AWK script for fix history.

Affected entry will be in history.bad, and good entry will be
history.n.

#
BEGIN {range = 7 * 3600}
$2 ~ /[1-9][0-9].*\~[1-9][0-9].*\~[1-9][0-9].*/ {
	n = split($2, a, "~");
	if (n == 3) {
		if ((a[2] - a[1]) < range) {
			print >> "history.bad"
			next;
		}
	}
	print >> "history.n"
	next
}
	{print >> "history.n"}

--
Takahiro Kanbe <taka@fxis.fujixerox.co.jp>	FXIS / Network Team.
Newsgroups: news.software.nntp
From: rsalz@osf.org (Rich Salz)
Subject: Re: Help wanted with slow program
Organization: NNTP q&a
Date: Tue, 15 Sep 1992 13:22:25 GMT

In <1992Sep14.134713.1@news.duc.auburn.edu> swanger@news.duc.auburn.edu writes:
>- xhdr having to search the header of each article file for the info
Most likely.
>- network bandwidth problem
Doubtful.
>- the server is slow
Perhaps; this is the same as #1, right?
>- crummy programming on my part
Perhaps.  Do you get information on all articles in the group, or just
the ones that the user has not already seen?  If the former, you should
probably fix your program.

>For whats its worth, when I load all of the group names into an array of
>strings at program startup, it only takes about 2 seconds and we have nearly
>2000 groups on our server.
That is because, typically, this information is stored in a single file
which can be gulped in and spit out in one chunk.

You can help determine if the problem is with your program, or other
factors, by telnet'ing to the port and sending the commands directly:
	telnet news-server 119
	group comp.foo
	xhdr Subject 1-200

Anyhow, here are some nits on your program, but I am sure that fixing
them will not give you any real speed-up.

>/*  sizeof_charp = sizeof(char *);  and is called at the start         */
That's a mistake, you just turned a compile-time constant into a
variable and slowed your program down.  (Not noticeably, tho.)

>   articles = (char **) malloc(num * sizeof_charp); 
You might find this syntax useful:
    #define NEW(T, c) (T *)malloc(c * sizeof (T))
    articles = NEW(char*, num);

>   articles[0] = (char *) malloc(NNTP_MAX * sizeof_char);
Why not re-use your send buffer?

>      if (get_server(string, NNTP_MAX) < 0)
>      {
>         printf("\n%s\n\n", ERROR2);
>         exit(0);   
>      }
>      else
Why do you have an "else" after a statement that can't return?  Ick.

>         if (strcmp(string, ".") == 0)
>         {
>            finished = TRUE;
Use:
	     break;
and, again, delete the "else" that comes after.

>            articles[loop] = (char *) malloc((strlen(string)+1) * sizeof_char);
Another waste; sizeof (char) is defined to be one, and you make a compile-time,
constant be a run-time variable.  Again, you might find this more clear:
	#define COPY(p)          strcpy(NEW(char, strlen(p) + 1), p)
	articles[loop++] = COPY(string);
Or see if your library provides strdup().
	/r$
Xref: sparky news.software.nntp:1139 news.software.b:2936
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: news.software.nntp,news.software.b
Subject: Re: INN, NNTP & compressed articles
Date: 14 Sep 1992 07:25:45 GMT
Organization: Univ. Natal, Durban, S. Africa
Distribution: inet
NNTP-Posting-Host: daisy.ee.und.ac.za

In article <1992Sep10.135321.16284@osf.org>,
rsalz@osf.org (Rich Salz) writes:
> To get political and perhaps annoying, INN is designed for the future
> when everyone can afford fast links.  (Please note that I know the
> difference between a 56kB link and a slow fast pipe; addressing the
> latter area is worthwhile as it will become commonplace with gigabit
> networking.)

s/slow fast pipe/slow fat pipe/, I think.

Yes, the roundtrip time in the IHAVE negotiation can be a killer.  I don't
buy the theory that INN is no good with slow links; It works fine unless
the RTT is so large that no NNTP implementation has a hope of keeping up.

If it takes x seconds for a ping to get from site A to site B and back
to site A, then it takes at least x seconds for an IHAVE from site A to
be acknowledged by site B, which means that no more than 3600/x messages
per hour can be transferred via NNTP between sites A and B, no matter
how fat the pipe is.  RTTs of 10 seconds or more are not uncommon beteen
South Africa and the rest of the world, which means that a full NNTP
feed is out of the question; we use compressed batches via UUCP over TCP.

Are the folk who are designing the successor to NNTP thinking of adding
asynchronous IHAVE negotiation?  It might work something like this:

        IHAVE <msg1>
        IHAVE <msg2>
        IHAVE <msg3>
                                DONT-SEND <msg1>
        IHAVE <msg4>
                                SEND <msg2>
        IHAVE <msg5>
        IHAVE <msg6>
                                SEND <msg3>
        HERE-IS <msg2>
                                DONT-SEND <msg4>
        blah blah
                                DONT-SEND <msg5>
        .
        HERE-IS <msg3>
                                DONT-SEND <msg6>
        blah blah
                                RECEIVED-OK <msg2>
	etc.			etc.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
From: taka@fxis.fujixerox.co.jp (Takahiro Kanbe)
Newsgroups: news.software.nntp
Subject: INN 1.1: A CRITICAL PROBLEM (and fix).
Date: 7 Sep 92 17:13:20 GMT
Distribution: inet
Organization: Fuji Xerox Information Systems Co., Ltd., Tokyo, Japan.
NNTP-Posting-Host: litra.nwt.fxis.fujixerox.co.jp

After switched to INN 1.1, all articles are kept only one or two days
and expired, expcept articles which have Expires: header.

There was a bug in innd/art.c, and this is simple fix.

--
Takahiro Kanbe <taka@fxis.fujixerox.co.jp>	FXIS / Network Team.

*** innd/art.c.~1~	Wed Sep  2 16:44:48 1992
--- innd/art.c	Sun Sep  6 22:51:55 1992
***************
*** 825,837 ****
      }
      p = HDR(_expires);
      Data->Expires = 0;
!     if (*p == '\0' && (Data->Expires = parsedate(p, &Now)) == -1) {
  #if	0
  	(void)sprintf(buff, "Bad \"Expires\" header -- \"%s\"",
  		MaxLength(p, p));
  	return buff;
  #endif
!     }
  
      /* Whitespace in the Newsgroups header? */
      for (p = HDR(_newsgroups); *p; p++)
--- 825,838 ----
      }
      p = HDR(_expires);
      Data->Expires = 0;
!     if (*p != '\0')
!       if ((Data->Expires = parsedate(p, &Now)) == -1) {
  #if	0
  	(void)sprintf(buff, "Bad \"Expires\" header -- \"%s\"",
  		MaxLength(p, p));
  	return buff;
  #endif
!       }
  
      /* Whitespace in the Newsgroups header? */
      for (p = HDR(_newsgroups); *p; p++)
Xref: sparky news.software.nntp:1145 news.software.b:2943
From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre)
Newsgroups: news.software.nntp,news.software.b
Subject: Re: INN, NNTP & compressed articles
Summary: Actually NNTP on high RTT links
Date: 14 Sep 92 22:25:58 GMT
Followup-To: news.software.nntp
Organization: Olivetti ATC; Cupertino CA, USA

In article <192nosINNp76@nigel.msen.com> emv@msen.com (Edward Vielmetti) writes:
>: >Yes, the roundtrip time in the IHAVE negotiation can be a killer.  I don't
>: >buy the theory that INN is no good with slow links; It works fine unless
>: >the RTT is so large that no NNTP implementation has a hope of keeping up.
>
>Some of the better connected sites, in terms of diverse feeds, access to
>regional groups, relatively timely delivery etc. are off on "slow" links. 
>Surely you don't need a T1 network capable of delivering 12,000 MB/day for
>sending "only" 40 or 50 MB...

It has nothing to do with bandwidth.  It has to do with the round trip
time (RTT).  If your T1 is via geosynchronous satellite then you will
get a whopping 0.8 articles per second MAXIMUM!  Luckily you can reject
1.6 articles per second.  That is because the sender will blast off its
pidling 40 bytes of "ihave" and then wait 0.3 seconds for it to get to
the receiver, wait for it to be looked up in the receivers history file,
and then wait another 0.3 seconds for the response to get back.  And
then repeat the whole process again to actually transfer the article.
The T1 will have no more thruput than a 9600 bps link.

It is not always practical or efficient to use multiple fees.  For
example the link may be an company internal one with only one reachable
usenet site on each end.

I can see it now, the first usenet site on mars fires up the 1000 Gbps
laser link to earth and starts NNTP transfer to their 10000 MIPs laptop
computer.  But they only get one article every 10 minutes!  (Not to
mention they won't get most articles because their feed won't pass
a distribution of "world" off planet). :-)
From: pj@linz.ensmp.fr (Pierre JOUVELOT <jouvelot@cri.ensmp.fr>)
Newsgroups: news.software.nntp
Subject: Statistics on NNTP transfers?
Date: 10 Sep 92 11:58:29 GMT
Organization: Ecole des Mines de Paris, France


Is there a way to log nntp traffic on an nntp server?  

I want to know who logs from where, when and for how long.  And no, I'm
not a cop but just someone trying to show how useful the News system is
on our site.  If this is an FAQ, sorry.

E-mail answers please  (my News feeder backlog is 2 weeks:-(

Thanks,

Pierre
--
Pierre Jouvelot		       			E-mail: jouvelot@cri.ensmp.fr
Centre de Recherche en Informatique		TPH: +33 (1) 64.69.48.36
Ecole Nationale Supe'rieure des Mines de Paris
From: gunnar@beppe.ericsson.se (Gunnar Forsgren)
Newsgroups: news.software.nntp
Subject: Simple support script example for 'nntpxfer'
Keywords: nntpxfer
Date: 11 Sep 92 10:50:20 GMT
Reply-To: gunnar@beppe.ericsson.se
Followup-To: news.software.nntp
Organization: Ericsson Telecom AB

Below is a few lines of shell script that shows an example of how
'nntpxfer' can be used to fetch new articles from a newsgroup
on another NNTP server for the purpose of updating a copy of that
newsgroup on your NNTP server. The use of it is to have 'cron'
run this script at a suitable interval. The script stores a
timestamp of the most recent access in a file which is used
the next time the script is run to fetch only articles that may have arrived
since the previous run. This is only a simple example,
user can add fault handling or change this script to whatever is appropriate.
A bug in the script is that if a new article appears within the timeframe after the
logged time but before 'nntpxfer' actually runs,
that article might be fetched and become a duplicate
the next time around, maybe somebody has a solution to this ?

It seems the script terminates when 'nntpxfer' has run, so any script
statements located after the 'nntpxfer' call will not be executed.
Maybe somebody also knows why this is so ?

Before running the script, put an initial date in file '/etc/tlog'
in format YYMMDD HHMMSS', for example '920501 113000'.
This date determines for how long back news articles will be requested
the first time you run. After run, the date is updated with the current date.
All runs are logged in file '/usr/lib/news/xferlog', comment out if not wanted.

---
Gunnar Forsgren  Ericsson Telecom AB  email:<gunnar@beppe.ericsson.se> 
S-126 25 Stockholm, SWEDEN            phone:+46 8 7196118 fax: 7192900


-------------- example of 'crontab' entry : ----------------------

(Runs every 15 minutes during office hours to request new articles from
 newsgroup 'alt.dogs' on NNTP server 'nserve')

0,15,30,45 8-18 1-31 *  1-5     su news -c '/etc/getnews nserve alt.dogs'


-------------- script 'getnews' : -------------------------------- 
#!/bin/sh
# This script requests new articles from NNTP server host '$1'
# that has arrived in newsgroup '$2' since the last saved date
# stored in file 'tlog'.
# For each successful transfer, the current date is saved
# so the next time the script is run, new news will be
# requested that has arrived since the last transfer.
# The purpose is to have this script be executed by 'cron'
# to fetch newly arrived articles at some defined intervals.
#
i=`cat /etc/tlog`		# Read timestamp from file
dat=`date +%y%m%d`		# Get date in YYMMDD format
tim=`date +%H%M%S`		# Get time in HHMMSS format
echo "getnews since ${i} from ${1}:${2} at ${dat} ${tim}" >> /usr/lib/news/xferlog
echo $dat $tim > /etc/tlog	# Save current timestamp to file
/usr/bin/nntpxfer $1 $2 $i	# Request news since previous xfer
-------------------------------------------------------------------------
From: kurt@dna.lth.se (Kurt Swanson)
Subject: Re: New-group-action
Organization: Lund Institute of Technology, Sweden
Date: Mon, 14 Sep 1992 18:03:44 GMT

mho@stacken.kth.se (Magnus Holmberg) writes:
>In <1992Sep14.131734.3492@lth.se> kurt@dna.lth.se (Kurt Swanson) writes:
>>I am surprised that no option allows new groups to be unsubscribed
>>that keeps it's name in .newsrc....
>>Is there a higher reason for this?  (maybe a programming limitation?)
>>Does anyone have an idea how this might be done?
>	You might want to set the variable keep-unsubscribed...

Och det har jag gjort...

That I have done, but we're talking about NEW groups.
Keep-unsubscribed only affects to status of the rc line for groups
that were already subscribed.  It is, however, needed to be set for
proper function of new-group-actions 1 and 2, since they only rely
upon .newsrc for determining whether or not a group is new.  For more
info type ":man<ret>yX/new-group-action<ret>/<ret>"...
-- 
Kurt Swanson, Dept. of Computer Science,
Lunds universitet.  Kurt.Swanson@dna.lth.se
Newsgroups: news.software.nn
From: chuck@edsi.plexus.COM (Chuck Tomasi)
Subject: Re: The future of NN - good news (send me patches)
Organization: Enterprise Data Systems Incorporated, Appleton WI
Date: Thu, 10 Sep 1992 18:52:55 GMT

scs@iti.org (Steve Simmons) writes:

:)Given that many sites have already accepted them, I'd take them as
:)official and follow them up with patch 19 ASAP to do any needed
:)cleanup to bring them to "official" format (even if it only changes
:)a comment or two to mark them as legit).  Then grab the other fixes
:)people have and go from there.

On the other hand many sites have NOT accepted them as they have not
come from Kim himself therefor it would be advantageous to post them or
make them FTP'able somewhere and let people know where they are and they
are now official.  I'm still running PL16 so patch #19 won't do me much
good until I get my hands on (so far unofficial) 17 and 18.
-- 
Chuck Tomasi             |     "It's my job to help
chuck@edsi.plexus.COM    |      but I don't have to like it."
spool!cserver!edsi!chuck |                    -Dr. Crusher, "I, Borg"
------<Enterprise Data Systems Incorporated, Appleton Wisconsin>------
Newsgroups: news.software.nn
From: bartscht@irb.uni-hannover.de (Eckhard Bartscht)
Newsgroups: news.software.nn
Subject: Emacs Newsreader using NN database?
Date: 14 Sep 92 13:04:19 GMT
Organization: IRB Uni-Hannover, Germany

Does anyone know of a newsreader for Emacs (something like GNUS for
example) that uses the nn-database?

                                                    Eckhard Bartscht
--
signature intentionally left blank