Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > Dear David, > > In message you > wrote: > > > > I added a -decodetypes switch to mhfixmsg: > > > > -decodetypes type/[subtype][,...] > > Cool. where can I find that, please? It's in the git repo. If you haven't been using that, these will download from master, build, and install (with the build_nmh -i flag): $ git clone git://git.savannah.nongnu.org/nmh.git $ cd nmh $ docs/contrib/build_nmh -div David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > However I notice that not only the "text/plain" part has been > modified; the "text/html" part has _also_ been modified: > originally, it was a base64 encoded HTML file with UNIX line endings > (plain LF); now it is a base64 encoded file with DOS line endings (CR > + LF). > > So apparenty mhfixmsg still touches parts which are not listed on > the "-decodetypes" list: in my case it decodes from base64, converts > LF => CR/LF, and re-encodes to base64. > > This is a bit unexpected to me. > > Is this intentional? > > Can I use some options to avoid it? It's a byproduct of the way mhfixmsg was implemented, using existing nmh components. I'll look into adding an option to avoid it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > mhfixmsg: ... part 1.2, will not decode because it is binary (line length > 9 > 98) > > This is because the HTML message is actually a single, very long line > (don't ask my why Android creates something like that). > > But the result is double ugly: decoding of the text/plain part (which > I want) fails, because the tol cannot contain the text/html part > (which I do NOT want to touch)... Are you sure about that? In this case, part 1.2 wasn't decoded. Other parts should be handled independently. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > mhfixmsg -verbose -decodetypes text/plain > > gives: > > mhfixmsg: Don't know how to convert ..., there is no mhfixmsg-format-text/htm > l profile entry That is due to a different transformation, not decoding. By default (-reformat), mhfixmsg tries to add a text/plain part corresponding to each text part that doesn't have one. In this case, that's the text/html part. The quick workaround is to add -noreformat. I will commit a change to permanently avoid mhfixmsg treating this as a failure. Though it will still issue the above message with -verbose. If you want more detail on the cause: When nmh is installed, it looks for an external program (w3m, lynx, or elinks) to convert html to text. The result is stored in `mhparam etcdir`/mhn.defaults. (This is described in the man page.) It looks like none was found in your case. Currently, mhfixmsg treats that as an error when it encounters a text/html part. As noted above, I'll change that. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > Yes, I'm sure about that. mhfixmsg issues the error message above, > and leaves the whole message unchanged, i. e. it does not touch the > text/plain part either. I can't replicate that. I added a check to test-mhfixmsg (and it passed even before today's fix to mhfixmsg). I did commit that fix to mhfixmsg. With it, -reformat, which is enabled by default, will no longer cause mhfixmsg to fail if it can't find a conversion program. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Wolfgang wrote: > In message <4e5f7dec-3dfc-4bbf-9d64-955f71aaf...@hubcas2.seas.wustl.edu> you > wrote: > > > That is due to a different transformation, not decoding. By default > > (-ref> ormat), mhfixmsg tries to add a text/plain part corresponding > > to each text part that doesn't have one. In this case, that's the > > text/html part. > > Are you sure? This message had both a text/pain and a corresponding > text/html part. I'm sure. You can verify by adding -noreformat. The text/plain part was not in a multipart/alternative with the text/html part, so while it might correspond, there's no way for mhfixmsg to know that for sure. > Normally I use the version of nmh that I get my Linux distro; at the > moment this is Fedora 23 -> nmh-1.6-3.fc23.x86_64 ; this installs > /etc/nmh/mhn.defaults ; which entry would be needed? > > All I can see is: > > -> grep -i html /etc/nmh/mhn.defaults > mhshow-suffix-text/html: .html Yes, the Fedora configuration/installation doesn't pick up any mhfixmsg entries for mhn.defaults. The right way to fix that would be to add a package dependency, I'll look into that. > Thanks for all your help!! Glad to. Thank you for your help to improve mhfixmsg! David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Ken wrote: > [Wolfgang:} > >> However I notice that not only the "text/plain" part has been > >> modified; the "text/html" part has _also_ been modified: > >> originally, it was a base64 encoded HTML file with UNIX line endings > >> (plain LF); now it is a base64 encoded file with DOS line endings (CR > >> + LF). > > Just as a point of note ... text parts that are based-64 encoded are > supposed to have CR+LF line endings. Before we got that wrong, but the > latest release of nmh should get that right (we'll write out those with > Unix line endings when storing them, and add a CR during encoding). > Technically a base64-encoded text part with Unix line endings is wrong > according to the standard. Oh yeah, thanks. I could see an option for mhfixmsg to not try to do the right thing. I find the current behavior of adding the CRs when it's supposedly not modifying a part to be a bit annoying. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Ken wrote: > according to the RFCs (see RFC 2046, §4.1.1, paragraph 1). > > Now, should mhfixmsg correct that? Weeelll ... good question. The > reason it is happening is because our MIME parser is now doing the > 'right' thing, and essentially the whole message is being regenerated. > Fixing that would involve telling the base64 parser to not perform the > line ending translation for (some) text parts. Part of me sees the > point about not modifying parts of messages you haven't told it to, but > a (larger) part of me thinks: seriously? mhfixmsg currently strips CRs out of text parts that it's decoding, which is wrong. I'll fix that, with default behavior. But I plan to add an option to strip/not add CRs. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
Paul F. wrote: > i think it would be helpful for the man page to be very explicit about > what mhfixmsg does by default (it's only somewhat implicit, now), There's a DEFAULTS section near the end. > perhaps along with some example invocations for the most common > problems/solutions. Yes, those would be helpful. > i'm a little surprised to not find -decodetext in that invocation, > since your (david's) message arrived with C-T-E of base64, but is in > my inbox with a C-T-E of 8bit. am i perhaps forgetting something about > my own mh configs? -decodetext 8bit is the default. Based on recent experience, and your Swiss-army-knife label, I'm thinking that it shouldn't be the default. But I don't feel strongly about it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] base64 ... just looking for advice
I wrote: > mhfixmsg currently strips CRs out of text parts that it's decoding, which is > wrong. I'll fix that, with default behavior. But I plan to add an option to > strip/not add CRs. I just added -[no]crlflinebreaks switches to mhfixmsg: By default, carriage return characters are preserved or inserted at the end of each line of text content. The -crlflinebreaks switch selects this behavior and is enabled by default. The -nocrlflinebreaks switch causes carriage return characters to be stripped from, and not inserted in, text content when it is decoded and encoded. Note that its use can cause the generation of MIME messages that do not conform with RFC 2046, §4.1.1, paragraph 1. To enable the non-default behavior all the time (unless overriden with -crlflinebreaks), add -nocrlflinebreaks to your mhfixmsg profile component, e.g., mhfixmsg: -verbose -nocrlflinebreaks David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mh and mairix and numerically named folders
Paul F. writes: > in the meantime, any objections if i add this new section to > mh-folders.man, or something like it? > Naming > nmh folders can be given arbitrary names, with one exception: > folders should not be given all-numeric names. This limitation > results from nmh messages themselves being stored in numerically > named files -- allowing folders to be named similarly would make > nmh slower, and introduce usage ambiguities. Nice. There's some old discussion of this starting with http://lists.nongnu.org/archive/html/nmh-workers/2007-02/msg3.html. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Truncated Email.
Ralph wrote: > I wrote: > > So this should stop happening when I fix the locking? Is that true? > > strace(8) shows inc is using fcntl(2)'s F_SETLK, and, mhparam can also tell you how nmh was configured: $ mhparam spoollocking fcntl That might be interesting to look at, because flock(2) might use fcntl underneath the bonnet/hood. I don't have any other explanation for the problems you've seen. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Norm wrote: > Maybe Contributions should have a tutorial script or two which > illustrate good ways to do that? How about adding this to the man page? EXAMPLES Basic usage To run mhfixmsg on the current message in the current folder, with default transformations to fix MIME boundaries and Content-Transfer- Encoding, to decode text and application/ics content parts to 8 bit, and to add a corresponding text/plain part where lacking: mhfixmsg -verbose View without modification To view the MIME structure that would result from running mhfixmsg on the current message, without modifying the message: mhfixmsg -outfile - | mhlist -file - Translate text/plain parts to UTF-8 To translate all text/plain parts in the current message to UTF-8, in addition to all of the default transformations: mhfixmsg -textcharset utf-8 David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] New release, v2?
Ken wrote: > So, in short: cut a 1.7, yes or no? Anything people would like in there? > My list is: > > - Incorporate XOAUTH support > - Fix character conversion on message bodies (right now it aborts if it > cannot convert characters to the target character set). Sounds good to me. I'd also like to have mhfixmsg decode to binary content. That's trivial, but I need to verify that the rest of nmh can handle that. Not sure when I'll get to it. XOAUTH support is a blocker. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Eric wrote: > I can freshen up the branch. Did anyone ever review it? Should I merge it > as is? We should settle the api key management issue too. I looked at it, but not even close to review. How about leaving it on the branch and we'll look it at there. I really do want to use it, just haven't been able to devote enough time to it. Anything you can do to walk me/us through use would help. Thanks. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Norm wrote: > David Levine writes: > > >Translate text/plain parts to UTF-8 > >To translate all text/plain parts in the current message to UTF-8, in > >addition to all of the default transformations: > > > >mhfixmsg -textcharset utf-8 > > How do I translate, to utf-8, all parts of a message, > which can be reasonably translated to utf-8? The first such part? mhfixmsg doesn't currently support either of those. It's not clear to me how to determine "can be reasonably translated to utf-8". We've discussed this here recently, and Ralph raised the counterexample of an html page relying on a particular charset. And I'll resist making the tool even more complicated by adding interfaces to select which parts to touch. So it's none or all, unless there would be a real benefit to translate only specified parts. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Norm wrote: > The bulk of the non-spam mail I receive still has a utf-8 or a quotedPrintabl > e part. I would like to apply UNIX text processing tools (grep, wc, sort, > uniq, perl, etc) to these messages. It would be nice if the next release made > that reasonably easily possible. That's the main motivation for mhfixmsg. The man page describes it in detail, esp. with the new EXAMPLES that I posted earlier. If you have any questions, please let us/me know. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Jerrad wrote: > I use slocal with rcvstore and at various times either MIME-hooks or the > following .mh_profile entries > > add-hook: /usr/local/bin/mhfixmsg > mhfixmsg: -decodetext 8bit -reformat -replacetextplain Note that -decodetext 8bit and -reformat are defaults, so they're not necessary in your profile (unless they're needed to override something else that you're doing). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Conrad wrote: > Yes, seems so; I guess I'd just like a "best practice" section in the > mhfixmsg man page which shows (for example) a recommended command line > invocation (more-or-less covered a few emails back) and a procmail recipe. There's been a procmail recipe in the man page since March of 2013, under "Integration with procmail". > I've tried running mhfixmsg across a selection of my email, and encountered a > mixture of complaints and occasional dumped cores (which I'll investigate and > report on — it may be that my Debian nmh-1.6-2 has bugs not present in the > current version). Possible, there have been bug fixes over the years, not sure what Debian has ended up with. It's so easy to download and build the latest, assuming you have modern autoconf, etc., so I recommend that instead of chasing down bugs in an older version: $ git clone git://git.savannah.nongnu.org/nmh.git $ cd nmh $ docs/contrib/build_nmh -div The -i option to build_nmh will install, in the location that it prompts you for. > In principle I'd *like* to run mhfixmsg on email as it's delivered, but I'm > also sympathetic to the "keep the wire copy" argument, and a little worried > because of the abovementioned failures; does anyone else run it through > procmail? Yes, I use the procmail recipe that's in the man page. It saves a backup of each message in case you want. I've never had to look at a backup. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Norm wrote: > I want to output to stdout all the lines of that part that contain the > string "family". What command go I feed into 'grep family"? Well, it depends whether you want to modify the message on disk or not. If you do want to modify the message permanently: $ mhfixmsg $ grep family `mhpath cur` Some of us run mhfixmsg on our messages as we inc them, so we can then use grep, etc., directly. If you don't want to modify the message: $ mhfixmsg -outfile - | grep family -outfile can be abbreviated in usual MH fashion. Those commands will output all the lines, in all parts, of the message. You asked "of that part". To just grep one or more specific parts, you could use mhstore, but that has nothing to do with (and precedes) mhfixmsg. > Suppose that I know that the current message in the current folder has a part > which is either utf-8 or a quotedPrintable and that It doesn't matter whether you know that the message has UTF-8 content, or quotedPrintable or base64 encoding. mhfixmsg won't decode or change the character set if it doesn't have to. And it's safe to run mhfixmsg multiple times on a message. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Future directions for nmh
Laura wrote: > but I would be seriously inconvenienced if mh directory mail store > went away. Enough of us would also, I expect, that this won't happen. At least at some layer that the user can see. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Maybe time for a new release?
Norm wrote: > Much of that was not clear to me from the man page. But that may say more > about me than about the man page. I don't know about that. In any case, I added all of it to the man page this morning. I expect that it will be useful to others. Keep the questions coming. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhfixmsg defies the principle of last surprise?
Valdis wrote: > So trying to debug why a message got eaten by procmail. What does "mhlist -file t1" say about the message? mhfixmsg -verbose? Would you please send me some reasonably complete extract of the message so that I can debug it? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhfixmsg defies the principle of last surprise?
Valdis wrote: > Sending you the message as an attachment via private e-mail. The MIME boundaries didn't match, and the one at the end of the message was broken across two lines. mhlist did notice. I committed a fix to mhfixmsg to not modify the message. At all. Thanks. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Big patch: Add XOAUTH2 support for SMTP and POP
Eric wrote: > I think we decided my names were ok? I don't mind at all if someone > wants to change them now. I think they're fine. > > - Repeating -user for each command is possibly odd. Maybe put > > -user on mhlogin and save it in the cred file. Arguably easier > > -for the user this way, arguably not. Changing it would > > -complicate the code slightly. I don't really care either way. > > As I said, this would complicate the code, and I'm not really sure > it's worth it. So you have -user foo repeated on a few lines in > .mh_profile, so what? I think that I'll want -user, to support multiple accounts on the same server. > > - I have a lot of test cases in only a few broadly categorized > > test scripts, and they print descriptions as they go so it's > > easy to see what broke. This messes up the test suite output. > > Does this make sense, should I change this only to print only > > if some environment variable is set, or should I just break > > these up into one test case per script? I'd kinda prefer the > > latter, but I don't know if anyone objects to a big pile of > > test scripts in there. > > I thought someone had a suggestion for this, but just now I looked for > it and didn't find it. I don't recall a suggestion. However, I just committed (on the xauth branch) an optional mechanism that quiets the tests when successful, but outputs the line that identifies the particular test that failed when that happens. I think this provides what you want, but if not I'll take another shot at it. The only changes to the oauth tests were to replace "echo" with "start_test", and add one "finish_test" at the end. start_test saves the message instead of outputting it, and a trap function outputs it only on failure. > Also, I never did figure out what to do about different error messages > on different platforms. I work on FreeBSD and Linux and they were > different; never mind what other platforms look like... We can see what happens after merging to master and running on the buildbots. Shouldn't be a big deal. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Username containing "." appears to cause test to fail
Greg wrote: > I'm running OS X 10.9.5 and my username on this machine > "gregory.nisbet". I believe this is causing one of the tests to fail. Yeah, I'm not surprised. I'll take a look later. David > Hi everyone, > > I'm running OS X 10.9.5 and my username on this machine > "gregory.nisbet". I believe this is causing one of the tests to fail. > > I followed the following procedure for installing `nmh` > > % mkdir -p $HOME/opt/nmh > % cd $HOME/nmh > % git clone git://git.savannah.nongnu.org/nmh.git > % sh autogen.sh > % ./configure > % make check |& tee /tmp/error.log > > Here's the output of the last command > > slocal: no such local user as nisbet > FAIL: test/slocal/test-slocal > > I've tried looking through the test-slocal script and it isn't obvious > to me where the error is occurring. > > Please let me know if there's any additional information that would be > helpful. > > Thanks, > Greg > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Username containing "." appears to cause test to fail
Greg wrote: > I'm running OS X 10.9.5 and my username on this machine > "gregory.nisbet". I believe this is causing one of the tests to fail. I just committed a fix. Without -user, slocal would default to a user based on addr. It would removed characters before the first period, if any. It's been that way since 1987, at least. I can't think of good reason to keep that behavior, so I changed the default -user to be the same as the default -addr. Thanks for reporting this. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Sending Binary Attachments
Hymie wrote: > The easy way: > > from the "what now" prompt, answer "attach /full/path/to/filename" Yes, that's the easiest way. The whatnow(1) man page describes the commands for managing attachments. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 2 of 88 tests failed on Unbuntu Trusty
John wrote: > I hope this report is useful to you. > I ran configure --prefix=ONETHING --exec-prefix=ANOTHERDIR > make > make test and got two errors (see below)., > As the errors will show, I was attempting to build/install in AFS. I don't have AFS installed so I can't debug these. Would you be willing to build/install in a non-AFS directory and see if those tests pass? I have installed and tested successfully on Ubuntu Trusty on an ext4 filesystem. If you want to see exactly where a test fails, you can run it individually under sh -x, e.g., $ sh -x test/refile/test-refile Just be sure to run test/cleanup if you modify the code and rebuild. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mts.conf that works with fastmail?
Thomas wrote: > If I understand correctly, initialtls is TLS and tls is STARTTLS. Yes, where initialtls encrypts the entire SMTP transaction. I bring that up because it might explain the following (in the other direction): > I didn't manage to receive POP mail from nmh with inc, If you want to use inc, it should work via an ssh tunnel. I used the /etc/stunnel.conf below to inc from at&t on Fedora. David /etc/stunnel.conf: pid= /var/run/stunnel.pid debug = 4 client = yes foreground = yes [pop3s] accept = pop3s connect = inbound.att.net:pop3s /usr/lib/systemd/system/stunnel.service: [Unit] Description=stunnel After=network.service [Service] ExecStart=/bin/stunnel ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] contrib to select mail server based on From: in draft
I added a program, docs/contrib/sendfrom.c, that selects the SMTP server based on the draft's From: address. The source code can be viewed at http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/contrib/sendfrom.c An excerpt from the usage notes is below. It can take full advantage of nmh's OAuth support, but that support is currently only available on the xoauth branch. It'd be nice if send read the draft and added the switches for post. It'd be easy to merge that code from sendfrom into send, and I'd be glad to do it if there's interest. David * This program fits between send(1) and post(1), as a postproc. It makes up for the facts that send doesn't parse the message draft and post doesn't load the profile. * * To use: * * 1) Add profile entries of the form: * *sendfrom-: * *The email address is extracted from the From: header line of the message draft. Multiple profile entries, with different email addresses or domain names, are supported. This allows different switches to post(1), such as -user, to be associated with different email addresses. If a domain name is used, it matches all users in that domain. * *Example profile entry using OAuth for account hosted by gmail: * * sendfrom-gmail_addr...@example.com: -saslmech xoauth2 -authservice gmail -tls -server smtp.gmail.com -user gmail_lo...@example.com * *Example profile entries that use an nmh credentials file: * * credentials: file:nmhcreds * sendfrom-sendgrid_addr...@example.com: -sasl -tls -server smtp.sendgrid.net * sendfrom-outbound.att.net: -sasl -initialtls -server outbound.att.net -port 465 * sendfrom-fastmail.com: -initialtls -sasl -saslmech LOGIN -server smtps-proxy.messagingengine.com -port 80 * *where nmhcreds is in the user's nmh directory (from the Path profile component) and contains: * * machine smtp.sendgrid.net * login sendgrid_lo...@example.com * password * machine outbound.att.net * login att_lo...@example.com * password * machine smtps-proxy.messagingengine.com * login fastmail_lo...@example.com * password * * 2) To enable, add a line like this to your profile: * *postproc: /contrib/sendfrom * *with expanded. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] contrib to select mail server based on From: in draft
Conrad wrote:
> Do you have anything set up to automatically alter From addresses when
> replying?
Here's the relevant part of my replcomps:
%<(nonnull(getmyaddr{to}))From: %(myname) <%(getmyaddr{to})>\
%?(nonnull(getmyaddr{cc}))From: %(myname) <%(getmyaddr{cc})>%>
If one of my addresses isn't in the To: or Cc:, it puts a blank line in the
draft.
I fill that in manually (using an editor macro).
This comes in handy for show what that will do:
$ fmttest -format "$(grep From: $(mhpath +)/replcomps)" -message +inbox last
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] contrib to select mail server based on From: in draft
Ken wrote: > My only quibble is perhaps that the implementation > is a bit inelegant but on further reflection it's probably the best > that can be done given the current API. If you're referring to the special handling for whom, that doesn't need to migrate to send. A lot of the other code doesn't, either. I'm so not a fan of m_getfld, but it gets the job done. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] XOAUTH2 integration, and a few questions
Ken wrote: > I had a few questions; I guess Eric is probably the best person to > answer them, Right, but I'll take a stab at them in the hope that I can save him the trouble. > - From looking at the protocol document and the source code, it seems > that (using RFC 6749 termology) mhlogin gets an OAuth Authorization > Grant (involving the user's browser), and then uses it to get an > access token and a refresh token, and stores those in a credential > file (by default: oauth-gmail). Is that correct? Yes. Multiple token sets can be stored in that file, to support different logins, e.g., multiple Gmail accounts. We should add an example to the mhlogin man page. > Under what circumstances will the refresh token be invalidated? I don't know, but isn't that up to the resource owner? As in, why would nmh care? > - If the access token is old, the refresh token is used to get a new > one. When you have an up-to-date access token, it's used to constrct > the SASL exchange for the XOAUTH2 mechanism. Is that correct? Yes. > I really think it would be preferrable to just pass down the 'real' > authservice flag and have post(8) (well, probably the SMTP code) > construct the access token. If there's a reason it's done the way it > is now, I would like to understand it. All parameters configuring the service may be overridden by profile components, and even though only Gmail is supported out of the box, the user can define new services entirely in the profile. Profile components are prefixed by oauth-service-, for example, oauth-gmail- credential-file which specifies where mhlogin should write credentials and where send should read them. And post doesn't read the profile. This also allows a postproc to do things that send/post can't. > I think it's almost ready to go; do other agree? Definitely. I've been using it, completely successfully, for a few months. It's my favorite recent nmh addition. BTW, I merged master to the xoauth branch in the hope that it would avoid merge conflicts when merging the branch to master. It won't, completely, so let me know if you want me to do it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] XOAUTH2 integration, and a few questions
Ken wrote: > It occurs to me that this makes it hard to have a postproc that sends > to different mail servers based on the "From" address ... because this > mechanism is unique in that it requires "send" to generate the access > token, and you can't change things when postproc is called. Well, you can (and I did in sendfrom.c) by relying on the fact that (most) MH switches only use their last value if repeated. > Ah, I see. THAT works because send(1) reads the profile for you and > passes down the "credentials" entry via the -credentials switch. > Hm. Could something like that work for post? It would require some > rejiggering (that I would be willing to do), but instead of passing down > the access token on the post command line, we could do: > > -oauth-cred-file > -oauth-client-id client_id > -oauth-client-secret client_secret > > ... and so on. There'd be 6 or 7 of them, so this is getting a bit ugly for switches, but OK. But should we consider alternatives, such as pseudoheaders? > A postproc could get all of those entries via mhparam. That seems like it > "fits" a bit better. Thoughts? Like I said, I'd be willing to do this > work since I'm the one asking for it. Or let me know if you want me to do it. The OAUTH code is quite clean so this won't be hard. And I need to integrate sendfrom into send, and it will have to change a bit. And it would be good to have Eric's thoughts. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] XOAUTH2 integration, and a few questions
Ken wrote: > I'm just thinking about a hypothetical world where there would be two > different mail servers that support XOAUTH; you don't get to make the > choice in postproc, because send(1) is the guy who generates the bearer > token. Actually, you do get to make the choice, because postproc can generate the bearer token. (sendfrom.c does, by overwriting the -authservice switch. See its call to mh_oauth_do_xoauth().) Are you still sure you don't want me to move it to post? :-) We might want to consider renaming post's (undocumented) -authservice switch. This is a bit confusing. > I looked at prior art; besides -credentials, which you added, there > is also -idanno, which is the number of the file descriptor to write > annotations to. It seems like this is the best fit, since it my > mind it falls under "stuff send(1) wants to communicate to post(8)". Agreed. Also, post currently doesn't parse the draft, and I don't think we want it to. > This brings up a related point; should we document all of those internal > switches like -idanno? I would say yes. It'd be nice. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] XOAUTH2 integration, and a few questions
Ken wrote: > Errr ... I'm not sure what you mean there, but it certainly does parse > the draft to decide who to deliver the message to (also, to set the > SMTP envelope address, process Fcc, and a few other things). Unless I > misunderstand what you mean, of course. My mistake, I should have said that send(1) doesn't parse the message draft. It'll have to when I merge sendfrom into it. Actually, it already does parse the draft in one special case, when it splits one message into message/partial messages. So I don't think it's that bad. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] contrib to select mail server based on From: in draft
Ken wrote: > >[David:] > >I added a program, docs/contrib/sendfrom.c, that selects the SMTP > >server based on the draft's From: address. > > > >The source code can be viewed at > > > >http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/contrib/sendfrom.c > > I think this is great. My only quibble is perhaps that the implementation > is a bit inelegant but on further reflection it's probably the best > that can be done given the current API. I say it should go into the > tree as part of send(1). Done. It's on both master and the xoauth branch. docs/contrib/sendfrom.c has been removed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] decode base64 auth info in -snoop output?
Hi, post(1) -snoop currently doesn't decode base64-encoded smtp authentication information. I'm thinking of decoding it to make it easier to use, and to not mask it. For example, -snoop currently shows this with AUTH LOGIN: (tls-decrypted) <= 334 VXNlcm5hbWU6 (tls-encrypted) => dXNlckBleGFtcGxlLmNvbQ== (tls-decrypted) <= 334 UGFzc3dvcmQ6 (tls-encrypted) => bXlfcGFzc3dvcmQ= But I'd rather see this: (tls-decrypted) <= 334 Username: (tls-encrypted) => u...@example.com (tls-decrypted) <= 334 Password: (tls-encrypted) => my_password It might not always be easy to find the base64 encoded text, but I think it would help with the obvious, common cases such as the above and AUTH XOAUTH2. Thoughts? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] decode base64 auth info in -snoop output?
Ken wrote:
> I personally have no objections ... but my only caution is that sometimes
> the base64 encoded SASL tokens are actually binary, so you should make
> sure you use a pretty-printer that can handle binary.
Right, I was thinking of hexifying non-printable characters, e.g.,
displaying [0x01]. And assuming ASCII, which if I read RFC 4954
right, is valid ("non-US-ASCII is only allowed as hexchar", where
hexchar is "+" HEXDIG HEXDIG). Maybe that suggests using +01 instead
of [0x01], though I like marking the SASL bytes differently from user
data.
> Also, to me the point behind -snoop is to observer the actual SMTP/POP
> network transmission; decoding the base64 means that you won't see that.
> So I don't know if it's worth marking it somehow that it's base64, or
> maybe make it so can not decode the SASL tokens.
I'd rather not extend the length of the current indications such as
tls-decrypted and sasl-decrypted. tls-b64decryp and sasl-b64decryp ?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] decode base64 auth info in -snoop output?
Ken wrote: > I don't think you can make an assumption what the _decoded_ base64 SASL > tokens are; that is just talking about what appears in the AUTH messages, > not what the tokens contents are. I mean, we can't even make an assumption > with regards to character set without knowing more about the particular > SASL mechanism. I'm not sure, but in any case, there's no character set identification. So I know what else we can do, other than display a single byte at a time, with hexified non-printable (as ASCII) bytes. > >I'd rather not extend the length of the current indications such as > >tls-decrypted and sasl-decrypted. tls-b64decryp and sasl-b64decryp ? > > Well, if you're using pure SASL encryption/decryption, encryption doesn't > start until SASL is complete, so I'm not sure that works. Looking at the code, it should. But I like this better, anyway: > Here's an idea. How about: > > 334 b64 > b64 David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] decode base64 auth info in -snoop output?
The attempted base64 decoding of -snoop traffic has been committed. Here's an example of what an AUTH PLAIN request will look like: AUTH PLAIN b64 I also tried to handle XOAUTH2, AUTH LOGIN, and any line including or following a 334 request from the server. If the base64 is invalid, a warning message will be printed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] folder -nocreate +/this/does/not/exist
Ralph wrote: > $ mhparam folder > -nocreate > $ folder +/this/does/not/exist > $ echo $? > 1 > > I'd expect something on stderr. Well, the man page doesn't promise that: Specifying -nocreate will cause folder to exit without creating a non-existant folder. It wouldn't be too hard (provide a new done()) to print a message on stderr. But, I think the non-zero exit status is sufficient. Esp. in scripts. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] folder -nocreate +/this/does/not/exist
Ralph wrote: > Well, folder(1) is kind of cd and mkdir in one. With -nocreate, I'm > cd-ing to the folder, and cd complains when the directory's missing. I > agree I should notice the lack of "/this/does/not/exist+ has no > messages.", but the Unix norm is silence if all's well so I've been > conditioned. My following commands, in the wrong folder, can wreak > havoc. :-) OK, I added an error message: $ folder +/this/does/not/exist -nocreate folder: folder /this/does/not/exist does not exist $ echo $? 1 David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Format function to create wrapped header lines?
Ken wrote: > But it turns out that it just appends the message-id to the existing > header without wrapping ... and if you get into a long email thread, that > can exceed the maximum email header limit. This seems like poor behavior. I think that appending the message-id on a new continuation line would be good enough. It wouldn't repair incoming References header lines that are too long, though. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Format function to create wrapped header lines?
Ken wrote: > Hrm. I thought about that, but it seems like it's slightly suboptimal; > You'd have to deal with a header that would take up a lot of space. As in more lines? I see 3 or even 4 screenfulls of header fields in typical messages these days, so a few more lines won't matter. > Also, if you want 'nice' formatting, you need something smarter that knows > about the length of the header (like what formataddr does). Really, I > think you could adapt most of the formataddr code, except for splitting at > commas. It may be that my concerns about "nice" header formatting are not > worthwhile. I don't think it's worth the complexity. I don't usually look at References, and the default mhl.headers doesn't cause it to be displayed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First Byte of Body Lost on inc(1).
Ken wrote:
> > [Ralph wrote:]
> > 1 memmove(0x13e61a0, "\n\nab\n", 5) = 0x13e61a0
>
> That looks like it happens in sbr/m_getfld.c:read_more().
I think that first character is missed here:
> > 2 memcpy(0x13ec980, "b\n", 2) = 0x13ec980
That's this line (738) in m_getfld():
memcpy( buf, bp, c );
with bp off by one, I think due to this increment in Getc():
if (read_more (s) == 0) {
/* Pretend that we read a character. That's what stdio does. */
++s->readpos;
return EOF;
}
In spite of the comment, I don't know why readpos needs to be incremented.
Also, I noticed:
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First Byte of Body Lost on inc(1).
I wrote: > In spite of the comment, I don't know why readpos needs to be incremented. After sleeping on it: it doesn't. I committed the fix. Thanks, Ralph and Ken. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Need some general advice
Ron wrote: > Before answering, keep in mind that I will likely need to configure the > SMTP server on the remote VM (postfix) in such a way that my home machine > will be able to authenticate to it, you know, in order to send outbound > mail. (The last time I tried something like this I think I gave up in > the end because it seemed like too much of a pain in the ass to get the > authentication all working. But now I have no choice, and have to make > it work this time.) Support for authentication in nmh 1.6 is better than it used to be. See "credentials" in the mh-profile (5) man page. Support for XOAUTH2 will be in the next release, and is currently on the main trunk. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Forwarding the attachments to a message or messages
Ken wrote: > [Norm:] > >Is there a way to forward messages so that all the attachments of > >the forwarded messages are attachments to the new message, other than > >a script using mhlist? > > If you want to create a new message which just happens to contain all of > the attachments from another message, I think you're going to have to > write that. Yeah, though it should be really simple (as in not worth writing?). Just create a tmp directory, cd to it, mhstore (probably with -type application) the attachments, and then add them with "at *" at the whatnow prompt. A custom whatnowproc could do the attach, though again maybe not worth the effort. I think that Norm might have been asking about attachments from multiple messages, in which case dist wouldn't work. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Laura wrote: > My nmh displays base-64 encoded mail just fine, but if you try to reply > or forward with the message quoted, it doesn't convert. nmh 1.6 has docs/contrib/replyfilter, it contains usage instructions. nmh 1.7 will have (and current master has) docs/contrib/replaliases, it also contains usage instructions. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] EAI?
Resurrecting an old topic, Email Address Internationalization (EAI). The original message is at http://lists.nongnu.org/archive/html/nmh-workers/2015-08/msg0.html It doesn't mention RFC 6531, SMTP Extension for Internationalized Email, which is what this message is mostly about. Ken wrote: > - SMTPUTF8 looks relatively straightforward to implement, at least. I've done that on a branch, smtputf8. I'd like to include it in 1.7. One design issue is how should the user enable sending of 8-bit (UTF-8 encoded) addresses. My first attempt was two explicit steps, one to disable RFC 2047 encoding of addresses in the draft message and the other to instruct post, via send, to use SMTPUTF8, if supported by the SMTP server. In terms of What now? responses: What now? mime -headerencoding utf-8 What now? send -eai But to make it more convenient and remove potential mismatches, that -eai switch in the second step could be removed, so it would just be send as usual. post would look at the draft and automatically use SMTPUTF8 if it has any 8-bit header field bodies. Downside would be if the user manually put 8-bit characters into a header field by mistake, post would then use SMTPUTF8 (if supported by the SMTP server). But I think that's really the user's problem, and not such a big one, and much better than having to enable this with two steps. Preferences? It'd be up to the user to know if their SMTP server supports SMTPUTF8. If it doesn't and they try to use it anyway, post will report an error and not send the message. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] TLS certificate validation
Ken wrote: > I've been poking around and I see that there is something that MIGHT > be worthwhile to look at: something called "trust on first use" (TOFU) Sounds good to me, I'd use it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] EAI?
Laura wrote: > Whatever we come up with, I will need a setting for 'default utf' > to handle my little corner of the world. I don't want to type send -eai > for practically every piece of mail I create or reply to. :) Oh, this is just about EAI and that's a much, much smaller corner of the world. In fact, not all SMTP servers support it yet. It's just for handling 8-bit addresses (and other header field bodies). nmh 1.6 handles 8-bit, include UTF-8, message bodies as-is. So will nmh 1.7. And just to note in case it's useful, if you want to enable a switch for all uses, you can put it in your profile. For example, send: -msgid -messageid random If you need to override occasionally, many switches have a corresponding -no form, -nomsgid in this case. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Laura wrote:
> I think this may be an advantage of living in a part of the world
> where ASCII is too small.
I don't know much about utf-7, but a quick look around shows that it
reduces the need for base64 or quoted-printable encoding.
> mhshow-show-text/plain: \
> iconv -f "$(charset=$(echo %a | sed -n -r 's/.*charset="
> ?([-a-zA-Z0-9_]*).*/\1/p');
> if [ x$charset = xunicode-1-1-utf-7 ]; then echo utf-7;
> else echo ${charset:-iso-8859-1}; fi)" | less
I don't think you need that with nmh 1.6, and you shouldn't with 1.7,
assuming your locale (LANG, LC_ALL, or LC_CTYPE environment variable)
is set to a utf-7 or utf-8 (preferred by some) locale.
> I forgot about quoted printable -- I do get those, but very, very, very
> rarely. I never figured out what quoted printable is for.
Like base64, it's another way of encoding 8-bit content so that it
can be sent and handled by 7-bit mail systems.
> The problem is that you typically get your new nmh one day when you, or
> maybe the sysadmins at work, do a system-wide update. Since you never
> asked for it to get changed, you never noticed that you have a new
> version (unless things stop working for some reason). I am not sure what
> the best way to handle this is,
Build your own nmh? If you want to give that a quick try:
$ git clone git://git.savannah.nongnu.org/nmh.git
$ cd nmh
$ docs/contrib/build_nmh -div
though it assumes you have various packages installed, as noted in the
MACHINES file. Those prerequisites are reduced if you build from the
distribution, but then you wouldn't get the bleeding edge.
> But can I make interleaved comments just as I did on this piece of mail
> in some mail that I am forwarding to others?
Not with dist, but you can with forw(1).
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Ralph wrote: > I meant to mention a barmy idea about dropping a "welcome" email on the > unsuspecting. Or add the welcome to the output of install-mh(1)? Its output is brief enough now that it shouldn't be lost. Question is whether new users use install-mh, though if they don't, they probably don't need a welcome. I do have some issues with install-mh, such as -check only looks for ~/.mh_profile (or $MH if set), but I don't think that's relevant. > A similar thing, but on a new release with essentially the NEWS of > changes? We could track whether they've had the welcome, and 1.6's > NEWS, in ~/mail, and the above scripter could block them all by creating > a file or setting an option. I'm warming up to the idea. Though I'm not sure what should trigger it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Laura wrote: > I interpreted this to mean local sysadmins at the site where you are > running nmh, i.e. somebody at Chalmers University, not you people. If > you want to hear from people, I think you need to be a whole lot more > welcoming. How about this, in nmh(7) and the output from install-mh(1): BUGS Send bug reports, questions, suggestions, and patches to nmh- work...@nongnu.org. That mailing list is relatively quiet, so user questions are encouraged. Users are also encouraged to subscribe. If problems are encountered with an nmh program, they should be reported to the local maintainers of nmh, if any, or to the mailing list noted above. When doing this, the name of the program should be reported, along with the version information for the program. To find out what version of an nmh program is being run, invoke the program with the -version switch. This prints the version of nmh, the host it was compiled on, and the date the program was linked. New releases and other information of potential interest are announced at http://www.nongnu.org/nmh/ . > This is one place where I would like a link to documentation, at some > master site, (so you can read it even if the docs never made it to > where they are supposed to be for your distro.) Unfortunately, there isn't such a site. If the man pages didn't get installed, that's a packaging problem. Modern nmh should be easier for packagers to deal with than older versions. Ralph wrote: % Is it worth having an mh man page (or did it used to be MH?) that either % explains the transition, or is simply another name for nmh(7). Looks like mh 6.8.5 docs had an MH page, I'll add it as an alias for nmh(7). Most of the BUGS section of the nmh man page came directly from it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Paul wrote: > any reason we couldn't in principle have a separate git tree on > savannah just for "compiled" man pages, and other docs? Is there really a need? And a separate tree is more likely to get out of sync. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Paul wrote: > perhaps replyfilter should move to libexec. The problem is the replyfilter uses perl and Ken doesn't want to add that as a dependency. (I agree.) There will be a native solution in 1.7: repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs text/plain '' That's a mouthful, hence the shell functions in docs/contrib/replaliases. They also give control over those switches. It'd be great if others tried this out and gave feedback. Though until it gets into a release, that requires building from master. > in the same vein, if there's anything in the doc/nmh/README* files > that should be more accessible, we should try and fix that as well. Yes, those files tend to fall out of date. And some of the contents might already be in the man pages. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Laura wrote: > In a message of Sun, 25 Sep 2016 12:57:19 -0400, David Levine writes: > > >How about this, in nmh(7) and the output from install-mh(1): > > This looks good to me. Thanks. I added it (along with where to subscribe to the mailing list) to the nmh(7) man page and the end of the output of install-mh(1), and an excerpt the end of each -help bbmessage, > Ah, I was talking about the case where there is a man page, but no > user documentation. Lots of places I go don't install the documentation > everywhere, just some places. To add to what others have said: we rely on the man pages as the user documentation. A docs directory, including the FAQ, is also included in the distribution. It isn't very large. I'd be interested to hear of packagers who omit it. Jerry Peek's excellent book is available online at http://rand-mh.sourceforge.net/book/ . Though it looks like it was last updated in 2006. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Ken wrote: > >> It's not in the EPEL repos either (which are basically extras > >> from Fedora built for Red Hat). Might be hard to get it into > >> Red Hat without somebody at RH taking it under its wing, but > >> EPEL is controlled by Fedora, so probably could the Fedora > >> package owner to roll an EPEL version? > > > >Yeah. Try filing a bugzilla request for that (against the existing > >nmh package, I think). > > Looks like David Levine is the package owner (along with Josh Bressers). > So maybe that's a to-do item for 1.7? :-) Right, I don't currently have permissions to commit EPEL packages but have requested. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
William wrote: > I'd prefer a seen sequence to an unseen sequence as this would let > an MDA deliver directly into an nmh folder without needing to update > the .mh_sequences file. So would rcvstore -nounseen, can you use that? > Possibly implemented by checking the specified unseen sequence for > the presence of the Sequence-negation prefix and behaving > appropriately (FX: waves hands vigorously). I'm not sure what you're trying to accomplish. Do you want the unseen sequence to be maintained? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Oliver wrote: > Could we perhaps include a configure test Easy, just add getline to the AC_CHECK_FUNCS in configure.ac. > and a fallback implementation such as the one below (it is a > public domain implementation tweaked to use mh_xmalloc etc)? If we include that implementation, I think we should attribute it, at least with the URL and ideally with the the author name. Just looking at it quickly, the unsigned char cast will probably cause a compile warning on some platforms. And I don't see why it's necessary. > I'm not quite sure which file would be appropriate for this to be > included in. sbr/utils.c seemed a reasonable choice Agreed. > but one of the test cases also depends on getline Add $(LDADD) here, in Makefile.am: test_fakehttp_LDADD = $(LDADD) $(POSTLINK) > I also can't work out how to run the tests by the way. make test > doesn't work and the README file provides no indication of how > to run them. tests/README says: To run these tests you can do "make check" via the top-level Makefile. It's also mentioned under "nmh test suite" in docs/README.developers. This isn't mentioned in the source tree, but Lyndon's buildbot results are available at http://orthanc.ca:8010/waterfall David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Valdis wrote: > It's not in the EPEL repos either (which are basically extras > from Fedora built for Red Hat). For EL6, the build needs to use autoconf268 instead of autoconf. And it needs automake 1.12, but it looks like automake 1.11 is installed, so that might be a show stopper. And worse on EL5: I don't see any autoconf or automake. Unless someone wants this enough to guide me through these, I won't bother. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
I wrote: > For EL6, the build needs to use autoconf268 instead of > autoconf. And it needs automake 1.12, but it looks like > automake 1.11 is installed, so that might be a show stopper. > > And worse on EL5: I don't see any autoconf or automake. I requested an EPEL7 branch. It looks like it has sufficient prerequisities. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Tom wrote: > Normal expectation is that builds should be done from a released tarball > if the upstream publishes such. The spec had autoreconf -force. I removed that and the auto* dependencies, and now builds succeed. I'll submit. Thanks! David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Ken wrote: > The exact issue is that some MUAs will use RFC 2047 encoding > for a filename that contains 8-bit characters when creating a > Content-Disposition field. > I am torn as to what to do here. It feels somehow wrong to support this > for decode natively, but I'm not completely convinced of that. We have > a number of email programs that get this wrong, including a very popular > one. This might be something perfect for mhfixmsg to deal with. What > do others think? Sounds like a job for mhfixmsg, I'll look into it for 1.7. It would probably go into the small category of things that it fixes unconditionally. The question remains of whether mhstore should decode 2047-encoded filenames natively. It'd be friendly and it's very unlikely that what looks ike an encoded string isn't. On the other hand, running mhfixmsg shouldn't be prohibitive. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh welcome message
I added a welcome message when nmh detects that its version changed. You'll you see it the first time after checking out the welcome branch (and 1.7, assuming we want to keep this). It doesn't happen if stdin or stdout isn't connect to a terminal, or for any of these commands: mhbuild, mhfixmsg, mhparam, mhpath, prompter, whatnow, whom or any of the libexec commands: ap, dp, fmtdump, mhl, mkstemp, post, rcvdist, rcvpack, rcvstore, rcvtty, slocal, spost, viamail Here's the message, printed on stderr: === Welcome to nmh version 1.6+dev See the release notes in /home/levine/lib/nmh/share/doc/nmh/NEWS . Send bug reports, questions, suggestions, and patches to nmh-workers@nongnu.org. That mailing list is relatively quiet, so user questions are encouraged. Users are also encouraged to subscribe, and view the archives, at https://lists.gnu.org/mailman/listinfo/nmh- workers . This message will not be repeated until nmh is next updated. === Thought the message will be repeated if the nmh command failed. It's implemented by adding a Version: string to the user's context. OK? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh welcome message
Paul wrote: > is there a "press enter to continue?" prompt? if not, many commands > which bring up an editor will tromp on that text before it can be > read. Oh, good idea, I'll add it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh welcome message
Ralph wrote: > So both have to be to a TTY. Perhaps stderr, where the welcome appears, > should be too? Otherwise a `2>/dev/null' in someone's script might > throw it away. Agreed, I'll add stderr. Thanks. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh welcome message
Oliver wrote: > I like to have a different current folder in different terminals so in > my .zshrc, I do: > export MHCONTEXT=/tmp/context.$$ > I've also got aliases which point it to /dev/null to prevent folder > changes, e.g: > alias new='MHCONTEXT=/dev/null flist +inbox +nmh-workers + > > So I'm sorry for being a pain but I'm concerned that the message > will get repeated with my non-standard usage. How about suppressing all of them with something like a "Welcome: disable" profile component? > Perhaps if the context file comes from $MHCONTEXT, it could only > print the message if the context file already has a Version: reference > where the version is old. OK. > Also, it looks like you're just doing strcmp on the version. So > what happens for someone with an NFS shared home where the nmh > versions are out of sync between different client systems. They'll > get a welcome message every time they switch between their NFS > client systems, right? It might be better to limit it to cases where > the version number is actually newer. But I'd like to be notified if a new version is backed out. So I think that suppression is the way to go in this case. > If I remember correctly, there's already something printed if > .mh_profile is missing. Have you checked how it interacts with that. That's a fatal error, and it happens before the nmh version check. > I notice that install-mh is also in the exception list. That's because install-mh prints the message unconditionally. > Another slight concern I have is with the exceptions being checked by using > strcmp on invo_name because links to nmh commands is maybe not that > uncommon to get different keys for ~/.mh_profile. Instead of using invo_name, we could put a key in each program, so it'll work no matter how it's called. (The key would probably be an additional parameter to nmh_init()). > As a final point, should it be easier for packagers to customise the > message? I don't think so. The message is completely nmh specific. Packagers can add with a postinstall, if that's supported. Or a patch, if not. I'd be willing to add something here if there's demand, but I just don't expect it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] TLS support for POP merged to master
Eric wrote: > but it crashes after a few messages with "inc: TLS peer aborted > connection". I see the same behavior. It looks like it's repeatable, always happens in the same place. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Multiple From Addresses.
Ken wrote: > > [Ralph:] > >Would it be more useful to demand From be a single header in the draft, > >though still allow that one header to have multiple addresses? That > >would catch the accidental sending of a multiple-From draft due to > >editing woes whilst still allowing multiple From addresses. > > Personally, I don't see the value in changing current behavior. Others > are welcome to have a differing opinion. I think it would be a good idea to change it. Ralph is right, multiple >From headers bypass the check for missing Sender in post. Multiple addresses in one From header don't. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
I wrote: > Ken wrote: > > > The exact issue is that some MUAs will use RFC 2047 encoding > > for a filename that contains 8-bit characters when creating a > > Content-Disposition field. > > > I am torn as to what to do here. It feels somehow wrong to support this > > for decode natively, but I'm not completely convinced of that. We have > > a number of email programs that get this wrong, including a very popular > > one. This might be something perfect for mhfixmsg to deal with. > > Sounds like a job for mhfixmsg, I'll look into it for 1.7. Done. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Ken wrote: > >[Earl:] > >I do not recommend blanket 2047 decoding for parameter data. Just limit it > >to parameters associated with a filename. > > I find this argument convicing; thoughts from others? That's what I implemented in mhfixmsg: just Content-Type name and Content-Disposition filename. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
I almost hate to bring this up, but . . . mhstore already asks users (if isatty). We could do something like: the filename of =?...?= is encoded, save as unencoded [...] instead? [y/n] And define what to do if the response is no. If not a tty, we're back to the question. Safer to fail, friendlier to decode. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] 8BITMIME?
As Ralph noted a while back[1], SMTP has an 8BITMIME extension. nmh currently doesn't support it, except for the recently added EAI (SMTPUTF8, RFC 6531) corner case. I'm thinking about adding full support for it. One approach would be: 1) In post, look for a Content-Transfer-Encoding header. It has to be the header for the message, not any MIME parts, because we (I) don't want to run the MIME parser on the message. If found, post would trust that it's correct. If there isn't one, it could scan the entire message body for any 8-bit bytes. BTW, I just committed a fix to mhbuild to properly add a C-T-E for all text parts when required. It gets propagated to the message header. 2) If the message body is 8-bit: If the server supports 8BITMIME, enable it. If the server doesn't support 8BITMIME, fail with a message to user that they need to encode the message for 7-bit transport. That would be a change from current nmh behavior. Thoughts? David [1] http://lists.nongnu.org/archive/html/nmh-workers/2012-12/msg00032.html ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 8BITMIME?
Ralph wrote: > Hi David, > > >If the server doesn't support 8BITMIME, fail with a message to user > >that they need to encode the message for 7-bit transport. That > >would be a change from current nmh behavior. > > Current behaviour being it spots top-bit-set bytes and QPs or base64s? > As someone that pays for bandwidth by the byte, I'm all in favour of > more fully using all their bits. :-) Actually, unencoded 8bit is used (by mhbuild) for non-ASCII text. (It's used by send attach, and can be specified with mhbuild directives.) That's no change from 1.6. The issue is that post doesn't check if the SMTP server can handle the 8-bit data. The change mentioned above is to fail if it can't. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Earl wrote: > For any file nmh creates based on email parameter input, it should run it > through a sanitizer to remove any characters deemed invalid and remove any > pathname components. For security reasons, this filename will be ignored if it begins with the character '/', '.', '|', or '!', or if it contains the character '%'. > For example, what if I have: > > Content-Type: application/octet-stream > Content-Disposition: attachment; filename="/etc/passwd" > > or relative pathname attacks using "../.."? The /etc/passwd or relative pathanme will be ignored, and a name of the form message#.part#.subtype will be used instead (assuming no profile override). > I do not recall if nmh checks if a file with same name already exists. It can, starting with 1.6, using the mhstore(1) -clobber switch. > If we are to be security conscience, filename parameter should be ignored, > with files stored based on content-type, or at a minimum, just use the > filename parameter extension. An option can be provided to specify that the > filename parameter be honored, but even then, only use the basename after it > has been sanitized. Yup, we're there. The mhstore switch you refer to is -auto; the default is -noauto. mhstore also has an -outfile switch, so the user can specify a particular filename (to store all selected content). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Earl wrote: > Decode. I'm leaning that way, too. > How often are real files with "=?...?=" in their name them encountered? Often enough for some. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Lyndon wrote: > > On Oct 6, 2016, at 5:20 AM, David Levine wrote: > > > > The /etc/passwd or relative pathanme will be ignored, and a name of > > the form message#.part#.subtype will be used instead (assuming no > > profile override). > > I think this is very wrong behaviour. > > Filenames in the attachment meta-data are suggestions. But they can be very > valid suggestions, and shouldn't be ignored for arbitrary reasons. I don' think they are. > But leading paths must be ignored, as security dictates. > > The safest course of action is: > > 1) Take the basename of the suggested filename. But I wouldn't consider the likely result with filename=/foo/bar/README to be safest. > 2) Perform an exclusive open+create of the filename. > > 2a) If the file exists, and we are interactive, prompt for a replacement name > (or to overwrite); else (2c) That can be configured with -clobber ask, but that's not the default for (decades of) historical precedent. I don't think we should change the default here. It's easy enough for users to override. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Lyndon wrote: > > On Oct 6, 2016, at 8:11 PM, David Levine wrote: > > > > But I wouldn't consider the likely result with filename=/foo/bar/README > > to be safest. > > Why not? If there is no "README" file, create it. If there is, prompt for a > replacement if stdin is a tty, else synthesize a unique replacement name and > be done with it. It wouldn't be safest because I would risk overwriting README in the current directory. That's not what I expect. In any case, I don't think that we should change the mhstore defaults because that might break scripts as well as user expecations. Those include the default of -noauto. You can override those defaults in your profile (I do) to get pretty close to what you ask for. Though there isn't a basename, it should be possible to support that with formatting strings that pipe the content to a script that runs basename(1) on %a. To get back to the question about RFC 2047 encoded name parameters, I'll just add a note to the mhstore man page for users to use mhfixmsg to get around that. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] One-line Summaries of Parts of Emails.
Ralph wrote: > Regarding the > > [ part 2 - application/postscript - foo.ps ] > > that appears when viewing an email, has any consideration been given to > looking up a `summary' command for the MIME type/subtype, falling back > to type, in the same vein as mhshow-show-* profile entries? I get this for one example: [ part 2 - application/pdf - Statement.pdf 4.4KB (suppressed) ] But then, I'm using nmh 1.6 :-) > There's quite a bit of metadata that could be shown for images, PDFs, > DSC'd PostScript, etc., if the user chooses to start throwing the bytes > at interpreters. Perhaps a -[no]summary would be needed so he can block > them all simply. I'd block them all simply, just to avoid waiting for interpreters. And this works: mhstore -nov -part 2 -o - | pdfinfo - David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] One-line Summaries of Parts of Emails.
Ralph wrote: > I get MIME type and Content-Description, if there is one. > Is that `4.4KB (suppressed)' part of the C-D? No, but I see what it is. I'm actually using master, not 1.6, and DEFAULT_MARKER in mhshowsbr.c now has %(kilo(size). > Mm, just a bit tedious to have to tack onto a `show' for each part. Should be easy to script, if you don't mind the part info at the end. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Ralph wrote: > Hi Oliver, > > > A number of tests are failing on Solaris. This seems to mostly consist > > of: > > id: illegal option -- u > > Usage: id [-ap] [user] > > FAIL: test/mhmail/test-mhmail > > http://git.savannah.gnu.org/cgit/nmh.git/tree/test/post/test-post-common.sh#n12 > suggests the effective user ID is only used to cook up a `64000 + $euid > % 1000' port for the fake SMTP server to listen on. Presumably, > something more steady that the sh's $$ is sought? I replaced with $$. The idea was to allow overlapping invocations of the test suite, that's good enough. I didn't receive Oliver's message, though it is in the archive. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] gmail oauth2 howto
Ken wrote: > [Anders:] > >Trying to send a single message interactively...what's the mts.conf > >settings required? I tried server=smtp.gmail.com and strace suggests that > >it figures out to use port 587 itself (triggerd by the -sasl I guess), nmh (post(1) now defaults to using the submission port, 587. > Try adding -tls to send; smtp.gmail.com won't advertise that it supports > SASL until you negotiate TLS. Yup, I use this, it's one of the examples in the send(1) man page: sendfrom-gmail_addr...@example.com: -sasl -saslmech xoauth2 -authservice gmail -tls -server smtp.gmail.com -user gmail_lo...@example.com You might not be using sendfrom, but the send switchs are the same without it. (I'll add the missing -sasl.) I don't override any of the mts.conf defaults. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] forw
Norm wrote: > But what I don't understand is why isn't it? In fact, why isn't that > an option to forw, or even its default? I'm not sure what "it" is. Do you want to include attachments from more than one message? Do you want to always include all attachments from those one or more messages? If not, how do you want to let nmh which attachments to include or not? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] gmail oauth2 howto
Also, you'll need to use mhlogin before using xoauth2. See the mhlogin(1) man page for instructions and example with Gmail. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Laura wrote: > But I get them in the order they arrived. I want them in the order they > were sent, which can be a whole lot different, before I read them. > > I use my own filter for that. Be nice if nmh did that natively. as part > of folder? Sounds like a job for sortm(1). It defaults to using Date:, which I think is what you want. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Oliver wrote: > Another issue is that tests using require_locale look for locales > in lowercase, e.g. en_US.utf8. On Solaris plus various *BSD systems, > these are output in uppercase form, e.g. en_US.UTF-8. Fixed. I haven't looked at the getline() replacement. Are you going to do that? Your Makefile.am and configure.ac changes look good to me. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Ralph wrote: > +1. The `Forward' header is grabbing another one for nmh's use, in > addition to the existing `Attach'. Should we be using `Nmh-Forward' if > the user isn't likely to have the hassle of typing them most of the > time? Absolutely. The existing code allows either Nmh-Attach or Attach. We should use only Nmh-Forward here. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Ken wrote: > > [Ralph:] > >Because the sooner we create the prefix, the sooner future new headers > >can fall under it. Ken says we discussed this over `Attach'. Here we > >are for `Forward'. Next year it will be another one? > My recollection is that it actually came up originally for > Envelope-From, actually. Both, so this is the third time in nmh history. Let's settle it once and for all. The only responsible choice is to include the prefix. Otherwise, we run the risk of messages leaking out with internal pseudoeheader names. Like this message! Note that Nmh-Attach and Attach are synonomous. And all others, except Envelope-From:, used by nmh originated with MH. > I don't see the value of having a special Nmh- prefix. Traceability is valuable. > If they happen to leak out in the wild, > they won't harm anything since they're not official headers. The won't harm anything, but how will Ralph know who to ask to fix it? Does anyone manually insert "Attach:" into their draft messages? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Paul F. wrote: > lyndon wrote: > > > > This means, moving forward, we only generate nmh-* headers, while > > continuing to accept the old ones. Yup. > > This is particularly important now that "forw -mime" is becoming > > the default; these headers *will* escape now. > > why? how? it seems to me that you have to work pretty hard to > get them into the wild -- mhbuild will eliminate them normally, won't > it? Note that post scrubs Bcc, Dcc, etc. But not Nmh-Attach or Attach. Also, nmh (whatnow) uses Nmh-Attach internally, not Attach. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Paul F. wrote: > david wrote: > > Note that post scrubs Bcc, Dcc, etc. But not Nmh-Attach or Attach. > > why not? Actually, I was mistaken: it does filter out all header lines that start with "Nmh-". As to why it doesn't scrub Attach: because no one implemented that. > > Also, nmh (whatnow) uses Nmh-Attach internally, not Attach. > > immaterial. :-) Except to those who might want to update their scripts to be consistent, now that they know that post will filter out Nmh-Attach if it leaks through :-) David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Ralph wrote: > I've written a getline(3) from scratch based on > https://manned.org/getdelim.3p and am happy for it to have whatever > licence nmh needs. I've assumed POSIX, e.g. stdbool.h, SSIZE_MAX, etc., > so it may need some conditional preprocessor bits for portability to > older systems. Committed (after testing), thank you! I did add a check for stdbool.h. Let's see what happens with SSIZE_MAX. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Oliver wrote: > For the autoconf/automake stuff to replace getline, the following > patch seems to work. Should AC_REPLACE_FUNCS perhaps be earlier or > later in configure.ac? > > The final change on configure.ac is to cope with cc -V output having > slightly changed in the most recent version of the compiler. > > A number of tests are failing on Solaris. This seems to mostly consist > of: > id: illegal option -- u > Usage: id [-ap] [user] > FAIL: test/mhmail/test-mhmail > > /usr/xpg4/bin/id -u would work but I'm not sure how to select that. > I thought command -p might help but not with /bin/sh. Would comparing > $LOGNAME to root do the job? Any other ideas? > > Another issue is that tests using require_locale look for locales > in lowercase, e.g. en_US.utf8. On Solaris plus various *BSD systems, > these are output in uppercase form, e.g. en_US.UTF-8. I just committed configure.ac and Makefile.am that should pick up Ralph's getline(3) replacement if needed. So we should be ready for another try on Solaris. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] When a message goes only to me, as a cc
Norm wrote: > But sometimes I forget to otherwise address the message. But > then send will just go ahead and send the message, instead of > balking, as it would if I used fcc instead of cc. > > Is there a workaround that problem? I always "w" at the What Now? prompt before sending. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Starting the final call for features for 1.7
Ralph wrote:
> Hi Oliver,
>
> > Just two failures left:
> > usage: script [ -a ] [ typescript ]
> ...
> > This is a new check with the welcome message stuff. Judging from
> > online man pages for script, this will have problems on other systems
> > too. OpenBSD for example, only seems to have a -a option for script.
> > Can't we redirect standard input on it to provide the command?
>
> I doubt it.
Right, the script man page on some systems cautions against doing that.
> I think the test is mhparam(1)'s checking for a TTY on FDs
> 0, 1, and 2. OpenBSD's man page says $SHELL is used. Perhaps the test
> can make use of this.
>
> $ cat >cmd
> #! /bin/sh
>
> mhparam path
> $ chmod +x cmd
> $ SHELL=`pwd`/cmd script
Don't some systems require that the shell be listed in /etc/shells?
> > It took a bit of tracking down to find the bad substitution but it
> > seems to be from the w3m invocation being passed ${charset:+-I
> > "$charset"}
> >
> > The space between -I and the charset is the problem.
> Yep. When two words are required, the test could be duplicated.
>
> ${charset:+-I} ${charset:+"$charset"}
I committed that change. There was another one, but it has a long
option, so removing the space wouldn't work for it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Ken wrote: KH> I guess this illustrates one problem with open-source projects; who makes KH> the decisions when people disagree? It's not that people who want KH> an Nmh- prefix are being unreasonable; I mean, I understand all of their KH> arguments; I just think my arguments are more compelling. Do the arguments boil down to traceability vs. keystrokes? The status quo supports both: Nmh-Attach: is used by the code, and if someone wants to use Attach:, they can. I think that Attach: is not the best we can do as net citizens, and that we shouldn't continue down that path with Forward:. Paul wrote: PF> in defense of not using a prefix: these are all user visible headers, PF> intended to be viewed and manipulated daily. i'm certainly happier PF> typing "bcc" and "fcc" than "nmh-bcc" and "nmh-fcc", Let me clarify: I'm not proposing that we go back and retrofit old headers. As Lyndon wrote: LN> This means, moving forward, we only generate nmh-* headers, while LN> continuing to accept the old ones. PF> and i prefer "attach" and "forward" to "nmh-attach" and "nmh-forward". To save keystrokes? That shouldn't be a consideration in scripts. And interactively, "a path" (at the What Now? prompt) is less keystrokes that "Attach: path". PF> as i understand it, the only worry with not using an Nmh- prefix is PF> with leaking headers. since none of these are supposed to ever get PF> out, conscientious scrubbing should get rid of them. (lyndon claimed PF> they'd get out, but didn't offer an example of how, so i'm still PF> unclear on that.) I put one in this message. (And also an Nmh-Attach: header, which will get scrubbed out, see below.) KH> Personally, even if those headers DID leak out, I don't think it would KH> be the end of the world, or even a big deal at all. Yes, but why not try to do better: if one does leak out, allow anyone to track it down. Ralph wrote: RC> Pass through, nmh ignores or doesn't expect, headers should be indicated RC> in some manner, e.g. colon prefix. Then `Bc: norm' and `Attahc: post(1) scrubs pseudoheaders that begin with "Nmh-". It also advises the user for each that has a non-empty value. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to forw(1)
Paul F wrote: > not if i'm already in my editor, it's not. and if i wait until leaving > the editor, i'll likely forget the attachment. so i sometimes use an > editor macro to create the Attach: header, and sometimes i type it by > hand. Fair enough. Though the editor macro could just as easily include the Nmh- prefix. > i could easily imagine doing that with Forward: as well. And an editor macro could just as easily use a #forw directive. > > PF> as i understand it, the only worry with not using an Nmh- prefix is > > PF> with leaking headers. since none of these are supposed to ever get > > PF> out, conscientious scrubbing should get rid of them. (lyndon claimed > > PF> they'd get out, but didn't offer an example of how, so i'm still > > PF> unclear on that.) > > > > I put one in this message. (And also an Nmh-Attach: header, which will > > get scrubbed out, see below.) > > great! so there's no problem. ;-) :-) In case my point was missed: the Attach: header was not scrubbed out. > i'd think adding an "X-Mailer: nmh-1.6" header would help even more. > (i confess i'm a little surprised that we don't already emit such a > header. i see that exmh does.) "X-" headers are deprecated by RFC 6648. We could add, say, a Mailer header. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
