Re: Anybody mind if I remove this piece of strange code?

[Jon Steinhart]

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

Re: Anybody mind if I remove this piece of strange code?

[Jon Steinhart]

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

Anybody mind if I remove this piece of strange code?

[Jon Steinhart]

There's a piece of code in addir (uip/folder.c) that seems well intended but
causes problems.  It's the stuff under the "short cut" comment below.

static void
addir (char *name)
{
int nlink;
char *base, *cp;
struct stat st;
struct dirent *dp;
DIR * dd;

cp = name + strlen (name);
*cp++ = '/';
*cp = '\0';

/*
 * A hack to skip over a leading
 * "./" in folder names.
 */
base = strcmp (name, "./") ? name : name + 2;

   /* short-cut to see if directory has any sub-directories */
if (stat (name, &st) != -1 && st.st_nlink == 2)
return;

...

I'm busy moving stuff around on my computers, and I made a Mail directory on
a new machine and linked all of the folders to the old machine.  Problem is,
the folder command doesn't work because there are no subdirectories in the
mail directory, even though there are links to them.  This code is probably
left over from before symbolic links were invented!

Anyone have a problem if I remove this test?

Jon

Re: A semi-annual poke about progress

[Jon Steinhart]

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

A semi-annual poke about progress

[Jon Steinhart]

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.

Jon

Re: Improving attachment viewing

[Jon Steinhart]

> 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

Re: Improving attachment viewing

[Jon Steinhart]

> 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
 

% 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
 
% show
% next
 (show first part of current message)
% next
 (show next part of current message)
% next
 (...)
% next
 (show first part of next message)

Jon

Re: Improving attachment viewing

[Jon Steinhart]

>   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

Re: The continuing install-mh saga

[Jon Steinhart]

> Jon Steinhart <[EMAIL PROTECTED]> writes:
> 
> > Also, I didn't mean to start a flame war with my questions
> > about the code.  It's my opinion that nmh has about twice as
> > much code as is really needed to do the job.  That excess
> > fluff makes the code harder to understand and maintain.  So
> > I'm gonna trim it out whenever I see it.  Not to show off,
> > but to make the code easier to deal with.
> 
> If you want something to do as far as duplication reduction goes,
> check out mhbuildsbr.c and mhparse.c.  Have a barf bag handy.
> 
> --  
> Eric Gillespie <*> [EMAIL PROTECTED]

Funny.  My main reason for looking at stuff is because I want to add features,
and right now there's nothing that I want to do there.  The changes that I made
to handle sending attachments at least keep the user from having to see that
stuff.  See doc/README-ATTACHMENTS in the CVS if you don't know about this.

My interest in m_getfld is because I'd like to experiment with the way that
attachments are shown.  It'd be interesting to get a bit of discussion on
this.  Basically, I don't like the way that message parts are treated
differently than messages.  To me, there's little difference between receiving
a message with two attachments and three messages.  I'd like to see an indented
scan that shows something like

5785+ 11/19 Eric Gillespie Re: The continuing install-mh saga<
 .2 

ant then be able to do show/next/prev on stuff.  I find it really annoying to
have all body parts displayed in a single batch, especially those that involve
some interaction to get rid of, like closing an image viewer.

Jon

The continuing install-mh saga

[Jon Steinhart]

Wow!  It's amazing how something so simple can be such a
problem.  OK, since I started this, I'll change it so that
install-mh lives in bin with a link to it from lib, and I'll
change the manual page to be in section 1 instead of section 8.

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.

Also, I didn't mean to start a flame war with my questions
about the code.  It's my opinion that nmh has about twice as
much code as is really needed to do the job.  That excess
fluff makes the code harder to understand and maintain.  So
I'm gonna trim it out whenever I see it.  Not to show off,
but to make the code easier to deal with.

Jon

Re: Working on the install-mh change questions

[Jon Steinhart]

> 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

Re: install-mh location

[Jon Steinhart]

> 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

install-mh location

[Jon Steinhart]

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

Another working on the install-mh change question

[Jon Steinhart]

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

Working on the install-mh change questions

[Jon Steinhart]

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

Re: Appropriateness of new program/feature

[Jon Steinhart]

> > 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

Re: Appropriateness of new program/feature

[Jon Steinhart]

> >It's always bugged me that MH/nmh starts to install a new user setup if 
> >it can't find something it's looking for -- like the MH (.mh_profile) 
> >file.  IMHO, it should simply fail and print an error message that gives 
> >the pathname of the MH file that it's looking for (that's either the 
> >setting of the MH envariable, or $HOME/.mh_profile).  It could also tell 
> >the user how to install MH/nmh.  The error could say something like:
> 
> >": aborting: can't read .  Check your MH 
> >environment variable (if any) or run install-mh to install nmh."
> 
> I vote for that feature.

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.

Jon

Appropriateness of new program/feature

[Jon Steinhart]

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

Trouble building from cvs

[Jon Steinhart]

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.

Jon

Re: Questions about nmh 1.1

[Jon Steinhart]

> 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

Re: Questions about nmh 1.1

[Jon Steinhart]

> Sigh.  I can see I'm not going to convince you.  While some software exists
> to perform spam detection, integrating it into nmh would be ... challenging,
> especially if you want to avoid downloading the whole message.
>
> --Ken

Well, I've been waiting for all of the minor updates to nmh to be done before
submitting changes for this, but since it came up...

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 to
least interesting as opposed to some other criteria such as order of arrival.
The system has a simple training interface: after you read a piece of mail
you rank it between -100 and 100.  No complicated expression writing a la
procmail, etc.

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.

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.

Jon

P.S.I'd still like to see the simplified attachment handling patches that I
submitted a year ago to be integrated at some time.  Is the next release
the place to do it or should I wait?

Re: nmh status

[Jon Steinhart]

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

Re: nmh status

[Jon Steinhart]

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

Update of new MIME attachment user interface patches

[Jon Steinhart]

Howdy.  This is a minor update of the patches that I posted a long
time ago.  It supercedes the earlier patches.  It makes one change
which is to add a -append option to anno so that headers that
indicate attachments can be appended to the header instead of
prepended.  This makes attachments come out in the correct order
instead of backwards.

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.

Jon


diff -Naur nmh/README-ATTACHMENTS nmh-jon/README-ATTACHMENTS
--- nmh/README-ATTACHMENTS  Wed Dec 31 16:00:00 1969
+++ nmh-jon/README-ATTACHMENTS  Sat Dec  8 09:01:27 2001
@@ -0,0 +1,258 @@
+Jon Steinhart's ([EMAIL PROTECTED]) Attachment Handling Patches
+~~~
+
+Attached are a set of patches designed to improve the nmh user interface
+for handling MIME attachments.
+
+Why Did I Do This?
+~~
+
+Although nmh contains the necessary functionality for MIME message handing,
+the interface to this functionality is pretty obtuse.  There's no way that
+I'm ever going to convince my partner to write mhbuild composition files!
+And even though I know how to write them, I often screw up when sending a
+message that contains a shell script because I forget that I have to double
+any # at the start of a line, which shell scripts have galore.
+
+These patches simplify the task of managing attachments on draft files.
+They allow attachments to be added, listed, and deleted.  MIME messages are
+automatically created when drafts with attachments are sent.
+
+Did I Do This Correctly?
+
+
+Hard to say.  Despite lots of time looking at the nmh code, I can't say that
+I get the philosophy behind its structure.
+
+I am aware of two deviations from what I saw in the nmh code.
+
+ 1.  I commented my changes.
+
+ 2.  It's been years since I've used a VT-100, so I don't try to make code
+ fit into 80 columns anymore.  Seems silly to me.
+
+What Did I Do?
+~~
+
+I made changes to the following files:
+
+   h/
+   prototypes.h
+   man/
+   anno.man
+   send.man
+   whatnow.man
+   uip/
+   Makefile.in
+   anno.c
+   annosbr.c
+   send.c
+   sendsbr.c
+   viamail.c   (needed change for new sendsbr argument)
+   whatnowsbr.c
+
+Attachments are associated with messages using header fields.  For example, a
+draft that looks like this
+
+   To: jon
+   Subject: test of attachments
+   X-MH-Attachment: /export/home/jon/foo
+   X-MH-Attachment: /export/home/jon/bar
+   X-MH-Attachment: /export/home/jon/test/foo
+   
+
+has the files "foo", "bar", and foo as attachments.
+
+Although I use the header field name "X-MH-Attachment" to indicate
+attachments, the implementation allows any header field name.
+
+The advantage of using header fields is that the list of attachments
+travels with the draft so it remains valid across editing sessions.
+
+Note that the header fields for attachments are removed from the message
+before it is sent.
+
+Since I was adding header fields to messages, it seemed sensible to use the
+existing anno program to do this for me.  This required several changes to
+generalize anno:
+
+ o  I added a -draft option that permits annotations (header fields) to
+be added to the draft instead of a message sequence.
+
+ o  I added a -delete option that allows annotations to be deleted.
+
+ o  I added a -list option that allows annotations to be listed.
+
+ o  I added a -number option that modifies the behavior of -delete and -list.
+
+ o  I added a -append option so that annotations are appended to the headers
+instead of the default prepend.  Without this, attachments come out in
+reverse order.
+
+Using the modified anno, the example above could be created (assuming that the
+draft exists) by
+
+   prompt% anno -draft -comp X-MH-Attachment -text /export/home/jon/foo -nodate 
+-append
+   prompt% anno -draft -comp X-MH-Attachment -text /export/home/jon/bar -nodate 
+-append
+   prompt% anno -draft -comp X-MH-Attachment -text /export/home/jon/test/foo 
+-nodate -append
+
+One can quite easily make an "attach" command using shell scripts, aliases or 
+functions.
+For example, here's a bash function that does the job:
+
+   function attach() { for i in $*; do anno -appen -nodate -draft -comp 
+X-MH-Attachment -text "$i"; done; }
+
+The following examples show the different ways in which attachments can be
+listed.
+
+   prompt% anno -list -draft -comp X-MH-Attachment
+   foo
+   bar
+   foo
+
+   prompt% anno -list -draft -comp X-MH-Attachment -text /
+   /export/home/jon/foo
+   /export/home/jon/bar
+   /export/home/jon/test/foo
+
+   prompt% anno -list -draft -comp

Re: Question about behavior of mhpath

[Jon Steinhart]

I originally wrote:

>I just noticed that
>
>   mhpath cur
>
>produces the same results as
>
>   mhpath new
>
>if there is no current message.  Looking at the code, it seems
>deliberate, but why?  Acts like a bug to me.

Neil wrote:

> I just tested, and got
>
>   6% mhpath cur
>   mhpath: no cur message
>
> It seems that if the "cur" sequence is defined, but there is no
> message of that number, mhpath will return that path to the indicated
> message anyway.  If the "cur" sequence is not defined at all, it
> returns "no cur message".
>
> This seems right to me.

 -NWR

Sean wrote:
> I set my .mh_sequences "cur=120" in a folder with only 17 messages,
> and 'mhpath cur' return nothing.
>
> However, if I set it to a number inside an unused range, I get the
> next lowest message (ie., I have a folder with 1-187, 215-250.  I set
> cur=200, and mhpath (and folder) return  187.
>
> Also seems right to me.
>
> Sean

OK, here's what I'm seeing.

I just incorporated the messages from each of you.  These ended up being message
numbers 3913-3916 (because you each cc'd me in addition to posting to the list
list so I got two of each) in my inbox, located in /export/home/jon/Mail/inbox.  

I deleted (rmm) message 3916.  I then did "mhpath cur" and it returned

/export/home/jon/Mail/inbox/3916

This is the same thing that "mhpath new" returns.  I would expect "cur" to say
"no cur message" and "new" to return the above.

I see the following line in uip/mhpath.c:

mp->msgflags |= ALLOW_NEW;  /* allow the "new" sequence */

Then, m_convert is called, and hits the following code in m_convert.c

if (mp->msgflags & ALLOW_NEW) {
set_select_empty (mp, first);
} else {
if (first > mp->hghmsg
|| first < mp->lowmsg
|| !(does_exist (mp, first))) {
if (!strcmp (name, "cur") || !strcmp (name, "."))
advise (NULL, "no %s message", name);
else
advise (NULL, "message %d doesn't exist", first);
return 0;
}
}

So I guess that I don't understand how Neil and Sean are seeing what they're
seeing.

Jon

Question about behavior of mhpath

[Jon Steinhart]

I just noticed that

mhpath cur

produces the same results as

mhpath new

if there is no current message.  Looking at the code, it seems
deliberate, but why?  Acts like a bug to me.  If I want to write
a shell script to, for example cat the current message so that I
can look at the headers, this doesn't work.  And there's no other
easy way to do it.

Jon

Re: my attachment code, plus attachments in general (really new release)

[Jon Steinhart]

> Hold up -- everyone back up a step. The most immediate concern is 
> getting out a release that makes public the changes in CVS for the last 
> 2 (?) years. This is not a good time to be making more changes on the 
> main branch, as it will inevitably hold up the process more. This would 
> be a good reason to make a branch for these types of exploration.
> 
> Hopefully, all the people on this list have the CVS version installed on 
> some machine, and have been using it for some time. If not, please do, 
> so we can get at any egregious bugs. I have not seen any so far, but...
> 
> Shantonu

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
out everything that fell through the cracks because the maintainer was too
busy.

Jon

Re: my attachment code, plus attachments in general

[Jon Steinhart]

> On 7 December 2001 at 8:24, Jon Steinhart <[EMAIL PROTECTED]> wrote:
> > 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.
> 
> There are cases where the *order* of anno's annotations (the header
> fields it adds) *does* matter.  For instance, if you're displaying a
> particular header field, "scan" will show only at the *first*
> occurrence of that field (the occurrence closest to the start of the
> message file).  For example:
> 
> $ show -noshow last
> (Message DELETE:352)
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Hmmm
> 
> This is a test
> $ anno -component X-haha -text 'first annotation' -nodate
> $ show -noshow last
> (Message DELETE:352)
> X-haha: first annotation
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Hmmm
> 
> This is a test
> $ anno -component X-haha -text 'second annotation' -nodate
> $ show -noshow last
> (Message DELETE:352)
> X-haha: second annotation
> X-haha: first annotation
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Hmmm
> 
> This is a test
> $ scan -format '%{x-haha}' cur
> second annotation
> 
> If it doesn't add too much complexity, it might be worth keeping the
> old prepending code as an option.
> 
> Jerry
> -- 
> Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/

OK, will do.

So, now that this list has come alive again, I have a larger question on
attachments.

I have been thinking about the interface for reading attachments.  While
mhlist, mhstore, and mhshow work, they don't present a pleasing UI.  I
would personally like there to be no difference between reading messages
and reading attachments.  In other words, I don't want to have to use a
different UI because someone sends me a message with 3 attachments as
opposed to 3 messages.

Along these lines, changing the message numbering scheme a bit makes
sense to me.  I'd like to be able to "show 123.4" as opposed to having
to "show 123; mhlist; mhshow -part 4".  And I'd like next and prev to
go to the next and previous attachments if a message has attachments.
I'd even like scan to list the attachments.

Now, I realize that this a major change.  Any opinions out there?

Jon

Re: my attachment code

[Jon Steinhart]

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

Re: IETF-Announce messages that nmh doesn't like...

[Jon Steinhart]

>   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

Re: IETF-Announce messages that nmh doesn't like...

[Jon Steinhart]

> The enclosed message causes problems for nmh-1.0.4 from the NetBSD 
> packages collection.  It prints the headers, along with the message:
> 
>   mhshow: bogus multipart content in message 1256
> 
> Alas, I don't know the mail RFCs well enough to pin the blame on the
> IETF editor or NMH.  Any ideas?
> 
> Thanks,
> 
> Kevin
> [EMAIL PROTECTED]

mhshow is right.  It is bogus multipart content.  Notice that the boundary specified
on the content-type line is "NextPart".  This means that "--NextPart" lines are
boundary markers.  But, in the remainder of the document they're "- --NextPart".
Also, there should be a boundary after the headers.  As the document is written
everything in it is commentary that may not be displayed by a mail reader.

> --- Forwarded Message
> 
> Return-Path: <[EMAIL PROTECTED]>
> Received: from nevertheless.selresearch.net (nevertheless.selresearch.net 
>[64.167.159.132])
>   by destroy.selresearch.net (8.12.0/8.12.0) with ESMTP id f9HJvFmZ004907
>   for <[EMAIL PROTECTED]>; Wed, 17 Oct 2001 12:57:15 -0700 (PDT)
> Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
>   by nevertheless.selresearch.net (8.12.0/8.12.0) with ESMTP id f9HJxMjK017410
>   for <[EMAIL PROTECTED]>; Wed, 17 Oct 2001 12:59:22 -0700 (PDT)
> Received: (from adm@localhost)
>   by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA28546
>   for [EMAIL PROTECTED]; Wed, 17 Oct 2001 15:05:01 -0400 (EDT)
> Received: from ietf.org (odin.ietf.org [10.27.2.28])
>   by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA28064
>   for <[EMAIL PROTECTED]>; Wed, 17 Oct 2001 14:38:12 -0400 (EDT)
> Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
>   by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03018;
>   Wed, 17 Oct 2001 14:38:12 -0400 (EDT)
> Message-Id: <[EMAIL PROTECTED]>
> To: IETF-Announce: ;
> Subject: RFC 3143 on Known HTTP Proxy/Caching Problems
> Cc: [EMAIL PROTECTED]
> Mime-Version: 1.0
> Content-Type: Multipart/Mixed; Boundary="NextPart"
> From: RFC Editor <[EMAIL PROTECTED]>
> Date: Wed, 17 Oct 2001 14:38:12 -0400
> Sender: [EMAIL PROTECTED]
> X-UIDL: Dlo"!0SP!!1pl"!eRU!!
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 3143
> 
> Title:Known HTTP Proxy/Caching Problems
> Author(s):  I. Cooper, J. Dilley
> Status: Informational
>   Date:   June 2001
> Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED]
> Pages:  32
> Characters: 57117
> Updates/Obsoletes/SeeAlso:  None
> 
> I-D Tag:draft-cooper-wrec-known-prob-01.txt
> 
> URL:ftp://ftp.rfc-editor.org/in-notes/rfc3143.txt
> 
> 
> This document catalogs a number of known problems with World Wide Web
> (WWW) (caching) proxies and cache servers.  The goal of the document
> is to provide a discussion of the problems and proposed workarounds,
> and ultimately to improve conditions by illustrating problems.  The
> construction of this document is a joint effort of the Web caching
> community.
> 
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
> 
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [EMAIL PROTECTED]  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [EMAIL PROTECTED]
> 
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [EMAIL PROTECTED] with the message body 
> help: ways_to_get_rfcs.  For example:
> 
> To: [EMAIL PROTECTED]
> Subject: getting rfcs
> 
> help: ways_to_get_rfcs
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [EMAIL PROTECTED]  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.echo 
> Submissions for Requests for Comments should be sent to
> [EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
> 
> 
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
> 
> ...
> 
> Below is the data which will enable a MIME compliant Mail Reader 
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> 
> - - End Included Message -
> 
> - --
> X-Sun-Data-Type: Multipart
> X-Sun-Content-Length: 490
> X-Sun-Charset: us-ascii
> X-Sun-Content-Lines: 22
> 
> - --OtherAccess
> Content-Type:  Message/External-body;
> access-type="mail-server";
> server="[EMAIL PROTECTED]"
> 
> Content-Type: text/plain
> Content-ID: <[EMAIL PROTECTED]>
> 
> RETRIEVE: rfc
> DOC-ID: rfc3143
> 
> - --OtherAccess
> Content-Type:   Message/External-body;
> name="rfc3143.txt";
> site="ftp.isi.edu";
> access-ty

Re: Odd bug, has anyone else seen this?

[Jon Steinhart]

> | 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.

Odd bug, has anyone else seen this? - another instance

[Jon Steinhart]

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 [208.177.199.21])
>   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: 
> list-unsubscribe: 
> list-post: 
> 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
> 
>   ...

Odd bug, has anyone else seen this?

[Jon Steinhart]

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 [208.177.199.21])
>   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: 
> list-unsubscribe: 
> list-post: 
> 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
> 
>   ...

Is anybody there?

[Jon Steinhart]

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

Recap on mail message compatibility with RFC822 [and it's successor]

[Jon Steinhart]

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

Question on compatibility of nmh mail messages with RFC822

[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

Attachment modifications to nmh

[Jon Steinhart]

Thanks to Dan Harkless for feedback on how to get this stuff in.  Among
other things, he wrote:

> Nothing special.  Just let the list know.  As for your attachment changes,
> why not just post your diffs (using -c, of course, and vs. the latest CVS
> source if possible) to the list and ask if someone with write access would
> commit them?  Doing it this way makes it easier for multiple people on the
> list to audit your changes.
> 
> Also, hopefully your diffs include documentation updates.

And, of course, they do.  There are even comments in the code, which seems
to go against the nmh grain!  Below is the documentation.  I'll wait a few
days for feedback on the documentation before posting the diffs in case
anyone suggests changes.

NAME
 whatnow - prompting front-end for sending messages

SYNOPSIS
 whatnow [-draftfolder +folder] [-draftmessage msg]
  [-nodraftfolder] [-editor editor] [-noedit]
  [-prompt string] [file] [-version] [-help]

DESCRIPTION
 Whatnow is the default program that queries the  user  about
 the  disposition  of  a  composed  draft.   It  is  normally
 automatically invoked by one of the nmh commands comp, dist,
 forw, or repl after the initial edit.

 When started, the editor is started  on  the  draft  (unless
 `-noedit'  is  given,  in  which  case  the  initial edit is
 suppressed).  Then, whatnow repetitively  prompts  the  user
 with   "What  now?"   and  awaits  a  response.   The  valid
 responses are:

 editre-edit using the same editor that was used on the
 preceding round unless a profile entry
 "-next: " names an alternate editor
 editinvoke  for further editing
 refile +folder  refile the draft into the given folder
 mimeprocess the draft as MIME composition file using
 the "buildmimeproc" command (mhbuild by default)
 display list the message being distributed/replied-to
 on the terminal
 listlist the draft on the terminal
 sendsend the message
 send -watch send the message and monitor the delivery process
 pushsend the message in the background
 whomlist the addresses that the message will go to
 whom -check list the addresses and verify that they are
 acceptable to the transport service
 quitpreserve the draft and exit
 quit -deletedelete the draft and exit
 delete  delete the draft and exit
 cd [dir]change directory from which attachments are read
 pwd print director from which attachments are read
 ls [ls-options] list files in attachment directory
 attach filesattach files to draft

 When entering your response, you need only type enough char-
 acters to uniquely identify the response.

 The attach response can be  used  to  attach  files  to  the
 draft.   It  does  this by appending a line to the draft for
 each file in the mhbuild(1) MIME  composition  file  format.
 It  is recommended that you set automimeproc in your profile
 so that the composition file is automatically  converted  to
 MIME  format  when  you  send.   The file names are expanded
 using your shell as defined by the $SHELL environment  vari-
 able,  so  metacharacters  and  other  syntactical  sugar is
 available.

 The cd response changes the attachment directory and can  be
 used  to eliminate the need for entering long file names for
 attachments.  The pwd response outputs the  current  attach-
 ment  directory.   The ls response can be used to list files
 in the attachment directory; all of the normal ls(1) options
 are  available.  As with the attach response, all file names
 are expanded using your shell.

 For the edit response, any valid switch  to  the  editor  is
 valid.

 For the  send  and  push  responses,  any  valid  switch  to
 send (1)  are  valid  (as  push merely invokes send with the
 `-push' option).

 For the whom response,  any  valid  switch  to  whom (1)  is
 valid.

 For the refile response, any valid switch to the fileproc is
 valid.

 For the display and list responses, any  valid  argument  to
 the  lproc  is  valid.   If  any  non-switch  arguments  are
 present, then the pathname of the  draft  will  be  excluded
 from  the  argument  list given to the lproc (this is useful
 for listing another nmh message).

 See mh-profile (5) for further information about how editors
 are  used  by  nmh.  It also discusses how environment vari-
 ables can be used to direct  whatnow's  actions  in  complex
 ways.

 The `-prompt string' switch sets the  prompting  string  for
 whatnow.

 The `-draftfolder +folder' and `-draftmessage msg'  switches
 invoke

How does one become a nmh-worker?

[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.