Hi Ken,
AFAIK, it's only in our interactions with network protocols like SMTP
and POP3 that we see CRs because that's the definition.
Right, good.
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!).
Works here. :-)
#<text/plain *b64
a£d
w£z
Well, at least it does if I'm doing comp, whatnow, mime, edit. If I run
mhbuild(1) then it always gives quoted-printable.
$ mhbuild -
#<text/plain *b64
a£d
w£z
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID:
<17591(_dot_)1504001563(_dot_)1(_at_)orac(_dot_)inputplus(_dot_)co(_dot_)uk>
Content-MD5: wrfRnlkZxzaLuNL9h63JVA==
Content-Transfer-Encoding: quoted-printable
a=C2=A3d
w=C2=A3z
$
Also, it SEGVs without the `/plain'. Probably because get_ctinfo()'s
685 if (*cp != '/') {
686 if (!magic)
687 ci->ci_subtype = mh_xstrdup("");
688 goto magic_skip;
689 }
skips 687 because "It's magic!".
We don't insist on CRLF when receiving RFC 5322, right.
Right ... I was just musing that maybe we should.
My inner facist system administrator says yes. Postel's maxim is wrong.
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
If we did that, a regular expression to handle a line ending with \r\n
would be trivial.
If it were to allow /\r?\n/ then I think it should insist on consistency
for all the lines based on the first. But really, the lexer should be
told which one of the two is valid at the start.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers