*** John Goerzen [2020-12-27 22:34]:
>Ahhhh..  I hadn't realized that it had to be in sync on both ends. When I
>corrected that, it began behaving as expected.  That does have some logic to
>it; presumably whatever side has the smallest value becomes the operative one
>for the connection?  This may be a useful thing to document wherever those
>settings are referenced.

Agreed and will document it explicitly. Each side has its own deadline
timers and if one is decided that session is over, then of course it
will disconnect.

>Is there something built into NNCP that does this log rotation and
>compression, by the way?

No. It was created by newsyslog rotation daemon that comes out of box in
FreeBSD. http://www.git.cypherpunks.ru/?p=nncp.git;a=blob;f=ports/nncp/files/nncp.newsyslog.conf.sample;hb=develop
Actually I very like the idea that no daemons should be bothering about
all that log rotation and they just should print log to stdout that will
be processed with some utilities like multilog from daemontools. But
that is acceptable only for non-interactive daemons. NNCP has manually
started utilities, so they write log files manually. Because all of them
open/close file for writing every single line of log, there is no
problems with simple log rotation with newsyslog.

>What I would not want is to weaken the existing NNCP protections around
>"via"; for instance, B should never be able to see the unencrypted data in
>this setup.

Personally I make my backups with gpg too, but just to be sure that
their encrypted form is placed on long-term storage:
    zfs send -R | zstd | gpg -z 0 -r ... -e | nncp-file - ...
Anyway I should think about all of that subject with multiple
recipients. If A sends data to C, -via B, then B-node anyway will see
only and only transitional (encrypted) packet to C-node. If C-node will
be an additional recipient, then it will also see that transitional
packet, but also it sees that its destination is C-node itself and it
can immediately begin also decrypting it. Of course C-node will decrypt
two packets to get the data from A-node: packet for B-node (and
additionally C-node) and packet inside it for C-node itself.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF