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
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
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
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
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
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
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?
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
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?
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
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
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
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
directive::= # type / subtype
0*(; attribute = value)
[ ( comment ) ]
[ id ]
[ [ description ] ]
| 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
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
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
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
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
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
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
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
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
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
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
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
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
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 :=
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
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?
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
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
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.
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
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:
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
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
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
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
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
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
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
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
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:
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,
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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.
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?
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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'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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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 |
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.
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
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
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
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
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
1 - 100 of 1394 matches
Mail list logo
