[nos-bbs] A trial baloon for SMTP protocol modification

[George [ham] VerDuin]

Greetings.
I'd like to run a concept by the software systems guys here -- 
especially Maiko.

I ran into an old [but still existing] problem in the last few days, and 
part of working around the problem led me to consider a source change to 
the SMTP client.

Here is a description of the issue:
Each time the "smtp timer ..." expires, smtp client proceeds to scan the 
output mail queue "mqueue" and initiate smtp send process for qualifying 
mail.  This process continues until "smtp maxclients ..." is reached 
amoung other conditions.  Upon reaching the maximum process count the 
queueing process stops and ignors the remaining mail stacked in the 
queue.  Mostly this algorythm works OK until all of the active send 
processes fail to deliver, then because the algorythm starts over again 
in an identical way on the next iteration a repeating cycle of failure 
is begun.  The result is that outbound mail that fails to deliver 
prevents potentially successful mail delivery from happening.

This problem has been discussed before but is not a high enough priority 
to get fixed?  I considered several algorithm changes to address the 
problem:

    * change the scan from linear to random
    * change the starting mail item to be considered -- use the "next"
      one from the "last" iteration.

Both of these options require some significant [in my opinion] changes 
to code especially because of the many options available [like hopper, 
batching, ...], but leaves the operating practices the same for the 
sysop.  Perhaps there is a better option?

Another [and the latest] consideration modifies sysop requirements a 
little but might be a pretty good, and simple, change to jnos.  It 
operates this way:
Everything works identically to above until exceeding the maxclients 
count.  Instead of stopping the scan process, pause the scan process 
until the send process count is reduced by the natural termination of 
one active send process.  Upon reduction, now continue the scan and 
start the next mail send process.  This change would result in scanning 
the entire mqueue contents on each iteration of "smtp timer ...".  Under 
this algorythm that will require more time to complete, extending the 
"smpt timer" setting so it does not expire while the preceding scan is 
still active seems like a prudent sysop choice.

After looking over the 2.0h code base, I believe I can deliver the 
"pause" option patch to Maiko for maybe inclusion in the next jnos rev.  
The change will introduce a new timer, but there is little reason to 
make this timer settable by jnos configuration.  But before I proceed, I 
have a need to ask for peer review of the concept and do a test of 
acceptance by the user community.  So the next step is for each jnos 
sysop to consider this [sorta RFC] email and pass back any thought that 
seems appropriate.

Thanks in advance for your consideration on this subject.
Skip