FidoNews Robot wrote to All <=-
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.
...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.
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.
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?
Ward Dossche wrote to Dan Clough <=-
The F I D O N E W S Volume 39, Number 18 02 May 2022Same 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 ...
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.
Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.
Then why send out an empty/duplicate issue?
You want content? Provide it ...
You already said that.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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*?
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".
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?
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?
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.
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.
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.
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?
IIRC, you can turn off "content" dupe-detection, but you cannot turn off MSGID dupe detection...
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.
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, agreed on all that. If the content hasn't changed, why do I need
to see it again?
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?
Yes, and that is *ALL* that is different. The *content* is exactly the same as the previous version, and therefore detected as a dupe.
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.
Echo Rules.
Right. So, if the rules haven't changed, why would I need
to see them again?
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?
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 I have good intentions (yeah, I know) of doing that, but
finding anything suitable as content is challenging.
* A recipe for Pizzagna ...
Well I have good intentions (yeah, I know) of doing that, but finding anything suitable as content is challenging.
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
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>
SBBSecho does seem to be just fine. It's dupe handling could be better.
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?
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.
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.
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.
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 235:53:38 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,128 |
| D/L today: |
49 files (7,136K bytes) |
| Messages: | 275,445 |