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

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

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

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

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

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

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

ok...

 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...

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

 KE> And ALL except you have to change their control files to get back to
 KE> 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)