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: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,150 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 34:11:59 |
| Calls: | 229,990 |
| Calls today: | 5 |
| Files: | 59,437 |
| D/L today: |
8 files (89,631K bytes) |
| Messages: | 291,628 |
| Posted today: | 2 |