Thunderbird -OT

Char Jackson wrote:

I'm curious, did you subscribe to it on news.individual.net or on
news.mozilla.org? Are the two groups mirrored?

NIN doesn't carry the moz support groups; they are not on 'usenet at large'.

But they /are/ on ugh! GG.

--
Mike Easter

On 11/4/2019 11:09 AM, Char Jackson wrote:
On Sat, 2 Nov 2019 18:11:51 -0700, Ken Blake wrote:

Sorry about the off-topic question, but I don't know where else to ask this.

I'm been trying Thunderbird 68.2.1 as my newsreader, rather than Agent,
which I used to use. I like some things about Thunderbird better than
Agent and some less, so I haven't yet decided which to stick with.

What kinds of issues are you having with Agent? I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.


The main issue, and the reason that I will probably stay with
Thunderbird is that Agent doesn't permit me to see the wide range of
foreign and other special characters that Thunderbird does. I'm active
in alt.usage.english, and there are a lot of such characters in posts there.

There are several other small things that aren't really issues but are
things I prefer about Thunderbird. For example, the authors of posts are
always displayed in the same column, not sometimes in the Author
column and sometimes in the Subject column. On the other hand, there are
also things I prefer about Agent, such as the handling of crossposted
messages. But I think the foreign and other special characters issue is
going to win out.


I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.



Yes, but if I stay with Thunderbird, I'll probably drop it.

--
Ken

On 11/4/2019 9:36 AM, Char Jackson wrote:
On Mon, 04 Nov 2019 09:42:09 -0400, nospam wrote:

In article , Neil
wrote:

I'm not sure how common it is for users to access newsgroups from
multiple servers.

it's extremely common for binary downloads, which is the overwhelming
majority of usenet these days.

Agreed, but even the text-only folks have been migrating to the free NSPs


Interesting. I hadn't realized that binary downloads is the overwhelming
majority of usenet these days.


such as Eternal-September and AEIOU (sp?), and from what I hear, the free
providers are flaky enough that people are configuring both so they'll have
a fallback when the primary goes down.



--
Ken

On 11/4/2019 11:12 AM, Char Jackson wrote:
On Sun, 3 Nov 2019 07:54:50 -0700, Ken Blake wrote:

On 11/3/2019 7:42 AM, Ken Blake wrote:
On 11/2/2019 7:05 PM, VanguardLH wrote:
Ken Blake wrote:

Sorry about the off-topic question, but I don't know where else to ask this.

I'm been trying Thunderbird 68.2.1 as my newsreader, rather than Agent,
which I used to use. I like some things about Thunderbird better than
Agent and some less, so I haven't yet decided which to stick with. But I
have a Thunderbird question:

A cross-posted message is showing up in each folder I open that it's
been cross-posted to. Is it possible to have it appear only once? If so,
what should I change to make that happen.

Thunderbird newsgroup: mozilla.support.thunderbird
Mozilla NNTP server: news.mozilla.org, port 119

OK, I just subscribed to it. My memory of a problem was wrong.

I'm curious, did you subscribe to it on news.individual.net or on
news.mozilla.org? Are the two groups mirrored?


news.mozilla.org. As far as I know, news.individual.net doesn't carry it.

--
Ken

Ken Blake wrote:
There are several other small things that aren't really issues but are
things I prefer about Thunderbird. For example, the authors of posts are
Â*always displayed in the same column, not sometimes in the Author
column and sometimes in the Subject column. On the other hand, there are
also things I prefer about Agent, such as the handling of crossposted
messages. But I think the foreign and other special characters issue is
going to win out.

News clients are a personal type issue. I stuck w/ OE a long time while
propping it up with several 3rd party tools to enable it to almost work
properly.

I like that Tb does format=flowed, which some people have no use for. I
like that it can rewrap, albeit not 'perfectly'; I don't like the issue
of the x-posted msg/s, I don't like that it can't fetch by m-id except
in a limited way, I don't like that it thinks it is an html mail agent.
I don't like that it is weak in filtering, no regex or wildcards or
scoring. But, some of those dislikes don't actually affect me directly.

--
Mike Easter

Char Jackson wrote:

Ken Blake wrote:

I'm been trying Thunderbird 68.2.1 as my newsreader, rather than
Agent, which I used to use. I like some things about Thunderbird
better than Agent and some less, so I haven't yet decided which to
stick with.

What kinds of issues are you having with Agent? I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.

Ken never mentioned which version of Agent he is/was using. If it's a
free version, that is damn old. Isn't 3.3 the latest free version of
Agent? That was released back in 09-Mar-2006. As I recall, it was
distributed as shareware, not freeware, so users were expected to try
and then discard or buy. It's up to version 8.0 now ($29). Agent 8.0
was released way back on 20-Oct-2014 (http://www.forteinc.com/release/)
which was 5 years ago, no improvements since then, and they still want
money for it? I suspect their primary and prevalent revenue comes from
their Usenet service, not their client.

My recollection when I tried the free version (don't know if it was 3.3,
or a 2.x version) was that it poorly handled multiple servers. I think
Agent, back then, only handled one server. The workaround was to make a
copy of some config file. You would have a config file for each server.
You copied the customized config file atop the standard-named config
file before you loaded free Agent. I used a batch file to make the
selection which did the overwrite of the config file and then loaded
Agent. As I recall, back then (don't know about now), it really didn't
have filters. It had searches you could define that acted like filters,
but you had to manually run the saved search.

I might've gone with a payware version of Agent, except there are lots
of free alternatives. The one that I'm using now (40tude Dialog,
abandoned since 2005) that got panned in several trials when I'd get
spurred to trial several alternatives to OE (the OE-QuoteFix just wasn't
enough, nor the registry tweaks afford in WinXP SP-3). Not until I
decided to spend more time defining macros to alter its behavior and
learn more regex to define more focused and accurate rules did I stick
with Dialog.

On 11/4/2019 12:43 PM, VanguardLH wrote:
Char Jackson wrote:

Ken Blake wrote:

I'm been trying Thunderbird 68.2.1 as my newsreader, rather than
Agent, which I used to use. I like some things about Thunderbird
better than Agent and some less, so I haven't yet decided which to
stick with.

What kinds of issues are you having with Agent? I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.

Ken never mentioned which version of Agent he is/was using. If it's a
free version, that is damn old.


6.0. I never went to a newer version because I never saw any advantage
to them.



My recollection when I tried the free version (don't know if it was 3.3,
or a 2.x version) was that it poorly handled multiple servers.


I don't remember which version I started with, but I don't think I ran
3.3. I don't remember ever having a problem with multiple servers.


--
Ken

Char Jackson wrote:

I'm curious, did you subscribe to it on news.individual.net or on
news.mozilla.org? Are the two groups mirrored?

For Mozilla's newsgroups: (1) They are actually primarily a mailing list
(i.e., you use an e-mail client), and why you don't get a fail on
submission and always get a succeed because it doesn't fail until their
NNTP-to-SMTP gateway gets it, but there is no feedback from their mail
server back to their NNTP server; and, (2) They are not peered anywhere
(except to Google Groups which doesn't peer them out from there).

individual.net, eternal-september, albasani, and non-Mozilla NNTP
servers don't carry the mozilla.* newsgroups. Other than the Google
Groups peering, Mozilla operates a "private" (non-peered) newsgroups
service. Like with news.grc.com, company NNTP servers, and other
private newsgroup services, they're private and you have to connect to
that particular NNTP server using their port and may have to register to
get a password for access. Although a private server, Mozilla doesn't
require registration (password) to access their NNTP server. However,
while the Thunderbird newsgroup is non-moderated, Chris Ilias is an
asshole moderator over in the Firefox newsgroup making it nearly
unusable for helpers or inquiry. When I pointed to a web page
delineating the responsibilities for Mozilla moderators, and how Ilias
was violating Mozilla's rules, that web page mysteriously disappeared.
For Firefox, seek help elsewhere. You're okay for asking help there
about Thunderbird.

Char Jackson wrote:
On 4 Nov 2019 14:22:20 GMT, Frank Slootweg wrote:

[big snips ahead, because it's mostly stuff that I agree with and some
other stuff that I'm not addressing in this post]

Apparently TB currently uses the newsrc file only for recording the
subscribed groups, *not* for recording the article numbers of the read
articles in those groups.

See Tools - Account Settings - your News account - 'Server
Settings' - Message Storage - newsrc file: - Browse...

You will see one or more server.rc files with entries like:

alt.comp.os.windows-10:

which means you're subscribed to that group.

A *normal* (non-TB) .newsrc file would have:

alt.comp.os.windows-10: 1-37201,37225,37231,37233-37235

which means I've read all articles with the indicated ranges and
numbers.

I.e. I've *not* (yet) read articles 37202-37224, 37226-37230 and
37232.

Why TB can't be bothered to do this properly is anyone's guess.

Hmmm, that's very interesting. Are you sure that your .newsrc file is
indicating which articles you've read?


hostinfo.dat has the master newsgroup list
blah.blah.rc is the newsrc with the subscribed list, and the
usual notation for read articles.
group.name.msf is the Mork file, which has status bits such
as Read and HasRe. The HasRe bit indicates an article
is a reply, so is stuck in front.

Using the Mork Dumper (written in Python), you can dump the
representation. In this example of a single thread, the Flags
seen are "Read" and "HasRe". I have removed the ends of the
long lines, from "numLines" through "threadParent", so they
don't wrap quite as badly. I think this might be part
of a dump of this group.

namespace,id,children,k,s,threadId,threadNewestMsg Date,threadRoot,unreadChildren
,,,ns:msg:db:table:kind:thread,9,,,,
m,103,1,,,1765,06/17/14 08:10:08,1765,0
----------------------------------------------------------------------
TABLE ns:msg:db:row:scope:msgs:all :: 240F
----------------------------------------------------------------------
namespace,id,date,flags,message-id,msgThreadId,numLines,numRefs,references,sender, size,subject,threadParent
ns:msg:db:row:scope:msgs:all,240F,04/17/18 00:43:33,Read,1buaddl37kffovfk8f6m65spu71jaff5ud@4 ax.com,240f,
ns:msg:db:row:scope:msgs:all,2410,04/17/18 04:07:29,Read ,240f,
ns:msg:db:row:scope:msgs:all,2411,04/17/18 10:47:45,Read ,240f,
ns:msg:db:row:scope:msgs:all,2412,04/17/18 11:04:47,Read ,240f,
ns:msg:db:row:scope:msgs:all,2413,04/17/18 11:43:10,Read ,240f,
ns:msg:db:row:scope:msgs:all,2414,04/17/18 12:00:13,Read ,240f,
ns:msg:db:row:scope:msgs:all,2415,04/17/18 13:40:01,Read ,240f,
ns:msg:db:row:scope:msgs:all,2418,04/18/18 10:58:24,Read ,240f,
----------------------------------------------------------------------
META-TABLE ns:msg:db:row:scope:msgs:all :: 240F
----------------------------------------------------------------------

The file will mention an article more than once, so there is more
information than that in there. I didn't run the dumper at the
time, with that purpose in mind. But that file serves as
the database that stores the headers and relationships
between incoming articles. And it would do so, even when
Thunderbird puts an article in the wrong thread, which it
does sometimes (when users, on purpose, destroy the linking
information).

In terms of "quality of implementation", I tried the Seamonkey
version of that code, and it is just plain terrible. It hasn't
been touched in years, that code.

The Thunderbird code did receive some work, because it isn't
a total shower when adding new servers. New server entries
do not half-overwrite old server entries, like on Seamonkey!!!

Another implementation would be Eudora OSE, which was a fork
of TBird that was abandoned later (presumably because Mozilla
didn't invest effort in improving it). You'd need to test that,
to see which code it's closer to.

Netscape Communicator should have that code too, and that
version might be closer to the Seamonkey version of the code.
Again, test it and see. You can still install Netscape, and then
run it just for the Newsgroup code if you want. And see if it's
the same horrible mess as the Seamonkey one.

While the Thunderbird code isn't "wonderful", it appears to
have had some bugfixes. I don't know if the "posting to multiple
servers" bug has been fixed or not - that's not a bug. It's
an actual architecture problem. And when I researched it, I
could not figure out what they were thinking when they did it.

If you see the complaint about "multiple servers" when you
try to post, change each Newsgroup line in the post, this way.

alt.computer.os.windows-10

news.eternal-september.org/alt.computer.os.windows-10

When the article is posted to your server, the "news.eternal-september.org/"
portion is removed by the Thunderbird code, while it parses your posting.
The posting then looks "normal" when you see it, incoming.

You can tell Thunderbird, on an apparent per-newsgroup basis,
which server to use. Even though it's a crosspost! By adding
the server you intend to use, in front of *every* newsgroup
name, your message is sent to the correct server. Even though
at the top of the message, the server you were sending it to
is in plain sight, and only an idiot would not figure that
out. That's why I don't understand their logic on this "bug".
It's not a code "oopsey", it's just dumb.

Paul

Ken Blake wrote:
On 11/4/2019 9:36 AM, Char Jackson wrote:
On Mon, 04 Nov 2019 09:42:09 -0400, nospam wrote:

In article , Neil
wrote:

I'm not sure how common it is for users to access newsgroups from
multiple servers.

it's extremely common for binary downloads, which is the overwhelming
majority of usenet these days.

Agreed, but even the text-only folks have been migrating to the free NSPs


Interesting. I hadn't realized that binary downloads is the overwhelming
majority of usenet these days.

On a bandwidth basis, a definite "Yes".

The binary groups that are not on your server, there are people
running downloads at full rate, all day long.

My ISP has a cap on bandwidth. I think my plan was 400GB per month.
But, between the hours of 2AM and 7AM, bandwidth is "free".

Well, one dude using my ISP, has automation set up to download
movies. He runs his link full rate, all month long, 2AM to 7AM,
downloading USENET binaries. He was bragging he got 1TB that way
in a single month, significantly exceeding his "daytime" 400GB allotment.
If he wanted then, he could have a total of 1.4TB of movie files
per month.

These are the kinds of people that are competing with your
paltry few text downloads :-)

They use bandwidth by the metric ton. They also pay a significant
amount to the NSP, to allow this. The monthly bill will be
X for the ISP, and ~3X for the NSP.

There is also a dude, who appears to have a fairly high end
fiber optic cable, who uploads 1TB of movies per day to USENET.
And he's doing it, because a DMCA bot issues takedowns at max
rate, to try and stop him. And this goes on, on commercial
binary servers, a safe distance from your text posting.

Think of this activity, as a "continuous dumpster fire you
cannot see" :-) While I'm not interested in the details,
I think some of this stuff is quite funny.

For Hollywood, from their perspective, they'll be trying
to figure out how they can "break the business model" of
the commercial binary servers. Cuomo played his part in
N.A. , but binary servers still run elsewhere. The servers
may not be big in number, but the implementation must
be huge on these things. If you believe their retention
figures. The biggest one would be competing with archive.org
for disk drives. I've never seen any statistics to back this up,
as to exactly how big all the servers together are. Or how
it's possible to store and organize bulk postings like this.
It's not likely to be a standard copy of INN.

Paul

Char Jackson wrote:
On 4 Nov 2019 14:22:20 GMT, Frank Slootweg wrote:

[big snips ahead, because it's mostly stuff that I agree with and some
other stuff that I'm not addressing in this post]

Apparently TB currently uses the newsrc file only for recording the
subscribed groups, *not* for recording the article numbers of the read
articles in those groups.

See Tools - Account Settings - your News account - 'Server
Settings' - Message Storage - newsrc file: - Browse...

You will see one or more server.rc files with entries like:

alt.comp.os.windows-10:

which means you're subscribed to that group.

A *normal* (non-TB) .newsrc file would have:

alt.comp.os.windows-10: 1-37201,37225,37231,37233-37235

which means I've read all articles with the indicated ranges and
numbers.

I.e. I've *not* (yet) read articles 37202-37224, 37226-37230 and
37232.

Why TB can't be bothered to do this properly is anyone's guess.

Hmmm, that's very interesting. Are you sure that your .newsrc file is
indicating which articles you've read?

Yes. It's what a .newsrc file is supposed to do. It's easy to
see/prove by not reading a few articles (or (re-)marking them as
unread), the unread status will be reflected in the .newsrc file.

But don't take my word for it! :-) This is what the tin(5) manual page
of my newsreader (tin) says about it:

quote

${TIN_HOMEDIR:-"$HOME"}/.newsrc

"newsgroupflag [article[,article | -article]...]" lines.

newsgroup
the name of the newsgroup.

flag a flag indicating if the group is subscribed ':' or not
'!'.

article
range of already read articles from that group; numbers
separated by commas with sequential numbers collapsed
with hyphens.

Example:
# sample .newsrc file
# news.software.b! 1-666,669
# news.software.nntp: 1-13245,13247,13249
# news.software.readers: 1-19567,19571-19597

/quote

Note "a flag indicating if the group is subscribed or not", *not* if
the group is available or not.

And the most important: "range of already read articles".

My experience is limited to Agent, which has always touted itself as being
fully compliant with standards, (and why wouldn't they), but with Agent the
.newsrc file only tells me a few things.

1. Contains a list of all available newsgroups available at this server,
one newsgroup per line, ending with a blank line to indicate EOF. My
current server, Newshosting, carried 110,673 groups as of my last refresh,
so my .newsrc file for this server is 110,674 lines long.

That's uncommon, but allowed use, if - as you mention - the
unsubscribed groups are marked by 'groupname!'.

Most old-style newsreaders use another file for the list of
*available* (i.e. not neccessarily subscribed) groups. *If* they need
such a file that is, because the list is readily available from the News
server. Common file names are 'active' (includes low and high water
marks) and 'newsgroups'. (IIRC, Agent is a (partly) offline newsreader,
so to be able to function offline, it might well use a file for this
information than to depend on the News server. (My Hamster server, which
offers offline capability to any newsreader, obviously has local
'active'/'newsgroups' files.))

2. Shows me which groups are currently subscribed (: versus !)
Subscribed groups are moved to the top of the list.

':' versus '!' is indeed standard use. The list may be ordered in any
way, so putting subscribed groups at the top is allowed. My .newsrc is
ordered the way I want my newsreader to list the groups (containing
unread articles).

3. For any group for which I've ever retrieved headers, (whether currently
subscribed or previously subscribed), it tells me the server-specific
article numbers that have been retrieved, shortening the list to a range
(x-y) when possible, otherwise using a comma separated list.

As explained, standard .newsrc usage shows articles *read* (and hence
retrieved), *not* (just) retrieved.

Coming to think of it, *when* does your newsreader mark/consider an
article as read? Doesn't the fact that there can be a comma separated
list in your .newsrc file mean that you *did* read those articles? Why
would your newsreader retrieve those articles, if you weren't reading
them?

That's all, nothing else. No Message IDs, no read/unread status. No
additional fields of any kind.

Does your .newsrc tell you more than that?

As I explained, not more, but different, i.e. read versus (only)
retrieved.

If so, the whole notion of
sharing a common .newsrc file across multiple newsreaders is in jeopardy.
Not that I share a common .newsrc, but I always assumed that I could.
That's essentially why it was created, after all.

*If* your newsreader is indeed recording (only) retrieved status, not
(also) read status, then it can indeed not be shared (assuming
cross-reader read status).

One .newsrc file for all the groups subscribed on a particular
News server.

For all of the groups that are available at that server, not just the
groups that are subscribed.

See above. Standard is subcribed (and no longer subscribed). All
available unsubscribed groups is uncommon - but allowed - use.

A .newsrc file only records *ranges* of article numbers, with the
occasional not-yet-read article numbers.

I would change "not-yet-read" to "not-yet-retrieved".

You would be wrong! :-) See above.

There is no requirement that news servers create and assign article numbers
in sequential order. They usually and normally do, but Easynews (for
example) used to be notorious for creating articles out of order. Agent,
and I presume other newsreaders, has the capability to deal with that
through a configuration setting.

If article numbers are all over the place, .newsrc entries could
become rather fragmented/long, but everything should keep working.
AFAIK, the RFCs cover this behaviour/aspect.

In Agent, for each configured server, you get an opportunity to declare
that this "Server creates messages out of order." By checking the box,
you're telling Agent not to assume that the highest article number means
that everything before that has been retrieved.

There's also an edge case that a certain Dutch dump group presented quite a
few years back. That group got so much traffic that news servers were
forced to roll over the article numbers, starting again at the beginning.
Newsreaders were generally unprepared for that and marked everything as
retrieved, thus making tons of posts 'disappear'. The Easynews support
group was awash with support requests when that happened. Folks who had
configured their newsreaders to expect article numbers to be retrieved out
of order didn't suffer when the article numbers rolled over. Everyone else
did. (Full recovery was always possible, of course.)

Yes, article number rollover is a problem and should be prevented.
It's an issue which is unlikely to be ever solved/fixed ("Can't fix old
clients.")

A typical entry/line is well less than 80 characters. *Some* entries/
lines might be a few hundred characters long, during the time you have
not yet completely 'catched up' with the group.

For example, my .newsrc file is 2574 bytes, 94 lines, i.e. a little
over *27* characters per entry (including LF).

As a second data point to reinforce your position, my Newshosting .newsrc
file is currently 3,008,221 bytes, 110,674 lines (one line per group plus a
trailing blank line to show end-of-file). The longest line is 14,211
columns, but the second longest is just 85 columns and every line after
that is less than 45 columns. All in all, this would be extremely easy to
parse, if desired.

Believe me, the structure, 'size', 'slowness', etc. of a .newsrc file
is a complete non-issue. It wasn't an issue on 640KB machines and it
surely isn't now.

I totally agree.

If a newsreader can handle getting articles from multiple News
servers, then there's a .newsrc file per server. Handling multiple
servers is of course more complex, but several newsreaders handle this
functionality in a seamless way. (AFAICT, TB can handle multiple News
servers, but without any integration, i.e. if you're subscribed to the
same newsgroup on multiple servers, you'll see each article multiple
times.)

That's why Agent uses a separate database for its Crosspost Management
function. The .newsrc file(s) aren't suitable substitutes since they:
1. Don't show read status.
2. Don't include Message IDs.
3. Only show server-specific article numbers.

The newsreader would have no way of knowing that article X on server A is
the same as article Y on server B if all it had to go on is the article
number. So .newsrc file(s) are useless for crosspost management.

Yes, for multi-server newsreaders. As I've shown, for single-server
newsreaders they're fine (but don't offer the *addtional* 'Crosspost
Management' features which Agent offers).

I don not know if there are any newsreaders which are multi-server
*and* use (multiple) .newsrc files for read status of cross-posted
articles. So we know that Agent doesn't do it that way, but we don't
know that it can't be done that way.

FWIW, I use a local,'small', 'personal', News server (Hamster) to -
amongst others - get the same - multi-server - functionality. Hamster
sits between my newsreader (tin) and my NSP (News SP),
News.Individual.[DE|.NET]. To my NSP, Hamster looks like a newsreader.
To my newsreader, Hamster looks like a News server.

That's good to hear. I used to hear a lot of Hamster stories in the early
2000's, but not so much anymore. Same with Stunnel stories. I used Stunnel
for a period of time, but never Hamster. I'm familiar with it, though.

Before retirement, I ran News servers in our tiny 150K employee
company. So I always had access to 'my' own News server. So after
retirement (in 2003), I wanted to have similar functionality/speed.
Enter Hamster and I never looked back! :-)

On Mon, 4 Nov 2019 01:25:01 -0500, Neil wrote:

On 11/3/2019 3:46 PM, Char Jackson wrote:
[...]

The xref header wouldn't be a good choice because it's server specific.
It's not that unusual to have multiple servers defined, which would likely
break crosspost checking.

I'm not sure how common it is for users to access newsgroups from
multiple servers.

I think it's common, but YMMV.

In all the years that I used Outlook Express, which had the ability to mark
cross-posts as read, it never failed to do so correctly

That's good to hear. I've always had an incredibly low appreciation for
Outlook Express, both as an email client and a Usenet client, so I'm happy
to hear that it got that part right.

because I don't use multiple servers.

I'm not sure it had anything to do with that.

However, providing the option to turn off cross-post checking could satisfy
both types of users.

To the user, the decision to use crosspost management and the decision to
use multiple servers should be independent of one another.

On 11/4/2019 4:22 PM, Char Jackson wrote:
On Mon, 4 Nov 2019 01:25:01 -0500, Neil wrote:

On 11/3/2019 3:46 PM, Char Jackson wrote:
[...]

The xref header wouldn't be a good choice because it's server specific.
It's not that unusual to have multiple servers defined, which would likely
break crosspost checking.

I'm not sure how common it is for users to access newsgroups from
multiple servers.

I think it's common, but YMMV.

In all the years that I used Outlook Express, which had the ability to mark
cross-posts as read, it never failed to do so correctly

That's good to hear. I've always had an incredibly low appreciation for
Outlook Express, both as an email client and a Usenet client, so I'm happy
to hear that it got that part right.

It just goes to show that it isn't a terribly complicated task... ;-)

because I don't use multiple servers.

I'm not sure it had anything to do with that.

However, providing the option to turn off cross-post checking could satisfy
both types of users.

To the user, the decision to use crosspost management and the decision to
use multiple servers should be independent of one another.

It's easy to understand why cross-post management could be problematic
if multiple servers are used. The xref message numbering could be
irrelevant because the numbering is generated by the server. Different
servers -- different numbering.

--
best regards,

Neil

Earlier, I wrote:
Char Jackson wrote:
On 4 Nov 2019 14:22:20 GMT, Frank Slootweg wrote:

[big snips ahead, because it's mostly stuff that I agree with and some
other stuff that I'm not addressing in this post]

Apparently TB currently uses the newsrc file only for recording the
subscribed groups, *not* for recording the article numbers of the read
articles in those groups.

See Tools - Account Settings - your News account - 'Server
Settings' - Message Storage - newsrc file: - Browse...

You will see one or more server.rc files with entries like:

alt.comp.os.windows-10:

which means you're subscribed to that group.

A *normal* (non-TB) .newsrc file would have:

alt.comp.os.windows-10: 1-37201,37225,37231,37233-37235

which means I've read all articles with the indicated ranges and
numbers.

I.e. I've *not* (yet) read articles 37202-37224, 37226-37230 and
37232.

Why TB can't be bothered to do this properly is anyone's guess.

Hmmm, that's very interesting. Are you sure that your .newsrc file is
indicating which articles you've read?

Yes. It's what a .newsrc file is supposed to do. It's easy to
see/prove by not reading a few articles (or (re-)marking them as
unread), the unread status will be reflected in the .newsrc file.

But don't take my word for it! :-) This is what the tin(5) manual page
of my newsreader (tin) says about it:

quote

${TIN_HOMEDIR:-"$HOME"}/.newsrc

"newsgroupflag [article[,article | -article]...]" lines.

newsgroup
the name of the newsgroup.

flag a flag indicating if the group is subscribed ':' or not
'!'.

article
range of already read articles from that group; numbers
separated by commas with sequential numbers collapsed
with hyphens.

Example:
# sample .newsrc file
# news.software.b! 1-666,669
# news.software.nntp: 1-13245,13247,13249
# news.software.readers: 1-19567,19571-19597

/quote

Note "a flag indicating if the group is subscribed or not", *not* if
the group is available or not.

And the most important: "range of already read articles".

My experience is limited to Agent, which has always touted itself as being
fully compliant with standards, (and why wouldn't they), but with Agent the
.newsrc file only tells me a few things.

1. Contains a list of all available newsgroups available at this server,
one newsgroup per line, ending with a blank line to indicate EOF. My
current server, Newshosting, carried 110,673 groups as of my last refresh,
so my .newsrc file for this server is 110,674 lines long.

That's uncommon, but allowed use, if - as you mention - the
unsubscribed groups are marked by 'groupname!'.

Most old-style newsreaders use another file for the list of
*available* (i.e. not neccessarily subscribed) groups. *If* they need
such a file that is, because the list is readily available from the News
server. Common file names are 'active' (includes low and high water
marks) and 'newsgroups'. (IIRC, Agent is a (partly) offline newsreader,
so to be able to function offline, it might well use a file for this
information than to depend on the News server. (My Hamster server, which
offers offline capability to any newsreader, obviously has local
'active'/'newsgroups' files.))

2. Shows me which groups are currently subscribed (: versus !)
Subscribed groups are moved to the top of the list.

':' versus '!' is indeed standard use. The list may be ordered in any
way, so putting subscribed groups at the top is allowed. My .newsrc is
ordered the way I want my newsreader to list the groups (containing
unread articles).

3. For any group for which I've ever retrieved headers, (whether currently
subscribed or previously subscribed), it tells me the server-specific
article numbers that have been retrieved, shortening the list to a range
(x-y) when possible, otherwise using a comma separated list.

As explained, standard .newsrc usage shows articles *read* (and hence
retrieved), *not* (just) retrieved.

Sigh! It finally hit me! The difference in handling - marking read
versus marking retrieved - is very likely not 'The Standard (TM)' versus
Agent, but an online reader (mine, tin) versus an offline reader (yours,
Agent).

An online reader only retrieves an article if the user - implicitly or
explicitly - requests it. After displaying the article and moving to
next one, the previous article is gone. so there's no concept of a 'has
been retrieved' status. So an online newsreader only records 'has been
read' status in the .newsrc file.

An offline newsreader retrieves articles and keeps them for some time.
So for an offline newsreader, there *is* a concept of a 'has been
retrieved' status. *And* - like an online newsreader - it has/
should_have a 'has been read' status.

So an online newsreader only records 'has been read' status and an
offline newsreader records both 'has been retrieved' status and 'has
been read' status.

To be compatible with 'standard' newsreaders, Agent should record 'has
been read' status in its .newsrc file and hence should record 'has been
retrieved' status in some other way/file.

If Agent is doing what you say it's doing - recording 'has been
retrieved' status in its .newsrc file - it's doing it incorrectly, i.e.
in a non-standard/incompatible way.

I hope this clears up most of the confusion (without creating/adding
any new).

[Rest of mostly moot stuff deleted.]

On Mon, 4 Nov 2019 11:50:05 -0700, Ken Blake wrote:

On 11/4/2019 11:09 AM, Char Jackson wrote:
On Sat, 2 Nov 2019 18:11:51 -0700, Ken Blake wrote:

Sorry about the off-topic question, but I don't know where else to ask this.

I'm been trying Thunderbird 68.2.1 as my newsreader, rather than Agent,
which I used to use. I like some things about Thunderbird better than
Agent and some less, so I haven't yet decided which to stick with.

What kinds of issues are you having with Agent? I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.


The main issue, and the reason that I will probably stay with
Thunderbird is that Agent doesn't permit me to see the wide range of
foreign and other special characters that Thunderbird does. I'm active
in alt.usage.english, and there are a lot of such characters in posts there.

There are several other small things that aren't really issues but are
things I prefer about Thunderbird. For example, the authors of posts are
always displayed in the same column, not sometimes in the Author
column and sometimes in the Subject column. On the other hand, there are
also things I prefer about Agent, such as the handling of crossposted
messages. But I think the foreign and other special characters issue is
going to win out.


I was going to suggest
posting in alt.usenet.offline-reader.forte-agent but I see that you're
already active over there.



Yes, but if I stay with Thunderbird, I'll probably drop it.

Ok, thanks. Good luck, whichever way you go.