🚀 go-pugleaf

On Thursday, in article
     <838324205snz.4907@grempc.demon.co.uk>
     Graham@grempc.demon.co.uk "Graham E Kinns" wrote:

GK> John Washington <john@wash.demon.co.uk> wrote:
GK> >But how is this variable used?
GK> >
GK> >while (1)
GK> >    {
GK> >    int no_check_dot = 0;           /* don't check for "."              */
GK> >    ...
GK> >    if (no_check_dot == 0 && *p == '.')
GK> >        {
GK> >        ...
GK> >        }   /* if (no_check_dot == 0 && *p == '.') */
GK> >
GK> >    if (has_newline != 0)
GK> >        no_check_dot = 0;           /* check "." next time              */
GK> >    else
GK> >        no_check_dot = 1;           /* don't check "." next time        */
GK> >    ...
GK> >    }
GK> 
GK> You've missed the 'obvious' C bug - the scope of no_check_dot means it

No I haven't.  That was precisely why I posted it, but I thought
it was glaringly obvious!

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

And meanwhile I've confirmed this is indeed the cause of my
problem.  In fact the 900K mail was a red herring.  Another
much shorter mail (from jobsite) contained a line of precisely
257 characters (including the final \n) and the last char
before the \n was '.'.

So this would be split into 255 chars, and then a 'line' of
".\n", causing the incorrect code to believe the mail was
complete.

Presumably the 'punt' was confused by (or at least, rightly
disdainful of) receiving ka9q's end-of-mail ack, and didn't
send anything further (or perhaps it did and ka9q threw it
away, I've not bothered to desk check that part).  I'm
puzzled that it seems as if ka9q then got 'stuck', my guess
is that the smtp server was waiting for something without
context switching to another process.  This jam cleared
immediately the modem was powered off.  Evidently interrupts
weren't locked out -- keystrokes during the jam were
echoed and honoured immediately after power-off.

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

If you mean line breaks (\n) are inserted, I disagree.
If you mean 'buf' is 256 bytes, I agree.  A longer line
requires multiple calls of recvline(), but is reassembled
in the mail file successfully, with no spurious breaks.

GK> task-switching problem when things get busy.  You don't say if you
GK> found a truncated copy of the mail in your mailbox file (ie did KA9Q 
GK> stick whilst still downloading to the temp file or copying to the 
GK> mailbox?)

Now that I know which mail was causing the symptom, yes,
I got a truncated copy of it every time I logged on, until
I recoded ka9q.

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

Thanks, didn't know that.  And thanks to Borland for giving
us the RTL source, something I've several times been grateful
for, and a feature that would strongly bias me against rival
vendors that don't.

Thanks also to Demon.  As a result of these shenanigans I
noticed that punt eventually started up another smtpserv
at my end FOR THE MAIL STACKED BEHIND THE BIGGIE.  I had
always imagined that multiple servers were only handling
the mail from different punts, and that each punt took
mail only off the head of its queue.  Not so.  BRILLIANT,
Demon, thanks.

GK> As others have said, I wouldn't be happy ack'ing mail 'til it was in 
GK> a mailbox.  One alternative would be to receive it into spool/mqueue 
GK> first in a .wrk/.txt combination and then later deliver it to the

Quite.  I wouldn't be happy ack'ing it until it was in a real
file, not RAM or an unnamed file.  After that, I feel equally
exposed to the ball-bearings dropping out of my Winnie, whether
the mail is in its final resting place or an intermediate file.

Fortunately nobody sends me digital money by email.  Hmm, scratch
that.  Make it unfortunately.  :-)

--
John Washington