(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #338623 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=338623 Imported into Bugzilla on 02/04/99 18:07) Additional Details : On our intranet, our preferred email addresses are always of the form "userid@nsa" (which causes mail to get routed through a central "post office" hub). In Communicator, this has to be entered as "userid@nsa." (with a dot at the end) to get around a Communicator restriction of having to have dot in the hostname portion. It's ugly but it works. When posting a news article with the Collabra client, it generates a Message-ID for the article of the form <someidhere@nsa.>, where the hostname portion is taken from the hostname portion of the user's email address. Well, this is a bad idea in our configuration because it causes everone's message-ids to have "nsa." as the hostname portion. This goes against RFC-1036 which I believe says that the hostname portions of Message-IDs should be unique across news servers, and should be a fully-qualified DNS name to ensure this. And this means that there is a much greater chance that two people will post an article with the same message-id generated, resulting in one article getting silently dropped as a duplicate. To fix this problem, my proposal is to simply add a new boolean preference to Communicator that says whether Communicator should generate its own Message-IDs for news postings. (If it doesn't, the news server will simply generate it itself, in the correct format guaranteed to be unique -- problem solved.) Alternatively, if you don't want to add another preference, you could make it not generate the Message-ID header if it looks like the hostname portion is not a FQDN, but there may not be a good heuristic for this (simply checking for period is not enough). Believe this is in all current versions of Communicator on all platforms.

mass-setting to TFV 5.0 all enhancement requests against Communicator 4.5

This claim sounds pretty bogus to me. Brian, can you comment on this? Reassigning to sspitzer for M9, which is pretty close to "later".

This claim sounds pretty bogus to me. Reassigning to sspitzer for M9, which is pretty close to "later". I'll forward this to bhern@netscape.com for feedback.

accepting bug

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

still need to investigate. not going to fix for m10. moving to m15, with other RFEs.

This does not sound like something that needs to be fixed for PR1

Change QA Contact to me since it's my feature now

moving to m17.

Mail Review recommends not in this release. Marking M20.

Seth - should we just close this bug out? I'm just reading through the comments of this bug report.

related to bug #54540

mass change of huang's news bugs to stephend.

marking nsbeta1-

umm.. this bug doesn't look valid. The "userid@nsa" problem nolonger exist. only the RFC-1036 issue I'm not sure of.

This is common BUG of many news programs. News user agents MUST NOT create any messages id for a new article. This is a job of the news server. It's dangerous to create any MessageID with the user agent, because only the news server is able to create a unique ID for the message. Remember that the MessageID has two parts: The unique part and the domain name. The unique part at the left of the @ sign, MUST be unique within that domain. How could you generate a unique ID for a domain, without the knowledge about any other newsreader within the domain? In 0.9.3, you create a MessageID for the complete mail domain. You could only reduce the risk, that no other user agent creates the same ID within 2 years. Note that a mail domain could be very large (e.g. the free mailers like hotmail or GMX). The news server has it's own domain name. It is able to create a unique ID for this domain (e.g. date/time plus the process id of the post process or something else).

Hummm...nsMsgSend.cpp says: PRBool bGenerateMessageId = PR_FALSE; mUserIdentity->GetBoolAttribute( "generate_news_message_id", &bGenerateMessageId ); // Note: if the preference is not found, this defaults to PR_FALSE. As we do not initially write // this pref when deploying Mozilla, this means that by default, no ids are generated for news targets. So why are the message-ids generated? Is something wrong with that code?

See bug 54540 with relevant discussion.

*** Bug 54540 has been marked as a duplicate of this bug. ***

*** Bug 314559 has been marked as a duplicate of this bug. ***

This is also an e-mail issue (see bug 314559). For e-mail, at least, I don't agree at all that the correct approach would be to omit the Message-ID and have it assigned at a later stage during transport. (I'm not sure that's a proper solution for news either, but I want to concentrate on the e-mail situation here.) I believe it's crucial for the e-mail client to generate a Message-ID, because (for example) that's the only way for a file copy (saved by Thunderbird in the "Sent" folder) to be linked to subsequent replies. What I believe should happen is that the right-hand side of the Message-ID ought to be the domain name of the local machine on which Thunderbird is running -- NOT the domain name of the user's e-mail address. That's the only way to ensure that two users, with e-mail addresses in the same domain, who compose messages on two different computers at the same time, don't occasionally end up with the same Message-ID on both messages. I think this would also be a perfectly acceptable solution for news postings.

I agree that would should generate a message-id. But, are some people going to complain when their machine domain name is made public when sending an e-mail?

The message sender's local machine name is likely to get revealed anyway, in the earliest (physically last) "Received:" header line. But if this is considered a major problem, perhaps an acceptable alternative would be to use a one-way hash of the local machine name (plus perhaps other stuff such as the time stamp, user's e-mail address, and anything else lying around), and use that one-way hash as all or part of the left-hand side of the Message-ID. That would, I think, be sufficient to satisfy the requirement to guarantee uniqueness of the Message-ID, even if the right-hand side continues to be the domain from the user's e-mail address.

> the earliest (physically last) "Received:" header line. Some admins make their SMTP server intentionally strip that out to hide that info. I don't see how you can use the machine hostname, given that it's probably invalid or internal for the vast majority of (Windows) users. Highly OS and network specific, some companies use .local etc.. See bug 54540 for some more discussion.

OK, if there's concern that the local host name is likely to be invalid anyway on your average Windows box, then perhaps a better approach is to include the user's FULL e-mail address -- that is, use the left-hand side as well as the right-hand side. That is, for example, if johndoe@somewhere.tld composes a message, include the "johndoe" in the Message-ID, like this: various-weird-stuff.johndoe@somewhere.tld This should create a reasonable guarantee that two Message-ID's, from messages created independently by two people at the same time, won't accidentally match. They could match only if the same user (johndoe in this case) were to compose two messages at the same time. Or, if people are paranoid about a Message-ID containing a complete, recognizable e-mail address that could be harvested by spammers, then the left-hand side of the Message-ID could be a one-way hash of something that included the user name.

Sounds good to me, incl the hash. IIRC was proposed earlier (without major objections), too.

Is this something that could be done in an extension (i.e., intercept the message just before it is sent and replace the Message-ID)? Assuming an extension can do the job, it could have options to customize the Message-ID in whatever way the user might prefer -- e.g., use a specified local domain name, show the date/time stamp (first element of the default Message-ID) in a more readable month-day-year-hour-minute-second form, include the local user name, or even scramble the entire left-hand side via a one-way hash (for those who are worried about spam harvesting).

This doesn't seem to be an issue anymore...? Fixed by bug 80819 perhaps?

That may possibly have been a fix for news, but I do NOT think that it would be a good idea to omit the Message-ID entirely when Thunderbird composes e-mail. My main reason for saying this (see my earlier comment #21, above) is that the only way for a sender's local file copy in his "Sent" folder to have the right Message-ID's for his outgoing e-mail would be if Thunderbird generated the Message-ID's itself at the time the mail was sent out. I'm going to repeat my earlier question in comment #27, since no one ever answered. Is there any way for an extension to intercept a message in Thunderbird just before it's sent and replace the default Message-ID with something else? As best I can tell, the Message-ID is created as the message is being sent. It doesn't appear to be anywhere in the message object during composition (I tried looking for it using DOM-Inspector). Also, the time stamp in the Message-ID definitely corresponds to when the message was sent, NOT to the time when composition was started. If an extension were to insert its own Message-ID line into the header during composition (I'm assuming there's some way to do this), would Thunderbird see that the message already has a Message-ID and refrain from tacking on its own? Or would Thunderbird still go ahead and prepend its own default Message-ID header line anyway?

It turns out that a solution, of sorts, has existed in TB for a long time. See the second comment in bug #178038, which says you can add user_pref("mail.identity.<id>.FQDN", <fqdn>); to the prefs.js file, where <id> is replaced by the appropriate identity, or it can be "default" to override the FQDN for all identities. Example: user_pref("mail.identity.default.FQDN", "blargh.example.tld"); I tried this in TB 1.5.0.10 just now, and it appears to work just fine. You could also add this value in the about:config editor GUI, of course, instead of editing prefs.js by hand.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Trunk no longer produces message IDs on trunk, as verified by fakeserver testing. RESO INVA, therefore. Yay for resolving four-digit bugs!