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

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote on Oct 20, 2003:

> Problem is,
>the folder command doesn't work because there are no subdirectories in the
>mail directory, even though there are links to them.

It is hard to imagine a Mail directory without at least one
subdirectory (such as RCS).

 -NWR

Re: default components file

[Neil W Rickert]

Bill Wohler <[EMAIL PROTECTED]> wrote:

>Earl Hood <[EMAIL PROTECTED]> wrote:

>> The only potential confusion for new users about "Fcc: +outbox" is
>> that when they see it the first time when composing a message, they
>> may be confused on exactly what that means.

>That's a good point. Here are some other issues that come to mind. In
>this discussion, "replcomps" means "replcomps and replgroupcomps".

>Note that in replcomps, the Fcc only appears if you specify "repl -fcc
>+outbox". But then it does appear in the header.

My "replcomps" contains:

%<{fcc}Fcc: %{fcc}\n%|Fcc: +outbox\n%>\

which seems to have the effect that outbox is the default,
but is overridden by "-fcc folder" on the command line.

>Whatever we do should be consistent. If we were simply to add "Fcc:
>+outbox" to components, we'd make "-fcc +outbox" the default for repl.
>This isn't consistent. Fcc would be set in the components file on one
>hand, and on the command line in another.

I think my "replcomps" handles that with sufficient consistency.

>So, one solution would be to add -fcc +outbox to comp and apply
>mh-format to components files as well so that Fcc could be controlled by
>both the components file and the command line. Perhaps folks would
>welcome MH formatting in the components file, but it could be a lot of
>work.

It would be nice to add a "-fcc" option to comp, but we should not
hold up a release waiting for that change.

>Even though Ruud make a good point about the difference between outbox
>and sent-items in other mailers, I'm not sure how applicable this
>argument is to MH, since the parallel between inbox and outbox is so
>strong.

He is correct about other MUAs.  But MH is not just another MUA,
and we should do this in the way most compatible with MH.  In
particular, MH users tend to want the maximum ability for personal
tailoring, and what other MUAs do could be too restrictive.

 -NWR

Re: Why not document dcc:?

[Neil W Rickert]

Ralph Corderoy <[EMAIL PROTECTED]> wrote:

>Perhaps mention it in the fcc description as an alternative.  I found
>fcc useless for my purposes;  it's really handy to have the real
>message-id, etc.

Have mh set the message-id

send: -msgid

in your ".mh_profile"

 -NWR

Re: default components file

[Neil W Rickert]

Glenn Burkhardt <[EMAIL PROTECTED]> wrote:

>I'd like to change the default components file to include a folder copy:

>To:
>cc:
>Fcc: +sent-mail
>Subject:
>

Why "sent-mail" rather than "outbox"?

 -NWR

Re: A semi-annual poke about progress

[Neil W Rickert]

Glenn Burkhardt <[EMAIL PROTECTED]> wrote:

>Clues on what the test for 'broken vi' does are solicited.

The "vi" on some systems (including solaris) returns a non-zero
exit status if any command at all failed during the vi session.

Presumably this makes sense if vi is running in the background
from a response file.

Anyway, nmh ignores vi exit codes on such systems.

 -NWR

Re: Improving attachment viewing

[Neil W Rickert]

Robert Elz <[EMAIL PROTECTED]> wrote:

>Preventing "show" (aka next, prev) from ever attempting to display attachments
>would be a great (as an option, or just as the default, imnsho).

setenv NOMHNPROC

 -NWR

Re: Improving attachment viewing

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

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

I just use

mhlist next

when I want that.  But mostly, I'm with Bill in preferring the plain
listing.  Screen real estate is too valuable to clutter with
attachment detail when you are scanning the list.

 -NWR

Re: Working on the install-mh change questions

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

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

The assumption that there will not be another getpwuid(), nor a
getpwnam(), is a horrible assumption, particularly from somebody who
has just commented about sloppy code.  Your comment about "a different uid"
is also confused -- there is no certainty that a second call for the
same uid will return the same result, and it is sloppy programming
to assume that it will.

Presumably the copy following getenv() is for consistency between
the two cases (getenv() or getpwuid()).

 -NWR

Re: install-mh location

[Neil W Rickert]

Eric Gillespie <[EMAIL PROTECTED]> wrote:
>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

People have been using MH, and now nmh, for a very long time.  They
have come to expect things in particular places and my have local
shell scripts that depend on it.

>with a backwards compatability symlink, but if you must have one
>the link goes in libexecdir.

Putting the link in lib would be fine.

 -NWR

Re: install-mh location

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

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

Make a sym-link, or put in a shell script.

 -NWR

Re: Appropriateness of new program/feature

[Neil W Rickert]

Jerry Peek <[EMAIL PROTECTED]> wrote:

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

 -NWR

Re: X-Authentication-Warning:

[Neil W Rickert]

Harald Koch <[EMAIL PROTECTED]> wrote:

>Short of patching the sourcecode, does anyone know how to turn off the
>warning message that sendmail generates when nmh submits a message?
>Specifically:

>  X-Authentication-Warning: elisabeth.cfrq.net: chk owned process doing -bs

The best solution is to compile nmh so that it uses smtp to localhost
when sending the mail.  Configure with "--with-mts=smtp".

>Now that SpamAssassin picks this up as one of its checks, the message is
>a liability. In my particular case, it doesn't add anything useful,
>since I own root on elisabeth.cfrq.net :-)

>(Adding myself to sendmail's "trusted users" list didn't do it...)

You are using sendmail-8.12.x

Add yourself to trusted users in submit.mc/submit.cf

 -NWR

Re: sorting messages by thread

[Neil W Rickert]

Moshe Kaminsky <[EMAIL PROTECTED]> wrote:

>I'm new to mh, and I have several questions. Please forgive me if
>they're stupid.

>My first question is this: Is it possible to sort messages by threads
>(like in Mutt, for instance; the replies to each mail appear immediately
>after the mail itself). I didn't find any obvious way to do it with
>sortm. If not possible directly, maybe there is some script that does
>it?

sortm -textfield subject -limit 0

 -NWR

Re: slocal (v1.0.2) garbles 8bit mail parts

[Neil W Rickert]

Tobias Polzin <[EMAIL PROTECTED]> wrote:

>I don't like BASE64/Quoted-Printable Encoded Mails, because they
>are difficult to Quote and Search with exmh/glimple.
>If I use "/usr/lib/python/mimefy.py -b -d | /usr/mh/lib/slocal"
>some 8bit Parts of Mails got garbled by slocal. It seems to me,
>everything in a line following a "zero char" (including the
>trailing newline) is removed.

Why am I not surprised.

>I don't know, whether it is allowed to have zero chars in 8bit 
>components of mails, anyway it should not be too difficult to
>tell slocal leave everything in the mail as it is.

"slocal" is only one of a zillion programs that cannot properly
handle embedded '\0' characters.

This is, at least in part, due to the unfortunate "design" of
fgets().

 -NWR

Re: Wrapping replies

[Neil W Rickert]

Sean Kamath <[EMAIL PROTECTED]> wrote:

>Lately, people here at work have really turned on the flowed text
>rather than wrap it.  In a way, this makes some sense -- let the mail
>reader wrap the text (and exmh does a fine job of it).

It makes no sense at all to me.

>But this makes for a problem on quoting replies. If there were some
>standardized way to mark a quote, this would be a non-issue,

The proper method is to send back a nasty-gram, asking the author to
resend as decently formatted text.

 -NWR

Re: Using web browser mail agent as nmh message viewer

[Neil W Rickert]

Jerry Peek <[EMAIL PROTECTED]> wrote:

> But, these days, I get so much MIME mail with
>attachments... and nmh's MIME handling is so far from what I
>need... that I've been using the Mozilla mail agent to make the
>first cut at reading my mail, weeding out spam, etc... then
>using a script to pull the messages I want to keep from my
>Mozilla inbox into my nmh inbox, where I file them.  Until now.

Interesting.

I'm doing the reverse.

I get so much MIME mail, and so much of that MIME mail is spam,
that my first pass is with command line tools, before I try
using exmh for rendering the mime.

 -NWR

Re: nmh and tcl

[Neil W Rickert]

Ken Hornstein <[EMAIL PROTECTED]> wrote:

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

I don't have any problem with that.

 -NWR

Re: nmh and tcl

[Neil W Rickert]

Ken Hornstein <[EMAIL PROTECTED]> wrote:
>>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" and "people with
>ability/time to implement said cool ideas" seems rather small at the
>moment, I'm not exactly worried yet :-)

I agree there is no need to panic.  I just wanted to register dissent
with the expressed view.  But maybe I should have expanded on that
comment.

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.

I use exmh, as you can see from the headers.  But I also use the
command line tools.  For example, if I want to lart an ISP for spam
received from that network, I have a shell script that does most of
the work of preparing my complaint.  Some messages I preview with
command line tools before deciding whether to open in exmh -- this
avoids having to wait for garish pornography to be displayed before I
move the message to my spam folder.  And then, even while using exmh,
I have put some shell scripts into the command line backend to
simplify my job.  I expect many exmh users have done similar things.

 -NWR

Re: nmh and tcl

[Neil W Rickert]

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.

 -NWR

Re: locking rcvstore?

[Neil W Rickert]

Michael Richardson <[EMAIL PROTECTED]> wrote:


>  Aside from trashing sequences (which I've experienced on occasion, no idea
>why)
>  I've run into situations where I wind up doing an "inc" from two difference
>sources into the same folder. Usually due to impatience on my part. 

As far as I know, "inc" does to file locking, at least when writing
to the standard unix mailbox.

>  The result was a mess of two processes using the same message numbers!

That should not be possible.  I haven't looked at the code.  But it
should be opening the file with "O_CREAT", which should fail if the
message already exists.

Unless there are major code deficiencies, creating new messages
should depend on the atomicity of unix file creation.  No additional
locking should be required.  That is supposed to be one of the
benefits of one message per file.

 -NWR

Re: locking rcvstore?

[Neil W Rickert]

Chris Garrigues <[EMAIL PROTECTED]> wrote:

>I always call rcvstore with this wrapper:

>#!/bin/bash

>...

>and it would be nice if it weren't needed.

I'm not convinced that it is needed.

The only risk is that your sequences might be corrupted.  I prefer
that to the problems caused by stuck locks.

 -NWR

Re: problem w/ make install on MacOS X 10.1.5

[Neil W Rickert]

"Jon Stewart" <[EMAIL PROTECTED]> wrote:

>I'm a Unix moron (hence the use of MacOS X), and I can't seem to get
>nmh-1.0.4 to install on my system. Make claims that the install target is
>up to date. (Also, config couldn't guess the host, so I specified
>powerpc-apple-machten5.5, which -- except for the part about not
>installing -- seemed to work.)

>Here's what I did (after reading INSTALL and MACHINES):

>% ./configure --host=powerpc-apple-machten5.5 --enable-debug \
>  --prefix=/usr/local

>...configuring, blah blah...

>% make

>...making, blah blah...

>% make install
>make: `install' is up to date.

ls -l install

If there is a zero-length file named "install" in the main nmh
directory (there shouldn't be)

rm install
make install

If the file isn't zero length, you might want to investigate before
removing it.

 -NWR

Re: Do you use (n)MH book? Should I maintain it?

[Neil W Rickert]

Jerry Peek <[EMAIL PROTECTED]> wrote:

>Would you please take 15 seconds now to send me a quick reply and tell me:

>- do you use the online book?

Last use was about 2 years ago.

 -NWR

Re: nmh status

[Neil W Rickert]

Geoff Raye <[EMAIL PROTECTED]> wrote:

>% packf `pick +l/nmh -after 03/17/2001 -and -search nmh-workers`

>http://www.raye.com/nmh-workers-20010317-20020509.gz
>aka
>http://lnk.to/archive

>So, that's just nmh-workers.  Should be a start.  Should be complete, as
>far as that list.

I'm pretty sure that nmh-bugs is forwarded to nmh-workers.

 -NWR

Re: nmh status

[Neil W Rickert]

Doug Porter <[EMAIL PROTECTED]> wrote:

>Could everyone please just settle down?  You all are so worried
>about moving the project to a new location, but there does not
>seem to be any immediate need for that.  Ftp access and anonymous
>CVS access to nmh still work.  Take what source exists and
>actually work on some patches instead of worrying about your CVS
>commit access.

I'm inclined to agree with Doug P. on this.

If development of nmh is languishing, it it because nobody is doing
much of the work.  When Richard Coleman was in charge, things moved
along.  But since then, nobody has been in charge.  A few people have
stepped in and managed things for a little while, so that they could
make their own changes.

Moving the repository won't solve that.  If Richard wants to step
back into that role, I would be happy to see that.  If somebody else
is willing to take charge that would be fine too.

I suspect that we all use nmh, and for the most part we are happy
with it.  We have a few gripes about little points.  But it works
well enough for us, that we don't want to put the effort into
continuing Richard's original plans to clean up the code base and
make it more maintainable.

 -NWR

Re: nmh problem

[Neil W Rickert]

"David L. Gehrt" <[EMAIL PROTECTED]> wrote:

>What still works is piping files directly to sendmail as in " cat file
>| sendmail -t".  What is not working is comp -> whatnow -> send from a
>command prompt.

Try (at the "whatnow" prompt:

 send -verbose -watch

Maybe the extra feedback will give you a better idea on what is going
wrong.

 -NWR

Re: FW: ports/36307: nmh port cuts off last part of sender domain

[Neil W Rickert]

Scott Blachowicz <[EMAIL PROTECTED]> wrote:

>This is a bug report from the FreeBSD ports mailing list.  I'm the maintainer
>of this port, so I figured I'd look into it a bit.  Does this behavior sound
>familiar to anyone?

Nobody else seems to be answering.

No, this does not sound familiar.

However, I use Solaris, not FreeBSD, so I cannot be certain my
experience applies.

>   The nmh 1.0.4 port from mail/nmh cuts off the last
>   part of the sender domain/hostname used for the mail envelope,
>   resolving in a bounced message from the destination server
>   because the sender domain could not be resolved.
>   See the following transcript:

>   Mar 25 17:13:22 reiher postfix/smtpd[512]: connect from localhost[127.0.0.1]
>   Mar 25 17:13:22 reiher postfix/smtpd[512]: 23E19ACE2: 
>client=localhost[127.0.0.1]
>   Mar 25 17:13:22 reiher postfix/cleanup[513]: 23E19ACE2: 
>message-id=<[EMAIL PROTECTED]>
>   Mar 25 17:13:22 reiher postfix/qmgr[332]: 23E19ACE2: 
>from=<[EMAIL PROTECTED]>, size=641, nrcpt=1 (queue active)

>   The full "from" should be "[EMAIL PROTECTED]",
>   whereas nmh sends it as "[EMAIL PROTECTED]", which
>   obviously is wrong.  hostname(1) reports the correct full hostname.

What is the first entry on the output from

grep -i `hostname` /etc/hosts

If that is the truncated name, it might explain the problem.

 -NWR

Re: Question about behavior of mhpath

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

[a bunch of stuff] and

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

I'm looking at folder +nmh, which currently has message 1-83, 85, 86.
I deleted (with "rmm") 84, which was a duplicate anyway.  At present
I am responding to message 86, which is therefore current.

If I look in $HOME/Mail/nmh/.mh_sequences I find

cur: 86

and "mhpath" gives the path to message file 86.  If I edit that
file, to change the "cur" setting to some other valid number,
"mhpath" returns the path to that message file, whether or not
the message file exists.  If I delete the line entirely, or
delete the ".mh_sequences" file entirely, I get "mhpath: no cur message".

This all looks as it should be.

 -NWR

Re: Question about behavior of mhpath

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> 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.

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

Re: nmh packf bug

[Neil W Rickert]

Rob Fugina <[EMAIL PROTECTED]> wrote:

>There seems to be a file descriptor leak in packf which results in
>messages like this:

>packf: unable to dup /full/path/.mailbox.map: Too many open files, continuing...

>The packf process opens the output file enough times (without closing any)
>to reach an OS limit around 1000 file descriptors.  Moving >1000 (or so)
>messages with packf results in this error.  Seems to be opening the output
>file once per message without closing.  I haven't investigated deeply yet.
>I will try to send a patch, but I'd like to know if anybody's aware of
>the problem at this point...

Strange.

As a test, I just used packf to pack a mailbox with 1322 messages.
It did so without a murmur.  When also using "-mmdf", I will admit
that it took too long and that it screwed up the ".map" file.
Certainly the ".map" file construction is broken.  But I didn't have
any problem with running out of file descriptors.
My current ulimit for descriptors is 64.  (This is solaris 7).

 -NWR

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

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

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

You are wrong there.  The "- --NextPart" comes from the encapsulation
used by "forw".  Extract the message with "burst" to remove that.

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

You are correct there.

In other tests:

  "pine" sees it as an empty malformed message.
  "exmh" sees it as an empty message.
  "mutt" displays the message.

 -NWR

"msh" is broken.

[Neil W Rickert]

Here is a transcript:

% msh OLD
Reading OLD, currently at message 1 of 1322
(msh) show 1232
(Message 1232)
mhshow: -show unknown
exit 1
(msh) q
% 

The file OLD is was generate by "packf -mmdf" as an archive of
older messages.

The particular message, 1232, consists of a single rfc822 attachment.

Incidently, "msh" from MH-6.8.4 does not have the same problem.  Also
there is no problem with messages that do not have attachments.

 -NWR

Re: packf and msh bugs

[Neil W Rickert]

Jerrad Pierce <[EMAIL PROTECTED]> wrote:

>packf -- nmh-1.0 [compiled on maytag.mit.edu at Wed May 16 05:46:34 EDT 2001]

>A)
>I pack'd a folder and recieved many:

>packf: /afs/athena.mit.edu/user/b/e/belg4mit/.msgbox.map: version mismatch (50331648 
>!= 3), continuing...

That happens with "-mmdf".  I haven't been able to track down the bug
(yet), but I admit to not having looked very hard.

>But I was able to msh the doc and all seemed fine.

That's why I haven't looked very hard.

>B)
>I pack'd on another architecture (packing a larger folder hosed the first box)
>and got no errors BUT:

>Reading msgbox, currently at message 1 of 1

Might be a problem of the mail reading program.

>There are 323 messages in msgbox. I can see them through a pager.
>I removed .msgbox.map hoping it would get refreshed
>but that did not seem to help.

>C)
>Here are the orignal headers from a message:

>To: [EMAIL PROTECTED]
>Subject: pardon the intrusion?
>Reply-to: [EMAIL PROTECTED]
>Return-receipt-to: [EMAIL PROTECTED]
>Organization: a) Discordia b) none c) what's that?
>Content-Typo: gibberish, charset=ascii-art
>Date: Wed, 13 Dec 2000 13:33:12 EST
>From: Jerrad Pierce 

>After pack'ing they look like this:

>>From nobody@nowhere  Wed Aug 08 22:26:51 2001To: [EMAIL PROTECTED]
>Subject: pardon the intrusion?
>Reply-to: [EMAIL PROTECTED]
>Return-receipt-to: [EMAIL PROTECTED]
>Organization: a) Discordia b) none c) what's that?
>Content-Typo: gibberish, charset=ascii-art
>Date: Wed, 13 Dec 2000 13:33:12 EST
>From: Jerrad Pierce 

That looks like pack without the "-mmdf" (gives you mbox format).

It works fine here.

>Now, that's not right...

The initial "From " line is invented, since it is needed as
a message separator in mbox format.

 -NWR

Re: Is this a bug?

[Neil W Rickert]

[EMAIL PROTECTED] (Peter Seebach) wrote:
>In message <[EMAIL PROTECTED]>, Neil W Rickert writes:

>>>... but it doesn't allow "[EMAIL PROTECTED]", a subscribed user, to submit
>>>a message unless the machine I'm on is actually named "plethora.net".

>>Have you tried using
>>localdomain: plethora.net
>>in your mts.conf file?

>No.  Did that exist in old MH?

I have a similar line in my "mtstailor" line.  Possibly it was a late
addition -- MH-8.6.3 or there abouts.

 -NWR

Re: Is this a bug?

[Neil W Rickert]

[EMAIL PROTECTED] (Peter Seebach) wrote:
>In message <[EMAIL PROTECTED]>, Neil W Rickert writes:

>>The principle is supposed to be that the "From:" header identifies
>>the author of the message, while the envelope sender or the "Sender:"
>>header identifies the person responsible for sending it.  The mailing
>>list interpretation is actually a reasonable one.  In principle it
>>allows you, as a subscribed user, to submit a message written by a
>>different author.

>... but it doesn't allow "[EMAIL PROTECTED]", a subscribed user, to submit
>a message unless the machine I'm on is actually named "plethora.net".

Have you tried using

localdomain: plethora.net

in your mts.conf file?

>I agree that it's useful... I'm just not sure what to do when my mailer
>wants to add a field which prevents my from mailing a list.  The easy
>solution is just to enable draft masquerading, and leave Sender: out.

If that best solves your problem, sure.

>>Program that do that (prefer "Sender:" to "Reply-To:" or "From:" for
>>the purpose of replies) are badly broken.  But that is not your
>>problem, which relates more to the distinction between administrative
>>responsibility and authorship.

>It's an interesting point.  I understand the intent of "only people subscribed
>to a list may send mail to it", but given the meaninglessness of machines
>these days,

Machine names have always been potentially meaningless.  That's why
there is a "localdomain:" line in mts.conf.

>  , I would think it would make sense to accept a message if *either*
>Sender *or* From was subscribed.

That's something you would have to argue with the mailing list
administrators.

 -NWR

Re: Is this a bug?

[Neil W Rickert]

[EMAIL PROTECTED] (Peter Seebach) wrote:
>In message <[EMAIL PROTECTED]>, Neil W Rickert writes:

>>>I don't really object to it... but the Lsoft "listserv" mailing list package
>>>does.  Whenever there's both a From: line *and* a "Sender:" line, listserv
>>>concludes that the Sender: line is authoritative.

>>What does "authoritative" mean here?

>It means that if my "Sender:" line says "[EMAIL PROTECTED]",
>that my mail will be rejected from a closed listserv list unless the address
>subscribed is "[EMAIL PROTECTED]".  This makes it very hard
>to use a canonical address.

>>Quite apart from the "From:" header and any "Sender:" header, there
>>is the information transferred in the SMTP "MAIL From:" command,
>>typically referred to by email gurus as the "envelope sender".  The
>>envelope sender is likely to be the same as is in the "Sender:"
>>header.  It is more likely that the listserve package is using the
>>envelope sender than that it is using the "Sender:" header.

>Nope.  I asked their tech support people.  When they are evaluating whether
>a message came from a subscriber, if there is both a "From:" and a "Sender:",
>they assume that the Sender is more correct.  I think this is wrong, but I
>seem to recall being told that their head developer is pretty much unwilling
>to grant the idea that, when people disagree about interpretation on an RFC,
>the best thing to do is adapt to allow their interpretations.

The principle is supposed to be that the "From:" header identifies
the author of the message, while the envelope sender or the "Sender:"
header identifies the person responsible for sending it.  The mailing
list interpretation is actually a reasonable one.  In principle it
allows you, as a subscribed user, to submit a message written by a
different author.

>>The ability to override this in nmh is a recognition that, in our
>>current complex world the value automatically determined on your
>>computer system might be invalid or inappropriate, due to the
>>complexity of today's email world, dynamic IP assignments, the use of
>>private hostnames on private networks that connect to Internet, etc.

>Yeah, the main problem is that it turns out to be useless data in almost
>all cases.  In practice, when I send mail, it's always really me sending it,
>and the address I put in the From line is always really me, so the Sender
>line isn't all that useful.

It's actually more common to use the envelope sender, which often shows
up as "Return-Path:" in the final delivered message.

Right now, I am looking at your original message.  It has your
address on the "From:" line.  But the envelope sender address
is [EMAIL PROTECTED]  Technically, that means that
you are responsible for the content of the message, and if I find
it libellous I should sue you.  But [EMAIL PROTECTED] is
administratively responsible, and errors in delivery and other such
problems should be reported there.

This distinction between authorship and administrative responsibility
has turned out to be a very useful one, even if it happens to be
causing your problems right now.

>It would actually be a sort of cool tracking feature if it were something
>like X-Sender, but when it's Sender, a lot of mail programs conclude that
>it overrides From and Reply-To.  (I have a lot of trouble with people on
>some Windows-based email package sending replies to my "Sender" address,
>too.)

Program that do that (prefer "Sender:" to "Reply-To:" or "From:" for
the purpose of replies) are badly broken.  But that is not your
problem, which relates more to the distinction between administrative
responsibility and authorship.

 -NWR

Re: Is this a bug?

[Neil W Rickert]

[EMAIL PROTECTED] (Peter Seebach) wrote:

>In my headers, you will see a field called "Sender".  I didn't add this field.

It's not a bug.  It's a feature.

>I don't really object to it... but the Lsoft "listserv" mailing list package
>does.  Whenever there's both a From: line *and* a "Sender:" line, listserv
>concludes that the Sender: line is authoritative.

What does "authoritative" mean here?

Quite apart from the "From:" header and any "Sender:" header, there
is the information transferred in the SMTP "MAIL From:" command,
typically referred to by email gurus as the "envelope sender".  The
envelope sender is likely to be the same as is in the "Sender:"
header.  It is more likely that the listserve package is using the
envelope sender than that it is using the "Sender:" header.

According to the standards, the envelope sender is where to send
error messages related to this mail.  The contents of the "From:"
header (or a "Reply-To:" header if there is one) indicates where
ordinary replies to the message should be sent.

>   Unfortunately, it's wrong;
>my "From" address is my "real" email address, the "Sender" address (obviously)
>changes whenever I move from one machine to another.

>Where did "Sender" come from?  Is there an RFC discussing what it's for?

See RFC2822 (or RFC822, the predecessor to RFC2822).

>I notice that in NMH, this is suppressible with "draft_from" masquerading.
>So, I assume it's now considered optional.  Any history on this?

The ability to override this in nmh is a recognition that, in our
current complex world the value automatically determined on your
computer system might be invalid or inappropriate, due to the
complexity of today's email world, dynamic IP assignments, the use of
private hostnames on private networks that connect to Internet, etc.

 -NWR

Re: Question on compatibility of nmh mail messages with RFC822

[Neil W Rickert]

Jon Steinhart <[EMAIL PROTECTED]> wrote:

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

RFC822 defines what goes out over the network.  It does not define what will
be the message format in a user mailbox.

With most unix email software, line termination is converted to CR-LF
on sending the message.  The receiving software turns the message
back into the unix NL line termination.

For mail received with a single LF in a header, that LF would be
treated as a unix NL (it's the same character), and the header might
then look broken.  A single CR is probably unaffected by most unix
email software.  Practically speaking, problems from this are rare or
non-existent.

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

Both "sendmail" and the version of "mail.local" distributed with the
current sendmail handle NUL correctly.  I have (once) received a
message with NUL characters.  MH, and most other unix software,
bungles this because of the problem you mention with the C string
functions.

This is usually not a serious problem in practice.  But mostly we
won't notice, since the NULs will disappear from our mail.

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

Certainly "sendmail" does conversions between network line termination
and unix line termination.  I would assume that most other MTAs
do likewise.

 -NWR

Re: Error message correctly

[Neil W Rickert]

"BDAVIDS/Goodys" <[EMAIL PROTECTED]> wrote:

>Here is the output again, this time with the error message.

>No suffix list.
>   for subdir in h config sbr zotnet mts uip etc man; do \
> (cd $subdir && make CC='cc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H'
>CFLAGS='-O' LDFLAGS='-s' LIBS=''  prefix='/usr/local/nmh' exec_prefix
>='/usr/local/nmh' bindir='/usr/bin'  etcdir='/etc' libdir
>='/usr/local/nmh/lib' mandir='/usr/share/man'  mailspool='/var/mail'
>sendmailpath='/usr/ucblib/sendmail'  default_editor='prompter'
>default_pager='/usr/bin/more' all) || exit 1; \
>   done
>   for subdir in mts tws mf bboards; do \
> (cd $subdir && make CC='cc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H'
>CFLAGS='-O' LDFLAGS='-s' LIBS=''  prefix='/usr/local/nmh' exec_prefix
>='/usr/local/nmh' bindir='/usr/bin'  etcdir='/etc' libdir
>='/usr/local/nmh/lib' mandir='/usr/share/man'  mailspool='/var/mail'
>sendmailpath='/usr/ucblib/sendmail'  default_editor='prompter'
>default_pager='/usr/bin/more' all) || exit 1; \
>   done
>   for subdir in smtp; do \
> (cd $subdir && make CC='cc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H'
>CFLAGS='-O' LDFLAGS='-s' LIBS=''  prefix='/usr/local/nmh' exec_prefix
>='/usr/local/nmh' bindir='/usr/bin'  etcdir='/etc' libdir
>='/usr/local/nmh/lib' mandir='/usr/share/man'  mailspool='/var/mail'
>sendmailpath='/usr/ucblib/sendmail'  default_editor='prompter'
>default_pager='/usr/bin/more' all) || exit 1; \
>   done
>   cc -s -o ali ali.o aliasbr.o ../config/version.o
>../config/config.o ../sbr/libmh.a ../mts/smtp/libsmtp.a ../zotnet/libzot.a

>Undefined   first referenced
> symbol in file
>gethostbyname   ../zotnet/libzot.a(mts.o)
>UX:ld: ERROR: ali: fatal error: Symbol referencing errors. No output
>written to ali
>*** Error code 1 (bu21)

>make: fatal error.
>*** Error code 1 (bu21)

>make: fatal error.

I would guess that you have to specify a library (maybe '-lnsl') for
the compile.  You could try passing that as an argument
to 'config'.

 -NWR

Re: Path to SASL shared library now saved in executables

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:

>> (And my vote is to call the next release 1.1).

>I guess the SASL addition may warrant a jump out of the '1.0.x's.  What do
>others think?

It sound ok to me.

Incidently, if you want some "Date:" headers for testing, I can
easily grep out a couple of thousand from sites all over the world.

 -NWR

Re: Y2K problem.

[Neil W Rickert]

Shantonu Sen <[EMAIL PROTECTED]> wrote:

>>  webproxy Digest Tuesday, 23 Jan 19?1
>>  Volume 1 : Issue 2


>Neil, I just verified the problem. Can you try the patch attached?
>Also, you can try checking out the latest CVS version from
>http://www.mhost.com/nmh/cvs.html

Wow.  That was quick and simple.  Thanks.

The same change also works for MH-6.8.4.

>Index: etc/digestcomps
>===
>RCS file: /cvs/nmh/etc/digestcomps,v
>retrieving revision 1.1
>retrieving revision 1.2
>diff -r1.1 -r1.2
>6c6
>< %{digest} Digest %(weekday{date}), %2(mday{date}) %(month{date}) 
>19%02(year{date})
>---
>> %{digest} Digest %(weekday{date}), %2(mday{date}) %(month{date}) %(year{date})


 -NWR

Y2K problem.

[Neil W Rickert]

   forw -digest webproxy sequence

gives a message that begins:

From: webproxy-Request
To:   webproxy Distribution: dist-webproxy;
Subject:  webproxy Digest V1 #2
Reply-To: webproxy

webproxy Digest Tuesday, 23 Jan 19?1
Volume 1 : Issue 2

Today's Topics:

Note the "19?1".

The digestcomps file uses the nmh date function, which I presume is
broken.

 -NWR

Re: corrupt `mhpath +`/context file

[Neil W Rickert]

Simon Burge <[EMAIL PROTECTED]> wrote:

>Hi,

>I use procmail and rcvstore to automatically sort my incoming mail, and
>twice in the last month I've had my context file get corrupted overnight
>and all following mail got dropped on the floor.  From my procmail log
>file, I see entries like:

>   rcvstore: eof encountered in field "904"
>   rcvstore: context is poorly formatted

But why is 'context' being updated?

Maybe you need to put

mark: -public

in your .mh_profile file.  Then the unseen sequence information
should be kept in the file '.mh_sequences' in the mail folder.  It
that is corrupted, nothing important is lost (other than your unseen
sequence).  The worst I have ever seen is an occasional message
failing to be added to the unseen sequence.

 -NWR

Re: slocal problem

[Neil W Rickert]

"Simon Butler" <[EMAIL PROTECTED]> wrote:

> i just installed redhat 6.2 and now i get a message
> "slocal service unavailable" when i try using my
> trusty .forward setup. is there a switch i need to 
> turn somewhere?

Your error message is incomplete.  Most likely this is the
'smrsh' problem:

http://www.sendmail.org/faq/section3.html#3.34

 -NWR

Re: [Fwd: Re: Questions about IMAP and sequences]

[Neil W Rickert]

Are we making this too complex?

If we really wanted to use IMAP, we wouldn't be using 'nmh'.

I can see two possible roles for IMAP for the dedicated 'nmh' user:

  (1)   As a pipe, to download messages into your nmh folders.  You
would really be using it much as you use POP3.  You might
want IMAP support either because your ISP does not support
POP3, or because support for IMAP is better.  As an example
of the latter, your ISP might support some sort of encrypted
authentication for IMAP, but only support plain text
passwords sent over the wire for POP3.

  (2)   When away from your main system, you might want to be able to
use IMAP to access your nmh folders from a remote site.

It seems to me that neither of the above require fully featured
support for nmh commands over imap.

 -NWR

Re: [Fwd: Re: Questions about IMAP and sequences]

[Neil W Rickert]

Jerry Peek <[EMAIL PROTECTED]> wrote:
>On 11 September 2000 at 15:01, "Dan Harkless" <[EMAIL PROTECTED]> wrote:
>> multiple users sharing a single nmh folder (with unique sequences) has to be
>> a pretty darn rare situation

>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.  For instance, I've done that in two different companies
>where I worked in groups that used MH for bug tracking and etc.  We'd
>have central folder(s) of bug reports that everyone accessed (and had
>their own current message, sequences of messages they were working on,
>etc.).  We could use "anno" to make annotations that everyone could see
>(like assigning a bug and tracking its state).  We could use the "mark"
>command to maintain our own sequences (by priority, "do today", etc.).
>"pick" was great for searching bugs and finding out who was working on
>which bugs.  We had a central "bin" directory of scripts to make this
>easier -- and, of course, individual workers could write their own
>scripts.  A central maintainer actually owned the bug folders, inc'ed
>new reports into them, refiled messages into archive folders when a bug
>was fixed, and so on.  (Directory modes were set so only the maintainer
>could move messages out of the folders, but group-write file permissions
>let everyone in the group make annotations on the messages.)  Etc. etc.

That brings up another point (perhaps a bug?)

Msg-Protect: 664

(from my '.mh_profile') is ignored on "Fcc:".  Thus if a folder
is shared between users, messages recorded by "Fcc:" are not
shareable -- they get 600 permissions, which is probably the compiled
default Msg-Protect).

Likewise, if 'refile' of a message crosses partition boundaries,
so that the file must be copied, the refile message does not
honor Msg-Protect, and does not preserve the original
message filemode.  It apparently gets the original filemode masked
by the umask.

Both of these problems would hinder sharing a folder.  Incidently, MH
appears to have the same problems, so this is not new to nmh.

Perhaps the existence of these bugs is evidence that Dan is right in
his opinion that shared folders are rarely used.  For me the bugs are
only a minor inconvenience.  I used shared folders, but I share them
with myself (administrative account and personal account).

 -NWR

Re: Off Topic: Text/ascii mh reader

[Neil W Rickert]

"J. W. Ballantine" <[EMAIL PROTECTED]> wrote:

>Sorry for this off topic question, but I thought this would be a good place
>to get some collective wisdom.  The organization I work in is basically
>a vi, berkely mail group of people whom our system administrator would
>like to convert to (n)mh users.  The issue is to provide them with a
>text-based/curses interface that can be used over a dial-up/telnet window.
>(Since the large majority are vi, an emacs based solution is not a viable
>answer.)  I've tried mutt, but the issue there is that it rewrites all
>the messages when you change to another folder (at least as far as I can tell).

>Are there any other text-based/curses readers that handle mh style mail
>folders that anyone can suggest.

I am having trouble understanding the question.

I read your mail with the 'show' command, which is part of 'nmh'.  I
have defined my 'showproc' to be 'less', since I prefer that to the
default.  I am using the 'repl' command to reply.  It invokes the
'vi' editor.

Yes, I sometimes use 'exmh' for an X-windows interface.  But plain
nmh would seem to already provide what you want.

 -NWR

Re: rcvdist security question

[Neil W Rickert]

"Simon Butler" <[EMAIL PROTECTED]> wrote:

>the new company i've just started at have told me
>i cant use a .forward file to foward mail to my
>home account when i'm out of the office due to
>security concerns. as an alternative i have
>proposed i use rcvdist instead. does anyone
>know if this is viewed as a security issue by
>sysAdmins in the same way the .forward method is.

>also, what is the .forward security concern?

Presumably the concern is with possibly sensitive internal
information being sent outside (to your home machine).

 -NWR

Re: mh to pine

[Neil W Rickert]

Yoseff Francus <[EMAIL PROTECTED]> wrote:

>Any utility out there to let me combine nmh files to a file that pine can
>read?

You should be able to use 'packf' to combine nmh messages into a
standard unix mailbox.  Also, pine probably has a way to directly
access mh mail folders.

 -NWR

MAN pages bug.

[Neil W Rickert]

This happens on solaris:

 2> man mts.conf
 windex entry incorrect:  mts.conf(5) not found.
 No manual entry for mts.conf.

It is fixed by

echo ".so man5/mh-tailor.5" > mts.conf.5

done in the man5 directory.  We need to add 'mts.conf.5' as a
reference sourcing mh-tailor.5.

 -NWR

Re: nmh new mail notification

[Neil W Rickert]

"Simon Butler" <[EMAIL PROTECTED]> wrote:

>* - ^ R /usr/bin/rcvtty -nobell*

The entry I am using is:

default - ^ R  "/opt/nmh/lib/rcvtty -biff -nobell"

The different paths are system specific, so ignore that.  The '-biff'
should not matter for what you are doing.

I'm not sure whether the full command has to be quoted.  The examples
I have seen quoted it.  I don't know what is the trailing '*' on your
entry.

In another message, Simom asked:

>also do you happen to know what entry i should have in the
>.Xdefaults to get the +ut set for every xterm that gets 
>started?

I turn it off with the line

XTerm*utmpInhibit:True

I presume you would change the "True" to "False", although I
thought that was the default.  Command line parameters should
overrule this.

 -NWR

Re: nmh new mail notification

[Neil W Rickert]

"Simon Butler" <[EMAIL PROTECTED]> wrote:

> i been fiddling with this for a while now and have
> not been able to get it to fly so i thought i'd ask
> the experts.

> i'd like to get somekind of notice when i receive mail
> so i have this in my .maildelivery file

>* - ^ R /usr/bin/rcvtty -nobell*

>but this doesn't seem to do anything.

>according to the jerry peaks book rcvtty will send
>a message to all shells listed in my /var/run/utmp
>file, which doesnot seem to be ascii file so i can't
>see which shells are registered.

The 'who' command lists this.

>one possible problem is that when i run 'who' i get

>%who
>simontty1 Apr 20 18:22

>but there are 4 xterms up so i'm not sure why they
>don't get mentioned in the who output.

That depends on how you start xterm.  The '-ut' and '+ut' operands
can set whether an entry is made in utmp.  (Offhand, I don't remember
which is which).  Also your .Xdefaults can turn this on or off.

>%mesg
>is y

That only looks at the permissions of your tty.

 -NWR

Re: unseen stopped working?

[Neil W Rickert]

Scott Lipcon <[EMAIL PROTECTED]> wrote:

>I think I fixed it - I created a .mh_sequences file with :

>unseen:

>in it (creating an empty sequence, instead of an empty .mh_sequences
>file) and that seems to have worked.  I still don't understand where my
>sequences went before, or why they weren't recreated properly when I
>removed .mh_sequences.  

Sometimes sequences are put in Mail/context.  I'm not sure of the
circumstances when this happens.  Perhaps 'exmh' doesn't look there.

 -NWR

Re: Forwarding a file with attachments

[Neil W Rickert]

"Sullivan N. Beck" <[EMAIL PROTECTED]> wrote:

>I don't know if I'm missing something simple here... but how do you
>forward a file with attachements and have the attachments still in
>correct MIME?

>The "forw -mime" doesn't seem to do anything useful (perhaps I don't
>understand what it's for, but it just creates a message with a line
>  #forw [forwarde message] +/my/home/dir/Mail/inbox 79
>I'm not sure what the function of this is.

At the 'whatnow' prompt, use

edit mhn

and the details will be filled in.

Check 'man mhn' for more information on this.

 -NWR

Re: Outgoing mail not saved

[Neil W Rickert]

John Summerfield <[EMAIL PROTECTED]> wrote:

>I was disconcerted (putting it mildly) when I discovered my outgoing mail 
>wasn't being saved.

Copy the 'components' file to your $HOME/Mail directory.  Edit it,
and add an "Fcc:" line.  The components file is in the 'etc'
directory of 'nmh'.

You can do the same with forwcomps 'forwcomps' and 'replcomps'.

 -NWR

No Subject

[Neil W Rickert]

I sent this to nmh-bugs.  Just in case that is a black hole with
no readers, I am also forwarding it to nmh-workers.

 -NWR

--- Forwarded Message

Date:Mon, 06 Mar 2000 12:04:21 -0600
From:Neil W Rickert <[EMAIL PROTECTED]>
To:  [EMAIL PROTECTED]
Subject: Re: Bug in msh.c 

This is a multipart MIME message.

- --==_Exmh_-15175783520
Content-Type: text/plain; charset=us-ascii

Neil W Rickert <[EMAIL PROTECTED]> wrote:

>I finally tracked down the problem in msh that was causing errors
>whenever I tried to examine a 'mmdf' style mailbox.

>It turns out that not enough memory was being allocated with
>calloc(), causing memory pointers to be overwritten and corrupted.

>Patch attached.

On second thoughts, use the patch attached to this message rather
than the earlier one.  It should be better for future maintenance,
although it is equivalent in effect.

 -NWR


- --==_Exmh_-15175783520
Content-Type: text/plain ; name="patch"; charset=us-ascii
Content-Description: patch
Content-Disposition: attachment; filename="patch"

- --- msh.c 2000/03/06 16:41:18 1.1
+++ msh.c   2000/03/06 17:54:28
@@ -754,7 +754,7 @@
 if (!(mp = (struct msgs  *) calloc ((size_t) 1, sizeof(*mp
padios (NULL, "unable to allocate folder storage");
 
- -if (!(mp->msgstats = calloc ((size_t) 1, msgp + 3)))
+if (!(mp->msgstats = calloc ((size_t) msgp + 3, sizeof(*(mp->msgstats)
padios (NULL, "unable to allocate message status storage");
 
 mp->hghmsg = msgp;

- --==_Exmh_-15175783520--


--- End of Forwarded Message

Re: $USERPLUS / $USER_EXTENSION (was Re: boolean type, DIFFERENCES...)

[Neil W Rickert]

Scott Blachowicz <[EMAIL PROTECTED]> wrote:
>Dan Harkless <[EMAIL PROTECTED]> wrote:

>> Here's my ChangeLog entry:

>>  * Changed the new "plussed_user" option to mts.conf's
>>  "masquerade:" to "username_extension" after getting feedback from
>>  qmail users, who use '-' as a separator rather than '+'.  Removed
>>  checking of $USERPLUS variable.  Now check $USERNAME_EXTENSION,
>>  which needs to include the appropriate separator for your MTA
>>  ('-', '+', or whatever) as its first character.

>FYI...Postfix calls that variable "recipient_delimiter" in its
>configuration file and it defaults to '+'.  So, what happens if
>USERNAME_EXTENSION isn't set, but "masquerade:" includes
>"username_extension"?

At least in its original form, if the variable is not set then the
username is used unchanged.  It is assumed this will be the most
typical behavior.

I am assuming that Dan's changes don't alter this.

 -NWR

Re: $USERPLUS / $USER_EXTENSION (was Re: boolean type, DIFFERENCES...)

[Neil W Rickert]

"Dan Harkless" <[EMAIL PROTECTED]> wrote:


>Dan Harkless <[EMAIL PROTECTED]> writes:
>> Okay, I ended up going with an environment variable called
>> $USERNAME_EXTENSION.  I didn't like $USER_EXTENSION because it sounds like
>> it describes the generic concept of an extension (to a software package) by
>> a user.  With $USERNAME_EXTENSION, it's much more obvious what it's for.

>> Here's my ChangeLog entry:

>>  * Changed the new "plussed_user" option to mts.conf's
>>  "masquerade:" to "username_extension" after getting feedback from
>>  qmail users, who use '-' as a separator rather than '+'.  Removed
>>  checking of $USERPLUS variable.  Now check $USERNAME_EXTENSION,
>>  which needs to include the appropriate separator for your MTA
>>  ('-', '+', or whatever) as its first character.

>BTW, while testing $USERNAME_EXTENSION just now I had an unexpected
>failure.  I tried to 'inc' my mail but it wasn't working because it was
>looking for /var/spool/mail/dan$USERNAME_EXTENSION.  

>Did you intend this, Neil?  It's a consequence of appending the environment
>variable while in getuserinfo(), which controls nmh's global idea of what
>the username is.

No, I didn't intend that, although I'm not really surprised.

Using '+detail' in an address is mainly useful if you use 'slocal' or
'procmail' to sort the mail into folders based on the '+detail'.  In
that case inc is not involved.

>I know with sendmail this is undesirable, because the "plussed user" email
>addresses definitely correspond to a single mailbox.  I'm still a little
>fuzzy on qmail's "user-extensions", though.  Do they (always? usually?)
>correspond to a single maildrop?

>If so, I should probably reimplement $USERNAME_EXTENSION to only get tacked
>onto the account name in the "From:" line that post generates.

Probably a good move anyway.

>qmail users, please let me know what you think.

>---
>Dan Harkless   | To prevent SPAM contamination, please 
>[EMAIL PROTECTED]  | do not post this private email address
>SpeedGate Communications, Inc. | to the USENET or WWW.  Thank you. 


 -NWR

Re: $USERPLUS / $USER_EXTENSION (was Re: boolean type, DIFFERENCES...)

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:

>Okay, I ended up going with an environment variable called
>$USERNAME_EXTENSION.  I didn't like $USER_EXTENSION because it sounds like
>it describes the generic concept of an extension (to a software package) by
>a user.  With $USERNAME_EXTENSION, it's much more obvious what it's for.

>Here's my ChangeLog entry:

>   * Changed the new "plussed_user" option to mts.conf's
>   "masquerade:" to "username_extension" after getting feedback from
>   qmail users, who use '-' as a separator rather than '+'.  Removed
>   checking of $USERPLUS variable.  Now check $USERNAME_EXTENSION,
>   which needs to include the appropriate separator for your MTA
>   ('-', '+', or whatever) as its first character.

Sounds reasonable enough.

 -NWR

Re: $USERPLUS / $USER_EXTENSION (was Re: boolean type, DIFFERENCES...)

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:

>"Chris Garrigues" <[EMAIL PROTECTED]> writes:
>> So clearly it provides for overriding the name, but not for simply adding
>> an extension.  I think adding this functionality to nmh would be useful.

>> I would then also be able to repackage my spam-proof addresses in a way 
>> that I wouldn't be embarrassed to share with others.

>Okay.  Well, I'll wait to hear from Neil Rickert about how sacred /
>widely-used the $USERPLUS variable is, and whether he would mind having to
>put his own '+' in a $USER_EXTENSION variable.

I should have added this to my previous comment:

I don't see any big problems with changing to $USER_EXTENSION, and
including the '+'.  But I also don't see any big problems with
dropping the whole thing and using the user specified "From:" as in
1.0.3.  Again, John might have a different opinion.

 -NWR

Re: $USERPLUS / $USER_EXTENSION (was Re: boolean type, DIFFERENCES...)

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:

>"Chris Garrigues" <[EMAIL PROTECTED]> writes:
>> So clearly it provides for overriding the name, but not for simply adding
>> an extension.  I think adding this functionality to nmh would be useful.

>> I would then also be able to repackage my spam-proof addresses in a way 
>> that I wouldn't be embarrassed to share with others.

>Okay.  Well, I'll wait to hear from Neil Rickert about how sacred /
>widely-used the $USERPLUS variable is, and whether he would mind having to
>put his own '+' in a $USER_EXTENSION variable.

Sorry for slow replying.

I am copying John Beck, who has experimented with this for exmh.

The uses that I know of for this should be easily modifiable to use
the support for "From:" that is already in 1.0.3.  Thus I don't have
any particularly strong feelings about it.  I want to know what John
thinks, however.

When I started using these changes for nmh, I provided equivalent
changes for classic MH.  But with the security problems, MH users
should switch to nmh anyway, so I don't see this as a serious
problem.

Unlike the 1.0.3 changes, I did deliberately use different bits of
mmailid, so that an adminstrator could selectively enable one option
or the other (or both).  I would like to suggest that this still be
considered.  On systems with a 'chfn' command, it may be a mistake
to always interpret an '@' in the gecos field as being intended
for 'nmh' addresses.

 -NWR

Re: building nmh-1.0.3 on Solaris

[Neil W Rickert]

"Olivier Lecarme" <[EMAIL PROTECTED]> wrote:

>   Strange.  I build on solaris 7 (sparc) using gcc-2.8.1.  I had no
>   corresponding problem.

To add to this, I just build on solaris 7/x86 without difficulty.

>I tried to build again the libraries, by doing a "make clean" before a
>new "make". I note the following message when building libmh.a :

Try
  make distclean
  ./configure
  make

 -NWR

Re: building nmh-1.0.3 on Solaris

[Neil W Rickert]

"Jacqueline Lecarme" <[EMAIL PROTECTED]> wrote:

>I'm trying to build nmh-1.0.3 on a Solaris machine :

>SunOS ling 5.7 Generic_106541-02 sun4u sparc

>I'm using gcc 2.8.1, and I ran configure without any parameter. I get
>the following error :

Strange.  I build on solaris 7 (sparc) using gcc-2.8.1.  I had no
corresponding problem.

When configuring, I used

  --prefix=/opt/nmh --enable-nmh-pop

After configuring, I edited 'config.h' to change the "," to "#"
for BACKUP_PREFIX .  Apart from that there were no changes.

System:

SunOS ux 5.7 Generic_106541-08 sun4d sparc SUNW,SPARCserver-1000

Judging by your system level, you probably should install Sun
patches.  But I think that has nothing to do with your problem.
It almost looks as if the libraries were not properly built.

>make[1]: Entering directory `/space/src/MH/nmh-1.0.3/uip'
>gcc -s -o ali ali.o aliasbr.o ../config/version.o ../config/config.o ../sbr/libmh.a 
>../mts/smtp/libsmtp.a ../zotnet/libzot.a   -lsocket -lnsl 
>Undefined  first referenced
> symbolin file
>context_findali.o
>path../sbr/libmh.a(context_read.o)
>m_mailpath  ../config/config.o
>advise  ../sbr/libmh.a(ambigsw.o)
>ssequal ../sbr/libmh.a(print_sw.o)
>m_maildir   ../sbr/libmh.a(context_read.o)
>adios   ali.o
>admonish../sbr/libmh.a(readconfig.o)
>copy../sbr/libmh.a(concat.o)
>doneali.o
>getcpy  ali.o
>ld: fatal: Symbol referencing errors. No output written to ali
>make[1]: *** [ali] Error 1
>make[1]: Leaving directory `/space/src/MH/nmh-1.0.3/uip'
>make: *** [all-recursive] Error 1

>Since I did not subscribe to the list nmh-workers, please reply me
>directly to the address [EMAIL PROTECTED]

>Thanks in advance !

>-- 

>   Olivier Lecarme


 -NWR

Re: problems with inc when mail body has lines starting with From

[Neil W Rickert]

"J.R. van Ossenbruggen" <[EMAIL PROTECTED]> wrote:

>Hi, (this is probably a FAQ, could not find it though...)

>I'm having problems with email messages where the body contains lines
>that start with the word "From".  Inc is splitting these messages up.
>Is this a bug in inc or am I doing something wrong?  Could anybody
>give me a hint?

The lines are probably starting "From ".  You are doing something
wrong.  Your mailbox is not supposed to have such lines.

>Thanks,

>   Jacco

>PS: I'm currently running Redhat 6.1, nmh-1.0-2. 
>The problem does not occur when using inc on IRIX (MH 6.8.3).

Most likely the MH 6.8.3 has Casper Dik's patch to use
"Content-Length:" for identifying the end of a message.  This is
correct for SysV, such as IRIX.  But linux does not use
"Content-Length:".  Instead, the mail delivery agent (usually
procmail) prepends ">" to any line beginning with "From ", so that
the only "From " lines are the message separators.

You probably copied the mailbox from IRIX to linux.  You should not
do that, since the two systems do not have completely compatible
mailbox formats.

 -NWR

Re: nmh-1.0.2 rcvstore

[Neil W Rickert]

Huy Le <[EMAIL PROTECTED]> wrote:

>I'm not sure if this is a configuration problem or an actual bug,
>but for some reason, my invocations of rcvstore are leaving the From line
>at the top of each email intact (in mail-drop format),
>rather than "incorporating" into MH format, i.e. splitting the line
>into "Delivery-Date" and "Return-Path" fields.

>This used to work for me but no longer does.
>But going back to my MH 6.8.3, that rcvstore acts just like nmh.
>So I'm confused.

>Any help would be appreciated.

The "Delivery-Date:" works for me using nmh, but not with mh.

I'm not sure whether it s 'rcvstore' that adds the header, or whether
it is 'slocal' before in invokes 'rcvstore'.

 -NWR

Re: nmh-1.0.2 rcvstore

[Neil W Rickert]

Huy Le <[EMAIL PROTECTED]> wrote:
>On Wed, 26 Jan 2000 17:23:39 CST, Neil W Rickert wrote:

>> The "Delivery-Date:" works for me using nmh, but not with mh.

>> I'm not sure whether it s 'rcvstore' that adds the header, or whether
>> it is 'slocal' before in invokes 'rcvstore'.

>That's it!!
>It's slocal that's changing the headers, not rcvstore.
>So the reason it doesn't work for me anymore is because I switched to
>procmail.

>So I guess slocal and rcvstore are not quite orthogonal,
>as the rcvstore man page would suggest; i.e. you lose something by using
>procmail instead.

>Could this be a design bug that goes back to the old MH?

I believe the technical term is "feature" rather than "bug".

 -NWR

Re: ``y2k'' patch

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:
>Neil W Rickert <[EMAIL PROTECTED]> writes:
>> >> This patch uses windowing, so it may be subject to stoopid patent claims
>> >> in some countries :-)

>> >Are you serious??  What countries have patent claims like that?  Never heard
>> >of this issue...

>> I expect that he is referring to the good old U.S.A.  Apparently the
>> patent office has awarded a patent to some sort of windowing methods
>> for y2k.  

>That's insane!  Who are the scum that patented that?  Unisys or somebody?

It wasn't unisys.  I don't remember who.  NPR had a story on it on
Monday, but there is not enough detail on their web page to track
down the details.

>Are they at least trying to get other companies to license the patents or
>are they sticking to their exclusive use rights and saying that all other
>software will just have to remain Y2K-noncompliant???

I gather they are trying to extract license payments.  I gather they
are being widely ignored, and that the patent office has ordered a
review.

>> I haven't been able to find the full details of what is
>> patented.  I guess I am curious as to whether the windowing I used
>> for dates in 1983 will be retroactively declared to violate that
>> recent patent.

>Out of curiosity, what kind of windowing were you doing in 1983?  A 1-digit
>year that had wrapped around or something?

I was wanting to represent the date as a 32 bit binary number, as the
number of days since the presumed (but non-existent) year ,
extrapolating backwards with the Gregorian calendar.  So if the two
digit year given by the operating system date function was <= 25, I
took it to 2000 plus the year.

 -NWR

Re: ``y2k'' patch

[Neil W Rickert]

"Dan Harkless" <[EMAIL PROTECTED]> wrote:
>Simon Burge <[EMAIL PROTECTED]> writes:

>> It seems that some MUA's didn't handle y2k very well - ELM seems to be
>> one of them, and Ultrix's DXmail (based on MH!).  I've got a few emails
>> this month that look like:

>>  575   Jan 00  Xx Xxxx   3603  ...
>> and
>>   22+  Jan 00  Xxx X 1771  ...

>> The first has "15 Jan 100" as the date and the second has "19 Jan 00" as
>> the date.  The following works around this so that scan, show, sortm, etc
>> work ok.

>> This patch uses windowing, so it may be subject to stoopid patent claims
>> in some countries :-)

>Are you serious??  What countries have patent claims like that?  Never heard
>of this issue...

I expect that he is referring to the good old U.S.A.  Apparently the
patent office has awarded a patent to some sort of windowing methods
for y2k.  I haven't been able to find the full details of what is
patented.  I guess I am curious as to whether the windowing I used
for dates in 1983 will be retroactively declared to violate that
recent patent.

 -NWR

Re: Locking in rcvstore

[Neil W Rickert]

Jonathan Ryshpan <[EMAIL PROTECTED]> wrote:

>I want to sort my incoming email using procmail and rcvstore; I've noticed
>a number of things:

>(1) rcvstore doesn't lock the .mh_sequences files, or anything else.  This
>should be pretty dangerous; the procmail man pages warn that bad things
>can happen, since procmail doesn't lock mh folders.  Nevertheless ...

What is so dangerous?  You would lose your sequences.  Personally, I
don't consider the data in '.mh_sequences to be so vital that it
worries me.  Incidently, I have never had a problem in practice, and
I have slocal, rcvstore handle almost all of my mail.

As far as I know, there isn't a problem with the message files
themselves, since file creation is atomic (except for possible NFS
problems).

>(2) MAIL.FILTERING doesn't say anything about this problem, so maybe it's
>theoretical rather than practical.

You could reduce the risk, at least in a sendmail setup, by having
slocal mail handled only on queue runs.  That would tend to
serialize.  With recent versions of sendmail, configuring "O
HoldExpensive=True" should do the trick, since the prog mailer is
expensive by default.  I don't bother, since I think the risk is
small and the damage expected is minor.

>(3) It should be pretty easy to add .mh_sequences file locking.  All you
>should have to do is open the .mh_sequences file with a lkfopen rather
>than an fopen (plus a few extra changes).  Nevertheless ...

That is not nearly as easy as it looks.  The mail might be delivered
on one system, and at the same time be read from another system over
nfs.  Both may touch the unseen sequence.

>(4) Nobody has done it, despite it's having been in the TODO list for some
>time.  So maybe it's not as easy as it looks.

>Any comments or suggestions?

>Thanks:
>   Jonathan Ryshpan <[EMAIL PROTECTED]>

>   And God fulfills himself in many ways
>   Lest one good custom should corrupt the world.
>   -- Tennyson


 -NWR

Re: nmh 1.0.2 build on Solaris 2.7

[Neil W Rickert]

I had no comparable problem on Solaris 2.7 (sparc).  However, I was
using gcc-2.8.1.

David Hoki <[EMAIL PROTECTED]> wrote:

>Solaris 2.7, gcc 2.95.1
>./configure --prefix=/usr/local

>nmh configuration
>-
>nmh version   : 1.0.2
>target os : sparc-sun-solaris2.7
>compiler  : gcc
>compiler flags: -O2
>linker flags  : -s
>source code location  : .
>binary install path   : /usr/local/bin
>libary install path   : /usr/local/lib
>config files install path : /usr/local/etc
>man page install path : /usr/local/man
>transport system  : smtp
>default editor: /usr/bin/vi
>default pager : /usr/bin/more


>In the "sbr" directory, everything builds without any warnings or errors until
>libmh.a is created. The command and output are as follows:

>if test x != x -a x = x ; then \
>   -static -c -o libmh.a add.o addrsbr.o ambigsw.o atooi.o brkstring.o 
>check_charset.o closefds.o concat.o context_del.o context_find.o 
>context_foil.o context_read.o context_replace.o context_save.o copy.o copyip.o 
>cpydata.o cpydgst.o discard.o done.o error.o fdcompare.o folder_addmsg.o 
>folder_delmsgs.o folder_free.o folder_pack.o folder_read.o folder_realloc.o 
>gans.o getans.o getanswer.o getarguments.o getcpy.o getfolder.o fmt_addr.o 
>fmt_compile.o fmt_new.o fmt_rfc2047.o fmt_scan.o lock_file.o m_atoi.o 
>m_backup.o m_convert.o m_draft.o m_getfld.o m_gmprot.o m_maildir.o m_name.o 
>m_scratch.o m_tmpfil.o makedir.o path.o peekc.o pidwait.o pidstatus.o 
>print_help.o print_sw.o print_version.o push.o putenv.o pwd.o refile.o 
>remdir.o r1bindex.o readconfig.o seq_add.o seq_bits.o seq_del.o seq_getnum.o 
>seq_list.o seq_nameok.o seq_print.o seq_read.o seq_save.o seq_setcur.o 
>seq_setprev.o seq_setunseen.o showfile.o signals.o smatch.o snprintb.o 
>ssequal.o strcasecmp.o strindex.o trimcpy.o uprf.o vfgets.o fmt_def.o 
>m_msgdef.o  ; \
>else \
>  ar cr libmh.a `lorder add.o addrsbr.o ambigsw.o atooi.o brkstring.o 
>check_charset.o closefds.o concat.o context_del.o context_find.o 
>context_foil.o context_read.o context_replace.o context_save.o copy.o copyip.o 
>cpydata.o cpydgst.o discard.o done.o error.o fdcompare.o folder_addmsg.o 
>folder_delmsgs.o folder_free.o folder_pack.o folder_read.o folder_realloc.o 
>gans.o getans.o getanswer.o getarguments.o getcpy.o getfolder.o fmt_addr.o 
>fmt_compile.o fmt_new.o fmt_rfc2047.o fmt_scan.o lock_file.o m_atoi.o 
>m_backup.o m_convert.o m_draft.o m_getfld.o m_gmprot.o m_maildir.o m_name.o 
>m_scratch.o m_tmpfil.o makedir.o path.o peekc.o pidwait.o pidstatus.o 
>print_help.o print_sw.o print_version.o push.o putenv.o pwd.o refile.o 
>remdir.o r1bindex.o readconfig.o seq_add.o seq_bits.o seq_del.o seq_getnum.o 
>seq_list.o seq_nameok.o seq_print.o seq_read.o seq_save.o seq_setcur.o 
>seq_setprev.o seq_setunseen.o showfile.o signals.o smatch.o snprintb.o 
>ssequal.o strcasecmp.o strindex.o trimcpy.o uprf.o vfgets.o fmt_def.o 
>m_msgdef.o  | tsort`  ; \
>  ranlib libmh.a  ; \
>fi 
>tsort: -: input contains a loop:

>tsort: context_find.o
>tsort: strcasecmp.o


>libmh.a appears to be created and the make continues but in 'uip' here's where 
>things bail out:

>gcc -s -o ali ali.o aliasbr.o ../config/version.o ../config/config.o 
>../sbr/libmh.a ../mts/smtp/libsmtp.a ../zotnet/libzot.a   -lsocket -lnsl
>Undefined   first referenced
> symbol in file
>context_findali.o
>path../sbr/libmh.a(context_read.o)
>m_mailpath  ../config/config.o
>advise  ../sbr/libmh.a(ambigsw.o)
>ssequal ../sbr/libmh.a(print_sw.o)
>m_maildir   ../sbr/libmh.a(context_read.o)
>adios   ali.o
>admonish../sbr/libmh.a(readconfig.o)
>copy../sbr/libmh.a(concat.o)
>doneali.o
>getcpy  ali.o
>ld: fatal: Symbol referencing errors. No output written to ali
>collect2: ld returned 1 exit status
>make: *** [ali] Error 1



 -NWR

Re: Error parsing address

[Neil W Rickert]

John Summerfield <[EMAIL PROTECTED]> wrote:

> This address has a valid domain; it should be passed on:

>post: bad address '<[EMAIL PROTECTED]>' - no sub-domain in domain-part 
>of addr
>ess (>), continuing...
>post: 1 address unparsable
>send: message not delivered to anyone

>What now? 

>The trailing dot causes DNS to not try various suffixes to the domain. 
>Theoretically, it should be quicker to resolve alum.mit.edu. than 
>alum.mit.edu

Nevertheless, the trailing '.' violates the syntax rules of
RFC822.

 -NWR

Suggested change for 1.0.3.

[Neil W Rickert]

Dan Harkless <[EMAIL PROTECTED]> wrote:

>...
>Therefore, I've upped the VERSION to 1.0.3.  Unfortunately Doug didn't do
>this just after releasing the tarball, so there was a small window when
>someone could have gotten a different 1.0.2 than most end-users have, but
>hopefully no significant changes were made after 1.0.2 went public.

Let me suggest a change for the next version -- patch attached.

The code changes are small -- most of the patch is documentation.

This is a simple change to allow a user to easily set the sender
address to user+detail, a form of address already supported by recent
sendmail versions.  I overloaded the variable mmailid in mts.conf, as
a way of giving the system administrator control over whether to
permit this.

Personally, I find this tremendously valuable.  It allows me to
easily use distinctive addresses for different mailing lists, such as
the <[EMAIL PROTECTED]> that I am using here.  This can aid in
automatically filtering incoming mail, as well as helping to identify
where the spammers got your address.

I understand that one of the exmh team has is testing exmh support
for accessing this feature.

 -NWR



--- zotnet/mts/mts.c1999/10/29 17:34:47 1.1
+++ zotnet/mts/mts.c1999/10/29 17:35:19
@@ -412,10 +412,10 @@
  * field should have the form "Full Name ".
  */
 #ifndefGCOS_HACK
-for (cp = fullname; *np && *np != (MMailids ? '<' : ','); *cp++ = *np++)
+for (cp = fullname; *np && *np != ',' && !((MMailids & 01) && (*np == '<')); 
+*cp++ = *np++)
continue;
 #else
-for (cp = fullname; *np && *np != (MMailids ? '<' : ','); ) {
+for (cp = fullname; *np && *np != ',' && !((MMailids & 01) && (*np == '<')); ) {
if (*np == '&') {   /* blech! */
strcpy (cp, pw->pw_name);
*cp = toupper(*cp);
@@ -429,15 +429,20 @@
 #endif
 
 *cp = '\0';
-if (MMailids) {
-   if (*np)
-   np++;
+if ((MMailids & 01) && (*np == '<') ) {
+   np++;
for (cp = username; *np && *np != '>'; *cp++ = *np++)
continue;
*cp = '\0';
 }
-if (MMailids == 0 || *np == '\0')
+if (!(MMailids & 01) || *np != '>' || *username == '\0')
strncpy (username, pw->pw_name, sizeof(username));
+
+if ((MMailids & 02) && (cp = getenv("USERPLUS")) && *cp &&
+  strlen(username) + strlen(cp) < sizeof(username) - 1) {
+   strcat(username,"+");
+   strcat(username,cp);
+}
 
 if ((cp = getenv ("SIGNATURE")) && *cp)
strncpy (fullname, cp, sizeof(fullname));
--- man/mh-tailor.man   1999/10/29 21:23:41 1.1
+++ man/mh-tailor.man   1999/10/29 21:29:06
@@ -101,9 +101,9 @@
 .ti -.5i
 mmailid: 0
 .br
-If this is non-zero, then activate support for MMailids (username
-masquerading).  When this is activated, \fInmh\fR will check if the
-pw_gecos field in the password file has the form
+If this is 1 (or any odd value), then activate support for MMailids
+(username masquerading).  When this is activated, \fInmh\fR will
+check if the pw_gecos field in the password file has the form
 
 .ti +.5i
 Full Name 
@@ -117,6 +117,14 @@
 This facility is useful if you are using POP, and wish for messages
 that are sent by users to appear to originate from the username of
 their POP account, rather than their username on the local machine.
+
+If mmailid is 2, then activate support for generating user+detail
+sender addresses, consistent with recent versions of sendmail.  If
+this support is active, then \fInmh\fR will check whether the
+variable USERPLUS is defined in the environment.  If it is, then the
+string "+$USERPLUS" will be appended to the username.  This can be
+useful for setting distinctive sender addresses for the various
+mailings lists to which you might subscribe.
 
 .ti -.5i
 maildelivery: %libdir%/maildelivery
--- INSTALL 1999/10/29 21:17:29 1.1
+++ INSTALL 1999/10/29 21:23:00
@@ -62,9 +62,9 @@
   originated on the POP server.
 
d) "mmailid" is checked to see if nmh should do username
-  masquerading.  If the value of this field is non-zero, then
-  nmh will check if the pw_gecos field in the password file
-  has the form
+  masquerading.  If the value of this field is 1 (or any odd
+  number), then nmh will check if the pw_gecos field in the
+  password file has the form
 
   Full Name 
 
@@ -74,6 +74,19 @@
   useful if you wish messages that you send to appear to come
   from the username of your POP account, rather than your username
   on the local machine.
+
+  If the value of mmailid is 2, then nmh will check whether
+  $USERPLUS is defined in the environment.  If it is, then nmh
+  will set the sender address to userid+$USERPLUS.  This allows
+  users to send mail with sender address of the form
+  user+detail.  Most recent versions of sendmail will treat this
+  as equivalent to user for incoming mail.  Using sender
+  addresses of this form can be

Re: Bus error for msh on Solaris 7 (sparc / sun 4d).

[Neil W Rickert]

>Neil W Rickert wrote:
>>This is not a new problem.  It existed also in 1.0.
>>When I use 'msh' to read an mmdf style mailbox, such as might be
>>created with packf -mmdf, it dies on a Bus error.

>I've found a bug where it segfaults on quit under Linux. This turns
>out to be in folder_free.c, line 26: 

>free (mp->msgstats);/* free message status area   */

>msgstats is a pointer to a pointer (to an unsigned int). I suspect
>this is unrelated.

It is conceivable that memory structures used by malloc()/free() are
being corrupted somewhere, and that both problems are symptoms.

>I'll check again at work tomorrow (where I have various solaris
>systems to test on) and see if I can reproduce your bug.

>I haven't exercised msh or the mmdf code very thoroughly. It looks
>like one or both need a bit of work. I've put it on the TODO list. I
>don't think either bug will be fixed in this release, unless I just
>happen to stumble on a fix tomorrow.

I was not expecting this to hold up release of 1.0.2.  However, I
would like to see the problem corrected eventually.  I find it very
convenient to archive old mail in packf -mmdf format, and be able to
use msh on the rare occasions that I have to look at an old message.
So at present I cannot complete my switch from MH to nmh.

 -NWR

Bus error for msh on Solaris 7 (sparc / sun 4d).

[Neil W Rickert]

This is not a new problem.  It existed also in 1.0.

When I use 'msh' to read an mmdf style mailbox, such as might be
created with packf -mmdf, it dies on a Bus error.

In my experience, a Bus error is usually an alignment problem.

Here is what gdb says of the error:

gdb uip/msh core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.12 (sparc-sun-solaris2), Copyright 1994 Free Software Foundation, Inc...
Core was generated by `uip/msh /home/ux/rickert/Mail/OLD'.
Program terminated with signal 10, Bus error.
procfs (find_procinfo):  Couldn't locate pid 0
#0  0xdf5c56ac in _end ()
(gdb) where
#0  0xdf5c56ac in _end ()
#1  0xdf5c5628 in _end ()
#2  0xdf5c5544 in _end ()
#3  0xdf5b9bcc in _end ()
#4  0x4326c in m_unknown (iob=0x773f8) at m_getfld.c:572
#5  0x17274 in setup (file=0xdde4 "/home/ux/rickert/Mail/OLD") at msh.c:811
#6  0x15f68 in main (argc=2, argv=0xdd0c) at msh.c:403
(gdb)

Note that traditional MH has no comparable problem.

The line pointed to in m_getfld.c is:

pat_map = (unsigned char **) calloc (256, sizeof(unsigned char *));

   --

Does anybody have suggestions as to where I can go from here in
tracking down the problem.

 -NWR

Re: nmh snapshot

[Neil W Rickert]

>Neil W Rickert wrote:
>>Solaris 5.7 sparc.
>>Compile error appended.
>>The test for $(LIBTOOL) is broken.

>I've fixed the tests and put up a new shapshot at

><ftp://ftp.mhost.com/pub/nmh/snapshots/nmh-1.0.1-snapshot.19991027.tar.gz>

Thanks.  It built cleanly this time.

I have been testing yesterday's build (which I take it is identical
to today's apart from those tests).  No surprises so far.

 -NWR

Re: nmh snapshot

[Neil W Rickert]

>

>I'd appreciate it if everyone interested could download it and try it
>out to see if it works for you. Obviously, if it doesn't compile, let
>me know. Otherwise, look for name service errors -- failed name
>resolution and the like. I updated the method configure uses to test
>for BIND capabilities, and that might cause errors on systems I wasn't
>able to test.

Solaris 5.7 sparc.

Compile error appended.

The test for $(LIBTOOL) is broken.

I was able to get the compile to complete by replacing
the line

LIBTOOL =

with

LIBTOOL = no

in sbr/Makefile, zotnet/Makefile, mts/smtp/Makefile

for subdir in h config sbr zotnet mts uip etc man; do \
  (cd $subdir && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H'  CFLAGS='-O2' 
LDFLAGS='-s' LIBS='-lsocket -lnsl'  prefix='/opt/nmh' exec_prefix='/opt/nmh' 
bindir='/opt/nmh/bin'  etcdir='/opt/nmh/etc' libdir='/opt/nmh/lib' 
mandir='/opt/nmh/man'  mailspool='/var/mail' sendmailpath='/usr/lib/sendmail'  
default_editor='/usr/bin/vi' default_pager='/usr/bin/more' all) || exit 1; \
done
rm -f libmh.a
if test x != xno -a x = x ; then \
   -static -c -o libmh.a add.o addrsbr.o ambigsw.o atooi.o brkstring.o check_charset.o 
 closefds.o concat.o context_del.o context_find.o context_foil.o  context_read.o 
context_replace.o context_save.o copy.o  copyip.o cpydata.o cpydgst.o discard.o done.o 
error.o  fdcompare.o folder_addmsg.o folder_delmsgs.o folder_free.o  folder_pack.o 
folder_read.o folder_realloc.o gans.o  getans.o getanswer.o getarguments.o getcpy.o 
getfolder.o fmt_addr.o  fmt_compile.o fmt_new.o fmt_rfc2047.o fmt_scan.o lock_file.o  
m_atoi.o m_backup.o m_convert.o m_draft.o m_getfld.o m_gmprot.o  m_maildir.o m_name.o 
m_scratch.o m_tmpfil.o makedir.o  path.o peekc.o pidwait.o pidstatus.o print_help.o  
print_sw.o print_version.o push.o putenv.o pwd.o refile.o  remdir.o r1bindex.o 
readconfig.o seq_add.o seq_bits.o seq_del.o  seq_getnum.o seq_list.o seq_nameok.o 
seq_print.o seq_read.o  seq_save.o seq_setcur.o seq_setprev.o seq_setunseen.o 
showfile.o  signals.o smatch.o snprintb.o ssequal.o strcasecmp.o strindex!
!
!
.o  trimcpy.o uprf.o vfgets.o fmt_def.o m_msgdef.o   ; \
else \
  ar cr libmh.a `lorder add.o addrsbr.o ambigsw.o atooi.o brkstring.o check_charset.o  
closefds.o concat.o context_del.o context_find.o context_foil.o  context_read.o 
context_replace.o context_save.o copy.o  copyip.o cpydata.o cpydgst.o discard.o done.o 
error.o  fdcompare.o folder_addmsg.o folder_delmsgs.o folder_free.o  folder_pack.o 
folder_read.o folder_realloc.o gans.o  getans.o getanswer.o getarguments.o getcpy.o 
getfolder.o fmt_addr.o  fmt_compile.o fmt_new.o fmt_rfc2047.o fmt_scan.o lock_file.o  
m_atoi.o m_backup.o m_convert.o m_draft.o m_getfld.o m_gmprot.o  m_maildir.o m_name.o 
m_scratch.o m_tmpfil.o makedir.o  path.o peekc.o pidwait.o pidstatus.o print_help.o  
print_sw.o print_version.o push.o putenv.o pwd.o refile.o  remdir.o r1bindex.o 
readconfig.o seq_add.o seq_bits.o seq_del.o  seq_getnum.o seq_list.o seq_nameok.o 
seq_print.o seq_read.o  seq_save.o seq_setcur.o seq_setprev.o seq_setunseen.o 
showfile.o  signals.o smatch.o snprintb.o ssequal.o strcasecmp.o strindex.!
!
!
o  trimcpy.o uprf.o vfgets.o fmt_def.o m_msgdef.o   | tsort`  ; \
  ranlib libmh.a  ; \
fi 
sh: -static: not found
*** Error code 1
make: Fatal error: Command failed for target `libmh.a'
Current working directory /extra/rickert/n/nmh-1.0.1-snapshot.19991026/sbr
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'

 -NWR

Re: Trouble reading a header

[Neil W Rickert]

>Here is what the header looks like when it sits in the mailbox (before
>inc).

>From [EMAIL PROTECTED]  Sat Oct 16 20:01:09 1999
>>From francus  Sat Oct 16 20:01:09 1999
>Return-Path: <[EMAIL PROTECTED]>
>Received: from localhost (localhost [[UNIX: localhost]])
>by metsny.yossi.com (8.9.3/8.9.2) with ESMTP id UAA10375
>for <[EMAIL PROTECTED]>; Sat, 16 Oct 1999 20:01:05 -0400
>(EDT)
>Date: Sat, 16 Oct 1999 20:01:02 -0400 (EDT)
>From: Yoseff Francus <[EMAIL PROTECTED]>
>To: Yoseff Francus <[EMAIL PROTECTED]>
>Subject: test
>Message-ID: <[EMAIL PROTECTED]>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Status: O
>X-Status: 
>X-Keywords:
>X-UID: 3

I copied that message into my mailbox, starting with
the "From [EMAIL PROTECTED]  Sat Oct 16 20:01:09 1999".
I fixed the "Received:" so that the "(EDT)" was not sitting at the
beginning of a line by itself.  I assume that your mail program
wrapped that line before sending it.

With the message in my mailbox in that form, I ran 'inc' (from
'nmh-1.0').  It worked fine here.  This is a solaris 7 system (but
nmh-1.0 was compiled on solaris 2.5.1).  If there is a bug, it might
be a peculiarity of your system.

Notice the second line of your message.  It was ">From francus  Sat
Oct 16 20:01:09 1999".  That is actually an invalid header line,
although it did not confuse 'inc' on this system.

Most likely 'sendmail' is misconfigured on your system, so that both
'sendmail' and your local delivery agent are adding a "From "
separator line to the message.  If your delivery agent is adding
that, then you want to configure sendmail to not do it.  This is a
matter of adding an 'n' to the mailer flags (the "F=" string) in the
line beginning "Mlocal" in sendmail.cf.


>Here is the header after inc

>Date:Sat, 16 Oct 1999 20:01:02 EDT
>To:  Yoseff Francus <[EMAIL PROTECTED]>
>From:Yoseff Francus <[EMAIL PROTECTED]>
>Subject: test

>Return-Path: [EMAIL PROTECTED]
>Delivery-Date: Sat Oct 16 20:01:09 1999
>>From francus  Sat Oct 16 20: 01:09 1999
>Return-Path: <[EMAIL PROTECTED]>
>MIME-Version: 1.0
>Status:  O
>X-Status: 
>X-Keywords: 
>X-UID:   3

That is how it is being formatted in the 'show' or similar command
you are using to read your message.  It is not the raw content of the
message file, which should have the "Return-Path:" and
"Delivery-Date:" lines first.

 -NWR

Re: Trouble reading a header

[Neil W Rickert]

>When I do an inc of mail that was sent from a Pine 4.10 reader the
>header looks like:

I would wonder what was the complete series of steps involved.  From
here it looks as if nmh is doing the right thing, and if the message
is broken, it was broken before nmh got hold of it.

To the best of my knowledge, 'inc' does not add that "Status: RO"
line, but pine does (as do programs such as 'mailx' and 'mutt').  And
when pine or mailx or mutt add this line, they add it at the end of
the headers.  That makes it appear that the empty line was already
present before 'inc' did its thing.  Also the ">" in the ">From" was
present before 'inc' did its thing, or else 'inc' should have split
this into two messages.

>Return-Path: [EMAIL PROTECTED]
>Delivery-Date: Thu Oct 14 18:47:03 1999
>Status:  RO

>>From aaa Thu Oct 14 18:47:03 1999
>Return-Path: <[EMAIL PROTECTED]>
>Received: from localhost (localhost [[UNIX: localhost]])
>by metsny.yossi.com (8.9.3/8.9.2) with ESMTP id SAA27906
>for <[EMAIL PROTECTED]>; Thu, 14 Oct 1999 18:46:57 -0400 (EDT)
>Date: Thu, 14 Oct 1999 18:46:53 -0400 (EDT)
>From: aaa <[EMAIL PROTECTED]>
>To: Yoseff Francus <[EMAIL PROTECTED]>
>Subject: Re: Fwd: [Fwd:

>When I do a scan what I see is:

>10/14 *To:<<>From aaa Thu Oct 14 18:47:03 1999 Return-P

>If I get rid of the blank line between Status and >From ...
>the scan works properly.

>How do I get scan to funciton without deleting that line?

>thanks

>yoseff

>-- 

>Yoseff Francus [EMAIL PROTECTED]
>212-531-2956   FAX: 212-316-9312

 -NWR

Re: use of mkstemp() in nmh

[Neil W Rickert]

>I was just fiddling with updating the FreeBSD "port" of nmh from 1.0 to
>1.0.1 when I noticed that I get this warning compiling:

>cc -c -DHAVE_CONFIG_H -I.. -I. -I.. -O -pipe m_tmpfil.c
>m_tmpfil.c: In function `m_tmpfil':
>m_tmpfil.c:18: warning: passing arg 1 of `unlink' makes pointer from integer 
>without a cast

>which caused me to check into it (it's probably happened forever without
>my checking into it :-)).  The 'man mkstemp' shows this:

>...

>Now...unfortunately, it looks like all of the mkstemp() calls either
>assume that its return value is the char* filename or neglect to notice
>(or use) the fact that mkstemp() is returning an open file descriptor.

>Does anyone know if this is the standard mkstemp() definition?  Has anyone
>noticed this?  Or have a fix just waiting to be applied?  I can take a
>look at it, but I'm not so sure WHEN...I've been in perpetual "deadline
>mode" for a while now (and a while longer)...

The solaris 7 definition agrees that it returns an open file
descriptor.  Yes, I agree that this is a bug.

 -NWR

Re: Compile options

[Neil W Rickert]

I am curious as to whether you heard anything about this.

I joined the 'nmh-workers' mailing list on the day you sent your
inquiry, and so far yours is the only message I have seen.  I have
been waiting to see if somebody more experience with 'nmh' would
reply.

Perhaps 'nmh' is in summer recess, or worse :-( .

>Back in the old MH days it was possible to get one or more of
>the MH commands (scan??? inc???) to spit out a list of the   
>options that used taken when MH was built.   

>Is this still available in nmh?  I'm trying to determine what the
>settings for a Red Hat Linux prebuilt copy of nmh are.

As far as I can tell, it is not available.  Certainly the method that
works with 'mh' does not work with 'nmh'.  With 'mh' you could simply
say

inc -help

I did 'strings' on a few of the nmh commands, and that didn't turn up
anything that looked like a list of compile options.  So I would have
to guess that the ability to list the options is not available.

 -NWR

Re: invoking lynx for html email

[Neil W Rickert]

>Thanks everybody.  This works...

>mhn-show-text/html: %plynx -force_html '%F'

>The only annoying thing is I get a message, have to press q to exit less,
>enter to start lynx, and Q to quit lynx for a message I can tell I don't
>want by the subject line.  Oh well.

I use a 'show' shell script that sets NOMHNPROC in the environment
before calling the real show.  If I really do need to see the html or
base64 or other part, I can use 'mhn -show'.  For most of my mail I
can do without that.

 -NWR