With both enabled, Thunderbird seems to quote better: no NBSP crap, no extra spaces in quoted Origins or other lines with leading spaces...
--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)
--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)
While the spaces aren't added in TB, they still seem to be added with slrn.
Please check your smapi/jamnntpd console log to see if "Content-Type:
... format=flowed" appears in the header when posting a message with slrn.
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)
TB still seems to add an extra space while quoting the origin line, but that's probably a TB issue. You've done about all you can with the new options added.
Please check your smapi/jamnntpd console log to see if "Content-Type:
... format=flowed" appears in the header when posting a message with slrn.
Good call. It doesn't. So while slrn and tin most likely don't support format=flowed, smapi/jamnntpd does a good job of covering it up with the def_flowed option. :)
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)
TB still seems to add an extra space while quoting the origin line, but
that's probably a TB issue. You've done about all you can with the new
options added.
HAH, nevermind. The space was removed after smapinntpd got ahold of it, slapped it around a bit, and set it straight. :)
With newsreaders that don't support format=flowed it may be better to
log in with parameter /flowed=off
Alternatively, you could set 'def_flowed off' in your server config, but then Thunderbird & Seamonkey users would have to login with /flowed=on
(if they want format=flowed)
That's just the way it works, it seems. If there are any other clients that support format=flowed it would be interesting to check if they do
the same.
HAH, nevermind. The space was removed after smapinntpd got ahold of it,
slapped it around a bit, and set it straight. :)
Nice to see it's working.
- def_delssq (user parameter delssq) for deleting stuffed space from quoted text (only in format=flowed).
With newsreaders that don't support format=flowed it may be better to
log in with parameter /flowed=off
Better how? If the only thing wrong is a space before the origin line, I'm not
to worried about it. At least now I know WHY it's doing it.
Alternatively, you could set 'def_flowed off' in your server config, but
then Thunderbird & Seamonkey users would have to login with /flowed=on
(if they want format=flowed)
Users? The only user besides me here is Tommi, and usually only for testing
purposes. He can log in however he wants. :)
After taking another look at the RFCs, I believe this is the correct approach.
I'm considering removing this experimental setting and always delete stuffed space from quotes, or at least make it on by default. Thoughts?
Better how? If the only thing wrong is a space before the origin line, I'm not
too worried about it. At least now I know WHY it's doing it.
Not only the Origin line, but any line that begins with one or more spaces.
Users? The only user besides me here is Tommi, and usually only for testing
purposes. He can log in however he wants. :)
I mean potential users...
I'm the only user here, too (for now) :-)
After taking another look at the RFCs, I believe this is the
correct approach.
I'm considering removing this experimental setting and always
delete stuffed space from quotes, or at least make it on by
default. Thoughts?
I think the option to toggle is still a good idea for people that
aren't using clients that this is affected by.
It took upwards of 20 years for us (or anyone, for that matter) to
find and report this.
Not only the Origin line, but any line that begins with one or
more spaces.
I only see it now in slrn. I don't see it in tin at all. I don't think either of them actually support format=flowed. So I think if someone
has an issue, they can easily DISable it.
For now, I'm setting 'def_delssq' to 'on' by default in my JamNNTPd
fork. (I suggest you do the same in yours.)
I haven't used tin, but I've checked its source code and it seems it
DOES support format=flowed, at least for reading.
- def_delssq (user parameter delssq) for deleting stuffed space from quoted text (only in format=flowed).
After taking another look at the RFCs, I believe this is the correct approach.
I'm considering removing this experimental setting and always delete
stuffed space from quotes, or at least make it on by default. Thoughts?
Users? The only user besides me here is Tommi, and usually only for testing purposes. He can log in however he wants. :)
I haven't used tin, but I've checked its source code and it seems it
DOES support format=flowed, at least for reading.
Hmm. I guess I haven't really seen it this way. I haven't been able to
get unquoted lines to be full width of the screen I'm using, even with
the "wrap_column 0" option used (which is supposed to wrap at the end of the screen).
I can definitely see differences between tin and slrn though, that would suggest it supported it, at least somewhat.
I can definitely see differences between tin and slrn though, that would
suggest it supported it, at least somewhat.
Maybe it has partial support. At least it displays f=f messages without extra spaces. That's nice, you don't need to set flowed=off.
Hello Carlos,
On Sat, Apr 13 2024 07:19:36 -0500, you wrote:
I can definitely see differences between tin and slrn though, that would
suggest it supported it, at least somewhat.
Maybe it has partial support. At least it displays f=f messages withoutI have no idea. But I've contacted support to ask for specifics on that option, so we will see if I can get any help on the matter. It's definitely one of the better text-based newsreaders on Linux that I could find.
extra spaces. That's nice, you don't need to set flowed=off.
Regards,
Nick
... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.4-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
Hotdoged still doesn't seem to support flowed... :(
Hello Tommi,
On Sat, Apr 13 2024 16:22:26 -0500, you wrote:
Hotdoged still doesn't seem to support flowed... :(Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?
Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?
This has been abandonware for some years..
http://pics.rsh.ru/img/Screens6394_s3outx1p.jpg
Hotdoged still doesn't seem to support flowed... :(
Hello Tommi,
On Sat, Apr 13 2024 17:39:14 -0500, you wrote:
Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?
This has been abandonware for some years..I understand f=f isn't supported, but does it look any better if you
http://pics.rsh.ru/img/Screens6394_s3outx1p.jpg
turn the phone horizontal?
Hello, Tommi Koivula.
On 13/4/24 18:22 you wrote:
Hotdoged still doesn't seem to support flowed... :(HotdogEd, like many newsreaders, does not support format=flowed.
--- HotdogEd/2.13.5 (Android; Google Android; rv:1) Hotdoged/1694692242000 Hotd
* Origin: cyberiada-NNTP (2:341/234.99)
HotdogEd, like many newsreaders, does not support format=flowed.Which is actually quite funny, because as a ftn reader it works
fine. :)
Is that some kind of phone/tablet app?
Hello, Tommi Koivula.
On 13/4/24 21:35 you wrote:
HotdogEd, like many newsreaders, does not support format=flowed.
Which is actually quite funny, because as a ftn reader it worksIn FTN, a paragraph is just a long line.
fine. :)
In format=flowed, a paragraph is formed by several soft-wrapped lines (except the last one). A trailing space indicates that it has been wrapped.
It would be nice to see jamnntpd to support hotdoged by not to wrap
lines :)
So we need to add user option /nowrap to allow long lines?
Yes, but that was not the point. :)
It would be nice to see jamnntpd to support hotdoged by not to wrap
lines :)
Yes, for HotdogEd or any newsreader showing less than 72 chars per line.
So we need to add user option /nowrap to allow long lines?
Will do. ;-)
TK>> It would be nice to see jamnntpd to support hotdoged by not
TK>> to wrap lines :)
CN> Yes, for HotdogEd or any newsreader showing less than 72
CN> chars per line.
TK>> So we need to add user option /nowrap to allow long lines?
CN> Will do. ;-)
Not sure I'm understanding this correctly.
Wouldn't '/nowrap' just be 'flowed=on', which would then leave the formatting to HotdogEd, which doesn't seem to be doing so properly?
Or are you looking for some kind of option for HotdogEd users to be
able set some kind of forced wrapping for it's own display?
Not sure I'm understanding this correctly.
Wouldn't '/nowrap' just be 'flowed=on', which would then leave the formatting to HotdogEd, which doesn't seem to be doing so properly?
If I get it right, with 'flowed=on' jamnntpd will always wrap the long lines, but adding a space to the end of the wrapped line.
My idea was to allow sending the long line from fidonet unwrapped so
that the news client would wrap it. Just like ftn editors do.
I dont know how it would work. :)
Wouldn't '/nowrap' just be 'flowed=on', which would then leave the
formatting to HotdogEd, which doesn't seem to be doing so properly?
HotdogEd (like may other newsreaders) doesn't support format=flowed, so
it doesn't join the wrapped lines with trailing space.
Here's an example. This is a normal paragraph, a long line with a CR+LF (NNTP) or CR (FTN) at the end:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
The same paragraph but with format=flowed (wrapped at 40 instead of the usual 72):
Lorem ipsum dolor sit amet, consectetur[SP]
adipiscing elit, sed do eiusmod tempor[SP]
incididunt ut labore et dolore magna[SP]
aliqua. Ut enim ad minim veniam, quis[SP]
nostrud exercitation ullamco laboris[SP]
nisi ut aliquip ex ea commodo consequat.
[SP] is a regular space (ASCII 32)
If I get it right, with 'flowed=on' jamnntpd will always wrap the long lines, but adding a space to the end of the wrapped line.
My idea was to allow sending the long line from fidonet unwrapped so
that the news client would wrap it. Just like ftn editors do.
It works (in fact, other NNTP servers do that), but there are issues
with some newsreaders, e.g. Thunderbird. A quoted paragraph is not wrapped, so it becomes a long line prefixed by just one ">". This
doesn't work well with all FTN/BBS software. (See my "long line test" thread in FIDOTEST.)
TK> If I get it right, with 'flowed=on' jamnntpd will always wrap
TK> the long lines, but adding a space to the end of the wrapped
TK> line.
Exactly.
TK> My idea was to allow sending the long line from fidonet
TK> unwrapped so that the news client would wrap it. Just like
TK> ftn editors do.
If you want to experiment, you can get a similar result if you set WRAP_WIDTH to 997. Only paragraphs longer than that will be wrapped.
It works (in fact, other NNTP servers do that), but there are
issues with some newsreaders, e.g. Thunderbird. A quoted paragraph
is not wrapped, so it becomes a long line prefixed by just one ">".
This doesn't work well with all FTN/BBS software. (See my "long
line test" thread in FIDOTEST.)
It works (in fact, other NNTP servers do that), but there are issuesIn thi case selecting the quoted text and pressing Ctrl-R in Thunderbird might help.
with some newsreaders, e.g. Thunderbird. A quoted paragraph is not wrapped, so it becomes a long line prefixed by just one ">". This
doesn't work well with all FTN/BBS software. (See my "long line
test" thread in FIDOTEST.)
So, if HotdogEd doesn't support format=flowed, wouldn't it be better to use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79 columns set by jam/smapinntpd, which then HotdogEd would still wrap the text early because it doesn't have that many columns on the screen?
On 20.04.2024 16:52, Nicholas Boel wrote:
So, if HotdogEd doesn't support format=flowed, wouldn't it be better toIn my phone screen the width is about 58 characters. So it wraps first at 58, then at 79. :(
use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap the
text early because it doesn't have that many columns on the screen?
The weird thing is that using a "real" nntp server this is not happening...
'Tommi
---
* Origin: smapinntpd/lnx (2:221/1.0)
On 20.04.2024 16:52, Nicholas Boel wrote:
So, if HotdogEd doesn't support format=flowed, wouldn't it be better toIn my phone screen the width is about 58 characters. So it wraps first
use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap the
text early because it doesn't have that many columns on the screen?
at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not happening...
'Tommi
---
* Origin: smapinntpd/lnx (2:221/1.0)
In my phone screen the width is about 58 characters. So it wraps first
at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not happening...
So, if HotdogEd doesn't support format=flowed, wouldn't it be
better to use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still
wrap the text early because it doesn't have that many columns on the
screen?
In my phone screen the width is about 58 characters. So it wraps
first at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not
happening...
Quote test hotdoged WendzelNNTPd.
Just wondering if HotdogEd is defaulted to wrapping at 79 characters,
but on a phone turned vertical you don't actually have that many characters. Have you tried HotdogEd on a tablet or something with a
bigger screen?
Hello Tommi,
On Sun, 21 Apr 2024 12:57:30 +0300, you wrote:
In my phone screen the width is about 58 characters. So it wraps first
at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not
happening...
If you look at the code for the "real" nntp server, can you make anything out
of it in regards to differences in wrap settings (or if there is none at all)?
If you look at the code for the "real" nntp server, can you makeanything out
of it in regards to differences in wrap settings (or if there isnone at all)?
I compiled wendzelnntpd, but I haven't read the code, yet.
--- GoldED+/LNX 1.1.5-b20240309
On Sun, Apr 21 2024 17:16:10 -0500, you wrote:
If you look at the code for the "real" nntp server, can you make
anything out
of it in regards to differences in wrap settings (or if there is
none at all)?
I compiled wendzelnntpd, but I haven't read the code, yet.
If you notice above, even Golded seems to quote longer than 80 character lines not so well. But since Golded displays them long as well, you
don't really notice it. This seems to be exactly what jam/smapinntpd
does also, and probably has to do with format=flowed text.
--- GoldED+/LNX 1.1.5-b20240309
Just wondering if HotdogEd is defaulted to wrapping at 79 characters,
but on a phone turned vertical you don't actually have that many
characters. Have you tried HotdogEd on a tablet or something with a
bigger screen?
Here I resized the window to under 80 characters. Notice the newly
written text is still flowed to fit the screen, however the quoted text looks much like your HotdogEd screenshots. Quoted text beginning with
any kind of quote character (including initials) can not be reflowed without actually removing the quote characters first. I don't think jam/smapinntpd does this.
Is it only quoted text that looks bad in HotdogEd?
Does newly written text display flowed to the size of the screen in HotdogEd?
Golded is smart. Hotdoged is pretty stupid with quotes. ;)
Anyways, it is always up to the author of the message how to format his/her message.
If you want to experiment, you can get a similar result if you set
WRAP_WIDTH to 997. Only paragraphs longer than that will be
wrapped.
This is exactly what I did once in the past. :) The combination of WRAP_WIDTH 997 and FLOWED OFF was a pretty good choice.
It works (in fact, other NNTP servers do that), but there are
issues with some newsreaders, e.g. Thunderbird. A quoted paragraph
is not wrapped, so it becomes a long line prefixed by just one
">". This doesn't work well with all FTN/BBS software. (See my
"long line test" thread in FIDOTEST.)
Yes. It needs a little manual works.
Wouldn't '/nowrap' just be 'flowed=on', which would then leave
the formatting to HotdogEd, which doesn't seem to be doing so
properly?
HotdogEd (like may other newsreaders) doesn't support
format=flowed, so it doesn't join the wrapped lines with trailing
space.
So, if HotdogEd doesn't support format=flowed, wouldn't it be better
to use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79 columns set by jam/smapinntpd, which then HotdogEd would still wrap
the text early because it doesn't have that many columns on the
screen?
Both of these look fine on Thunderbird (with flowed=on), as well as
tin (with flowed on and off), and slrn (with flowed on), and I'm still unsure format=flowed is supported in either of the last two mentioned.
Maybe tin and slrn can deal with incoming format=flowed, but just
don't post that way..?
So is it a HotdogEd problem that you're looking to come up with a work around for, specifically?
If you notice above, even Golded seems to quote longer than 80
character lines not so well.
If you notice above, even Golded seems to quote longer than 80
character lines not so well.
Looks like Tommi has set QUOTEMARGIN to 80-something in his GoldEd config...
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap
the text early because it doesn't have that many columns on the
screen?
Yes, but it does the same with both flowed off and on (format=flowed and format=fixed look almost identical on readers that don't support f=f).
If you use it in horizontal view, or on a larger screen like a tablet,
it looks better.
I think we had seen that tin does support f=f, at least it removed
stuffed spaces. Does it wrap paragraphs at more than 72 chars, or are
they adjusted to the screen width?
Also, what about slrn?
It may be that they send paragraphs as long lines, instead of breaking them into several lines with soft-wrapping trailing spaces as in format=flowed. Smapi/JamNNTPd properly handles both formats when posting to the messagebase.
So is it a HotdogEd problem that you're looking to come up with a work
around for, specifically?
No, it may be good for other newsreaders too. If I'm not mistaken, Smapi/JamNNTPd would work like other NNTP servers do.
Looks like Tommi has set QUOTEMARGIN to 80-something in his
GoldEd config...
I'm willing to bet Tommi doesn't even have the option set/overridden
from default. I've noticed this in Golded plenty of times in the past
as well, and I don't use that option in my config, either.
Also, what about slrn?
I'm willing to bet Tommi doesn't even have the option set/overridden
from default. I've noticed this in Golded plenty of times in the past
as well, and I don't use that option in my config, either.
:-m I don't have that option set and quotes are wrapped at 75 (the default, if I'm not mistaken).
I can now confirm via news.tin.org, slrn is also able to utilize the entire screen width - when NOT connecting to a jam/smapinntpd server.
Yes, but it does the same with both flowed off and on
(format=flowed and format=fixed look almost identical on readers
that don't support f=f). If you use it in horizontal view, or on
a larger screen like a tablet, it looks better.
Which is why I'm wondering if the wrap is set in HotdogEd for 79 characters by default. Then it would obviously have that issue when
using a phone with only ~58 character width available.
I think we had seen that tin does support f=f, at least it
removed stuffed spaces. Does it wrap paragraphs at more than 72
chars, or are they adjusted to the screen width?
I tested tin on the tin nntp server that contained very old messages. However, this was the only time I saw paragraphs adjusted to the
screen width. Anything that has come through jam/smapinntpd has been wrapped at 72-79 characters.
So is it a HotdogEd problem that you're looking to come up with
a work around for, specifically?
No, it may be good for other newsreaders too. If I'm not
mistaken, Smapi/JamNNTPd would work like other NNTP servers do.
I think with what I just described above (where I've seen screen width paragraphs outside of jam/smapinntpd), I see now where you guys are pointing out the difference against a "real" NNTP server.
Some clients probably don't understand the 'soft-wrapping trailing spaces', or don't care to put them back together to re-form long
lines, but can handle long lines themselves just fine. Am I
understanding what you are describing here, now?
I tried upping mailnews.wraplength to 79, and also down to 66 as
suggested in some RFC that was posted by you in the past, I believe. Neither one helps. Where the default settings are now is probably the best. Fidonet style "smart quoting" sometimes just needs a bit of backspacing of the text that gets wrapped to the next line back up to
the previous line it should be on.
If we were to fix that, we would probably have to get into the quoting
and rewrapping part of the code in order to detect
initials/smartquotes, remove them while remembering what quote level
it was, rewrap the text to be quoted, and re-add the initials with the quote level (probably how Golded does it).
I can now confirm via news.tin.org, slrn is also able to utilize the
entire screen width - when NOT connecting to a jam/smapinntpd
server.
I spun up Synchronet's nntp service to compare apples and oranges. Now slrn displays single long lines, which wraps at screen width. However, when quoting the single long line you get the above result.
And this:
Content-Type: text/plain; charset=UTF-8
* Note no "format=flowed" on there. This seems to be the same results found in Tommi's Wendzelnntp or whatever it was.
No. It's just that it doesn't support f=f's soft wraps. A "real" long
line is wrapped at screen width.
I tested tin on the tin nntp server that contained very old messages.
However, this was the only time I saw paragraphs adjusted to the
screen width. Anything that has come through jam/smapinntpd has been
wrapped at 72-79 characters.
So it has partial f=f support, as it seems it doesn't recognize soft wraps.
Some clients probably don't understand the 'soft-wrapping trailing
spaces', or don't care to put them back together to re-form long
lines, but can handle long lines themselves just fine. Am I
understanding what you are describing here, now?
Yes!
Thunderbird and Seamonkey do, but most others don't.
09 Apr 2024 18:23, you wrote to me:
I also did several tests and couldn't find anything that didn't have issues.
If we were to fix that, we would probably have to get into the quoting
and rewrapping part of the code in order to detect
initials/smartquotes, remove them while remembering what quote level
it was, rewrap the text to be quoted, and re-add the initials with the
quote level (probably how Golded does it).
It might be done in different ways, but yes, I think that the solution would be that Smapi/JamNNTPd re-wraps FTN-style quotes to 72 chars or
less when sending them to the client.
The alternative would be making clients support Fido-quotes. But this seems more difficult... :-)
BTW, HotdogEd does. You can select NNTP-style (no initials) or FTN-style quoting.
* Note no "format=flowed" on there. This seems to be the same results
found in Tommi's Wendzelnntp or whatever it was.
As expected. SBBS's NNTP server does not use format=flowed.
On Mon, Apr 22 2024 00:12:40 +0000, you wrote:
If you notice above, even Golded seems to quote longer than 80
character lines not so well.
Looks like Tommi has set QUOTEMARGIN to 80-something in his GoldEdconfig...
I'm willing to bet Tommi doesn't even have the option set/overridden
I'm willing to bet Tommi doesn't even have the option set/overridden
You may win or lose. I *do* have that setting in some of my golded's. :)
I'm willing to bet Tommi doesn't even have the option set/overridden
You may win or lose. I *do* have that setting in some of my golded's.
:)
Ok, but do you have it set to 80+? I think that's where we were going with that topic.
NB>> I'm willing to bet Tommi doesn't even have the option
NB>> set/overridden
TK> You may win or lose. I *do* have that setting in some of my
TK> golded's. :)
Ok, but do you have it set to 80+? I think that's where
we were going with that topic.
Hello Accession,
On Sat, 27 Apr 2024 07:52:20 -0500, I wrote to Tommi Koivula:
I'm willing to bet Tommi doesn't even have the option set/overridden
You may win or lose. I *do* have that setting in some of my golded's.
:)
Ok, but do you have it set to 80+? I think that's where we were going with
that topic.
Here is a perfect example. I have set "quotemargin 75" in my
golded.conf, and the line above is still wrapped by golded at 79. Now, probably when this gets re-quoted by something like Jam/Smapinntpd that uses WRAP_WIDTH 72 and LINE_WIDTH 79, there may be an issue.
going withOk, but do you have it set to 80+? I think that's where we were
that topic.
Ok, but do you have it set to 80+? I think that's where we were going
with that topic.
Ok, but do you have it set to 80+? I think that's where we were going with
that topic.
Ok, but do you have it set to 80+? I think that's where we were going with
that topic.
Test message with WRAP_WIDTH 72, LINE_WIDTH 80.
No. It's just that it doesn't support f=f's soft wraps. A "real"
long line is wrapped at screen width.
Yes, and then ends up with only one quote character before the first
line of the paragraph?
So if HotdogEd is your only current worry, maybe you could add some
kind of user option to change WRAP_WIDTH to 50 and LINE_WIDTH to 58 or something in order to fit on your phone screen. But then again, it's abandonware. lol
I've added a couple new settings to my JamNNTPd fork (https://github.com/cnb/jamnntpd/) that I hope will fix some of the
issues with spaces and quotes.
- def_nonbsp (user parameter nonbsp) for replacing UTF-8 non-breaking spaces by regular spaces.
I've improved that feature with this commit:
On Wed, 01 May 2024 20:07:14 +0200, you wrote to All:
Thanks Carlos!
Hello Carlos,
On Wed, 01 May 2024 20:07:14 +0200, you wrote to All:
Thanks Carlos!
Regards,
Nick
... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
Test.
...
---
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
I've improved that feature with this commit:
Thanks Carlos!
Test.
On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:
TK> Test.
TK> ...
TK> ---
TK> * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
Not sure if you actually saw anything odd, but there was a typo in my
commit, pointed out by Carlos, that has since been fixed.
On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:
I've improved that feature with this commit:
Thanks Carlos!
Test.
Testing another typo fix in 2.4.3 commit.
Yes I did. I applied your pathes to smapinntpd, and then reverted back. Tested your server also.
Then I had no time to test more. ;)
Continuing now..
I think I've got it ok now. ;)
On Sat, 4 May 2024 23:48:18 +0300, Tommi Koivula -> Nicholas Boel wrote:
I think I've got it ok now. ;)
That's good. I was worried about you for a second there. ;)
BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.
BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.
I wanted to "log" something from nntp client to kludges. So NOTE was changed to what the client sends.. Just for testing..
X-SMAPI-Control: @RFC-User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64;
x64; rv:115.0) Gecko/20100101 Thunderbird/115.10
X-SMAPI-Control: @RFC-Content-Type: text/plain; charset=UTF-8; format=flowed
X-SMAPI-Control: @RFC-Content-Transfer-Encoding: 8bit
On Sun, 5 May 2024 00:14:44 +0300, Tommi Koivula -> Nicholas Boel wrote:
BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.
I wanted to "log" something from nntp client to kludges. So NOTE was changed to what the client sends.. Just for testing..
X-SMAPI-Control: @RFC-User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.10
X-SMAPI-Control: @RFC-Content-Type: text/plain; charset=UTF-8; format=flowed
X-SMAPI-Control: @RFC-Content-Transfer-Encoding: 8bit
Is that specific to Thunderbird and/or Sylpheed? I believe slrn and tin
it doesn't use or display "RFC". It just sends "User-Agent:", "Content-Type:", and "Content-Transfer-Encoding:".
Is that specific to Thunderbird and/or Sylpheed? I believe slrn and tin
it doesn't use or display "RFC". It just sends "User-Agent:",
"Content-Type:", and "Content-Transfer-Encoding:".
The "RFC-" part of the kludge was added by me.
Is that specific to Thunderbird and/or Sylpheed? I believe slrn
and tin it doesn't use or display "RFC". It just sends
"User-Agent:", "Content-Type:", and
"Content-Transfer-Encoding:".
The "RFC-" part of the kludge was added by me.
I get that. But, did you get that from some technical document that
that should be in use?
Or is this something you've just done yourself because FMail adds a RFC-X-NO-ARCHIVE kludge?
From Wikipedia:
"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."
So I imagine what FMail is doing, isn't actually preventing messages
from being archived.
Or is this something you've just done yourself because FMail adds a
RFC-X-NO-ARCHIVE kludge?
Nothing to do with FMail. Actually I cannot find anything like that in fmail docs or in the code.
Maybe it is the GoldED of Wilfred that is adding that kludge. ;)
From Wikipedia:
"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."
So I imagine what FMail is doing, isn't actually preventing messages
from being archived.
In the fidonet, probably not.
I get that. But, did you get that from some technical document that
that should be in use?
Nope.. Just my own thing, something what soupgate does..
Or is this something you've just done yourself because FMail adds a
RFC-X-NO-ARCHIVE kludge?
Nothing to do with FMail. Actually I cannot find anything like that in fmail docs or in the code. Maybe it is the GoldED of Wilfred that is adding that kludge. ;)
It indeed has nothing to do with FMail.
Maybe it is the GoldED of Wilfred that is adding that kludge. ;)
That is true.
From Wikipedia:
"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."
So I imagine what FMail is doing, isn't actually preventing messages
from being archived.
I have no illusions about that. It's incase my messages are gated to newsgroups in some of the fido areas...
Right, but the question is (after reading that wiki site, and
finding no reference to said prefix), is if the newsgroup software
(s) are looking for an "X-NO-ARCHIVE" or an "RFC-X-NO-ARCHIVE"
header field. According to the above, adding the "RFC" prefix would
cause the search for the proper header field to fail, as would the
rest of the ones Tommi has changed. That's why I asked.
That's also possible. I just don't understand where the "RFC"
prefix came from for some of these headers (even the few already in
use in Fidonet). I can't find any reference to that prefix anywhere.
That's also possible. I just don't understand where the "RFC"
prefix came from for some of these headers (even the few already in
use in Fidonet). I can't find any reference to that prefix anywhere.
Well, even GoldED has some 'RFC' things in its internet support..
If some news archive software is searching for "X-NO-ARCHIVE", it might
be happy to find "RFC-X-NO-ARCHIVE". :)
Right, but the question is (after reading that wiki site, and finding
no reference to said prefix), is if the newsgroup software(s) are
looking for an "X-NO-ARCHIVE" or an "RFC-X-NO-ARCHIVE" header field. According to the above, adding the "RFC" prefix would cause the search
for the proper header field to fail, as would the rest of the ones
Tommi has changed. That's why I asked.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:03:54 |
| Calls: | 8,066 |
| Calls today: | 1 |
| Files: | 13,055 |
| Messages: | 5,841,810 |
