Re: [Nmh-workers] Bcc query...
I wrote: heymanj writes: I know all are giddy about the release of nmh 1.2 (will be compiling it this weekend), but I am curious as to how to resolve the following situation: On my office workstation, I use a different logon id than my email address (as given to me by the corporation I work for). I have solved that by adding From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] to every one of the various *comp* files in ~/Mail/ I've also added masquerade: draft_from to /etc/nmh/mts.conf The problem seems to occur with Bcc in that I get the following: From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: undisclosed-recipients:; Subject: $10 Linux answering machine Date: Thu, 22 Dec 2005 14:33:40 -0500 --- Blind-Carbon-Copy To: From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: $10 Linux answering machine Date: Thu, 22 Dec 2005 14:33:40 -0500 The problem is that if someone replies having received the message on the Bcc, it gets sent to a non-deliverable email address. Yup. I've tripped over that myself recently. I don't know the motivation for the current behavior, and can't think of a good reason for it. My guess is that not many people use draft_from so it hasn't been noticed. Is this a MTA issue (not MUA)? Am I missing something to configure? Is this standard for the appropriate RFCs? Can nmh honor the From:/Reply-To: on a Bcc?? It's an nmh issue, and I don't see a way to configure around it. Dcc: doesn't behave this way, but I want to use Bcc:. nmh would honor From: on a Bcc with the patch below to post.c and spost.c. It wouldn't be as simple to propagate Reply-To: through, but I don't think it's as important. Especially because you're setting From: and Reply-To: to the same value. Could this patch be considered for the upcoming release, please? I committed it. David Thanks! jerry Proud MH/nmh since 1987 // Jerry Heyman | Software is the difference between // Amiga Forever :-) | hardware and reality \\ //[EMAIL PROTECTED] | \X/ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] suppress Content-ID's with new mhbuild option?
Hi, I have been manually editing drafts to remove Content-ID headers from outgoing MIME messages. The default configuration of Microsoft Outlook, Build 10.0.3416, in particular, doesn't see attachments in incoming messages if there are Content-ID headers. (There are a few old postings to comp.mail.mh about it. That's not the latest version of Outlook, but I still need to deal with it.) I'd like to remove the manual steps, as well as support use of X-MH-Attachment headers, which doesn't give me a chance to edit the final draft before sending. in the type directive gets part of the job done, but I've not found a way to suppress Content-ID in the message header without hacking nmh itself. One easy hack would be to add yet another option to mhbuild, and check that in the build_headers function of uip/mhbuildsbr.c where the Content-ID: header is added. Can anyone suggest a better way? Or better option names than -contentid/-nocontentid? Thanks, David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
I have been manually editing drafts to remove Content-ID
headers from outgoing MIME messages. The default
configuration of Microsoft Outlook, Build 10.0.3416, in
particular, doesn't see attachments in incoming messages if
there are Content-ID headers. (There are a few old postings
to comp.mail.mh about it. That's not the latest version of
Outlook, but I still need to deal with it.)
I'd like to remove the manual steps, as well as support use
of X-MH-Attachment headers, which doesn't give me a chance
to edit the final draft before sending.
Can anyone suggest a better way? Or better option names
than -contentid/-nocontentid?
Can you perhaps define the sendproc profile entry to be a filter that
forwards options and its output to send?
That could work. It's easy to filter out all Content-ID:
lines. But if I wanted to keep forwarded messages perfectly
intact, it's not as simple. It usually doesn't matter, but
some recipients might want to see _all_ original header lines
in forwarded messages.
The changes to nmh are trivial, see below. I'm not fond of
adding options. But I think it might be easier than deciding
whether we should just eliminate Content-ID: completely :-)
David
8--8--8--8--8--8--8
Index: uip/mhbuild.c
===
RCS file: /sources/nmh/nmh/uip/mhbuild.c,v
retrieving revision 1.9
diff -r1.9 mhbuild.c
62c62,66
#define VERSIONSW 16
---
#define CONTENTIDSW16
{ contentid, 0 },
#define NCONTENTIDSW 17
{ nocontentid, 0 },
#define VERSIONSW 18
64c68
#define HELPSW 17
---
#define HELPSW 19
66c70
#define DEBUGSW18
---
#define DEBUGSW20
87a92
int contentidsw = 1;
221a227,233
case CONTENTIDSW:
contentidsw = 1;
continue;
case NCONTENTIDSW:
contentidsw = 0;
continue;
Index: uip/mhbuildsbr.c
===
RCS file: /sources/nmh/nmh/uip/mhbuildsbr.c,v
retrieving revision 1.10
diff -r1.10 mhbuildsbr.c
53a54
extern int contentidsw;
3935c3936
* output the Content-ID
---
* output the Content-ID, unless disabled by -nocontentid
3937c3938
if (ct-c_id) {
---
if (contentidsw ct-c_id) {
Index: man/mhbuild.man
===
RCS file: /sources/nmh/nmh/man/mhbuild.man,v
retrieving revision 1.6
diff -r1.6 mhbuild.man
17a18
.RB [ \-contentid | \-nocontentid ]
317c318,321
using the \*(lq\*(rq and \*(lq\*(rq characters.
---
using the \*(lq\*(rq and \*(lq\*(rq characters. Alternatively,
the
.B \-nocontentid
switch suppresses creation of all \*(lqContent-ID:\*(rq headers.
644a649
.RB ` \-contentid '
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
Can you perhaps define the sendproc profile entry to be a filter that
forwards options and its output to send?
That could work. It's easy to filter out all Content-ID:
lines. But if I wanted to keep forwarded messages perfectly
intact, it's not as simple. It usually doesn't matter, but
some recipients might want to see _all_ original header lines
in forwarded messages.
I agree. Isn't it guaranteed that a blank line separates headers from
body? If so, the filter can be something like this
awk '/^$/ { body=1 } \!body /^Content-ID:/ { next } { print }'
We'd need to consider MIME context, in order to not suppress
Content-ID: lines inside of attachments:
To: you
From: me
Subject: foo
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-ID: dispensable
--- =_aa0
Content-Type: text/plain
Content-Disposition: attachment; filename=foo.txt
To: someone
From: someone else
Subject: indispensable Content-ID: header
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-ID: indispensable!
Take a look at the Content-ID: header for this message, will ya!
--- =_aa0--
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
I'd like to remove the manual steps, as well as support use of X-MH-Attachment headers, which doesn't give me a chance to edit the final draft before sending. How would you propose doing this, since usually one is using attachments for non-ASCII stuff? Or am I not understanding the question? You can edit the list of attachments. It's got nothing to do with what's in the attachment, ASCII or otherwise. The problem is simply that I do not want Content-ID headers to appear in the message that I create. My big-hammer solution is to disable output of Content-ID's, under control of an option to mhbuild. Another approach might include (among other things) insertion of in the directives that X-MH-Attachment generates just before the [: #text/plain; name=foo.txt; x-unix-mode=0644 [ English text ] /tmp/foo.txt #application/pdf; name=foo.pdf; x-unix-mode=0644 [ Adobe Portable Document Format (PDF) v1.2 ] /foo/multiatt.pdf Would there be a reasonable way to do that? I see where it would be done in the code, in make_mime_composition_file_entry (). But I don't see a convenient way to change what goes into those directives. Maybe add a configure option? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
I'd like to remove the manual steps, as well as support use of X-MH-Attachment headers, which doesn't give me a chance to edit the final draft before sending. The problem is simply that I do not want Content-ID headers to appear in the message that I create. My big-hammer solution is to disable output of Content-ID's, under control of an option to mhbuild. Another approach might include (among other things) insertion of in the directives that X-MH-Attachment generates just before the [: #text/plain; name=foo.txt; x-unix-mode=0644 [ English text ] /tmp/foo .txt #application/pdf; name=foo.pdf; x-unix-mode=0644 [ Adobe Portable Doc ument Format (PDF) v1.2 ] /foo/multiatt.pdf Would there be a reasonable way to do that? I see where it would be done in the code, in make_mime_composition_file_entry (). But I don't see a convenient way to change what goes into those directives. Maybe add a configure option? This sounds like a matter of personal taste as you never want content-id headers; it's not something that you do on a message by mesage basis. So why not add a dash option and you can put it in your profile? Seems nicer than added more cryptic goo to something that is already too cryptic for a sane person to use which is why I added the attachment handling code a while back. Yes, agreed. And thank you for adding the attachment handling support. I got tangled up in the cryptic goo one too many times. The option to suppress Content-ID: could be added to either mhbuild or send. mhbuild seems like the right place, because that's where the MIME message is created. And it's trivial to do there. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
Nice. Attach already takes the filename. Options would need to include mime-type, name, mode, description, and Content-ID. Anything else? If there's too much, it would get unwieldy. Any suggestion on how to associate the option values with the build directive? printf style? whatnow: -attach X-MH-Attachment='#%T; name=%N %C[%D; %M] %F' whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640 -descr iption=my app -contentid= /tmp/foo If any value in the build directive isn't specified, it would be determined automatically (using mhshow-suffix for the mime-type as it is now, and getting the name from the filename, and so on). While that example has a lot of typing, its purpose is to show all the options. I expect to rarely specify options, given a suitable build directive, such as '#%T; name=%N [] %F', with the mime-type and name usually determined automatically. I don't see a need to bother with mode or description, and don't want contentid. It might be possible to add support for Content-Disposition here. Um, gimme a break here. Why not just use mhbuild mime-composition files? I've been doing that for years, with help from emacs functions and key definitions. Even with that support, I still made a copy-and-paste error last week. And not the first time. I added the attachment handling code so that non-geeks could send attachments . This is heading in the opposite direction. How often are these cryptic arguments really going to be used? How many other mailers care about this sort of stuff? How many mail programs even look at this stuff? While it may not be obvious :-), I want simple, as well. And more foolproof. But I also want configurable. I know that I would never use any of the command line options above. Maybe I should just not bother with them. The one thing I do want to be configurable is the build directive. Again, it's not something that I'll change, so it can go into my .mh_profile. But, what's the best way to communicate it (currently it has three pieces) to make_mime_composition_file_entry ()? If you decide to make these additions, keep in mind that they have to be done in the send code, not in the whatnow code. This is because the design of the attachment code was such that it would work independent of the user interface . In particular, I know people who have hacked mh-e to add attachment headers. Got it. It's easier given nmh's current state, as well. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
Oliver wrote: David Levine wrote: Any suggestion on how to associate the option values with the build directive? printf style? whatnow: -attach X-MH-Attachment='#%T; name=%N %C[%D; %M] %F' I don't see why that needs to be configurable instead of hard coded. I want to use something different than what's in the code. whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640 -descr iption=my app -contentid= /tmp/foo Looks good for the most part. MH commands tend to use a space instead of =. I wouldn't include mode given that x-unix-mode is non-standard. Could always use long options (e.g. --x-unix-mode) similar to pick's syntax for additional components. Good idea. Though as I indicated in my response to Jon, I don't know if the options are even needed. If any value in the build directive isn't specified, it would be determined automatically (using mhshow-suffix for the mime-type as it is now, and getting the name from the filename, and so on). Could also allow something like -autodescription to specify a command to generate the description automatically. So running file to get a description would be something you need to configure. For the mime type it would allow you to use a script that uses .mailcap files. It might be possible to add support for Content-Disposition here. The filename ought to go in Content-Disposition really. Can always copy that from the file= component. We may need some syntax for specifying the main value for Content-Disposition, though. One reason I want to use a different build directive is that I currently do use Content-Disposition. Eventually, the configurable build directive could include support for that. For the time being, I'll try without it and see if anything breaks. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] mhbuild Content-Disposition header
The Subject was: [Nmh-workers] suppress Content-ID's with new mhbuild option? That's taken care of. The discussion had evolved to the mhbuild directive created by send's -attach option. Any suggestion on how to associate the option values with the build directive? printf style? whatnow: -attach X-MH-Attachment='#%T; name=%N %C[%D; %M] %F' I don't see why that needs to be configurable instead of hard coded. I want to use something different than what's in the code. Though maybe all we need are two kinds of directives. Currently, with attach, mhbuild directives look like: #text/plain; name=foo.txt; x-unix-mode=0644 [ English text ] /tmp/foo.txt #application/pdf; name=foo.pdf; x-unix-mode=0644 [ Adobe Portable Document Format (PDF) v1.2 ] /tmp/foo.pdf mhbuild translates them (along with everything else that it does) to: Content-Type: text/plain; name=foo.txt; x-unix-mode=0644; charset=us-ascii Content-Description: English text Content-Type: application/pdf; name=foo.pdf; x-unix-mode=0644 Content-Description: Adobe Portable Document Format (PDF) v1.2 Content-Transfer-Encoding: base64 I want: #text/plain [attachment; filename=foo.txt] /tmp/foo.txt #application/pdf [attachment; filename=foo.pdf] /tmp/foo.pdf which mhbuild would (almost) translate to: Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=foo.txt Content-Type: application/pdf Content-Disposition: attachment; filename=foo.pdf Content-Transfer-Encoding: base64 The almost part is that mhbuild currently creates Content-Description instead of Content-Disposition. I hijacked the Content-Description information and used it to form the Content-Disposition header (with or without -attach). (Is that a good idea? Or, should Content-Description be maintained, and new code and data fields added to support Content-Disposition? I have no need for Content-Description.) Selection of the second form above could be controlled by a -contentdisposition (or -rfc2183) switch to mhbuild. So with default settings, nmh behavior would be unchanged. This would be very easy to implement. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
Lyndon writes:
On Feb 1, 2006, at 7:22 PM, David Levine wrote:
The almost part is that mhbuild currently creates
Content-Description instead of Content-Disposition. I
hijacked the Content-Description information and used it to
form the Content-Disposition header (with or without
-attach). (Is that a good idea? Or, should
Content-Description be maintained, and new code and data
fields added to support Content-Disposition? I have no need
for Content-Description.)
No, it's not a good idea ;-)
Just yesterday I had to construct some messages using both -
description and -disposition. We need to figure out a syntax
extension that will support generating both headers.
I was afraid of that.
How about using {} to encapsulate the -disposition parameters:
directive ::= # type / subtype
0*(; attribute = value)
[ ( comment ) ]
[ id ]
[ { disposition-type 0*(; attribute = value) } ]
[ [ description ] ]
[ filename ]
EOL
E.g.,
#application/pdf {attachment; filename=foo.pdf}[Adobe PDF v1.3] foo.pdf
This is no longer very easy to implement :-/
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
Perhaps you should create a new utility that writes build directives and works both interactively and non-interactively, depending on the command line options? If it is able to write both directives and attachment headers, whatnow can use it for a *really* versatile way to attach stuff, and it could also be used from many UNIX editors with a shell. At this point, I don't see sufficient need. Build directives are straightforward. I have only ever used two, one for text and one for application attachments, and never had to change their structure. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
Perhaps you should create a new utility that writes build directives and works both interactively and non-interactively, depending on the command line options? If it is able to write both directives and attachment headers, whatnow can use it for a *really* versatile way to attach stuff, and it could also be used from many UNIX editors with a shell. At this point, I don't see sufficient need. Build directives are straightforward. I have only ever used two, one for text and one for application attachments, and never had to change their structure. Huh? Then why all this talk about getting whatnow to do this-or-that to the content parameters? That's what I'm suggesting might be best placed in a new utility. I certainly don't need it, but I'd prefer to see it there rather than in whatnow, or even a super-smart send or mhbuild. Perhaps I've misunderstood your objective. My objective is to be able to use -attach, which is straightforward and safer than dealing with mhbuild directives directly, to generate MIME messages that 1) all versions of Outlook can understand, and 2) are RFC 1806 and 2183 compliant. mhbuild -nocontentid now gets me 1). If we can get mhbuild -contentdisposition going, I'll have 2). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
My feeling is that a delimited string might not be appropriate for this because content-disposition has an internal grammar, unlike comments, ids, and descriptions. Perhaps something like what mhbuild does with Content-Description in plaintext is appropriate, i.e. if a Content-Disposition line follows immediately after a directive it is treated as a header for that MIME entity. In fact, what might be even clearer is if the Content-Disposition line is escaped with a #, because then if it's divorced from a directive mhbuild will treat it as an error. In fact, this might be a way to do all MIME extension fields. The grammar then becomes directive::= # type / subtype 0*(; attribute = value) [ ( comment ) ] [ id ] [ [ description ] ] [ filename ] EOL [ # extension-field ] where extension-field just can't look like a directive. Like this? extension-field::=Content- fieldname : attribute [ = value ] 0*(; attribute [ = value ]) #application/pdf; [ Adobe Portable Document Format (PDF) v1.2 ] /tmp/foo.pdf #Content-Disposition: attachment; filename=foo.pdf David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
directive::= # type / subtype
0*(; attribute = value)
[ ( comment ) ]
[ id ]
[ [ description ] ]
[ filename ]
EOL
[ # extension-field ]
where extension-field just can't look like a directive.
Like this?
extension-field::=Content- fieldname :
attribute [ = value ]
0*(; attribute [ = value ])
#application/pdf; [ Adobe Portable Document Format (PDF) v1.2 ] /tmp/foo.
pd
f
#Content-Disposition: attachment; filename=foo.pdf
Yes for the example, no for the grammar, although I got the grammar I wrote
wrong anyway. :)
Just a missing EOL at the end?
Firstly, how does the example look to you? The colon
isn't really necessary, and keep in mind that the line might be immediately
followed by another directive.
Regarding your grammar, I think it's wrong as a general RFC2045 grammar
because the value of the field can be any text, no?
My intent was to allow the value of the field to be
anything, for future expansion. It seems that RFCs issue at
a faster rate than nmh can support.
It would be up to the user to use sensible field names,
mhbuild would not enforce that. And that's the spirit
in which I put in the colon, the idea being that whatever is
in the extension field is pretty much going to be the header.
And the plaintext Content-Description: has a colon.
It's the right grammar
for Content-Disposition though.
Note that The grammar isn't for an RFC, it's for mhbuild.
But clearly we want it to support any RFC2045
extension-field.
Another reason I suggested this grammar is that I think the parsing of
it will be quite easy to fit into the existing mhbuildsbr.c code.
{} would be, too, but at this point I'm leaning towards
extension-field.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
| My intent was to allow the value of the field to be | anything, for future expansion. It seems that RFCs issue at | a faster rate than nmh can support. I think Joel's point was that that wasn't what your grammar achieved, it required the value of the field to be a sequence of attribute=value The =value portion is optional, and the grammar doesn't further define attribute. tuples, whereas some new field that might want to be added (and whose name need not necessarily start with Content- I would have thought) RFC2045 extension-fields are defined as starting with Content-. We could support arbitrary field names, but then let's call it something beside extension-field. might have some entirely different syntax, or perhaps no syntax at all. It admits at least one attribute, which can be any characters except CRLF, SPACE, and HTAB. The only syntax it doesn't admit is simply the header name. We could allow that, but I don't think it's necessary. ps: Also remember, if you're using RFC ABNF grammars (as opposed to the semi-defined thing that was in RFC822) then you also need to be explicit about where white space is to be permitted, if anywhere. Using RFC ABNF, the example you gave didn't fit your grammar, as you included (in the example) spaces between Disposition: and attachment, and again between attachment; and filename= (and in the actual directive line, between pdf; and and between ] and /tmp/foo.) This is mhbuild, not RFC, syntax. The mhbuild composition file grammar doesn't explicitly show whitespace. For example, directive starts with: # type / subtype, but this is supported: # text/ plain foo.txt David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
I just committed support for Content-Disposition headers in
mhbuild directives. I elected for the point solution, using
optional {}, instead of a more general solution. It just
seems more appropriate to me. And there are no issues with
backward compatibility.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Somebody out there have a virus or something? Also release stuff.
I just did a 'cvs update', and the resulting tree was lacking a config.h.in which the configure script wanted: configure: creating ./config.status config.status: creating Makefile config.status: creating config/Makefile config.status: creating h/Makefile config.status: creating sbr/Makefile config.status: creating uip/Makefile config.status: creating mts/Makefile config.status: creating mts/smtp/Makefile config.status: creating etc/Makefile config.status: creating docs/Makefile config.status: creating man/Makefile config.status: creating config.h config.status: error: cannot find input file: config.h.in See docs/README.developers: you need to run autoheader and autoconf. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Typo in sendsbr.c
Yes, fixed. Thanks! David At least, I assume it's a typo. Cheers, - Joel Index: uip/sendsbr.c === RCS file: /sources/nmh/nmh/uip/sendsbr.c,v retrieving revision 1.10 diff -r1.10 sendsbr.c 501c501 dtime (st.st_mtim, 0)); --- dtime (st.st_mtime, 0)); ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] whatnow attach usage
Ralph Corderoy writes: Hi Philipp, I wonder how I'd use the 'attach' option on the 'What now?' prompt. Whenever I use it I get whatnow: can't attach because no header field name was given. As a side note, whatnow(1) mentions -attach header-field-name in SYNOPSIS, but doesn't describe its use in DESCRIPTION. Right, it would be helpful to add a description there. For now, the best place to look is docs/README-ATTACHMENTS . David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild destroying german Umlauts
This is a real problem: when I MIMEfy a message (on the What now? prompt= ) it destroys german Umlauts. Check it out, here's a =8A (ae), =9A (oe), =9F (ue) and =A7 (sharp s). How can I tell nmh to leave Umlauts alone? Is this portion of the mhbuild man page relevant? When composing a text content, you may indicate the rele- vant character set by adding the charset parameter to the directive. #text/plain; charset=iso-8859-5 If a text content contains any 8-bit characters (charac- ters with the high bit set) and the character set is not specified as above, then mhbuild will assume the character set is of the type given by the environment variable MM_CHARSET. If this environment variable is not set, then the character set will be labeled as x-unknown. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Is mhstore-suffix supposed to work?
I don't know what it should do with mhstore, but can't think of any use. The mhshow man page describes what mhshow-suffix-type[/subtype] does for mhshow. uip/mhparse.c finds the context based on invo_name, so it could do something with mhstore, even unintended. What effect do you see? David Joel writes: It's undocumented, but if you put an entry of this form in the .mh_profile, it has an effect. Does anyone know what the case is supposed to be with this? Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Attaching a zip file
Another easy way to attach files is to use the whatnow attach command included in modern nmh. It hides the mhbuild commands. See the send and whatnow man pages. Modern here means since August 2002, I think, though support for the attachformat option shown below was added in February 2006. To use: 0) Add -attach X-MH-Attachment to the send: and whatnow: lines in your .mh_profile. Mine look like: send: -forward -attach X-MH-Attachment -attachformat 1 whatnow: -attach X-MH-Attachment And, add some mhshow-suffix entries for the content types that you send, if you don't already have them. I use these: The mhshow-suffix entries are necessary to get the: proper application type with -attach X-MH-Attachment: mhshow-suffix-text/plain: .txt mhshow-suffix-application/msword: .doc mhshow-suffix-application/pdf: .pdf mhshow-suffix-application/PostScript: .ps mhshow-suffix-application/vnd.ms-excel: .xls mhshow-suffix-application/vnd.ms-powerpoint: .ppt 1) At the whatnow prompt, enter: attach /tmp/foobar.zip Then send as usual. You won't get a chance to preview the mime output, but I've gained so much confidence with it that I no longer feel the need to. Some tips: * attach allows shell wild cards. * ls can be used at the whatnow prompt to look for your files. * al[ist] can be used at the whatnow prompt to show what you've attached. det[ach] can be used to delete attachments. And if you really want, you can edit the message to change attachments, though I reserve that for reordering. * Cc: or Bcc: yourself if you want to see what was sent. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The invisible mail folder
Joel writes: Joel Reicher [EMAIL PROTECTED] writes: If everyone's happy with + meaning the folder root and @ meaning the current folder and anything following being interpreted the same as any pathspec would be then I'll clean up the code and try to get around to making sure it's documented properly too. NO. I'm not quite happy with that, in that I would prefer that + foobar mean the same thing as +foobar. That way wild card expansion in shell scrip ts and file name completion in interactive shells would be much easier. OK, that brings us back to the original discussion. :) Is + without anything immediately following a folderspec in its own right? Norman says no, and I think I agree with him, chiefly because the folder root could still be referenced with +. (once I fix the bugs). I agree. Anything that helps users avoid the unexpected result of refile + is good. David Cheers, - Joel P.S. Norman, I replied to your two-month old message about using file -i just recently, but your mailserver rejects any email coming from mine. If this list doesn't send duplicates to you then you might not have seen my reply at all. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Attachments question
Jerry writes: Check the mhbuild(1) manpage or the online book section http://rand-mh.sourceforge.net/book/mh/cosemime.html (which is a bit out of date but may be easier to start with). An alternative to mhbuild is to use the whatnow attach command included in modern nmh. It hides the mhbuild commands. See the send and whatnow man pages. Modern here means since August 2002, I think, though support for the attachformat option shown below was added in February 2006. To use: 0) Add -attach X-MH-Attachment to the send: and whatnow: lines in your .mh_profile. Mine look like: send: -forward -msgid -attach X-MH-Attachment -attachformat 1 whatnow: -attach X-MH-Attachment And, add some mhshow-suffix entries for the content types that you send, if you don't already have them. I use these: The mhshow-suffix entries are necessary to get the: proper application type with -attach X-MH-Attachment: mhshow-suffix-text/plain: .output mhshow-suffix-text/plain: .txt mhshow-suffix-text/plain: .xml mhshow-suffix-text/html: .html mhshow-suffix-image/jpeg: .jpg mhshow-suffix-application/msword: .doc mhshow-suffix-application/pdf: .pdf mhshow-suffix-application/PostScript: .ps mhshow-suffix-application/vnd.ms-excel: .xls mhshow-suffix-application/vnd.ms-powerpoint: .ppt For tar files, something like these should work: mhshow-suffix-application/x-tar: .tar mhshow-suffix-application/x-compressed-tar: .tgz 1) At the whatnow prompt, enter: attach /tmp/foobar.tgz Then send as usual. You won't get a chance to preview the mime output, but I've gained so much confidence with it that I no longer feel the need to. Some tips: * attach allows shell wild cards. * ls can be used at the whatnow prompt to look for your files. * al[ist] can be used at the whatnow prompt to show what you've attached. det[ach] can be used to delete attachments. And if you really want, you can edit the message to change attachments, though I reserve that for reordering. * Cc: or Dcc: yourself if you want to see what was sent. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Compiling nmh-1.2 on CentOS 5
I thought that FC6 should be roughly comparable to RHEL 5. So, the nmh-1.1-19.fc6.i386.rpm in FC6 extras might work. rpmfind has it. It also has the Fedora 8 and Fedora 7 RPMs, they might work as well and are nmh version 1.2. David Parker Jones writes: There seems to be no binary available for CentOS / RHEL 5 so I had to compile from source. Here's a bit of information that would have saved me some time: nmh requires gdbm-devel and libtermcap-devel # yum install gdbm-devel libtermcap-devel Apologies to those for whom this is obvious. Regards, PJ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Sending automatic email
Are you looking for this: $ mhmail to ... -subject subject -body text David Xavier writes: I am trying to figure out how, given the To, Subject and body of message, to generate a complete mail draft ready to shoot. I read about sendfile, comp and friends *but* I can't give these information at the command line level. How do you generally do ? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cannot get envelop sender address correct
Anders writes: [EMAIL PROTECTED] said: I thought that draft_from couldn't be enabled in a .mh_profile so that the installer could restrict its use. To preserve that capability, how about just defaulting masquerade to be enabled instead of disabled? In this day and age, isn't that an impossible mission? After all, we have usespace (nmh or other) process doing smtp towars the smtp server. Any such check should, imo, be on the server side. Nothing's stopping the user from telnetting to port 25 and try to send the mail with whatever envelope he wants anyway. It's always been that way. I think that we should retain the original nmh capability, just change the default build configuration. Speaking of ports, wny way to use other ports than 25? I'm occationally sitting behind an intricate mess^Dh of ssh tunnels... It looks like it's hard-coded (smtp) in mts/smtp/smtp.c. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] content type syntax?
According to RFC 2045, it's not legal syntax, because a (non-quoted) token cannot contain spaces: content := Content-Type : type / subtype *(; parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. parameter := attribute = value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token / quoted-string token := 1*any (US-ASCII) CHAR except SPACE, CTLs, or tspecials I don't know of a good way to get mhshow to handle it. If you want to hack the source, it looks like line 789 of uip/mhparse.c is the place: for (cp = dp, dp = vp; istoken (*cp); cp++, dp++) I don't see how allowing spaces in the token could hurt, if we want to consider a permanent hack. David Paul writes: can someone tell me whether this is legal syntax for a Content-Type field? --Apple-Mail-21--97781285 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644; name=Low Cost Laptop.pdf Content-Disposition: inline; filename=Low Cost Laptop.pdf the issue, unsurprisingly, is the lack of quotes on the name= field. i have the following rule in .mh_profile, which catches otherwise unhandled application types and lets me save the file: mhshow-show-application: fallback_save '%f' '%a' when invoked, the fallback_save script is getting the string: 'x-unix-mode=0644 name=Low' (without the single quotes) as its second argument. so -- who's at fault, and if it's apple mail, is there a way to make mhshow handle this better? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cannot get envelop sender address correct
I wrote: Unless there's objection, I'll look into changing the default configuration to enable masquerading. (But not until next week, at least.) I committed that change on the main trunk. So, it won't be in 1.3. It's a simple change, if we want it to be in 1.3. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cannot get envelop sender address correct
I wrote: Unless there's objection, I'll look into changing the default configuration to enable masquerading. (But not until next week, at least.) I committed that change on the main trunk. So, it won't be in 1.3. It's a simple change, if we want it to be in 1.3. Do we want it in 1.3? Let me know and I'll copy the change to the branch so it gets into RC3. Here's the commit message: * configure.in, INSTALL: if --enable-masquerade is not specified to configure, enable all supported masquerade forms. This allows users to masquerade with the default configuration. That seems to be more worthwhile now than trying to prevent users from using it, especially with single-user installations or those where a user can edit etc/mts.conf. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cannot get envelop sender address correct
Peter Maydell writes: David Levine wrote: I wrote: Unless there's objection, I'll look into changing the default configuration to enable masquerading. (But not until next week, at least.) I committed that change on the main trunk. So, it won't be in 1.3. It's a simple change, if we want it to be in 1.3. Do we want it in 1.3? Let me know and I'll copy the change to the branch so it gets into RC3. I don't have any particular strong feelings myself. It looks like a pretty safe change -- all it does is change the value in the default mts.conf, right? (I think if you do a 'make install' the new mts.conf gets used rather than the installed one, but it does print a message so the sysadmin will know that something has changed.) Right. I just ported it to the 1.3 branch. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] sync'ing an mh mailstore between two machines?
Could a distributed file system help? Maybe Coda? http://en.wikipedia.org/wiki/Coda_(file_system) I don't know anything about Coda in particular, but it seems like it has solved at least some of the problems with disconnected operation. I think it lives on top of a conventional filesystem, so it's not too intrusive. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] things to mention in 1.3 release announcement?
I think it would be a good idea to mention the change in the default configuration to allow all supported form of masquerading. David Peter writes: I was looking back through the ChangeLog to see if there was anything in 1.3 that's particularly worth mentioning in the release announcement. It looks to me as if it's essentially all bugfixing; but does anybody have anything they'd like mentioned? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] things to mention in 1.3 release announcement?
How about: Changed default configuration to allow all supported forms of masquerading. See --enable-masquerade option to configure, and mh-tailor and post man pages. Thanks, David Peter writes: David Levine wrote: I think it would be a good idea to mention the change in the default configuration to allow all supported form of masquerading. Sure. Any chance you could come up with some suitable words, since you did the change? thanks -- PMM __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
I've noticed this, too. Glad that you tracked it down, thanks :-) I don't see any problem with your fix. It behaves properly for me and valgrind is happy with it. How about 512 instead of 192? The only downside would be higher memory usage, but I don't expect that's an issue here. David Mark wrote: Messages with very long envelope From lines break scan(1). This behavior happens with nmh 1.3 and 1.2. These messages are typically from mailing lists (Yahoo groups, in particular ). The Subject field in the scan listing is displayed as just an asterisk (*) . When I run scan, I get errors like: - scan: field name From SRS0=+Q5m=2Z=returns.groups.yahoo.com=sentto- [EMAIL PROTECTED] excee ds 127 bytes ??Format error (message 1764) in component 1 1764+ 10/17* scan: field name From SRS0=+Q5m=2Z=returns.groups.yahoo.com=sentto- [EMAIL PROTECTED] excee ds 127 bytes ??Format error (message 1765) in component 1 - The warning comes from sbr/m_getfld.c, which uses the value of NAMESZ (set to 128 in h/mh.h). I've increased NAMESZ to 192, which fixes scan(1), and nothing seems to have blown up...but I'd appreciate some guidance on whether this is the correct solution and if there are unforeseen side-effects. Thanks, Mark __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
Mark wrote: In the message dated: Tue, 21 Oct 2008 08:19:59 BST, The pithy ruminations from Peter Maydell on Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1) were: = David Levine wrote: = Mark wrote: = Messages with very long envelope From lines break scan(1). This = behavior happens with nmh 1.3 and 1.2. = = These messages are typically from mailing lists (Yahoo groups, in = particular ). The Subject field in the scan listing is displayed = as just an asterisk (*) . = = I've noticed this, too. Glad that you tracked it down, = thanks :-) = = I think this has been reported on the bug tracking system before. = (https://savannah.nongnu.org/bugs/?14975) Yes, that does sound like the issue I'm seeing. Note that the bug was opened in 2005. I'm really not a C programmer, but it took me almost as long to read the bug report as it did to increase the value of NAMESZ. As far as I'm concerned, this is a trivial fix to a signficant interface issue (ie., not being able to see the fields in the scan listing). = What I want to know is why you have files in your ~/Mail/whatever/ = with envelope 'From ' lines in the first place. The usual path = via inc doesn't have them (I think because they are the delimiters I do the same thing that's described in the bug report...I use formail procmail rcvstore. I haven't typed inc in years. = in a mail spool file and so get stripped out as the messages are = split). So perhaps this bug should be fixed by making whatever = path you're using to put messages in the folder strip out the = envelope From as inc does. Ah, I had procmail configured to insert the 'From ' line, with its -f option. Maybe I don't understand bug #14975, but the 'From ' line that procmail -f inserts does not start with ''. It starts with 'From ', and if it's longer than 127 bytes, scan complains. Perhaps, as the bug report from 2005 stated, that would break mail filtering that actually looks at the From line. Why strip it out...it's data about the mail delivery process, and may have some value to some other process (spam filtering? mail statistics? random number generation?). Personally, I think that the philosophical argument about whether tools strip out the From line or not is really separate from the fact that the the scan listing breaks because of an arbitrarily small value in NAMESZ. The first issue is difficult to resolve (as evidenced by the 3 year-old bug), while the second issue is trivial to fix (though maybe not as pure as some would want)but what do I know? :) I agree. Any objection to raising NAMESZ to 512? David Mark = = -- PMM = __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
Jeff wrote: David Levine [EMAIL PROTECTED] wrote: Perhaps the mh-mail man page needs to be updated. My mh-mail manpage, from the 1.3 source, cites a limit of 63 characters, as per RFC822. That's different, that's for header names. That should say 126 now (excluding the :, which is included in the 127 bytes in the buffer). The 998 is the limit on the length, excluding the trailing CR/LF, of any line. I've scanned RFC822 (w/o re-reading the whole thing) and I see no limits listed there for the field name or the total length. RFC2822 says: There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages. But there is no limit on field name length that I can find. If a line can't be more than 998 characters long, than a field name can't be. Note that it says you should be able to handle a arbitrary length to be robust. In any case, raising the limit does seem to be the answer... Agreed. I don't think that dynamic buffer allocation is worth the trouble here. We're just trying to avoid a harmless warning. While we are at it, it wouldn't hurt to make the implementation more robust. Besides the dynamic allocation, or at least raising the limit to 998, we should check to see what would happen with long header (127-~998) names We know what happens with header names longer than NAMESZ-2: scan issues its warning, e.g., scan: field name 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567 exceeds 127 bytes ??Format error (message 48) in component 23 exceeds 127 bytes really isn't right here, it exceeds 126 bytes. It is trivial to fix that message. and long lines (up to 998). I tried header lines and body lines over 3000 characters long. Both were handled without problem or complaint on Linux, with its BUFSIZ of 8192. Long header lines were pretty printed. On Solaris, with its BUFSIZ of 1024, line feeds were inserted after 1022 bytes in body lines. I took a quick look at your dynamic allocation and it looks fine to me. If you're confident that it's good, I say go for it. Otherwise, I think we should raise NAMESZ to 999 and fix the warning message. David As I admit above, I did not read the whole of rfc822 and rfc2822 (OK, I'll admit that I have in the past, but that was years ago), only did some relevant searches. Thanks (=E8=B0=A2=E8=B0=A2). Jeff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
Jeff wrote: Peter Maydell [EMAIL PROTECTED] wrote: David Levine wrote: I took a quick look at your dynamic allocation and it looks fine to me It hasn't got to me yet, but I had a look at it in the list archive, and this line of the patch: + i +- namebufsiz; looks very dubious to me :-) Good catch. I haven't tested it yet, I need to make sure it works properly when entering the realloc code. It's also got at least one unrelated change in it: + if(uprf(cp, re:) || uprf(cp, fw:)) Ah, part of my pending work on generalizing stripping of Re:, another topic. Other than that, it's not as invasive a patch as I'd feared it might be, but I still vote to put it on ice until we have some decent tests. Yes, testing good. Can the OP send me one of the messages that had issues? Insert this anywhere in the headers of any message: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567: Some Sender That name is 127 characters long. scan will trip over it. I just committed the NAMESZ increase to 999 and closed bug #14975. David Thanks (=E8=B0=A2=E8=B0=A2). Jeff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Can One Suppress MIME Part Number Headers?
Martin wrote: Lines like: part 1 text/html 1286 probably take 1.5 seconds to hear but in a year, I get over 7200 messages in just the inbox alone. That's 2 hours of just that.:-). Maybe my question should be; Is there a best place to put a content filter in nmh that always gets all of the output? That part number info line will always be printed to stdout by list_content (). So it can't currently be controlled by any option or filter. Maybe a new option should be considered. And maybe a very general one to suppress anything that's not message content? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] set from
Paul wrote: yoshi wrote: I have a virtusertable and prefer to send mail from a mail alias. How can I change the From: header? In mutt I use something like: set from = 'virtu...@host' my_hdr From: Full Name virtu...@host Sorry for that trivial question, but I found no answer so far. mh doesn't have a trivial answer for this. you can either: - add your new From: header manually, when you edit your draft (perhaps you can define an editor macro to help with this), but this will become tiring. A related approach uses shell aliases and the -form option: 1) Copy nmh/components to, e.g., components_a in my nmh directory and add the From: header to it. 2) Create a shell alias, e.g., alias compa='comp -form components_a'. And similarly for forw and repl. So it adds some pollution to my .bashrc but it's easy to set up. masquerade includes draft_from in nmh 1.3. If using an older version, you'll have to add it to your nmh/mts.conf. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] header issue, when replying to self
Paul wrote:
i get bitten by this several times a year -- perhaps there's a
way to configure around it.
i often reply to my own mailing list posts. when i do so, mh
attempts to reply to me, cc'ing the original recipient (i.e.,
the list). but i think because i'm both the sender and the
recipient, the To: header ends up missing entirely. for example,
here's what the draft looks like if i start to reply to an old
message i sent to this list:
Subject: Re: [Nmh-workers] sync'ing an mh mailstore between two machines?
cc: nmh-workers@nongnu.org
In-reply-to: 12129.1211398...@foxharp.boston.ma.us
References: e1jyqcd-0007y8...@mnementh.archaic.org.uk 200805211914.m4L
JExTY0
Fcc: outbox
needless to say, if i don't notice, and simply send the message,
it causes great confusion.
the command i use to reply to a list looks like this, after
expanding my wrapper scripts:
repl -cc to -cc cc -form form.repl.usual msgnumber
the contents of form.repl.usual look like this:
%(lit)%(formataddr %{reply-to}%|%{from}%|%{sender}%%)\
%(nonnull)%(void(width))%(putaddr To: )\n%\
%{subject}Subject: Re: %{subject}\n%\
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(nonnull)%(void(width))%(putaddr cc: )\n%\
%;
%; Make References: and In-reply-to: fields for threading.
%; Use (void), (trim) and (putstr) to eat trailing whitespace.
%;
%{message-id}In-reply-to: %{message-id}\n%\
%{message-id}References: \
%{references}%(void{references})%(trim)%(putstr) %\
%(void{message-id})%(trim)%(putstr)\n%\
Reply-to: p...@foxharp.boston.ma.us
Fcc: outbox
i've just done a scan of the repl and mh-format man pages to see
what might cause, or fix, this, but i'm missing it if it's there.
any ideas?
I add -cc me when replying to my own messages and suppress
the second copy (see below) by using -query. Inconvenient
and of course doesn't solve the problem. But maybe it gives
a clue on how to fix it: -cc me (or -cc all) restores the
To: header. But that seems like an unintended side effect:
I don't see why -cc should affect To:.
And they also add my login name, even if my reply address is
in my Alternate-Mailboxes. I don't need two copies of the
message.
I took a quick look at the code in uip/replsbr.c and quick
fixes didn't jump out at me. Maybe it would be best to
maintain the current behavior and add another -cc option,
but I have yet to figure out how the current code works.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] header issue, when replying to self
I wrote:
Paul wrote:
i get bitten by this several times a year -- perhaps there's a
way to configure around it.
i often reply to my own mailing list posts. when i do so, mh
attempts to reply to me, cc'ing the original recipient (i.e.,
the list). but i think because i'm both the sender and the
recipient, the To: header ends up missing entirely. for example,
here's what the draft looks like if i start to reply to an old
message i sent to this list:
Subject: Re: [Nmh-workers] sync'ing an mh mailstore between two
machines?
cc: nmh-workers@nongnu.org
In-reply-to: 12129.1211398...@foxharp.boston.ma.us
References: e1jyqcd-0007y8...@mnementh.archaic.org.uk
200805211914.m4LJExTY0
Fcc: outbox
needless to say, if i don't notice, and simply send the message,
it causes great confusion.
the command i use to reply to a list looks like this, after
expanding my wrapper scripts:
repl -cc to -cc cc -form form.repl.usual msgnumber
the contents of form.repl.usual look like this:
%(lit)%(formataddr %{reply-to}%|%{from}%|%{sender}%%)\
%(nonnull)%(void(width))%(putaddr To: )\n%\
%{subject}Subject: Re: %{subject}\n%\
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(nonnull)%(void(width))%(putaddr cc: )\n%\
%;
%; Make References: and In-reply-to: fields for threading.
%; Use (void), (trim) and (putstr) to eat trailing whitespace.
%;
%{message-id}In-reply-to: %{message-id}\n%\
%{message-id}References: \
%{references}%(void{references})%(trim)%(putstr) %\
%(void{message-id})%(trim)%(putstr)\n%\
Reply-to: p...@foxharp.boston.ma.us
Fcc: outbox
i've just done a scan of the repl and mh-format man pages to see
what might cause, or fix, this, but i'm missing it if it's there.
any ideas?
I add -cc me when replying to my own messages and suppress
the second copy (see below) by using -query. Inconvenient
and of course doesn't solve the problem. But maybe it gives
a clue on how to fix it: -cc me (or -cc all) restores the
To: header. But that seems like an unintended side effect:
I don't see why -cc should affect To:.
And they also add my login name, even if my reply address is
in my Alternate-Mailboxes. I don't need two copies of the
message.
That's because I had %(formataddr(me)) in my reply form
(and so do you). Removing that got rid of the reply to my
login name.
So, adding -cc me (or -cc all) should get what you want.
Or, we could hack the code as shown below. That keeps
the To: header to self, unless -nocc me was specified.
It keeps the confusion between cc and To:, but at this
point I don't think that's worth fixing.
David
Index: replsbr.c
===
RCS file: /sources/nmh/nmh/uip/replsbr.c,v
retrieving revision 1.11
diff -u -r1.11 replsbr.c
--- replsbr.c 13 Apr 2007 11:53:08 - 1.11
+++ replsbr.c 5 Apr 2010 01:44:38 -
@@ -396,7 +396,9 @@
!mh_strcasecmp (np-m_mbox, mp-m_next-m_mbox))
return 0;
}
-if (!ccme ismymbox (np))
+
+/* Check for own mailbox. Don't reply to self if -nocc me specified. */
+if (ccme == 0 ismymbox (np))
return 0;
if (querysw) {
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] header issue, when replying to self
Paul wrote:
david wrote:
I wrote:
Paul wrote:
i get bitten by this several times a year -- perhaps there's a
way to configure around it.
i often reply to my own mailing list posts. when i do so, mh
attempts to reply to me, cc'ing the original recipient (i.e.,
the list). but i think because i'm both the sender and the
recipient, the To: header ends up missing entirely. for example,
here's what the draft looks like if i start to reply to an old
message i sent to this list:
Subject: Re: [Nmh-workers] sync'ing an mh mailstore between two
machines?
cc: nmh-workers@nongnu.org
In-reply-to: 12129.1211398...@foxharp.boston.ma.us
References: e1jyqcd-0007y8...@mnementh.archaic.org.uk
200805211914.m4LJExTY0
Fcc: outbox
needless to say, if i don't notice, and simply send the message,
it causes great confusion.
the command i use to reply to a list looks like this, after
expanding my wrapper scripts:
repl -cc to -cc cc -form form.repl.usual msgnumber
the contents of form.repl.usual look like this:
%(lit)%(formataddr %{reply-to}%|%{from}%|%{sender}%%)\
%(nonnull)%(void(width))%(putaddr To: )\n%\
%{subject}Subject: Re: %{subject}\n%\
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%(nonnull)%(void(width))%(putaddr cc: )\n%\
%;
%; Make References: and In-reply-to: fields for threading.
%; Use (void), (trim) and (putstr) to eat trailing whitespace.
%;
%{message-id}In-reply-to: %{message-id}\n%\
%{message-id}References: \
%{references}%(void{references})%(trim)%(putstr) %\
%(void{message-id})%(trim)%(putstr)\n%\
Reply-to: p...@foxharp.boston.ma.us
Fcc: outbox
i've just done a scan of the repl and mh-format man pages to see
what might cause, or fix, this, but i'm missing it if it's there.
any ideas?
I add -cc me when replying to my own messages and suppress
the second copy (see below) by using -query. Inconvenient
and of course doesn't solve the problem. But maybe it gives
a clue on how to fix it: -cc me (or -cc all) restores the
To: header. But that seems like an unintended side effect:
I don't see why -cc should affect To:.
And they also add my login name, even if my reply address is
in my Alternate-Mailboxes. I don't need two copies of the
message.
That's because I had %(formataddr(me)) in my reply form
(and so do you). Removing that got rid of the reply to my
login name.
So, adding -cc me (or -cc all) should get what you want.
at the expense of the extra cc to me, right? (unless i use -query)
Right, for messages that Cc: you. For messages that you
sent, there won't be an extra cc to you if you remove
%(formataddr(me)).
Or, we could hack the code as shown below. That keeps
the To: header to self, unless -nocc me was specified.
It keeps the confusion between cc and To:, but at this
point I don't think that's worth fixing.
did you attach the right patch? i'm having trouble seeing
that this will result in any change in behavior.
You're right, that patch doesn't change anything. And at this
point I don't think that the code should be changed. (Or I should
say, that I should change it.)
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Bash completion
Joel wrote:
Hello,
When I source /usr/share/doc/nmh-1.3/COMPLETION-BASH I get the following
error:
somehost: ~ source /usr/share/doc/nmh-1.3/COMPLETION-BASH
bash: /usr/share/doc/nmh-1.3/COMPLETION-BASH:23: syntax error near
unexpected token `('
bash: /usr/share/doc/nmh-1.3/COMPLETION-BASH:23: `\++([a-zA-Z_]))'
There seem to be a lot of unbalanced parentheses in this file; I have
fixed those I could find (see attached patch).
I'm just guessing, but are those parenthesis pairs needed?
Maybe remove them? I don't know if quoting the patterns, as you
did in your fix, works properly.
Adding the leading open paren, which you only did on line 23,
doesn't seem right. The close paren has significance in a case
statement and should not be matched with an open paren.
However after I source it again I get this error:
bash: have: command not found
The first line of the file is have show
Is this a portability issue (is have a builtin command for some
installations of bash? I can't find it in any documentation), or am I
not supposed to source it? How else would I load it?
Replace have with type?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] JLR
meillo wrote: just one question for better understanding: Who or what is ``JLR''? There are several #ifdefs for JLR in code which is related to scan(1). There is also a comments which appears to be written by JLR and docs/ChangeLog_MH-3_to_MH-6.6 lists changes done for JLR. John Romine, I expect. From docs/README.about: In 1982, the University of California, Irvine took up maintenance of the software, under the direction of Marshall T. Rose and John L. Romine. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] CVS
Lyndon wrote: On 10-11-05 6:03 AM, Peter Maydell wrote: Yes, please start with the CVS head. Could someone please lay down a PRE_POSIX_CONVERSION tag that I can use as a reference point for the patches? Done. (It's on the head as of right now.) David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] miscellaneous proposed changes along the way
Jon wrote: o Can we just use exit() instead of done()? o Can we just use fprintf() instead of advise() adios(), admonish(), and advertise()? For exit(), and to a lesser extent fprintf(), I occasionally find it helpful to get them to do something else, such as dump core or some other state. It's easier to do that if they're wrapped. I agree that having 4 wrappers for fprintf() is a bit much. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh2?
Given the recent discussions: Should we move the current nmh project to maintenance-only mode, and start up a separate nmh2? It need not promise perfect backward compatibility, I would think reason enough to start anew. And it could be written in C++ :-] David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Understanding nmh (aka. What's the goal)
meillo wrote: our relationship is a bit special. I came in February and it resulted in a big discussion on MTAs and the like. I came again recently, had been active, proposed improvements, but feel like running agains walls. The point is, we collide at any point. It's the community on the one side and me on the other. At least this is how it feels to me. I realize that my opinions and point of view is quite different from your's (at least of those who speak up). I trust that all opinions expressed on the issues have been based on good reason and intent. Please don't feel that any sides are being taken, especially against an individual. Suggestions for improvements are always welcome by me, and by others from what I've observed here. The main topic of our disagreement is compatibility. As I'm sure you're aware, many of us have been using mh/nmh for a very long time (decades!). Whatever its deficiencies, it works. Furthermore, I use nmh a _lot_. So compatibility is quite critical. It seems to me as if you would be doing compatibility for compatibility's sake. This is sticking to old cruft. Caring to much for some old userbase likely keep you from getting new users while old ones slowly vanish. This also includes frontends. It is a dead end. If it's old cruft that works, I'm happy to stick to it. If anyone wants to fix things under the hood, without breaking anything, or add new capabilities, great! I value clearer and simpler solutions above compatibility in any case. I understand the importance for compatibility in case of a backend, but it should never be for it's own sake, but this is what I feel here again and again. Is nmh just good enough for you and therefore better not changed? Is updating your setups once a year more effort than the improvements of modernization? It could be and I would understand. The point is: What is the goal of nmh? At this point, compatibility has got to be part of nmh's goal. It was even at its inception, according to docs/README.about: intended to be a (mostly) compatible drop-in replacement for MH That's what I don't understand. No matter what I try to do, I conflict with you. This indicates that we probably have too different views of nmh. With pleasure I see the discussion of nmh2 which could finally be a step in my direction. But before I cheer too much up, I'd better know: What's the goal for nmh2, if it should come to happen? Good question. I think it can allow more rapid evolution of nmh because it wouldn't be as bound by compatibility and portability: 1) It can be a fork of the current nmh code base. 2) It can be a proving ground for new ideas and implementations. If some are deemed suitable for inclusion into nmh, that's fine. If not, that's fine, too. It should be useful and usable on its own. 3) It can sacrifice compatibility, whereas nmh must try to avoid user-visible, incompatible changes. 4) It can be implemented in languages other than C. 5) It need not be portable to odd (say, non-POSIX) platforms. I don't care what it is called. Having the goals clearly stated would allow me to figure out if it's worthwhile for me to try to add value to this community and project. If someone has personal opinions on this subject, I welcome them too. Nmh is clearly your project and not mine, besides being Free Software. I don't want to sail in your waters if you don't like. I don't think it's necessary or useful to think in such terms as your and mine. And I, for one, welcome your (and anyone else's) suggestions. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Understanding nmh (aka. What's the goal)
meillo wrote: Hmm that's then the basic point where we differ. I do care if the inside is clean and I rather like to remove features than add ones. From my point of view these are key factors to maintainability and thus for the future of the code. One of the most important properties of software is the question if the concepts are most simple and implemented best possible. If at some time the concepts are found to be imperfect, I really favor for change. I admit that providing a drop-in replacement is a fully valid goal. I rather dislike the fact that this looking back holds us from going forward. (It's more a general problem, though.) Then it's time to fork. Especially given that the current code base has changed surprisingly (to me) little in the last decade or so. It might not be pretty but it works, at least well enough to get used often. While maintenance is painful, that doesn't happen very often. And the intricate dependencies of people and frontends on nmh restrict the kinds of changes that can reasonably be made. For example, while I don't use many, or even most, of nmh's features, I think it would be a really bad idea to remove any of them. I could see an argument for starting over from scratch, but it's clear that not enough people have enough spare time for that. Another data point: I use nmh exclusively as my MUA. Also, I haven't used mhbuild (mime at the whatnow prompt) since I started using -attach. It's very easy to use and it certainly does work well. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]
Peter wrote: markus schnalke wrote: The old code generates ... ... for ASCII: Content-Type: text/plain; name=sendKi9x7j; x-unix-mode=0644; charset=us-ascii Content-ID: 4962.128958967...@argentina.foo Content-Description: ASCII text foo ... for non-ASCII (only if at least one attachment is present): Content-Type: application/octet-stream; name=sendbRaV8T; x-unix-mode=0644 Content-ID: 5209.128958999...@argentina.foo Content-Description: UTF-8 Unicode text Content-Transfer-Encoding: base64 d2l0aCBKb24 These are definitely just wrong -- we shouldn't be specifying name and x-unix-mode for the body text Adding -attachformat 1 to the send entry of your .mh_profile will get rid of the name and x-unix-mode. That option can also be added when entering send at the whatnow prompt. The send man page has examples of what it produces. If there's consensus to make that the default, it would be an easy code and documentation change. (Yes, I'm volunteering to make the changes. But not to push for consensus :-) (and base64ing when we could q-p is a bit unfriendly). Blackberries, and I think Droids, unnecessarily base64 text. But I do agree with you, nmh shouldn't. David __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Ralph wrote: Thoughts I've had over the years... MH was handy because it integrated with the Unix command line and filesystem; I still awk, etc., ~/mail/inbox/* on occasion when nmh's commands don't suffice. That's good; I don't think nmh should grow every bell and whistle. MIME breaks this. If all textual parts were stored in UTF-8 on disk things would improve once again. I agree. Grep is a requirement for me. I handle repl of MIME messages by decoding base64-encoded text/plain parts. I actually modify the message (using a script). I realize that not everyone wants to do that, but one of the beauties of nmh is that I can. So I am wary of fundamental changes to nmh's message per file approach. Additional files and/or dbs with metadata would be fine. It would be even better to integrate that decoding into nmh, optionally of course, and I would like to do that some day. I'm also wary of changing the message file naming scheme. anno modifies messages, so it is inconsistent with a naming scheme that includes file size, hash, or other properties. I could probably live without anno, but someone else might consider it important. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh post doesn't read profile, fileproc ignored
Stephen wrote: In nmh 1.3 (and 1.4-RC2), the post program doesn't read the user's profile file. It is quite deliberate about this, calling context_foil(). Why? The result I see is that post does not obey my fileproc profile entry, contrary to the documentation in the mh-profile man page. Stephen You're right. I don't know why it doesn't read the user's profile. It should be a simple change to the code and the post man page. Can anyone think of a reason not to fix post? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vfork()
Lyndon wrote:
We don't do any vfork() without an immediately following exec*()
call, do we?
From vmh.c:
#ifdef hpux
switch (PEERpid = fork ()) {
/*
* Calling vfork() and then another routine [like close()] before
* an exec() messes up the stack frame, causing crib death.
* Use fork() instead.
*/
#else /* not hpux */
switch (PEERpid = vfork ()) {
#endif /* not hpux */
I'll fork (:-) a separate thread on vmh and other unused files.
makedir.c calls setgid() and setuid() between vfork() and an exec*().
showfile.c calls strcmp().
mhbuildsbr.c calls close() and conditionally dup2() and fileno().
mhlsbr.c calls those plus snprintf() and sigaction() or signal().
With that, I won't look further. I agree that vfork() should be
globally replaced with fork().
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
Lyndon wrote:
On 2011-12-25, at 9:00 AM, David Levine wrote:
It's time, I think, to remove vmh.c. If someone wants it
they can get it from nmh 1.4 or prior. These files can
be removed:
h/vmhsbr.h
uip/vmhsbr.c
msh links against vmhsbr.o. Before killing those files we need to
extract whatever msh needs and move it into msh.c
I tripped over that. I just left vmhsbr.{h,c}. I don't use msh
and don't want to risk breaking it.
I didn't touch sbr/, it can wait until your changes are merged to
the master.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
AM wrote: I am new at the list. Sorry for direct (and perhaps stupid) question. Does anyone can compile vmh from nmh-1.4-RC2? Form me it gives a lot of errors. I read at list archive that in nmh there is something like vmh. This what I need, ncurses interface to nmh, but it is not a part of debian nhm package and does not compile. Difficult to test... vmh hasn't been supported for years. We just yesterday removed it from nmh, so it won't be in future releases unless someone wants to resurrect it. If you're looking for a visual front end and use emacs, mh-e is worth looking at. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh post doesn't read profile, fileproc ignored
kre wrote: Date:Tue, 03 Jan 2012 13:14:02 + From:Ralph Corderoy ra...@inputplus.co.uk Message-ID: 20120103131403.2042932...@orac.inputplus.co.uk | So scan(1), etc., in a script should ignore ~/.mh_profile? I suspect it is more that most of the MH commands make no sense other than as the MUA's interface to the user, and so the user's preferences always make sense (even when scan is run in a script .. it is generally run for the benefit of the user running the script). On the other hand, sending mail can be done by a script entirely for the script's own purposes (logging its uses for the developer, or ...) and for that, the user's preferences as to how mail should get sent might more reasonably want to be ignored. This is the function that mst of us would invoke using either mail user or some variation of sendmail (including the sendmail front ends that postfix, etc, mostly all provide for exactly this purpose), but being MH, the ability to use just MH for this purpose makes sense, so post is the just send this as instructed interface, and send is the front end to post that interprets the user's profile. I asked John Romine and here's what he had to say, which agrees and provides an example that convinces me: # My take on this is that post should not be called by # users directly, and it doesn't read the .mh_profile # (only front-end UI programs read the profile). # # For example, there can be contexts where post is called # by a helper program (like 'mhmail') which may be run by # a non-MH user. We don't want this to prompt the user # to create an MH profile, etc. # # My suggestion would be to have send pass a (hidden) # '-fileproc proc' option to post if needed. You could also # use an environment variable (I think send/whatnow do # this). I think that's the way to go. My personal preference is to use a command line option, not an environment variable. I think that send and whatnow are the only programs that interact with post and would need to pass a fileproc, and they and rcvdist need to add mhlproc support. I'll look into it tonight. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh post doesn't read profile, fileproc ignored
OK, I hacked rcvdist, send, and whatnow to feed fileproc and/or mhlproc to post. It's on a branch, fileproc_mhlproc_to_post, for now. Mainly so I could try out git remote branches, the changes are really small. And to allow time for more discussion. To try it: git clone as usual, then git checkout fileproc_mhlproc_to_post David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
Jerrad wrote: ...although msh should SEE ALSO packf instead of bbc, and packf should point to msh; unless that's already been done in 1.4 Hadn't been done for 1.4, just did. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
Jerrad wrote: I do not think msh should be discarded. At worst, a build time option, but you never know when you might want/need it, so why not build it? It's a single, documented useful utility that provides a useful complement to packf. I've not had *much* call for it, but it's nice to know it's there if I do want to interact with a mail archive in a familiar way. Paul wrote: fwiw i still like msh. i've used it as a login shell for some captive accounts. Thanks. Let's keep msh. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] par
Joel wrote: I'd be happy to have par as part of nmh, especially since there's no Fedora package for par right now. (Or, alternatively, I'd be happy for someone to package par for Fedora.) The par build hints contain a link to a spec file by Volker Kuhlmann. It works very nicely on Fedora. There's also a patch to add support for multibyte charsets. The attached script downloads all that and builds an RPM. Takes just seconds. The par codebase hasn't evolved since 2001, not a typo! The multibyte char patch has been living by itself since Oct 2006. If we decide to rely on it by default, I'll try to contact the author to see if we can make this a little easier. David if [ -f /usr/bin/par ]; then echo 'You already have par. Is it from par2cmdline?'; exit 1 fi [ -x /usr/bin/rpmbuild ] || sudo yum install rpm-build mkdir -p ~/lib/rpmbuild/SOURCES ~/lib/rpmbuild/SPECS cd ~/lib/rpmbuild/SOURCES wget http://www.nicemice.net/par/Par152.tar.gz wget http://www.nicemice.net/par/par_1.52-i18n.3.diff.gz cd ../SPECS wget http://www.nicemice.net/par/par-1.52-1.spec.gz gzip -d par-1.52-1.spec.gz patch -b MB_PATCH --- par-1.52-1.spec.orig2004-02-09 22:08:43.0 -0600 +++ par-1.52-1.spec 2012-01-26 21:01:29.0 -0600 @@ -23,0 +24 @@ +Patch: par_1.52-i18n.3.diff.gz @@ -57,0 +59 @@ +%patch -p 1 MB_PATCH rpmbuild -bb --clean par-1.52-1.spec echo the RPM is: ~/lib/rpmbuild/RPMS/$(uname -i)/par-1.52-1.$(uname -i).rpm ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
Tethys wrote: Ken Hornstein writes: That was fixed by installing ncurses-devel, but we should really be checking for that at configure time. Also: I think we do, right? I mean, we check for tgetent in configure. What did configure say when you ran it without ncurses-devel installed? checking for tgetent in -ltermcap... no checking for tgetent in -lcurses... no checking for tgetent in -lncurses... no checking if tgetent accepts NULL... no checking if tgetent returns 0 on success... no But it doesn't actually complain. It still builds a makefile and lets me think everything is OK. I'm not sure how best to handle this with configure. It'd be easy to print a warning message. I doubt that would be very effective, but maybe it's good enough. Or it'd be easy to exit 1, but then a user might end up chasing one missing lib at a time. You want to look at dtimep.c (the generated output from dtimep.lex). And from the 1.4 tarball ... yes, it's in there. I don't have one of those. From the savannah tarball: local@riva:~/nmh-1.4% find . -name 'dtimep*' -print ./sbr/dtimep.lex It looks like $(LEX) is not being set, so the makefile to build dtimep.c isn't doing so. Ahhh, I see. I don't have flex installed. Again, from configure: checking for flex... no checking for lex... no But it still doesn't tell me that the absence of flex is problem. As Steve noted, sbr/dtimep.c should be in the tarball. make dist puts it there. Try downloading the latest? One final grumble. If I install as a non-root user (which I always do, unless there's a specific reason to do otherwise), I get: if test x1 !=3D x; then \ /usr/bin/install -c -g mail -m 2755 inc = /local/opt/x86/linux/nmh-1.4/bin/$cmd; \ else \ /usr/bin/install -c inc = /local/opt/x86/linux/nmh-1.4/bin/$cmd; \ fi /usr/bin/install: cannot change ownership of = `/local/opt/x86/linux/nmh-1.4/bin/inc': Operation not permitted make[1]: *** [install-scmds] Error 1 make[1]: Leaving directory `/local/home/install/nmh-1.4/uip' make: *** [install] Error 1 We should probably be catching this and failing a bit more gracefully. I'm not sure why inc needs to be setgid mail anyway, though, given that mail files are owned by the user that's running inc, they should surely always have permission to modify them anyway, right? Certainly that's true on all of my machines. Not that I use inc, so it's somewhat irrelevant to me. But if inc does need the setgid bit set, then surely shouldn't rcvstore (which I do use) also need it? Only inc needs to be setgid, and then only 1) if using dot locking and 2) non-world writable mail spool. configure does the right thing if you add --with-locking=fcntl. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking - which to use?
Ken wrote: So Lyndon pointed out to me in private email that on BSD systems we should be using flock for locking. (Specifically, the mail spool on those systems uses flock). But this made me realize that locking in nmh is a big mess. Not just in nmh. This is old but looks useful: https://bugzilla.mozilla.org/show_bug.cgi?id=239013#c9 I think we can divide locking into two categories - the mail spool, and everything else. Everything else includes annotations, the context, sequences, and the MIME content cache. It occurs to me that it probably doesn't matter which locking method we use for that as long as it's consistent inside of nmh. I think that should be the best locking available, which would be one of flock/lockf/fcntl. As for the mail spool ... well, I am wondering if that should be runtime configurable. My thinking is that most people seem to be using prebuilt packages and what makes sense on one system might not make sense on another, so maybe runtime selection would be better. Right now we default to dot locking unless you override it, and that seems wrong to me. I agree. How about this: default to flock on FreeBSD, fcntl on Linux, and so on for the platforms we know. For platforms we don't know, use dot locking. Or to really play it safe, have configure determine which are available and use them all? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking - which to use?
Lyndon wrote: On 2012-02-05, at 8:49 AM, David Levine wrote: Or to really play it safe, have configure determine which are available and use them all? At the same time? Sounds like a recipe for deadlock to me. And it won't work correctly, if at all, on platforms that implement one or more of fcntl/flock/lockf as wrappers around one of the others (e.g. Solaris). So it sounds like picking one default for each platform and allowing run-time selection is the way to go. configure should be able to set this on a per-platform basis. It can't because it depends on what other applications use. As for internal locking, it's a toss-up between flock and lockf. To me the tie breaker is which of the two gets along best with network mounted filesystems these days (and think AFP and CIFS in addition to NFS). And forget about fcntl -- the semantics are too broken for consideration. If neither of flock/lockf are available, we can fall back to dot locking. Fedora /bin/mail uses fcntl and Mutt recommends it. procmail can use it. I haven't had any problems since I starting using fcntl. I did see problems with dot locking, I expect because other applications weren't using it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking - which to use?
Personal attacks benefit no one. And certainly do not belong here. Cygwin doesn't have a /bin/mail, either. I didn't bring it up before because it obviously doesn't count, so no need to jump on it. And I don't use it for mail, but I don't want to break nmh on it, either. procmail can be configured to use whatever locking a user wants. Let's leave nmh that way, too. I'm all for choosing more sensible defaults. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking - which to use?
Lyndon wrote: On 2012-02-05, at 4:04 PM, David Levine wrote: procmail can be configured to use whatever locking a user wants. Let's leave nmh that way, too. And again, an end user configuring their system into a stupid state is not justification for nmh to follow suit. Shun fcntl, but when someone discards their /bin/mail that uses it: stupid. And again, I'm not asking for nmh to be stupid. I am all for sensible defaults. If someone wants to choose a different locking scheme for whatever reason, it doesn't bother me. If they can do it at runtime, even better. How about submitting a patch set Your order has no effect on my priorities. that makes nmh work reasonably under cygwin. I'm not the only person who would rejoice. As a matter of fact, I have fixed some things. The build is reasonably clean. inc and folder operations seem to work. whatnow doesn't, maybe because of (v)fork. post doesn't, but I haven't looked at it even to determine if it's a nmh problem. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] make test
Josh Bresser's test suite is now integrated into the Makefile. make test runs it. And builds nmh if needed and you want to do both with one command. It already caught two code errors: a segfault in new due to an uninitialized variable and a recent regression in the display of timezone. And found a format glitch in a man page. Please try it, use it, and add to it. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] docs/COMPLETION-BASH.
Norm wrote: Well,... I had never heard of a bash-completion package, so it wasn't clear, but now it is. Using Redhat 6.2, I installed bash_completion and put COMPLETION-BASH in /etc/bash_completion.d/. The result was that every time I hit the tab key I got a slew of error messages about undefined variables, from bash. The problem persisted when I removed COMPLETION-BASH from /etc/bash_completion.d/, so it had nothing to do with nmh or you. When I logged in as a user, not norm, the problem disappeared, so it had to do with my environment. I spent a couple hours on the problem, to no avail. So for now, I gave up and uninstalled bash_completion. You have more patience than me :-) Just a guess, I wonder if set +u would have silenced those messages. I removed bash-completion (all of it, not just for nmh) from my system (Fedora 16) because it disabled some completions that I use frequently. I don't think it's very useful for nmh, anyway, because nmh options can be abbreviated. It should complete folder names, but didn't for me. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings spost
I've had this in my .mh_profile almost since I started using nmh: postproc: /usr/libexec/nmh/spost Wow, how did you ever know to use it? That's in the FAQ. Should be removed, I think. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Request For New Feature: Unadorned Plus Sign
Norm wrote: Folder name completion was what I wanted for. I guess that it's not to be. Norm, did you source /etc/bash_completion and copying COMPLETION-BASH to /etc/bash_completion.d/? After doing that, I do get completion of folder names. Oliver wrote: n...@dad.org wrote: Note: This feature would break what is now either an nmh bug or an undocumented nmh feature: An unadorned plus sign designates the user's nmh mail directory. That is surely a feature. I regularly use it in scripts along with mhpath rather than hardcoding the directory. Reason enough to keep it. And it is documented in the mhpath man page. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] I need help configuring nmh 1.4
Ken wrote: This happens because you have multiple cc: headers ... and according to the relevant RFCs, that isn't actually permitted I've never seen multiple Cc: headers in an nmh draft. Norm, did you add any? If not, does your .mh_profile have any -cc switches for repl (assuming you used that)? Did you enter any on the command line? nmh only has the ability to send email to one location, and that setting is global for all recipients. So you have the choice of submitting to your local SMTP server (which handles local email okay The only time I use my local SMTP server is from cron jobs, and then I use /bin/mail. I expect the default RedHat sendmail configuration works fine with that and lets you use local addresses. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Fedora RPMs
Joel wrote: Thus spake Ken Hornstein: Who builds the nmh RPMs for Fedora? I upgraded the machine where I use nmh to Fedora 16 over the weekend, but the version of nmh I get is 1.3-4. According to the Interwebs it looks like it was ... Josh Bressers, maybe? At least he's listed in the ChangeLog as doing the update to 1.3. Is he on this list? How did he find out before when there was a new release? My info showed that James Ralston is the nmh maintainer. I tried to contact him about 1.4 but never heard back. I'll try Josh now. And I'll ask him about par. In the meantime, there's a script attached to this message to built an rpm for it: http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00256.html David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] masquerade settings spost
Bill wrote: David Levine levin...@acm.org writes: I've had this in my .mh_profile almost since I started using nmh: postproc: /usr/libexec/nmh/spost Wow, how did you ever know to use it? That's in the FAQ. Should be removed, I think. There seemed to be some legitimate reasons for its use. Even I used spost for some time. There's been few questions that I've completely removed. I agree. I'm not arguing for removal of spost from nmh. The problem is where the mention of spost appears in the FAQ. The complete question and answer are below. spost is in the last recommendation, #7. For the purpose of answering this question, does #7 do anything that mts: sendmail does not? The explanation for #7 sounds like the user wants to work around a server problem. If they're going to edit their config file, why not remove that server? If it's a transient problem, they wouldn't have to edit the config if they used the -server option to send. #5 should say mts: smtp and mts: sendmail instead of mta: sendmail/smtp and mta: sendmail, respectively. #6 should be removed from this answer because the sendmail executable is not run when using SMTP. David Subject: 06.04 Fixing post: problem initializing server; [BHST] no servers available From: Peter Marvit marvit at hplabs.hpl.hp.com, Eric Bracken bracken at bacon.performance.com Date: Tue, 1 Nov 1994 00:00:00 -0800 The error message itself is essentially correct. However, what this really means is: MH's post cannot connect to a running sendmail over an SMTP port (MH configured with SMTP and SENDMTS). The potential problems: 1. Your local sendmail daemon is dying or not running for some reason. 2. You use BIND and your local nameserver is not responding. Solution: Delete /etc/resolv.conf. 3. Your $MHLIB/mts.conf (mtstailor) has its servers: pointing to a non-existent machine or a machine which is a) not reachable or b) not running the sendmail daemon. From: Bdale Garbee bdale at col.hp.com, Eric Bracken bracken at bacon.performance.com Date: Sun, 1 May 1994 00:00:00 -0800 4. The hostname localhost [127.0.0.1] is missing from /etc/hosts. Solution: add an entry for localhost to /etc/hosts or your DNS database or add the following to $MHLIB/mts.conf (mtstailor): servers: 127.0.0.1 \01localnet From: Larry Daffner ldaffner at convex.com Date: 3 Mar 1996 14:39:54 -0600 5. Your load average is so high that sendmail is refusing connections. Solution: Change your configuration from mta: sendmail/smtp to mta: sendmail so that a sendmail processes is spawned to deliver the message. This is a double-edged sword since the extra process only makes the load worse. From: Corbin Covault cec8 at po.cwru.edu Date: Sun, 02 Sep 2001 02:13:42 -0400 6. Sendmail may not be located on the path that MH expects. Solution: Try specifying the path explicitly by adding a line to mts.conf thus: sendmail: /usr/sbin/sendmail or wherever your sendmail daemon executable lives. From: Neil W Rickert rickert+nn at cs.niu.edu Date: 13 Apr 2001 18:47:43 -0500 7. You don't want to use an available server. Solution: Try postproc: /usr/local/lib/mh/spost in your MH profile (but check the path first). That should use command line sendmail. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
Ken wrote: I've seen a number of nmh man pages which say things like this: Consult the Advanced Features section of the nmh User's Manual for more information on making digests. Which leads to to ask ... which manual are they talking about, exactly? Looks like the MH User's Manual. I found a copy here: ftp://ftp.vim.org/pub/mail/mh/doc/MH.ps.gz The Historical Documentation page on Sourceforge has links to the ftp site at UCI, but it's gone. I think that we should archive those old documents before all of the mirrors disappear. Is there a place to store them on Savannah? Or should I just throw them into the git repo? About 3.5 MB. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
The old docs, ps converted to pdf, are now in docs/historical/ David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
I found a goldmine: the MH 6.8.5 tar ball contains RCS files for all of the source code. And it contains the sources for all of the documentation. I currently have it staged for addition at docs/historical/mh-6.8.5/ Before committing, is there a way to not include the contents of each file in the nmh-commits message? It's about 20 MB. Or even better, is there a reasonable way to shove the old histories into the beginning of the git history? My guess is not, but that would be really neat. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
Lyndon wrote: On 2012-02-29, at 11:26 AM, Ken Hornstein wrote: I've got nothing against bringing in the original troff input; it's just that what's in the MH 6.8 sources isn't exactly pure troff. It's got to be run through the build system to get rid of all the @BEGIN@/@END@ pairs (and I'm not even sure what definitions we should use to do that). Someone has to do that grunt work ... and I haven't heard anyone volunteer for that just yet. I can deal with that. I just don't have time to extract the document files themselves. If you can put the raw files into docs/historic/... docs/historical/mh-6.8.5/conf/doc David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
I've got nothing against bringing in the original troff input; it's just that what's in the MH 6.8 sources isn't exactly pure troff. It's got to be run through the build system to get rid of all the @BEGIN@/@END@ pairs (and I'm not even sure what definitions we should use to do that). Someone has to do that grunt work ... and I haven't heard anyone volunteer for that just yet. I can deal with that. I just don't have time to extract the document files themselves. If you can put the raw files into docs/historic/... docs/historical/mh-6.8.5/conf/doc And the corresponding macro-expanded versions are already in docs/historical/mh-6.8.5/doc/ David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild directives and filenames with spaces
Ken wrote:
How about this, without the escapes:
#application/pdf {inline} irritatingly named document.pdf
It will wrap the name in double quotes and put that in a
Content-Disposition header.
In a side note ... should {attachment} be the default nowadays?
I would think so.
And should we add a name parameter to Content-Type?
Or just use whatnow attach. It adds the name parameter.
And its attachformat 1 enables {attachment}.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Unknown switches to post and more garbage collection
Ken wrote: I was working on post, and I came across these switches. I was wondering if any of the greybeards here happen to know what they're for: -deliver Claims that the argument is an address-list, but from the code it seems to do ... nothing? Hm. Maybe in the old days it was used when compiling in MHMTS ... and I have no idea what THAT is for. Any ideas? -fill-in Maybe when you're doing whom ... it redirects the output of that command to a specified file? Maybe? No, it seems to do more. Anyone know? -fill-up Seems to change behavior when you're doing a whom. Again ... what the hell? Right, -deliver was used only with MHMTS. And it looks like only by the long-extinct rmail. I don't see it documented anywhere. -fill-in and -fill-up were used only by whom in support of White Pages. I won't try to paraphrase this: If MH is compiled with the WP option, send recognizes an address between and characters such as: To: rose -org psi ; to be a name meaningful to a whitepages service. In order to expand the name, send must be invoked interactively (i.e., not from push). For each name, send will invoke a command called fred in a special mode asking to expand the name. fred, FRont-End to Dish, is documented here: ftp://165.87.194.246/pub/gen-info/NYSERNet_Guide-v2.txt WP support was removed from MH 6.7.2 in '92. Clearly we can nuke all of this. All of the fprintf's to out could be removed, there's quite a few of them. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] mhstore nmh-storage disabled with -auto
The nmh-storage directory profile entry is ignored when -auto is switched on with mhstore. A bug was filed. I think it would be fine to obey that directory even with -auto. Does anyone see a reason not to? David __ The information contained in this e-mail message and its attachments are intended only for the personal and confidential use of the named recipient(s). If you are neither the intended recipient nor the person responsible for delivering to the intended recipient, you are not authorized to and must not disclose, copy, distribute or retain this e-mail or its attachments. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. E-mail is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We are not liable for data corruption, interception, tampering, amendment or viruses or any consequences thereof. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The curse of m_getfld()
paul wrote: (does nmh have a regression test suite of any kind?) It was recently revived and is being expanded. The last time Peter Maydell touched m_getfld.c, he added two torture tests of it. So we're in good shape. Here's the coverage of the entire test suite on m_getfld.c: File 'sbr/m_getfld.c' Lines executed:74.01% of 177 sbr/m_getfld.c:creating 'sbr#m_getfld.c.gcov' That's (only!) 177 executable lines. That .gcov file shows which lines were/were not covered. Some of the uncovered lines are to handle error conditions, others are to handle MMDF maildrops and MSH format. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
Jon wrote: Is there any way to change where nmh puts the draft temporary file? Never paid much attention to this before, but nmh creates a file named @ in the current directory when editing a draft. It shows up when doing a reply. I know that I don't have time to mess with things right now but if somebody could look at it it's probably gonna burn folks other than me. Can't say that I understand why it's needed. Right, it's certainly not needed if the current directory isn't writable. I'll try to look into making that the only behavior this weekend. With the default Msg-Protect of 600, it shouldn't be group or world readable. Do you have something else in your profile? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
Ken wrote: Because ... I'm writing the code, and I get to make the decision? :-) In all seriousness ... it's a balancing act between move nmh forward and keep around existing interfaces. So I have to make a judgement call, and my judgement is to add switches. If someone ELSE wants to write the code, they can use their judgement. There are practical concerns as well. Specifically: - A LOT of people apparantly just take whatever the package manager chooses for the options. That means effectively that if it's an option which is turned off by default, that means it's turned off for most people. - Just a guess, but I expect that most people who use prepackaged nmh don't use @. (Again assuming no use by mh-e and xmh.) - And the facts that there's only one @, and that the user won't get a @ if they can't write to the directory, means that they really have to know what they're doing with it. - It really is bad form to open a file in the current directory. Someone finally got burned by it, though admittedly with the help of su. This is one ugly default that really needs to be phased out. If someone wants to keep using it, they'll have the run-time/profile option to do so. How about this: * Add the switches. * Default to disabled. * I'll write the code :-) If we prefer to default to the current behavior (@ enabled) but deprecate that default, OK by me. David nmh fun fact of the day: mhn was deprecated in June 2001. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
Ralph wrote: Punt until the m_getfld() re-write. It's annoyed me for years, it can continue a while longer. I agree (with the re-write, I've never witnessed the problem). The code after Ken's excerpt goes directly into the io buffer. It's in the caller, not m_getfld(). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
I agree (with the re-write, I've never witnessed the problem). I assume you mean WITHOUT the rewrite, because nobody's re-written m_getfld last time I looked :-) Right. Looking at things ... it may be a simple fix, actually. I wasn't envisioning any changes to m_getfld(), that's for sure. I stared at it for a few moments and thought that removing the scansbr.c snippet that you posted might do it, but I really don't know. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] whatnow: can't attach because no header fieldname was given.
rfg wrote: Please excuse me if this is old news... I myself didn't know about it until today... but it would seem that the file(1) command on both FreeBSD and Linux implements a -i option that nicely spits out an appropriate MIME type for the file being examined. Unfortunately, POSIX file's -i means something different (spit out one of a very short list of short file types that aren't what we want, see man 1p file on Linux). And it doesn't have an option to spit out the MIME type. So we could use it, but only with a configure check to determine that it does what we need. If not available, we could look for mime.types, and so on. I haven't looked to see if the attach command for whatnow is using that or not, but certainly, if it is (or if it will, in the future), then it would seem to me that whatnow itself would not even need to make use of any file called mime.types (no matter where located). Currently, we use the associations in the user's .mh_profile and etc/mhn.defaults, which are greatly enhanced in the upcoming nmh 1.5 as a result of your report. Of course, it would be much better to rely on system capabilities. Some day . . . David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Spam: Re: whatnow: can't attach because no header fieldname was given.
Steve wrote:
Included here for all to consider.
This is a pretty arbitrary list of hand picked types initially genereted
by...
cat /etc/mime.types \
| perl -ane 'if ($F[1] ne ) {print mhshow-suffix-$F[0]:
.$F[1]\n}'
I didn't look at the new etc/mhn.defaults, so my apologies if they are
all/mostly dups.
Those listed below weren't dups so I added them.
mhshow-suffix-text/plain: .asc
.txt
and that should be vetted and given a 2nd thought?
The code in sendsbr.c will assign a content type of text/plain
if no mhshow-suffix entry in either the profile or
etc/mhn.defaults matches (or if the file has no suffix), and the
file contains only ASCII characters. So we don't need any
text/plain entries.
David
mhshow-suffix-application/ogg: .ogg
mhshow-suffix-application/rtf: .rtf
mhshow-suffix-application/x-bzip2: .bz2
mhshow-suffix-application/x-cpio: .cpio
mhshow-suffix-application/x-dvi: .dvi
mhshow-suffix-application/x-gzip: .gz
mhshow-suffix-application/x-java-archive: .jar
mhshow-suffix-application/x-javascript: .js
mhshow-suffix-application/x-latex: .latex
mhshow-suffix-application/x-sh: .sh
mhshow-suffix-application/x-tar: .tar
mhshow-suffix-application/x-texinfo: .texinfo
mhshow-suffix-application/x-tex: .tex
mhshow-suffix-application/x-troff-man: .man
mhshow-suffix-application/x-troff-me: .me
mhshow-suffix-application/x-troff-ms: .ms
mhshow-suffix-application/x-troff: .t
mhshow-suffix-application/zip: .zip
mhshow-suffix-audio/basic: .au
mhshow-suffix-audio/midi: .midi
mhshow-suffix-audio/mpeg: .mpg
mhshow-suffix-audio/x-ms-wma: .wma
mhshow-suffix-audio/x-wav: .wav
mhshow-suffix-text/css: .css
mhshow-suffix-text/rtf: .rtf
mhshow-suffix-text/sgml: .sgml
mhshow-suffix-video/x-msvideo: .avi
mhshow-suffix-video/x-ms-wmv: .wmv
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh on Cygwin
nmh is fully operational on Cygwin, as of the current state of the repository. If someone has a need with nmh 1.4, try configuring with --with-pager=less, and set your Signature profile entry or SIGNATURE environment variable to something without any special characters. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
Bill wrote: David Levine levin...@acm.org writes: - Just a guess, but I expect that most people who use prepackaged nmh don't use @. (Again assuming no use by mh-e and xmh.) That's probably a good assumption for MH-E. The message that you are replying to is available in a buffer; all message buffers are named according to the messages folder and message number. Thanks. I took a quick look at xmh and didn't see any use of @. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
Bill wrote: David Levine levin...@acm.org writes: Ken wrote: I've seen a number of nmh man pages which say things like this: Consult the Advanced Features section of the nmh User's Manual for more information on making digests. Which leads to to ask ... which manual are they talking about, exactly? Looks like the MH User's Manual. I found a copy here: ftp://ftp.vim.org/pub/mail/mh/doc/MH.ps.gz The Historical Documentation page on Sourceforge has links to the ftp site at UCI, but it's gone. I think that we should archive those old documents before all of the mirrors disappear. Is there a place to store them on Savannah? Or should I just throw them into the git repo? About 3.5 MB. Were you aware of https://sourceforge.net/projects/rand-mh/files/Documentation/? We archived all of the old MH stuff at SourceForge (project rand-mh). Yes, and just to be safe it's all in nmh/docs/historical/ now, with .ps converted to .pdf and all .doc files renamed to .txt. The document sources are also in that hieararchy. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
Ken wrote: That is basically the same thing as doing a rebase, except that way is more work. It would invalidate every checked-out copy of the revision control tree. It _might_ be useful, but would it be worth it? I think not, if there's not a reasonable way to deal with checked-out copies. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5 release and better repl/MIME handling
Ken wrote: Okay, so I am thinking that perhaps we are close to ready to start the 1.5 release cycle; I don't have anything else on my plate that I'd like to see in there. So if anyone else has any code they would like to see in nmh for 1.5, now is the time they should speak up! I'd prefer to see 1.5 go out soon and then dedicate the next release to better repl/MIME handling. If people think it's a good idea I wouldn't mind shipping this with nmh, but I'm not sure where is should go; right now nmh doesn't have a dependency on perl. We could always put it in the docs directory. Anyway, please let me know what you think! I'm fine with perl but I expect not everyone will be. Configure could check for MailTools, and at least warn if it's not available. Maybe grab it only if a new configure option for this purpose was specified. How about a new contrib directory? This has been brought up before. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First release candidate for 1.5 now available
Oliver wrote:
I tried compiling and installing on Solaris. It all builds fine but I
get the following message repeated a number of times:
./man/mh-chart-gen.sh: !: not found
! is not available in pure Bourne shell and should be avoided.
There are several options, we could use:
echo $i | grep 'mh-chart.man' /dev/null continue
or:
expr $i : .*/mh-chart.man /dev/null continue
I think continue works in any reasonable /bin/sh.
Or we could avoid any forks by using a case statement:
case $i in
*/mh-chart.man) break;
*)
...
;;
esac
I'll change it to the case statement (without the break).
The script then goes on to complain about the -E option to grep (only
/usr/xpg4/bin/grep or egrep handle that on Solaris).
I think the easiest solution here to the roll the grep -E into the awk:
awk '/.SH SYNOPSIS/,/^(\.ad|typical usage:)/ { if ( $0 !~ /^(\.SH
SYNOPSIS|\.na|\.ad|typical usage:)/ ) print }'
Thanks. I'll change it to that.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First release candidate for 1.5 now available
Ken wrote: Minor nit: ! is in POSIX; the problem here is Solaris has an ancient sh implementation (isn't there a POSIX one in something like /usr/xpg4/bin?). Same with -E for grep. I'm fine with workarounds for Solaris, but I'm wondering if we want to tackle this in a different way. Example: we could use AC_PROG_EGREP for the grep issue (although Oliver's suggestion to combine it into awk seems reasonable as well). I'm neutral on solutions for the problem with POSIX shell constructs; we could either get rid of them or have autoconf pick a better shell. Oliver's fix with awk works, and saves some cycles, so I'm happy with that. I'll wrestle with the shell accomodations here and in the test suite for now. If it gets to be too much, we can revisit. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking In Scripts and nmh Locking
Norm wrote: They include adding to mail drops, moving files between and within folders and editing context files (mostly to rename or remove sequences). Though they can get clumsy, there are nmh programs to do each of those things. send/post adds to mail drops, refile moves messages between and within folders. Copy a sequence: mark -seq s2 `mark -seq s1 -list | sed 's/.*: //'` Remove a sequence: mark -seq s1 -del all Unfortunately, pick doesn't help here, it creates sequences rather than searches them. I don't know which of these things require what kinds of locking. I don't want to learn. And most importantly I shouldn't have to know. I'd much, much rather use the high-level tools. I realize you provided examples so there may be tasks that aren't as easy to handle. If we need to add to existing programs to get what you need, I think that's the way to go. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking In Scripts and nmh Locking
I wrote: Copy a sequence: mark -seq s2 `mark -seq s1 -list | sed 's/.*: //'` That should be: mark -seq s2 -zero `mark -seq s1 -list | sed 's/.*: //'` just in case the target sequence already exists. I'm willing to add an option to mark to suppress the sequence name in the output of list. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking In Scripts and nmh Locking
Paul wrote: i think locking inside of mh is nec'y, Of course, it definitely is necessary. I'm concerned about _outside_ poking around _inside_. Bad idea. While it's always been easy to do with mh, I don't see a need to encourage it any further. And I'm willing to help make it less necessary. i fought mh locking bugs for years That's my point :-] because my .forward went to a perl script that ultimately ran rcvstore, while cron was capable of running pick at any moment.) Would a don't-modify-any-internal-nmh-state switch to pick would have solved that problem? Assuming it was specified, of course, but compared to locking that's not a disadvantage. And if the machine crashes while it's executing pick with that switch, no harm. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking In Scripts and nmh Locking
Norm wrote: (Minor, and really irrelevant details: send/post imposes constraints on and alters the contents of a file; refile won't let me designate the name of the destination file; refile won't overwrite an existing file; etc,etc. I have little doubt that you (David Levine) could figure out ways to overcome those details). nmh-workers, as a whole, will figure out ways to overcome those details, whether using existing capabilities or adding new ones. I'm just trying to help. Ralph provided a fantastic (and documented) suggestion of looking at separate mh environments. The alternative, locking, requires cooperation and is therefore tricky to get right, and isn't robust. And from what I've seen and experienced in 25 years of using mh, just isn't necessary. If you can avoid locking, why not? I don't know which of these things require what kinds of locking. I don't want to learn. And most importantly I shouldn't have to know. I'd much, much rather use the high-level tools. I realize you provided examples so there may be tasks that aren't as easy to handle. If we need to add to existing programs to get what you need, I think that's the way to go. The basic philosophy and reason-for-existence of mh and of nmh is that that's not the way to go. I should be allowed -- nay encouraged -- to use file system tools to manipulate mh constructs. Certainly, I routinely manipulate message files to do all kinds of things. Does mh constructs include its mechanisms for saving state? Not so clear. As Jerry notes in the section of his book referenced by Ralph yesterday: Worse, the format of public and private sequence files isn't documented (as far as I can tell), so it could change. He's not saying don't do it. But this is another reason, along with locking, to stay away from direct manipulation of mh's state files. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] draft validation, error checking
Paul wrote: is there a way to set up a hook of some sort, either at the whatnow level, or deeper in send or post, which will cause forbid sending, or cause sending to fail, if a set of user-defined sanity checks don't succeed? i use a wrapper script for my editor in mh, and the script prints warnings regarding the draft when the editor exits. If that script exits with non-zero status, then comp, etc., should not send, and terminate with a message. it checks for things like a missing To: header at all, or if the From: header looks like my home address but the To: header looks like a work address -- that sort of thing. when vi exits, and i'm back at whatnow, i get this: WARNING: missing or empty 'To:' header What now? and that's great, when i'm fully caffeinated and am actually paying attention to what's on the screen. i'd like to elevate at least some of those warnings to fatal errors -- i'd like to not be able to send the message until i fix the problem. how might i do that? If I understand correctly, you're doing something like: comp -editor sanitychecker where sanitycheck is of the form below. Or do you get to whatnow some other way? David #! /bin/sh sanity checks if sanity checks succeeded; then exec whatnow -editor $EDITOR $mhdraft else echo sanity checks failed exit 1 fi ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
