🚀 go-pugleaf

On Wednesday, in article <837582170snz@pdlmail.demon.co.uk>
     pete@pdlmail.demon.co.uk "Peter Disdale" wrote:

PD> In article <593574303wnr@roborat.demon.co.uk>
PD>            dave@roborat.demon.co.uk "Dave Scott" writes:
PD> 
PD> > In article: <837432741snz@wash.demon.co.uk>  John Washington 
PD> >   <john@wash.demon.co.uk> writes:
PD> > .. 
PD> > > A single newline character preceding a 'From '
PD> > > is (I imagine) not sufficient to signal the start of a header.
PD> > 
PD> > You mean something like :-
PD> >    blah\n
PD> >    blah\n
PD> >    \n
PD> >    From ... 
PD> > is required? Have to disagree - I'm pretty sure <blah\n><blah\n><From >
PD> > is all that's actually needed, i.e. only the preceding line's C/R.
PD> 
PD> As far as PCElm is concerned <\nFrom > appears all that is 
PD> necessary to signal the start of the next header.

[thinks]  If real mail arrived like that, mail2snz would
get its knickers in a twist.  [browses code..]  Oops, <blush>
indeed a simple <\nFrom > _is_ all it looks for, I didn't even
remember my own code.  I wonder why I coded it like that?

As for checking what actual code does, mail2snz is a bit of
a hack, and I wouldn't give you tuppence for the relevance of
what it does or doesn't do.  And IMNSHO, PcElm and NewsWin
also qualify as BOAHs, so experiments on them are equally
irrelevant.

This is outside the purview of the RFCs, since it's an internal
file format produced by ka9q (and others?).  smtpserv.c has
the comment
                /* Leave a blank line between msgs */

in it, so I guess that's why the random samples I've just
made on my recent incoming mail show \n\n before the
From's I looked at.

PD> I believe the confusion occurs when a genuine <\nFrom > appears
PD> in the text body (and possibly in a malformed header too - I

No confusion at all.  See below.

PD> haven't tried that).  If one has text like:
PD> 
PD> From what you say, it seems ...
PD> From an earlier posting you say ...
PD> 
PD> whether or not it's just <\nFrom > or <\n\nFrom > in the text 
PD> body, PCElm treats it as the start of the next message :-(

But something (?) would have to put such lines in your
.txt file.  Ka9q doesn't.  Any From within the body is
prefixed with '>'.  If you go into your mail
file with a text editor and hack in some spurious lines,
well, <shrug>.

PD> (This is news, so I hope I didn't screw up anyone's mailbase 
PD> by the above example...)  This seems reasonable, as scanning

This is news, so 'From' is nothing special.

PD> through ~spool/mail/pete.txt there is no consistent pattern
PD> of <\n\nFrom > between articles, ie. ka9q seems not to inject
PD> a <\n\n> between articles when filing them.

Oh.  In that case either I've misunderstood or you're
not using 2.16d.  Likely I've not figured out the source,
I did little more than look at the comment, and we all
know how well they stay in step with a program's code,
right?

PD> 
PD> ISTM that PCElm is somewhat undiscerning (if not actually 
PD> broken) in its interpretation of the .txt files.  Maybe yet
PD> another item for Malcolm's wishlist when time permits (or
PD> when entropy starts decreasing; whichever happens first:-)).
PD> 
PD> But hey - didn't this start off as a question on blank lines
PD> between headers and bodies?

Hey, that's thread entropy for you!  When did a Usenet thread
stay on the same topic 2 days running?  :-)

I still think the perfect solution would not be for Malcolm (nor
anyone else) to spend his time upgrading PcElm, but for someone
to produce something similar (or extend Snews) under GPL.
We've all seen the enormous benefit of having source readily
available, and that's impossible with PcElm.

Speaking of source availability (and thread entropy), what're
the latest plans on the DIS menu?

--
John Washington