The F I D O N E W S Volume 39, Number 18 02 May 2022 +--------------------------+-----------------------------------------+
| |The newsletter of the | | |
| | FidoNet community. | | Netmail attach to (POTS): |
| | | | Editor @ 2:2/2 (+46-31-960447) |
| | ____________| | |
| | / __ | Netmail attach to (BinkP): |
| | / / \ | Editor @ 2:203/0 |
| | WOOF! ( /|oo \ | |
| \_______\(_| /_) | Email attach to: |
| _ @/_ \ _ | b @ felten dot se |
| | | \ \\ | |
| | (*) | \ ))| |
| |__U__| / \// | Editor: Bj”rn Felten |
| ______ _//|| _\ / | |
| / Fido \ (_/(_|(____/ | Newspapers should have no friends. |
| (________) (jm) | -- JOSEPH PULITZER | +--------------------------+-----------------------------------------+


Table of Contents
1. LIST OF FIDONET IPV6 NODES ............................... 1
List of IPv6 nodes ....................................... 1
2. JAMNNTPD SERVERS LIST .................................... 4
The Johan Billing JamNNTPd project ....................... 4
3. FIDONEWS'S FIDONET SOFTWARE LISTING ...................... 5
4. SPECIAL INTEREST ......................................... 12
Statistics from the Fidoweb .............................. 12
Nodelist Stats ........................................... 13
5. FIDONEWS INFORMATION ..................................... 15
How to Submit an Article ................................. 15
Credits, Legal Infomation, Availability .................. 17

--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)

=================================================================
LIST OF FIDONET IPV6 NODES =================================================================

List of IPv6 nodes
By Michiel van der Vlist, 2:280/5555

Updated 29 April 2022


Node Nr. Sysop Type Provider Remark

1 2:280/464 Wilfred van Velzen Native Xs4All f 6DWN
2 2:280/5003 Kees van Eeten Native Xs4All f
3 2:5019/40 Konstantin Kuzov T-6in4 he.net f
4 2:280/5555 Michiel van der Vlist Native Ziggo f
5 1:320/219 Andrew Leary Native Comcast f
6 2:221/1 Tommi Koivula Native Hetzner f
7 2:221/6 Tommi Koivula Native OVH
8 2:5030/257 Vova Uralsky Native PCextreme
9 1:154/10 Nicholas Boel Native Spectrum f
10 2:203/0 Bjorn Felten T-6in4 he.net
11 2:280/5006 Kees van Eeten Native Xs4All f INO4
12 3:712/848 Scott Little T-6in4 he.net f
13 2:5020/545 Alexey Vissarionov T-6in4 he.net f 6DWN
14 1:103/17 Stephen Hurd T-6in4 he.net
15 2:5020/9696 Alexander Skovpen T-6in4 TUNNELBROKER-0
16 2:421/790 Viktor Cizek T-6in4 he.net
17 2:222/2 Kim Heino Native TeliaSonera
18 3:633/280 Stephen Walsh Native AusNetServers f
19 2:463/877 Alex Shuman Native Nline f IO
20 1:19/10 Matt Bedynek T-6in4 he.net
21 3:770/1 Paul Hayton T-6in4 he.net
22 3:770/100 Paul Hayton T-6in4 he.net
23 2:5053/58 Alexander Kruglikov Native TTK-Volga f
24 1:103/1 Stephen Hurd Native Choopa
25 3:633/281 Stephen Walsh Native Internode
26 2:310/31 Richard Menedetter Native DE-NETCUP f
27 3:633/410 Tony Langdon Native IINET
28 2:5020/329 Oleg Lukashin Native Comfortel f
29 2:246/1305 Emil Schuster Native TAL.DE
30 2:2448/4000 Tobias Burchhardt Native DTAG IO
31 2:331/51 Marco d'Itri Native BOFH-IT
32 1:154/30 Mike Miller Native LINODE
33 2:5001/100 Dmitry Protasoff Native OVH
34 2:5059/38 Andrey Mundirov T-6in4 he.net
35 2:240/5853 Philipp Giebel Native Hetzner
36 2:5083/444 Peter Khanin Native OVH
37 2:2452/413 Ingo Juergensmann Native RRBONE-COLO f
38 1:123/10 Wayne Smith T-6in4 he.net
39 2:4500/1 Eugene Kozhuhovsky Native DATAHATA6
40 1:135/300 Eric Renfro Native Amazon.com
41 1:103/13 Stephen Hurd Native Choopa
42 2:5020/1042 Michael Dukelsky Native FORPSI Ktis f
43 2:5095/0 Sergey V. Efimoff T-6in4 he.net
44 2:5095/20 Sergey V. Efimoff T-6in4 he.net
45 2:5019/400 Konstantin Kuzov Native LT-LT
46 2:467/239 Mykhailo Kapitanov Native Vultr f
47 2:463/1331 Andrei Dzedolik Native DIGITALOCEAN
48 2:5010/275 Evgeny Chevtaev T-6in4 TUNNELBROKER-0 f
49 2:280/2000 Michael Trip Native Xs4All
50 2:230/38 Benny Pedersen Native Linode
51 2:460/58 Stas Mishchenkov T-6in4 he.net f
52 2:5020/2123 Anton Samsonov T-6in4 he.net
53 2:5020/2332 Andrey Ignatov Native ru.rtk
54 2:5005/49 Victor Sudakov T-6in4 he.net f
55 2:5005/77 Valery Lutoshkin T-6in4 NTS f
56 2:5005/106 Alexey Osiyuk T-6in4 he.net f
57 2:5057/53 Ivan Kovalenko Native ER-Telecom f
58 2:5010/352 Dmitriy Smirnov Native SAGE-SU-V6
59 2:292/854 Ward Dossche Native Proximus
60 2:469/122 Sergey Zabolotny T-6in4 he.net f
61 2:5053/400 Alexander Kruglikov Native FirstVDS f
62 2:5030/1997 Alexey Fayans T-6in4 he.net
63 2:5061/15 Eugene Gladchenko Native ARUBAUK-NET
64 2:2452/502 Ludwig Bernhartzeder Native DTAG
65 2:423/39 Karel Kral Native WEDOS
66 2:5080/102 Stas Degteff T-6to4 NOVATOR
67 2:280/1049 Simon Voortman Native Solcon
68 1:102/127 Bradley Thornton Native Hetzner
69 2:335/364 Fabio Bizzi Native OVH
70 1:124/5016 Nigel Reed Native DAL1-US f
71 2:5075/37 Andrew Komardin Native IHC-NET
72 1:106/633 William Williams Native LINODE-US PM *1
73 2:263/5 Martin List-Petersen Native TuxBox
74 2:5030/1520 Andrey Geyko T-6in4 he.net f
75 1:229/664 Jay Harris Native Rogers f
76 1:142/103 Brian Rogers T-6in4 he.net
77 1:134/101 Kostie Muirhead T-6in4 he.net f
78 2:280/2030 Martien Korenblom Native Transip
79 3:633/509 Deon George Native Telstra
80 2:5020/4441 Yuri Myakotin Native SOVINTEL
81 1:320/319 Andrew Leary Native Comcast f
82 2:240/5824 Anna Christina Nass Native DTAG f
83 2:460/5858 Stas Mishchenkov T-6in4 he.net f INO4
84 2:5030/3165 Serg Podtynnyi Native DIGITALOCEAN
85 2:301/812 Benoit Panizon Native WOODYV6
86 1:229/616 Vasily Losev Native GIGEPORT
87 2:301/113 Alisha Manuela Stutz T-6in4 he.net
88 1:134/100 Kostie Muirhead T-6in4 he.net f
89 1:134/101 Kostie Muirhead T-6in4 he.net f
90 1:134/102 Shelley Petersen T-6in4 he.net f INO4
91 1:134/103 Gordon Muirhead T-6in4 he.net f
92 1:134/301 Brandon Moore T-6in4 he.net f INO4
93 1:134/302 Adam Park T-6in4 he.net f
94 1:153/7715 Dallas Hinton Native Shaw Comms
95 1:218/840 Morgan Collins Native Linode
96 2:5020/921 Andrew Savin T-6in4 he.net
97 2:240/1634 Hugo Andriessen Native Vodafone
98 2:280/2040 Leo Barnhoorn Native KPN f
99 2:5020/736 Egor Glukhov Native RUWEB f
100 2:221/10 Tommi Koivula Native Hetzner f INO4
101 1:266/420 Scott Street Native Comcast OO
102 1:218/850 John Nicpon Native LINODE-US
103 1:142/104 Clive Reuben Native SNETFCC-1
104 2:301/1 Alisha Stutz Native CH-DATAWIRE
105 3:633/267 Andrew Clarke Native Widebandnetv6
106 2:5035/63 Vladimir Goncharov Native RFEIV6NET
107 2:5010/152 Dmitry Smirnov Native RU-SELECTCEL
108 2:5010/252 Dmitry Smirnov T-6in4 TUNNEL-BROKER-NET-1
109 2:5020/290 Andrew Kolchoogin T-6in4 he.net


T-6in4 Static 6in4
T-AYIY Dynamic AYIYA
T-6to4 6to4
T-6RD 6RD

Remarks:

f Has a ::f1d0:<zone>:<net>:<node> style host address.
(zone, net, node in decimal notation)
IO Incoming only (Node can not make outgoing IPv6 calls)
OO Outgoing only (Node can not accept incoming IPv6 calls).
INO4 No IPv4 (Node can not accept incoming IPv4 calls).
PO4 Prefers Out on 4 (Node can make outgoing IPv6 calls,
but is configured to try IPv4 first)
6DWN The IPv6 connectivity of this node is temporarely down.
NO6 The node no longer presents an IPv6 address in the nodelist
and will soon be removed from this list.
HOLD The node is temporarely off-line. Mail may be routed.
DOWN This node is Down for both IPv4 and IPv6 and will be
removed from this list if the condition pertains.
PM Prospective Member. The node has demonstrated IPv6
capability but is not listed or does not advertise an
IPv6 address in the Fidonet nodelist yet.

PM *1 [2600:3c01::f03c:91ff:fe2b:c319]


Notes:

To make an IPv6 connection to a node connected via 6to4 tunneling
one may have to force the mailer into IPv6 (-6 option in binkd's
node config for binkd up to 1.1a-96, -64 option for binkd 1.1a-97
and up when compiled with AF_FORCE=1). If the destination address
is a 6to4 tunnel address (2002::/16) many OSs default to IPv4 if
an IPv4 address is present.


Submitted on day 121

-----------------------------------------------------------------

--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)

=================================================================
SPECIAL INTEREST =================================================================

Last week's statistics from the Fidoweb
By EchoTime @ 2:203/0

(Some nets may have lost their last
digit for technical reasons)

pkt (toss-toss) msg (write-toss)
nodes mean dev no mean dev no

154/* 1.2m 0.8m 760 1.1h 5.6h 761
201/* 1.9m 0.7m 4 0.0h 0.0h 4
221/* 0.9m 0.8m 800 5.9h 11.8h 800
280/* 0.8m 0.8m 488 6.1h 12.4h 487
292/* 3.3m 1.4m 11 4.0h 3.6h 10
320/* 3.5m 2.7m 286 2.1h 5.0h 286

Sigma 1.3m 1.5m 2349 3.9h 9.9h 2348

-----------------------------------------------------------------
Nodelist Stats

Input nodelist nodelist.119
size 181.6kb
date 2022-04-29

The nodelist has 972 nodes in it
and a total of 1423 non-comment entries

including 4 zones
33 regions
171 hosts
66 hubs
admin overhead 274 ( 28.19 %)

and 111 private nodes
32 nodes down
34 nodes on hold
off line overhead 177 ( 18.21 %)


Speed summary:

>9600 = 34 ( 3.50 %)
9600 = 162 ( 16.67 %)
(HST = 2 or 1.23 %)
(CSP = 0 or 0.00 %)
(PEP = 0 or 0.00 %)
(MAX = 0 or 0.00 %)
(HAY = 0 or 0.00 %)
(V32 = 57 or 35.19 %)
(V32B = 18 or 11.11 %)
(V34 = 73 or 45.06 %)
(V42 = 55 or 33.95 %)
(V42B = 18 or 11.11 %)
2400 = 0 ( 0.00 %)
1200 = 0 ( 0.00 %)
300 = 776 ( 79.84 %)

ISDN = 33 ( 3.40 %)

-----------------------------------------------------
IP Flags Protocol Number of systems -----------------------------------------------------
IBN Binkp 798 ( 82.10 %) ----------------------------------
IFC Raw ifcico 80 ( 8.23 %) ----------------------------------
IFT FTP 62 ( 6.38 %) ----------------------------------
ITN Telnet 167 ( 17.18 %) ----------------------------------
IVM Vmodem 13 ( 1.34 %) ----------------------------------
IP Other 4 ( 0.41 %) ----------------------------------
INO4 IPv6 only 5 ( 0.51 %) ----------------------------------

CrashMail capable = 864 ( 88.89 %)
MailOnly nodes = 295 ( 30.35 %)
Listed-only nodes = 19 ( 1.95 %)



[Report produced by NETSTATS - A PD pgm]
[ Revised by B Felten, 2:203/2]
[ NetStats 3.8 2014-11-23]

-----------------------------------------------------------------

--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)

FidoNews Robot wrote to All <=-

The F I D O N E W S Volume 39, Number 18 02 May 2022

<SNIP>

.-.<YAWN>.-.

Same old tired duplicate crap. Only the Volume/Number/Date is changed.



... He does the work of 3 Men...Moe, Larry & Curly
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Same old tired duplicate crap. Only the Volume/Number/Date is changed.

Well, you obviously didn't read the issue then.

And, BTW, I didn't find your contribution. You *do* know that it's the community that's supposed to write the articles, not the editor?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Dan,

The F I D O N E W S Volume 39, Number 18 02 May 2022

...

Same old tired duplicate crap. Only the Volume/Number/Date is changed.

You want this to change? Well ... why don't you provide change ... write an article and publish it.

Other than that. the Fidonews-publication (not the echo) is a time-track of whatever's happened in and to Fidonet since nearly the early beginnings ... no content? Nothing happened...

You want content? Provide it ...

\%/@rd

--- DB4 - 20220425
* Origin: Many Glacier ... Protect - Preserve - Conserve - Recycle (2:292/854)

Bj”rn Felten wrote to Dan Clough <=-

Same old tired duplicate crap. Only the Volume/Number/Date is changed.

Well, you obviously didn't read the issue then.

That is actually true. You know why? Because it's sent out as
something like 7-8 different messages (which is fine), but my dupe
checking filters out all but 3 of the pages because they're EXACTLY the
same as the previous edition. The only reason I even see 3 pages is
because there are minor differences (not content-related) in them from
the previous ones.

And, BTW, I didn't find your contribution. You *do* know that
it's the community that's supposed to write the articles, not the
editor?

Yeah yeah, I know.

I guess my point is - why even send it out if it has no (new) content?



... All the easy problems have been solved.
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Ward Dossche wrote to Dan Clough <=-

The F I D O N E W S Volume 39, Number 18 02 May 2022

Same old tired duplicate crap. Only the Volume/Number/Date is changed.

You want this to change? Well ... why don't you provide change
... write an article and publish it.

Well I have good intentions (yeah, I know) of doing that, but finding
anything suitable as content is challenging.

Other than that. the Fidonews-publication (not the echo) is a
time-track of whatever's happened in and to Fidonet since nearly
the early beginnings ... no content? Nothing happened...

Then why send out an empty/duplicate issue?

You want content? Provide it ...

You already said that.



... Press any key to continue or any other key to quit
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Hello Dan,

On Monday May 02 2022 07:54, you wrote to Bj”rn Felten:

Well, you obviously didn't read the issue then.

That is actually true. You know why? Because it's sent out as
something like 7-8 different messages (which is fine), but my dupe checking filters out all but 3 of the pages because they're EXACTLY
the same as the previous edition.

Then obviously there is something wrong with your dupe detection algorithm. My Fmail does not reject them as dupes and rightly so because the message /are/ different.

The only reason I even see 3 pages is because there are minor
differences (not content-related) in them from the previous ones.

You missed the difference in content in my list of IPv6 nodes on the second page?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.

* The weather
* Superbowl
* Nancy Pelosi visiting Kiev
* Will Smith whacking the other fellah between the eyes
* Odd airplane crashes with Boeing airplanes
* You just shit your pants and the advantages of adult diapers
* A recipe for Pizzagna ...

There's so much.

Weren't you also going to write something for the Fidogazette?

I did ... 4 articles, the "only" genuine articles which appeared there. Without them, that publication would've been just as extinct as the do-do bird.

So start writing something, anything, and by doing so give credibility to both publications ... and yourself...

Then why send out an empty/duplicate issue?

It doesn't break the time-track ...

You want content? Provide it ...

You already said that.

Yups ... so have you started writing?

Besides ... what crappy dupe-checker do you use? Everything's just fine here ...

\%/@rd

--- DB4 - 20220425
* Origin: Many Glacier ... Protect - Preserve - Conserve - Recycle (2:292/854)

Michiel van der Vlist wrote to Dan Clough <=-

Well, you obviously didn't read the issue then.

That is actually true. You know why? Because it's sent out as
something like 7-8 different messages (which is fine), but my dupe checking filters out all but 3 of the pages because they're EXACTLY
the same as the previous edition.

Then obviously there is something wrong with your dupe detection algorithm. My Fmail does not reject them as dupes and rightly so
because the message /are/ different.

No, about half of them are NOT different. Maybe your Fmail dupe
detection sucks.

The only reason I even see 3 pages is because there are minor
differences (not content-related) in them from the previous ones.

You missed the difference in content in my list of IPv6 nodes on
the second page?

Where did you get that idea?



... Internal Error: The system has been taken over by sheep at line 19960
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Ward Dossche wrote to Dan Clough <=-

Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.

* The weather
* Superbowl
* Nancy Pelosi visiting Kiev
* Will Smith whacking the other fellah between the eyes
* Odd airplane crashes with Boeing airplanes
* You just shit your pants and the advantages of adult diapers
* A recipe for Pizzagna ...

There's so much.

None of that is relevant to FidoNet.

Just like the remainder of your message, that I snipped.



... He does the work of 3 Men...Moe, Larry & Curly
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Hello Dan,

The F I D O N E W S Volume 39, Number 18 02 May 2022

[..]

Same old tired duplicate crap. Only the Volume/Number/Date is changed.

If you wish to submit an article for inclusion in the Fidonews, here
are some guidelines ...

--Lee

--
Every bite is a different temperature

--- MesNews/1.08.05.00-gb
* Origin: news://eljaco.se:4119 (2:203/2)

Then obviously there is something wrong with your dupe detection
algorithm. My Fmail does not reject them as dupes and rightly so
because the message /are/ different.

No, about half of them are NOT different. Maybe your Fmail dupe
detection sucks.

Nope, in this case it is SBBSecho's dupe detection that sucks.

These messages being trapped as dupes by SBBSecho are not dupes. They have a different date stamp and MSGID.

This is a long standing issue with SBBSecho's dupe detection that has been reported but for whatever reason is not considered important and so has never been fixed.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Alan Ianson wrote to Dan Clough <=-

Then obviously there is something wrong with your dupe detection
algorithm. My Fmail does not reject them as dupes and rightly so
because the message /are/ different.

No, about half of them are NOT different. Maybe your Fmail dupe
detection sucks.

Nope, in this case it is SBBSecho's dupe detection that sucks.

These messages being trapped as dupes by SBBSecho are not dupes.
They have a different date stamp and MSGID.

Yes, and that is *ALL* that is different. The *content* is exactly the
same as the previous version, and therefore detected as a dupe.

This is a long standing issue with SBBSecho's dupe detection that
has been reported but for whatever reason is not considered
important and so has never been fixed.

I'm fine with the detection being done on the *CONTENT* which is of
course what matters. Think about this - a spammer could just keep
dumping the same message(s) over and over, and they'd come through
because of a different MSGID? Screw that.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Nope, in this case it is SBBSecho's dupe detection that sucks.

These messages being trapped as dupes by SBBSecho are not dupes.
They have a different date stamp and MSGID.

Yes, and that is *ALL* that is different. The *content* is exactly the
same as the previous version, and therefore detected as a dupe.

Right, but the messages are not dupes as can be seen clearly by the date stamp and MSGID.

This issue affects messages well beyond the issue we see in the FIDONEWS echo.

This is a long standing issue with SBBSecho's dupe detection that
has been reported but for whatever reason is not considered
important and so has never been fixed.

I'm fine with the detection being done on the *CONTENT* which is of
course what matters. Think about this - a spammer could just keep
dumping the same message(s) over and over, and they'd come through
because of a different MSGID? Screw that.

The issue here is not spammers.

I think I said that wrong. It is not an issue that needs to be reported and/or fixed.

SBBSecho is working as designed. It is a design issue that needs to be changed if change is wanted/desirable.

I ran a Synchronet BBS for a long time and find it to be an excellent and well designed BBS package but walked away from it for this one reason.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Alan Ianson wrote to Dan Clough <=-

Nope, in this case it is SBBSecho's dupe detection that sucks.

These messages being trapped as dupes by SBBSecho are not dupes.
They have a different date stamp and MSGID.

Yes, and that is *ALL* that is different. The *content* is exactly the
same as the previous version, and therefore detected as a dupe.

Right, but the messages are not dupes as can be seen clearly by
the date stamp and MSGID.

Yes.... you already said that, and I acknowledged that. Let me put it a different way. How many users do you think look at (or care about) a
MSGID? Or the date, really? What matters in a message is the *CONTENT*
of the message. The body of the message. If *THAT* is exactly the same
as a previous message, why would we want to see it again?

This issue affects messages well beyond the issue we see in the
FIDONEWS echo.

Well sure, it would affect all echos. Can you give me a good example of why/when a person would want to see a message that has already come
through, with the *EXACT* same *MESSAGE BODY*?

This is a long standing issue with SBBSecho's dupe detection that
has been reported but for whatever reason is not considered
important and so has never been fixed.

I'm fine with the detection being done on the *CONTENT* which is of
course what matters. Think about this - a spammer could just keep
dumping the same message(s) over and over, and they'd come through
because of a different MSGID? Screw that.

The issue here is not spammers.

But it could be. With your preference of dupe detection, somebody could
post 10,000 copies of the same message into any echo they wanted, and
they'd all show up on your BBS as new messages. How can that be good?

I think I said that wrong. It is not an issue that needs to be
reported and/or fixed.

You're confusing me now, as it seems you would like it to be "fixed".

SBBSecho is working as designed. It is a design issue that needs
to be changed if change is wanted/desirable.

Okay...

I ran a Synchronet BBS for a long time and find it to be an
excellent and well designed BBS package but walked away from it
for this one reason.

Wow. Really? This one "issue" made you stop using the whole BBS
package? That seems kinda strange/extreme. I vaguely remember some conversation about this, probably in DoveNet at some point. Did DM say
it wasn't something he wanted to change/fix?


... Behind every great man is an amazed mother-in-law!
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Right, but the messages are not dupes as can be seen clearly by
the date stamp and MSGID.

Yes.... you already said that, and I acknowledged that.

I keep saying that because it is important.

I don't want my tosser tossing some (most) of the messages and throwing some away.

Let me put it a different way. How many users do you think look at (or care about) a MSGID? Or the date, really?

They don't. It is used (or could be) by the tosser to detect dupes.

What matters in a message is the *CONTENT* of the message. The body of the message. If *THAT* is exactly the same as a previous message, why would we want to see it again?

Maybe we don't, that's a choice you or anyone reading a message can make a choice about. If it is a new message it should be tossed as expected.

This issue affects messages well beyond the issue we see in the
FIDONEWS echo.

Well sure, it would affect all echos. Can you give me a good example of why/when a person would want to see a message that has already come
through, with the *EXACT* same *MESSAGE BODY*?

You were the one who brought the issue up saying that these messages were not present in your message base because your tosser (incorrectly) trapped them as dupes.

These messages may have the same content as previous posts. This will happen in the fidonews echo when content doesn't change. It happens when an echoes rules post is made and there has been no change in content. It happens with BBS ads also when content doesn't change.

These are all new posts with a new date stamp and MSGID.

The issue here is not spammers.

But it could be. With your preference of dupe detection, somebody could
post 10,000 copies of the same message into any echo they wanted, and
they'd all show up on your BBS as new messages. How can that be good?

No that is not good, but that is not what we are talking about. That is not what is happening.

I think I said that wrong. It is not an issue that needs to be
reported and/or fixed.

You're confusing me now, as it seems you would like it to be "fixed".

It's not really relevent to me since I don't use SBBSecho but yes, I think it is an issue that should be fixed. You are not alone in this situation.

Wow. Really? This one "issue" made you stop using the whole BBS
package?

Yes, that is the case.

That seems kinda strange/extreme. I vaguely remember some conversation
about this, probably in DoveNet at some point. Did DM say it wasn't something he wanted to change/fix?

I can't speak for DM but that is my understanding.

If I had only BBS users I might let it slide but I have more links than BBS users so this situation becomes more of an issue.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: Re: FidoNews 39:18 [00/06]: The Front Page
By: Dan Clough to Alan Ianson on Mon May 02 2022 07:28 pm

I ran a Synchronet BBS for a long time and find it to be an
excellent and well designed BBS package but walked away from it
for this one reason.

Wow. Really? This one "issue" made you stop using the whole BBS
package? That seems kinda strange/extreme. I vaguely remember some conversation about this, probably in DoveNet at some point. Did
DM say it wasn't something he wanted to change/fix?

IIRC, you can turn off "content" dupe-detection, but you cannot turn off MSGID dupe detection...


...ëîåï
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Alan Ianson wrote to Dan Clough <=-

Right, but the messages are not dupes as can be seen clearly by
the date stamp and MSGID.

Yes.... you already said that, and I acknowledged that.

I keep saying that because it is important.

I don't want my tosser tossing some (most) of the messages and
throwing some away.

I do. I want it to throw away dupes, which I like to define as having
the same message body as a previous message. If the only thing
different is the date and an arbitrary number (MSGID), it's a dupe.

Let me put it a different way. How many users do you think look at (or care about) a MSGID? Or the date, really?

They don't. It is used (or could be) by the tosser to detect
dupes.

I suppose it could be, yes.

What matters in a message is the *CONTENT* of the message. The body of the message. If *THAT* is exactly the same as a previous message, why would we want to see it again?

Maybe we don't, that's a choice you or anyone reading a message
can make a choice about. If it is a new message it should be
tossed as expected.

We'll have to differ in opinion on this.

This issue affects messages well beyond the issue we see in the
FIDONEWS echo.

Well sure, it would affect all echos. Can you give me a good example of why/when a person would want to see a message that has already come
through, with the *EXACT* same *MESSAGE BODY*?

You were the one who brought the issue up saying that these
messages were not present in your message base because your
tosser (incorrectly) trapped them as dupes.

Again, opinion.... I think it correctly called them dupes.

These messages may have the same content as previous posts. This
will happen in the fidonews echo when content doesn't change. It
happens when an echoes rules post is made and there has been no
change in content. It happens with BBS ads also when content
doesn't change.

Yes, agreed on all that. If the content hasn't changed, why do I need
to see it again?

These are all new posts with a new date stamp and MSGID.

And the same content that you saw last month. Not needed.

<SNIP>

I think I said that wrong. It is not an issue that needs to be
reported and/or fixed.

You're confusing me now, as it seems you would like it to be "fixed".

It's not really relevent to me since I don't use SBBSecho but
yes, I think it is an issue that should be fixed. You are not
alone in this situation.

Indeed. I suspect I'm in the majority with my opinion.

Wow. Really? This one "issue" made you stop using the whole BBS
package?

Yes, that is the case.

That seems kinda strange/extreme. I vaguely remember some conversation about this, probably in DoveNet at some point. Did DM say it wasn't something he wanted to change/fix?

I can't speak for DM but that is my understanding.

He is very receptive to suggestions/requests, if you didn't directly ask
him about the issue you maybe should have...

If I had only BBS users I might let it slide but I have more
links than BBS users so this situation becomes more of an issue.

This is a good point that I hadn't considered, as I don't have any
downlinks here. Hmmmm. I can almost see the word "censorship" creeping
into the conversation... ;-)

Probably best to agree to disagree, and leave it be. Cheers.


... Backup not found: (A)bort (R)etry (P)anic
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

On May 02, 2022 07:33pm, Dan Clough wrote to Alan Ianson:

Yes.... you already said that, and I acknowledged that. Let me put it a different way. How many users do you think look at (or care about) a MSGID? Or the date, really? What matters in a message is the *CONTENT* of the message. The body of the message. If *THAT* is exactly the same as a previous message, why would we want to see it again?

Echo Rules.

Terry

... Platinum Xpress & Wildcat!..... Nice!!!!
--- Platinum Xpress/Win/WINServer v7.0
* Origin: The File Bank BBS! https://tfb-bbs.org (3:712/1321)

IIRC, you can turn off "content" dupe-detection, but you cannot turn off MSGID dupe detection...

Yes, you can disable duplicate message detection, then the only detection you get is from the MSGID. This doesn't work at all with messages that have no MSGID. There are still many of those.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

I don't want my tosser tossing some (most) of the messages and
throwing some away.

I do. I want it to throw away dupes, which I like to define as having
the same message body as a previous message. If the only thing
different is the date and an arbitrary number (MSGID), it's a dupe.

Yes, dupes should go to dupe heaven. Not new messages that look like old messages. That is a false positive.

I can't speak for DM but that is my understanding.

He is very receptive to suggestions/requests, if you didn't directly ask
him about the issue you maybe should have...

Yes, I spoke directly with DM. I didn't press the issue but I brought it up.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Yes, agreed on all that. If the content hasn't changed, why do I need
to see it again?

Dan .... on the 1st of every month, in some cases also the 15th, there is a moderator message in echoes outlining the rules.

Some of these messages haven't changed in a decade or more ... just the time/date stamp and the MSGID.

So they are thrown out now too? One day you may be banned from an echo because of a rule violation which you never saw because you claimed it was a dupe ...

Listen, Dan, you're grasping at straws ... With the Fido-technology at present and the way of how business has been conducted for years it is quite obvious what is a dupe and what not. I guess these things have been documented by the FTSC even, but I'm not going to search for it.

You may personally consider what you call a dupe as outlined previously but if you want to use that as the starting point of a religeous sect then you will have very few followers.

I consider this nothing else than the occasional Bjorn-bashing ... and then someone else will say "Did you see that? He is a friend of Bjorn's and defending him again. He should not have access to Z1C (while your ZC has free access to our similar)" ...

You're grasping at straws Dan ... just drop it ... can not be improved.

\%/@rd

--- DB4 - 20220425
* Origin: Many Glacier ... Protect - Preserve - Conserve - Recycle (2:292/854)

Hello Dan,

On Monday May 02 2022 15:28, you wrote to me:

Then obviously there is something wrong with your dupe detection
algorithm. My Fmail does not reject them as dupes and rightly so
because the message /are/ different.

No, about half of them are NOT different. Maybe your Fmail dupe
detection sucks.

I am not going to argue with you. These false dupes of yours are obviously due to the software you use. Your choice, your problem.

The only reason I even see 3 pages is because there are minor
differences (not content-related) in them from the previous ones.

You missed the difference in content in my list of IPv6 nodes on
the second page?

Where did you get that idea?

From what you wrote above. "not content related". You missed the difference in content on that page.

If you want more content in the Fidonews, stop trolling and start writing articles.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

MvdV> If you want more content in the Fidonews, stop trolling and start
MvdV> writing articles.

One of the problems in Fidonet of today is, that there's far too much gimme, gimme and far too little lemme, lemme.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Yes, and that is *ALL* that is different. The *content* is exactly the same as the previous version, and therefore detected as a dupe.

Rather than complaining about it, why don't you simply ask for a refund. Problem solved. How much did you pay for your subscription?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Terry Roati wrote to Dan Clough <=-

On May 02, 2022 07:33pm, Dan Clough wrote to Alan Ianson:

Yes.... you already said that, and I acknowledged that. Let me put it a different way. How many users do you think look at (or care about) a MSGID? Or the date, really? What matters in a message is the *CONTENT* of the message. The body of the message. If *THAT* is exactly the same as a previous message, why would we want to see it again?

Echo Rules.

Right. So, if the rules haven't changed, why would I need to see them
again?



... "42? 7 and a half million years and all you can come up with is 42?!"
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Hello Dan Clough!

** On Tuesday 03.05.22 - 07:46, Dan Clough wrote to Terry Roati:

Echo Rules.

Right. So, if the rules haven't changed, why would I need
to see them again?

Somebody else entering the echo for the first time might.

--
../|ug

--- OpenXP 5.0.51
* Origin: --> . <-- Oh look.. A point! (2:221/1.58)

On May 03, 2022 07:51am, Dan Clough wrote to Terry Roati:

Terry Roati wrote to Dan Clough <=-

On May 02, 2022 07:33pm, Dan Clough wrote to Alan Ianson:

Yes.... you already said that, and I acknowledged that. Let me put it
a
different way. How many users do you think look at (or care about) a
MSGID? Or the date, really? What matters in a message is the
*CONTENT*
of the message. The body of the message. If *THAT* is exactly the
same
as a previous message, why would we want to see it again?

Echo Rules.

Right. So, if the rules haven't changed, why would I need to see them again?

Ward already explained it, ball is in your court.

Terry


... Platinum Xpress & Wildcat!..... Nice!!!!
--- Platinum Xpress/Win/WINServer v7.0
* Origin: The File Bank BBS! https://tfb-bbs.org (3:712/1321)

August Abolins wrote to Dan Clough <=-

Echo Rules.

Right. So, if the rules haven't changed, why would I need
to see them again?

Somebody else entering the echo for the first time might.

Well, that's a good point, that I hadn't considered. Thanks for that
input.



... If it weren't for Edison we'd be using computers by candlelight
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Hello Ward!

02 May 22 18:55, you wrote to Dan Clough:

Well I have good intentions (yeah, I know) of doing that, but
finding anything suitable as content is challenging.

* A recipe for Pizzagna ...

Please elaborate..!

Regards
Fermin


... TAGLINE: A line that does the work of many (lines) !.
--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: USS Ferminator - Unteraegeri, Switzerland (2:301/123)

Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.

Surely there must be some sections that fit your taste? Not all sections are "available" to all, but at least some of them are:

section foo Food for Thought
section gla Inside
section hd Headline News
section ed Editorial
section let Letters to the Editor
section top Top Stories
section art General Articles
section ap Adam's Column - Adam Park
section fts FTSC Information
section ftc Getting Fidonet Technical
section css From the *Cs
section reg Fidonet Regional News
section net Fidonet Net News
section reb Rebuttals to Previous Articles
section cmt Comments on Previous Articles
section dep Departing sysops
section bf Editor's Corner
section rec Fidonet's International Kitchen
section gue Guest Editorial
section www Ward's Wondering Ways
section cur Fidonet Current Events
section inv Fidonet Interviews
section rev Fidonet Software Reviews
section web Fidonet Web Page Reviews
section not Fidonet Notices
section qst Question of the week
section ans Answers of the week
section ls Lee's Puzzle Corner - Lee Lofaso
section cor Corrections & Retractions
section hfv Humour in a Fido Vein
section cmx Comix in Ascii
section poe Poet's Corner
section jok Clean Humour & Jokes
section bof Best of Fidonet
section ip6 List of Fidonet IPv6 nodes
section jam JamNNTPd Servers List
section ads Fidonet Classified Ads
section asc Fidonews Public-Key
section col Fidonet by Internet
section sof Fidonews's Fidonet Software Listing
section ca Calendar
section spi Special Interest
section mas Fidonews Information
section clz The Clutz!




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Bj”rn Felten wrote to Dan Clough <=-

Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.

Surely there must be some sections that fit your taste? Not
all sections are "available" to all, but at least some of them
are:

section foo Food for Thought

<SNIP>

Interesting list... I'll ponder it some more, thanks.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.15-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Hello Alan!

02 May 22 16:11, you wrote to Dan Clough:

Nope, in this case it is SBBSecho's dupe detection that sucks.

These messages being trapped as dupes by SBBSecho are not dupes. They
have a different date stamp and MSGID.

This is a long standing issue with SBBSecho's dupe detection that has
been reported but for whatever reason is not considered important and
so has never been fixed.

My SBBSecho worked just fine. I received all six messages through SBBSecho, which created a packet with all six messages in it for this "Road Node," which uses the Husky package along with Golded+.

SBBSecho seems just fine to me. <shrug>

73 de W6RAY Ray Quinn
Visalia, CA DM06II
Ham Shack Hotline 4655

--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: Ray's Road Node | Somewhere in California. (1:214/23)

My SBBSecho worked just fine.

What do you mean by "just fine".

I received all six messages through SBBSecho,

I recieved 7 messages along with the echo rules.

which created a packet with all six messages in it for this "Road Node," which uses the Husky package along with Golded+.

If you disable dupe checking SBBSecho will pass all traffic regardless of dupes since it doesn't check for them.

SBBSecho seems just fine to me. <shrug>

SBBSecho does seem to be just fine. It's dupe handling could be better.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: FidoNews 39:18 [00/06]: The Front Page
By: Alan Ianson to Ray Quinn on Sun May 08 2022 01:44 pm

SBBSecho does seem to be just fine. It's dupe handling could be better.

In what way? SBBSecho rejects messages in the same message area with duplicate Message-IDs, always, and optionally, duplicate body text. What could be better?
--
digital man (rob)

Sling Blade quote #16:
Karl Childers (to Doyle, re: lawn mower blade): I aim to kill you with it. Mmm. Norco, CA WX: 69.5øF, 51.0% humidity, 6 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

SBBSecho does seem to be just fine. It's dupe handling could be better.

In what way? SBBSecho rejects messages in the same message area with duplicate Message-IDs, always, and optionally, duplicate body text. What could be better?

<my opinion>

SBBSecho does a good job checking for Message-IDs. However, not all messages contain a Message-ID so we need dupelicate body checking also. SBBSecho does an excellent job checking for dupelicate message bodies.

It would be a good thing when checking the body (or Message-IDs) and if a match is found to check the date of the message as well to see if it is a new message as well in spite of the fact the message body is the same.

There are a few cases where "new" messages arrive that are caught as dupes and discarded because the message body hasn't changed. Area rules posts and BBS ads and other automated posts.

I couldn't really care less about BBS ads but new posts (even when the message body hasn't changed) should be tossed like any other new message.

</my opinion>

I am not a programmer and my view of all this is completely non technical.

While I may have seen a message myself others on the BBS or linked nodes (who come and go) may not have. This is why this issue is important to me.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: FidoNews 39:18 [00/06]: The Front Page
By: Alan Ianson to Rob Swindell on Sun Oct 23 2022 06:16 pm

SBBSecho does seem to be just fine. It's dupe handling could be better.

In what way? SBBSecho rejects messages in the same message area with duplicate Message-IDs, always, and optionally, duplicate body text. What could be better?

<my opinion>

SBBSecho does a good job checking for Message-IDs. However, not all messages contain a Message-ID so we need dupelicate body checking also. SBBSecho does an excellent job checking for dupelicate message bodies.

It would be a good thing when checking the body (or Message-IDs) and if a match is found to check the date of the message as well to see if it is a new message as well in spite of the fact the message body is the same.

There are a few cases where "new" messages arrive that are caught as dupes and discarded because the message body hasn't changed. Area rules posts and BBS ads and other automated posts.

I couldn't really care less about BBS ads but new posts (even when the message body hasn't changed) should be tossed like any other new message.

</my opinion>

I am not a programmer and my view of all this is completely non technical.

While I may have seen a message myself others on the BBS or linked nodes (who come and go) may not have. This is why this issue is important to me.

All Synchronet sysops have the option of disabling duplicate message body checking on a per-area basis (e.g. too allow identical message rules to be posted over and over again). So the control is in the hands of the sysop.
--
digital man (rob)

Breaking Bad quote #26:
Your commercials suck ass. I've seen better acting in an epileptic whorehouse. Norco, CA WX: 60.5øF, 76.0% humidity, 7 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

All Synchronet sysops have the option of disabling duplicate message body checking on a per-area basis (e.g. too allow identical message rules to be posted over and over again). So the control is in the hands of the sysop.

I don't want to disable duplicate message body detection, that would be ugly.

I'm not saying that posting rules (or anything else) over and over again is good but the rules need to be posted.

The rules for this area are posted monthly but are not going to be imported by a synchronet BBS (depending on dupe checking settings) or sent to linked nodes.

When a duplicate message body is detected checking also the posting date and/or MSGID would pass the message.

It's not an issue I care to press you on, so I'll stop there.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: FidoNews 39:18 [00/06]: The Front Page
By: Alan Ianson to Rob Swindell on Sun Oct 23 2022 09:59 pm

All Synchronet sysops have the option of disabling duplicate message body checking on a per-area basis (e.g. too allow identical message rules to be posted over and over again). So the control is in the hands of the sysop.

I don't want to disable duplicate message body detection, that would be ugly.

I'm not saying that posting rules (or anything else) over and over again is good but the rules need to be posted.

The rules for this area are posted monthly but are not going to be imported by a synchronet BBS (depending on dupe checking settings) or sent to linked nodes.

When a duplicate message body is detected checking also the posting date and/or MSGID would pass the message.

It's not an issue I care to press you on, so I'll stop there.

I'm still trying to understand what it is you're suggesting. It sounds to me like you're saying that messages with duplicate body text should only be rejected if the Message-ID (and date/time stamp?) are *also* duplicates. But if a system (e.g. SBBSecho) is already checking for and rejecting messages with duplicate Message-IDs, what's the point of also checking for duplicate message body text that is only rejected if the Message-ID is *also* a duplicate? In that case, checking for duplicate Message-IDs alone is all that is needed.
--
digital man (rob)

This Is Spinal Tap quote #16:
David St. Hubbins: I believe virtually everything I read...
Norco, CA WX: 69.9øF, 16.0% humidity, 7 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I'm still trying to understand what it is you're suggesting. It sounds to me like you're saying that messages with duplicate body text should only be rejected if the Message-ID (and date/time stamp?) are *also* duplicates. But if a system (e.g. SBBSecho) is already checking for and rejecting messages with duplicate Message-IDs, what's the point of also checking for duplicate message body text that is only rejected if the Message-ID is *also* a duplicate? In that case, checking for duplicate Message-IDs alone is all
that is needed.

Checking for dupelicate message bodies is needed when no Message-ID is present.

In a perfect world checking for Message-ID would/should/could be enough, but I think there are still messages without them.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: FidoNews 39:18 [00/06]: The Front Page
By: Alan Ianson to Rob Swindell on Mon Oct 24 2022 10:10 pm

I'm still trying to understand what it is you're suggesting. It sounds to me like you're saying that messages with duplicate body text should only be rejected if the Message-ID (and date/time stamp?) are *also* duplicates. But if a system (e.g. SBBSecho) is already checking for and rejecting messages with duplicate Message-IDs, what's the point of also checking for duplicate message body text that is only rejected if the Message-ID is *also* a duplicate? In that case, checking for duplicate Message-IDs alone is all
that is needed.

Checking for dupelicate message bodies is needed when no Message-ID is present.

In a perfect world checking for Message-ID would/should/could be enough, but I think there are still messages without them.

Okay, I now understand what you're suggesting. Thanks.
--
digital man (rob)

This Is Spinal Tap quote #10:
Dozens of people spontaneously combust each year... just not widely reported. Norco, CA WX: 62.1øF, 33.0% humidity, 2 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)