That's because -decodeheaderfieldbodys utf8 only decodes UTF-8 text.
That makes sense. I'd forgotten that utf-8 is a mandatory argument for
"-decodeheaderfieldbodies.
There was a reason for only allowing decoding of UTF-8 header field
bodies. If any character set could be decoded, it would be possible
to produce header field bodies with embedded nulls,
I didn't know that.
we could decode ASCII because 1) we've seen it in the wild, 2) it seems as
harmless as it is pointless to encode ASCII as ASCII, assuming no NULs,
and 3) it's a proper subset of UTF-8 so it doesn't interfere with the
semantics of the "-decodeheaderfieldbodies utf8" switch.
That also makes sense.
Any other suggestions?
No, but then I've never noticed any encoded headers that weren't utf-8 or
ASCII. And I agree that encoding ASCII seems pointless, but that doesn't
stop my Android mail app from doing it anyway. :-/
So I'm curious, why is the ASCII encoded as ASCII? Why not just fold
the header as usual?
I have absolutely no idea. This isn't a configurable choice as far as I'm
aware, it't just something that the app does. If you're curious, it's
called "K-9 Mail":
https://play.google.com/store/apps/details?id=com.fsck.k9&hl=en_CA&gl=US
https://k9mail.app/
https://github.com/k9mail/k-9
This line is too long, I'm not sure if that is related or if it's a
separate issue:
It's probably related. I can't prove that, but in general, shorter subject
lines appear to be passed through without encoding.
Regardless, this kind of thing is exactly what I'm trying to eliminate in
my saved messages. I just realized that my decode_headers program doesn't
detect the second encoded string in the same header, but I'm about to go
fix that. :-)
- Steven
--
___________________________________________________________________________
Steven Winikoff |
Montreal, QC, Canada | "Any teacher who _can_ be replaced by a
smw@smwonline.ca | machine, _should_ be."
http://smwonline.ca |
| - Arthur C. Clarke