• CrashMail

    From AVON@46:3/103 to ALL on Thu Jan 31 19:20:17 2019
    If I want my system to accept crash mail from any system that wants to send it to me... so that's crash netmail sent directly to my agoranet or fidonet address.. how do I set my Mystic binkp up to do this?

    I have a nagging feeling I can't as I need to state echomail nodes explicitly to get bink onnections working - right?

    If I was using binkd I think the issue goes away as it could be counted as an unsecure connection at least?

    Any thoughts appreciated.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From GRYPHON@46:1/116 to AVON on Thu Jan 31 19:20:17 2019
    On 09/05/14, Avon said the following...

    If I want my system to accept crash mail from any system that wants to send it to me... so that's crash netmail sent directly to my agoranet or fidonet address.. how do I set my Mystic binkp up to do this?

    I have a nagging feeling I can't as I need to state echomail nodes explicitly to get bink onnections working - right?

    If I was using binkd I think the issue goes away as it could be counted
    as an unsecure connection at least?

    Any thoughts appreciated.

    I don't think that receiving connections is the problem. I think that sending is the problem. The issue with crash mail is that the sending nodes' mailer needs to know how to connect to you. I would think that reading the address from the nodelist would work, but I don't know of a mailer that will do that. I know that when I ran binkd, I could create a binkd.list from the nodelist, and use it as an include file to the binkd.conf file.

    With mystic, that is another matter.

    "No matter where you go, there you are!" - B. Bonzai

    --- Mystic BBS v1.10 A51 (Linux)
    * Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)
  • From AVON@46:3/103 to GRYPHON on Thu Jan 31 19:20:24 2019
    On 09/05/14, Gryphon pondered and said...

    I don't think that receiving connections is the problem. I think that sending is the problem. The issue with crash mail is that the sending nodes' mailer needs to know how to connect to you. I would think that reading the address from the nodelist would work, but I don't know of a mailer that will do that. I know that when I ran binkd, I could create a binkd.list from the nodelist, and use it as an include file to the binkd.conf file.

    Receiving was a problem for me the other day. A Z2 address could not send me anything until I set him up as an echonode in my system :-(


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 05 Sep 14 21:10, Avon wrote to All:

    If I want my system to accept crash mail from any system that wants to send it to me... so that's crash netmail sent directly to my agoranet
    or fidonet address.. how do I set my Mystic binkp up to do this?

    I have a nagging feeling I can't as I need to state echomail nodes explicitly to get bink onnections working - right?

    If I was using binkd I think the issue goes away as it could be
    counted as an unsecure connection at least?

    Any thoughts appreciated.

    Ah hah! We just found this the other day, thanks to Psi-Jack and his misconfiguration of sorts. :)

    It's in the Message Base Settings, not individual links or the editor where we thought it may be. You'll see "Netmail Crash," "Netmail Hold" and "Netmail KillSent". That's where you enable it.

    Be aware though, that if you do that as an uplink, if your downlink has that set, your system will push the netmail directly to it's destination. Mystic cannot do this yet, because it won't connect to undefined links.

    May want to wait a bit before jumping into this.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to GRYPHON on Thu Jan 31 19:20:24 2019
    Hello Gryphon,

    On 05 Sep 14 08:47, Gryphon wrote to Avon:

    I don't think that receiving connections is the problem. I think that sending is the problem. The issue with crash mail is that the sending nodes' mailer needs to know how to connect to you. I would think that reading the address from the nodelist would work, but I don't know of
    a mailer that will do that. I know that when I ran binkd, I could
    create a binkd.list from the nodelist, and use it as an include file
    to the binkd.conf file.

    With mystic, that is another matter.

    I doubt Mystic supports this (yet?). But we just went through this the past couple days, when Psi-Jack was routing a Fidonet netmail through my system to Janis. I don't have Janis configured anywhere here on my system, as I route through Ross. Well, his netmail went from my system directly to Janis anyways, because he had the "Netmail Crash" option set to yes.

    Synchronet's tosser picked up on that, and pushed the netmail directly to Janis, instead of my normal route configuration. Good thing I run binkd and use

    the BINKD.TXT nodelist format.. otherwise that netmail would have just sat on my system not knowing where to go! :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 06 Sep 14 07:28, Avon wrote to Gryphon:

    Receiving was a problem for me the other day. A Z2 address could not
    send me anything until I set him up as an echonode in my system :-(

    That's because Mystic doesn't currently support connections with people not defined in your node configuration. It's probably on the top of the TODO list, though..

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    Receiving was a problem for me the other day. A Z2 address could not
    send me anything until I set him up as an echonode in my system :-(

    A52 has had the ability to receive (via BINKP) and toss unsecured files for a couple of months now; it was the first thing I added. Unfortunately, I
    haven't gotten around to getting A52 ready for release just yet.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
  • From G00R00@46:1/127 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    That's because Mystic doesn't currently support connections with people not defined in your node configuration. It's probably on the top of the TODO list, though..

    I'm not sure if you remember but we had some dialog about this. A52 does already support unsecured receiving and inbound processing.

    If you recall when I told you it was done, you suggested I changed it so that only unsecured netmail would be imported and everything else (TIC and
    echomail) would be trashed.

    I need to go back and make those options before I can release A52.

    I was also hoping to get my Pi going so I could release A52 for the Pi too
    but I haven't had time to start on that yet either.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
  • From AVON@46:3/103 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/05/14, Access Denied pondered and said...

    It's in the Message Base Settings, not individual links or the editor where we thought it may be. You'll see "Netmail Crash," "Netmail Hold"
    and "Netmail KillSent". That's where you enable it.

    ..this is for outgoing stuff from my board... so yep, thanks was aware of
    those settings and they are all off. It's the inbound netmail from an unknown system I want to be able to handle - so I can honour a CM flag against my nodelist entry in FidoNet.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From AVON@46:3/103 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/05/14, Access Denied pondered and said...

    Receiving was a problem for me the other day. A Z2 address could not send me anything until I set him up as an echonode in my system :-(

    That's because Mystic doesn't currently support connections with people not defined in your node configuration. It's probably on the top of the TODO list, though..

    Yes I really hope so and this is exactly what I would like to be able to do... if I used binkd I think I could as I could set up some sort of unsecure directory but not with Mystic - yet :-)


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From AVON@46:3/103 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/05/14, g00r00 pondered and said...

    A52 has had the ability to receive (via BINKP) and toss unsecured files for a couple of months now; it was the first thing I added. Unfortunately, I haven't gotten around to getting A52 ready for release just yet.

    Just read this after posting an earlier comment - oh that's great thanks, looking forward to seeing this in action and being able to use it when you hatch A52. So this feature would handle both netmail and other files sent to the BBS from an unknown connection?


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From AVON@46:3/103 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/05/14, g00r00 pondered and said...

    I'm not sure if you remember but we had some dialog about this. A52 does already support unsecured receiving and inbound processing.

    If you recall when I told you it was done, you suggested I changed it so that only unsecured netmail would be imported and everything else (TIC
    and echomail) would be trashed.

    By trashed do you mean chucked into a 'bad' dir for possible manual inspection and further manual processing? Better that than just deleting it altogether I would have thought.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From ACCESS DENIED@46:1/701 to G00R00 on Thu Jan 31 19:20:24 2019
    Hello g00r00,

    On 05 Sep 14 22:37, g00r00 wrote to Access Denied:

    I'm not sure if you remember but we had some dialog about this. A52
    does already support unsecured receiving and inbound processing.

    Now that you mention it, I do remember. We just don't have access to it yet, is

    all. So in our alpha(s), it's not supported yet, but in yours.. it is. :)

    If you recall when I told you it was done, you suggested I changed it
    so that only unsecured netmail would be imported and everything else
    (TIC and echomail) would be trashed.

    Well, not so much "trashed" but placed into an unsecure inbound directory for manual processing.. leaving it up to the operator to do so.

    Maybe even including some kind of mutil option to toss unsecure mail/files, so it's easy for the operator to manually do it. Otherwise, it would just be as easy as moving the stuff from the unsecure directory to the secure one, and running mutil again.

    I need to go back and make those options before I can release A52.

    I was also hoping to get my Pi going so I could release A52 for the Pi
    too but I haven't had time to start on that yet either.

    No worries. It's still a WIP, and we all know that. You'll get to it when you can! Other than that, thanks for REconfirming that this has, in fact, been added.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 06 Sep 14 15:02, Avon wrote to Access Denied:

    ..this is for outgoing stuff from my board... so yep, thanks was aware
    of those settings and they are all off. It's the inbound netmail from
    an unknown system I want to be able to handle - so I can honour a CM
    flag against my nodelist entry in FidoNet.

    Understood. This isn't supported in A51, but will be when A52 is released.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 06 Sep 14 15:03, Avon wrote to Access Denied:

    Yes I really hope so and this is exactly what I would like to be able
    to do... if I used binkd I think I could as I could set up some sort
    of unsecure directory but not with Mystic - yet :-)

    I haven't read on from here, so I don't know if you got to g00's messages or not. But yeah, should be soon. :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 06 Sep 14 15:07, Avon wrote to g00r00:

    By trashed do you mean chucked into a 'bad' dir for possible manual inspection and further manual processing? Better that than just
    deleting it altogether I would have thought.

    Agreed. See my message regarding it and explaining what another possibility could be. :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    you hatch A52. So this feature would handle both netmail and other files sent to the BBS from an unknown connection?

    BINKP has an unsecure inbound directory, where all files received from an unknown source are saved. Then there is an option in MUTIL to toss unsecured packets and a second option to process unsecure TIC files. If these are on, it
    fully processes them as if they were secure.

    However, as AD recommended, it should never toss echomail or TIC; only netmail for the automatic unsecure. So this leaves me with two options:

    1) Add an option to say "only toss netmail" or
    2) Remove the ability to process unsecure TIC/echomail all together.

    Not sure which one to do, and I am open to suggestions.

    Tossing the ONLY netmail from unsecure but keeping the echomail is a challenge,
    because then Mystic would have to completely rebuild all of the packets that come in so that they no longer contain the Netmail messages that have already been processed.

    I wonder how tossers handle this and what options they have today?

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
  • From TESORO@46:1/132 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/05/14, Access Denied said the following...

    I doubt Mystic supports this (yet?). But we just went through this the past couple days, when Psi-Jack was routing a Fidonet netmail through my system to Janis. I don't have Janis configured anywhere here on my
    system, as I route through Ross. Well, his netmail went from my system directly to Janis anyways, because he had the "Netmail Crash" option set to yes.

    Mystic should ignore that on newly arrived messages that are intransit to
    other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct bit and i'm thinking maybe another one or two...

    FWIW: this was a bug seen years ago with other software packages and the solution in them was as above ;)

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)
  • From WKITTY42@46:1/132 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/06/14, tesoro said the following...

    Mystic should ignore that on newly arrived messages that are intransit to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct bit and i'm thinking maybe another one or two...

    actually, tess didn't write the above... /i/ wrote it when she showed it to me and let me have the keyboard... i should have waited until she logged out and wrote it on my account later when i checked the mail... ooops :redfaced:

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)
  • From ACCESS DENIED@46:1/701 to G00R00 on Thu Jan 31 19:20:24 2019
    Hello g00r00,

    On 06 Sep 14 12:27, g00r00 wrote to Avon:

    BINKP has an unsecure inbound directory, where all files received from
    an unknown source are saved. Then there is an option in MUTIL to toss unsecured packets and a second option to process unsecure TIC files.
    If these are on, it fully processes them as if they were secure.

    However, as AD recommended, it should never toss echomail or TIC; only netmail for the automatic unsecure. So this leaves me with two
    options:

    1) Add an option to say "only toss netmail" or
    2) Remove the ability to process unsecure TIC/echomail all together.

    Not sure which one to do, and I am open to suggestions.

    My suggestion would be to only toss netmail, and leave the rest untouched in the unsecure directory. All a sysop would need to do if they wished to process that tic and file and/or echomail, would be to move them to the secure inbound directory.

    Tossing the ONLY netmail from unsecure but keeping the echomail is a challenge, because then Mystic would have to completely rebuild all of
    the packets that come in so that they no longer contain the Netmail messages that have already been processed.

    I wonder how tossers handle this and what options they have today?

    Very good point. Then again, quite a few (except maybe D'Bridge) mail/file tossers are completely separate from each other as well. I do know Htick has a "toss bad tics" command line option, but I don't think that has anything to do with unsecure, just TIC files that weren't processed correctly the first time and moved to the bad folder.

    HPT also has an option to toss mail from the BAD area, but I don't see anything

    in regards to the unsecure folder. That being said, it would seem as though both of those leave it completely up to the sysop to move the contents of the unsecure inbound over to the secure inbound manually, which then they can process it.

    That being said, once it's processed, it would probably end up in the BAD folder anyways, because if it was unsecure, it was probably not from a defined link, unless you were connecting someone new and they didn't have the proper authorization via the mailer.

    I'm not completely sure with where to go with this. It would be *nice* to be able to process any netmail. Just recently there were instances where netmail ended up in someone's unsecure folder, and they didn't find it there for more than a week until someone mentioned sending something to that person. But like you said, if it's only that, and echomail/tics stayed in the unsecure folder for manual processing.. it would be a pain in the ass to search all echomail bundles/packets for any netmail that may be in them. :(

    It may just be better to leave it as you have it, and let the sysop do any of it manually. If other tossers aren't doing it I'm sure it's probably for the same reasons you've already covered. That would give the sysop a chance to (if they were so inclined) to break apart any bundles to see what the contents are (netmail or echomail) before making the decision to process it.

    Heh. Thanks for making me think it over, too! :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to TESORO on Thu Jan 31 19:20:24 2019
    Hello tesoro,

    On 06 Sep 14 15:32, tesoro wrote to Access Denied:

    Mystic should ignore that on newly arrived messages that are intransit
    to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct
    bit and i'm thinking maybe another one or two...

    FWIW: this was a bug seen years ago with other software packages and
    the solution in them was as above ;)

    Doesn't that kinda defeat the entire purpose of the crash and direct bits you're referring to?

    Also, is there some kind of FTSC standard or proposal documented on this so I can refer it to the Synchronet developers?

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to WKITTY42 on Thu Jan 31 19:20:24 2019
    Hello wkitty42,

    On 06 Sep 14 15:57, wkitty42 wrote to Access Denied:

    actually, tess didn't write the above... /i/ wrote it when she showed
    it to me and let me have the keyboard... i should have waited until
    she logged out and wrote it on my account later when i checked the
    mail... ooops :redfaced:

    No problem. But I'm not replying to you twice with the same content. :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From AVON@46:3/103 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/06/14, Access Denied pondered and said...

    My suggestion would be to only toss netmail, and leave the rest
    untouched in the unsecure directory. All a sysop would need to do if
    they wished to process that tic and file and/or echomail, would be to
    move them to the secure inbound directory.

    I support this, it's the best way forward IMHO.

    to be able to process any netmail. Just recently there were instances where netmail ended up in someone's unsecure folder, and they didn't
    find it there for more than a week until someone mentioned sending something to that person. But like you said, if it's only that, and

    This brings me to the other thing on my mind about all of this and that's something I'd find useful. If MUTIL can be configured to produce reports that could be auto posted to nominated message bases around these kinds of activity.

    1. The following files were received today (secure files report)
    2. The following files were received today (unsecure files report)
    3. The following files failed to toss (.tic bad files report)

    If we could link these reports to a template and then be able to customise it and then inject the output to nominated message areas it would be cool. Then
    as a sysop I could see at a glance in a s255 message area if I had an issue to deal with... as like AD I have found .tic's in the bad dir that have failed to toss files hatched out only by chance when looking into the dir weeks later.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
  • From WKITTY42@46:1/132 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/06/14, Access Denied said the following...

    Mystic should ignore that on newly arrived messages that are
    intransi
    to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the
    direct
    bit and i'm thinking maybe another one or two...

    Doesn't that kinda defeat the entire purpose of the crash and direct bits you're referring to?

    no because they only pertain to the system originating the netmail messages in question... no other system's routing settings should be overridden by my system's settings... consider POTS connections and i drop off netmail on your system for delivery to a node in australia... are you going to be happy when your phone bill comes in and you are the one paying for a phone call to OZ instead of me? ;)

    Also, is there some kind of FTSC standard or proposal documented on this so I can refer it to the Synchronet developers?

    not really... this comes from the "school of hard knocks" and lessons learned... this is also done when packing the mail... the local copy, if one remains, still has those bits set plus the sent bit...

    i might have something around here from historical development conversations concerning this... let me look for it... there's a lot to dig through, though...

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)
  • From WKITTY42@46:1/132 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/06/14, Access Denied said the following...

    1) Add an option to say "only toss netmail" or
    2) Remove the ability to process unsecure TIC/echomail all together.

    Not sure which one to do, and I am open to suggestions.

    My suggestion would be to only toss netmail, and leave the rest
    untouched in the unsecure directory. All a sysop would need to do if
    they wished to process that tic and file and/or echomail, would be to
    move them to the secure inbound directory.

    exactly... that's what we do now...

    also, don't worry about trying to rebuild the PKTs after tossing any netmails they may contain... i mean, sure, it would be OK to exactly duplicate the PKT right down to the name and timestamps but without the netmail but it shouldn't be necessary as that netmail, when tossed a second time, should appear as a dupe... this might also be a reason why so many other systems pack netmail and echomail into separate PKTs...

    speaking of dupes, it would also be nice for messages in the BADMAIL area to have an additional couple of hidden control lines added to them stating what echotag they were destined for, what system they arrived from and what dupe checking method was used to catch them... this way we can move them to the proper area if we determine that they are false positives or we can let the sending system know of a possible problem...

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)
  • From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 07 Sep 14 13:46, Avon wrote to Access Denied:

    My suggestion would be to only toss netmail, and leave the rest
    untouched in the unsecure directory. All a sysop would need to do
    if they wished to process that tic and file and/or echomail,
    would be to move them to the secure inbound directory.

    I support this, it's the best way forward IMHO.

    Maybe. There's still flaws in it I think. It may just be better to do as g00 has already done, and leave ALL unsecure stuff to the sysop for manual intervention. If there's a better way of doing it, I'm all ears!

    to be able to process any netmail. Just recently there were
    instances where netmail ended up in someone's unsecure folder,
    and they didn't find it there for more than a week until someone
    mentioned sending something to that person. But like you said, if
    it's only that, and

    This brings me to the other thing on my mind about all of this and
    that's something I'd find useful. If MUTIL can be configured to
    produce reports that could be auto posted to nominated message bases around these kinds of activity.

    1. The following files were received today (secure files report)
    2. The following files were received today (unsecure files report)
    3. The following files failed to toss (.tic bad files report)

    If we could link these reports to a template and then be able to
    customise it and then inject the output to nominated message areas it would be cool. Then as a sysop I could see at a glance in a s255
    message area if I had an issue to deal with... as like AD I have found .tic's in the bad dir that have failed to toss files hatched out only
    by chance when looking into the dir weeks later.

    There is a LOT of statistical stuff I would like to see. But getting the main functionality of it all working first is a definite must.

    Here, at the moment, I only use a binkd log analizer that produces the statistics you see in AGN_HUB. If it weren't for that, all hell probably would have broken loose by now with all the door game packet tossing that goes on in this network. When I see someone failing connections for a week or more, I say something to them. Otherwise I would have to analize the log myself, which I probably wouldn't do.

    The Husky software suite has all sorts of log analizers.. echomail/netmail/files/link statistics, etc. I just don't use it as my main hub, so I can't use any of it. I've definitely tinkered with it on my Golded+/hpt/htick node though, and it's impressive.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to WKITTY42 on Thu Jan 31 19:20:24 2019
    Hello wkitty42,

    On 06 Sep 14 21:58, wkitty42 wrote to Access Denied:

    Doesn't that kinda defeat the entire purpose of the crash and
    direct bits you're referring to?

    no because they only pertain to the system originating the netmail messages in question... no other system's routing settings should be overridden by my system's settings... consider POTS connections and i
    drop off netmail on your system for delivery to a node in australia...
    are you going to be happy when your phone bill comes in and you are
    the one paying for a phone call to OZ instead of me? ;)

    Phone lines/modems are a thing of the past these days (at least for me). I can understand why something was done (your explanation) about it years ago, most definitely. Nowadays it could sing a different tune, though.

    Also, is there some kind of FTSC standard or proposal documented
    on this so I can refer it to the Synchronet developers?

    not really... this comes from the "school of hard knocks" and lessons learned... this is also done when packing the mail... the local copy,
    if one remains, still has those bits set plus the sent bit...

    i might have something around here from historical development conversations concerning this... let me look for it... there's a lot
    to dig through, though...

    Just for my own knowledge, that would be awesome. Even if you'd like to netmail

    me it that would be fine.

    I'm actually leaning to be on board with you on this one. I actually mentioned this exact idea to Rob a few days ago, when we figured out that it was the crash bit on the Mystic downlink that made my system send directly to Janis, even when I didn't have her configured anywhere here.

    The only reason it made it to her is because of the BINKD.TXT I include in my binkd config. Unfortunately, it ended up in her unsecure inbound directory (I'm

    still trying to figure that one out, especially if she uses BINKD.TXT too, it should have been a passwordless secure connection), and wasn't found until about a week later. That's not a good thing, IMO.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From ACCESS DENIED@46:1/701 to WKITTY42 on Thu Jan 31 19:20:24 2019
    Hello wkitty42,

    On 06 Sep 14 22:04, wkitty42 wrote to Access Denied:

    My suggestion would be to only toss netmail, and leave the rest
    untouched in the unsecure directory. All a sysop would need to do
    if they wished to process that tic and file and/or echomail,
    would be to move them to the secure inbound directory.

    exactly... that's what we do now...

    Cool. That was just out of my own experience's opinion.. obviously. I don't want netmail to sit in an unsecure directory if I forget to look at it on a daily basis (which I definitely would forget to do so). Echomail and .tic files

    from an unsecure link? No thanks. I hook up to certain people for those things for a reason. I can look at it when I have the time, and decide on my own to put it in or delete it. :)

    also, don't worry about trying to rebuild the PKTs after tossing any netmails they may contain... i mean, sure, it would be OK to exactly duplicate the PKT right down to the name and timestamps but without
    the netmail but it shouldn't be necessary as that netmail, when tossed
    a second time, should appear as a dupe... this might also be a reason
    why so many other systems pack netmail and echomail into separate
    PKTs...

    Good point!

    speaking of dupes, it would also be nice for messages in the BADMAIL
    area to have an additional couple of hidden control lines added to
    them stating what echotag they were destined for, what system they
    arrived from and what dupe checking method was used to catch them...
    this way we can move them to the proper area if we determine that they
    are false positives or we can let the sending system know of a
    possible problem...

    I'm also good with anything that can help track problems with incoming mail as well. So I won't get in the way of this one, either. :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
  • From TESORO@46:1/132 to WKITTY42 on Thu Jan 31 19:20:24 2019
    On 09/06/14, wkitty42 said the following...

    On 09/06/14, tesoro said the following...

    actually, tess didn't write the above... /i/ wrote it when she showed it to me and let me have the keyboard... i should have waited until she logged out and wrote it on my account later when i checked the mail... ooops :redfaced:

    Thank you for clarifying that!

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)
  • From G00R00@46:1/127 to WKITTY42 on Thu Jan 31 19:20:24 2019
    netmail but it shouldn't be necessary as that netmail, when tossed a second time, should appear as a dupe... this might also be a reason why

    This is a good point, thank you for pointing that out.

    speaking of dupes, it would also be nice for messages in the BADMAIL
    area to have an additional couple of hidden control lines added to them stating what echotag they were destined for, what system they arrived
    from and what dupe checking method was used to catch them... this way we

    I actually already have that in my TODO list :) The idea being you can see the
    base, but also press one button to move it to the base it was supposed to be in
    (just in case they were incorrectly tossed there).

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
  • From WKITTY42@46:1/132 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/07/14, g00r00 said the following...

    netmail but it shouldn't be necessary as that netmail, when tossed a second time, should appear as a dupe... this might also be a reason

    This is a good point, thank you for pointing that out.

    you are welcome :)

    speaking of dupes, it would also be nice for messages in the BADMAIL area to have an additional couple of hidden control lines added to
    th
    stating what echotag they were destined for, what system they
    arrived
    from and what dupe checking method was used to catch them... this
    way

    I actually already have that in my TODO list :) The idea being you can see the base, but also press one button to move it to the base it was supposed to be in (just in case they were incorrectly tossed there).

    thank you sir! :)

    --- Mystic BBS v1.10 A51 (Windows)
    * Origin: (46:1/132)