public inbox for nncp-devel@lists.stargrave.org
Atom feed
* nncpnet tools usage
@ 2025-10-17 7:06 Jonathan Lane
2025-10-18 13:05 ` John Goerzen
0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Lane @ 2025-10-17 7:06 UTC (permalink / raw)
To: nncp-devel
Hello,
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?
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.
--
Jonathan Lane
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: nncpnet tools usage
2025-10-17 7:06 nncpnet tools usage Jonathan Lane
@ 2025-10-18 13:05 ` John Goerzen
2025-10-24 20:55 ` Jonathan Lane
0 siblings, 1 reply; 3+ messages in thread
From: John Goerzen @ 2025-10-18 13:05 UTC (permalink / raw)
To: Jonathan Lane; +Cc: nncp-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: nncpnet tools usage
2025-10-18 13:05 ` John Goerzen
@ 2025-10-24 20:55 ` Jonathan Lane
0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Lane @ 2025-10-24 20:55 UTC (permalink / raw)
To: John Goerzen; +Cc: nncp-devel
On Sat Oct 18, 2025 at 6:05 AM PDT, John Goerzen wrote:
> 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)
I found out that Postfix allows you to present an equivalent recipient
as a command line argument. I don't have Salsa access so I put my fork
on Sourcehut.
https://git.sr.ht/~tidux/nncpnet
This assumes "recipient" is one big quoted string as far as argv goes.
If it's not I'll need to build iteration in it. Adding "$RECIPIENT" to
the end of the Exim config file should perform equivalently to Postfix.
The Postfix config I'm working on doesn't rely on Dovecot since it's
getting rolled into GNOME and KDE based desktop OSes, but
Postfix+Dovecot takes about ten minutes to set up so if there's demand I
could put that in an Ansible playbook or something.
> 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.
I agree. My idea was to treat the cfgdir as an intermediate HJSON
parser since "move one file" is a lot more atomic than "move a bunch of
files and directories." So something like
```
nncp-cfgdir -cfg /etc/nncp.hjson -dump /tmp/nncpdir
nodelist-proc
nncp-cfgdir -load /tmp/nncpdir > /etc/nncp.hjson.new
cp /etc/nncp.hjson "/etc/nncp.hjson.$(date -Isec)"
mv /etc/nncp.hjson.new /etc/nncp.hjson
rm -rf /tmp/nncpdir
```
--
Jonathan Lane
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-10-24 20:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-17 7:06 nncpnet tools usage Jonathan Lane
2025-10-18 13:05 ` John Goerzen
2025-10-24 20:55 ` Jonathan Lane