@MSGID: 1:3828/7.0 bf9b4871
@REPLY: 1:229/426 E268D52C
@CHRS: IBMPC 2
On Fri Nov-23-2018 17:14, Nick Andre (1:229/426) wrote to Ward
Dossche:
On 23 Nov 18 19:22:21, Ward Dossche said the following to Nick
Andre:
@EEN-BY: 15/2 57/0 123/1970 153/250 757 229/107 275 426 728 240/5832 @EEN-BY: 249/317 400 261/38 267/800 280/464 292/854 317/2 3 322/757 @EEN-BY: 342/200 393/68 396/45 633/0 267 280 281 412 509 712/132 620 @EEN-BY: 712/848 770/0 1 100 340 772/0 1 500 3828/7
@ATH: 3828/7 229/426 393/68 770/1 712/848 633/280 229/426 3828/7
@EEN-BY: 15/2 57/0 123/1970 153/250 757 229/107 275 426 728 240/5832 RN>RN> @EEN-BY: 249/317 400 261/38 267/800 280/464 292/854 317/2 3 322/757 RN>RN> @EEN-BY: 342/200 393/68 396/45 633/0 267 280 281 412 509 712/132 620 RN>RN> @EEN-BY: 712/848 770/0 1 100 340 772/0 1 500 3828/7
@ATH: 3828/7 229/426 393/68 770/1 712/848 633/280 229/426 3828/7
@ATH: 3828/7 229/426 393/68 770/1 712/848 633/280 229/426 3828/7
@ATH: 3828/7 229/426 393/68 770/1 712/848 633/280 229/426 3828/7
Besides the seen-by stripping... The fact that it passes 229/426 twice with being detected as a dupe the second time.
@MSGID: 2:292/854 0c353f42
@REPLY: 1:3828/7.0 bfa59cd0
People using crappy software? That's more and more the case these days
...
And hard-coded seen-by stripping of course in some cases ...
@TID: FMail-lnx64 2.1.0.18-B20170815
@RFC-X-No-Archive: Yes
@TZUTC: 0100
@CHRS: UTF-8 2
@PID: GED+LNX 1.1.5-b20161221
@MSGID: 2:280/464 5bfa93a5
@REPLY: 1:3828/7.0 bfa59cd0
On 2018-11-25 03:10:00, you wrote to All:
@ATH: 3828/7 229/426 393/68 770/1 712/848 633/280 229/426 3828/7
Besides the seen-by stripping... The fact that it passes 229/426 twice without being detected as a dupe the second time.
Bye, Wilfred.
--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)
There is a good reason for that, but if you're trying to trash
D'Bridge publicly, you did a good job, which says a lot about you.
On the path you showed, there is a fastecho system on a Zone border,
which has hardcoded seen-by stripping. That's been known for ages, and nothing to worry about. Dupe detection takes care of it most of the time.
@TID: FMail-lnx64 2.1.0.18-B20170815
@RFC-X-No-Archive: Yes
@TZUTC: 0100
@CHRS: UTF-8 2
@PID: GED+LNX 1.1.5-b20161221
@MSGID: 2:280/464 5bfc1544
@REPLY: 1:3828/7 05202c52
Hi Roger,
On 2018-11-26 04:21:18, you wrote to me:
There is a good reason for that, but if you're trying to trash
D'Bridge publicly, you did a good job, which says a lot about you.
You asked the open question, I wrote what I noticed, and didn't even mention d'Bridge.
And Ward was quick with his trashing of other software: "People using crappy software? That's more and more the case these days" ?
There's probably a good reason for that too...
On the path you showed, there is a fastecho system on a Zone border,
which has hardcoded seen-by stripping. That's been known for ages, and nothing to worry about. Dupe detection takes care of it most of the time.
You asked the open question, I wrote what I noticed, and didn't even
mention d'Bridge.
A man on a flying horse could read the path line.
But you had to point out 229/426 as if it was his fault without
mentioning all the other stops in-between.
On the path you showed, there is a fastecho system on a Zone border,
which has hardcoded seen-by stripping. That's been known for ages,
and nothing to worry about. Dupe detection takes care of it most of
the time.
Well then, you know more than I do because I have no idea what most others in the path are using. However, I an interested to know how you know.
On the path you showed, there is a fastecho system on a Zone border,
which has hardcoded seen-by stripping. That's been known for ages, and nothing to worry about. Dupe detection takes care of it most of the time.
In any case FastEcho acts as an inbound-zone-gate, which means
SEEN-BYs will be stripped when processing EchoMail coming from another zone.
[snip]
So my system may well be the culprit?
But it was certainly not intentional nor to my knowledge has even been
an issue prior.
I'm happy to work with folks to try and resolve the problem.
So my system may well be the culprit? But it was certainly not
intentional
nor to my knowledge has even been an issue prior. I'm happy to work with folks to try and resolve the problem.
I'm happy to work with folks to try and resolve the problem.
If fastecho is still maintained, maybe inbound stripping can be made optional. Otherwise you have the choice of changing tosser. (I can recommend one ;)) ...
Ever since some years ago all netnumbers in Fidonet throughout all the zones became unique seen-by stripping is "not done" anymore and
definitely a nono in the Fidoweb.
If it can be disabled, then I suggest you do so and also for any other echo you are hubbing.
Here in NZ there are planes and they fly daily... there I'm on topic now
:)
I should chat with you in Fmail then :)
I'm going to contact the author as a starting point to see what can be done if anything.
At LAX-airport a while ago, I saw an Air NewZealand 777 ... it read: "The airline of Middle Earth" ... 8-)
Ever since some years ago all netnumbers in Fidonet throughout all
the zones became unique seen-by stripping is "not done" anymore and
definitely a nono in the Fidoweb.
I can't be the only chap running this software then that's in the same boat? Yipes!
I think one of the nodes of Tommi Koivula runs or used to run fastecho, where the same problem was noticed in the past. But he might have circumvented the problem by only have it contact his Host node which runs Husky, so it no longer communicates with nodes out of zone...
On 11/29/18, Ward Dossche pondered and said...
Ever since some years ago all netnumbers in Fidonet throughout all th zones became unique seen-by stripping is "not done" anymore and definitely a nono in the Fidoweb.
If it can be disabled, then I suggest you do so and also for any othe echo you are hubbing.
Not sure but am contacting the author. Suggestions of other tossers to look into are welcome. We should move that to another echo I guess?
In other news. I contacted the FastEcho author asking if it were
possible
to make a change to the hard coded zone-gate feature? He kindly replied
but indicated it would be highly unlikely :(
Sysop: | Nelgin |
---|---|
Location: | Plano, TX |
Users: | 513 |
Nodes: | 10 (1 / 9) |
Uptime: | 13:53:38 |
Calls: | 8,287 |
Files: | 15,519 |
Messages: | 928,545 |