🚀 go-pugleaf

John Washington <john@wash.demon.co.uk> wrote:
>     Graham@grempc.demon.co.uk "Graham E Kinns" wrote:

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

Sorry ...

[...]

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

Yes, checked this myself, KA9Q does start sending back 500 responses 
to the rest of the lines of the mail.

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

As I read it:

    recvline (mp->s, p, sizeof (buf))
    ...
    has_newline = strchr (p, '\n');
    rip (p);
    ...
    fprintf (mp->data, "%s\n", p)

has_newline remembers whether a \n was present, rip() removes any \r\n
but fprintf() adds the \n regardless of has_newline.

I regularly receive mail from either mailtool or textedit under X 
which only has an \n at the end of a paragraph which is why I know it 
happens :)  I'd be wary of fixing this one in case it breaks other 
mailers/editors e.g. PCElm seems to cope OK with long lines but Ted 
doesn't cope too well with lines > 256 chrs when quoting such mail.

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