public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: "Jonathan Lane" <jon@borg•moe>
Cc: <nncp-devel@lists.cypherpunks.su>
Subject: Re: nncpnet tools usage
Date: Sat, 18 Oct 2025 08:05:38 -0500	[thread overview]
Message-ID: <871pn0pdgd.fsf@complete.org> (raw)
In-Reply-To: <DDKENQUEG378.3B6WW17L726NG@borg.moe> (Jonathan Lane's message of "Fri, 17 Oct 2025 00:06:05 -0700")

Hi Jonathan,

Replies below.

On Fri, Oct 17 2025, Jonathan Lane wrote:

> I'm working on wiring up the NNCPNet tools to Postfix and I don't
> understand how nncpnet-transmit is reading the HOST and RECIPIENT
> environment variables in the docker container.  Is Exim just injecting
> those when it invokes nncpnet-transmit?  Are all MTAs with a "pipe
> transport" expected to behave the same way?

Yes, those come from Exim and are documented at

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_pipe_transport.html

I don't know what other MTAs might do, but there is a need to get this
information out of band because the RFC822 headers don't always
adequately cover all cases.  The simplest example is in the case of a
Bcc; it won't be in the message headers but will be in the SMTP
conversation (or, in this case, the NNCP parameters)

> On a related note the absolute filepaths in nncpnet-transmit.rs are
> gross, mixing /opt and /usr/local.  The required use of the exploded
> config format is also fragile.  I'm probably going to end up rewriting
> this tool regardless of how the RECIPIENT magic works.

I was pressed for time when writing it, and as its target was a defined
environment, that worked fine.  But I'd be happy to add a simple way to
specify those paths (perhaps via environment variables or a config
file).

I guess you mean the NNCP cfgdir format when you mention "exploded
config format"?  I don't know that it's any more fragile than the hjson
format.  Anyhow, that format is used not for the benefit of nncpnet --
it's easy enough to parse hjson in Rust anyhow -- but rather for the
benefit of the nodelist processing scripts, which I wrote as shell
scripts.  It makes it much simpler to filter the quux nodelist for
things such as nodes that are flagged as NNCPNET participants, and
public Internet bridge participants.

Automatic processing of the quux nodelist was an important objective for
the project, so that manual action would not be required from every
participant every time a node joins or leaves.

That said, even if parsing HJSON were possible in a given language,
those parsers often don't preserve the comments, which are used for
these flags.

In any case, if you do rewrite it, I would be happy to review your work
and possibly switch my own container to use it.  There's no inherent
need for more than one of these.

- John

  reply	other threads:[~2025-10-18 13:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17  7:06 nncpnet tools usage Jonathan Lane
2025-10-18 13:05 ` John Goerzen [this message]
2025-10-24 20:55   ` Jonathan Lane