• killsent attribute

    From mark lewis@1:3634/12.73 to all on Sat Oct 27 14:59:02 2018

    how can i tell makenlng to not use the killsent attribute in the FA netmail MSG?

    my tosser sees the killsent attribute in the MSG and packs the mail for BSO delivery which leads to the mailer deleting the file once it has been delivered... i really didn't want to create a script to copy files back and forth... on my old system i was able to run a tool to specifically remove killsent but i don't know that i want to do that on this new setup... i prefer to keep the netmail as well as the file so they may be archived later...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The human animal is an unfathomable creature.
    ---
    * Origin: (1:3634/12.73)
  • From Kees van Eeten@2:280/5003.4 to mark lewis on Sat Oct 27 22:29:08 2018
    Hello mark!

    27 Oct 18 14:59, you wrote to all:

    how can i tell makenlng to not use the killsent attribute in the FA netmail MSG?

    There are two solutions and you will not like either of them.

    1. Search the source code, and remove the kill/sent bit from the attribute.
    Recompile the changed source.

    2. Do not use Makenl to transmit the files, but use something external, where
    you have more control over the atribute bits.

    For a long term solution, convince Andrew to move the definition of the
    attribute to the ctl file. But expect the answer that is was not needed in
    the last 25 or so years.

    my tosser sees the killsent attribute in the MSG and packs the mail
    for
    BSO delivery which leads to the mailer deleting the file once it has been delivered... i really didn't want to create a script to copy files back and forth... on my old system i was able to run a tool to specifically remove killsent but i don't know that i want to do that on this new setup... i prefer to keep the netmail as well as the file so they may be archived later...

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Andrew Leary@1:320/219 to mark lewis on Sun Oct 28 00:44:59 2018
    Hello mark!

    27 Oct 18 14:59, you wrote to all:

    how can i tell makenlng to not use the killsent attribute in the FA netmail MSG?

    You can't, currently. It should not be difficult to add a toggle for that to the config file. I'll take a look at it the next time I'm playing with the MakeNL code.

    Regards,

    Andrew
    Team MakeNL

    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Andrew Leary@1:320/219 to Kees van Eeten on Sun Oct 28 00:48:40 2018
    Hello Kees!

    27 Oct 18 22:29, you wrote to mark lewis:

    27 Oct 18 14:59, you wrote to all:

    how can i tell makenlng to not use the killsent attribute in the
    FA netmail MSG?

    There are two solutions and you will not like either of them.

    1. Search the source code, and remove the kill/sent bit from the attribute.
    Recompile the changed source.

    I've already located the relevant portion of msgtool.c. A quick edit there, plus a toggle added to the config file parser and it should be done in an hour or so.

    2. Do not use Makenl to transmit the files, but use something
    external, where
    you have more control over the atribute bits.

    Also an option.

    For a long term solution, convince Andrew to move the definition of
    the attribute to the ctl file. But expect the answer that is was not needed in the last 25 or so years.

    I have no problem doing this; it has never been done because nobody ever asked for it before.

    Andrew
    Team MakeNL

    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Ward Dossche@2:292/854 to Andrew Leary on Sun Oct 28 16:13:04 2018

    I've already located the relevant portion of msgtool.c. A quick edit there,
    plus a toggle added to the config file parser and it should be done in an hour or so.

    Just wondering ... whenever updates are being produced, is there also documentation that's updated ?

    \%/@rd

    --- D'Bridge 3.99 SR33
    * Origin: A man's most proud moment is when he takes a shit (2:292/854)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Sun Oct 28 12:52:40 2018

    On 2018 Oct 27 22:29:08, you wrote to me:

    For a long term solution, convince Andrew to move the definition of
    the attribute to the ctl file. But expect the answer that is was not needed in the last 25 or so years.

    while i understand, it apparently has been needed... else why would we have these?

    submit x:y/z INTL
    notify errors INTL CRASH
    notify receipt INTL
    notify self INTL

    if someone wanted killsent then we could have something like this...

    submit x:y/z INTL KILLSENT
    notify errors INTL CRASH PVT
    notify errors INTL DIRECT IMMEDIATE PVT
    notify receipt INTL KILLSENT
    notify self INTL KILLSENT

    in other words, turn killsent off by default and specify it if you want it... maybe LOCAL should be the only forced attribute and all the others added as above...

    i don't know about others but i /want/ to see those emails that were generated... i can delete or archive them later...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... "Against the run of the mill" -RUSH
    ---
    * Origin: (1:3634/12.73)
  • From Andrew Leary@1:320/219 to Ward Dossche on Sun Oct 28 16:13:40 2018
    Hello Ward!

    28 Oct 18 16:13, you wrote to me:

    Just wondering ... whenever updates are being produced, is there also documentation that's updated ?

    The changes in each new version are documented in history.txt in the distribution archives. At some point, the changes in history.txt do need to get merged into the main docs.

    Andrew

    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Andrew Leary@1:320/219 to mark lewis on Sun Oct 28 16:18:56 2018
    Hello mark!

    28 Oct 18 12:52, you wrote to Kees van Eeten:

    while i understand, it apparently has been needed... else why would we have these?

    submit x:y/z INTL
    notify errors INTL CRASH
    notify receipt INTL
    notify self INTL

    These were all in the original MakeNL program, I believe.

    if someone wanted killsent then we could have something like this...

    submit x:y/z INTL KILLSENT
    notify errors INTL CRASH PVT
    notify errors INTL DIRECT IMMEDIATE PVT
    notify receipt INTL KILLSENT
    notify self INTL KILLSENT

    Nobody has requested this until now. I'm working on it as my work schedule allows.

    in other words, turn killsent off by default and specify it if you
    want it... maybe LOCAL should be the only forced attribute and all the others added as above...

    LOCAL will be set in all MakeNL created messages, and the file attach flag for submit messages.

    i don't know about others but i /want/ to see those emails that were generated... i can delete or archive them later...

    I should be able to get it working before too long for KILL/SENT. DIRect and IMMediate would require implementing the ^aFLAGS kludge line, which I really don't see the need for, unless I receive multiple requests for it.

    Andrew

    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Kees van Eeten@2:280/5003.4 to mark lewis on Mon Oct 29 12:27:04 2018
    Hello mark!

    28 Oct 18 12:52, you wrote to me:

    For a long term solution, convince Andrew to move the definition of
    the attribute to the ctl file. But expect the answer that is was not
    needed in the last 25 or so years.

    while i understand, it apparently has been needed... else why would we have these?

    submit x:y/z INTL
    notify errors INTL CRASH
    notify receipt INTL
    notify self INTL

    You are diverting my words, I was talking about the kill sent bit not the
    mechanism of send or not sending messages.

    if someone wanted killsent then we could have something like this...

    submit x:y/z INTL KILLSENT
    notify errors INTL CRASH PVT
    notify errors INTL DIRECT IMMEDIATE PVT
    notify receipt INTL KILLSENT
    notify self INTL KILLSENT

    in other words, turn killsent off by default and specify it if you want it... maybe LOCAL should be the only forced attribute and all the others added as above...

    Your suggestion of implementation, would be correct if this would be built
    in from the start. Now however it would change the default behaviour of
    makenl.

    The new features that have been added to makenl, have all been implemented
    in such a way, that when they are not added to the control file, makenl
    will ignore the feature and behave as it has always has done.

    Ik my opinion that is a golden rule that should be adhered to.

    i don't know about others but i /want/ to see those emails that were generated... i can delete or archive them later...

    You may put any emphasis on what YOU want, but that should not lead to
    having all other users of makenl to suddenly have their messagebase clogged
    with messages, that were automatically remove as long as makenl exists.

    And ALL except you have to change their control files to get back to the
    how makenl used to work.

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Kees van Eeten@2:280/5003.4 to Andrew Leary on Mon Oct 29 12:47:04 2018
    Hello Andrew!

    28 Oct 18 00:48, you wrote to me:

    I've already located the relevant portion of msgtool.c. A quick edit there, plus a toggle added to the config file parser and it should be done in an hour or so.

    If it is trivial, by all means, add it as a feature.

    For a long term solution, convince Andrew to move the definition of
    the attribute to the ctl file. But expect the answer that is was not
    needed in the last 25 or so years.

    I have no problem doing this; it has never been done because nobody ever asked for it before.

    It has indeed not been asked before. But I cannot judge what time you have
    available to add such a feature.

    As I have written to marc, I think that irrespective of the way the feature
    is implemented, the default behavior of makenl should not change if the
    keyword is not in the control file.

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From mark lewis@1:3634/12.73 to Andrew Leary on Mon Oct 29 12:41:58 2018

    On 2018 Oct 28 16:18:56, you wrote to me:

    submit x:y/z INTL
    notify errors INTL CRASH
    notify receipt INTL
    notify self INTL

    These were all in the original MakeNL program, I believe.

    ok...

    if someone wanted killsent then we could have something like this...

    submit x:y/z INTL KILLSENT
    notify errors INTL CRASH PVT
    notify errors INTL DIRECT IMMEDIATE PVT
    notify receipt INTL KILLSENT
    notify self INTL KILLSENT

    Nobody has requested this until now. I'm working on it as my work schedule allows.

    thank you...

    in other words, turn killsent off by default and specify it if you
    want it... maybe LOCAL should be the only forced attribute and all
    the others added as above...

    LOCAL will be set in all MakeNL created messages, and the file attach
    flag for submit messages.

    yes, i didn't mention that because...

    i don't know about others but i /want/ to see those emails that were
    generated... i can delete or archive them later...

    I should be able to get it working before too long for KILL/SENT. DIRect and IMMediate would require implementing the ^aFLAGS kludge line, which I really don't see the need for, unless I receive multiple requests for it.

    in light of other discussion, sincce killsent is default, prefixing the option with a '-' could be used to turn off a default bit...

    eg: submit x:y/z INTL -KILLSENT

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Don't hurry, don't worry & don't forget to stop and smell the flowers.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Mon Oct 29 12:44:28 2018

    On 2018 Oct 29 12:27:04, you wrote to me:

    You are diverting my words, I was talking about the kill sent bit not
    the mechanism of send or not sending messages.

    sorry, i wasn't trying to do that...

    Your suggestion of implementation, would be correct if this would be
    built in from the start. Now however it would change the default
    behaviour of makenl.

    true... so i've revised my request...

    The new features that have been added to makenl, have all been
    implemented in such a way, that when they are not added to the control file, makenl will ignore the feature and behave as it has always has
    done.

    Ik my opinion that is a golden rule that should be adhered to.

    ok...

    i don't know about others but i /want/ to see those emails that were
    generated... i can delete or archive them later...

    You may put any emphasis on what YOU want, but that should not lead to having all other users of makenl to suddenly have their messagebase clogged with messages, that were automatically remove as long as
    makenl exists.

    And ALL except you have to change their control files to get back to
    the how makenl used to work.

    and this is different from the way the nodelist stuff for IP connections was implemented how? everyone got to keep their defaults until the balance swung the other way and then things were switched around... i don't see a difference but in the case of makenl, sure, we can do it the other way with

    -killsent

    in the config file meaning to NOT use that bit in the messages where it is specified, submit, notify, and errors...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The Lord to John: "Come forth & receive eternal life." John got a toaster for
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Mon Oct 29 12:48:22 2018

    On 2018 Oct 29 12:47:04, you wrote to Andrew Leary:

    As I have written to marc,

    marK, please...

    I think that irrespective of the way the feature is implemented, the default behavior of makenl should not change if the keyword is not in
    the control file.

    in retrospect and after this discussion, i agree...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... We do not tear your clothing with machinery. We do it carefully by hand. ---
    * Origin: (1:3634/12.73)
  • From Kees van Eeten@2:280/5003.4 to mark lewis on Mon Oct 29 21:53:14 2018
    Hello mark!

    29 Oct 18 12:48, you wrote to me:

    As I have written to marc,
    marK, please...

    Sorry.

    I think that irrespective of the way the feature is implemented, the
    default behavior of makenl should not change if the keyword is not in
    the control file.

    in retrospect and after this discussion, i agree...

    Thanks,

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Kees van Eeten@2:280/5003.4 to mark lewis on Mon Oct 29 22:16:40 2018
    Hello mark!

    29 Oct 18 12:44, you wrote to me:

    and this is different from the way the nodelist stuff for IP connections was implemented how? everyone got to keep their defaults until the balance swung the other way and then things were switched around... i don't see a difference but in the case of makenl, sure, we can do it the other way with

    In that period, I was not really interested in the Nodelist, moreover I think
    the approach was different between the zones.
    I am not sure, that modifications were then made to Makenl. There was some
    overloading of nodelist fields and new flags were defined.
    The first modification I remeber was reducing restrictions on the combination
    of the First field of a nodelist line and -Unpublished-
    Without that modification -Unpublished- could only be used with tpe Pvt tag.
    Later the latter was expanded, to allow -Unpublished- with Zone, Region, Host
    and Hub.

    -killsent

    in the config file meaning to NOT use that bit in the messages where it is specified, submit, notify, and errors...

    In case the "-" causes parsing problems consider "NOKillsent", where the
    characters given in capitals als the minimum, that should be used.

    This would be in line with the tags in the control file, where the minmal
    string to make the tag unique is sufficient.

    I added this as I expect that Andrew will read this message as well.

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Brother Rabbit@2:460/5858 to Kees van Eeten on Fri Nov 16 10:01:38 2018
    Hi, Kees!

    27 окт 18 22:29, Kees van Eeten -> mark lewis:

    There are two solutions and you will not like either of them.

    1. Search the source code, and remove the kill/sent bit from the attribute.
    Recompile the changed source.

    2. Do not use Makenl to transmit the files, but use something external, where
    you have more control over the atribute bits.

    In deed more. Avery time you may write own solution of a problem, like this https://yadi.sk/d/87UCO0VCFgpsEw

    ;)

    Have nice nights.
    Brother Rabbit.

    --- Коньки и ласты - что суждено отбросить, того уже не склеишь...
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Paul Quinn@3:640/1384.125 to Stas Mishchenkov on Fri Nov 16 17:58:45 2018
    Hi! Stas,

    On 11/16/2018 05:01 PM, you wrote to Kees van Eeten:

    27 ╨╛╨║╤В 18 22:29, Kees van Eeten -> mark lewis:

    There are two solutions and you will not like either of them.
    [ ...trimmed... ]
    In deed more. Avery time you may write own solution of a problem, like this https://yadi.sk/d/87UCO0VCFgpsEw

    ;)

    (That looked interesting even with just the static graphic. I only have a very
    basic Chromium install on this netbook, so any animations will not display.)

    I just wanted to say that there is a third option WRT the file-attach segments from nlmake, and that's just using a filebox for binkD. Or similar, as I have a Radius mailer on port 24554 [you knew this] that has daily competitions with binkD on who can _first_ get my region segment lodged to ZC3's mailer. Ah, I see that binkD won this afternoon.

    It was only last night that I cleaned out 219 .msg files from the fake netmail directory that I told nlmake about. 8-)

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: If it itches, it will be scratched. (3:640/1384.125)