Hi All.

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?

'Tommi

---
* Origin: *** JamNNTPd @ nntp://fidonews.mine.nu *** (2:221/6)

Hi! Tommi,

On 9/05/2015 4:49 PM, you wrote:

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.

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/1384)

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...

)\/(ark
member, FastEcho Beta Team


* Origin: (1:3634/12)

09 May 15 17:13, you wrote to me:

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.

Nope, "tiny seenby" is _not_ set for any echoes or groups. Wouldn't you guys think that I checked that first? ;-)

'Tommi

---
* Origin: *** JamNNTPd @ nntp://fidonews.mine.nu *** (2:221/6)

09 May 15 10:14, you wrote to Paul Quinn:

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.

'Tommi

---
* Origin: *** JamNNTPd @ nntp://fidonews.mine.nu *** (2:221/6)

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.

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 = no?

it may be a bug but we can't tell for sure yet...

)\/(ark
member, FastEcho Beta Team


* Origin: (1:3634/12)

Hi! Tommi,

On 10/05/2015 2:32 AM, you wrote:

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? ;-)

That thought did cross my mind. Then I gave myself a smack! for trying to out-think you (myself). ;)

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/1384)

Hi! Tommi,

On 9/05/2015 5:42 PM, mark lewis wrote to you:

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 =

no?

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.

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/1384)

10 May 15 10:52, Paul Quinn wrote to Tommi Koivula:

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.

I'm aware of the (H)ide option but it is available only for "Keep SEEN-BY:" setting.

If it is a bug, it may not be ever fixed... But we can live with it.

'Tommi

FastEcho/2 1.46.1 FAST! Electronic Mail Processor
Copyright (c) 1991-'97 by Software Technik Burchhardt
Compiled on Apr 3 1997, 20:37:02 All rights reserved

---
* Origin: ========================================>>>> (2:221/1)

Hi Paul & All,

Ok, I have now examined some .PKT's that came from Paul's FE to me. I
saved copies of incoming .PKT's before any processing.

First quick results:

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

Both of these messages have address of origin on PATH line, but not on
SEENBY line.

I have received also some .PKT's from Andrew's FE, but I didn't find any failures yet.

'Tommi

.... to be continued ...

--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

28 May 15 02:57, you wrote to Paul Quinn:

--- 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.

right... some software adds their address to the seenbys and some doesn't...

here's what FTS-0004 has to say about seenbys...

[quote]
4. Seen-by Lines

There can be many seen-by lines at the end of Conference
Mail messages, and they are the real "meat" of the control
information. They are used to determine the systems to
receive the exported messages. The format of the line is:

SEEN-BY: 132/101 113 136/601 1014/1

The net/node numbers correspond to the net/node numbers of

the systems having already received the message. In this way
a message is never sent to a system twice. In a conference

with many participants the number of seen-by lines can be
very large. This line is added if it is not already a part
of the message, or added to if it already exists, each time
a message is exported to other systems. This is a REQUIRED
field, and Conference Mail will not function correctly if
this field is not put in place by other Echomail compatible
programs.
[/quote]

note the two hilited lines... strict reading of that line might suggest that each system that gets a message add their address to the seenbys... another view is like that used today where the sending system adds the addresses of the
systems it is sending the message to... nothing is really said about what an originating system should do with its address and the seenbys... on one hand, it makes sense to add it, on the other, it is in the origin and the first in the path so it should be apparent that it saw it already...

then think about what happens when a point originates an echomail message... take this one for example ;)

I have received also some .PKT's from Andrew's FE, but I didn't find any failures yet.

that's a good thing :)

)\/(ark

... That old thing? It is a pretty good work of fiction, though!
---
* Origin: (1:3634/12.73)

Hello mark.

27 May 15 14:08, you wrote to me:

--- 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.

right... some software adds their address to the seenbys and some doesn't...

You're right about different software.

If you look at the second example of mine, you will notice that 249/303 280/464
are missing from seenbys.

Is it so that Paul's FE has stripped them before sending to 2:221/1?

'Tommi

--- GoldED+/W32-MINGW 1.1.5-b20120229
* Origin: ================================= (2:221/360.8110)

28 May 15 12:43, you wrote to me:

Hello mark.

27 May 15 14:08, you wrote to me:

--- 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.

right... some software adds their address to the seenbys and some
doesn't...

You're right about different software.

If you look at the second example of mine, you will notice that 249/303 280/464 are missing from seenbys.

yes, i see that now...

Is it so that Paul's FE has stripped them before sending to 2:221/1?

might be but it might be a quirk with sbbsecho and what it does with seenbys when it sends to a system in a different zone... i don't know as i've not worked with sbbsecho in that capacity...

)\/(ark

... Program abort: Close all that you have worked on. You ask far too much.
---
* Origin: (1:3634/12.73)

On 05-28-15 11:46, mark lewis wrote to Tommi Koivula <=-

28 May 15 12:43, you wrote to me:

Hello mark.

27 May 15 14:08, you wrote to me:

--- 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.

right... some software adds their address to the seenbys and some
doesn't...

You're right about different software.

If you look at the second example of mine, you will notice that 249/303 280/464 are missing from seenbys.

yes, i see that now...

Is it so that Paul's FE has stripped them before sending to 2:221/1?

might be but it might be a quirk with sbbsecho and what it does with seenbys when it sends to a system in a different zone... i don't know
as i've not worked with sbbsecho in that capacity...

You could ask Bj%rn to see if I strip seenbys when I send him stuff from z1


--

Bill

Telnet: tequilamockingbirdonline.net
Web: bbs.tequilamockingbirdonline.net
FTP: ftp.tequilamockingbirdonline.net:2121
IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
Radio: radio.tequilamockingbirdonline.net:8010/live


... Look Twice... Save a Life!! Motorcycles are Everywhere!!
=== MultiMail/Win32 v0.50
--- SBBSecho 2.27-Win32
* Origin: TequilaMockingbird Online - Toms River, NJ (1:266/404)

28 May 15 14:30, you wrote to me:

If you look at the second example of mine, you will notice that 249/303
280/464 are missing from seenbys.

yes, i see that now...

Is it so that Paul's FE has stripped them before sending to 2:221/1?

might be but it might be a quirk with sbbsecho and what it does with
seenbys when it sends to a system in a different zone... i don't know
as i've not worked with sbbsecho in that capacity...

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...

)\/(ark

... Even a blind pig stumbles across a truffle now and again.
---
* Origin: (1:3634/12.73)

Hello All,

Thanks to Matt, I found this from the docs:

=======================================================================
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 FEOPT=ZONEGATE will _not_ disable stripping.

'Tommi

---
* Origin: * RBB * Lake Ylo * Finland * (2:221/360)

09 Sep 15 19:13, you wrote to All:

Thanks to Matt, I found this from the docs:

======================================================================= 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

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...

)\/(ark

... Washington DC: Southern Efficiency, Northern Charm.
---
* Origin: (1:3634/12.73)

Hi! mark,

On 09 Sep 15 14:24, you wrote to Tommi Koivula:

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?

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

Inquiring minds, et al...

;)

Cheers,
Paul.

... Today's mighty oak is just yesterday's nut that held its ground.
--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

10 Sep 15 08:51, you wrote to mark lewis:

@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?

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.

--- 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

'Tommi

---
* Origin: *** JamNNTPd @ nntp://fidonews.mine.nu *** (2:221/6)

Hi! 'Tommi,

On 10/09/2015 1:03 PM, you wrote:

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.

Blerk! Why do I now feel like an amusement park shooting gallery target...

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... :(

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
* Origin: Paul's other Linux vBox - Maryborough, Qld, OZ (3:640/1384)

10 Sep 15 08:51, you wrote to me:

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?

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...


)\/(ark

... Oh my god, it's grotesque! Oh, and there's something in a jar.
---
* Origin: (1:3634/12.73)

Hi! mark,

On 09 Sep 15 20:10, you wrote to me:

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...

Ah, yes. Understood. Thanks, mark.

Cheers,
Paul.

... All stressed out and no one to choke.
--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

10 Sep 15 13:45, you wrote to Tommi Koivula:

Blerk! Why do I now feel like an amusement park shooting gallery

target...

i dunno...

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... :(

you could always use another tosser in front of fastecho if you cannot switch and absolutely need seenbys to be left alone... i'm not switching on my main system, though... it is running fastecho and i've not even looked at this seenby thing in relation to my non-Z1 connections... if i absolutely must keep seenbys everywhere, i'll do as above and use one of my other nodes as my feed...

)\/(ark

... You can't unsay a cruel or unkind word.
---
* Origin: (1:3634/12.73)

10 Sep 15 13:45, you wrote to me:

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... :(

Well I don't think the seen-by stripping is not so bad thing. Dupe detection still works pretty good.

'Tommi

---
* Origin: *** JamNNTPd @ nntp://fidonews.mine.nu *** (2:221/6)

Hi! mark,

On 11/09/2015 12:02 AM, you wrote:

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... :(

you could always use another tosser in front of fastecho if you cannot switch and absolutely need seenbys to be left alone... i'm not switching on my main system, though... it is running fastecho and i've not even looked at this seenby thing in relation to my non-Z1 connections... if i absolutely must keep seenbys everywhere, i'll do as above and use one of my other nodes as my feed...

Thanks for that. I feel better about it now. I can switch over to -this- other node interfacing with other zones, sometime soon. Just not too soon. ;)

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
* Origin: Paul's other Linux vBox - Maryborough, Qld, OZ (3:640/1384)

Hi! 'Tommi,

On 11/09/2015 2:04 AM, you wrote:

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... :(

Well I don't think the seen-by stripping is not so bad thing. Dupe detection still works pretty good.

I can fix the situation. Just not at this time. Thanks.

Cheers,
Paul.

--- Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
* Origin: Paul's other Linux vBox - Maryborough, Qld, OZ (3:640/1384)