I just added a -checkbase64 switch to mhfixmsg(1):
The -checkbase64 switch enables a check of the encoding
validity in base64-encoded MIME parts. The check looks for a
non-encoded text footer appended to a base64-encoded part.
Per RFC 2045 §6.8, the occurrence of a "=" character
I didn't know about the built-in iconv. But this behaviour seems a
lot better than 'just drop the problems on the floor silently'. The
reason I was interested in a louder error reporting was that, for a
certain chunk of time if there was an encoding error, then chances
were that the person who
On Mon, 18 Mar 2019 21:10:45 -0400, Ken Hornstein said:
> But the email you sent out was marked as having a character set of UTF-8
> with characters encoded as ISO-8859-1. Dude, I know you could do better
> (also, I am puzzled as to how that happened; I think with nmh you'd have
> to work to
Valdis wrote:
> Deciding whether the detection of an issue should
> be in the bse64 decoder or elsewhere is bikeshedding compared to trying
> to decide what semantics you want..
Identifying whether the issue is due to invalid base64 characters or due to an
improperly constructed MIME part is
>With irony, in a discussion about how to handle bad encodings in
>mail, I found that I could not read this message by Valdis Klētnieks
>https://lists.nongnu.org/archive/html/nmh-workers/2019-03/msg00023.html
>
>Something bad seems to have happened to his encoding of a '§'.
Here are my thoughts
workers@nongnu.org
>From:"Valdis Klētnieks"
>Subject: Re: [nmh-workers] mhshow: invalid BASE64 encoding in --
>
>
>iconv: illegal input sequence at position 507On Sun, 17 Mar 2019 17:29:16
>-0400, Ken Hornstein said:
>
>> >My reading of RFC2045 says a conf
On Sun, 17 Mar 2019 20:43:40 -0400, David Levine said:
> Note the "in base64-encoded data". The characters in the footer are after
> the end of the base64-encoded data, per the use of "end" here:
>
>Special processing is performed if fewer than 24 bits are available
>at the end of the
Ken wrote:
> That message is a single text/plain part with a C-T-E of base64; I think
> by definition the whole message body is supposed to be considered base64
> data.
I think the message is invalid. If we want to salvage what we can from it,
I'm all for it. But that should be done carefully.
>The non-base64 characters in the message body are after the end of the
>base64-encoded data. They're not "in base64 data".
That message is a single text/plain part with a C-T-E of base64; I think
by definition the whole message body is supposed to be considered base64
data. And how do we know
Valdis wrote:
> > >My reading of RFC2045 says a conforming base64 decoder is allowed to toss
> > >out
> > >the blanks and the '!' char and decode the rest.
> > >
> > > Any characters outside of the base64 alphabet are to be ignored in
> > > base64-encoded data.
Note the "in base64-encoded
On Sun, 17 Mar 2019 17:29:16 -0400, Ken Hornstein said:
> >My reading of RFC2045 says a conforming base64 decoder is allowed to toss out
> >the blanks and the '!' char and decode the rest.
> >
> > Any characters outside of the base64 alphabet are to be ignored in
> > base64-encoded data.
> >
>
>I understand that the list is broken (and I've passed this on to the
>administrator). But my perspective is this: I've used nmh for eight
>years, and while I'm a big fan of the concept, and it has noticeably
>improved in usability in that time, it is still difficult. My camel's
>back is not
>My reading of RFC2045 says a conforming base64 decoder is allowed to toss out
>the blanks and the '!' char and decode the rest.
>
> Any characters outside of the base64 alphabet are to be ignored in
> base64-encoded data.
>
>Yeah. That's pretty definitive. :)
Oh, hm, you know you learn
On Sun, 17 Mar 2019 09:28:53 -0400, David Levine said:
> More generally, what if a sender (improperly) had annotated an already
> encoded message with, say, "DO NOT FORWARD THIS!"? Bad, yes, but could lead
> to
> undesired results if that was dropped.
My reading of RFC2045 says a conforming
> In other words, I'd like to see all of the content or an error message.
I too like to be informed of errors instead of having the system guess
what I want and possibly be wrong with disastrous results.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ralph Corderoy writes:
> David wrote:
> > In other words, I'd like to see all of the content or an error
> > message.
>
> This is the juncture where I normally take
> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00#section-1
> out for a trot.
I understand that the list is broken
>"mhshow: invalid BASE64 encoding in --"
I'm also on a mailing list that has the same problem. And yes, it is
totally invalid MIME due to the mailing list software appending a header
to the bottom of a base64-encoded part, as everyone else has mentioned.
And yes, that mailing list software
Hi,
David wrote:
> In other words, I'd like to see all of the content or an error
> message.
This is the juncture where I normally take
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00#section-1
out for a trot.
--
Cheers, Ralph.
--
nmh-workers
Valdis wrote:
> that maybe if we're looking at base64, if we encounter a blank line we toss
> the
> rest of the body part.
That would work in this case, but the mailing list should be fixed. More
generally, what if a sender (improperly) had annotated an already encoded
message with, say, "DO
On Sat, 16 Mar 2019 22:14:41 -0600, "Anthony J. Bentley" said:
> "mhshow: invalid BASE64 encoding in --"
>
> Since it's a public mailing list, one of these messages is enclosed below.
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
Yeah that's a reasonable thing to
Hi,
I receive many messages on a particular mailing list that fail to
render in nmh-1.7.1, giving the error:
"mhshow: invalid BASE64 encoding in --"
Since it's a public mailing list, one of these messages is enclosed below.
Received: by 2002:a25:1505:0:0:0:0:0 with SMTP id 5csp1062256ybv;
21 matches
Mail list logo
