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