nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] mhfixmsg on a pathological mail

2017-08-27 12:45:54
I agree RFC 5322 lines are CRLF, but RFC 4155's application/mbox are
just LF, and Unix mbox files from Postfix, etc., are just LF.  I don't
think the code should allow /\r?\n/ for all inputs, but I don't think
you're saying it does?

AFAIK, it doesn't.

Is retrieving POP3 emails the only time we should see the CR and it gets
stripped off before the non-POP3 code sees it?  When nmh creates a
message/rfc822 it doesn't tack CRs on so presumably they're not meant to
be there on non-nmh incoming ones?

If we are just doing a straight message/rfc822, then no, we don't tack a
CR on, because we're doing Unix line endings locally.  AFAIK, it's only
in our interactions with network protocols like SMTP and POP3 that we
see CRs because that's the definition.

text/* that is encoded as base64 should technically include a CRLF.  I
BELIEVE I added the code that will convert that Unix line endings upon
decode, and reencode it with CRLF (did I?  I did!  How about that!).

We don't insist on CRLF when receiving RFC 5322, right.

Right ... I was just musing that maybe we should.

Some people have been recoiling in horror at my attempts to write an
RFC-822 address parser in Yacc/Bison.  I don't know if that's going
to be successful or not; we'll see!  But I was thinking of ditching
m_getfld() completely and switching it to flex tokenizer.  I think that
makes a lot of sense, and should be straightforward.  If we did that, a
regular expression to handle a line ending with \r\n would be trivial.
I welcome thoughts about that idea as well.

--Ken

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>