Hi! Wilfred,

FMail/lnx is wonderful, Wilfred. Thank you for letting me try it out.

What was what I call 'Phase 1' testing ceased for me at about midday on Saturday. Test packets originated from -this- node as received from my current
peer linked Fidonet systems. They were shoved otherwise-untouched to my test system via binkD, and ingested by FMail.

With FMail, I have enjoyed seeing _full_ inter-zone SEENBY & PATH data in messages. These items form the singular function that's caused me to try FMail.

FMail was under rigorous supervision for about three weeks of 24/7 operation. I think there's about three Mb of logfiles with nary a glitch reported, IIRC.

It did turn up that weirdness with message sorting that I was later to find was
subject to what Uncle Google & Wikipedia tells me is the 'Observer effect'. After I reworked the data originating from FastEcho, whose packet size limits dated from the POTS days, all was well.

Interestingly, a couple of AreaMgr requests were replied to but the responses were not sent. I guess that could be the case with potential PING responses as
well. Is that normal? (On my main node [~/384] I would have a BATch file check for any *.Msg files in the netmail path, since the primary netmail area is usually empty, and would attempt a PACK if any such mails existed.) How do you recommend they be completed by FMail if it is the only configured netmail area?

The 'Phase 2' test occurred later on Saturday and lasted for about 10 seconds or less. :) It's premise was simply continuing function with a pre-existing messagebase, from that morning's backup from this node. I did allow the *.Msg,
HMB areas & dupe ID database to remain as they were. FMail cruised through the
test without even a grunt.

On Sunday I was surprised and pleased by the 'badmail' capability to detect old
mails... it found one! (It was a phurphy from region 18 IIRC, and was a re-badged old mail from NZ.) Did yours? ;-)

Now 'Phase 3'. I'm thinking of doing some sort of export SCANning of outbound mails. I think I need something further from you? Do you have something of a 32-bit flavour, please? :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Paul,

On 04 Sep 17 18:46, Paul Quinn wrote to Wilfred van Velzen:
about: "Trialing FMail/lnx status check-in":

FMail/lnx is wonderful, Wilfred. Thank you for letting me try it out.

Thank you for testing it! ;)

What was what I call 'Phase 1' testing ceased for me at about midday on Saturday. Test packets originated from -this- node as received from my current peer linked Fidonet systems. They were shoved otherwise-untouched to my test system via binkD, and ingested by FMail.

With FMail, I have enjoyed seeing _full_ inter-zone SEENBY & PATH data in messages. These items form the singular function that's caused me to try FMail.

FMail was under rigorous supervision for about three weeks of 24/7 operation. I think there's about three Mb of logfiles with nary a glitch reported, IIRC.

(I had to look up "nary" ;))

It did turn up that weirdness with message sorting that I was later to find was subject to what Uncle Google & Wikipedia tells me is the 'Observer effect'. After I reworked the data originating from FastEcho, whose packet size limits dated from the POTS days, all was well.

Interestingly, a couple of AreaMgr requests were replied to but the responses were not sent. I guess that could be the case with potential PING responses as well. Is that normal? (On my main node [~/384] I would have a BATch file check for any *.Msg files in the netmail path, since the primary netmail area is usually empty, and would attempt a PACK if any such mails existed.) How do you recommend they be completed by FMail if it is the only configured netmail area?

Do these mails have the 'Crash' flag set? Crash mail needs to be packed with "special" command line options:

.../fmail pack '*' '-c'

Where '*' can be replaced by any fidonet address, or match pattern, if you want
to just pack netmail for specific destinations. E.g. '3:640/*'.

And make sure to put the pattern between single quotes, otherwise your shell might expand it to filenames!

The 'Phase 2' test occurred later on Saturday and lasted for about 10 seconds or less. :) It's premise was simply continuing function with a pre-existing messagebase, from that morning's backup from this node. I did allow the *.Msg, HMB areas & dupe ID database to remain as they were. FMail cruised through the test without even a grunt.

On Sunday I was surprised and pleased by the 'badmail' capability to detect old mails... it found one! (It was a phurphy from region 18 IIRC, and was a re-badged old mail from NZ.) Did yours? ;-)

There was some regurgitated echomail originating from 1:15/0, partly in wrong areas. But none in my bad area, because none were older then my 60 day setting for old mail... And none in a NZ_* area...?

Now 'Phase 3'. I'm thinking of doing some sort of export SCANning of outbound mails. I think I need something further from you? Do you have something of a 32-bit flavour, please? :)

The fmail and ftools I gave you are 32-bit, so I don't understand?

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Wilfred,

On 09/04/2017 09:23 PM, you wrote:

FMail was under rigorous supervision for about three weeks of 24/7
operation. I think there's about three Mb of logfiles with nary a
glitch reported, IIRC.

(I had to look up "nary" ;))

So did I, once upon a time. ;-)

How do you recommend they be completed by FMail if
it is the only configured netmail area?

Do these mails have the 'Crash' flag set? Crash mail needs to be packed with "special" command line options:

Ah, yes they are. My fault, and they need not be. Thank you for the wake up on that.

18 IIRC, and was a re-badged old mail from NZ.) Did yours? ;-)

There was some regurgitated echomail originating from 1:15/0, partly in wrong areas. But none in my bad area, because none were older then my 60 day setting for old mail... And none in a NZ_* area...?

Yep, that was the one. The original post was from my friend's system in New Zealand (NZ).

Now 'Phase 3'. I'm thinking of doing some sort of export SCANning of
outbound mails. I think I need something further from you? Do
you have something of a 32-bit flavour, please? :)

The fmail and ftools I gave you are 32-bit, so I don't understand?

Ahmm... something about a fix relating to echomail.jam paths??

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Paul,

On 05 Sep 17 09:01, Paul Quinn wrote to Wilfred van Velzen:
about: "Trialing FMail/lnx status check-in":

Now 'Phase 3'. I'm thinking of doing some sort of export SCANning
of outbound mails. I think I need something further from you? Do
you have something of a 32-bit flavour, please? :)

The fmail and ftools I gave you are 32-bit, so I don't understand?

Ahmm... something about a fix relating to echomail.jam paths??

O, that one... ;)

It's already to long a go, to remember such little things and the exact chronology. ;)

I'll make a new version for you later tonight (tomorrow for you), or later this
week. If you don't hear from me in a couple of days, please remind me. ;)


Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Wilfred,

On 09/05/2017 04:37 PM, you wrote:

Ahmm... something about a fix relating to echomail.jam paths??

O, that one... ;)
It's already to long a go, to remember such little things and the exact chronology. ;)

Some people may say that I am a pedantic bastard. I like to think I'm just afflicted with a form of OCD.

I'll make a new version for you later tonight (tomorrow for you), or later this week. If you don't hear from me in a couple of days, please remind me. ;)

No problem. I have tobacco. Waiting without tobacco is an unbearable bore. :)

Thank you, kindly.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

On 09/05/17, Paul Quinn pondered and said...

partly in WvV> wrong areas. But none in my bad area, because none were older then my 60 WvV> day setting for old mail... And none in a NZ_* area...?

Yep, that was the one. The original post was from my friend's system in New Zealand (NZ).

Can I ask who? Just curious... if there was something amiss with traffic
coming out of over here I'd be happy to help solve it.

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

Hi! Paul,

On 09/05/2017 07:04 PM, you wrote:

Yep, that was the one. The original post was from my friend's
system in New Zealand (NZ).

Can I ask who? Just curious... if there was something amiss with traffic coming out of over here I'd be happy to help solve it.

Nothing amiss with your system(s), mate. Someone regurgitated an old post of yours in a file announcement echo using a 1:15/0 origin line over the top (really under) one of yours.

Lovely weather here. 5th day of spring & temp maxed at 30C! Summer may be warm-ish. ;-)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Paul,

On 2017-09-05 17:09:09, you wrote to me:

I'll make a new version for you later tonight (tomorrow for you), or
later this week. If you don't hear from me in a couple of days,
please remind me. ;)

No problem. I have tobacco. Waiting without tobacco is an unbearable bore. :)

http://www.vlzn.nl/fmail/files/FMail-lnx32-2.1.0.18-Beta20170905.zip

I just did a recompile, and didn't test anything, except starting it...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 09/06/2017 07:18 AM, you wrote:

I just did a recompile, and didn't test anything, except starting it...

Copy received. Thanks, muchly. Ooh, ooh... now I have to do something... oh, no...! (It complains as usual, on this old netbook[v2.6 Linux].) Gotta get out of bed... :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

On 09/05/17, Paul Quinn pondered and said...

Nothing amiss with your system(s), mate. Someone regurgitated an old
post of yours in a file announcement echo using a 1:15/0 origin line
over the top (really under) one of yours.

Aha all good cheers Paul.

Lovely weather here. 5th day of spring & temp maxed at 30C! Summer may be warm-ish. ;-)

Wow, best I got to was 12C today :(

Take care

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

Hi Paul,

On 2017-09-06 08:15:32, you wrote to me:

I just did a recompile, and didn't test anything, except starting
it...

Copy received. Thanks, muchly. Ooh, ooh... now I have to do something... oh, no...! (It complains as usual, on this old netbook[v2.6 Linux].) Gotta get out of bed... :)

I'll stay tuned! ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Wed, 06 Sep 17, you wrote to me:

Copy received. Thanks, muchly. Ooh, ooh... now I
have to do something... oh, no...! (It complains as
usual, on this old netbook[v2.6 Linux].) Gotta get
out of bed... :)

I'll stay tuned! ;)

Kkaaahhhh... I was hoping to sneak back into bed... ;-)

FMail has been tossing like a trooper all day with nary a belch, even. I've updated some scripts (wrappers for cron & scan/pack) and the GoldEd config just
15 minutes ago and will test same tomorrow. If all goes according to plan, real life wise, I'll post a quickie report about 0400 your time.

Relax. I am.

Cheers,
Paul.

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

Hi! Wilfred,

In a msg of Wed, 06 Sep 17, Paul Quinn wrote to you:

Ooh, ooh... now I have to do something... oh, no...!

I'll stay tuned! ;)

Well, I managed to screw up even some of the simplest things but eventually got
something like a normal echomail scan out...

GoldEd created the expected echomail.jam file, containing...

--- 8< ---
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---

In the areas.bbs file that file is identified as...

--- 8< ---
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---

Then a sendmail script called for a 'fmail scan' which scanned _every_ message area: netmail, HMB & then JAM. It seemed to completely ignore the echomail.jam file except when it came time to delete it.

This was kinda awkward so I re-ran the same actions. Same result. Oops. ;-)

There must have been something else that I missed? Do you have any suggestions, please?

Cheers,
Paul.

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

Hi Paul,

On 07 Sep 17 12:21, Paul Quinn wrote to Wilfred Van Velzen:
about: "Re: Trialing FMail/lnx status check-in":

Ooh, ooh... now I have to do something... oh, no...!

I'll stay tuned! ;)

Well, I managed to screw up even some of the simplest things but eventually got something like a normal echomail scan out...

GoldEd created the expected echomail.jam file, containing...

--- 8< ---
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---

Is that the name of the jam area filenames (without the extensions)?

Mine have more readable names. For instance when I reply to this message echomail.jam contains:

/home/fido/jam/fido/fmailhelp 998

In the areas.bbs file that file is identified as...

--- 8< ---
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---

Then a sendmail script called for a 'fmail scan' which scanned _every_ message area: netmail, HMB & then JAM. It seemed to completely ignore the echomail.jam file except when it came time to delete it.

This was kinda awkward so I re-ran the same actions. Same result. Oops. ;-)

There must have been something else that I missed? Do you have any suggestions, please?

Do you run Golded and the sendmail script as the same linux user? Is that user also the owner of the echomail.jam file and the jam area files?

What does the log say?

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Wilfred,

On 09/07/2017 05:43 PM, you wrote:

GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---

Is that the name of the jam area filenames (without the extensions)?

Yes.

Mine have more readable names. For instance when I reply to this message echomail.jam contains:
/home/fido/jam/fido/fmailhelp 998

Understood. The area consists of pre-existing files, copied over five years ago from FastEcho/DOS's auto-create origin point, and since then maintained by Crashmail II/lnx. As of Saturday last, FMail/lnx is now the owner/operator.

In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---

Do you run Golded and the sendmail script as the same linux user? Is
that user also the owner of the echomail.jam file and the jam area files?

Yes. Everything at & below /opt/ftn has my user's rights, only.

What does the log say?

--- 8< ---

07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan
07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED

[ ...trimmed... ]

07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
07 Sep 17 12:15:15 FMAIL Mail bundle already going from 3:640/1384 to 3:640/384
07 Sep 17 12:15:15 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1
07 Sep 17 12:15:15 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad: 0
07 Sep 17 12:15:15 FMAIL Scan Active: 1.376 sec.

--- 8< ---

The terminal screen says

Hi Paul,

On 2017-09-07 19:48:25, you wrote to me:

What does the log say?

--- 8< ---

07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan
07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED

[ ...trimmed... ]

07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
07 Sep 17 12:15:15 FMAIL Mail bundle already going from 3:640/1384
to 3:640/384 07 Sep 17 12:15:15 FMAIL Netmail: 0, Personal: 0,
Hudson: 0, JAMbase: 1 07 Sep 17 12:15:15 FMAIL Msgbase net: 0, echo:
1, dup: 0, bad: 0 07 Sep 17 12:15:15 FMAIL Scan Active: 1.376 sec.

--- 8< ---

The terminal screen says things about checking netmail & HMB, and then JAM areas. Nothing about the echomail.jam file at all.

Maybe the loging/printing isn't perfect, but this all seems fine. Have you checked if the mail arrived at it's destination (3:640/384) ?

If you are not certain you can have FMail make backups of outgoing .pkt files by specifying a "Outgoing backup" directory in FConfig. So you have a way of checking what's produced without it disappearing because of your mailer (or other processes) doing their jobs...


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Thu, 07 Sep 17, you wrote to me:

The terminal screen says things about checking
netmail & HMB, and then JAM areas. Nothing about the
echomail.jam file at all.

Maybe the loging/printing isn't perfect, but this all
seems fine. Have you checked if the mail arrived at it's
destination (3:640/384) ?

Maybe so. They were only test posts within a 'sandbox'. OTOH, I've just now checked the mail bundle with David Nugent's 'InspectA' util, and found the posts were written properly. Even the TZUTC values were correct.

If you are not certain you can have FMail make backups of
outgoing .pkt files by specifying a "Outgoing backup"
directory in FConfig. So you have a way of checking what's
produced without it disappearing because of your mailer
(or other processes) doing their jobs...

I used to when I first started toying with FMail/lnx, but soon turned that off.
They're effectively being backup up for the duration of the testing phase by not being sent anywhere. They're boxed in as if "lab rats". :)

Cheers,
Paul.

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

Hi Paul,

On 2017-09-07 21:47:00, you wrote to me:

Maybe the loging/printing isn't perfect, but this all
seems fine. Have you checked if the mail arrived at it's
destination (3:640/384) ?

Maybe so. They were only test posts within a 'sandbox'. OTOH, I've just now checked the mail bundle with David Nugent's 'InspectA' util, and found the posts were written properly.

Ok, nice!

Even the TZUTC values were correct.

That's put there by golded! ;)

Only ftools generates TZUTC kludges when you use the 'post' function.

If you are not certain you can have FMail make backups of
outgoing .pkt files by specifying a "Outgoing backup"
directory in FConfig. So you have a way of checking what's
produced without it disappearing because of your mailer
(or other processes) doing their jobs...

I used to when I first started toying with FMail/lnx, but soon turned that off. They're effectively being backup up for the duration of the testing phase by not being sent anywhere. They're boxed in as if "lab rats". :)

That also works. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Paul,

On Thu Sep 07 2017 19:48:24, Paul Quinn wrote to Wilfred van Velzen:

GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020

The above seems like a MSGID or a computed packet naming scheme, not an areatag. Is the echotag actually fec1e5dd? Also, is 8020 the number of your message in the message base?

In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384

--- 8< ---

07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 -
Scan 07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED

[ ...trimmed... ]

07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update
/opt/ftn/fido/outbound/02800180.hlo 07 Sep 17 12:15:15 FMAIL
Mail bundle already going from 3:640/1384 to 3:640/384 07 Sep 17
12:15:15 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1
07 Sep 17 12:15:15 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad:
0 07 Sep 17 12:15:15 FMAIL Scan Active: 1.376 sec.

--- 8< ---

This log snippet doesn't mention anything about area "fec1e5dd". But it does mention "WIN95". Something seems odd there, like your echomail.jam should read:

/opt/ftn/fido/msgbase/win95 8020

..instead, and that is what FMail is looking for, but since it doesn't see it, and nothing else was read from echomail.jam it deleted the file.

The terminal screen says things about checking netmail & HMB, and then
JAM areas. Nothing about the echomail.jam file at all.

I believe I had asked about some better logging when echomail.jam fails too. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi! Nick,

On 09/08/2017 07:36 AM, you wrote:

GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020

The above seems like a MSGID or a computed packet naming scheme, not an areatag. Is the echotag actually fec1e5dd? Also, is 8020 the number of your message in the message base?

No bout-a-doubt it. I'm with you on this. It does and probably uses the same hashing code... in FastEcho (FE). It's originally an auto-created FE echomail base filename generated by using a hash value. (While browsing logfiles, I narrowed it down last night to sometime during the week 14-20 December 1997.) It is how FE does that sort of thing.

In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384

This is the important bit... ^^^^ It's where the translation you're looking for occurs, and also most importantly, is in FMail's area manager also.
The areas.bbs is only used by GoldEd, and is the only format quotable in echomail taking into account FMail's config files are binary types.

--- 8< ---

07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 -

--- 8< ---

This log snippet doesn't mention anything about area "fec1e5dd". But it does mention "WIN95". Something seems odd there, like your echomail.jam should read:
/opt/ftn/fido/msgbase/win95 8020

For most of the echo areas that is true; there is a very small number of areas cloned from my old FE config. Your average echomail.jam deals in echo base path+filename and message number, only. No area tags.

The terminal screen says things about checking netmail & HMB, and
then JAM areas. Nothing about the echomail.jam file at all.

I believe I had asked about some better logging when echomail.jam fails too. ;)

Damned right! Or, at least a log entry that says "Nup, it's Thursday... I don't do echomail.jam files on Thursdays. Thank you for your co-operation". 8-)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi! Nick,

On 09/08/2017 07:36 AM, you wrote:

Oops, I forgot...

/opt/ftn/fido/msgbase/fec1e5dd 8020

Also, is 8020 the number of your message in the message base?

Yes. :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hello Paul,

On Fri Sep 08 2017 08:45:44, Paul Quinn wrote to Nicholas Boel:

/opt/ftn/fido/msgbase/fec1e5dd 8020

The above seems like a MSGID or a computed packet naming scheme,
not an areatag. Is the echotag actually fec1e5dd? Also, is 8020
the number of your message in the message base?

No bout-a-doubt it. I'm with you on this. It does and probably uses
the same hashing code... in FastEcho (FE). It's originally an auto-created FE echomail base filename generated by using a hash
value. (While browsing logfiles, I narrowed it down last night to sometime during the week 14-20 December 1997.) It is how FE does that sort of thing.

Is that some sort of separate option or setting? I can only seem to recall areatag-esque filenames created by FastEcho when I used it some ages ago. At least I don't remember any tosser I've ever used making filenames like that by default.

In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384

This is the important bit... ^^^^ It's where the translation you're looking for occurs, and also most importantly, is in FMail's
area manager also. The areas.bbs is only used by GoldEd, and is the
only format quotable in echomail taking into account FMail's config
files are binary types.

This is probably where I was confused when originally setting up FMail with an areas.bbs. I suppose I've just seen way too many different formats of areas.bbs
to know which is actually the _correct_ one.

This log snippet doesn't mention anything about area "fec1e5dd".
But it does mention "WIN95". Something seems odd there, like your
echomail.jam should read: /opt/ftn/fido/msgbase/win95 8020

For most of the echo areas that is true; there is a very small number
of areas cloned from my old FE config. Your average echomail.jam
deals in echo base path+filename and message number, only. No area
tags.

Right. It was the areas.bbs format you had above that confused me, not the echomail.jam format. Have you tried a test post on an echo not cloned from FE to see if echomail.jam is read properly?

I believe I had asked about some better logging when echomail.jam
fails too. ;)

Damned right! Or, at least a log entry that says "Nup, it's
Thursday... I don't do echomail.jam files on Thursdays. Thank you for your co-operation". 8-)

Yeah, or "Go get me a beer first, then we'll talk!"

So far in my endeavo(u)r, I haven't seen any big issues with Fmail/lnx, so I added in the rest of my Fidonet echos. Still haven't added othernets yet, but that time will come. Seems to be chugging along nicely so far, so I don't see an issue. Once I get it all setup the way I want it, hopefully I can just drop it in place on this machine and replace the few 'hpt <args>' commands with 'fmail <args>' ones.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi! Nicholas,

On Thu, 07 Sep 17, you wrote to me:

It is how FE does that sort of thing.

Is that some sort of separate option or setting? I can only
seem to recall areatag-esque filenames created by FastEcho
when I used it some ages ago. At least I don't remember any
tosser I've ever used making filenames like that by
default.

Nothing special other than only certain up/down/sideways-linked systems can be given access to the function. There is a 'perhaps', maybe, if it does the hash
when there ain't no backbone-type of tag descriptor file.[shrug] Just browsing
the doco 5 mins ago, I couldn't see anything related to the naming of auto-created echo base files. The function is descibed at page 26.

Right. It was the areas.bbs format you had above that
confused me, not the echomail.jam format. Have you tried a
test post on an echo not cloned from FE to see if
echomail.jam is read properly?

Just a little while ago, twice. The echomail.jam file read...
--- 8< ---
/opt/ftn/fido/msgbase/aviation 14
--- 8< ---

That was the second attempt... I forgot to check the file first time around. Oops. Lucky #13, it was. Don't look for them of course. Nothing gets out of the glass menagerie alive. ;-)

Cheers,
Paul.

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

On 09/07/17, Nicholas Boel pondered and said...

Damned right! Or, at least a log entry that says "Nup, it's Thursday... I don't do echomail.jam files on Thursdays. Thank you fo your co-operation". 8-)

Yeah, or "Go get me a beer first, then we'll talk!"

I love watching you guys hard at work testing stuff. Fido and BBS land is a better place for all the hard work you lad do :) *pat on the back*

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

Hi Nicholas,

On 2017-09-07 16:36:44, you wrote to Paul Quinn:

07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95

/opt/ftn/fido/outbound/02800180.hlo 07 Sep 17 12:15:15 FMAIL
Mail bundle already going from 3:640/1384 to 3:640/384 07 Sep 17
12:15:15 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1
07 Sep 17 12:15:15 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad:
0 07 Sep 17 12:15:15 FMAIL Scan Active: 1.376 sec.

This log snippet doesn't mention anything about area "fec1e5dd". But
it does mention "WIN95". Something seems odd there,

The jam file area name that is used on Pauls system is odd, but all is working fine...

..instead, and that is what FMail is looking for, but since it doesn't
see it, and nothing else was read from echomail.jam it deleted the
file.

It did see it and exported the message to Pauls outbound (if that isn't clear yet?)...

The terminal screen says things about checking netmail & HMB, and
then JAM areas. Nothing about the echomail.jam file at all.

I believe I had asked about some better logging when echomail.jam fails too. ;)

It's there... In the debug version. Just have to clean that up a bit for the production version. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Paul,

On 2017-09-08 08:45:44, you wrote to Nicholas Boel:

I believe I had asked about some better logging when echomail.jam
fails too. ;)

Damned right! Or, at least a log entry that says "Nup, it's Thursday... I don't do echomail.jam files on Thursdays. Thank you for your co-operation". 8-)

Something like "sabbath" option, with configurable rest day of the week? Should
I put that on the wish list? ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Nicholas,

On 2017-09-07 20:45:24, you wrote to Paul Quinn:

Is that some sort of separate option or setting? I can only seem to
recall areatag-esque filenames created by FastEcho when I used it some ages ago. At least I don't remember any tosser I've ever used making filenames like that by default.

FMail uses the area tag for auto created areas. But filters out characters that
conflict with filesystems (like : / \), and I also changed it to convert uppercase to lowercase a while back, in preperation of the linux version...

This is probably where I was confused when originally setting up FMail with an areas.bbs. I suppose I've just seen way too many different
formats of areas.bbs to know which is actually the _correct_ one.

What I've seen is that every software uses it's own format, so is there a "correct" one? Certainly the ftsc hasn't documented one...

Right. It was the areas.bbs format you had above that confused me, not
the echomail.jam format. Have you tried a test post on an echo not
cloned from FE to see if echomail.jam is read properly?

echomail.jam was read correctly! (If that wasn't clear yet?) ;)


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Fri, 08 Sep 17, you wrote to me:

Something like "sabbath" option, with configurable rest
day of the week? Should I put that on the wish list? ;)

I reckon it's about time we had software with 'attitude'. You know, Terminator-sized terror under the hood...

"HaHa-ha! Only one puny Echomail.Jam file? You need a diskful! Let's fix that...". ;-)

Cheers,
Paul.

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

Hi Paul,

On 2017-09-08 20:41:00, you wrote to me:

Something like "sabbath" option, with configurable rest
day of the week? Should I put that on the wish list? ;)

I reckon it's about time we had software with 'attitude'. You know, Terminator-sized terror under the hood...

"HaHa-ha! Only one puny Echomail.Jam file? You need a diskful! Let's

fix

that...". ;-)

If I had the time, I could make such a release on april 1st some year... ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 2017 Sep 07 09:43:26, you wrote to Paul Quinn:

--- 8< ---
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---

Is that the name of the jam area filenames (without the extensions)?

that's an autocreated-by-fastecho area... FE on the beginning of the name tells
that... the other 6 characters are the result of some sort of CRC routine on the name, AFAIK...


)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Sewer Rat might taste like pumpkin pie, but I'll never know.
---
* Origin: (1:3634/12.73)

Hello Paul,

On Fri Sep 08 2017 15:57:00, Paul Quinn wrote to Nicholas Boel:

Just a little while ago, twice. The echomail.jam file read...
--- 8< ---
/opt/ftn/fido/msgbase/aviation 14
--- 8< ---

That was the second attempt... I forgot to check the file first time around. Oops. Lucky #13, it was. Don't look for them of course.
Nothing gets out of the glass menagerie alive. ;-)

If it's still not working. I wonder if the stuff Wilfred compiled for you contained the updated fmail.c I had gotten and compiled with, which contained a
fix for echomail.jam not reading linux paths...?

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Paul,

On Fri Sep 08 2017 21:49:12, Paul Hayton wrote to Nicholas Boel:

I love watching you guys hard at work testing stuff. Fido and BBS land
is a better place for all the hard work you lad do :) *pat on the
back*

If I didn't try things out and report any findings, I would have lost interest in Fido/BBS land a long time ago. It's the *only* thing keeping me around, because when this kind of discussion isn't happening, the discussions I'd rather not get involved in take over.

Which reminds me. A35 needs to be setup here soon. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Wilfred,

On Fri Sep 08 2017 12:22:40, Wilfred van Velzen wrote to Nicholas Boel:

The jam file area name that is used on Pauls system is odd, but all is working fine...

Ok.

It did see it and exported the message to Pauls outbound (if that
isn't clear yet?)...

Very clear. However, the only reason it was scanned out is because his FMail scanned _every_ area, rather than just what was in the echomail.jam.

I believe I had asked about some better logging when echomail.jam
fails too. ;)

It's there... In the debug version. Just have to clean that up a bit
for the production version. ;)

Did you give Paul a compiled setup with the updated fmail.c you gave me that fixed linux paths in echomail.jam?

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Wilfred,

On Fri Sep 08 2017 12:13:36, Wilfred van Velzen wrote to Nicholas Boel:

Right. It was the areas.bbs format you had above that confused
me, not the echomail.jam format. Have you tried a test post on an
echo not cloned from FE to see if echomail.jam is read properly?

echomail.jam was read correctly! (If that wasn't clear yet?) ;)

Hmm, what I saw was that echomail.jam was deleted, and his entire message base was scanned instead of just the area given by echomail.jam.

Did I miss something?

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi Nicholas,

On 2017-09-08 15:47:04, you wrote to me:

It did see it and exported the message to Pauls outbound (if that
isn't clear yet?)...

Very clear. However, the only reason it was scanned out is because his FMail scanned _every_ area, rather than just what was in the echomail.jam.

Nope. If I understood Paul correctly, it worked ok, scanning from echomail.jam!

I believe I had asked about some better logging when echomail.jam
fails too. ;)

It's there... In the debug version. Just have to clean that up a bit
for the production version. ;)

Did you give Paul a compiled setup with the updated fmail.c you gave me that fixed linux paths in echomail.jam?

Yes, it was freshly compiled. But it wasn't a debug version, so it didn't contain the extra logging...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Nicholas,

On 2017-09-08 15:49:06, you wrote to me:

echomail.jam was read correctly! (If that wasn't clear yet?) ;)

Hmm, what I saw was that echomail.jam was deleted, and his entire message base was scanned instead of just the area given by echomail.jam.

Did I miss something?

Maybe you're right. ;)

I'll gona give Paul a version with the extra logging, so we can find out for sure...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 09/09/2017 07:53 AM, you wrote to Nicholas Boel:

echomail.jam was read correctly! (If that wasn't clear yet?) ;)

Hmm, what I saw was that echomail.jam was deleted, and his entire
message base was scanned instead of just the area given by
echomail.jam.
Did I miss something?

Maybe you're right. ;)

I see your maybe and raise you a definite. I did originally report...

"a sendmail script called for a 'fmail scan' which scanned _every_ message area: netmail, HMB & then JAM. It seemed to completely ignore the echomail.jam
file except when it came time to delete it."

I'll gona give Paul a version with the extra logging, so we can find out for sure...

Kewl. More toys! Thank you. :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Wilfred, just a quick question have you enabled JAM for netmail bases in
FMail? This is a feature I'd really like to see as/when you're able to look
at it.

Thanks for the dev work you do :)

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

On 09/08/17, Nicholas Boel pondered and said...

If I didn't try things out and report any findings, I would have lost interest in Fido/BBS land a long time ago. It's the *only* thing keeping me around, because when this kind of discussion isn't happening, the discussions I'd rather not get involved in take over.

Fair enough... :)

Which reminds me. A35 needs to be setup here soon. ;)

Heh... sing out if you need anything, always happy to help!

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

Hi Paul,

On 2017-09-09 08:30:23, you wrote to me:

I see your maybe and raise you a definite. I did originally report...

"a sendmail script called for a 'fmail scan' which scanned _every_ message area: netmail, HMB & then JAM. It seemed to completely ignore the echomail.jam file except when it came time to delete it."

I probably didn't pay enough attention, but you didn't say 'fmail scan -s' ! ;)

If you use the -s option or configure 'Scan always' in FConfig, than that's the
behaviour you get...


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Paul,

On 2017-09-09 13:16:30, you wrote to me:

Wilfred, just a quick question have you enabled JAM for netmail bases
in FMail? This is a feature I'd really like to see as/when you're able
to look at it.

"enabled" as in flicking a switch? ;)

If it where that easy I would already have done it! ;)

Thanks for the dev work you do :)

You're welcome!

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Sat, 09 Sep 17, you wrote to me:

completely ignore the echomail.jam file except when
it came time to delete it."

I probably didn't pay enough attention, but you didn't say
'fmail scan -s' ! ;)

I knew I wasn't doing it, so I wouldn't say I was.[gulp]

If you use the -s option or configure 'Scan always' in
FConfig, than that's the behaviour you get...

Oh, bugger... I found this in an exported config text, "Scan Always : Yes". Aww, I don't like saying "no" to things. It's so negative. My humble apologies, dear fellow. I will fix this schamozzle tomorrow and give fmail scan a proper workout, along with some other evil plans I have for FMail.

If I wasn't up to my armpits in EwwToob (YT), I'd do it now. Priorities...

Thank you, kindly.

Cheers,
Paul.

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

Hi Paul,

On 2017-09-09 20:33:00, you wrote to me:

Oh, bugger... I found this in an exported config text, "Scan Always : Yes". Aww, I don't like saying "no" to things. It's so negative. My humble apologies, dear fellow. I will fix this schamozzle tomorrow
and give fmail scan a proper workout, along with some other evil plans
I have for FMail.

Ok, keep us informed!

If I wasn't up to my armpits in EwwToob (YT), I'd do it now.
Priorities...

If you mean YouTube, yes I know, it's addictive! ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Sat, 09 Sep 17, you wrote to me:

I will fix this schamozzle tomorrow and give fmail
scan a proper workout, along with some other evil
plans I have for FMail.

Ok, keep us informed!

Well, I had this itch to fix it...

If I wasn't up to my armpits in EwwToob (YT), I'd do
it now. Priorities...

If you mean YouTube, yes I know, it's addictive! ;)

Yes. Then there are times I end up in a sort of Twilight Zone for hours if my attention wanders from YT to Vimeo and LiveLeak. Anyway, I have a tall tale to
tell...

This morning I modified GoldEd's config over to reading the FMail config rather
than an Areas.Bbs file exported from it, after I found & re-enabled the GoldEd config switch to convert DOS paths to a Linux one in tosser area config files.
(It took a little fine-tuning but in the end it worked.) So, after doing the right thing with the scan always FMail switch, I went through the motions of another post test. GoldEd created the echomail.jam file like this...

--- 8< ---
C:\opt\ftn\fido\msgbase\fmail_help 867
--- 8< ---

Which is fine since the FMail envar translation will convert it back to a Linux path. (I say back because FMail initially sucked in the Areas.Bbs file from CM II, _with_ Linux paths. And they stuck! FMail's area manager has Linux paths!) So, running the sendmail.sh produced...

--- 8< ---

09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384 to 3:640/384
09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad: 0
09 Sep 17 20:56:14 FMAIL Scan Active: 0.162 sec.

--- 8< ---

Neat, huh? I shall admonish myself tomorrow for not saying "no" enough times. :) Thank you for your kind assistance.

Cheers,
Paul.

--- Paul's Win98

Hi Nicholas!

08 Sep 2017 15:44, from Nicholas Boel -> Paul Hayton:

If I didn't try things out and report any findings, I would have lost interest in Fido/BBS land a long time ago. It's the *only* thing
keeping me around, because when this kind of discussion isn't
happening, the discussions I'd rather not get involved in take over.

:-))

CU, Ricsi

--- GoldED+/LNX
* Origin: So many coffee blends, so little time. (2:310/31)

Hi Paul,

On 2017-09-09 21:49:00, you wrote to me:

... Anyway, I have a tall tale to tell...

This morning I modified GoldEd's config over to reading the FMail config rather than an Areas.Bbs file exported from it, after I found & re-enabled the GoldEd config switch to convert DOS paths to a Linux one in tosser

area

config files. (It took a little fine-tuning but in the end it worked.) So, after doing the right thing with the scan always FMail switch, I went through the motions of another post test. GoldEd created the echomail.jam file like this...

--- 8< ---
C:\opt\ftn\fido\msgbase\fmail_help 867
--- 8< ---

Which is fine since the FMail envar translation will convert it back to a Linux path. (I say back because FMail initially sucked in the Areas.Bbs file from CM II, _with_ Linux paths. And they stuck! FMail's area

manager

has Linux paths!) So, running the sendmail.sh produced...

--- 8< ---

09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384 to
3:640/384 09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0, Hudson: 0,
JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0, echo: 1, dup: 0,
bad: 0 09 Sep 17 20:56:14 FMAIL Scan Active: 0.162 sec.

--- 8< ---

Neat, huh?

Yes, looks all good!

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Fri Sep 08 2017 23:47:58, Wilfred van Velzen wrote to Nicholas Boel:

Very clear. However, the only reason it was scanned out is
because his FMail scanned _every_ area, rather than just what was
in the echomail.jam.

Nope. If I understood Paul correctly, it worked ok, scanning from echomail.jam!

Ah. Well if that's the case, I completely missed a part of this conversation then.

Did you give Paul a compiled setup with the updated fmail.c you
gave me that fixed linux paths in echomail.jam?

Yes, it was freshly compiled. But it wasn't a debug version, so it
didn't contain the extra logging...

OK.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Paul,

On Sat Sep 09 2017 21:49:00, Paul Quinn wrote to Wilfred Van Velzen:

--- 8< ---
C:\opt\ftn\fido\msgbase\fmail_help 867
--- 8< ---

Which is fine since the FMail envar translation will convert it back
to a Linux path. (I say back because FMail initially sucked in the Areas.Bbs file from CM II, _with_ Linux paths. And they stuck!
FMail's area manager has Linux paths!) So, running the sendmail.sh produced...

--- 8< ---

09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384
to 3:640/384 09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0,
Hudson: 0, JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0,
echo: 1, dup: 0, bad: 0 09 Sep 17 20:56:14 FMAIL Scan Active: 0.162
sec.

--- 8< ---

Neat, huh? I shall admonish myself tomorrow for not saying "no"
enough times. :) Thank you for your kind assistance.

20 lashes with a wet noodle should do the trick! ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi! Nick,

On 09/11/2017 05:27 AM, you wrote:

20 lashes with a wet noodle should do the trick! ;)<message>.

Ooh, kinky! I just considered mandatory chocolate withdrawal would suffice. :)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Nicholas,

On 2017-09-10 14:23:04, you wrote to me:

Nope. If I understood Paul correctly, it worked ok, scanning from
echomail.jam!

Ah. Well if that's the case, I completely missed a part of this conversation then.

It wasn't but now it is! ;)


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

Today I had set aside some play time with FMail, but I'm sort of hung up on a little thing with the 'primary netmail' area. You know, the one not in any HMB
base; it's the *.Msg area.

Just between you & me before anyone else notices: how does one bargain with or bribe FMail into exporting a FREQ netmail into the binkD stream? FMail completely ignores a FREQ from me to my main node, even after I slung an imaginary PING to Tommi Koivula's joint... which FMail actually did pack up properly.

I've tried several different pack manager statements beyond the original routing that had everything not previously stipulated goes via my main node, in
any case. I don't know if that's the problem area. I'm forced to ask if there's a secret pack "-f" switch for FREQ netmails? ;-)

Cheers,
Paul.

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

On 2017 Sep 16 16:22:00, you wrote to Wilfred Van Velzen:

Today I had set aside some play time with FMail, but I'm sort of hung up

on

a little thing with the 'primary netmail' area. You know, the one not in any HMB base; it's the *.Msg area.

ahh... the mailer's playpen...

Just between you & me before anyone else notices: how does one bargain with or bribe FMail into exporting a FREQ netmail into the binkD
stream?

you don't... the FREQs are completely different formats... this is where the nodelist comes into play and remote sites having proper FREQ flags defined... intelligent mailers like frontdoor do this as a matter of fact because they know what format the remote needs... BSO mailers are generally not so intelligent...

what mailer are you using on the local end?
what mailer is running on the remote end?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... This byte has all the naughty bits masked out...
---
* Origin: (1:3634/12.73)

Hi! mark,

On 09/16/2017 05:30 PM, you wrote:

it's the *.Msg area.

ahh... the mailer's playpen...

That's how me & you understand it, if looking from a FroDo POV. In this case it belong'em FMail (& GoldEd) only.

Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into
the binkD stream?

you don't... the FREQs are completely different formats... this is where the nodelist comes into play and remote sites having proper FREQ flags defined... intelligent mailers like frontdoor do this as a matter of
fact because they know what format the remote needs... BSO mailers are generally not so intelligent...

Ah, yup...

what mailer are you using on the local end?

binkD.

what mailer is running on the remote end?

Radius. I mastered the internal FREQ server setup maybe a year ago. Now that you raised the matter, I've realized there ain't no X? nodelist flag for my main node & RC AKA. I think I pulled the flags when I was troubleshooting a problem with my DOS BATch FREQ handler, which was okay; it was just missing some supporting files which disappeared over years of disuse. The flag should be XX, as for Argus I think. I'll try & get David to fix that ASAP or with the
next necessary region update.

That's besides the point IAC: FMail knows nothing of the nodelist IIRC. I'm a little remote from my PC now but I've checked a FMail text output file that makes no mention of a nodelist file in the config.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Paul,

On 2017-09-16 16:22:00, you wrote to me:

Just between you & me before anyone else notices: how does one bargain with or bribe FMail into exporting a FREQ netmail into the binkD
stream?

You can't.

FMail completely ignores a FREQ from me to my main node,

That's by design. Freq's are not really the domain of a mail processor/tosser.

A BSO mailer needs a .req file to send a file request to a node. So if you would pack a netmail with a freq flag into a .pkt file nothing that you expect would happen except of course the .pkt file would be send to the node. Where it
would be handled by the nodes tosser, and not by the mailer or freq processor...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Sat, 16 Sep 17, you wrote to me:

Just between you & me before anyone else notices: how
does one bargain with or bribe FMail into exporting a
FREQ netmail into the binkD stream?

You can't.

I am crushed. :(

FMail completely ignores a FREQ from me to my main
node,

That's by design. Freq's are not really the domain of a
mail processor/tosser.

You had better tell FTools then. It has a 'post' function sporting a '-r' switch (I wasn't using it... honest).

A BSO mailer needs a .req file to send a file request to a
node.

That's all the tosser needs to do in a BSO environment: parse the Subj field for FREQ-able filename(s), and create the .Req file for the intended system from the netmail. That .Req file is added to the .Flo file. The contents are the requested filename(s) at one per line.

So if you would pack a netmail with a freq flag into
a .pkt file nothing that you expect would happen except of
course the .pkt file would be send to the node. Where it
would be handled by the nodes tosser, and not by the
mailer or freq processor...

That is something like a FrontDoor/Intermail environment (maybe not the .Pkt part). I dunno any more as I gave up on FroDo last century.

I'm pretty sure these are the ways that FastEcho works. That may not carry much weight with you and I am not wielding it as if in an argument; I'm just saying. IAC, I am happy to be corrected by Mark Lewis as he knows best.

OTOH, I have learned to not be able to FREQ via netmail from node #1384 since having used CrashMail II for the last five years. It is similarly retarded. I'm not disappointed, just crushed. ;-)

Thank you for your time.

Cheers,
Paul.

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

On 2017 Sep 16 14:11:56, you wrote to Paul Quinn:

Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into the
binkD stream?

You can't.

one might be able to, though...

FMail completely ignores a FREQ from me to my main node,

That's by design. Freq's are not really the domain of a mail processor/tosser.

right but it is the only thing in position to perform this feat...

A BSO mailer needs a .req file to send a file request to a node. So if
you would pack a netmail with a freq flag into a .pkt file nothing
that you expect would happen except of course the .pkt file would be
send to the node. Where it would be handled by the nodes tosser, and
not by the mailer or freq processor...

ummm... FMail can simply look at the MSG and see that it is a FREQ... there's a
flag or bit setting for this... then FMail can ""pack"" the FREQ by creating the REQ file and possibly associated ?LO file... the REQ file can have any name
but the BSO traditional format is to name it via the same outbound.xxx/yyyyzzzz
format as already used... a ?LO file is required to at least trigger the delivery of the REQ, though... binkd doesn't trigger on just the REQ alone... if the REQ file is not named traditionally, it needs to be referenced in the ?LO file like others... REQ files can simply be deleted after they are sent... no need to truncate them... all of this would be restricted to telling FMail that you are using a BSO mailer... it doesn't need to be done for intelligent mailers...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Compared to Rice Krispies, oatmeal is brain dead!
---
* Origin: (1:3634/12.73)

Hi Paul,

On 2017-09-16 22:56:00, you wrote to me:

You can't.

I am crushed. :(

You'll get over it. ;)

That's by design. Freq's are not really the domain of a
mail processor/tosser.

You had better tell FTools then. It has a 'post' function sporting a '-r' switch (I wasn't using it... honest).

That's about creating a filerequest message, not about handling it...

A BSO mailer needs a .req file to send a file request to a
node.

That's all the tosser needs to do in a BSO environment: parse the Subj field for FREQ-able filename(s), and create the .Req file for the intended system from the netmail. That .Req file is added to the .Flo file. The contents are the requested filename(s) at one per line.

Ok it could be done, maybe in the pack function, or maybe in a seperate function. It doesn't seem all that hard... But it was never implemented by the original author, and never came up before in the 10 years I'm involved with the
source code. I could put it on "the list", but it wouldn't be a high priority item...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi mark,

On 2017-09-16 09:12:14, you wrote to me:

Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into the
binkD stream?

You can't.

one might be able to, though...

Of course... Anything is possible given enought time. ;)

FMail completely ignores a FREQ from me to my main node,

That's by design. Freq's are not really the domain of a mail
processor/tosser.

right but it is the only thing in position to perform this feat...

Isn't there software more geared towards file transfers in fidonet, that can do
this? Maybe something like allfix? (Just guessing)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Saturday September 16 2017 22:38, you wrote to mark lewis:

right but it is the only thing in position to perform this
feat...

Isn't there software more geared towards file transfers in fidonet,
that can do this? Maybe something like allfix? (Just guessing)

Allfix can handle an incoming file request and binkd has hooks for that. TTMBOK, allfix does not have the ability to setup an outgoing file request. If there is I haven't found it yet.

Setting up a request in a BSO environment is not hard. Just use any text editor
to create a file nnnn.ffff.req with the name of the requested file as content and store it in the outbound. nnnn being the number of the net in hex and ffff the node number in hex.
It will be sent the next time the node is called for some reason. Like a scheduled contact or a forced poll.

Writing a script to do this would not be hard, but on the few occasions that I wanted to freq, I just created the *.req file manually. I suppose it could be added to Fmail, but there are other things much higher on my fmail wish list.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi! Wilfred,

On 09/17/2017 06:31 AM, you wrote:

You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).

That's about creating a filerequest message, not about handling it...

Fascinating. That's what they mean by the term conundrum, I guess. Why create
something that cannot be handled by itself at a later stage? Mmm...

Ok it could be done, maybe in the pack function, or maybe in a seperate function. It doesn't seem all that hard... But it was never implemented by the original author, and never came up before in the 10 years I'm involved with the source code. I could put it on "the list", but it wouldn't be a high priority item...

Nice. Even at priority #99 it is still on 'the list'. :) Thank you.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hello Paul,

On Sunday September 17 2017 07:17, you wrote to Wilfred van Velzen:

You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).

That's about creating a filerequest message, not about handling
it...

Fascinating. That's what they mean by the term conundrum, I guess.
Why create something that cannot be handled by itself at a later
stage? Mmm...

It is a relic from the past. Fmail was originally designed in a FrontDoor like environment. In a Frontdoor environment creating a file attach message makes sense. The Frontdoor environment is also called AMA (Arc Mail Attach). Files are always send as file attach. There is a message associated with every file transfer. Also with a file request.

In a BSO environment things work different. The mailer only knows about files. It does not directly deal with messages, that is left to the tosser or packer.

Ok it could be done, maybe in the pack function, or maybe in a
seperate function. It doesn't seem all that hard... But it was
never implemented by the original author, and never came up
before in the 10 years I'm involved with the source code. I
could put it on "the list", but it wouldn't be a high priority
item...

Nice. Even at priority #99 it is still on 'the list'. :) Thank you.

Have you tried to manually create a *.req file. If you ever dealt with hex, it shoukd not be hard...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi! Michiel,

On 09/17/2017 07:48 AM, you wrote:

You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).

MvdV> It is a relic from the past. Fmail was originally designed in a
MvdV> FrontDoor like environment. In a Frontdoor environment creating a file
MvdV> attach message makes sense. The Frontdoor environment is also called AMA
MvdV> (Arc Mail Attach). Files are always send as file attach. There is a
MvdV> message associated with every file transfer. Also with a file request.

So, we have 'r'=='relic' in this context. :) Thank you for the history lesson.

MvdV> In a BSO environment things work different. The mailer only knows about
MvdV> files. It does not directly deal with messages, that is left to the
MvdV> tosser or packer.

Mmm... you're limited by your experience with binkD, perhaps.[shrug] BinkleyTerm (where BSO originated) knew exactly what to do when Alt-G was pressed: it started a FREQ dialogue of its own. I can do the same thing with a
few mouse clicks in Radius... an advanced BSO mailer.

MvdV> Have you tried to manually create a *.req file. If you ever dealt with
MvdV> hex, it shoukd not be hard...

After five years with CrashMail II, I already have the necessary files at hand,
and a wonderful editor. Thanks, Michiel.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)

Hi Paul,

On 2017-09-17 07:17:12, you wrote to me:

That's about creating a filerequest message, not about handling
it...

Fascinating. That's what they mean by the term conundrum, I guess. Why create something that cannot be handled by itself at a later stage?

Mmm...

That probably shows FMail's origin in a frontdoor mailer (or likewise) environment...

Ok it could be done, maybe in the pack function, or maybe in a
seperate function. It doesn't seem all that hard... But it was never
implemented by the original author, and never came up before in the
10 years I'm involved with the source code. I could put it on "the
list", but it wouldn't be a high priority item...

Nice. Even at priority #99 it is still on 'the list'. :) Thank you.

It's a coasy area of the list, with a lot of other wishes which have been there
a long time... ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On Sun, 17 Sep 17, you wrote to me:

Nice. Even at priority #99 it is still on 'the
list'. :) Thank you.

It's a coasy area of the list, with a lot of other wishes
which have been there a long time... ;)

Can I nominate another? I will anyway: has anyone commented on the paucity of output from 'ftools stat', yet? ;-)

I used to think that FastEcho did its thing rather well until I saw the reports
from CrashMail II. I can send you a copy of this afternoon's report as an example, if you're interested...

Cheers,
Paul.

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

Hello Paul,

On Sunday September 17 2017 21:15, you wrote to Wilfred Van Velzen:

Can I nominate another? I will anyway: has anyone commented on the paucity of output from 'ftools stat', yet? ;-)

I have never used it...

I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...

What I always find remarkable is that when pwople change software, after a while they always want the new software to behave exactly as the old softwrae...

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi! Michiel,

On Sun, 17 Sep 17, you wrote to me:

MvdV> What I always find remarkable is that when pwople change
MvdV> software, after a while they always want the new software
MvdV> to behave exactly as the old softwrae...

Weird, isn't it. It's not a want in this case; I won't lose any sleep if nothing comes of the idea. I asked first, Michiel.

How's the weather over there at the moment? ;-)

Cheers,
Paul.

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

On 2017 Sep 16 22:38:00, you wrote to me:

FMail completely ignores a FREQ from me to my main node,

That's by design. Freq's are not really the domain of a mail
processor/tosser.

right but it is the only thing in position to perform this feat...

Isn't there software more geared towards file transfers in fidonet,
that can do this?

no, there's not... originating FREQs has generally always been done by creating
a netmail MSG... mail tossers, mailers and/or MSG tools performed whatever steps were needed to convert the MSG to the proper FREQ format needed by the destination system... frontdoor handled them transparently and sent whatever was needed to the remote... binkd doesn't have the intelligence for this so it has to rely on the mail tosser or some tool like bonk (if bonk can do the conversion) to do it and place the REQ files in the BSO for binkd to deliver...
at one time i had a special tool specifically to process REQ files arriving on my frontdoor system because FD didn't do REQ files at that time... there's at least two formats that i'm aware of... REQ and whatever the other one is... in today's world, REQ is most used because binkd converts it to SRIF to feed to a FREQ processor like allfix so that allfix can go find the files and queue them for delivery during this live connection... the problem is that REQ with binkd requires manual intervention that wasn't needed years ago... there are some huge regressions in the network with the widespread use of binkd and only a few
remember how to do some of those things manually...

Maybe something like allfix? (Just guessing)

allfix is just a FREQ processor that handles the inbound request and queues up the response(s) and files requested...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Life is painting a picture, not doing a sum.
---
* Origin: (1:3634/12.73)

Hi Paul,

On 2017-09-17 21:15:00, you wrote to me:

Can I nominate another?

You can nominate anything you want...

I will anyway: has anyone commented on the paucity of output from
'ftools stat', yet? ;-)

And I learned a new English word: "paucity"...

You're the first.

I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...

I'm mildly interested. The ftools stat function is probably a remnant from the time fmail only supported the hudson message base. I never used it myself. Aren't there external utils that can do stats on jam areas?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 09/18/2017 04:33 AM, you wrote:

And I learned a new English word: "paucity"...
You're the first.

I'm happy to be of assistance. WARNING: you may already realize that English is my first language but you might be surprised to learn that I /failed/ at it as a formal subject in high school. :)

I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...

I'm mildly interested. The ftools stat function is probably a remnant from the time fmail only supported the hudson message base. I never used it myself.

Ah, yes. I had thought the same myself, and that it was designed as a diagnostic tool rather than as an informative one.

To take a step backwards for a second: you already know bad my C programming skill is. That's a fact. I had cause to give the CrashMail sources a cursory look over and saw a possibility of perhaps grafting Johan Billing's statistics analysis code into FMail. It seemed to be fairly modular. I looked at one routine that delivered two functions: read stats, or, write stats. I do not know how it sat in the whole puzzle that is CM II, to deliver a report.

Aren't there external utils that can do stats on jam areas?

Ah, yes. I've spotted one possibility of Michiel's manufacture, on his website. I will explore that further, again.

Thank you for your time, Wilfred.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)