msgHdr does not include recipients or ccList for news
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
People
(Reporter: TbSync, Unassigned)
Details
A msgHdr returned for news (for example for news from news.mozilla.org) do not include recipients or ccList.
I stumbled upon this, because we use the msgHdr to build up the MessageHeader object for the WebExtension messages API.
As a workaround, I call headers = MimeParser.extractHeaders(rawText)
using experiment API to decode quoted printable or base64 strings in headers. It necessary to convert returned Map
-like object to pass result to extension. In addition I obtain original headers using headers.getRawHeader(h)
to get date in sender's timezone as a bonus.
var { MimeParser } = ChromeUtils.import("resource:///modules/mimeParser.jsm");
Reporter | ||
Comment 2•3 years ago
|
||
That is exactly what I will do in our WebExtension API, but this bug is about the core msgHdr implementation. Any WE API related comments should go into our meta bug 1644027 or a dedicated bug in the WebExtension component (which I will open soon to land the patch).
Reporter | ||
Comment 3•3 years ago
•
|
||
I had a look at nsNNTPProtocol.cpp and nsNNTPNewsgroupList.cpp.
The implementation wants to grab as little data from the news server as possible when a new group has been subscribed or new entries are coming in. The NNTP protocol has a XOVER command which returns information from the servers overview DB about the available news, like subject, date, sender, size, message-id and some xref. This is what TB uses to create the msgHdr, without looking at the individual news.
The protocol does allow to fetch other headers using the XHDR command, which for example could return "To" for all news in a single request. So this would be perfect. However, it is not supported by all servers and thus using this will not fix the issue for all servers.
The only option to fix this consistent is to use the HEAD command to get all headers of all news and extract To and Cc.
If there is no general shift away from the "grab as little data as possible" approach, this is unfixable.
Personally, I think that absence of some headers for news messages is acceptable if it depends on the network protocol. Message header structure could have some flags to allow to determine the reason why some value is unavailable.
Ideally, different strategies could be implemented and chosen depending on capabilities of a particular server.
At least documentation for extensions API should be updated to reflect reality and to form proper expectations.
Comment 5•3 years ago
|
||
Should this be marked confirmed?
Updated•3 years ago
|
Reporter | ||
Comment 6•3 years ago
|
||
As written in Comment 3, this is basically by design. The NNTP protocol has a certain set of (useful) information which it broadcasts for a news folder (one network request/response for all news in a folder). Any additional information has to be requested per news.
After having worked on this for the WebExt API, we reverted a patch which did this additional lookup, because the gain was so minimal. News mostly do not have cc, and the recipient is the list itself. We simply documented this behavior instead of filling the missing information.
It is a strategic decision, if we want this additional info in the header, because all other headers include it, or if we keep it as it is.
By now, I would even go as far as wontfixing this bug.
Updated•3 years ago
|
Description
•