Closed Bug 80819 Opened 23 years ago Closed 22 years ago

Mozilla News Client does create Message-Ids

Categories

(MailNews Core :: Networking: NNTP, defect)

Product:
MailNews Core
Component:
Networking: NNTP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fgkoehler, Assigned: bugzilla)

Details

Attachments

(2 files, 4 obsolete files)

yet another update
3.66 KB, patch
bugzilla
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
small UI for disabling/enabling the setting
1.15 KB, text/plain
Details 
Mozilla's news client does always create Message-Ids for news article with the
user's domain as fqdn, which is incorrect (See son-of-1036 for details).
To avoid Message-Id dupes it shouldn't generate a Message Id, instead, the news
server, which the article is injected, should generate it (as it is recommened
by rfc).
My suggestion is to disable Message-Id Generation by default and, if the user
requests it explicitely, the Domain part of the Message-Id should be created
with the Hosts Fully Qualified Domain Name [uname()].
Domain part in Message-IDs for mail should always be created with the hosts fqdn.
Confirming...
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think there's a bug on this already.
You can not always disable Message-Id generation - for messages that are address
both to newgroups and e-mail addresses you need to generate Message-Ids so that
the newsgroup message and the e-mail message have the same Message-Id (with all
the email-news gateways out there it's possible that the paths of different
copies of the message will cross again and it would be nice if they had the same
IDs when that happens).
The safest way to have a unique MID is to let the news server create it. A MID
MUST be unique for at least 2 years (ideally live-long), creating it locally by
the news agent does not guarentee uniqueness.
RFC-1036 says "... where full_domain_name is the full name of the host at which
the message entered the network..."
The message/posting does not enter the network at the user's mail server.
Please, this issue is very important for many many people (especially in German
usenet). For users with FQDN add a user_pref or an UI option to specify the FQDN.
QA Contact: esther → stephend
Isn't this #54540?

*** This bug has been marked as a duplicate of 54540 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This bug is _not_ a duplicate of 54540, so I'll reopen it.

Bug 54540, in brief, states that Mozilla should check wether the domain
part of the From:, when using it to generate a Message-ID, is a valid
FQDN. However, even if it is a valid FQDN, the user need not be allowed
to use this FQDN to generate MID's (or better: the home user usually is
*not* allowed to use it, See son-of-1036 for details), and this second
point is the subject of bug 80819.

Creating message-ID's that are unique is very important in Usenet, because
servers as well as clients use them to decide wether to accept or reject (or
load or ignore for clients) a specific posting. The result of the current
behavior of Mozilla is that, with lots of users having the same domain part in
their e-mail-adress, like @aol.com, @msn.com or @gmx.de, probability increases
for duplicate message-ID's. The safest way, as pointed out in the RFC's, is to
let the news server create the message ID's, not the client.

I recommend that this be the default behavior in Mozilla. Adding a configuration
option to allow power users with their own FQDN create their own message-ID's
would be great, though.

Frank
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Hi there

Is it possible to have a checkbox in preferences to disable/enable generating an
message-id? The default setting to kreate a msg-id has to be for the normal user
as disabled.

See also the Message <9ugnje$80d$04$1@news.t-online.com> in
news:de.comm.software.newsreader

Andi
Hi,

I suggest targeting this for 1.0 (and fixing it with adding the preference Andi
Heitzer suggested).
Short justification (I wrote a long one in bug 54540): Clients generating
potential ambiguous message ids are near to unusable.

Frank
I suggest this patch for solving the problem.
It modifies msg_generate_message_id in nsMsgCompUtils.cpp so that the given
identity is asked whether or not to generate message ids.

In an default installation (where the pref is not present) this will lead to id
generation as before ('cause GetBoolAttribute defaults to PR_FALSE if the pref
is not found), but if the user enters a
user_pref("mail.identity.<id>.no_message_id", true);
to her preferences, messages sent with this identity won't get a client-side
message id.
the default setting should be, not to generate a message id, unless the user
explicitely wants mozilla to generate one.

is this going to be fixed until v1?

a gui parameter would be nice as well....
same patch, but this time with context information
(like to make 70486 obsolete, bug have no permissions for this ....)
Franz,

not sure about what you said about the default setting. Finally, having no
message id has a disadvantage: If you group the messages you sent the and ones
you get, then a message without id sent by you will break the threading.

As long as there is no easy user interface to control the generation, I think
most people would be annoyed by the fact that they have to manually edit the
prefs.js to get their threading back. That's why I think any patch should keep
the behaviour unchanged, and allow to disable generation for the advanced user.
Attachment #77399 - Attachment is patch: true
Attachment #70486 - Attachment is obsolete: true
Frank,

I think Franz wants Mozilla _not_ to generate Message-ids for _news_ only. There
should be a difference between mail and news in generating message-ids.
Default for mail: let Mozilla create a message-id.
Default for news: do not create a message-id unless the user specifies one.

- Holger
Ah! good idea ...

Hmm. Damn. Have no mozilla source here at work, but I'm eager to look into the
code to see how much this would take ...
> I think Franz wants Mozilla _not_ to generate Message-ids for _news_ only. There
> should be a difference between mail and news in generating message-ids.

But this should *not* be based on the type of the account used, but only on the
actual destination of the message. If a message is going to both some
newsgroup(s) and some mail recepient(s), then the ids whould definitely be
generated!
> But this should *not* be based on the type of the account used, but only on the
> actual destination of the message. If a message is going to both some
> newsgroup(s) and some mail recepient(s), then the ids whould definitely be
> generated!

Pure usenet messages should not contain client-generated ids, unless the user
insists in his software to do so and ensures validity of the id.
In this case (and to a usenet article which gets also mailed) mozilla should
create the message-id based on the host's (which it is running on) fully
qualified domain name.
I.E., if I'm running mozilla on a host named 'test.buech.se' mozilla should
generate a id like <uniqueid@test.buech.se> .
So this would mean (in order of importance):

1. if the message is targeted to at least one mail account, generate a valid id
2. if the message is targeted to news accounts only, check a preference
3. if (and only if!) the preference forces client-side ids, generate a valid one

(BTW: The "valid" in 1. and 3. is covered by bug 54540. I think discussing it
should not be part of this bug here, we should assume a valid algorithm for
generating an id).

Is this correct? Any opinions?
Frank,

sound good. :-)

- Holger
this patch implements the behaviour suggested in comment #18.

In addition, I allowed myself :) to let the generation depend on the delivery
mode. With the current behaviour, message ids are generated when only saving a
message (normal, as template, or as draft), too. Though these ids are ignored
later on, and superseeded by new ones, I thought that would make sense to
generate an id only if a message is sent immediately or stored for later
sending. Flame me if you disagree :)
Attachment #77399 - Attachment is obsolete: true
forgot to mention that I chose "generate_news_message_id" as preference name
(suggestions welcome :), so adding
user_pref("mail.identity.default.generate_news_message_id", true);
will enable id generation for news accounts and all identities.
bienvenu, sspitzer, could you r= and sr= this patch here?
you want ducarroz to review this, since it's in the message composition/sending
code.
Comment on attachment 78514 [details] [diff] [review]
patch for target- and preference dependent message id generation

> +      // * if and only if the preference is set to true, we do not generate an id

Isn't that comment wrong? Shouldn't it be something like:

If the preference exists and is set to true, we still generate an id.
I'll review tomorrow morning...
keep in sync with the latest source, and corrected a comment (thanks, Aleksey!)
Attachment #78514 - Attachment is obsolete: true
Comment on attachment 84601 [details] [diff] [review]
patch for target- and preference dependent message id generation (updated)

patch looks good but I have 2 requests:

1} Don't need to check for   SendUnsent, please remove that test.
+      ||  ( nsIMsgCompDeliverMode::SendUnsent == m_deliver_mode )	       
// TODO: really necessary?

2) nsMsgComposeAndSend::generateMessageId should start with a uppercase:
GenerateMessageId
complied to Jean-Francois' requests
Attachment #84601 - Attachment is obsolete: true
Comment on attachment 84746 [details] [diff] [review]
yet another update

Good job. R=ducarroz
Attachment #84746 - Flags: review+
what about a gui option in the preferences dialog?

targeting this bug would also be nice....
Comment on attachment 84746 [details] [diff] [review]
yet another update

sr=bienvenu
Attachment #84746 - Flags: superreview+
This adds a checkbox to the settings for the identity associated with an
account.

I admit I tested it some time ago only with some 0.9.8 version, but at least it
could be applied to the 1.0 source :).

I explicitly do *not* see this as patch for this bug here. I think it would
require some discussion about _how_ the UI should finally really look like. I
could even imagine that there should be _no_ UI for this setting at all because
it is way too advanced. Which leads to "it could be in the 'advanced' dialog
for an identity" (which, then, would require some more changes).

I just wanted to share what I once used for this setting ....
I'll take care of check the fix in the trunk... Reassign to myself
Assignee: sspitzer → ducarroz
Status: REOPENED → NEW
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Fix checked in the trunk.
Frank S. can you open a new bug for the UI implementation (even if we will no do
it) else your patch for the UI might get lost...

Thanks
bug 152132 is about the user interface ....
Fix works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020619.

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

Attachment

General

Creator:
Created:
Updated:
Size: