Hello,

How do I enable crash netmail sending from my system? I am able to receive crash netmails well, but when I send a reply they go through the routed option always..

Regards,
Flavio

... What was the best thing before sliced bread?

--- Mystic BBS v1.12 A48 (macOS/64)
* Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)

On Friday April 12 2024, Flavio Bessa said the following...

How do I enable crash netmail sending from my system? I am able to
receive crash netmails well, but when I send a reply they go through
the routed option always..

In mystic -cfg go to to:

Configuration
Message Base Settings

Set Netmail Direct & Netmail Crash to Yes

Crash will have it sent right away & Direct won't route it through your uplink.


Jay

... Try milking a kangaroo, you'll get a kick out of it
--- GoldED+/LNX 1.1.5-b20240309
* Origin: Northern Realms (1:229/664)

Hello,

How do I enable crash netmail sending from my system? I am able to receive crash netmails well, but when I send a reply they go through the routed option always..

I could be wrong, but I think you mean direct, not crash. Crash just sends immediately instead of waiting for a scheduled poll. Direct means it's not routed. And this isn't very helpful because I'm not a mystic sysop, so I
don't know the answer :P.

--- shsbbs.net
Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp,
,wss) (Ports 22,23,110,21,119,8080) (ssh login 'bbs' pass 'shsbbs').


*** THE READER V4.50 [freeware]
---
* Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (1:340/1101)

Re: Crash Netmail
By: Rob Swindell to Martin Kazmaier on Fri Apr 12 2024 11:35 pm

Crash means direct (not routed) *and* immediate.

I was thinking that Crash is an odd word to use. But it makes sense now.

Most crashes are immediate. :D
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 12 Apr 2024 at 11:35p, Rob Swindell pondered and said...

Crash means direct (not routed) *and* immediate.

I really should know this by now also.

In my head I always thought it was immediate but did not put together the direct/non routed bit.

Just found some old FastEcho tosser docs and at the back of them was this table of info which may be helpful for others following along.


Appendix (C) - Message Attributes
==================

The message attributes specify, mostly, the messages aim and/or the
message status, furthermore, them determines how the mailer must treat
the outgoing NetMail messages and how your editor must handle the inco-
ming NetMail messages.. There are a lot of message attributes, standard
or not. In the table below the most common of them will be summarized.

???????????????????????????????????
? M E S S A G E A T T R I B U T E S ?
???????????????????????????????????
?ATTRIBUTE ? D E S C R I P T I O N ?
???????????????????????????????????
? ATT ?Means that the present NetMail message has a file at- ?
? ?tached to it. The path and file specification of the ?
? ?file to be sent must always be specified in the messa- ?
? ?ge subject. The message text may contain other infor- ?
? ?mations too. ?
???????????????????????????????????
? CRA ?Crash or High-Priority mail. The messages having this ?
? ?attribute set, bypass any routing statement and are, ?
? ?usually, sent directly to the addressee system. ?
???????????????????????????????????
? DIR ?This means "Direct". the presence of this attribute in ?
? (*) ?te in a NetMail message implies that it can be sent ?
? ?to this system directly (avoiding to go through in-?
? ?termediary systems). If, for example, a NetMail messa-?
? ?ge has the DIR and the HOLD attribute together, it re-?
? ?quires that only the destination system (points inclu-?
? ?ded) calls your system to be able to pickup their mail.?
???????????????????????????????????
? FRQ ?File/Request. When a NetMail message having this attri-?
? ?bute is sent, then the addressee system will consider ?
? ?it as a request to send one or more files to the reque-?
? ?sting system. The files requested must be indicated in ?
? ?the message subject. A NetMail message having this at- ?
? ?tribute set, must always be sent directly and never ?
? ?routed. ?
???????????????????????????????????
? HLD ?This means "Hold". If a NetMail message has this attri-?
? ?bute set, then the mailer doesn't route or send it un-?
? ?less the addressee system calls yours. In case of net-?
? ?mail message addressed to a point system, it will be ?
? ?delivered through its boss but only if the boss calls ?
? ?your system (this doesn't apply if the message also ?
? ?has the DIR status (seen before). ?
???????????????????????????????????
? IMM ?When a NetMail message has the "IMM" (Immediate) attri-?
? (*) ?bute set, then it will be sent immediately, ignoring ?
? ?any mailer restriction and/or qualification. So it ?
? ?will force the mailer to call the destination system ?
? ?to give it your mail. ?
???????????????????????????????????

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Re: Crash Netmail
By: Rob Swindell to Martin Kazmaier on Fri Apr 12 2024 11:35 pm

Howdy,

Crash means direct (not routed) *and* immediate.

What's the difference between "Crash" and "immediate"?


...ëîåï
--- SBBSecho 3.20-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

deon wrote to All <=-

Re: Crash Netmail
By: Rob Swindell to Martin Kazmaier on Fri Apr 12 2024 11:35 pm

Crash means direct (not routed) *and* immediate.

What's the difference between "Crash" and "immediate"?

Immediate might not be Direct (could be routed).



... There are two types of people; those who finish what they start and
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Crash means direct (not routed) *and* immediate.

What's the difference between "Crash" and "immediate"?

I'm not sure but I think immediate has priority over crash.

I have never seen/read documentation about the immediate flag so I am not sure of that.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: Re: Crash Netmail
By: Dan Clough to deon on Sun Apr 14 2024 08:46 am

... There are two types of people; those who finish what they start and

Sychronet has a "upvote message" and I really wanted to upvote just for that tagline. Unfortunately I
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Crash Netmail
By: deon to All on Sun Apr 14 2024 10:44 pm

Re: Crash Netmail
By: Rob Swindell to Martin Kazmaier on Fri Apr 12 2024 11:35 pm

Howdy,

Crash means direct (not routed) *and* immediate.

What's the difference between "Crash" and "immediate"?

"Crash" is a stored message attribute (defined in FTS-1). The meaning of "crash" is not really defined in FTS-1, but in other docs, it's clarified as meaning to send direct (not routed) and immediately. There's no "immediate" message or packet attribute.

"Immediate" is a flow file flavor (defined in FTS-5003):
"If a flow file with such a flavour exists the
mailer must try to poll a remote system without taking in
consideration any external and internal restrictions."

FTS-5003 also defines the "Continuous" flow file flavor:
"If a flow file with such flavour exists the
mailer must try to poll a remote system taking in consideration
internal restrictions but not external ones (assuming that the
remote system carries a CM flag)."

BinkIT (Synchronet's FTN/BinkP mailer) treats .d (Direct), .i, and .c flow files all the same, FWIW.
--
digital man (rob)

Rush quote #64:
He's cleaning up his systems to keep his nature pure .. New World Man
Norco, CA WX: 56.7øF, 76.0% humidity, 2 mph SSW wind, 0.07 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Jon Robertson wrote to Dan Clough <=-

Re: Re: Crash Netmail
By: Dan Clough to deon on Sun Apr 14 2024 08:46 am

... There are two types of people; those who finish what they start and

Sychronet has a "upvote message" and I really wanted to upvote
just for that tagline. Unfortunately I

Hahahaha! Well played.



... The Bagginses, they steals our taglines, preciousss...
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

On 13 Apr 2024, Paul Hayton said the following...

Can you give me an example of what's happening now and what you would
like to happen?

All right, my node is 4:801/188 and I connect to the hub at 4:80/1.

4:80/1 has a direct link to 2:292/854. Route Info at Hub states that all netmail towards 2:* should go through there.

4:801/188 has the Crash Netmail flag on at the Configuration part.

If I send a message to Bjorn Felten, 2:203/0, despite my nodelist is updated inside Mystic, netmail is routed through 4:80/1 -> 2:292/854 -> 2:203/0 instead of going directly to 2:203/0....

--- Mystic BBS v1.12 A48 (macOS/64)
* Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)

On 22 Apr 2024 at 01:26a, Flavio Bessa pondered and said...

On 13 Apr 2024, Paul Hayton said the following...

Can you give me an example of what's happening now and what you would like to happen?

All right, my node is 4:801/188 and I connect to the hub at 4:80/1.

OK

4:80/1 has a direct link to 2:292/854. Route Info at Hub states that all netmail towards 2:* should go through there.

So confirming Route Info for the echomail node 2:292/854 defined at 4:80/1 has 2:* ?? Just checking I understand this.

Also does 4:80/1 have any other echomail nodes with Zone 2 systems that are defined and active or is 2:292/854 the only one?

4:801/188 has the Crash Netmail flag on at the Configuration part.

Understood, so this just means any netmail you send is sent quickly off to it's next hop.

If I send a message to Bjorn Felten, 2:203/0, despite my nodelist is updated inside Mystic, netmail is routed through 4:80/1 -> 2:292/854 -> 2:203/0 instead of going directly to 2:203/0....

this sounds correct.

I am assuming your system routes all netmail to your HUB 4:80/1 ?

Do you have any other echomail nodes setup with systems in Fidonet on your BBS?

Based on the rule 2:* you have stated at 4:80/1 then Mystic would look to that to route all Zone 2 netmail via 2:292/854 ...so that behavior is also expected at the HUB system.

If you are wanting to send netmail direct to Bjorn at 2:203/0 then I'd suggest establish a direct link with him and add his system as an echomail node to your BBS.

Mystic will check to see if you have a direct connection with a system you are sending netmail to and if it find that, it will route the netmail directly to that echomail node and not look at the Route Info line you may (I am assuming here) have set up for your HUB system ... presume something like a Route Info statement like 1:* 2:* 3:* 4:* or similar?

Best, Paul

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Flavio Bessa wrote to Paul Hayton <=-

Can you give me an example of what's happening now and what you would
like to happen?

All right, my node is 4:801/188 and I connect to the hub at
4:80/1.

4:80/1 has a direct link to 2:292/854. Route Info at Hub
states that all netmail towards 2:* should go through there.

4:801/188 has the Crash Netmail flag on at the Configuration
part.

If I send a message to Bjorn Felten, 2:203/0, despite my
nodelist is updated inside Mystic, netmail is routed through
4:80/1 -> 2:292/854 -> 2:203/0 instead of going directly to
2:203/0....

I don't know how to set it in Mystic, but having the Crash flag set is
not enough. You also need to set a DIRECT flag. A message can have a
"Crash" status but that does not mean it will go directly to the
recipient unless it is ALSO set to DIRECT.



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

I don't know how to set it in Mystic, but having the Crash flag set is not enough. You also need to set a DIRECT flag. A message can have a "Crash" status but that does not mean it will go directly to the recipient unless it is ALSO set to DIRECT.

... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

In Mystic -cfg, under "Configuration/Message Base Settings" you'll see
options to set the Netmail crash and Netmail Direct. Select "Yes".

ogg
Sysop, Altair IV BBS
altairiv.ddns.net:2323

... Why is the man who invests all your money called a broker?

--- Mystic BBS v1.12 A49 2023/04/30 (Windows/32)
* Origin: Altair IV BBS (1:106/1)

On 22 Apr 2024, Paul Hayton said the following...

So confirming Route Info for the echomail node 2:292/854 defined at
4:80/1 has 2:* ?? Just checking I understand this.

Correct.

Also does 4:80/1 have any other echomail nodes with Zone 2 systems that are defined and active or is 2:292/854 the only one?

Is the only one.

Understood, so this just means any netmail you send is sent quickly off
to it's next hop.

Correct.

this sounds correct.

I am assuming your system routes all netmail to your HUB 4:80/1 ?

Yes, it does.

Do you have any other echomail nodes setup with systems in Fidonet on
your BBS?

No, just the HUB does.

Based on the rule 2:* you have stated at 4:80/1 then Mystic would look
to that to route all Zone 2 netmail via 2:292/854 ...so that behavior
is also expected at the HUB system.

Mystic will check to see if you have a direct connection with a system
you are sending netmail to and if it find that, it will route the
netmail directly to that echomail node and not look at the Route Info
line you may (I am assuming here) have set up for your HUB system ... presume something like a Route Info statement like 1:* 2:* 3:* 4:* or similar?

But that is the point... If I have the CRASH flag enabled for Netmail, Mystic should (according to the FTSC specs) read the nodelist, find out the Binkp address for Bjorn's system, and issue an unsecured session towards 2:203/0. That is what the other mailers do, and that is why we have nodelists in the first place...

--- Mystic BBS v1.12 A48 (macOS/64)
* Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)

Flavio Bessa wrote to Paul Hayton <=-

But that is the point... If I have the CRASH flag enabled for
Netmail, Mystic should (according to the FTSC specs) read the
nodelist, find out the Binkp address for Bjorn's system, and
issue an unsecured session towards 2:203/0. That is what the
other mailers do, and that is why we have nodelists in the first
place...

Nope. The CRASH flag is not the same as, nor does it specify, the
DIRECT flag. You need to have both set for the behavior you desire.


... So easy, a child could do it. Child sold separately.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

On 22 Apr 2024, Dan Clough said the following...

Nope. The CRASH flag is not the same as, nor does it specify, the
DIRECT flag. You need to have both set for the behavior you desire.

Well, I tried both, but the netmail keeps getting routed through 4:80/1. I am starting to think that this is the expected behavior from Mystic.

--- Mystic BBS v1.12 A48 (macOS/64)
* Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)

Hello Flavio,

On Mon, Apr 22 2024 22:07:44 +0000, you wrote:

Well, I tried both, but the netmail keeps getting routed through 4:80/1. I am starting to think that this is the expected behavior from Mystic.

The only other thing I could suggest, is to read the whatsnew.txt of the latest A49 version, and see if something has been done about it. Otherwise, at the moment, you could try to add them as a link to your system, with no password?

I thought there was something unfinished about unsecure connections, but it may have been addressed in the latest alphas.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 22 Apr 2024 at 12:07p, Flavio Bessa pondered and said...

Based on the rule 2:* you have stated at 4:80/1 then Mystic would loo to that to route all Zone 2 netmail via 2:292/854 ...so that behavio is also expected at the HUB system.

Mystic will check to see if you have a direct connection with a syste you are sending netmail to and if it find that, it will route the netmail directly to that echomail node and not look at the Route Info line you may (I am assuming here) have set up for your HUB system ... presume something like a Route Info statement like 1:* 2:* 3:* 4:* similar?

But that is the point... If I have the CRASH flag enabled for
Netmail, Mystic should (according to the FTSC specs) read the nodelist, find out the Binkp address for Bjorn's system, and issue an unsecured session towards 2:203/0. That is what the other mailers do, and that is why we have nodelists in the first place...

No. The CRASH flag won't in itself be enough for Mystic to do what you hope it will do. Also note that just because you may have run the MergeNodelists function in MUTIL this will only scan the nodelists you point to and build a text file in the data directory of Mystic. This is in turn used by the nodelist browser feature, but that feature is like looking up a phone book for a number, nothing more.

It does not impact on how Mystic deals with netmail (g00r00 may care to jump in when next active to confirm or update these thoughts ;))

Mystic has it's own logic as to how it will route netmail. Refer to whatsnew.txt to see what this is. g00r00 has documented it there. Look for 'netmail routing' in that document and read this to understand the steps Mystic takes.

If you are unhappy with the way Mystic acts, then it's best to post some feedback to this echo and suggest what you think it could do differently/better etc. and why... and then you will need to wait for the software author to reply.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

On 23 Apr 2024, Paul Hayton said the following...

No. The CRASH flag won't in itself be enough for Mystic to do what you hope it will do. Also note that just because you may have run the MergeNodelists function in MUTIL this will only scan the nodelists you point to and build a text file in the data directory of Mystic. This is
in turn used by the nodelist browser feature, but that feature is like looking up a phone book for a number, nothing more.

Yeah, that was what I was suspecting. I even tried to do a mis poll towards Bjorn's system, but it did not deliver the netmail since it was routed towards 4:80/1 by default.

Mystic has it's own logic as to how it will route netmail. Refer to whatsnew.txt to see what this is. g00r00 has documented it there. Look
for 'netmail routing' in that document and read this to understand the steps Mystic takes.

Yeah, I did go through the docs and the process is pretty smart actually.

However there is no provision for the crash logic.

If you are unhappy with the way Mystic acts, then it's best to post some feedback to this echo and suggest what you think it could do differently/better etc. and why... and then you will need to wait for
the software author to reply.

Thanks! Will do that.

... Just another prisoner of gravity!

--- Mystic BBS v1.12 A48 (macOS/64)
* Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)

Mystic has it's own logic as to how it will route netmail. Refer to whatsnew.txt to see what this is. g00r00 has documented it there. Loo for 'netmail routing' in that document and read this to understand th steps Mystic takes.

Yeah, I did go through the docs and the process is pretty smart actually.

The auto routing can really simplify things!

You are correct there is a problem with direct flag where it is not routed directly to the node - the flag does not override anything..

It has been a while so my memory is foggy but I think the reason this happened is because there was no way to specify the direct flag on a per message level within Mystic when sending Netmail. It is either every single netmail in the base gets direct or none of them do - which is a problem that needs to be resolved first. Users should be able to per-message direct a Netmail if they meet a specific ACS level configured.

Once that part is done then the tosser needs to override any auto routing and send it direct.

One challenge I could use suggestions on for the community is what happens when a netmail is flagged direct and there is no nodelist entry or the entry is there but the system doesn't answer or doesn't have an IP address/hostname etc.

... There is an exception to every rule, except this one.

--- Mystic BBS v1.12 A49 2024/05/13 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

On 13 May 2024 at 12:35a, g00r00 pondered and said...

One challenge I could use suggestions on for the community is what
happens when a netmail is flagged direct and there is no nodelist entry
or the entry is there but the system doesn't answer or doesn't have an
IP address/hostname etc.

If there's non delivery after X attempts I'd suggest an auto netmail to the sender is generated and something to sysop as well / noted in MUTIL logs.

Not sure if the logic is in there but if a netmail is routed to another Mystic system and the routing at destination sends the netmail back to the originating system... and you start getting a back and forth loop happening... there needs to be something there to detect this, cease the loop and send a netmail to the sender and sysop of the source system alerting them to the failed delivery...

Nice to see you active, hope things are going well.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)