[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralph Corderoy
Subject: Re: [Nmh-workers] mhfixmsg on a pathological mail
Date: Tue, 29 Aug 2017 11:18:53 +0100

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

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
    MIME-Version: 1.0
    Content-Type: text/plain; charset="UTF-8"
    Content-ID: <address@hidden>
    Content-MD5: wrfRnlkZxzaLuNL9h63JVA==
    Content-Transfer-Encoding: quoted-printable


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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]