Hello mark!

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

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

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

 ml>   submit     x:y/z INTL
 ml>   notify     errors INTL CRASH
 ml>   notify     receipt INTL
 ml>   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.

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

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

 ml> in other words, turn killsent off by default and specify it if you want
 ml> it... maybe LOCAL should be the only forced attribute and all the others
 ml> 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.

 ml> i don't know about others but i /want/ to see those emails that were
 ml> 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)