handle empty proposed message IDs in NNTP gracefully



14 years ago
10 years ago


(Reporter: Sebastian, Unassigned)


Firefox Tracking Flags

(Not tracked)




14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041121 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041121 Firefox/1.0

Some NNTP servers do not propose a message id. Here is an expert of the log I
created with Thunderbierd:
Receiving: 340 Ok, recommended ID

Posting will then fail with "538 Bad message id". If I resubmit the exact same
message a second time, the server proposes an id:
Receiving: 340 Ok, recommended ID <cunsfn$7u4$1@nntp>

Sending works just fine in this case.

THe NNTP server in question here is: "nntp.i2p InterNetNews NNRP server
INN 1.7.2 08-Dec-1997 (Debian/29)"
I don't have access to its configuration, so I don't know if it could/should be
configured differently.

Could thunderbird create a message id if none is proposed? That would be
terrific. I do see that the problem is probably with the server, but we should
still be able to handle it without pressing "send" twice :-).

Thank you.

Reproducible: Always

Comment 1

14 years ago
err :-): s/expert/excerpt
QA Contact: general
Assignee: mscott → nobody
Joshua, thoughts?

(should this be moved to News?)
(In reply to comment #2)
> (should this be moved to News?)


> Joshua, thoughts?

Well, we ignore the posting response code in any case. Also, the semantics of the return code are "<response code> <explanatory text>", which means we don't see what INN is telling us about message IDs anyways, so this is INVALID.

There is a related bug (somewhere) about not using our own Message-IDs, but I can't find that off the top of my fingers right now.
Last Resolved: 10 years ago
Component: General → Networking: News
Product: Thunderbird → Core
QA Contact: general → networking.news
Resolution: --- → INVALID


10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.