Robert Elz writes: | Anyone have a problem if I remove this test? Yes. It is that test that makes folder run in manageable time, without it, every message in every folder has to be stat'd to see if it happens to be a directory - with it, folders with no sub-folders (which almost all folders with many messages count as) can simply be skipped. kre How about if I change the test so that it is only ignored for the top level directory? Jon
Robert Elz wrote: | How about if I change the test so that it is only ignored for the top | level directory? That would do much less harm, but is unlikely to be so easy (that function gets called for any level in the hierarchy, if I recall correctly). An alternative would be a try really hard option (inverse of folder -fast) that made it ignore the test. But for your purposes, wouldn't just making a dummy sub-directory in your new (symlinks only) Mail directory, until it gets a real folder sub-dir of its own do just as well? kre OK, I give up. I guess that this is a special case. But I found it real annoying to have to resort to the source code in order to find out why the command mysteriously didn't work. I think a warning on the manual page would suffice. Jon
I have it working on Solaris (albeit an old 2.6) and Linux RH9. 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 on all of the major platforms that they have access to, and if the answer is yes, then we call the head of the 1.1 branch 1.1 final ? --Ken
Where we're had to move away from nmh towards gnus is in MIME composition (e.g. for the ability to specify inline/attachment). You might want to look at the attachment stuff that I checked in a while back. I implemented it in such a way that it could easily be incorporated into MH-E. The short summary is that you can specify the names of attachments using a header field, and send handles invoking mhbuild as required to package everything up before sending. Anno has been extended to assist in managing the header fields. It might be nice to be able to output a character in a scan column if attachments are present. MH-E could even replace that character with a paperclip glyph or something to pretty it up. Seems to me that my notion of scanning attachments is getting the most attention here, even though it's not the most important part to me. My main interest is in being able to read attachments in a more consistent way. Maybe an example would help... Right now, a session looks like this: % inc scan output % show (oh, this looks like a multipart message) % mhlist % mhshow -part 1 % mhshow -part 1.1 % mhshow -part 2 (...) % next ... What I'd like to be able to do is: % inc scan output % show % next (show first part of current message) % next (show next part of current message) % next (...) % next (show first part of next message) Jon
Hmm. I'm afraid I disagree about this redefinition of next. Currently, I don't need to do individual mhshows if I just want to sequence through all the parts: just show, and keep hitting Return, or Ctrl-C to skip a part. Cheers, Dave Disagreement is good. I do it too! If I get a message with 20 photos attached, I hate having to hit Ctrl-C 20 times just to get to the next message. And I also have problems with multiple text parts since the way things get exec'd I haven't found a reasonable way to pipe the whole pile through a pager; short body parts that come before long ones scroll off the top of the screen. I guess that I just feel that it's bad user interface to have the behavior depend on the number and type of body parts. Jon
I've changed the Subject and included [EMAIL PROTECTED] since we've spent the last year improving MIME handling in Gnus since raw MH wouldn't work for us. We should be able to provide some suggestions which would allow us to use more MH and less Gnus. Peter? Satyaki? Yeah, should have changed the subject myself. What I have in mind is twofold. First, I'd like to be able to optionally scan with message parts listed. Second, I'd like to be able to have an option to show/next/prev that says show the cur/next/prev message part. If the next/prev message part doesn't exist, then it should show the first/last part of the next/prev message. In other words, I just want to be able to read using a consistent interface, and the existing next/prev would let me skip attachments if I didn't want to see them. Also, I'd like to be able to show message.part file rather than have to do the clunky mhstore thing. Jon
Neil W Rickert [EMAIL PROTECTED] writes: But, install-mh is not likely to be in the user's path; it's in the lib directory. Should I change the installation to move this to the bin directory or to make a link from the bin to the lib directory? Make a sym-link, or put in a shell script. Why? It's an obvious end-user program, especially now. It belongs in bindir. I doubt much if anything uses the old path (mh-e might, but note that it is still alive and kicking, arguably more so than nmh itself), so i say don't even bother with a backwards compatability symlink, but if you must have one the link goes in libexecdir. -- Eric Gillespie * [EMAIL PROTECTED] Well, I already checked in a change to make it a link. Feel free to change it. By the way, should the manual page be changed from section 8 to section 1? Jon
Jon Steinhart [EMAIL PROTECTED] writes: 3. If the $HOME environment variable is set, mypath is copied from the getenv return. Why? It's never changed. 4. If the $HOME environment variable is not set, mypath is copied from the pw_dir member of the returned passwd structure. Now, I understand that this is a static structure, but getpwuid is never called again so I don't see why the copy is needed. 4. If the $HOME environment variable is not set, the pw_dir member of the passwd structure returned by getpwuid() is checked for a NULL pointer. This can never happen in a non-error return, which is already checked. So why the superfluous check? These checks are not superflous, they are for maintainability. Two years from now someone will add a second getenv(3) call and waste their (probably volunteer) time trying to figure out how they busted the home dir variable. That is why, unless you are writing super-tight-must-be-the-best-performing-code-ever applications (which mh is not), it is necessary always to make a copy of the static buffer pointed to by the return values of such functions. -- Eric Gillespie * [EMAIL PROTECTED] This is one of those places where we'll have to respectfully disagree. I'm obviously in the minority given the quality of software that I see these days, but I think that programming is still something that should be done by professionals. I don't want someone hacking on code that doesn't take the time to figure out what's going on first. Protecting against the really silly mistakes allows such people to make really complex ones. As I said in my earlier email, I'm not going to write slow and sloppy code just because computers are fast. Matter of fact, I keep on trying to get up the courage to tackle m_getfld(). Oh, some details. 1. A second getenv() call would not break the code. The copy was really unnecessary. 2. It's hard for me to imagine a situation where getpwuid() would #1 get called a second time and #2 for a different uid, which is the only that a problem would occur. 3. If there's a NULL passwd-pw_dir then libc is broken and should be fixed. Better that this gets pointed out and fixed rather than covered up so that it stays unnoticed and broken. Oh, and I've wasted some of my volunteer time trying to figure out what the code did before changing it. I'd waste less if there was less code. Best way to accomplish this is to get rid of the code that doesn't do anything. Jon
Well, here's a minor detail that could cause problems. I have a version of nmh here that has sbr/context_read modified to give a run install-mh message if mh isn't installed rather than doing it for the user as per yesterday's discussion. But, install-mh is not likely to be in the user's path; it's in the lib directory. Should I change the installation to move this to the bin directory or to make a link from the bin to the lib directory? Jon
Howdy. I've been working on a companion mail reading system for nmh. In short, this is a system that builds a database from mail in folders, allowing it to be searched quickly. It includes a ranking mechanism, and allows messages to be searched by rank. Sort of like the current fad of Bayesian spam filters, but more general. I have already checked in external hook modifications to nmh that allow it to invoke external programs when mail is added, removed, or refiled. But, there's one more sticky point. There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. I need to do this because my program needs to invoke some nmh commands via pipes, like folder -fast to get the current folder, or mhpath + to get the mail folder. If there is no mail folder, nmh commands prompt the user for installation as opposed to failing with an error code. This is nice for a user but a real nuisance for a program. I currently have an is_nmh_installed() function as part of my program. I really don't like doing it this way because things like how the MH environment variable works and where to find the mail folder in the profile seem to me like nmh internals that belong in nmh, not in some other program. So, I'd like to add something to nmh to allow for installation testing. I think that the best way to do this would be to add a report-only option to install-mh. Any objections if I do this? Jon
But, there's one more sticky point. There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. Is test -d `mhparam Path` sufficient for your needs? -- Eric Gillespie * [EMAIL PROTECTED] No. If mh isn't installed, mhparam will prompt for installation just like every other mh program. Jon
I've started working on the changes for the mh installation thing discussed earlier. My plan is to modify context_read() to print a message instead of invoking install-mh, and to add a -check option to install-mh that allows it to silently check for installation, returning the status via the exit code. There's a bunch of strange stuff in context_read() that seems unnecessary. I'd like to get rid of it, but want to check with y'all in case there's some undocumented historic necessity of which I'm unaware. I know that these are picky things, but I'm just not in the write-sloppy-and-slow-software-camp even though computers are pretty darned fast these days. 1. The program starts by checking to see whether or not defpath has been set, and bails if it has. Apparently a test in case it's called more than once. I've checked all of the other programs, and it never is. defpath is unnecessarily checked in a number of other places: sbr/context_del.c sbr/context_find.c sbr/context_replace.c sbr/seq_read.c sbr/seq_save.c uip/flist.c uip/folder.c uip/rmf.c I'd prefer to see asserts used to check for dumb programming errors. 2. Next there's a test to see if mypath is set, and setting it is skipped if it's already set. Again, I don't see any way that this could occur. 3. If the $HOME environment variable is set, mypath is copied from the getenv return. Why? It's never changed. 4. If the $HOME environment variable is not set, mypath is copied from the pw_dir member of the returned passwd structure. Now, I understand that this is a static structure, but getpwuid is never called again so I don't see why the copy is needed. 4. If the $HOME environment variable is not set, the pw_dir member of the passwd structure returned by getpwuid() is checked for a NULL pointer. This can never happen in a non-error return, which is already checked. So why the superfluous check? 5. There's code that removes a trailing / from mypath if mypath is more than one character long. Seems completely unnecessary; the definition of path names means that // is interpreted as /. And if that wasn't the case, this code wouldn't catch multiple trailing slashes anyway. 6. If an MH environment variable is set and doesn't begin with a / the MH environment variable is changed to the profile path. Why bother? It's never used by anything. Exec'd programs can get figure this out if they need to - any exec'd nmh program does that anyway. Jon
sbr/context_read does a complicated check for installation involving first the MH environment variable and second the default profile. I was surprised to discover that uip/install-mh does not perform identical tests. It just looks for the default profile. This seems wrong to me. Should I fix it? Jon
On July 8, 2002 at 11:05, Jon Steinhart wrote: And I agree, downloading the entire message is the way to go. Most spam is very small compared to even slow V90 speeds which is what I'm stuck with out in the country here, so it's no big deal. Well, I would have to disagree about spam being small and no big deal over V90 modem. Spam messages have been increasing in size since many are HTML messages and some with attachments or images. Also, if you are flooded with alot of messages, they add up. Of course, the annoyance factor is relative for any given person, but when I was using dialup, I definitely considered writing my own POP filtering tool with interactive capabilities to avoid downloading crap (and sometimes the messages may not be spam but from friends and/or relatives sending huge-assed attachments that I did not care about). However, once I got cable modem, my need for such a tool dropped considerably. A side note: I considering spam filtering, and other filtering needs, mainly delivery issue. Hence, I think it is best solved done before nmh even sees the mail (the boundary is somewhat lose when dealing with automatic filing of messages to different folders). This keeps the filtering job independent of the MUA and prevent developers re-implementing the wheel for every MUA. I have a set of changes that I'll submit at an appropriate time. These changes allow .mh_profile entries that name programs that are executed whenever a piece of mail is incorporated, removed, or refiled. A nice feature. --ewh This has the potential to go way off topic for this mailing list, but... I agree that a fair number of bytes are consumed by spam. It isn't a huge problem for me because even though V90 is the best that I can do out here in the sticks, it's a full time connection so I'm not waiting on mail delivery. I find it hard to see filtering as a delivery issue, but that's probably because I read my mail on my machine which uses sendmail to deliver mail; I'm not dialing in somewhere to pick up mail. If I need to read mail on the road, I ssh into my machine and read it there. The big issue on filtering is that everybody wants to filter different things. Strange as it seems, some people even like to collect spam for study. One of the big difficult issues on filtering is that, while an occasional false positive can be tolerated, false negatives are completely unacceptable. A system that keeps all of your mail and only shows you interesting messages doesn't lose anything, which helps that problem. But it requires sucking down all messages. Another example, I remember Gosling telling me that especially since he's become embroiled in the Sun/MS suits that a mirror copy of all of his incoming and outgoing mail is kept for legal reasons. This wouldn't work if incoming mail was rejected based on headers. Jon
Hey folks, nothing is served by this increasingly heated bickering. There seems to be a general consensus on the following: o People would like to see work continue on nmh in a timely fashion, o People would like to get a new release together, o CVS is a good tool and people would like to be using it, o The current repository and maintainer are perceived as a roadblock, and o People have been patient for a long time. So how about we put the egos aside and get to work? It sound like moving the repository is a good way to get this going, or at least a way to move the burden to someone else. As an alternative, how about the current maintainer giving a firm date, such as June 10, by which time the repository issues will be resolved. If they're not resolved by then, it'll be time to move it. Jon
I too would like to see work continue on nmh. I'd like to see the stuff that I contributed to integrated in to a new release. It seems clear that Doug is no longer able to be the maintainer for this, so someone else should pick it up. If that means forking the CVS, so be it. Let's get something done! Jon
Well, since Chad just reposted my attachment code, let me tell you what's wrong with it. I'll update it if work is really going to happen on a new release. I use anno to add attachment headers. Anno works by prepending headers to a message. Unfortunately, this means that if you add several attachments to a message, they'll come out in reverse order. I am planning to change anno to append header fields instead. Can't see how this would break any existing applications. If anyone is worried about this, I can add a prepend/append option but that seems unnecessarily complex to me. Jon
Jon Notice that the boundary specified on the content-type Jon line is NextPart. This means that --NextPart lines Jon are boundary markers. But, in the remainder of the Jon document they're - --NextPart. It's not clear from the mangled copy attached just WHAT it looked like originally. The - -- was probably done by nmh in forwarding the message. OK, OK enough already. Regardless of whether or not the boundaries were mangled in the original or by some forwarding program, there were no parts in the multipart message which is probably what was causing the message. Jon
I have noticed that mail from one of the mailing lists that I subscribe to often gets mangled on inc, splitting a message into two. I can't tell what's going on for sure because by the time I see the mail, it's too late. My suspicion is that somehow one of the headers in the message body is triggering problems. There are headers in the body because the message is a collection of other messages. Oh, I don't recall seeing this running the stock nmh, just on the stuff from the CVS. Here's what I'm seeing: (Message inbox:3135) Return-Path: [EMAIL PROTECTED] Delivery-Date: Fri Aug 17 15:07:17 2001 Received: from fedney.cdc.nextlink.net (fedney.cdc.nextlink.net [22.214.171.124]) by darkstar.fourwinds.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f7HM7Abg011851 for [EMAIL PROTECTED]; Fri, 17 Aug 2001 15:07:11 -0700 (PDT) Message-Id: [EMAIL PROTECTED] Received: (qmail 26091 invoked by alias); 17 Aug 2001 21:50:12 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk X-No-Archive: yes list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] From: Digestifier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 17 Aug 01 17:50:01 EDT Subject: DAT-heads Digest #10 Content-Length: 15813 DAT-heads Digest #10, Volume #6 Fri, 17 Aug 01 17:50:01 EDT Contents: taping Los Lobos (Bill Shaw) ... From: Bob Ramstad [EMAIL PROTECTED] Subject: Brad taping (Breakroom Seattle 9/1 9/2 9/3) Date: Fri, 17 Aug 2001 10:06:49 -0700 (Message inbox:3136) Return-Path: speaking Delivery-Date: with the drummer for Bra Brad allows taping for private noncommercial use only i.e. you are ...
Here's another instance of the previously posted bug: (Message inbox:3107) Return-Path: [EMAIL PROTECTED] Delivery-Date: Wed Aug 15 20:07:07 2001 Received: from fedney.cdc.nextlink.net (fedney.cdc.nextlink.net [126.96.36.199]) by darkstar.fourwinds.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f7G36wbg008312 for [EMAIL PROTECTED]; Wed, 15 Aug 2001 20:07:01 -0700 (PDT) Message-Id: [EMAIL PROTECTED] Received: (qmail 10960 invoked by alias); 16 Aug 2001 02:50:12 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk X-No-Archive: yes list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] From: Digestifier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 15 Aug 01 22:50:01 EDT Subject: DAT-heads Digest #8 Content-Length: 20438 DAT-heads Digest #8, Volume #6 Wed, 15 Aug 01 22:50:01 EDT Contents: Re: Junior Brown (Dan Witt) ... From: Bas Ruesink [EMAIL PROTECTED] Subject: NEED: U2 radio-broadcast DAT taper for this weekend Date: Wed, 15 Aug 2001 16:22:50 +0200 (Message inbox:3108) BAD MSG: Definitive U2 Radio Documentary to Air in UK ...
| I have noticed that mail from one of the mailing lists that I subscribe | to often gets mangled on inc, splitting a message into two. Are you running Solaris? Solaris' mail.local uses Content-Length to delimit messages, and leaves From alone. That can confuse MH. There was an old patch for m_getfld.c for this (which should have been integrated after all these years.) Well, I am running Solaris. But I can't see why that would make a difference since I'm using sendmail and nmh, not any of the stock Solaris stuff. Also, since this is all in the body of the message I can't see why this would happen as it shouldn't be looking for headers anymore.
I posted some patches to improve the user interface for handling attachments with mail drafts several weeks ago and haven't heard a thing since. Was this stuff great? Terrible? Need some changes before merging it with the code base? Or is nobody there with the time to look at it? Jon
Thanks for all the responses. Here's a recap of what I think I heard... RFC822 [and possibly RFC2822 when I can find a copy since it's not on the ietf web site, where does one get a copy?] allows single NL characters in header field bodies, which are supposed to be treated as normal characters, distinct from the CR-NL pair that indicates the end of a line. The receiving transformation will probably preserve these, but the result on a *N[IU]X system is likely to be an illegal header since the NL will start another line which is not likely to be a valid header field. Hey, this could be a great spam hack; put a NL in, for example, the subject field, followed by a legal looking but completely bogus received field. RFC822 allows NUL character in header field bodies. This probably will break most *N[IU]X mail programs. Neither of these are problems at the moment because nobody is doing this stuff. But if, for example, Microsoft decided to being every mail header field name with a NUL it would be legal while breaking lots of things. Is this a correct recap? Jon Steinhart
Hi. I'm working on some mail filtering software that will work with nmh. I've noticed a few conflicts between the way messages are stored in folders and RFC822. I figure that y'all know something about this, so just wanted to check to make sure that this is really the case and that it isn't a problem or might be a problem in the future. 1. RFC822 says that header fields end with a CR-LF pair. That might be true on a Microsoft system but not on Linux of any of the other UNIX-like systems. Single CR or LF characters are allowed in header field-bodies. Does this ever occur in real life or might it happen some day? 2. RFC822 allows the NUL character in header field-bodies. Code written around the C string functions won't handle this of course. Does this ever occur in real life or might it happen some day? Now, I recognize that this stuff is sort of covered by the NETWORK-SPECIFIC TRANSFORMATIONS section of RFC822 but I have trouble believing that any *NIX mail system actually does it. Is this true? Thanks, Jon Steinhart
I have made a modification to whatnow to support an "attach" request, and an associated mhattach program. There are a few other minor changes to support an "attachproc" in the context. This all allows MIME attachments to drafts with a decent user interface. I'd like to get this into the nmh code base. I wrote Doug Morris about this a while ago, and he suggested checking out the code, making the changes, and mailing the patches to him. Did this, and haven't heard back from him despite pinging him a few times. So, I'm assuming that Doug is on vacation or too busy. Since there's been a lot of traffic on the mailing list recently I was hoping that one of you could help. My question is how does one get to be a nmh worker so that one can commit changes to the cvs? And what's the etiquette for proposing/making changes? Thanks.