Retro Guy wrote:

> SugarBug wrote:

>> On Fri, 19 Jan 2024 11:57:06 +0000
>> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>>> SugarBug wrote:
>>>
>>> > On Thu, 18 Jan 2024 19:39:59 +0000
>>> > retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>>>
>>> >> SugarBug wrote:
>>> >>
>>> >> > On Thu, 18 Jan 2024 06:50:04 -0700
>>> >> > Retro Guy <retroguy@novabbs.org> wrote:
>>> >>
>>> >> >> On Thu, 18 Jan 2024 06:38:51 -0700, Retro Guy wrote:
>>> >> >>
>>> >> >> > On Thu, 18 Jan 2024 07:13:00 -0600, SugarBug wrote:
>>> >> >> >
>>> >> >> >> On Wed, 17 Jan 2024 18:21:51 +0000
>>> >> >> >> retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>>> >> >> >>
>>> >> >> >>> SugarBug wrote:
>>> >> >> >>>
>>> >> >> >>>> I noticed that with a peer (GRC) that ignores custom
>>> >> >> >>>> Message-ID that a duplicate message is created in the
>>> >> >> >>>> newsgroup.
>>> >> >> >>>
>>> >> >> >>>> Steps:
>>> >> >> >>>
>>> >> >> >>>> 1. Post a message via the local server. The message posts
>>> >> >> >>>> with the Message-ID generated by rslight.
>>> >> >> >>>
>>> >> >> >>>> 2. The remote INN server accepts the message on sync but
>>> >> >> >>>> strips the Message-ID and replaces it with its own
>>> >> >> >>>> Message-ID.
>>> >> >> >>>
>>> >> >> >>>> This should be reproducible by posting to grc.test.
>>> >> >> >>>
>>> >> >> >>>> If the remote server strictly generates its own message-id
>>> >> >> >>>> in place of the provided message-id, rslight is not aware
>>> >> >> >>>> of this. So rslight then stores its original message in the
>>> >> >> >>>> spool with its own Message-ID, then pulls the message from
>>> >> >> >>>> remote containing the remote-generated Message-ID. This
>>> >> >> >>>> results in the same message appearing twice with two
>>> >> >> >>>> Message-ID values.
>>> >> >> >>>
>>> >> >> >>>> Is there any configuration option to get rslight to accept
>>> >> >> >>>> the Message-ID from the remote, or at least discard one of
>>> >> >> >>>> the duplicate messages and refrain from re-copying the
>>> >> >> >>>> duplicate to and from the remote?
>>> >> >> >>>
>>> >> >> >>> Interesting. So the remote server is ignoring the supplied
>>> >> >> >>> MID and creating it's own.
>>> >> >> >>>
>>> >> >> >>> Does the remote server send a reply to state this? If it
>>> >> >> >>> does, rslight could then modify it's MID. If not, we'll
>>> >> >> >>> need to code it to NOT generate a MID for a certain
>>> >> >> >>> <section>. If it DOES send a reply, that would be better.
>>> >> >> >>> Can you see if it does that?
>>> >> >> <snip>
>>> >> >> >>
>>> >> >> >> Two of the test messages generated duplicates. Two did not:
>>> >> >> >>
>>> >> >>
>>> >> >> My guess is that two were not inserted immediately and two were.
>>> >> >> The ones not inserted immediately were only inserted after
>>> >> >> receiving back from remote server (so no duplicate).
>>> >> >>
>>> >> >> Rslight will not insert immediately if spoolnews for the
>>> >> >> specific section is running at that moment. In that situation,
>>> >> >> it will only prepare it for send to remote server and wait for
>>> >> >> it's return. (That will explain why some messages do not appear
>>> >> >> immediately after posting)
>>> >>
>>> >> > I ensured the cron job was not running and I posted two
>>> >> > messages.
>>> >>
>>> >> > Then I ensured the cron job was running and I posted one
>>> >> > message.
>>> >>
>>> >> > I can confirm that a duplicate was created while the cron was
>>> >> > running.
>>> >>
>>> >> Messages won't immediately insert if the specific spoolnews.php for
>>> >> the specific <section> is running. Cron can be running, just not
>>> >> the specific spoolnews.php.
>>> >>
>>> >> > Here are the duplicate message-id headers:
>>> >>
>>> >> > <8b99344ade793ca9dc76e6d34b5e8295$1@sybershock.com>
>>> >> > <uobr41$k2l$1@GRC>
>>> >>
>>> >> > Here is the spoolnews entry:
>>> >>
>>> >> > spoolnews.log:Jan 18 18:36:49 grc Posted: .msg: 240 Article
>>> >> > received <uobr41$k2l$1@GRC> Removed: 1
>>> >>
>>> >> > All three messages were posted using claws-mail. All three
>>> >> > messages were posted to my rslight NNTP server, which then
>>> >> > synced to the GRC test group.
>>> >>
>>> >> Ok, thank you for testing. It does look like anytime a message is
>>> >> immediately inserted, it gets duplicated. I don't see a way around
>>> >> that other than a config option to disable immediate insertion for
>>> >> the section.
>>>
>>> > I think you are right in your assessment. Since GRC is opinionated
>>> > about using only its own serialized Message-ID header I don't know
>>> > of any way to tell the remote server to override that behavior. If
>>> > you want to try a config hack I will test it and report back.
>>>
>>> I just made a mod to rslight-lib.php and it seems to work fine. It is
>>> sending a MID, but doesn't need it for anything, so the message
>>> returning with a different MID should be ok.
>>>
>>> For a quick test, please add this to the beginning of 'function
>>> insert_article' in rslight-lib.php (line 1101):
>>>
>>> file_put_contents($logfile, "\n" . format_log_date() . " " . $section
>>> . " Insert Disabled... Queuing local post: " . $nntp_group,
>>> FILE_APPEND); $return_val = "240 Article received OK (queued)\r\n";
>>> return ($return_val);
>>>
>>> Then kill any running nntp servers and try posting.
>>>
>>> It works for me, but let's make sure it's ok and if so, we'll add a
>>> config toggle for it.
>>>
>>> Here's a nntp.log entry when there is a post:
>>> Jan 19 11:41:51 rocksolid Insert Disabled... Queuing local post:
>>> rocksolid.test.test

>> The hack is working on this end. The messages are withheld from the
>> local spool and interface. The proper message is pulled from the GRC
>> test group on the next cycle.

> Great! I will write it up to use a config toggle. I haven't decided yet whether $CONFIG or $OVERRIDES. $CONFIG is more difficult as it requires modifying every <section>.inc.php file if you already have an install, but it still might be better. Not sure yet.

Decided to go with $OVERRIDES. Example:

// Disable immediate post insertion (wait for remote server)
// for a SECTION. Comma separated list ex: 'rocksolid,section3,section5',
'insert_disable' => 'grc',

So you will be able to disable immediate insertion by <section>.

It's not done yet, just letting you know my plan.

--
Retro Guy