nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] why does mhfixmsg dislike long text lines?


From: Steven Winikoff
Subject: Re: [Nmh-workers] why does mhfixmsg dislike long text lines?
Date: Mon, 22 Jan 2018 22:32:42 -0500

>Well, "binary" has a specific meaning in the MIME world.  Specifically,
>it refers to a MIME Content Transfer Encoding of binary, which has no
>restrictions in terms of line length.  So when that message says that
>it can't decode it because the part would have to be binary, THAT is what
>it is referring to.

This helps, but I'm still a bit confused.  (That's an exaggeration; I'm
really still very much confused. :-()

I just looked up Content-Transfer-Encoding header, and found what you
already know (but which I'll repeat here, for the record and for my
own future reference):

   The Content-Transfer-Encoding field is designed to specify an invertible
   mapping between the "native" representation of a type of data and
   a representation that can be readily exchanged using 7 bit mail
   transport protocols, such as those defined by RFC 821 (SMTP). This field
   has not been defined by any previous standard. The field's value is
   a single token specifying the type of encoding, as enumerated below.
   Formally:

   Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
                                "8BIT"   / "7BIT" /
                                "BINARY" / x-token

...so when a message clearly contains

   Content-Transfer-Encoding: base64

shouldn't that mean we don't need to test the decoded content to see if
it's binary or not?  You just said in your previous message that there's
no line length restriction in the content after decoding.


>But David points out that if you tell it to, mhfixmsg will happily
>generate such messages (but the documentation does caution you that the
>resulting messages may not be readable with nmh).

That's good to know, but I really have no plans to create out-of-spec
messages; I just want to be able to read the messages I'm receiving, and
you clearly explained that I should be able to do that, because the encoded
form follows the RFC specification and the decoded form doesn't have to.

Or at least that's what I thought you said.


>Our only general-purpose nmh list is nmh-workers; plenty of people on it
>are not coders, so please don't be concerned on that score.

Thanks.  I've just subscribed.

     - Steven
-- 
___________________________________________________________________________
Steven Winikoff                | "Nature is by and large to be found out
Concordia University           |  out of doors, a location where, it
Montreal, QC, Canada           |  cannot be argued, there are never
address@hidden   |  enough comfortable chairs."
                               |                        - Fran Leibowitz



reply via email to

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