Re: automatic decode mime in repl
[2022-02-11 18:25] David Levine > Philipp wrote: > > As a _m_mh user I don't have the -convertargs switch. > > You submitted a patch to nmh. I'm not sure what mmh has to do with > any of this. Are you asking for an nmh enhancement to support mmh? No, I try to explain why thinks looks diffrent to me, but you akt like you don't want to listen. I'm full aware I have submitted a patch to nmh. I think some of your users can benefit from it. With every mail from you I regent it more. I though there will be some discussion, but not this empty defence of an complex feature in order to reject my patch. So back to topic. You asked me if it's possible to improve my patch by using the convertargs and convert interface: No because it is an alternativ solution to convertargs. Your example of how this could be done doesn't even get the idea of my patch. So you might go back and look again what my patch does before complaining about it. If you have complaines or problems with my patch explain them proper. If you just claim there are other problems, I will asume you have somehow brok your setup. But stick to stuff which is introduced by my patch, not bugs which are there since forever and you just currently don't see because you don't use the default config. If you still like convertargs, stick with it. I couldn't care less. But then go away and let other users have this feature if they want to. > I would rather do that then add new code to nmh that doesn't seem > like a complete solution. You say: A complex copy of the mhshow interface is good to keep, but a small patch with calls mhshow out of repl is bad. The users should better add all the code to there config. Or did I missunderstand you? Philipp
Re: automatic decode mime in repl
Thank you for submitting your patch, Philipp. I have these reservations with it: 1. For all users, it can add newlines in text that cause, for example, URLs to break. 2. For existing users, it may require changes to their existing nmh environments. 3. It does not add new functionality to nmh. Its functionality is a proper subset of a pre-existing feature. 4. Given 3, if implemented within nmh, an alternative could be to internally simply wrap a suitable use of the pre-existing feature. From the user point of view, the result would be the same. I have additional though lesser concerns, such as the name of the switch and the support effort required, mostly related to 1. and 2. above. David
Bug: repl breaks urls
Hi
repl will break urls with the format switch, depending on the size of
your terminal. A test case is attached. To reproduce run the test in a
terminal with less then 300 chars width.
Philipp
#!/bin/sh
##
#
# Test repl -convertarg
#
##
set -e
if test -z "${MH_OBJ_DIR}"; then
srcdir=`dirname $0`/../..
MH_OBJ_DIR=`cd $srcdir && pwd`; export MH_OBJ_DIR
fi
. "${srcdir}/test/post/test-post-common.sh"
expected="$MH_TEST_DIR/test-url$$.expected"
actual=`mhpath +`/draft
printf 'Local-Mailbox: recipi...@example.com\n' >>"$MH"
Make sure that this works with 7-bit encoding.
LC_ALL=C; export LC_ALL
# check if urls get broken
start_test 'long urls get broken on reply'
cat >"$expected" <<'EOF'
From: recipi...@example.com
To: sen...@example.com
cc:
Fcc: +outbox
Subject: Re: test
Comments: In-reply-to sen...@example.com
message dated "Thu, 11 Dec 2014 08:19:02 -0600."
sen...@example.com writes:
> https://example.com/realy/long/path/to/some/importent/document/with/i/need/to/reference/in/the/reply/because/it/is/realy/importent/and/has/also/some/random/string/in/it/a//but/is/not/longer/than/900/chars/because/it/is/still/a/valide/mail.html
EOF
cat >`mhpath new` <<'EOF'
From: sen...@example.com
To: recipi...@example.com
Subject: test
Date: Thu, 11 Dec 2014 08:19:02 -0600
https://example.com/realy/long/path/to/some/importent/document/with/i/need/to/reference/in/the/reply/because/it/is/realy/importent/and/has/also/some/random/string/in/it/a//but/is/not/to/long/because/it/is/still/a/valide/mail.html
EOF
repl -editor true -nowhatnowproc -format last
check "$actual" "$expected"
Make sure that this works with 8-bit encoding.
finish_test
exit ${failed:-0}
Re: Experimental IMAP branch
Eric Gillespie wrote: > And I guess I also omitted that you need to configure with > --enable-experimental-imap-folder-manager as this is all off > by default. Got it. >> make >> saw some .rs stuff go bye... error... > You shouldn't have seen any unless you ran 'make cargo'. I was just saying that I saw some stuff about .rs files in the configure, confirming that I'm on the right branch... > Since you missed the flag to configure, this suggests my > non-experimental build has bitrotted. I intend for a clean build > when the flag is off. Not sure when I last tested that. Sorry. Yup, that worked. I'll need to figure out how to use this now... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: mhfixmsg character set conversion
>> [ re -decodeheaderfieldbodies ] > >Ok, couple of issues, both due to very limited support of >encoded formats by -decodeheaderfieldbodies. I'll work on >them. Thank you. >Note that the only encoded headers in your message are >us-ascii, that seems pointless. In the case of that particular message, the encoded headers are ones that I'd almost never want to search for anyway. But today I sent myself a message using an IMAP-based app on my phone, resulting in the appended, and I'd definitely want to decode the Subject: header. Unfortunately, running it through mhfixmsg results in the message coming back unchanged. Is that specifically about -decodeheaderfieldbodies, or is mhfixmsg doing nothing because the message body is already unencoded text/plain? - Steven 8<- cut here >8 >From s...@smwonline.ca Sun Feb 13 15:03:01 2022 Return-Path: Received: from server03.4goodhosting.com (198.178.116.238:993) by mort.smwonline.ca with IMAP4-SSL; 13 Feb 2022 20:03:01 - Delivered-To: s...@smwonline.ca Received: from server03.4goodhosting.com by server03.4goodhosting.com with LMTP id qHlDCdljCWKQfgAA2eRUeQ (envelope-from ) for ; Sun, 13 Feb 2022 15:02:33 -0500 Envelope-to: s...@smwonline.ca Delivery-date: Sun, 13 Feb 2022 15:02:33 -0500 Received: from mort.smwonline.ca ([206.248.137.116]:59412 helo=[127.0.0.1]) by server03.4goodhosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nJL4r-Oz-0y for s...@smwonline.ca; Sun, 13 Feb 2022 15:02:33 -0500 Date: Sun, 13 Feb 2022 15:02:32 -0500 From: Steven Winikoff To: s...@smwonline.ca Subject: =?US-ASCII?Q?Using_the_Linux_fold_command_to_mak?= =?US-ASCII?Q?e_text_more_readable_=7C_Network_World?= User-Agent: K-9 Mail for Android Message-ID: <43c6f911-0ded-4953-897b-3a5cffaf9...@smwonline.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX https://www.networkworld.com/article/3646748/using-the-linux-fold-command-to-make-text-more-readable.amp.html 8<- cut here >8 -- ___ Steven Winikoff | Montreal, QC, Canada | "Believe that life is worth living, and s...@smwonline.ca | your belief will help create the fact." http://smwonline.ca | |- William James
Bad message list?
In Mr Paul Fox's ml script, could anyone tell me what the warning "Mark: bad message list unseen" means and how I would get rid of it? Thank you
Re: Bad message list?
aalin...@riseup.net writes: > In Mr Paul Fox's ml script, could anyone tell me what the warning "Mark: > bad message list unseen" means and how I would get rid of it? It looks like you need to add this to your profile: Unseen-Sequence: unseen That's documented in the mh-sequence(5) man page. David
Re: mhfixmsg character set conversion
Steven Winikoff writes: > Unfortunately, running it through mhfixmsg results in the message coming > back unchanged. Is that specifically about -decodeheaderfieldbodies, or > is mhfixmsg doing nothing because the message body is already unencoded > text/plain? That's because -decodeheaderfieldbodys utf8 only decodes UTF-8 text. 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, which I expect would result in incorrect message parsing. It certainly would with scan(1): it would truncate a Subject with an embedded null. That can't happen with UTF-8 encoded text, assuming it doesn't contain any single-byte NUL octets. In addition to decoding UTF-8, 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. Any other suggestions? If there's an enumeration of character encodings that can't have NULs, we could expand those. > But today I sent myself a message using an IMAP-based app on my phone, > resulting in the appended, and I'd definitely want to decode the Subject: > header. So I'm curious, why is the ASCII encoded as ASCII? Why not just fold the header as usual? This line is too long, I'm not sure if that is related or if it's a separate issue: Subject: =?US-ASCII?Q?Using_the_Linux_fold_command_to_mak?= =?US-ASCII?Q?e_text_more_readable_=7C_Network_World?= David
Re: mhfixmsg character set conversion
>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 s...@smwonline.ca | machine, _should_ be." http://smwonline.ca | |- Arthur C. Clarke
Re: mhfixmsg character set conversion
Date:Sun, 13 Feb 2022 22:07:52 -0500 From:Steven Winikoff Message-ID: <990728-1644808072.157...@mrwn.zn5-.vkyf> | >So I'm curious, why is the ASCII encoded as ASCII? Why not just fold | >the header as usual? | | I have absolutely no idea. I don't know the app in question, but I can guess. Folding that way requires no smarts of any kind, and should be understood as intended by any (modern) recipient, no matter where the actual line break is inserted. Personally I prefer to manually insert the line break, so things look good whether unfolded or not. But your typical app for e-mail novices cannot assume the ability to do things like that, and tends to assume the average user believes that newline is useful only to divide paragraphs. So sad. kre
