[leafnode-list] Re: [Mcgoo-nttpbeta]Leafnode posting problems

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

"San 'NeTTwerk' Mehat" <nettwerk@xxxxxxxxxxxxxx> writes:

> I'm sorry Matthias, but as I mentioned earlier, SFNNTPD *MUST* be the
> entity that assigns the message ID in order to provide proper
> synchronization between the web, and proper article numbering within our
> database schema. This also allows us to facilitate synchronization
> within threads between replies posted via NNTP, and replies posted via
> the web. (The 'References' header sent on a message reply for example).

Other news software before has managed to coordinate article numbers and
Message-IDs without clobbering the user-provided Message-ID.

Other news software before has managed to thread without tampering with
the user-provided Message-ID or references.

>   The only point where I can really see the possibility of a 'major
> accident' is where someone decides to redistribute content taken from
> SFNNTPD to someone else. The intended use for SFNNTPD is to be a
> single-client communications point for participating in sourceforge
> forums; *not* to be a usenet/nntp distribution point.

Usenet software has always relied on the uniqueness and integrity of
Message-IDs. People who thought they knew better drowned in duplicates before.

Here is my official statement on the leafnode-vs-SFNNTPD issue:

------

1. Leafnode was not designed to work with broken NNTP servers.

2. Server that mangle the Message-ID in a posted article are broken.
   (Adding a Message-ID when none is present, is fine though.)

3. Leafnode's retrieval and posting agent, "fetchnews", relies on the
   integrity of Message-IDs. It reposts an article it was given until
   one article with the same Message-ID shows up on the upstream
   server. Fetchnews requires: 1. STAT <Message-ID> says 430 no such
   article (with any text) before POST, 2. STAT <Message-ID> replies
   with 223 0 <Message-ID> after a POST, with the Message-ID being the
   same as was in the article.

   So two SFNNTPD bugs cause duplicates:

   i. Message-ID mangling.

   ii. SFNNTPD does not implement STAT <Message-ID> although RFC-977
   requires so.

4. Even if I wanted to work around this Message-ID sabotage, you'd still
   see duplicates, because I have no means of forcing users to upgrade.

5. I'm not taking responsibility for duplicates that happen because the
   server tampers with user-provided Message-IDs.

6. I will not fix incompatibilities that I am not responsible for.

------

As a side note, I'm also sometimes frustrated about users who refuse to
update leafnode even after they've been advised their version is broken
and when an update takes a single line or a few mouse clicks.
I have no means, neither technical nor legal, to force them to update.

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list