Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Mon, Apr 14, 2014 at 11:14 PM, Lyndon Nerenberg wrote: >> -1 on deprecating SASL support. I use it. > > Out of curiosity, which mechs? What's this have to do with anime? :) If you mean operating systems, my router/relay system is an old linux box (pre RHEL release) running on a 15+ year old box. My other systems are CentOS 5. I mount my mail directory across systems and have nmh configured to post any messages to delegated, which subsequently is configured to connect to gmail server (over TLS). I setup delegated some time ago since it seemed to be the easiest method at the time to get submission of email over a TLS-based connection. IIRC, at that time, I updated some of the SASL code so things like the what-now command 'whom' would work. I know I can get things better setup, but I get no pleasure with sysadmin tasks anymore, so I try to go with something that is the least amount of effort. I should not have to F with MTAs and other things in order to get an MUA to submit mail. Here is relevant entries in my .mh_profile (identifying information edited to protect the guilty): push: -unique -sasl -saslmech LOGIN -user USER -server local.example.com -port send: -verbose -sasl -saslmech LOGIN -user USER -server local.example.com -port whom: -check -sasl -saslmech LOGIN -user USER -server local.example.com -port I can configure delegatd to not require SASL login to access, but I wanted some simple access control so any one else I might let connect to my LAN cannot trivially submit email through my gmail account. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Apr 14, 2014, at 9:00 PM, Earl Hood wrote: > -1 on deprecating SASL support. I use it. Out of curiosity, which mechs? signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Mon, Apr 14, 2014 at 10:28 PM, Lyndon Nerenberg wrote: > I think in 1.7 we need to deprecate the POP support. And in 1.8 > deprecate the submission SASL support. -1 on deprecating SASL support. I use it. I use delegated on my LAN, where my local systems can submit mail to it using SASL, and it is configured to then submit messages to gmail server for transport. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
On Apr 14, 2014, at 8:14 PM, David Levine wrote: > I think that the nmh_get_credentials() call needs to move back > to sm_get_pass(). We might want to do that with inc and msgchk, > too. I think in 1.7 we need to deprecate the POP support. And in 1.8 deprecate the submission SASL support. POP has been handled by external programs for ages. As for submission, it's time to teach the MSAs to accept mail on named pipes. No need for SASL, or networks, or ... I thought I taught sendmail to listen for mail submission on UNIX:/var/mail/submission circa 1999? --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
Ken wrote: > It turns out even though I tested this, I wasn't actually using some of > the backend programs until now ... like post. D'oh! > > Anyway, I discovered that now post(8) is always asking me for a username > and password ... even when it doesn't need to (my sasl mechanism doesn't > require them). I didn't expect that: I thought that a username and password were always required here. > The change that caused this is b9763fdd7e96e7ac8bdb1, and > the key issue is that in the third argument for sm_get_credentials() is > now "0", instead of "1" (like it used to be). > > I went back and looked at the mailing list, and that discussion was here: > > http://lists.nongnu.org/archive/html/nmh-workers/2013-05/msg5.html If that argument is changed to "1", it breaks Valdis's use case. I think that the nmh_get_credentials() call needs to move back to sm_get_pass(). We might want to do that with inc and msgchk, too. > But I guess I don't understand why post now behaves differently than inc > and msgchk, which are also sasl-aware programs. Can someone fill me in > here? My read of the code was that post did behave differently than inc and msgchk. See commit 52a236230220, the diffs of the inc.c and msgchk.c are straightforward. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Buildbots switched to 1.6-release branch.
The buildbot cluster is now building against the 1.6-release branch. I have also increased the git repo polling frequency to every 10 minutes. Presumably the builds will now trigger off commits (only) to the release branch, but I can verify that until I see a few commits to the branch and the head go through. David, Ken, and I can use The Force if need be. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
On Apr 14, 2014, at 3:33 PM, Ralph Corderoy wrote: > C source code? > > Cheers, Ralph. i think this mailing list thread is going into my fortunes file ;-) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] First release candidate of nmh 1.6 now available
Greetings all, I am pleased to announce that after close to two years, we are finally starting the release cycle for nmh 1.6 and the first release candidate is now available! You can download it here: http://download.savannah.gnu.org/releases/nmh/nmh-1.6-RC1.tar.gz (I've also included a MIME external-body pointer to it below, which newer versions of nmh should be able to use). This release has a large number of new features, too numerous to list here. The NEWS file included in the distribution has a reasonably complete list of new features, bugfixes, and other changes. If you encounter any problems with this distribution, please don't hesitate to let us know at nmh-workers@nongnu.org. Ken Hornstein on behalf of the nmh development team ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
ralph wrote: > part text/plain 307 > Hi Paul, > > > for instance, if the leading character were '}', i don't think i would > > ever have a conflict with "real" text. > > C source code? doh! i originally thought of ')', and ']', and extrapolated incorrectly to "any righthand delimiter". okay, okay. before you bring up "lisp source code", i'll give up. tokens in the text is a bad idea. i'm on board now... paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.8 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
Hi Paul, > for instance, if the leading character were '}', i don't think i would > ever have a conflict with "real" text. C source code? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhshow.man: -textonly / -inlineonly
i wrote: > one can make a pretty good assumption about what they mean, based on > the descriptions of how they interact with other options, but neither > -textonly nor -inlineonly are actually described in the mhshow man > page. sorry. i lied. they're defined in their "no" form in the third paragraph. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 63.3 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] mhshow.man: -textonly / -inlineonly
one can make a pretty good assumption about what they mean, based on the descriptions of how they interact with other options, but neither -textonly nor -inlineonly are actually described in the mhshow man page. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 64.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
ken wrote: > part text/plain1575 > >for me? it's new-fangled, and i don't trust it. ;-) > > Geez Paul, we only had like a huge discussion about this back in > December :-/ geez ken. that's like, just a blip, in mh-time. :-) > It does occur to me that if your only beef is automimeproc is no longer > supported, then there is an easy workaround: create your own sendproc > that always runs mhbuild, and you should be where you were before. good point. yet another solution. thanks. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 67.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
>for me? it's new-fangled, and i don't trust it. ;-) Geez Paul, we only had like a huge discussion about this back in December :-/ >seriously, it's just not how i've been doing attachments for the last >15 years. my current mechanism [1] trivially lets me attach either >files or MH messages (e.g. "cur", or "+mh last") and i can insert >them anywhere i want in my message. Attach is limited (as far as i >know) to pathnames, and its attachments are always placed at the end >of the message. That's true (although if you have a new-enough "file" command, it will figure out that a particular file is, for example, a message/rfc822). As we talked about in December, this is a simple mode of attaching files; designed for what the average user is going to be doing, which is creating MIME messages which looks like the ones created by nearly every other MUA out there. Now you're still free to write your own mhbuild directives and do what you did before. >up 'til now, i've used automimeproc=1, and i have a hook in my mh.edit >script that warns me about leading '#' chars in my draft. with 1.6 >i'll need to change my ways. that may mean using Attach, but it will >only be part of my solution. It does occur to me that if your only beef is automimeproc is no longer supported, then there is an easy workaround: create your own sendproc that always runs mhbuild, and you should be where you were before. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] post now asking for a password, even when it doesn't have to
It turns out even though I tested this, I wasn't actually using some of the backend programs until now ... like post. D'oh! Anyway, I discovered that now post(8) is always asking me for a username and password ... even when it doesn't need to (my sasl mechanism doesn't require them). The change that caused this is b9763fdd7e96e7ac8bdb1, and the key issue is that in the third argument for sm_get_credentials() is now "0", instead of "1" (like it used to be). I went back and looked at the mailing list, and that discussion was here: http://lists.nongnu.org/archive/html/nmh-workers/2013-05/msg5.html But I guess I don't understand why post now behaves differently than inc and msgchk, which are also sasl-aware programs. Can someone fill me in here? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
jon wrote: > part text/plain1607 > Paul Fox writes: > > ken wrote: > > > part text/plain1020 > > > >i don't recall us ever discussing the possibility of making the '#' > > > >character that introduces mhbuild directives configurable by the user. > > > > > > > >for instance, if the leading character were '}', i don't think i would > > > >ever have a conflict with "real" text. > > > > > > > >interpretation of those directives is strictly within mhbuild, > > > >correct? no leakage into other mh commands? > > > > > > There used to be some leakage; for example, the old attach > > implementation > > > would parse the Nmh-Attachment headers and then create mhbuild > > directives. > > > I am not sure there is any leakage now. But I am not in love with the > > idea > > > of changing the leading character, because that opens the box for "how > > should > > > we do MIME composition, anyway?" Which is not going to be easy. As a > > > > i guess i'm not sure how letting a user change the prefix character on > > the existing mechanism would make that worse. > > > > (and i'm not talking about 1.6.) > > > > paul > > We wouldn't be talking about this if we had a good solution! > > My opinion is that having special characters in the body is bad, like > crossing > the beams. It was a good hack at the time but should be put out of our > misery. > I think that all MIME composition should be done via headers. Y'all have > done > a bunch of work on my original attachment stuff. In what way is it not good > enough yet? for me? it's new-fangled, and i don't trust it. ;-) seriously, it's just not how i've been doing attachments for the last 15 years. my current mechanism [1] trivially lets me attach either files or MH messages (e.g. "cur", or "+mh last") and i can insert them anywhere i want in my message. Attach is limited (as far as i know) to pathnames, and its attachments are always placed at the end of the message. up 'til now, i've used automimeproc=1, and i have a hook in my mh.edit script that warns me about leading '#' chars in my draft. with 1.6 i'll need to change my ways. that may mean using Attach, but it will only be part of my solution. i was just floating the idea of making the '#' configurable -- that would only be a partial solution as well. paul [1] i have an 'attach' command that takes paths and/or mh message specifications as args, and produces mhbuild directives on stdout. so (in vi) using "!!attach cur" or "!!attach /tmp/cartoon.pdf" populates the correct directives. lately i've been trying to remember to mostly use it at the bottom of the edit buffer (so attachments come last, as a courtesy to the recipient, but that's not always what i want. -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 72.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
>My opinion is that having special characters in the body is bad, like crossing >the beams. It was a good hack at the time but should be put out of our misery. >I think that all MIME composition should be done via headers. Y'all have done >a bunch of work on my original attachment stuff. In what way is it not good >enough yet? It's fine for 90% of what people normally want to do. It's just the rest of the stuff ... like creating multiparts like multipart/alternative, or external-body references, or if you want to create HTML and specify the Content-ID of attachments exactly. Not many people want to do that, it's true. I'm not sure how we do that in headers easily. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
> > There used to be some leakage; for example, the old attach > > implementation would parse the Nmh-Attachment headers and then create > > mhbuild directives. I am not sure there is any leakage now. But > > I am not in love with the idea of changing the leading character, > > because that opens the box for "how should we do MIME composition, > > anyway?" Which is not going to be easy. As a > >i guess i'm not sure how letting a user change the prefix character on >the existing mechanism would make that worse. I understand your point ... it's just that it seems like a Band-Aid™ on a much larger problem, and I'd rather solve the much larger problem. But then again, I wrote replyfilter which is also a Band-Aid™ on a much larger problem. I don't have a good answer, unfortunately; the idea of changing that leaves me unsettled, but I recognize that's not really a rational argument. What do others think? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
Paul Fox writes: > ken wrote: > > part text/plain1020 > > >i don't recall us ever discussing the possibility of making the '#' > > >character that introduces mhbuild directives configurable by the user. > > > > > >for instance, if the leading character were '}', i don't think i would > > >ever have a conflict with "real" text. > > > > > >interpretation of those directives is strictly within mhbuild, > > >correct? no leakage into other mh commands? > > > > There used to be some leakage; for example, the old attach implementation > > would parse the Nmh-Attachment headers and then create mhbuild directives. > > I am not sure there is any leakage now. But I am not in love with the idea > > of changing the leading character, because that opens the box for "how > should > > we do MIME composition, anyway?" Which is not going to be easy. As a > > i guess i'm not sure how letting a user change the prefix character on > the existing mechanism would make that worse. > > (and i'm not talking about 1.6.) > > paul We wouldn't be talking about this if we had a good solution! My opinion is that having special characters in the body is bad, like crossing the beams. It was a good hack at the time but should be put out of our misery. I think that all MIME composition should be done via headers. Y'all have done a bunch of work on my original attachment stuff. In what way is it not good enough yet? Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
ken wrote: > part text/plain1020 > >i don't recall us ever discussing the possibility of making the '#' > >character that introduces mhbuild directives configurable by the user. > > > >for instance, if the leading character were '}', i don't think i would > >ever have a conflict with "real" text. > > > >interpretation of those directives is strictly within mhbuild, > >correct? no leakage into other mh commands? > > There used to be some leakage; for example, the old attach implementation > would parse the Nmh-Attachment headers and then create mhbuild directives. > I am not sure there is any leakage now. But I am not in love with the idea > of changing the leading character, because that opens the box for "how should > we do MIME composition, anyway?" Which is not going to be easy. As a i guess i'm not sure how letting a user change the prefix character on the existing mechanism would make that worse. (and i'm not talking about 1.6.) paul > comparison, MH-E has it's own syntax which seems to be XML-based. I have > no idea if it's better or worse than mhbuild. > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 71.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Whoops, my bad
Hey all, If you happened to pull from the git repo within the past few minutes, you might have gotten a "1.6" tag. If you did, that was my mistake; I meant that to be 1.6-RC1. I deleted it from the remote repo, but if you happened to get it you should delete it from your remote repo by doing: git tag -d 1.6 If you want to test to see if you got it, you can try doing: git describe 1.6 It SHOULD return something like "fatal: not a valid object name 1.6". If it instead returns "1.6", you should delete it using the command above. Again, my apologies! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
>i don't recall us ever discussing the possibility of making the '#' >character that introduces mhbuild directives configurable by the user. > >for instance, if the leading character were '}', i don't think i would >ever have a conflict with "real" text. > >interpretation of those directives is strictly within mhbuild, >correct? no leakage into other mh commands? There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for "how should we do MIME composition, anyway?" Which is not going to be easy. As a comparison, MH-E has it's own syntax which seems to be XML-based. I have no idea if it's better or worse than mhbuild. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Release branch created: 1.6-release
Greetings all, I've just pushed the new release branch to the git repo. It's name is 1.6-release. If you're doing release work, it should be done on this branch. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between "mime" command and attach
resurrecting an old thread, but a continuing issue... ken wrote: > - I use to run with automimeproc set. But that's lousy; if you include C > code in your text, it fails. Totally non-obvious and I always forget it. > It got to be such a problem that I turned it off. i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with "real" text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 72.3 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
