80819 - Mozilla News Client does create Message-Ids

Status: RESOLVED FIXED

(MailNews Core :: Networking: NNTP, defect)

Description

[Franz G. Koehler]

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.

Comment 1

[Håkan Waara]

Confirming...

Comment 2

[(not reading, please use [e-mail] instead)]

I think there's a bug on this already.

Comment 3

[Aleksey Nogin]

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).

Comment 4

[Holger Metzger]

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.

Comment 5

[Holger Metzger]

Isn't this #54540?

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

*** This bug has been marked as a duplicate of 54540 ***

Comment 7

[ffrank]

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

Comment 8

[Andi Heitzer]

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$[e-mail]> in
news:de.comm.software.newsreader

Andi

Comment 9

[Frank Schönheit]

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

Comment 10

[Frank Schönheit]

Attachment: patch for identity-pref-dependent message-id generation

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.

Comment 11

[Franz G. Koehler]

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....

Comment 12

[Frank Schönheit]

Attachment: patch for identity-pref-dependent message-id generation (with context)

same patch, but this time with context information
(like to make 70486 obsolete, bug have no permissions for this ....)

Comment 13

[Frank Schönheit]

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.

Comment 14

[Holger Metzger]

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

Comment 15

[Frank Schönheit]

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 ...

Comment 16

[Aleksey Nogin]

> 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!

Comment 17

[Franz G. Koehler]

> 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 <[e-mail]> .

Comment 18

[Frank Schönheit]

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?

Comment 19

[Holger Metzger]

Frank,

sound good. :-)

- Holger

Comment 20

[Frank Schönheit]

Attachment: patch for target- and preference dependent message id generation

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 :)

Comment 21

[Frank Schönheit]

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.

Comment 22

[Sören 'Chucker' Kuklau (gone)]

Status?

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

bienvenu, sspitzer, could you r= and sr= this patch here?

Comment 24

[David :Bienvenu]

you want ducarroz to review this, since it's in the message composition/sending
code.

Comment 25

[Aleksey Nogin]

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.

Comment 26

[Jean-Francois Ducarroz]

I'll review tomorrow morning...

Comment 27

[Frank Schönheit]

Attachment: patch for target- and preference dependent message id generation (updated)

keep in sync with the latest source, and corrected a comment (thanks, Aleksey!)

Comment 28

[Jean-Francois Ducarroz]

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

Comment 29

[Frank Schönheit]

Attachment: yet another update

complied to Jean-Francois' requests

Comment 30

[Jean-Francois Ducarroz]

Comment on attachment 84746 [details] [diff] [review]
yet another update

Good job. R=ducarroz

Comment 31

[Franz G. Koehler]

what about a gui option in the preferences dialog?

targeting this bug would also be nice....

Comment 32

[David :Bienvenu]

Comment on attachment 84746 [details] [diff] [review]
yet another update

sr=bienvenu

Comment 33

[Frank Schönheit]

Attachment: small UI for disabling/enabling the setting

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 ....

Comment 34

[Jean-Francois Ducarroz]

I'll take care of check the fix in the trunk... Reassign to myself

Comment 35

[Jean-Francois Ducarroz]

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

Comment 36

[Frank Schönheit]

bug 152132 is about the user interface ....

Comment 37

[Boris 'pi' Piwinger]

Fix works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020619.

pi