I've asked one of the Nodes that feeds off me to send a NetMail to me to see wh
t happens.
@TZUTC: -0500
@MSGID: 53.tub@1:2320/105 242d5066
@REPLY: 1:396/45.0 fc6a8011
@PID: Synchronet 3.18a-Linux May 24 2020 GCC 7.5.0
@TID: SBBSecho 3.11-Linux r3.173 May 24 2020 GCC 7.5.0
@CHRS: ASCII 1
I've asked one of the Nodes that feeds off me to send a NetMail to me
to see what happens.
Based on some of the other messages here, I would ask that node
what they are using as the PacketType setting for your node in
their sbbsecho.ini file. Maybe they need to change that to
something else?
Squish *can* use MSGID to do dupe checking, but it doesn't have to.
Check the DupeCheck keyword in Squish.Cfg, does it say MSGID,
HEADER, or both? You could try using only HEADER to see what
happens.
Okay, I've changed the DupeCheck line to read HEADER.
I've asked one of the Nodes that feeds off me to send a NetMail to
me to see what happens.
I *seriously* doubt that Squish is at fault.
Unfortunately, Fred, that had no effect whatsoever. It may be time for meto
just hang it up. I can't afford the time to completely redesign the system to accomodate the Synchronet way of doing things...
And they're so
predominant now-a-days that almost 2/3 of the nodes feeding off me run Synchronet. Mr. Swindell says it's Squish's fault and I strongly disagree with him, but there's not much I can do about it. It's apparent in his opinion that he's right and Squish is wrong, despite the lenght of time its been around doing its job without problem.
Based on some of the other messages here, I would ask that node
what they are using as the PacketType setting for your node in
their sbbsecho.ini file. Maybe they need to change that to
something else?
It seems that everyone is using the 2+ type packet. As you can see
from the quoted message kludge lines above, the @MSGID line, which includes the extraneous characts worked fine since this this EchoMail unlike NetMail where it plays hell with Squish. There's bound to be something that can be addressed with regards to that; I *seriously*
doubt that Squish is at fault.
For fixing the problem we have to know the real cause of the problem.
Have you inspected the raw packets before tossing?
As I already told you, Synchronet (actually, SBBSecho) only recently started ev
n adding MSGIDs to FTN NetMail messages. "that line" didn't even exist in Synch
onet-generated FTN NetMail messages before June of this year.
As I already told you, Synchronet (actually, SBBSecho) only recently started ev
n adding MSGIDs to FTN NetMail messages. "that line" didn't even exist in Synch
onet-generated FTN NetMail messages before June of this year.
Do other tossers add MSGIDs to netmail messages?
Do other tossers add MSGIDs to netmail messages?
Hi Dumas,
On 2020-12-03 15:42:00, you wrote to ROB SWINDELL:
Do other tossers add MSGIDs to netmail messages?
It's usually the message editors that do that, the tossers shouldn't add this, unless they are the ones generating some auto created message.
theDo other tossers add MSGIDs to netmail messages?
It's usually the message editors that do that, the tossers shouldn't add
this, unless they are the ones generating some auto created message.
Or the BBS software. As is with Synchronet, the message editors are just simple text editors and don't really know anything about FidoNet "control paragraphs" (kludge lines). So Synchronet adds the FTN message-ID when
message is saved by the user, regardless of what editor was used to write the text.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 409 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 63:51:40 |
| Calls: | 8,575 |
| Calls today: | 5 |
| Files: | 13,225 |
| Messages: | 5,930,600 |