Greetings all,
I just committed support for external filtering inside of mhl. It only
works on the message body, but I still think it's useful (trust me, it
was too hard to make it work in the general case).
The man pages have more detail, but basically you want to put something
like:
for years.
The following patch should fix it. I am now mulling over whether
to release a 1.4.1 or a 1.5.
--Ken
commit 01943d78230ead5bcc568e8a87d3cdbaac1f5584
Author: Ken Hornstein k...@pobox.com
Date: Wed Jan 11 14:48:45 2012 -0500
Fix two errors in the conversion to m_mktemp2
... I am now mulling over whether to release a 1.4.1 or a 1.5. --Ken
if we're going to do 1.5 then let's get all of the posix, ansi, and
ifdef-removal work done and in.
We haven't done a branch for 1.5 yet, so anything we would do would be
from the tip of the master branch.
I've been using
Alright, here are some things I've been thinking about in no particular
order:
- I think we have enough new stuff that a new release based on the tip
of master is worthwhile. Let's call it 1.5, since it doesn't feel
fresh enough to me to make it a 2.0. I'd rather invest my energy in
doing
I propose we have a new .mh_profile entry that is used as the default
From: when one isn't supplied in a draft. Objections?
I would rather we use the existing components framework to do this.
Growing a new option is just bloat, IMO. Thus my comments a few weeks
back about having the installer
i think that we should not emit a From: without an @FQDN, or fail to
emit a From:. if the components file did not give us a From: then we
should autogenerate From: `whoami`@`hostname` and let the gods sort it
out.
So that's what we _used_ to do. I kinda punted on that a bit. Turns out
that
On 2012-02-03, at 10:59 AM, Ken Hornstein wrote:
I thought about this ... but that would mean we ditch the installed
system components files completely, and it's not clear what we do for
existing users.
I would use the system-side components as the template to populate
the user's components
Alright let me see if I've captured the consensus:
- Make the default email address be (in decreasing precedence order)
- A knob in .mh_profile (Local-Mailbox ?)
- `whoami`@mts.localname
- `whoami`@`hostname`
- All drafts get run through mh-format
- All default component files now
- If there is a draft without a From that is fed to post, it will error
erp? What sort from From is it going to require? I currently use
From: me
No requirements other than it exists and is parsable by nmh (any
From: line that exists today has to be parsable by nmh). If you
just have that,
Isn't that what the (now poorly named) Signature mh_profile entry
does? I used to use it for this purpose, anyway.
All that Signature does is serve as a replacement for the GCOS field
from /etc/passwd. mh-profile(5) specifically says to not put an address
in there. So we need something else.
Would somebody be willing to tell me how to download the 1.4 sources?
In addition to what Paul said, if you go under the nmh web page on
savannah (https://savannah.nongnu.org/projects/nmh/) there is a tab
up top marked Source code. You can get brief instructions on how to
use git, but if you
(for those new to git -- the links that ken pointed out don't point at
physical tarballs -- when you click, a tarball is created on the fly,
based on the tag that ken attached to that point in the git repo.)
One more followup :-)
It occurs to me that those auto-generated tarballs will require
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.
I think we can divide locking into two categories - the mail spool, and
On CentOS 5, I get the following compile time errors:
reference to `tgetnum' termsbr.c:(.text+0x132): undefined
[...]
reference to `tgetnum' termsbr.o: In function `SOprintf':
termsbr.c:(.text+0x1be): undefined reference to `tputs'
termsbr.c:(.text+0x1f9): undefined
In the IMAP case, you don't want to download the entire message just to
satisfy an mhpath request. The value in IMAP is its ability to treat
MIME sections as separate objects. By sucking down entire messages, all
you've done is downgrade IMAP to POP.
I understand where you're coming from, but I
No, you need to download text parts. It would be pointless to download
the 15 multi-MB TIFF attachments as well.
Huh, I guess I was thinking that you had to download the whole message
body, but I guess I shouldn't go up against an IMAP expert like you :-)
I took a closer look at RFC 3501 and I
It's not that hopeless. If the IMAP server supports the METADATA
extension (and most modern servers do), we can almost fully support
anno.
So ... looking at RFC 5464 ... for anno you would do something like:
SETMETADATA INBOX (/private/nmh/${imap-uid}-anno Replied: Mon, 06 Feb 2012)
As I
i didn't know about user_extension until just now. it's a pretty modern
feature, as these things go, though it would probably be more generally
useful if it allowed for substituting the entire username, rather than
just appending to it. in any case, i suspect it's a new enough feature
(the man
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?
I must have had some reason for it once, but I can't recall what that
would have been now. If I don't have this, I presume post will be used
instead. It's
yes! please either keep it, or improve post by giving it a switch that
allows it to submit mail to an mta/msp program directly.
E ... you know about the sendmail mts, right?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
yes! please either keep it, or improve post by giving it a switch that
allows it to submit mail to an mta/msp program directly.
E ... you know about the sendmail mts, right?
i do indeed - but post always talks smtp, even with mts: sendmail.
i need something that submits to a program on
Really? How do you propose making that work? Look at the From: header
of this message, which should be the same as the From: header in the
draft that I am currently typing, and try to figure out how to make that
fit the rules for the envelope from.
I'm not changing the way nmh works, Robert.
Which brings up a question - is it sane to try to support
per-destination customization? I can probably do the things I'd want
in replcomps and friends, *if* there was a way to say emit this header
for matches in 'to' for this pattern, but emit this other header for
non-match recipients.
You
I didn't get to see what was inserted in the message I sent before, I
didn't cc it to myself, and the list replaces the Sender with one of
its own choosing (and without altering the Message-ID, which is broken
behaviour, not that that is relevant to nmh).
Well, the off-list copy you sent me had:
sorry. i was rambling. i'm only saying that it should be dropped,
because, a) it's a pretty new feature, so there are probably people
actively using it, and b) it's quite a useful feature -- on the fly
modification (albeit limited) of the From: address, in a way that caters
to the
Please don't reduce nmh to being just another mailer in the as long as
it works with outlook it is OK camp that so many others have fallen
into. It must continue to be semantically, as well as syntactically,
correct. Even if the code to do that is not easy to make work, or
understand.
Well,
i think it's itinerant upon those who think this should be done, to walk
the walk. i also think that intermediate products such as example API's
and proposals should be shared with the whole list. and lastly i think
that silence will equal assent :-).
Okay, I can see your point. I was going to
I don't understand that, I've used multiple identities, without any
particular difficulties, for a long time now ( 20 years), and MH (and
later nmh) just works as it is. That is, to say, in this area I see
no need for any changes, and consequently no need for any code to be
developed.
Well,
441 12/18 Joel Uckelman o [Nmh-workers] mhshow: invalid QUO
442 12/18 Josh Bressers +oRe: [Nmh-workers] mhshow: invalid
443 12/18 Paul Fox +oRe: [Nmh-workers] mhshow: invalid
444 12/18 Joel Uckelman |+o Re: [Nmh-workers] mhshow: invalid
448 12/19 To:nmh-worker |
On the other hand, I personally don't think any of this is important
enough to spend a lot of cycles on, this isn't an area where nmh is
really deficient.
Well, I respectfully don't agree. You admit yourself that your
setup is unusual; you control all of the components (including DNS)
yourself.
Folder name completion was what I wanted for. I guess that it's not to
be.
I did work out the tcsh(1) spell for that in another millenium, these
days I use bash as it's what to hand.
Note that in docs there is also COMPLETION-TCSH and COMPLETION-ZSH. Might
be worth putting this snippet in
Greetings all,
With the encouragement of David Levine, I am pleased to announce that I've
reworked the test suite so it now functions nicely with Automake. To use
it you can run make check. It also gets run automatically as part of
make distcheck. I think I've got it right, but please let me
checking for dbm in ndbm.h... no
[...]
Hm.
The obvious place to start is config.log. Look near the end; you want to
find the part where you started checking for stuff and see what errors
you got. That should get you started.
i have libgdm-dev and libgdm3 installed, and i don't see any
gdbm doesn't provide ndbm compatibility unless built with a particular
switch.
FWIW, we seem to have a db-devel package on our Linux systems that
does the right thing.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
FWIW, we seem to have a db-devel package on our Linux systems that
does the right thing.
Is that Berkeley DB? We have libdb-dev but I'm not sure it helps here.
Yeah, db4. You get prototypes for the old dbm interface if you
define DB_DBM_HSEARCH ... which, coincidently, we do :-)
(Actually,
Thanks, Paul, I've applied this patch (and your other one).
And thanks for using git format-patch!
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
As previously discussed, I've been looking at putting the From address
in message draft via extensions to the format language (the existing
syntax doesn't have that ability).
I see two possibilities as to how to implement this:
- A new function, e.g. %(localmbox).
- A new pseudo-component, e.g.
it's completely possible that i'm misunderstanding the previous
consensus, but i sort of thought that after allowing for a knob in
mh-profile (which is satisfied with just the first half of what
you just suggested), the second 2nd and 3rd bullets in the list you
referenced would be handled outside
Okay ... so now that's been cleared up :-)
Do people like the idea of:
- A dedicated function %(localmbox)
- A pseudo component %{localmbox}
- Extra primitives to build the default local mailbox (%(myname), %(myhost)).
?
--Ken
___
Nmh-workers
If you go with a pseudo component, I recommend using a well-defined
prefix for it to avoid any potential collisions with a real component.
Fair enough ... but getting back to the higher-level question ... any
thoughts there? :-)
--Ken
___
Nmh-workers
names. username is a bit ambiguous ... does
that mean kenh or Ken Hornstein? It's easy enough to change those
names if people can come up with something better. And it worked out
I didn't need to create any format instructions, which was a relief.
--Ken
I've just put a small new section in mh-format.5 called Other Hints and
Tips to help document some of the oddity surrounding the format syntax.
I had two questions for everyone:
- If you have some free time, would you be willing to take a look at that
section and give some feedback?
- If you
Sigh. This just keeps getting more and more addictive; every time I try
to something with the format language, I can't help thinking, Man, this
would be easier with a REAL embedded language. But that would take
too long, so I'm stuck nibbling around at the edge.
Anyway ... when working on the
A project where I'm one of the primary developers is in the planing
stages right now for replacing an awful, grotty template language which
accreted on our program over time. One one hand, I would say that the
sooner such things are replaced, the less pain there is overall. On
the other, the MH
norm: loses; [USER] 550 5.1.1 norm... User unknown
post: 1 addressee undeliverable send: message not delivered to anyone
So, I'm wondering ... previous version of nmh worked fine, is that
right? What version did you have previously? If you still have that old
version of nmh around,
As a side note ... Norm, when I try to reply to your message, I get
the following warning from repl:
repl: bad addresses:
nmh-workers@nongnu.org n...@dad.org -- junk after local@domain (norm)
nmh-workers@nongnu.org n...@dad.org -- junk after local@domain (norm)
This happens
I've never liked fcc: and always dcc: myself instead.
Just curious ... why? I mean, either way works, and it doesn't really
bother me that people don't like Fcc, but I just like to understand how
other people use nmh.
--Ken
___
Nmh-workers mailing
correct From: and a Message-ID, amongst other headers I'm not so
concerned with.
Fair enough ... two notes, however:
- You can have send/post add a Message-ID header with the -msgid flag,
and that ends up in the saved message if you use Fcc (just checked
that).
- I think you _might_ have
Has the default of the --with-mts= configure option changed at all
recently. I was suprised to have to specify --with-mts=sendmail when I
recently rebuilt the Nmh that I use daily.
If I'm reading the logs correctly, that's actually been the default
since Doug Morris took over from Richard Coleman
Is there any way I could change it for a single message, short of
modifying mts.conf -- maybe some kind of entry in .mh_profile or
something? Note that messages for which I will want to this will have
exactly one addressee, norm.
Ah, okay, I understand ... and now that I think about it, yes!
I see this has been covered in some detail but I really need to know
if there's an override for the 998 character line limit when building
a message for sending? We're attempting to migrate to nmh for a
production system and the current one allows lines of apparent unlimited
length - is there an
Apologies for the vagueness. By current one I'm referring
to our existing X400 gateway accessed via Clearswift MTA software, with
SMTP conversion done by a third party.
Our belief now is that at some point in that submission processes the
lines are split with CR/LF under the Clearswift route,
The long lines are being produced by a bespoke C process,
running on Solaris, and the data is EDIFact formatted. These output
files are fine up until the point I call mhmail and by the time it
gets through our Exchange gateway it comes back with exclamation marks
in it ~every 998 characters.
When looking over forw today, I came across the code that handles digests
(which I guess is the companion code to burst). So, I was wondering ...
do people use this? I'm not really suggesting it be removed, I'm just
trying to understand the use cases.
--Ken
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?
--Ken
___
Looks like the MH User's Manual. I found a copy here:
ftp://ftp.vim.org/pub/mail/mh/doc/MH.ps.gz
Hm. Can people actually view this? I tried printing it out and it
died with a PostScript error. I tried opening it on my Mac and it
could only view the first page; the subsequent pages were all
I don't suppose anyone is around who still has the original source to
this thing, do they?
Following up myself ...
I found it! It's in the original mh-6.8.4 source, under conf/doc! Yeah,
we should totally get that in our git tree. It's going to take some love to
extract it from the original
Okay, for those of you that haven't been paying attention ...
The code in git now has comp forw run their component files through
mh-format, and as soon as the git repo comes back up dist will do
the same thing as well. This is all tied into the add a From:
header to all outgoing drafts thing
as Paul implied, troff input is perfectly usable, very much more so than
MSWurd or the Prodigal Data Format
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
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
So I was foolishly working on burst in terms of cleaning it up, fixing
long-standing bugs in it ... and I wrote a test for it. And it was at
this point I realized ... this thing couldn't have worked right.
Specifically, if there is text after the last encapsulated message, then
it ends up as a
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
I just committed some changes to post, and I wanted to give people a
heads up and solicit some feedback.
The changes to post include the previously-discussed requirement
that a From: header is now required in message drafts. But as always,
there are wrinkles.
The discussion I had with Robert
On 1/27/2012 2:07 AM, Ken Hornstein wrote:
Okay, you've convinced me. I've also got my finger on the fire photon
torpedoes button. Does anyone want to speak up for m_getfld.c before
we decide to relegate it to the dustbin of history?
noone spoke up.
is there any interrim cleanup happening
Right now From: has to be set in components, replcomps, replgroupcomps,
etc. I currently rely on From: being set from the GECOS and localname:'
option from mts.conf so I don't have to set From: in all those comp
files.
If you make the above change, will there be an .mh_profile way to set
the
But there is another issue that we need to address. Envelope-From:
is a valid message header. It's remotely conceivable that someone
might have a need to use it for another purpose. And there are other
SMTP parameters that it might be useful to set, e.g.: deliver-by.
I don't like the
The only portion of the one I have here that seems at all relevant is
this:
For file names with dot suffixes, the context is scanned for a
mhshow-suffix- entry for that suffix. The content-type for
the part is taken from that context entry if a match is found.
If no
Hell, it's not even that much of an edge case. It's a reasonably common
situation, and it silently fails by simply relinking the @ for each new
reply. Unless anyone has any strong rationale for keeping it around (and
I haven't seen any posted here so far), I'm all in favour of nuking it
Full disclosure: I am using NMH version 1.3. Alas, version 1.4 has not
been ported to FreeBSD yet. (Is this the real root of the problem?)
When you say not ported ... do you mean, It doesn't work when I
tried to compile it?, because that's a serious problem. Or do you
mean, Not in the ports
Anyway ... check out the man page for mhshow. And also mhn.defaults
has an example.
Hm, I realize now that attach does NOT CHECK mhn.defaults! Whoops.
Looks like you have to do extra work to make that happen.
Alright, so I just fixed that ... and I added a smattering of common
content types to
Better mime handling in repl/forw ? Ok, maybe that is too much to ask.
But an option for repl/forw which simply drops attachments shouldn't
be too complicated. Unfortunately I can only hope this request is
category a) stuff.
Sadly, it's complicated. See previous discussions on the list. I wish
Rather than proliferate switches, why not begin deprecating it, by first
making it something that must be explicitly enabled in build?
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
Watching Ronald Guilmette struggle through making the attach command
work, I decided that this stuff should be cleaned up. I understand
Jon Steinhart's initial reluctance to make attach turned on by
default, but it's been in there for a decade now and I haven't seen
any complaints about it (other
Wow. So I'm not hallucinating (at least not this time :)
Been seeing this, haven't had a chance to track it down. Looking at
exmh's .xmhcache files, I have 145,141 total messages listed in
.xmhcache entries, and the bug is affecting 3,266 of them. So there's
an anectodal value for the=
Since I started using mh-v, for about two months, I've been keeping a
pretty close eye on making sure scan and mhshow work perfectly. This
week collected four msgs where the decoding %{body} is truncated after 6
to 16 characters with v1.2 and v1.4!
Okay, Steve was nice enough to give me a test
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 :-)
It's sort of Steve's setup that triggers it; not only does he have a bunch
of Received: headers, but a huge spam score report, a
I'm using the latest source (and autogen.sh) now, and scan does work
properly. Thanks.
What a relief! Glad it works! I was totally stumped, because I was
sure I fixed it.
I know that you know this now, Steve, but for everyone else: autogen.sh,
at the top level of the source code tree, should
Okay, this has been bugging me for a little while now, and it's a little
confusing. But please follow along.
Last month I complained about messages Norman Shapiro was sending,
because they contained multiple cc: lines which technically isn't
valid according to the RFCs; these messages made repl
I know this was six years ago, but I'm wondering if a) you remember
exactly what you were trying to solve and b) if we could fix it another
way. I have thought about various code fixes but they all have issues.
We have the %(trim) function available in mh-format; we could always use
that instead.
Yes, I know I've followed-up to myself twice. Sorry about that.
So the bug report that prompted this change is here:
https://savannah.nongnu.org/bugs/?4360
Some more history shows me that Glenn Burkhardt commited a patch shortly
after that to trim whitespaces from References headers
Well, what if GNU Mailutils folks buy these changes? Then they would
have to change the header fields to mailutils-* which would be annoying.
Worse, it would then make the header fields incompatible when in fact
they would be compatible.
This header is just an implementation wart ... it's really
And this is why it's wrong to pretend they are headers. It leads to
exactly this sort of misunderstanding. I still say the syntax should
chance so there's no confusion as to what they really are - meta
commands to nmh programs.
I don't disagree with you, but I am
Yes, it would be awesome to prepend git's history with the original
RCS files. That could probably be done by exporting the git
repository, started anew, importing the RCS files, and then importing
the exported git repository.
Thanks for the approach, it sounds doable but not by me at this
But that got me to thinking - maybe I could have a more intelligent
formatproc that could handle MIME?
I havenât been following the discussion very closely, but what strikes
me is, are you saying that itâs difficult to arrange (within mh) that
a different formatproc is called (for each mime
Shouldn't take much more than
#after opening for reading
binmode(IFH, ':utf8');
#before writing
binmode(OFH, ':utf8');
to fix your formatting script.
That's not the problem; the perl script handled UTF-8 just fine. It's
just that nmh didn't know what to do with it.
--Ken
It's not as bad as all that - if you have the entire body handy, about the only
three things that you'd really need are the C-T-E from the main headers, the
main MIME type, and if it's a multipart/*, what the bodypart boundary string
is. And your Perl script already does 2 of those.
Actually,
I'll likely continue to use it until nmh's MIME handling
is redone to support the registration of custom formatters
based on a MIME entities content-type. It is not only
multipart bodies that reply needs to deal with, but
media-types like text/html which is becoming more
prevalent as time goes
Well, if I run the replied message through mhn it automagically
figures out that the charset is UTF-8 and encodes everything with
quoted-printable (I assume it's getting the correct charset through my
locale). So maybe all I need to do is make sure my script converts
all of the text it gets
Yeah, probably. But I'm not sure what the right solution should be
for that case.
As a side note ... my last message went out as quoted-printable, but I guess
the mailing list software re-encoded it as base64. Go figure.
--Ken
___
Nmh-workers
Yes, I think it does that. Bit annoying. Would be nice if it picked
the one that shipped the least bytes.
Bytes schmytes, pick the one that's maximally human readable.
A lot of my European friends refer to quoted-printable as quoted-unreadable.
But if the choice is between q-p and base64, I'd
Jerrad Piere belg4...@pthbb.org writes:
There's probably a perl module you could integrate into the script,
rather than relying on par? Text::Autoformat for instance.
Hm. I didn't know about that one. Thanks for the pointer!
Marcin Cieslak sa...@saper.info writes:
This patch included in the
Nmh got a bug report recently complaining that a message containing a binary
subject was displayed on a user's terminal and messed it up.
The user was kind enough to include the original message; the issue was
that the message was spam and in UTF-8, but wasn't using RFC-2047 encoding.
Actually
If the only source of these malformed messages is spam then we should
just refuse to display them.
I recently ran into this when working on replyfilter (the core issue was that
par mangles UTF-8 and replyfilter would end up with invalid UTF-8 sequences).
Refusing to display the message is rather
operating systems)
then please let us know.
Ken Hornstein
on behalf of the nmh development team
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
In sending out the announcement for 1.5-RC1, I sent mail to the mh-users
list at UCI (README.developers said to do that, and I guess I didn't do
that for 1.4). Like I figured it would, it bounced.
The developer documentation said that this was a bidirectional gateway
to comp.mail.mh. So this
I've got you covered.
Thanks Jerry, appreciate it!
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
When I was upgrading the OpenBSD nmh package from 1.4 to 1.5rc1, the build
errored out, because OpenBSD does not have utmpx.h. Speaking with other
devs implies that this is unlikely to ever be supported on OpenBSD.
Seriously? What the hell?
utmpx is part of POSIX; utmp is not. There was a
For routine installation on popular platforms, the shell script in
docs/contrib/build_nmh can be used to guide you through configuration.
It will then build and optionally (with -i) install in the configured
location.
I can't find a file named build_nmh anywhwere in the distribution.
I am pleased to announce the first release candidate (RC1) of nmh 1.5 is now
available.
Are requests for new feature, sans code. in order yet?
Sure, go for it. Obviously no new features will be in 1.5, but I can't
think of a reason to not talk about what comes next.
--Ken
! is not available in pure Bourne shell and should be avoided.
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
201 - 300 of 2428 matches
Mail list logo
