I've studied seenbys of echomail that is coming from a zone 1 node. Seenbys are stored into the jam base ok. But it seems that Fastecho is tinying seenbys of outgoing messages whatever i try to set up.
Is there some kind of a hardcoded interzone seenby stripping feature, or am I missing something?
Is there some kind of a hardcoded interzone seenby stripping
feature, or am I missing something?
It's more likely that the 'Tiny SEENBYS' option is set for one or
a number of echoes, in FeSetup. Ordinarily it should be left as
"N" for each.
I've studied seenbys of echomail that is coming from a zone 1
node. Seenbys are stored into the jam base ok. But it seems that
Fastecho is tinying seenbys of outgoing messages whatever i try
to set up.
Is there some kind of a hardcoded interzone seenby stripping
feature, or am I missing something?
It's more likely that the 'Tiny SEENBYS' option is set for one or a
number of echoes, in FeSetup. Ordinarily it should be left as "N" for each.
Is there some kind of a hardcoded interzone seenby stripping
feature, or am I missing something?
It's more likely that the 'Tiny SEENBYS' option is set for one or
a number of echoes, in FeSetup. Ordinarily it should be left as
"N" for each.
spot on! also check the group defaults to ensure that areas assigned
to a group don't get tiny sb set to yes...
Is there some kind of a hardcoded interzone seenby stripping
feature, or am I missing something?
It's more likely that the 'Tiny SEENBYS' option is set for one or
a number of echoes, in FeSetup. Ordinarily it should be left as
"N" for each.
spot on! also check the group defaults to ensure that areas assigned
to a group don't get tiny sb set to yes...
And another thing: if the message comes from Zone2 node, seenby's
will not be tinyed, but if the message comes from Zone1 node,
seenby's will be tinyed.
In both cases full seenbys are stored in jam base. Only outbound
seenbys are tinyed when coming from different zone.
It's more likely that the 'Tiny SEENBYS' option is set for one or a
number of echoes, in FeSetup. Ordinarily it should be left as "N"
for each.
Nope, "tiny seenby" is _not_ set for any echoes or groups. Wouldn't you guys think that I checked that first? ;-)
no?And another thing: if the message comes from Zone2 node, seenby's
will not be tinyed, but if the message comes from Zone1 node,
seenby's will be tinyed.
right... because you are in Z2, messages arriving from Z2 nodes will
have the seenbys...
In both cases full seenbys are stored in jam base. Only outbound
seenbys are tinyed when coming from different zone.
you've double checked to ensure that the echo area is set for tiny sb =
it may be a bug but we can't tell for sure yet...
Also, have a real *close* look at the 'tiny' setting... make sure it
isn't a "H" where you're expecting a "N". I can't recall if it's
possible for that one; it might only be an option for the (main)
'Keep' setting.[shrug]
it may be a bug but we can't tell for sure yet...
That may be a possibility but FE is a Z2 product. Tada! That sort of
bug should have been squashed aeons ago.
Packet from: 3:640/384
Packet to : 2:221/1
--- D'Bridge 3.99
* Origin: Many Glacier -- Protect - Preserve - Conserve (2:292/854) SEEN-BY: 221/1 280/5555 640/305 384 1384 690/682
PATH: 292/854 280/5555 640/384
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
SEEN-BY: 221/1 280/5555 640/305 384 1384 690/682
PATH: 249/303 280/464 5555 640/384
--- D'Bridge 3.99
* Origin: Many Glacier -- Protect - Preserve - Conserve (2:292/854)
SEEN-BY: 221/1 280/5555 640/305 384 1384 690/682
PATH: 292/854 280/5555 640/384
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
SEEN-BY: 221/1 280/5555 640/305 384 1384 690/682
PATH: 249/303 280/464 5555 640/384
Both of these messages have address of origin on PATH line, but not on SEENBY line.
the systems having already received the message. In this waywith many participants the number of seen-by lines can be
a message is never sent to a system twice. In a conference
I have received also some .PKT's from Andrew's FE, but I didn't find any failures yet.
You could ask Bj%rn to see if I strip seenbys when I send him
stuff from z1
i'll let tommi do that... but it also depends on bj's system saving
the PKTs before they are tossed and mangled by whatever tosser he is
using over there... my main system saves both all inbound and all
outbound PKTs for 30 days... it took a real hit the other day with the full rescan of all areas for this point system... in one batch there
was over 305Meg of raw PKTs totaling over 135000 messages ;) i don't
know about anyone else's system(s) saving PKTs, though...
Thanks to Matt, I found this from the docs:FEOPT=ZONEGATE
======================================================================= 8.7.18 - ZONEGATE flag
When your system acts as outbound zonegate you may need to strip all the SEEN-BY information present in your echomail for all messages addressed out-of-zone. FastEcho is capable to do that simply by enabling this feature (which is disabled by default). This can be done
by using the flag ZONEGATE in FEOPT. In any case FastEcho acts as an inbound-zone-gate, which means SEEN-BYs will be stripped when processing EchoMail coming from another zone. =======================================================================
So, if I understand this last sentence correctly, setting of
will _not_ disable stripping.
So, if I understand this last sentence correctly, setting of
FEOPT=ZONEGATE will _not_ disable stripping.
correct... inbound from another zone will always have seenbys
stripped... the FEOPT ZONEGATE keyword is only for outbound from you
to another zone and it will cause seenbys to be stripped...
SEEN-BY: 109/500 116/116 123/5 52 57 140 400 500 789 124/5013 5014
140/1
SEEN-BY: 154/0 10 701 203/0 242 221/1 226/600 227/101 201 229/310 426 230/0
SEEN-BY: 249/303 261/38 266/404 320/119 322/759 342/11 806 640/384
3634/12
SEEN-BY: 3634/22 24 27 50
@PATH: 3634/12 123/500 154/10 203/0
@TID: FastEcho 1.46.1 15059
So, if I understand this last sentence correctly, setting of
FEOPT=ZONEGATE will _not_ disable stripping.
correct... inbound from another zone will always have seenbys
stripped... the FEOPT ZONEGATE keyword is only for outbound from
you to another zone and it will cause seenbys to be stripped...
So, why do I see all the SEEN-BYs here?
--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
SEEN-BY: 221/0 1 6 360 240/1120 320/119 640/384
@PATH: 640/384 221/1
So, why do I see all the SEEN-BYs here?
Because seen-by's are stored into your msgbase, but stripped from the messages your system sends out.
This is exactly what I found out.
pop<[ding!]...180turn... >pop<[ding!]...180turn...
pop<[ding!]...180turn...
So, if I understand this last sentence correctly, setting of
FEOPT=ZONEGATE will _not_ disable stripping.
correct... inbound from another zone will always have seenbys
stripped... the FEOPT ZONEGATE keyword is only for outbound from you
to another zone and it will cause seenbys to be stripped...
So, why do I see all the SEEN-BYs here?
So, why do I see all the SEEN-BYs here?
from the looks of things, that's because it arrived at the system you
read it on without crossing a zone boundry jumped by FASTECHO... in
other words, some other tosser tossed the post across at least one
zone...
Blerk! Why do I now feel like an amusement park shooting gallerytarget...
pop<[ding!]...180turn... >pop<[ding!]...180turn...
pop<[ding!]...180turn...
Yikes! Not nice. And, it's taken 21 years for this little gem of knowledge to bubble to the surface of my awareness. I guess I'll have to turnabout and sever all out-of-zone links I have... :(
pop<[ding!]...180turn... >pop<[ding!]...180turn...
pop<[ding!]...180turn...
Yikes! Not nice. And, it's taken 21 years for this little gem of knowledge to bubble to the surface of my awareness. I guess I'll have
to turnabout and sever all out-of-zone links I have... :(
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,090 |
Nodes: | 15 (0 / 15) |
Uptime: | 61:09:34 |
Calls: | 232,716 |
Calls today: | 3 |
Files: | 60,050 |
D/L today: |
72 files (57,454K bytes) |
Messages: | 299,380 |