🚀 go-pugleaf

John Washington <john@wash.demon.co.uk> wrote:
>But how is this variable used?
>
>while (1)
>    {
>    int no_check_dot = 0;           /* don't check for "."              */
>    ...
>    if (no_check_dot == 0 && *p == '.')
>        {
>        ...
>        }   /* if (no_check_dot == 0 && *p == '.') */
>
>    if (has_newline != 0)
>        no_check_dot = 0;           /* check "." next time              */
>    else
>        no_check_dot = 1;           /* don't check "." next time        */
>    ...
>    }

You've missed the 'obvious' C bug - the scope of no_check_dot means it 
is >always< 0 when checked, it should be declared/initialised outside 
the while loop.  Thus in the unlikely event of mail arriving with a 
long line with '.' at position n*256, it will currently be truncated 
(? I think, KA9Q will send OK, punt acks, then KA9Q sees the rest of 
the message as trash and complains ... only one way to find out ...)

One of the bits of code you clipped in that block also breaks incoming 
lines at 256 chars.

>Ka9q receives this mail ok,
>but then seems to "get stuck" at the end.  It won't even
>respond to commands like 'so' or 'ex'. 

>Anyone else had this problem, any clues where exactly in
>the source the problem might be?  I'm aware that it may be
>due to the delay while copying the temp file being too long
>for the client, but I don't see why that should lock up
>other processes.

I've seen something similar when the results of a large ls -lrt were 
downloading in an ftp session and switching about between other 
sessions - eventually everything did free itself up.  Wasn't a memory 
problem as I have 100-150K free online so I can only assume it's a 
task-switching problem when things get busy.  You don't say if you
found a truncated copy of the mail in your mailbox file (ie did KA9Q 
stick whilst still downloading to the temp file or copying to the 
mailbox?)

>As a kluge around it, I'm thinking of counting the incoming
>lines, and if over a threshold changing the action.  Instead
>of doing the copy I want to rename the temp file, so as to
>speed up the response to the client.  Any thoughts on that?

With the present implementation you can't rename the temp file 
since the filename is internal to the BC runtime, KA9Q just calls 
tmpfile() to get a new FILE*

>More generally, I wonder whether this might be an interesting
>route to go for all mail.  In essence, instead of copying
>the mail to its destination file when the '.' is received,
>leaving the file to be processed offline.  Result would be
>shorter time online, as well as greater resilience to the
>timeout problem.  However, I'm not familiar with how ka9q
>handles its temp files -- does that sound workable?

As others have said, I wouldn't be happy ack'ing mail 'til it was in 
a mailbox.  One alternative would be to receive it into spool/mqueue 
first in a .wrk/.txt combination and then later deliver it to the 
mailbox but I can imagine the 'KA9Q ate my mail' cries to Support ...

Cheers, Graham.
-- 
----[ Graham E. Kinns ]----==========----< Graham@grempc.demon.co.uk >----