>Comments? Votes?
Seems reasonable to me.
--Ken
>While I use +out, I think +outbox is more MH-like than +sent-mail and
>would vote for +outbox for the default and may well edit my own
>components file accordingly now that I'm thinking of it.
"Me too" (except that I already use +outbox :-) I don't really care what
the name is, as long as it's i
>echo 'r /nonexist-file\nq' | ex > /dev/null 2>&1
>
>This works with vim 6.0 and both bash and the Solaris release of 'sh'.
>Should 'configure.in' be changed this way to make it work?
When I last tried something like that (in something else), I discovered that
"\n" wasn't portable. Perhaps the be
>Hi. Seems like we've had a 1.1 release candidate sitting for a long
>time. Can we make it a release yet? It would be nice to have something
>newer than 1.0.4 going into things like Linux distributions.
Hm, well ... how about everyone (including me) makes sure what's on the
1.1 branch compiles
>Are you still sheparding this project? I remembered to look at
Rather poorly, but yes (well, I just got back from a two week vacation in
Europe).
>http://savannah.nongnu.org/projects/nmh
>
>I noticed that there are outstanding bugs - I haven't had a chance to look
>at the reports. Do you need
>Just wondering...
Short answer: I suck.
Longer answer: Busy with work, other people have been commiting, just
made a bunch of changes to make nmh work with sasl v2 ... maybe soon,
actually.
--Ken
>Is there any reason that 1.1-RC1 hasn't been promoted to a real 1.1?
Mostly, because I'm a lame-ass.
"soon". I promise. There have been a few bugs (and patches) posted.
>Every time I get a new Redhat installation, I need to update inc 1.0.4
>because it doesn't properly handle POP passwords (w
>Now, I hate to make this even more complicated, but should it
>really be called install-nmh? The change from mh to nmh has
>left a lot of stuff like this that could confuse a new user
>because you sort of have to know the history to know what
>things are called.
I can't see a reason why we shoul
>> >It's always bugged me that MH/nmh starts to install a new user setup if
>I guess that I wasn't being brave enough to suggest changing the way that
>things worked. I'll give it a few days to settle out, and then make the
>above change if no major objections arise.
No objection from me.
--Ken
>> ps: I have absolutely no idea if there will ever be a new nmh release, or
>> if anyone really still cares (and is able) to make cvs commits, I know I
>> can't.
>
>So development of NMH is dead, then?
Well ... I've been unfortunately busy in my real life job. Buuuttt ...
Everyone who has asked
>I just started integrating some of my stuff. I noticed that the cvs does
>not come with a configure file. I tried to use the one from nmh-1.0.4 but
>it doesn't work because it doesn't know anything about SASL_INCLUDES.
>Anyone know how to get this stuff built? Thanks.
If you're building from
>It is the accessibility of command line tools that makes nmh so
>powerful. It is already in the 21st century, although a little buggy
>in spots.
Oh, I agree ... but I don't think NEW features that don't remove or diminish
the command-line tools functions are necessarily bad. E.g., embedding
Tc
>Chris Garrigues <[EMAIL PROTECTED]> wrote:
>
>>More recently, the strategy that applications have used to implement (b) is to
>>embed a language such as tcl instead.
>
>The day that happens to MH/nmh will be the day that I switch to
>using mutt.
Since the intersection of "people with cool ideas
>There is one other problem with getting nmh to work over IMAP. The
>IMAP daemon's themselves must understand the MH format. I believe UW
>has mh support as a "legacy", but I haven't spent enough time to get
>my own use of it working. Any feedback on IMAP daemons that work with
>the MH format.
>Ken> You mean via POP? It deletes each message right after it retrieves
>Ken> it,
>Ken> AFAIK. I think that problem is that according to the POP3 spec,
>Ken> unless you
>Ken> get a clean QUIT, you don't make any changes to the mailbox.
>
> Hmm. That's probably what I exp
>>> Well, I did:
>>> make distclean
>>> autoconf
>>> ./configure
>>> make
>
>Ken> Errr ... you didn't run autoheader, as far as I can tell.
>
> Hmm.. Last time, it got run by make when I edited configure.in.
>
> I run it manually and all is well.
Hm, I believe that'
> Something I need to put in is having inc delete messages after X many
>have been downloaded. That way I can survive a net outages or ^C easier.
You mean via POP? It deletes each message right after it retrieves it,
AFAIK. I think that problem is that according to the POP3 spec, unless you
ge
>I'm working on a project to sort of do spam detection on email. The target
>mail system is nmh because it's a whole lot more modular than other mail
>systems. The reason that I say "sort of" is that it's not really a spam
>detection system, it's a system to show you your mail in order from most
>There are tons of software that let you do this on the net, I don't believe
>it is so hard to do , however this would certainly require to create a new
>command in nmh and the addition of a few new options in the existing commands
Sigh. I can see I'm not going to convince you. While some softw
>I had hoped to see APOP in this list among other things
Well ... shoot. I was under the impression that APOP is on it's way out
to be replaced by the CRAM-MD5 mechanism that SASL uses. But I just
checked, and it seems like you can enable APOP already with --enable-apop.
So that's a non-issue,
>I was wondering if you could list the features and new features (or
>reintegrated ones)
>of the 1.1 RC please
In short:
- A bunch of new shit
- A bunch of bug fixes
But seriously ... that's a good question. I haven't had time to come up
with a set of release notes. The one new feature I know
>Shouldn't this be 1.5? Otherwise, you'll get folks confused. I seem to
>recall that the last official "nmh" release was 1.4
Last release was 1.0.4, not 1.4. So I think 1.1 is right.
--Ken
> Well, I did:
> make distclean
> autoconf
> ./configure
> make
Errr ... you didn't run autoheader, as far as I can tell.
--Ken
>> - I'm not sure what the impact of public folders would be. I have
>> never used them, any ideas?
>
>Thanks for thinking of this obscure but useful nmh feature. As a sort
>of side question: do nmh hackers want/need a list of "obscure nmh
>features" to keep in mind as they hack the code? (I
>This is a good point. I wonder if Tobias' feature belongs in a future
>release of nmh, where we'd have time to discuss things like the
>fascinating question Earl brought up: what about IMAP? I had a few
>major questions and concerns in my own long reply. There's a lot that
>nmh needs to do
> This file is now marked as deleted on the head.
>
>I now get:
>
>creating config.h
>cat: ./config.h.in: No such file or directory
>
> Is it supposed to be created somehow?
By running autoheader (same as configure; you create that by running autoconf)
--Ken
Everyone,
I've created a nmh 1.1 release canidate. You can get it from:
http://savannah.gnu.org/download/nmh/nmh-1.1-RC1.tar.gz
This is also available off of the regular "Download Area" link off of the
nmh home page on savannah, at http://savannah.gnu.org/projects/nmh/
I know there are still
Okay, here's what's been going on:
- I've set up the cvs email stuff, and it works. You can access it off
of the "Mailing Lists" link at http://savanannh.gnu.org/projects/nmh
- I've tagged the CVS repository with a release tag, RELEASE_1_1. So
Mike, please go ahead and commit your changes
> Do we have a notion if we are using autoconf2.13, or autoconf2.5?
Just FYI, we're (going to be) using autoconf 2.52 (unless something newer
comes out, or has come out already).
--Ken
>[EMAIL PROTECTED] said:
>> start doing release canidates next week. Only bug fixes for 1.1,
>
>I vote for the linux-kernel strategy of using odd releases for unstable
>and even releases for stable versions.
I hope I don't come across wrong when I say that my preferred versioning
scheme is bot
>I just noticed that the CVS site has the excellent additions in
>popsbr.c for SASL authentication.
Don't forget mts/smtp/smtp.c as well :-) (Sigh, I need to get encryption
done for it ... so much code ...)
--Ken
Hey guys a word.
Yes, I've been tied up with Real Work(tm), but here's what's happening in
a very short order:
- I've created the mailing list [EMAIL PROTECTED],
and it should be in place in less than two hours from now (so the
email from Savannah tells me). I'm finishing up the stuff
>Might as well give that to you in this post rather than sending you an
>additional email, Ken. My account name is "Dan_Harkless".
You should be able to have write access now. Just FYI, the current
list of developers is now:
Ken Hornstein
Scott Lipcon
Michael Richardson
Dan
Okay, this has taken _way_ longer than I had expected, but I have some
good news.
The nmh repository is now hosted at savannah. You can got to the (admittedly)
plain web page for it at:
http://savannah.gnu.org/projects/nmh/
You can also check out the CVS tree by following the directions at:
h
>> Their concern was that they couldn't determine to their satisfaction that
>> nmh was free software. I am trying to work with them on the issue, but
>> I haven't heard back from them in a little while. However, if you (or
>> anyone) wants to talk with them directly, please do. You could find
>I expect FSF to be very particular about copyright for projects they
>would make part of the GNU project, but for non-GNU software, I'd
>figure they would be a little lax. If the license is compatible with
>what FSF would accept for a license, why be so anal about copyright
>notices?
Their conc
>> I have no objection to you or anyone implementing this functionality
>> (and I don't believe I ever said so).
>
>No, you only implied it.
if you say so. I don't recall ever meaning to imply it, but
whatever.
>> I am just explaining why I don't
>> think it's that important in the larger sc
>Yes, without a timezone offset. I have a bunch of these from my company's
>Japanese customer. Also found one in a recent (March 2002) post on the
>Bugtraq mailing list (I can't point you to the online archived copy because
>the archive parses the dates and re-states them relative to one's own
>
>> The problem is that because of the lack of a clear copyright, we may not
>> be able to host nmh there. I was waiting to hear back from Loic, but I just
>> pinged him again. We may be stuck with SourceForge.
>
>Why not just do things like the CVS project does? You can even point
>Loic to it a
>> If you think that it's _that_ important to have correct date handling for
>> non-standard timezones that don't even seem to be used anymore ...
>
>They are still used. I still get mail from Japanese colleagues with the JST
>timezone. I'm sure I could find current instances of the other
>no-l
>As for the service, I am currently satisfied. The bug tracking
>service can be quite useful and something to consider using for
>the nmh project.
The problem is that because of the lack of a clear copyright, we may not
be able to host nmh there. I was waiting to hear back from Loic, but I just
>Shantonu Sen <[EMAIL PROTECTED]> writes:
>> On Fri, 12 Apr 2002, Ken Hornstein wrote:
>> > >If I remember correctly, wasn't there still some problems remaining with
>> > >the the code in CVS? I thought I remember some problems with date
>> &
Just wanted to give everyone a quick status update.
I've been working with the savannah folks on the nmh collection; however,
one sticking point is that the copyright pedigree of nmh is not clear.
Currently, the copyright of nmh is assigned to "The Authors of nmh" and
that's a little fuzzy (also,
>> I've already got it (thanks to Doug Morris for putting it up today!)
>
>Now what?
ell, _since_ you asked ... I've already submitted it for a project n
savannah.gnu.org. By that, I mean that I've created a developer's
account for myself and gone through the registration process to host a
new p
>If development of nmh is languishing, it it because nobody is doing
>much of the work.
See the previous emails; it's not that nobody is _doing_ the work, it's
that it's NOT POSSIBLE currently for anyone to do the work.
--Ken
>> I tried. The basic problem was simple: Doug and I couldn't get
>> me working repository access. There was simply some
>> strangeness between our versions of OpenSSH that made it not
>> work, no matter how much we tried.
>
>What version were you running? I see that mononoke.mhost.com is
>runn
>Back around December people got all excited talking about a new
>release, rolling in patches that are floating around, and taking
>care of issues in the TODO file, but I have not seen >any<
>progress on that front. Until people start to do some real work,
>moving the repository so that it can ju
>If I remember correctly, wasn't there still some problems remaining with
>the the code in CVS? I thought I remember some problems with date
>processing.
IMHO, the only problem was with Dan's perception of the date processing.
I thought the changes were fine.
>If so, I would suggest rolling bac
>Who has usually rolled releases in the past? Was that Dan? I've heard
>that there was a lot of unreleased changes in the CVS. But, I'm sure we
>can work through this and get another release out there.
Yes, that was Dan, but he seems to be gone now.
I think I've used up my energy trying to ge
>A lot, but there's a refusal to kick the ball into the goal. There have been
>many significant bug fixes over the last couple of years, but the maintainers
>don't seem willing to issue a new release to the outside world
>(UNFORTUNATELY!).
Well, it seems like the last maintainer vanished, and
>nmh-1.0.4 doesn't support content-disposition header.
>so, mhstore command cannot respect filename="...".
>
>looking at cvsweb, I found supporting content-disposition is
>one of todo items for mh* commands in nmh/doc/TODO.
>
>any progress on nmh-1.0.4+dev?
No. I can't access the CVS server, so
>I'd still like to see these patches integrated into the main tree.
>But, once again, it seems like the recent short burst of enthusiasm
>for a new release has faded.
Well ... from where I'm sitting the problems are more technical than
any lack of enthusiasm. I don't want to go into details righ
>I'd say it still only warrants a 1.1. There are insufficient new
>features added or changed functionality. Leave 2.0 for a major
>rewrite.
Are you sure? Have you looked at the changes? There was a whole lot
of cleaning up that was done, and I don't think the security stuff was
insignificant ei
>> I _would_ like to do off-site backups of the CVS repository,
>> but assuming everything goes through, I'll work that off-line
>> with Doug.
>
>Definately... It would be a shame to loose all the history. One
>nice way to accomplish this would be to allow cvsup access, then
>anyone can have a f
Okay, my reading of the "rough consensus" of the messages I've seen is,
"Yes, do something, dammit". Here's what I think we should do:
- We should wait for Dan to say something. I just checked my exmh address
book, and the last message I ever saw from Dan was July 31st. So I'm
not even sur
>I'm not sure that I agree. When I asked people on this list about making
>changes to the CVS, I was told to post my changes and someone would look
>'em over and put them into the CVS. I couldn't find anybody to give me
>CVS write access since the maintainer was too busy. So let's not just toss
>If someone wants to take over driving the developement, I'm more than
>happy to keep hosting it. It might be nice to see what's happened to
>Dan, to keep from ruffling any feathers.
And I'm certainly waiting to hear from Dan ... right now I was just
in the "sounding everyone out" phase (but wha
>I would suggest Sourceforge not be used for a variety of reasons;
>First being the fact that it is a sinking ship. If people feel a
>Sourceforge-like site is really needed it would make more sense
>to me to use savannah.gnu.org which is now open to non-GNU
>projects.
>
>What is wrong with mhost.
>No, I agree there hasn't been much work. I think the major sticking
>issue for a 1.0.5 was that Dan was not happy with the new date parsing
>code. The new code was a bit faster and actually compiled. The old
>parser was some crufty code that was being munged with sed in order to
>compile. How
>In looking over back mail recently, I noticed that no one responded to
>Jon Steinhart's interesting patches regarding mime attachments. If
>memory serves, he prodded the list more than once; at least once with no
>response in early July. I would say that if you are interested and
>don't get a r
>How's SourceForge doing these days? VA Software isn't in the best shape
>now, I hear. I've been trying to find a big chunk of time to move the
>online MH book to SourceForge, but now I'm wondering if I might move it
>there and the server would go away. Comments, anyone?
"Make a backup".
-
It doesn't seem like nmh development has really progressed lately; I am
having a hard time finding commits later than March 17th of this year.
I'm wondering if Dan & the gang are still doing work on nmh; if not, then
would they be interested in having someone else run the show for a while?
I'd be
>> That's how it should treat those messages.
>> (Whether or not it takes them as GMT and converts it to local or simply
>> treats it as local is another discussion - I'm not sure which one is
>> right).
>
>I fail to see the distinction between the two discussions, but oh well
>(we're storing the
>Guess I'll have to look at the draft, but does "known" here mean it can only
>be one of EST/CST/MST/PST/GMT/UT (and daylight versions)?
Those are only the ones recognized by the draft (generally considered to
be the son of RFC 822).
>> SHOULD be considered equivalent to "-" unless there is
>> The remaining 3 were not accurately parsed by either 1.0.4
>> or 1.0.4-dev. 1.0.4 identifed 2 MET's as +0700, although the mail
>> headers disagree, and MSK (which stands for Moscow, I believe)
>> as -0700 which it definitely doesn't. 1.0.4-dev treated all three
>> as GMT, which, while not corr
>Finally got a chance to implement that for Solaris just now. Anyone that
>can extend the support to other OSes, please do so. I'll get support in
>there for AIX when I get a chance ('-Wl,-rpath', I believe). If I get time,
>I'll look at HP-UX and Linux, too.
FWIW, I always added this to whate
>As mentioned in a previous message, when you network-mount a folder that is
>owned by a different UID, it gets flagged as "read-only" regardless of whether
>you actually can write to it. I have a one-line patch which turns off this
>behavior (included below). I was thinking it would be good
>OSes *with* ruserpass() will probably build (but will be using the wrong
>ruserpass()) in the first case. Again, Shantonu, looks like your libmts.a
>has circular dependencies with libmh.a.
If you want to change how SASL works in terms of using ruserpass(), I'd
be willing to do that.
BTW ... af
>What provision in RFC 2060 treats flags as a scarce resource? I missed that
>in my reading.
It might just be my reading of the specification - there is a fair amount
of text regarding the limits w.r.t. permanent flags.
>I know of no IMAP server in common use which does not support arbitrary
>f
>Maybe he's talking about the ability of the UW imapd to access the MH
>folders you have on the server? I've used it before (in 'pine' to
>access a folder "{SYSTEM_NAME}#mh/lists/foo", for instance) to do just
>that. These days, I would just ssh in to the box and use nmh
>directly.
Was that a f
>> I don't think they're rich enough to
>> emulate everything that annotations give you.
>
>Because you can't add multiple ones per message, or because they're of a
>fixed length, or...?
The IMAP specification treats them as a fairly scarce resource.
I haven't done a survey, but IMAP servers ar
>If we really wanted to use IMAP, we wouldn't be using 'nmh'.
You're not always given a choice, you know. What if company-wide
message boards are only available via your IMAP server?
>I can see two possible roles for IMAP for the dedicated 'nmh' user:
>
> (2) When away from your main system,
>Well, anno might be implementable via the IMAP "tags" facility, no?
Are you thinking about "flags"? I don't think they're rich enough to
emulate everything that annotations give you. I'm not sure there's
any other tagging facility in IMAP.
--Ken
>See the APPEND IMAP4rev1 command:
>
>append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10.
Yeah, I had look at this, but it really doesn't work - you can't
_replace_ an old message, you can only add a new one to a folder. You
can set a system-defined flag called \Answer that signif
>IMO, it's rare because people these days don't think of being able to
>do it; they're used to GUI mail front-ends that don't allow (?) this
>kind of thing.
Use an IMAP client recently? "Shared" mailboxes are already part of
the IMAP specification. Most reasonable ones deal with them just
fine.
>Then there's the question of a "session": doesn't IMAP have the idea
>of "logging on" or "connecting" to an IMAP store for some period of
>time, and preserving the state of that session while the user is
>logged on?
"Not really". You can have multiple simultaneous connections, and
your clients
>Eww, adding sequences could get complex. Whilst I suppose it might be nice
>for some, do we really need it?
It's actually not that bad.
IMAP has the concept of "message flags", which can be set/read on
a per-message basis. There's a system one called "\Seen", which
obviously maps to the unseen
>1) Backward compatibility: a new, theoretical version of nmh that uses
> nmh should be smart enough to use old storage formats if they
> already exist. If we implement a new storage backend, it should
> be used only if the user starts using advanced features (like
> IMAP)
>The last time I remember IMAP support coming up was quite awhile ago, and
>the commentary (from Richard Coleman??) was that IMAP support probably
>wouldn't be forthcoming because IMAP would probably spell the eventual death
>of [n]mh. I don't recall a lot of posts disagreeing with that view, tho
Howdy all.
If y'all remember, I had done some patches to add SASL support for POP
and SMTP inside of nmh. I've been using these patches in production for
a couple of weeks, so I feel fairly good about them.
I'm interested in getting them in the distribution. I remember from last
time the way t
>Actually I meant what was wrong with your subscription to the list (in case
>it comes up again).
Um, good question. You'd have to talk to Doug about that (I got the
impression from him that it was failing for an unknown reason, so he
added me manually and would debug it later).
>As I recall, m
>> I've included a MIME pointer to the patch below. Comments welcome.
>> Doug has fixed my subscription to the list, so you can feel free to
>> reply to the list with comments.
>
>What was wrong, out of curiosity?
Let's see
Well, I didn't realize that whatnow parsed switches for send, so
I
Howdy all,
After putting my SASL patches into some more widespread use, I found
a few bugs with them. As a result, I've updated the patch. You can
get it at:
ftp://ftp.cmf.nrl.navy.mil/pub/kenh/nmh-sasl-patch-1.0.4-v2
I've included a MIME pointer to the patch below. Comments welcome.
Doug ha
83 matches
Mail list logo
