Here's a patch that allows setting rfc3461 Delivery Service Notification
(notify=success,fail,delay ret= and envid=) flags on outbound mail. I've
added corresponding UA support to the exmh CVS tree already.
I didn't do patches for the manpages or the 'spost' command - am willing
to do so if this
On Sun, 10 Oct 2004 16:37:00 CDT, Chad Walstrom said:
nmh is an old code-base, well established, and stable. Stable things
don't generally get messed with unless there are bugs or security
problems. You've found some bugs, so go ahead and fix them. This
environment is all about scratching
On Tue, 23 Nov 2004 16:08:40 MST, Robert Tarrall said:
On a Linux system where I just upgraded from nmh-1.0.4 to nmh-1.1RC3,
sending takes a long, long time (circa 30 seconds) from the time you
type send at the whatnow prompt to the time you get a command prompt.
Yeah, I've noticed this one
On Wed, 24 Nov 2004 10:21:13 MST, Robert Tarrall said:
Maybe I'm missing something, but I *think* the general assumption when
you're locking these files is that you're going to change them and want
to ensure that someone else doesn't make changes at the same time. If
you don't have
On Sat, 22 Jan 2005 11:43:48 GMT, Ralph Corderoy said:
Seems sane, except for one little detail. There's the corner case
where (for instance) the $LANG is set to something like fr_FR.UTF-8
(which means that the system understands UTF-8, but it's quite
possible that for actual display, we
On Mon, 14 Feb 2005 19:35:36 +0100, Harald Geyer said:
Obviously any script which tries to do the above runs into the same
problem that prevents nmh from doing it itself: The script would need
to know which charsets the terminal can handle and how to tell it.
Also changing the terminal might
On Wed, 27 Apr 2005 11:01:45 EDT, Mike O'Dell said:
if i were to hazzard a guess, the reason the code doesn't use
mkstemp() is that [1] the code cited is likely well more than
twice age of mkstemp() [2]and nobody has gone looking for
things to fix that were still (apparently) working. (big
On Mon, 09 May 2005 18:16:01 PDT, Jon Steinhart said:
I'll take it over if that's OK with the current maintainer. I'm not a
great expert on all of the fine points of mail delivery, but I do have
an interest in modernizing the code base and adding new features.
Fear not - there's a goodly
On Wed, 11 May 2005 16:03:26 PDT, Bill Wohler said:
The following message is a courtesy copy of an article
that has been posted to gmane.mail.nmh.devel as well.
Chad Walstrom [EMAIL PROTECTED] writes:
On Wed, May 11, 2005 at 10:13:52AM -0400, Peter Galbraith wrote:
As a note of
On Sat, 14 May 2005 13:13:44 PDT, Norman Shapiro said:
I accomplish a similar functionality with an sh function for use in scripts:
newmh ()
{
local oldContext=${MHCONTEXT-context};
local path=`mhpath +`;
export MHCONTEXT=,$oldContext.$$;
cp $path/$oldContext
On Sun, 15 May 2005 22:30:45 PDT, Jon Steinhart said:
So, ask per earlier messages, I'm looking at the context/profile
code and trying to clean it up as I make the changes that I need.
There's a pretty strange function called context_foil(). In all
but two of the places where it is called
On Thu, 26 May 2005 15:44:29 +0200, Harald Geyer said:
Hm, ok then this probably isn't that much of an issue as I thought before.
Is fprintf(stderr, ...) ok? After all it should be unbuffered?
Don't count on unbuffered semantics, unless you can find a reference that
states that stderr is
On Mon, 09 Jan 2006 20:13:56 +0700, Robert Elz said:
The suggestion to make an IMAP filesystem (as linux centric as the
original suggestion was) is clearly the direction that would allow
MH and IMAP to work together properly. Embedding IMAP knowledge into
show, next, scan, pick, refile, ...
On Thu, 12 Jan 2006 12:53:27 +0100, Oliver Kiddle said:
Any thoughts on the following patch? It gets rid of the DATE file and
has the date automatically updated when autoconf is run. This has the
advantage that the date will be automatically updated when a release is
made and the man pages
On Tue, 21 Feb 2006 21:01:45 PST, Jon Steinhart said:
Also, I have time to roll another release now. Is it time? I know
that it was a while back, but have all of the recent check-ins been
tested enough for everybody?
I just did a 'cvs update', and the resulting tree was lacking a
On Fri, 24 Feb 2006 08:44:39 EST, David Levine said:
See docs/README.developers: you need to run autoheader and
autoconf.
Damn. Ran autoconf, forgot autoheader.
Somebody pass me some caffeine. ;)
pgp9VFUFEqfKf.pgp
Description: PGP signature
___
On Mon, 20 Mar 2006 10:33:40 EST, Paul Fox said:
i believe there was consensus that a) this behavior was a result
of a problem with the original content encoding, and that b) the
nmh decoder should be more tolerant when decoding, and simply
pass mis-codings through untouched.
I'd have to
On Mon, 20 Mar 2006 18:09:41 GMT, [EMAIL PROTECTED] said:
RFC 2045 is pretty clear about what MUAs should do in the face
of a bad encoding; the idea is to follow that.
(Also, anything
you can get through with odd q-p you could have got through
On Fri, 05 May 2006 10:07:18 +0200, Matthias Teege said:
I try to build the latest nmh on a Mac OS X box. The make dies with
gcc -c -DHAVE_CONFIG_H -I.. -I. -I.. -Wall -O2 slocal.c
slocal.c: In function 'parse':
slocal.c:780: warning: pointer targets in passing argument 2 of 'm_getfld'
On Wed, 24 May 2006 21:14:18 EDT, Jeffrey C Honig said:
That's a good idea. But I think that can be accomplished w/o a regex by
listing `[listname]' as a prefix to list for each list you are on.
I'm hesitant to try to use a regex because the only regex code in nmh is
strictly for pick and
On Sat, 15 Jul 2006 21:01:56 +0200, [EMAIL PROTECTED] said:
I added those 2 lines to .mh_profile but still doesn't work.
Error message:
mhbuild: draft shouldn't contain MIME-Version: field
And this is the draft message:
To:[EMAIL PROTECTED]
cc:
From:[EMAIL PROTECTED]
Fcc:
On Sun, 23 Jul 2006 06:13:41 +0200, [EMAIL PROTECTED] said:
What are valid values for MM_CHARSET?
As a practical matter, the valid values are Some single-width charset you have
proper locale support installed on the system. iso8859-1 works on my system,
most other iso8859-* should work if you
On Wed, 02 Aug 2006 13:00:54 BST, [EMAIL PROTECTED] said:
Did we ever come up with a good plan for this? It's currently
at the top of my 'list of things that annoy me about nmh'...
Whatever we do, we need to remember to include a check for the rather common
case of Tagged as
On Sat, 07 Apr 2007 17:34:10 BST, Peter Maydell said:
Neil W Rickert wrote:
WTF! It seems that nmh is attempting to lock /dev/null.
This bug was fixed in CVS in 2005. I suggest that you (or your
vendor) upgrade to nmh 1.2 :-)
Whoops, somebody take me out back and shoot me - I flagged the
On Thu, 19 Apr 2007 10:13:07 BST, Peter Maydell said:
(Surely there's going to be at least one file where the source code
calls done() and which done() it winds up calling depends on which
program it's compiled into...)
Such code needs to be taken out back and shot. Or at the very least,
tap tap tap Is this thing on?
Dragging a thread over here from the exmh list, as Robert Elz pointed out
that it's probably replcomp's job..
Has anybody looked at what it would take to do the following:
1) Fix replcomps and friends so base64 or quoted-printable was decoded
before processing, so
On Sat, 08 Mar 2008 11:31:22 +0100, Anders Eriksson said:
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64
other headers
Seems familiar? Is cte:base64 legal, or is nmh missing something? Judging
from
the bugzilla list, others can read the messages fine.
It's
On Sun, 04 May 2008 23:22:41 BST, [EMAIL PROTECTED] said:
NB: when we eventually produce a final 1.3 release, where should we be
announcing it? The README.developers suggests [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED],
but I suspect that at least some of
On Mon, 05 May 2008 21:46:29 +0200, Anders Eriksson said:
[EMAIL PROTECTED] said:
here is another problem. After several days I found most of the emails I se
nt
did not arrive. I found it is because nmh always use [EMAIL PROTECTED]
oca
ldomain as my envelop sender address, despite I have:
On Tue, 06 May 2008 09:48:18 EDT, David Levine said:
Anders writes:
[EMAIL PROTECTED] said:
I thought that draft_from couldn't be enabled in a .mh_profile so that th
e
installer could restrict its use. To preserve that capability, how about
just defaulting masquerade to be enabled
On Wed, 21 May 2008 11:47:58 EDT, Paul Fox said:
now, i'm about to find myself in a job situation where it would
be very convenient to be able to read mail on my laptop when
disconnected, primarily during commute time. i could envision
installing all my mh scripts on the laptop, inc'ing the
On Thu, 24 Jul 2008 15:18:26 PDT, Eric Gillespie said:
Stupid CVS, I can't remove a file locally without commit access.
If someone commits this, please cvs rm -f it first. Any chance
you could switch to something modern? Savannah supports (or will
soon) Bazaar...
*NO*.
cvs, svn, monotone,
On Thu, 24 Jul 2008 18:35:45 PDT, Eric Gillespie said:
-To: T=C3=B6m =C3=98rley [EMAIL PROTECTED]
It occurs to me that maybe, just maybe, this example Deserves To Lose,
as it's lacking any RFC2047 markup. It probalby *should* read
To: =?utf-8?Q?T=C3=B6m=20=C3=98rley
or some similar.
(Hint -
On Tue, 09 Sep 2008 11:41:43 EDT, [EMAIL PROTECTED] said:
Below you can find the diff (suitable for feeding to patch(1)) against
mhfinddup 1.2.
Possible enhancement for 1.3 - I'd code and test but am swimming in other work
today...
$msgs{$msgid} =~ m|^\+(.*)/(\d+)$|;
On Tue, 09 Sep 2008 12:59:50 EDT, [EMAIL PROTECTED] said:
Possible enhancement for 1.3 - I'd code and test but am swimming in other work
today...
Obviously true, because...
if (exists $cached{$folderpath/$m}) {
$sum1=$cached{$msgid};
should be
On Fri, 09 Jan 2009 11:23:00 EST, Ken Hornstein said:
I was doing some work on the smtp code for nmh, and I couldn't help noticing
that it has no IPv6 support.
Go for it.
A few particular corner cases to make sure we handle right:
1) IPv6 is supported, but not enabled on the system (no
On Tue, 13 Jan 2009 13:13:52 EST, Ken Hornstein said:
the code in client.c calls getnetbyname() on this name and then
iterates over all of the hosts available (using gethostent()) and tries
to connect to every server on the named network.
*boggle*. :)
I suggest heaving it over the side as
On Tue, 13 Jan 2009 13:19:05 EST, Ken Hornstein said:
Oh, more old crap the KPOP code in sbr/client.c only supports
Kerberos V4. Since Kerberos V4 is way long in the tooth nowadays
and nmh supports Kerberos V5 via GSSAPI and the Cyrus SASL library,
as part of the general cleanup of
On Tue, 27 Jan 2009 21:57:50 +0100, Anders Eriksson said:
Unfortunately, today's broken internet infrastructure has removed this useful
feature from the mail system. If more MUAs implemented a Guaranteed Delivery
Service out of the box, maybe we can get proper connectivity reinstated?
wishful
On Mon, 16 Feb 2009 09:17:44 PST, belg4...@pthbb.org said:
Alternatively, the package is LGPL, so why not include it with nmh? It's not
obvious where people should acquire liblockfile, as there is no official site
for it, and distro's often add weird deps. Luckily debian's 1.08-3 works.
I've
On Tue, 18 Aug 2009 11:33:51 EDT, berg...@merctech.com said:
Is there a way to use rcvstore to refile messages to a specified folder
without
changing the default folder?
Umm.. run procmail with a different value of $MHCONTEXT so its folder changes
don't interfere with yours?
Potentially,
On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said:
TLS seems to be already solved. However, why does nmh need TLS?
Doesn't it delegate mail transfer to an MTA?
You may need it to talk to a remote MTA that insists on doing TLS. And
there's valid use cases for it.
Half the time my laptop
On Thu, 28 Jan 2010 11:04:15 +0100, markus schnalke said:
Use a simple forwarding MTA (like nullmailer or ssmtp) instead.
Still more complicated than the one-line change to one file it took to change
the SMTP server in nmh. ;)
For the user, shipping an own forwarder is not much different than
On Wed, 03 Feb 2010 13:56:40 CST, Earl Hood said:
A descision to be made is the work I have currently
done worth rejecting because it fails to address all
(less probable) cases, or accept it now for something
better than what currently exists and then improve
upon it later?
Given that the
On Tue, 05 Oct 2010 13:46:17 PDT, Lyndon Nerenberg said:
The utmp changes need to be guarded with '#if __FreeBSD_version =
90'. Otherwise this won't compile on 8.x or earlier.
Not all the world is FreeBSD. So make sure there's a #else/#endif for the
rest of the world.
What should the
On Tue, 05 Oct 2010 14:43:01 PDT, Lyndon Nerenberg said:
On 10-10-05 2:14 PM, valdis.kletni...@vt.edu wrote:
What should the code do on systems that have both utmp.h and utmpx.h?
utmpx is the new POSIX flavour, so I'd defer to it over utmp in that case.
Sorry, my mind blanked for a bit when
On Thu, 04 Nov 2010 17:12:06 EDT, Mike O'Dell said:
there's no Kerberos V that I know of.
V4 was officially End-of-Life'd several years ago:
http://web.mit.edu/kerberos/krb4-end-of-life.html
V5 has been around for a while. See RFC1510, from 1993.
1510 The Kerberos Network Authentication
On Sat, 06 Nov 2010 11:08:52 +0700, Robert Elz said:
Date:Fri, 05 Nov 2010 21:27:33 +
From:Peter Maydell pmayd...@chiark.greenend.org.uk
Message-ID: e1petor-0002hx...@mnementh.archaic.org.uk
| [Aside: 'columns' is
| usually the same as 'characters'
On Mon, 08 Nov 2010 21:06:04 +0100, markus schnalke said:
[2010-11-05 22:34] markus schnalke mei...@marmaro.de
A second try for removing only what install-mh(1) installs:
ctx=${MHCONTEXT:-`mhparam context`}
case $ctx in
'/*') rm $ctx ;;
*)rm `mhpath +`/$ctx ;;
On Fri, 05 Nov 2010 15:36:59 BST, markus schnalke said:
nmh currently includes the reference MD5 implementation of RFC 1321.
Unfortunately this has a ``problematic'' license. I dealt with this
for another software project and asked on the debian-legal mailing
list where concerns were
On Tue, 09 Nov 2010 09:15:33 PST, Lyndon Nerenberg (VE6BBM/VE7TFX) said:
Does nmh work usefully on any boxes that don't have OpenSSL
available? If not, can/should we just punt and use the OpenSSL
version?
Seems like a pretty blunt instrument for an md5 implementation.
I've seen bigger
On Wed, 10 Nov 2010 13:30:28 EST, Ken Hornstein said:
You know, I'm wondering what purpose that display at the end serves; maybe
it should just be ripped out?
It's incredibly useful for catching stuff before you say 'make; make install'
and end up with stuff in directories you didn't expect,
On Fri, 12 Nov 2010 19:50:06 PST, Jon Steinhart said:
I'm starting to look at writing new code to handle reading MIME messages
as per the earlier discussion. My plan is to write a completely new
version of scan for people to play with, and to replace the original only
when consensus is
On Fri, 19 Nov 2010 18:56:03 EST, Ken Hornstein said:
Yeah, that's exactly what I was thinking (and really, why would setting
CPPFLAGS/LDFLAGS be unacceptable for packaging distros? That's the way
nearly every other autoconf package works).
The way every other autoconf package works is that
On Sat, 20 Nov 2010 12:33:48 +0100, Oliver Kiddle said:
mh-format(5) stuff. But Python with its weak typing tends to be almost as
bad as Perl for long-term maintenance.
I think it's safe to say that based on our experience thus far, anything with
weaker typing and required variable declaration
On Tue, 30 Nov 2010 15:53:02 +0100, markus schnalke said:
The new profile names are: `attachment-header' and
`attachment-format'. (attach_fmt should likely be a char* too.)
What if exmh (which uses nmh under the covers)
Of course, the changes will break compatibility but for a saner
On Thu, 02 Dec 2010 19:18:30 +0100, markus schnalke said:
My patch however does break compatibility if one likes to send
messages that contain non-ASCII chars without MIME.
Sending non-ASCII without MIME is against the RFCS, and shouldn't
be allowed. This is one case where intentionally
On Tue, 07 Dec 2010 12:03:38 CST, Earl Hood said:
On Tue, Dec 7, 2010 at 11:10 AM, Jon Steinhart j...@fourwinds.com wrote:
I understand that my attachment system does not handle non-ASCII message
bodies, but again, that's because non-ASCII message bodies are not legal.
Please cite an RFC
Current -git tree:
% inc -help
inc: no mail to incorporate
% inc -version
inc: no mail to incorporate
This used to work:
% ~/src/nmh.hold/uip/inc -version
inc -- nmh-1.2 [compiled on turing-police.cc.vt.edu at Tue Feb 19 18:35:11 EST
2008]
% ~/src/nmh.hold/uip/inc -help
Usage: inc [+folder]
On Tue, 21 Dec 2010 15:28:01 GMT, Peter Maydell said:
Also, given that we basically have all the information about
accepted switches in the ansp parameter, it would be cool if we
could pass that along to readline so tab completion completed
commands rather than just filenames. This in
I've hit a corner case of send/post getting confoozled when my VPN
connection died while sending.
Almost certainly relevant is my .mh_profile entry:
post: -msgid -server auth.smtp.vt.edu -port 587 -tls -sasl
My VPN connection evaporated during the send, and post got hung spinning
on 100% CPU
On Sat, 05 Feb 2011 12:23:51 PST, Lyndon Nerenberg said:
Adding the index/cache files to the native MH file store would make most
MH commands blazingly fast, the obvious benefits being to scan and pick.
I've seen this idea several times, and I always have the same question - how
would we deal
On Mon, 07 Feb 2011 08:54:13 GMT, Peter Maydell said:
Dunno if 100 chars will be enough if and when we finally add
enough MIME support for scan to do something sensible with
MIME-encoded bodies (ie print the start of the text/plain bit).
Keep in mind that there isn't any requirement that the
On Mon, 07 Feb 2011 17:13:21 GMT, Paul Vixie said:
1. mhshow should not exist, we should merge its functionality into show.
Amen.
2. mhstore should not exist, we should merge its functionality into burst.
Amen.
3. text/plain with long lines should be word wrapped (via fmt or similar.)
On Tue, 15 Feb 2011 14:53:42 GMT, Paul Vixie said:
on the strength of observations made by somebody else here recently, i tried
moving my mail store from ZFS to UFS.
scan results for +inbox, ~4000 messages.
UFS (3Ware mirror):
0.114u 0.076s 0:00.21 85.7% 138+1461k 1+0io 0pf+0w
ZFS
On Tue, 15 Feb 2011 16:12:42 GMT, Paul Vixie said:
From: valdis.kletni...@vt.edu
Date: Tue, 15 Feb 2011 10:42:34 -0500
00.21 versus 33.47? I'd really investigate hot/cold cache effects
there. If you just moved it to UFS, a copy is probably still in
cache. Any way to flush the
On Thu, 17 Feb 2011 08:19:50 GMT, Paul Vixie said:
and i'd agree. similarly, when uw-imap started vacuuming up my whole
home directory rather than just my Mail subdirectory, and i found out
that the default is ~ and my client had not overridden this, i knew
that technical correctness was not
On Thu, 12 May 2011 14:09:29 EDT, Ken Hornstein said:
- Client systems are configured with short hostname.
What's the solution here? If we do what you suggest, nmh will have a
functionality regression.
Short hostnames are evil, doubly so if the config allows them to escape on the
wire.
On Tue, 06 Dec 2011 09:08:13 GMT, Tethys said:
Ken Hornstein writes:
Specifically, scan can decode RFC 2047 headers, but it seems that show
cannot (okay, mhshow seems to decode some headers, but not others).
I'd say you've got that the wrong way round:
scan is clearly not decoding
On Tue, 06 Dec 2011 15:32:28 +0100, Andreas Wittkemper said:
This one is really annoying and should be done better. In our work environment
we have a exmh/nmh group email box and this gives us headaches every time.
I've been getting close to getting peeved enough at exmh's behavior on replies
On Mon, 05 Dec 2011 21:03:40 EST, Ken Hornstein said:
I am thinking of making the nmh libraries
While we have the phrase nmh libraries on the table, would it be interesting
to convert sbr/libmh.a into a .so that can be embedded into other projects?
I'm thinking that exmh could use that in a
On Tue, 06 Dec 2011 13:07:41 EST, Ken Hornstein said:
several times though, so perhaps it's worth revisiting. Valdis, are you
willing to pick up the exmh/Tcl work to use a shared library for libmh?
Sure, if it simplifies the Tcl code. Probably would end up being a exmh 2.0
requires at least
On Sat, 10 Dec 2011 12:27:00 +0100, Yoshi Rokuko said:
I disagree, one should break up the MIME parts. There is not value in
keeping MIME beasts in your file system. If it's encrypted MIME there
should be a command that decrypts and detangles mails. Why store a
mail encrypted on your
On Sat, 10 Dec 2011 20:56:44 EST, valdis.kletni...@vt.edu said:
Unfortunately, for signed mails, it's quite often the case that you will need
to re-verify the signature at a later date. If 6 months later you need to
produce the mail your boss sent, you're probably going to want to be able to
On Sun, 11 Dec 2011 10:36:15 GMT, Jon Fairbairn said:
to. Perhaps all I want is a -symlink option for refile and a
guarantee that all mh progs can be told to treat symlinked
messages as if they were linked?
OK, that raises a good question - if we're doing an overhaul of the code, what
On Sun, 11 Dec 2011 19:20:10 EST, Ken Hornstein said:
I personally would like to see nmh declared end-of-life for non-UNIX-like
systems. There's a lot of cruft in the code from these days the understandng
of which is a barrier to getting new work done.
I see a lot of stuff in there for older
On Sat, 24 Dec 2011 13:33:10 PST, Lyndon Nerenberg said:
Well I managed to completely f*ck up my local posix branches in GIT.
Could they possibly have made remote branch management any more obtuse?
Just be glad they didn't use the CVS model of branches. :)
pgp37Poi3Uhn7.pgp
Description: PGP
On Sat, 24 Dec 2011 13:44:27 PST, Lyndon Nerenberg said:
On 2011-12-24, at 13:42 PM, valdis.kletni...@vt.edu wrote:
Just be glad they didn't use the CVS model of branches. :)
I LIKE the CVS model of branches!
OK, you got me there. CVS does branches just fine. It's merges that totally
blow.
On Sat, 24 Dec 2011 18:01:44 PST, Lyndon Nerenberg said:
Will replacing vfork() with fork() seriously impact nmh performance on
any current UNIX variants? (How many VAX users do we still have?)
fork() should be almost as cheap as vfork() on any system that has a
sane memory manager that does
On Mon, 26 Dec 2011 20:29:37 EST, Jeffrey Honig said:
If I remember right, m_getfld.c tries to eek the most performance out of
header field scanning by taking advantage of knowledge of the stdio
structures to peek further into the buffer and do an optimized ungetc().
Wow, is *that* what it
On Thu, 05 Jan 2012 11:55:25 EST, Ken Hornstein said:
In the garbage collect old crap vein ...
I've noticed that there are a number of places that are #ifdef UCI.
They turn on various random things (like, if you have a file called
.signature in your home directory, it will use it as the
On Mon, 09 Jan 2012 19:26:38 PST, Lyndon Nerenberg said:
Lua isn't that bad, syntax-wise. I speak from too much experience with TCL
;-)=
TCL isn't that bad, actually. Except for the quoting rules. :)
pgpOc4xBiyYUC.pgp
Description: PGP signature
On Tue, 10 Jan 2012 18:36:59 EST, Ken Hornstein said:
regression. Okay, I would agree that it's a bit bogus to send email from
yourself and cc'ing yourself, but I can see it happening.
Actually, I know a lot of people who will cc: or bcc: themselves on important
mail, specifically so that
On Thu, 26 Jan 2012 10:22:26 PST, Bill Wohler said:
Definitely need to treat quoted text ( or some supercite format) as
pre-formatted text and not touch it.
Debatable. I've had to reply to far too many e-mails that contained
some sort of line that went on for ever and ever off the right side
On Thu, 26 Jan 2012 14:35:42 EST, Ken Hornstein said:
- An option to disable any kind of line breaking in mhl.
- An option to filter mhl content through a program. I'm thinking maybe
a flag like format and using a mh_profile entry called formatproc.
GIven those two, I think I've convinced
On Sun, 05 Feb 2012 11:16:20 EST, David Levine said:
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
On Mon, 06 Feb 2012 07:11:57 PST, Lyndon Nerenberg said:
No, you need to download text parts. It would be pointless to download the
15 multi-MB TIFF attachments as well.
The fact it's text doesn't imply it needs downloading. I regularly get
logfiles from
our NetApp that run to 4M in size -
On Mon, 06 Feb 2012 11:51:04 MST, Joel Uckelman said:
in 'mhpath'. Maybe we could add 'mhurl' to produce URLs (and file: URLs
for local storage!) and leave mhpath producing paths?
m-hurl. What has been seen cannot be unseen. ;)
pgpLvQ2xPjlNU.pgp
Description: PGP signature
On Mon, 06 Feb 2012 22:41:14 EST, Ken Hornstein said:
I'm not changing the way nmh works, Robert. It already does that today,
as shipped, by default. All I'm proposing is that we remove the code that
lets you turn off that behavior ... because it's a gigantic mess and
I can't see the point
On Tue, 07 Feb 2012 10:14:53 +0700, Robert Elz said:
Really? How do you propose making that work? Look at the From: header
of this message
One wonders how many MUAs out there choke at that. Does Outlook/Exchange
manage to cope with that?
Please read the mail standards before proposing
On Mon, 20 Feb 2012 18:41:52 GMT, Ralph Corderoy said:
Alexander Zangerl wrote:
Content-Type: multipart/mixed;
boundary4345720567471976529==
Does anyone else have trouble displaying the meat of this email with nmh?
For whatever it's worth, exmh didn't have any trouble with
On Wed, 29 Feb 2012 09:49:08 GMT, Tethys said:
PS. That was the paper that introduced me to the world of MH, some
time in the late '80s. At the time, 200 messages a day was an
inconceivably huge number. At the peak of the spam problem a few
years ago, I was getting over
On Thu, 15 Mar 2012 18:02:48 PDT, Jon Steinhart said:
And yes, having defaults for common content types in the profile would
be a good thing. At the time that I wrote this stuff suffixes were not
nearly as standardized as they are today.
Wow. Maybe somebody should gather them all up into a
On Sun, 18 Mar 2012 22:15:17 -0400, Ken Hornstein said:
Looking at things ... it may be a simple fix, actually. I wasn't
envisioning any changes to m_getfld(), that's for sure.
Alright, I think I've got a fix in there, and I've got a test which exercises
the bug. I was right that the fix
On Fri, 30 Mar 2012 23:51:05 -0400, Ken Hornstein said:
But that got me to thinking - maybe I could have a more intelligent
formatproc that could handle MIME? Since the formatproc only has
access to the message body (don't ask; that is NOT easily fixable),
It's not as bad as all that - if
On Wed, 25 Apr 2012 11:28:05 -0500, Ken Hornstein said:
Today you can do:
pick -before -180 -and -after -365
D'Oh! -- H. Simpson.
Thanks for shaking that fact loose from some overly stubborn neurons. :)
pgpsvqZEQDFnO.pgp
Description: PGP signature
On Wed, 23 May 2012 21:46:21 +0100, Tethys said:
Yes, but I'm also lying. It turns out that what I was seeing was
a bug in xterm and show does display the message correctly in a
terminal. However, exmh doesn't :-(
What release of exmh and nmh are you on, and what font are you using for
the
On Wed, 23 May 2012 10:50:11 -0700, n...@dad.org said:
After I sent the attached Email, last February, Ken Hornstein solved the
dilemma it posed by telling me about the -server localhost option to send.
Until a few weeks ago, everything was fine. Then I started getting the same:
Received:
On Sat, 26 May 2012 16:20:33 -0400, Ken Hornstein said:
As long as we're looking at that code, we probably want to do an audit to
make
sure that we aren't using isspace() anyplace to detect rfc822 ascii-ish
'whitespace'. I've seen the hilarity that ensues when the mail system at one
end
On Tue, 29 May 2012 10:01:22 +0100, Ralph Corderoy said:
No `#'? How about just always send to the user's shell from the
password entry with a -c, as distinct from /bin/sh.
The problem is that some people (at least in the Elder TImes) would have
their login shell set to /bin/csh but they'd
1 - 100 of 240 matches
Mail list logo
