From Newsgroup: news.software.nntp

I have a question about the 'recommended Message-ID' when posting via nnrpd.

My servers generate a MID for posts when the user does not create their own. This MID is a hash of some parts of the message, which allows a future duplicate (maybe a newsreader tries to resend for some reason) to be rejected simply by having the same MID.

I don't know if any readers use the 'recommended Message-ID' line for anything, but if they do, and if they believe this will be the MID, they will be incorrect.

Is there a way for me to either specify the MID here? I can't actually, because I need the message first, so I guess the question is, is there a way to not send this info at all? I've read in the FAQ about setting a different domain name here, but that does not fix the issue.

Thanks for any help.
--
Retro Guy <retroguy@i2pn2.org>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

In article <82047ed9fe64034c6e2327f0131dddae8f595c4e@i2pn2.org> Retro Guy wrote:

I don't know if any readers use the 'recommended Message-ID' line for anything, but i

tin uses it
a) as message-id (not an issue if the posting ends up with a diffrent id)
b) for cancel-locks (that will be an issue)

tinews (nntp inews in perl) uses it
a) as message-id (not an issue if the posting ends up with a diffrent id)
b) for cancel-locks (that will be an issue)
c) for header signing (that will be an issue)

so I guess the question is, is there a way to not send this info at all?

then the user/reader may still send it's own message-id and you should not overwirte it as that may break cancel-locks or header signing.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On Fri, 13 Sep 2024 14:20:26 -0000 (UTC), Urs Jan#en wrote:

In article <82047ed9fe64034c6e2327f0131dddae8f595c4e@i2pn2.org> Retro Guy wrote:

I don't know if any readers use the 'recommended Message-ID' line for anything, but i

tin uses it
a) as message-id (not an issue if the posting ends up with a diffrent id)
b) for cancel-locks (that will be an issue)

tinews (nntp inews in perl) uses it
a) as message-id (not an issue if the posting ends up with a diffrent id)
b) for cancel-locks (that will be an issue)
c) for header signing (that will be an issue)

so I guess the question is, is there a way to not send this info at all?

then the user/reader may still send it's own message-id and you should not overwirte it as that may break cancel-locks or header signing.

Thanks for this info!

On my servers if the client sends it's own message-id, that is the mid used
for the message, so if I'm reading properly it should not be an issue in
most cases. Hoping I understand correctly :)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Retro Guy <retroguy@novabbs.com> wrote or quoted:

On my servers if the client sends it's own message-id, that is the mid used >for the message, so if I'm reading properly it should not be an issue in
most cases. Hoping I understand correctly :)

Yeah, it's the same here. I write the message-ID I want in my
headers. Then I send my message with a small Python script.
That script shows the messages from the news server verbatim:

|b'340 Ok, recommended ID <A>\r\n'
|b'240 Article posted <B>\r\n'

, where <A> is the ID the server recommends and <B> is the
message-ID from my header lines.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On 13 Sep 2024 17:02:10 GMT, Stefan Ram wrote:

Retro Guy <retroguy@novabbs.com> wrote or quoted:

On my servers if the client sends it's own message-id, that is the mid used >>for the message, so if I'm reading properly it should not be an issue in >>most cases. Hoping I understand correctly :)

Yeah, it's the same here. I write the message-ID I want in my
headers. Then I send my message with a small Python script.
That script shows the messages from the news server verbatim:

|b'340 Ok, recommended ID <A>\r\n'
|b'240 Article posted <B>\r\n'

, where <A> is the ID the server recommends and <B> is the
message-ID from my header lines.

That sounds good.

What I want to avoid is a client using the "Ok, recommended ID", not
sending a MID, then relying on that recommended ID. My server creates a MID
for messages that do NOT contain a MID, after the message is received, but before the connection is closed.

If you geneerate a MID at the client, that is what is used.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Hi Retro Guy,

'recommended Message-ID' line [...]
is there a way to not send this info at all?

This information is always sent by INN and cannot be deactivated.

|b'340 Ok, recommended ID <A>\r\n'
|b'240 Article posted <B>\r\n'

What I want to avoid is a client using the "Ok, recommended ID", not
sending a MID, then relying on that recommended ID. My server creates a MID for messages that do NOT contain a MID, after the message is received, but before the connection is closed.

A news client is not supposed to do that. The data following the 340
and 240 codes are just comments, with no special meaning defined by the
NNTP protocol. See the example in RFC 3977:

[C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: An Example Net
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received OK


If a news client wants to parse the comments for possible Message-IDs as
INN and maybe other news servers provide them, let's trust the developer
to implement it right and take the one of the 240 response. That would otherwise be a bug in the implementation.
And if not implemented, you don't mind.
--
Julien |eLIE

-2-aIl vaut mieux avoir de l'avenir que du pass|-.-a-+

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On Fri, 13 Sep 2024 19:24:34 +0000, Julien |eLIE wrote:

Hi Retro Guy,

'recommended Message-ID' line [...]
is there a way to not send this info at all?

This information is always sent by INN and cannot be deactivated.

|b'340 Ok, recommended ID <A>\r\n'
|b'240 Article posted <B>\r\n'

What I want to avoid is a client using the "Ok, recommended ID", not
sending a MID, then relying on that recommended ID. My server creates a
MID
for messages that do NOT contain a MID, after the message is received,
but
before the connection is closed.

A news client is not supposed to do that. The data following the 340
and 240 codes are just comments, with no special meaning defined by the
NNTP protocol. See the example in RFC 3977:

<snip>

If a news client wants to parse the comments for possible Message-IDs as
INN and maybe other news servers provide them, let's trust the developer
to implement it right and take the one of the 240 response. That would otherwise be a bug in the implementation.
And if not implemented, you don't mind.

Thank you for the info Julian!

I'll then continue as I am now, producing a mid for articles which do
not already contain one.
--
Retro Guy
--- Synchronet 3.21a-Linux NewsLink 1.2