🚀 go-pugleaf

In article <838295414snz@wash.demon.co.uk>, John Washington
<john@wash.demon.co.uk> writes

>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        */
>    ...
>    }
>
>I've omitted detail, but those are ALL the lines that use
>this variable.
>
>If they served any purpose I'd also be carping about
>using that if..else instead of a simple
>
>        no_check_dot = !has_newline;

that only works the same if you set has_newline = 1 before entering the
loop for the first time and you are careful to put your proposed
statement before the code which determines whether there is a newline at
the end of this chunk...

>And now for something completely different...
>
>Believe it or not, I wasn't browsing smtpserv.c to score
>coding style.  Currently I have a problem with a 900K
>mail that is waiting for me on 'punt'. 

>Anyone else had this problem, any clues where exactly in
>the source the problem might be?

turn up the tracing and see exactly what turns up....  you must be right
that the problem is in KA9Q because no-one reports problems from the
punts like this with Turnpike; however you need to have some idea what
sort of data is involved.

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

you have to arrange that KA9Q is sure that the file is on disk (in temp
or otherwise) before it sends the OK. However, you have to deal with
crashes thereafter, and arrange that the user is unlikely to delete the
temp files before KA9Q (or something) has had a chance to continue with
the movement of the data to the final destination.

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

see above ... once you've sent the OK you are responsible for the mail.
KA9Q avoids a lot of complexity by putting in into its final resting
place before it says OK.

-- 
richard                      richard.clayton    @    T U R N P I K E .com
                                                     tel: +44 1306 732300
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM