• hpt moving/changing netmail?

    From Eric Renfro@1:135/371 to All on Tuesday, July 21, 2015 15:53:51
    Gimme a bone here.. I'm trying to do something a little out of the ordinary, maybe, but here goes.

    I use Synchronet for my BBS, and it has a wierd level of support for NetMail/FTN in general. sbbsecho lets be have it not delete imported/exported netmail, but on the case of doing so, it will repeatedly re-send the netmail endlessly while it remains in the /sbbs/netmail/*.msg format/path.

    I need a means, if it's hpt or something, to migrate those to another directory and even possibly different format (Squish maybe?), that I can use for GoldEd/MsgEd that I can also then pack into my BSO outbound stuff. Basically everything in /sbbs/netmail/*.msg I need to append to a different netmail mailbox, and either delete them or I can just rm *.msg no problem.

    I've thought about writing a bash script to do this, and it could work, but it wouldn't be well maintained, such as packing/renumbering, etc.. Wouldn't be done so well. ;)

    Anyone have any ideas on this? I need it because Synchronet does have limits on how it handles Netmail, including the fact that it won't let me choose the specific netmail address to use on outgoing, when I have a zone with multiple AKAs. It'll only let me use the first matching AKA. heh

    )))[Psi-Jack -//- Decker]

    ... Failure is a measurement that depends on the standard applied.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From Alan Ianson@1:153/757 to Eric Renfro on Tuesday, July 21, 2015 13:16:16
    Hello Eric,

    I need a means, if it's hpt or something, to migrate those to another directory and even possibly different format (Squish maybe?), that I can use for GoldEd/MsgEd that I can also then pack into my BSO outbound stuff. Basically everything in /sbbs/netmail/*.msg I need to append to a different netmail mailbox, and either delete them or I can just rm *.msg no problem.

    If you have the two areas configured in fidoconfig, you could select the message you want to copy/move to the other area in golded using the m key. You could select multiple msgs to copy/move at once with the spacebar and then use the m key do what you need to do with them.

    You could use whatever storage format you prefer. *.MSG, Jam or Squish.

    Ttyl :-),
    Al

    ... This message uses 100% recycled electrons
    --- GoldED+/LNX 1.1.5-b20150715
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Eric Renfro@1:135/371 to Alan Ianson on Tuesday, July 21, 2015 16:52:12
    Re: hpt moving/changing netmail?
    By: Alan Ianson to Eric Renfro on Tue Jul 21 2015 01:16 pm

    I need a means, if it's hpt or something, to migrate those to
    another directory and even possibly different format (Squish
    maybe?), that I can use for GoldEd/MsgEd that I can also then pack
    into my BSO outbound stuff. Basically everything in
    /sbbs/netmail/*.msg I need to append to a different netmail mailbox,
    and either delete them or I can just rm *.msg no problem.

    If you have the two areas configured in fidoconfig, you could select the message you want to copy/move to the other area in golded using the m key. You could select multiple msgs to copy/move at once with the spacebar and then use the m key do what you need to do with them.

    You could use whatever storage format you prefer. *.MSG, Jam or Squish.

    While that's useful, I need this to be done right after an sbbsecho call so that it doesn't run again and re-export the netmail in an endless loop. So, if I, or another user sends netmail from within Synchronet, my plan is to tell sbbsecho not to delete which it normally does do, but in doing so, if the outbound *.msg files remain there, every time sbbsecho runs, it'll send it again, and again and again, endlessly. It doesn't seem to care if it's marked Unsent or not.

    )))[Psi-Jack -//- Decker]
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From Joe Delahaye@1:249/303 to Eric Renfro on Tuesday, July 21, 2015 19:19:29
    Re: hpt moving/changing netmail?
    By: Eric Renfro to All on Tue Jul 21 2015 15:53:51

    Anyone have any ideas on this? I need it because Synchronet does have limits on how it handles Netmail, including the fact that it won't let me choose the specific netmail address to use on outgoing, when I have a zone with multiple AKAs. It'll only let me use the first matching AKA. heh


    It will let you use whatever you define in your nodes setup. Just set the AKA as a different node. Your mailer should be the one that deletes sent mail, if it is set to Kill Send.



    ... I got some powdered water, but I don't know what to add.
    --- SBBSecho 2.27-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
  • From Alan Ianson@1:153/757 to Eric Renfro on Tuesday, July 21, 2015 18:44:44
    Hello Eric,

    While that's useful, I need this to be done right after an sbbsecho call so that it doesn't run again and re-export the netmail in an endless loop. So, if I, or another user sends netmail from within Synchronet, my plan is to tell sbbsecho not to delete which it normally does do, but in doing so, if the outbound *.msg files remain there, every time sbbsecho runs, it'll send it again, and again and again, endlessly. It doesn't seem to care if it's marked Unsent or not.

    So you need this to automatically and reliably happen after every toss?

    Years ago I used to do that with CFRoute under OS/2. CFR is in the husky stuff but it doesn't compile here.

    Netmgr is also a strong possibility. I have not tried to do that in many, many years but I used netmgr or CFR to do things that squish wouldn't/couldn't do when that was my tosser. JAM support is broken in netmgr (or is it xmsgapi) so I think you would need to use squish. It's also possible to build against husky's smapi but I haven't tried.

    andrew clarke has netmgr and friends available from his svn site. Below is a snippit from a recent post in the artware echo


    ==== Begin "artware.txt" ====
    = ARTWARE (1:153/757) =========================================================
    Msg : 2 of 6
    From : andrew clarke 3:633/267 01 Jul 15 01:00:00
    To : All
    Subj : Artware updates (autopost) ===============================================================================

    Artware software
    ================

    Note: The latest version of this document is available via SVN. See
    the end of the document for more information.


    Status
    ------

    The software timEd, NetMgr and WIMM have all been ported to UNIX. In
    years gone by these programs were distributed as shareware by Gerard
    van Essen under the name 'Artware', however in late 2000 they were
    released as open source under the GNU General Public Licence (GPL) and
    uploaded to http://www.nicestories.com/fidonet/ (last accessed
    2013-09-20).

    Most of the work porting timEd to UNIX was done by Oliver Grimm.
    Currently the Windows port of timEd is only stable, and semi-usable,
    when compiled using Cygwin. To date there has been no attempt to port
    it back to OS/2 or DOS. Contributions are welcome though! The latest
    version is stable under Linux, FreeBSD, BeOS and Mac OS X.

    WIMM should compile under Windows, UNIX, OS/2, BeOS & 32-bit DOS.
    There has been a report of instability under 32-bit DOS, but this
    cannot be replicated by me. It has been stable under FreeBSD during
    testing.

    NetMgr is the most recent port, thanks to Bo Simonsen. Currently it
    only compiles under UNIX (Linux/FreeBSD) and BeOS. It will probably
    also compile under Cygwin. It won't compile out of the box for OS/2,
    Windows or 32-bit DOS using Watcom, but shouldn't need too much work
    to make this possible. It has been stable under FreeBSD and BeOS
    during testing, but has not been exhaustively tested.

    All three require the latest version of XMSGAPI if you wish to compile
    from source. XMSGAPI is a port of the Squish MSGAPI written by Scott
    Dudley and released under the GNU Lesser Public Licence.


    Downloading
    -----------

    An anonymous SVN server has been set up for timEd, WIMM, NetMgr and
    XMSGAPI. If you have a command-line SVN client installed you can
    retrieve the latest version of the timEd source code using the
    following command:

    svn co svn://svn.ozzmosis.com/timed

    For WIMM, NetMgr and XMSGAPI, replace 'timed' with 'wimm', 'netmgr' or 'xmsgapi':

    svn co svn://svn.ozzmosis.com/wimm
    svn co svn://svn.ozzmosis.com/netmgr
    svn co svn://svn.ozzmosis.com/xmsgapi


    Contributing
    ------------

    You can make changes to the source code or documentation of any of
    these programs and have it incorporated into the main SVN repository.

    If you'd like write access to the SVN at svn.ozzmosis.com please
    send netmail to Andrew Clarke at FidoNet node 3:633/267 or e-mail mail@ozzmosis.com with the username and password you wish to use.


    Updates
    -------

    The latest version of this document is posted on the 1st and 15th of
    every month in the FidoNet ARTWARE echo. It is also available via
    SVN as 'artware.txt', using the command:

    svn co svn://svn.ozzmosis.com/fidonet/

    -+-
    + Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

    ==== End "artware.txt" ====

    Ttyl :-),
    Al

    ... Admit Nothing..... Deny EVERYTHING..... Demand PROOF!
    --- GoldED+/LNX 1.1.5-b20150715
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Eric Renfro on Tuesday, July 21, 2015 19:42:26
    Hello Eric,

    So you need this to automatically and reliably happen after every toss?

    Thinking more about this.. this config is going to be a peice of work in an ongoing way.. ;)

    Synchronet is still being developed and I believe they are planning a release soon. I think someone should ask the developers about this and see if it's possible to mark the affected msgs sent and not resend them again and again.

    I don't have all the details and don't know exactly what is happening or why but I would be inclined to talk to them and see what they say.

    Ttyl :-),
    Al

    ... When your work speaks for itself, don't interrupt
    --- GoldED+/LNX 1.1.5-b20150715
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Eric Renfro@1:135/371 to Joe Delahaye on Tuesday, July 21, 2015 23:34:07
    Re: hpt moving/changing netmail?
    By: Joe Delahaye to Eric Renfro on Tue Jul 21 2015 07:19 pm

    Anyone have any ideas on this? I need it because Synchronet does
    have limits on how it handles Netmail, including the fact that it
    won't let me choose the specific netmail address to use on outgoing,
    when I have a zone with multiple AKAs. It'll only let me use the
    first matching AKA. heh


    It will let you use whatever you define in your nodes setup. Just set the AKA as a different node. Your mailer should be the one that deletes sent mail, if it is set to Kill Send.

    Yeah, seems it's actually an sbbsecho bug that it's not marking the SENT status and also packing it up to send, repeatedly. Rob's working on the problem and already put in one update, that has yet to fix the problem. ;)

    )))[Psi-Jack -//- Decker]

    ... Massachusetts has the best politicians money can buy.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From Eric Renfro@1:135/371 to Alan Ianson on Tuesday, July 21, 2015 23:54:21
    Re: hpt moving/changing netmail?
    By: Alan Ianson to Eric Renfro on Tue Jul 21 2015 07:42 pm

    So you need this to automatically and reliably happen after every
    toss?

    Thinking more about this.. this config is going to be a peice of work in an ongoing way.. ;)

    Synchronet is still being developed and I believe they are planning a release soon. I think someone should ask the developers about this and see if it's possible to mark the affected msgs sent and not resend them again and again.

    Yep. I said that I reported the bug in my last post, actually. It's being worked on. Just the "fix" didn't work, so I'm continuing to report. :)

    )))[Psi-Jack -//- Decker]

    ... Chuck Norris can divide by zero.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From mark lewis@1:3634/12.73 to Eric Renfro on Tuesday, July 21, 2015 17:22:28

    21 Jul 15 15:53, you wrote to All:

    Gimme a bone here.. I'm trying to do something a little out of the ordinary, maybe, but here goes.

    I use Synchronet for my BBS, and it has a wierd level of support for NetMail/FTN in general. sbbsecho lets be have it not delete imported/exported netmail, but on the case of doing so, it will repeatedly re-send the netmail endlessly while it remains in the /sbbs/netmail/*.msg format/path.

    the mail should be marked as SENT the first time it is exported... you should check to this attribute it being set...

    )\/(ark

    ... Reality is something you rise above.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Eric Renfro on Tuesday, July 21, 2015 17:24:16

    21 Jul 15 16:52, you wrote to Alan Ianson:

    tell sbbsecho not to delete which it normally does do, but in doing so, if the outbound *.msg files remain there, every time sbbsecho runs, it'll
    send
    it again, and again and again, endlessly. It doesn't seem to care if it's marked Unsent or not.

    then that's a bug that DM or stephen need to take a look at and fix if it is true...

    )\/(ark

    ... Empathy is the most revolutionary emotion. - Gloria Steinem
    ---
    * Origin: (1:3634/12.73)
  • From Eric Renfro@1:135/371 to mark lewis on Wednesday, July 22, 2015 16:49:28
    Re: hpt moving/changing netmail?
    By: mark lewis to Eric Renfro on Tue Jul 21 2015 05:22 pm

    Gimme a bone here.. I'm trying to do something a little out of the
    ordinary, maybe, but here goes.

    I use Synchronet for my BBS, and it has a wierd level of support for
    NetMail/FTN in general. sbbsecho lets be have it not delete
    imported/exported netmail, but on the case of doing so, it will
    repeatedly re-send the netmail endlessly while it remains in the
    /sbbs/netmail/*.msg format/path.

    the mail should be marked as SENT the first time it is exported... you should check to this attribute it being set...

    Yep.. Come to find out, it wasn't being set as sent after being
    packed, nor did sbbsecho care if it was sent or unsent.

    I've got Rob looking into this, though his first code revision caused more problems, but did at least stop the endless cycle of re-sending the netmail. After the code patch, it just sent it 3 times. Once to the destination (which was a point-node, and the point node tosser thought it was addressed to the boss node), then bounced back empty, then bounced back to the point node empty, finally dying there. :)

    I'm hoping to resolve this at an sbbsecho level since it seems to be where the problem child is. Despite 20 years of nobody complaining about this, apparently nobody has actually tried to use it /and/ keep their fido *.msg netmail for external use. ;)

    )))[Psi-Jack -//- Decker]

    ... He who laughs, lasts.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From mark lewis@1:3634/12.73 to Joe Delahaye on Wednesday, July 22, 2015 21:56:36

    21 Jul 15 19:19, you wrote to Eric Renfro:

    Anyone have any ideas on this? I need it because Synchronet does have
    limits on how it handles Netmail, including the fact that it won't
    let me choose the specific netmail address to use on outgoing, when I
    have a zone with multiple AKAs. It'll only let me use the first
    matching AKA. heh

    It will let you use whatever you define in your nodes setup. Just set
    the AKA as a different node. Your mailer should be the one that
    deletes sent mail, if it is set to Kill Send.

    you're thinking of the older file attach mailers which manage their own netmail
    areas... binkd has no such mechanism... binkd relies on the tosser to mark mail
    as sent or to delete it when it is packed for transmission into PKT files...

    )\/(ark

    ... Argue if you must . . . just remember I'm right!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Alan Ianson on Wednesday, July 22, 2015 21:58:22

    21 Jul 15 18:44, you wrote to Eric Renfro:

    While that's useful, I need this to be done right after an sbbsecho
    call so that it doesn't run again and re-export the netmail in an
    endless loop. So, if I, or another user sends netmail from within
    Synchronet, my plan is to tell sbbsecho not to delete which it
    normally does do, but in doing so, if the outbound *.msg files remain
    there, every time sbbsecho runs, it'll send it again, and again and
    again, endlessly. It doesn't seem to care if it's marked Unsent or
    not.

    So you need this to automatically and reliably happen after every toss?

    not a toss... tossing is inbound... he needs outbound scanning to recognise that the message has already been sent and not scan it out again... that would be something in sbbsecho that needs adjustment...

    )\/(ark

    ... I may grow old, but I *refuse* to grow up! ;*)
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Joe Delahaye on Thursday, July 23, 2015 10:21:06

    23 Jul 15 09:26, you wrote to me:

    you're thinking of the older file attach mailers which manage their
    own netmail areas... binkd has no such mechanism... binkd relies on
    the tosser to mark mail as sent or to delete it when it is packed for
    transmission into PKT files...

    As far as I know it is the job of the mailer to mark a message as sent or not.

    you are thinking of FD and friends... they are File Attach mailers and they pack netmail messages in their netmail area on their own... binkd and friends cannot do that because they do not have any idea what a netmail area is... binkd and friends rely on the tosser to do the same job that FA mailers spoiled
    us with... the truth is that FA mailers do perform some tossing and scanning functions like a tosser but they are limited strictly to netmail in only one netmail area...

    Tossers only prepare for transmission. Now, I agree, I am not very familiar how binkd works, but, I thought there were some settings in
    the config to do something like that.

    binkd and other similar BSO mailers only read and react to files of specific nameing formats in their outbound directories... they don't care what is in the
    files... only that they can read their names to send and delete them... only ?LO files are parsed by BSO mailers and that so they know which other files to send that do not have the hex xxxxyyyy naming format... BSO is more primitive than the other formats used by FA mailers...

    )\/(ark

    ... Free Love, n. - All that most can afford after taxes.
    ---
    * Origin: (1:3634/12.73)
  • From Joe Delahaye@1:249/303 to mark lewis on Thursday, July 23, 2015 09:26:47
    Re: hpt moving/changing netmail?
    By: mark lewis to Joe Delahaye on Wed Jul 22 2015 21:56:36

    you're thinking of the older file attach mailers which manage their own netmail
    areas... binkd has no such mechanism... binkd relies on the tosser to mark mail
    as sent or to delete it when it is packed for transmission into PKT files...

    As far as I know it is the job of the mailer to mark a message as sent or not. Tossers only prepare for transmission. Now, I agree, I am not very familiar how binkd works, but, I thought there were some settings in the config to do something like that.
    --- SBBSecho 2.27-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
  • From Eric Renfro@1:135/371 to Joe Delahaye on Thursday, July 23, 2015 15:00:59
    Re: hpt moving/changing netmail?
    By: Joe Delahaye to mark lewis on Thu Jul 23 2015 09:26 am

    you're thinking of the older file attach mailers which manage their
    own netmail
    areas... binkd has no such mechanism... binkd relies on the tosser
    to mark mail
    as sent or to delete it when it is packed for transmission into PKT
    files...

    As far as I know it is the job of the mailer to mark a message as sent or not. Tossers only prepare for transmission. Now, I agree, I am not very familiar how binkd works, but, I thought there were some settings in the config to do something like that.

    Well, you are partially correct.

    ArcMail/Attach-mail mailers used "Stored Messages", FTS-1 style, meaning they directly utilize the *.msg files and in monitoring and in transmission, they are read, attached, and changed.

    binkd is BSO/FLO style mailer, which means it doesn't use "Stored Messages", instead, NetMail is packed into PKTs and shipped that way. Combined with an .out file in a specific directory matching zone, net, node, and point in a specific hexadecimal naming convention.

    That's the baseline fundamental differences. I know, when I ran my BBS back in the day, I always /preferred/ Arcmail/Attachmail style, using InterMail,
    simply because I hated BSO style, especially BinkleyTerm, Portal of Power was okay, but BSO-style still.

    So, while using BSO-style mailing, once netmail is packed into a PKT for delivery, it's technically "sent" in terms of the concept, it's been processed for delivery. It's up to the mailer to try to ship it from there from that.

    Another point of interest. ArcMail/Attach-Mail could do their own routing, while BSO/FLO relied on the packer to route it.

    )))[Psi-Jack -//- Decker]

    ... If you've seen one REDWOOD tree, you've seen 'em all.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From Nicholas Boel@1:154/701 to mark lewis on Thursday, July 23, 2015 19:28:38
    Hello mark,

    On 22 Jul 15 21:56, mark lewis wrote to Joe Delahaye:

    you're thinking of the older file attach mailers which manage their
    own netmail areas... binkd has no such mechanism... binkd relies on
    the tosser to mark mail as sent or to delete it when it is packed for transmission into PKT files...

    I think I asked this question recently to Eric that was getting updates from DM/Rob recently.. but, If a tosser does mark something kill/sent, will binkd delete it?

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20150715
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)
  • From Eric Renfro@1:135/371 to Nicholas Boel on Thursday, July 23, 2015 23:28:38
    Re: Re: hpt moving/changing netmail?
    By: Nicholas Boel to mark lewis on Thu Jul 23 2015 07:28 pm

    you're thinking of the older file attach mailers which manage their
    own netmail areas... binkd has no such mechanism... binkd relies on
    the tosser to mark mail as sent or to delete it when it is packed
    for transmission into PKT files...

    I think I asked this question recently to Eric that was getting updates from DM/Rob recently.. but, If a tosser does mark something kill/sent, will binkd delete it?

    Hehe. That's one of the funny things about BSO/FLO mailers. Take a good look at the binkd configuration file and notice something very specific. There is no netmail directory configuration option. :)

    That there should kind of answer your question, no?

    )))[Psi-Jack -//- Decker]

    ... Never try to out-stubborn a cat.
    --- SBBSecho 2.27-Linux
    * Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Thursday, July 23, 2015 23:43:14

    23 Jul 15 19:28, you wrote to me:

    you're thinking of the older file attach mailers which manage their
    own netmail areas... binkd has no such mechanism... binkd relies on
    the tosser to mark mail as sent or to delete it when it is packed for
    transmission into PKT files...

    I think I asked this question recently to Eric that was getting
    updates from DM/Rob recently.. but, If a tosser does mark something kill/sent, will binkd delete it?

    no, the tosser should do that once it has packed the message into a PKT... at that point, it is "sent" for all intents and purposes concerning BSO operations... the actual transmission is handled by the mailer and has nothing to do with the netmail directory...

    )\/(ark

    ... The Oracle has pondered your question deeply.
    ---
    * Origin: (1:3634/12.73)
  • From Matt Bedynek@1:19/10 to mark lewis on Friday, July 24, 2015 01:11:54
    mark,

    Thursday July 23 2015 10:21, you wrote to Joe Delahaye:

    you are thinking of FD and friends... they are File Attach mailers and they pack netmail messages in their netmail area on their own... binkd
    and friends cannot do that because they do not have any idea what a netmail area is... binkd and friends rely on the tosser to do the same
    job that FA mailers spoiled us with... the truth is that FA mailers do perform some tossing and scanning functions like a tosser but they are limited strictly to netmail in only one netmail area...

    I never was really fond of arcmailattach because to cluttered my netmail area. :-) The only thing I did not like about BSO is that it sometimes left trash (zero byte files) laying around - especially for removed links. Nothing that was functionally wrong just felt dirty on system with many links. Filebox (with LFNs) is far better because one can simply drop files into a directory whether system is busy or not. A mailer can be made aware to send mail first, the archives, and lastly .TIC files (so as not to trip bad tic). If a developer wanted to get really creative could read tic files to see which archive/tic pair should be sent. Also made scripting one's own support for FTP driven fido way easier!

    BSO is more primitive than the other formats used by FA mailers...

    Older yes.... primitive? Not so sure. I never felt limited by what I could do
    with it.

    Take care,

    Matt

    ---
    * Origin: The Byte Museum - An IPV6 Capable System (1:19/10)
  • From Joe Delahaye@1:249/303 to Eric Renfro on Friday, July 24, 2015 09:25:05
    Re: hpt moving/changing netmail?
    By: Eric Renfro to Joe Delahaye on Thu Jul 23 2015 15:00:59

    Well, you are partially correct.

    ArcMail/Attach-mail mailers used "Stored Messages", FTS-1 style, meaning they directly utilize the *.msg files and in monitoring and in transmission, they are read, attached, and changed.

    binkd is BSO/FLO style mailer, which means it doesn't use "Stored Messages", instead, NetMail is packed into PKTs and shipped that way. Combined with an .out file in a specific directory matching zone, net, node, and point in a specific hexadecimal naming convention.


    Yes, and the hexidecimal naming convention is confusing without a converter <G>
    At least with Arcmail attach, I knew what was going where, and I could manage it if required. With BSO style it is difficult. Can be fixed to some extent using file boxes


    That's the baseline fundamental differences. I know, when I ran my BBS back in the day, I always /preferred/ Arcmail/Attachmail style, using InterMail, simply because I hated BSO style, especially BinkleyTerm, Portal of Power was okay, but BSO-style still.

    I liked Intermail. It did PCBoard natively <G> Had it been a 32 bit Front End, I would still be using it, even though I am now using Synchronet. I did use it for quite a while actually, before switching to REX, and now Binkd.


    So, while using BSO-style mailing, once netmail is packed into a PKT for delivery, it's technically "sent" in terms of the concept, it's been processed for delivery. It's up to the mailer to try to ship it from there from that.

    Another point of interest. ArcMail/Attach-Mail could do their own routing, while BSO/FLO relied on the packer to route it.

    Yes, and that was another point that I had difficulty with, and still do on occassion.



    ... You can tell when politicians are lying...They move their lips.
    --- SBBSecho 2.27-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
  • From mark lewis@1:3634/12.73 to Matt Bedynek on Friday, July 24, 2015 11:10:16

    24 Jul 15 01:11, you wrote to me:

    you are thinking of FD and friends... they are File Attach mailers
    and they pack netmail messages in their netmail area on their own...
    binkd and friends cannot do that because they do not have any idea
    what a netmail area is... binkd and friends rely on the tosser to do
    the same job that FA mailers spoiled us with... the truth is that FA
    mailers do perform some tossing and scanning functions like a tosser
    but they are limited strictly to netmail in only one netmail area...

    I never was really fond of arcmailattach because to cluttered my
    netmail area. :-)

    you fell into the same misunderstanding that many others also fell into... i did for a long time, as well... then i wised up one day when i was rereading some mailer and tosser documentation... the key is that the mailer's and tosser's netmail areas are shared between them but the sysop's netmail area should be elsewhere to keep his mail from being mixed in with that being managed by the mailer and tosser... whether the sysop's netmail area is another
    MSG area or some other message base format doesn't matter as long as the tosser
    can import/export netmails to/from it to the software managed netmail area used
    by the mailer and tosser... it may be that the sysop would place their netmail in the same area as their BBS users' netmail instead of their own private area... the thing is that it all comes down to how things are configured...

    The only thing I did not like about BSO is that it sometimes left
    trash (zero byte files) laying around - especially for removed links.

    not sure what files you are talking about but if they are/were mail bundles, they are left as zero bytes so the tosser can see that they've been sent and can increment the extension... using a zero byte file on the drive keeps the tosser from having to manage some sort of database with this information...

    Nothing that was functionally wrong just felt dirty on system with
    many links.

    it is SOP with AM/FA mailers ;)

    Filebox (with LFNs) is far better because one can simply
    drop files into a directory whether system is busy or not.

    true to a point... that point being that interfacing with hybrid systems using both BSO and AM/FA mailers is somewhat more complicated...

    A mailer can be made aware to send mail first, the archives, and
    lastly .TIC files (so as not to trip bad tic).

    most mailers do this after learning the hard lessons over the years ;)

    If a developer wanted to get really creative could read tic files to
    see which archive/tic pair should be sent.

    true but that's a little much... just send the mail first, then the files and finally the tics... there can be no problems with that ordering... or am i/we missing something else?

    Also made scripting one's own support for FTP driven fido way easier!

    there is that... i do similar with my frontdoor/binkd hybrid setup... we use fileboxes for all binkd links and a glue program or two to move things from the
    AM/FA outbound to the fileboxes... inbound is all scripted in 4DOS/4OS2 .bat file stuff... even checking BSO busy flags and the like... there is a way to have frontdoor use fileboxes directly with its static queue but i don't use that right now... i don't recall if fastecho understands FD's static queue to that level and would know to place a system's outbound mail in its filebox as indicated by the STQ... what i've got works but it is a real PITA to add a new system because of the various config files that have to be adjusted... missing one breaks things in an ugly way...

    BSO is more primitive than the other formats used by FA mailers...

    Older yes.... primitive? Not so sure. I never felt limited by what I could do with it.

    definitely primitive... there's a difference between being primitive and limited... but there are limits to BSO... it is where the max zone number of 4095 comes from... with 8.3 limitations, the zone of the outbound can only go up to 0xfff ;) aside from that, BSO is pretty well defined and quite capable...
    AM/FA changed things slightly in that they automaticall handle packing and routing of netmail offering dynamic routing capabilities whereas BSO is lovingly know as "black hole" because the tosser has to pack everything and any
    rerouting changes mean that those packed messages have to be unpacked and repacked to the new destination if the current mailer event adjusts the routing... knowing what message(s) is in which PKT(s) destined to which system(s) to validate proper routing is much harder with BSO... AM/FA also allows for one single outbound instead of multiple ones... AM/FA mailers are simply a more intelligent mailer... nothing wrong with either...

    )\/(ark

    ... <smack> <smack> <whip> <whip> Oh! Ms. Co-Moderator!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Joe Delahaye on Friday, July 24, 2015 11:01:18

    24 Jul 15 09:25, you wrote to Eric Renfro:

    ArcMail/Attach-mail mailers used "Stored Messages", FTS-1 style,
    meaning they directly utilize the *.msg files and in monitoring and
    in transmission, they are read, attached, and changed.

    binkd is BSO/FLO style mailer, which means it doesn't use "Stored
    Messages", instead, NetMail is packed into PKTs and shipped that way.
    Combined with an .out file in a specific directory matching zone,
    net, node, and point in a specific hexadecimal naming convention.

    Yes, and the hexidecimal naming convention is confusing without a converter <G>

    that's easy enough to deal with, though...

    At least with Arcmail attach, I knew what was going where,

    have you ever looked into your raw AM/FA outbound? i was never able to tell what was going where by looking in the directory... luckily most tossers used the same base filename for a system's packed mail... raw PKTs, on the other hand, not so easy to tell... with packed mail using the same names for each system, it was easy enough to write a quick little script that showed each file
    and its destination at the command line level in the outbound directory... since i've switched to raw PKTs and no longer pack PKTs into bundles, this script cannot do anything because PKT names are always different...

    and I could manage it if required. With BSO style it is difficult.
    Can be fixed to some extent using file boxes

    one only needs the proper BSO tools to manage a BSO outbound... the sad part is
    that they are pretty much lost to history and the sands of time... if they are able to be found, it is possible that they won't work (runtime error 200 - division by zero while attempting to calculate the delay loop) on today's blazingly fast behemoth machines...

    )\/(ark

    ... 39. Under no circumstances should you ask a woman if she is pregnant.
    ---
    * Origin: (1:3634/12.73)
  • From Joe Delahaye@1:249/303 to mark lewis on Friday, July 24, 2015 19:56:19
    Re: hpt moving/changing netmail?
    By: mark lewis to Joe Delahaye on Fri Jul 24 2015 11:01:18

    Yes, and the hexidecimal naming convention is confusing without a
    converter <G>

    that's easy enough to deal with, though...

    Yes but it is time consuming. It would make more sense if the .try or .*lo files had a node number in the text. Sometimes there is a number, but I have no idea what its purpose is.


    At least with Arcmail attach, I knew what was going where,

    have you ever looked into your raw AM/FA outbound? i was never able to tell what was going where by looking in the directory... luckily most tossers used the same base filename for a system's packed mail... raw PKTs, on the other hand, not so easy to tell... with packed mail using the same names for each system, it was easy enough to write a quick little script that showed each file
    and its destination at the command line level in the outbound directory... since i've switched to raw PKTs and no longer pack PKTs into bundles, this script cannot do anything because PKT names are always different...

    Yes, but with Irex, and other mailers, you could look up a que and see what was where. Even Taurus has that capability.


    and I could manage it if required. With BSO style it is difficult.
    Can be fixed to some extent using file boxes

    one only needs the proper BSO tools to manage a BSO outbound... the sad part is
    that they are pretty much lost to history and the sands of time... if they are able to be found, it is possible that they won't work (runtime error 200 - division by zero while attempting to calculate the delay loop) on today's blazingly fast behemoth machines...

    Ancient technology IOW
    --- SBBSecho 2.27-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
  • From mark lewis@1:3634/12.73 to Joe Delahaye on Friday, July 24, 2015 21:45:54

    24 Jul 15 19:56, you wrote to me:

    Yes, and the hexidecimal naming convention is confusing without a
    converter <G>

    that's easy enough to deal with, though...

    Yes but it is time consuming. It would make more sense if the .try or
    .*lo files had a node number in the text. Sometimes there is a
    number, but I have no idea what its purpose is.

    i was pointing to using proper BSO tools ;)

    At least with Arcmail attach, I knew what was going where,

    have you ever looked into your raw AM/FA outbound? i was never able
    to tell what was going where by looking in the directory... luckily
    most tossers used the same base filename for a system's packed
    mail... raw PKTs, on the other hand, not so easy to tell... with
    packed mail using the same names for each system, it was easy enough
    to write a quick little script that showed each file and its
    destination at the command line level in the outbound directory...
    since i've switched to raw PKTs and no longer pack PKTs into bundles,
    this script cannot do anything because PKT names are always
    different...

    Yes, but with Irex, and other mailers, you could look up a que and see what was where. Even Taurus has that capability.

    that is completely outside what i asked about... that being, again, looking in the raw outbound directory... i guarantee that you would be just as lost there as with BSO... AM/FA is only a step above BSO and it provided built in tools for this...

    and I could manage it if required. With BSO style it is difficult.
    Can be fixed to some extent using file boxes

    one only needs the proper BSO tools to manage a BSO outbound... the
    sad part is that they are pretty much lost to history and the sands
    of time... if they are able to be found, it is possible that they
    won't work (runtime error 200 - division by zero while attempting to
    calculate the delay loop) on today's blazingly fast behemoth
    machines...

    Ancient technology IOW

    what do you think that binkd and any BSO software is?? ;)

    )\/(ark

    ... Be realistic, aim for the impossible.
    ---
    * Origin: (1:3634/12.73)
  • From Matt Bedynek@1:19/10 to mark lewis on Friday, July 24, 2015 22:43:00
    mark,

    Friday July 24 2015 11:10, you wrote to me:

    you fell into the same misunderstanding that many others also fell
    into... i did for a long time, as well... then i wised up one day when
    i was rereading some mailer and tosser documentation... the key is
    that the mailer's and tosser's netmail areas are shared between them
    but the sysop's netmail area should be elsewhere to keep his mail from being mixed in with that being managed by the mailer and tosser...

    This meant running additional tool (i.e netmgr) to move those netmail messages to/from primary? I always opt for running the lightest configuration possible so had natural adversion to doing this. I just believe netmail should contain
    only netmail. Functional components seperate from administrative components.

    not sure what files you are talking about but if they are/were mail bundles, they are left as zero bytes so the tosser can see that
    they've been sent and can increment the extension... using a zero byte file on the drive keeps the tosser from having to manage some sort of database with this information...

    Not needed or an issue with hpt and filebox because bundle names use timestamp by default. More available bundle names and no overlap. Additionally, smart mailers like binkd are capable of incrementing name at receiving end even if overlap tries to occur.

    true but that's a little much... just send the mail first, then the
    files and finally the tics... there can be no problems with that ordering... or am i/we missing something else?

    Less of issue these days with high bandwidth links but I remember modem sessions lasting 30+ minutes. TIC+FILE pairs would arrive in sequence allowing
    processing to begin in background. If TIC files arrived last then processing must wait until very end of session.

    directly with its static queue but i don't use that right now... i
    don't recall if fastecho understands FD's static queue to that level
    and would know to place a system's outbound mail in its filebox as indicated by the STQ... what i've got works but it is a real PITA to
    add a new system because of the various config files that have to be adjusted... missing one breaks things in an ugly way...

    What is the FD Static queue?

    definitely primitive... there's a difference between being primitive
    and limited... but there are limits to BSO... it is where the max zone number of 4095 comes from... with 8.3 limitations, the zone of the outbound can only go up to 0xfff ;) aside from that, BSO is pretty
    well defined and quite capable... AM/FA changed things slightly in
    that they automaticall handle packing and routing of netmail offering dynamic routing capabilities whereas BSO is lovingly know as "black
    hole" because the tosser has to pack everything and any rerouting
    changes mean that those packed messages have to be unpacked and
    repacked to the new destination if the current mailer event adjusts
    the routing... knowing what message(s) is in which PKT(s) destined to which system(s) to validate proper routing is much harder with BSO... AM/FA also allows for one single outbound instead of multiple ones... AM/FA mailers are simply a more intelligent mailer... nothing wrong
    with either...

    I think zone ~100 was the highest I've ever went. Also can't recall ever having to re-route or re-pack any netmail but could simply be fading memory. There were things I did not like about either. Since I use exclusively filebox
    that deprecated past is in rearview mirror.

    I suppose BSO never bothered me as I wrote my own REXX equivalent of FIFTP when
    I ran OS/2. Whipping together a tool to understand BSO was nothing then though
    I suppose it would require some effort today. Once you go filebox you never go back. :-)


    Take care,

    Matt

    ---
    * Origin: The Byte Museum - An IPV6 Capable System (1:19/10)
  • From Joe Delahaye@1:249/303 to mark lewis on Saturday, July 25, 2015 10:33:34
    Re: hpt moving/changing netmail?
    By: mark lewis to Joe Delahaye on Fri Jul 24 2015 21:45:54

    that's easy enough to deal with, though...

    Yes but it is time consuming. It would make more sense if the .try
    or .*lo files had a node number in the text. Sometimes there is a
    number, but I have no idea what its purpose is.

    i was pointing to using proper BSO tools ;)

    Yes I saw that later in the message


    Yes, but with Irex, and other mailers, you could look up a que and
    see what was where. Even Taurus has that capability.

    that is completely outside what i asked about... that being, again, looking in the raw outbound directory... i guarantee that you would be just as lost there as with BSO... AM/FA is only a step above BSO and it provided built in tools for this...

    That is true. and to some extend all I have to do is look at the log file to see what is still in the que <G>


    Ancient technology IOW

    what do you think that binkd and any BSO software is?? ;)

    I used Arcmail attach long before I ever heard of binkd. Binkleyterm was a familiar term, but I never used it.
    --- SBBSecho 2.27-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
  • From mark lewis@1:3634/12.73 to Matt Bedynek on Saturday, July 25, 2015 11:29:22

    24 Jul 15 22:43, you wrote to me:

    you fell into the same misunderstanding that many others also fell
    into... i did for a long time, as well... then i wised up one day
    when i was rereading some mailer and tosser documentation... the key
    is that the mailer's and tosser's netmail areas are shared between
    them but the sysop's netmail area should be elsewhere to keep his
    mail from being mixed in with that being managed by the mailer and
    tosser...

    This meant running additional tool (i.e netmgr) to move those netmail messages to/from primary?

    it could, yes... if one were to place their netmail in the same areas as their bbs users' netmail, then tosser would handle it...

    I always opt for running the lightest configuration possible so had natural adversion to doing this. I just believe netmail should
    contain only netmail. Functional components seperate from
    administrative components.

    exactly and that's where the confusion stems from with AM/FA mailers... when one first starts out, they don't know or understand the difference between the mailer's netmail area and their own personal netmail area... at some point they
    may also figure out that they can also have a netmail area within their bbs for
    their users' netmails...

    not sure what files you are talking about but if they are/were mail
    bundles, they are left as zero bytes so the tosser can see that
    they've been sent and can increment the extension... using a zero
    byte file on the drive keeps the tosser from having to manage some
    sort of database with this information...

    Not needed or an issue with hpt and filebox because bundle names use timestamp by default.

    this is relatively new in FTN software... tradition has the same base bundle name per linked system... for example, here's some of the bundle names that my fastecho used to use and the systems they are for... this before i turned off archiving PKTs into bundles... you might recognise/remember some of the names ;)

    ==== Begin ====
    describe 0b6dc800.* "Bob Juge - 1:106/2000"
    describe 1b0d4211.* "Joe Rigdon - 1:151/208"
    describe 20d8fb39.* "Warren Pittman - 1:3636/505"
    describe 229e4560.* "Don Neal - 1:3636/506"
    describe 22e178fb.* "Richard Webb - 1:116/901"
    describe 235c2f57.* "Devin Somerton - 1:3636/507"
    describe 3a64d789.* "Ross Cassell - 1:123/500"
    describe 65299dbd.* "Joaquim Homrighausen - 2:201/329"
    describe 400b19cb.* "Scott Little - 3:712/848"
    describe 6dee2900.* "Bill Burton - 1:3634/15"
    describe 705e2009.* "Jerry Gause - 1:3651/9"
    describe 7a14906b.* "Bill Gordon - 1:3634/22"
    describe 7bd6fa5c.* "John Kelly - 1:3634/23"
    describe 7e99ecd9.* "Richard Miles - 1:3634/24"
    describe 7e0ceac0.* "Bruce Bodger - 1:170/400"
    describe 81a83c9f.* "Dr. Pepper - 1:10/41"
    describe 8eb6db60.* "David Calafrancesco - 1:2624/306"
    describe b20ac007.* "Andy Roberts - 1:109/921"
    describe b3d37bf8.* "Bruce Morse - 1:101/122"
    describe bc136508.* "Paul Quinn - 3:640/384"
    describe be0eb7D9.* "Leonard Erickson - 1:105/50"
    describe e34ed460.* "Paul Kerr - 1:3634/54"
    describe e601c2e5.* "Keith Kottwitz - 1:3634/53"
    describe ed0ba6c0.* "Walter Tietjen - 1:151/114"
    ==== End ====

    More available bundle names and no overlap.

    having the same bundle name makes it easier for one to tell what is going to which system but it isn't all that important... as long as the software can keep up with it, who cares? ;)

    Additionally, smart mailers like binkd are capable of incrementing
    name at receiving end even if overlap tries to occur.

    only in some cases... i have seen certain binkd configurations that fail to rename inbound files when there's a collosion... IIRC, this was related to fileboxes and the use of an inbound temp directory... i don't know if this has been fixed in recent versions and i haven't pushed it as it doesn't happen very
    often... when it was happening, it was aggrivating but that was then...

    true but that's a little much... just send the mail first, then the
    files and finally the tics... there can be no problems with that
    ordering... or am i/we missing something else?

    Less of issue these days with high bandwidth links but I remember
    modem sessions lasting 30+ minutes.

    some of mine were over an hour long... increasing my polling rate made the sessions shorter but didn't lessen the connection times when they were all tallied up :)

    TIC+FILE pairs would arrive in sequence allowing processing to begin
    in background. If TIC files arrived last then processing must wait
    until very end of session.

    that's just a procedural thing... one could send the files first, then the tics
    and lastly the mail... some prefer to get the mail first and process that in the background while the ""less important"" files and tics come in and are processed later... as far as files and their tics, the file really should be sent first to that it is available when the tic processor runs... otherwise the
    tic can/will be moved to a "badtics" area so that it isn't processed over and over for a non-existent file...

    directly with its static queue but i don't use that right now... i
    don't recall if fastecho understands FD's static queue to that level
    and would know to place a system's outbound mail in its filebox as
    indicated by the STQ... what i've got works but it is a real PITA to
    add a new system because of the various config files that have to be
    adjusted... missing one breaks things in an ugly way...

    What is the FD Static queue?

    hunh? one might say that it is similar to the dbridge static queue... basically
    it is nothing more than a binary database with the names of the files and the systems they are destined to... with a static queue, one can also designate a directory that is for a certain system... anything in that directory is sent out just like a filebox... the difference is that the binary static queue can be processed faster since it doesn't have to thrash the disk looking in various
    directories... even with a disk cache, the STQ is faster but not by much and with today's machines, probably not really as noticible as it was on a 486/20mhz system with a couple of 40meg HDs ;)

    definitely primitive... there's a difference between being primitive
    and limited... but there are limits to BSO... it is where the max
    zone number of 4095 comes from... with 8.3 limitations, the zone of
    the outbound can only go up to 0xfff ;) aside from that, BSO is
    pretty well defined and quite capable... AM/FA changed things
    slightly in that they automaticall handle packing and routing of
    netmail offering dynamic routing capabilities whereas BSO is lovingly
    know as "black hole" because the tosser has to pack everything and
    any rerouting changes mean that those packed messages have to be
    unpacked and repacked to the new destination if the current mailer
    event adjusts the routing... knowing what message(s) is in which
    PKT(s) destined to which system(s) to validate proper routing is much
    harder with BSO... AM/FA also allows for one single outbound instead
    of multiple ones... AM/FA mailers are simply a more intelligent
    mailer... nothing wrong with either...

    I think zone ~100 was the highest I've ever went.

    i don't recall what the highest zone number was that i saw listed in the OTHERNETS echo back in the day... i know that there were a lot of private FTNs around, too... before 5D FTN addressing came about, one had to be careful of the othernets they joined because it was pretty tough to keep mail for two FTNs
    using the same zone number separated if one could do it at all... 5D using FTN domain names (eight characters in length) were the solution but they require(d)
    that all BSO software (especially) be 5D aware and capable... we still see a lot of 4D software in use today... it is noticible when your fidonet outbounds are named (for example)

    /ftn/outbound/fidonet
    /ftn/outbound/fidonet.002
    /ftn/outbound/fidonet.003
    /ftn/outbound/fidonet.004

    and you also see

    /ftn/outbound/fidonet.048 (thisnet z72)
    /ftn/outbound/fidonet.049 (thisnet z73)
    /ftn/outbound/fidonet.063 (foonet z99)

    knowing that fidonet is only zones 1-6 (z5 and z6 are defunct now, though)... when what you'd rather see is this...

    /ftn/outbound/fidonet
    /ftn/outbound/fidonet.002
    /ftn/outbound/fidonet.003
    /ftn/outbound/fidonet.004
    /ftn/outbound/thisnet (thisnet z72)
    /ftn/outbound/thisnet.049 (thisnet z73)
    /ftn/outbound/foonet (foonet z99)


    Also can't recall ever having to re-route or re-pack any netmail but
    could simply be fading memory.

    it would be necessary if a link were to go down or one changed links to a different one and there was still mail waiting to be sent out to the down/previous linked system...

    There were things I did not like about either. Since I use
    exclusively filebox that deprecated past is in rearview mirror.

    fileboxes are good but they bring their own limitations and problems...

    I suppose BSO never bothered me as I wrote my own REXX equivalent of
    FIFTP when I ran OS/2. Whipping together a tool to understand BSO was nothing then though I suppose it would require some effort today. Once
    you go filebox you never go back. :-)

    hehe, i have done some REXX stuff but generally fall back to 4DOS/4OS2 on my OS/2 system... i have a 4DOS routine that does 5D BSO... it is kinda hefty but it works... it is used mainly for creating poll ?LO files in the proper outbound and checking for BSY flags so that we don't muck up a session in progress... it could be made more generic and tweaked to handle 4D but for now,
    it does what i need of it ;)

    )\/(ark

    ... Caring for the wants and needs of the needy and the wanty.
    ---
    * Origin: (1:3634/12.73)