folks, it's been a blast. i used MH from 1985 to 2005 exclusively, then
from 2005 to 2015 in parallel with uw-imapd, and not at all since mark
crispen's death when i moved to dovecot and Maildir.
i've helped find and fix bugs in the MH library, i regularly tested and
patched the MH (and Kerber
hymie! wrote on 2019-09-27 07:21:> Unfortunately, Yahoo isn't the only
culrpit. More and more servers are
honoring DMARC.
yes, i know.
I, for example, keep my email on my own server at home,
but because my ISP blocks port 25, I have to hire a third party to
receive and re-send my email for
Ken Hornstein wrote on 2019-09-26 09:36:
Everyone,
I received this email, and I wanted to pass it along. The executive
summary is: in the near future subject lines to nmh-workers will no
longer be prefixed with "[nmh-workers]" and there won't be a footer
at the end of the message anyone sayin
On Monday, 10 June 2019 22:41:18 UTC Ken Hornstein wrote:
> >$ cd `mhpath +future`
> >$ find -type f
> >./2019-06-10T18:13/1
> >$
>
> Maybe it's the rocket engines, but it sure doesn't seem like that's how
> it works. It implies you can "Undo Send" anything.
you seem to be implyi
we should remove all feature or behaviour ifdef's. those things should be
configured at runtime, in config files or command line options. code size is
not the menace it once was. only things that won't compile everywhere need
ifdef, and only for the non-portable bits.
--
nmh-workers
https://
Ralph Corderoy wrote on 2019-04-23 05:10:
...
I agree with the general principle that if we open it, we track it, and
then close it so it doesn't reach the child, typically with O_CLOEXEC or
FD_CLOEXEC. ...
to that end, i propose that we treat any open descriptor N>2 at the time
of an exe
valdis.kletni...@vt.edu wrote on 2019-02-14 14:16:
...
Am I the only guy who's been bitten by documentation that has single
and double quotes that look cut-n-paste-able but actually aren't?
nope.
--
P Vixie
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken Hornstein wrote:
It determines the style of date(1) to invoke without relying on user
input, then when that's known it invokes it again with the desired
number of seconds but without discarding stderr in case of problems, and
the existing `set -e' would exit on an error.
It occurs to me
Paul Fox wrote:
...
i love this mailing list.
i keep trying to leave, but, i can't!
--
P Vixie
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Andy Bradford wrote:
Thus said Ralph Corderoy on Tue, 20 Mar 2018 12:56:09 -:
For evermore, programs that only offer one means of invoking an editor
have had to checking first $VISUAL, falling back to $EDITOR. :-)
You mean like the following chunk of code: :-)
http://www.fossil-scm.or
Ken Hornstein wrote:
... it turns out the default editor back in the day (if you didn't
configure one with mhconfig) was "prompter", which would give you a
kind of very simple message input interface (but not exactly like you
describe).
prompter is what i was thinking of. repl and forw also u
Ralph Corderoy wrote:
why would our build or install dependency list include any editor?
Fedora's is changing from an install dependency on /usr/bin/vi to a
Suggests one. I haven't checked what the other distributions do. AIUI
the idea is a user won't see
$ comp
unable to exec vi
rewind, please. i set VISUAL to /usr/local/bin/jove, and never have used
any version of vi with any version of mh, ever.
why would our build or install dependency list include any editor?
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
by the way, this is how i move my wife's inbox into annual
subdirectories now. when we used MH, it was simpler by far.
http://www.redbarn.org/node/29
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken Hornstein wrote:
from there, implementing Maildir might be easier than from here. even
IMAP isn't impossible, if we're willing to return a socket descriptor
instead of a file descriptor, or maybe a pipe from a fork, or (gag me) a
temporary file.
Wlll ... I think, sadly, that to really
Ken Hornstein wrote:
Here is my $0.02 on that topic.
...
strong +1 to ken's analysis here, and below where he questioned the
utility of developing our own IMAP server. in more detail, this topic:
Now I am not suggesting that we replace the MH mailstore with Maildir;
that doesn't seem suc
Ralph Corderoy wrote:
...
Could an optional level of indirection help; mail/inbox/42 having
content that states it's not the email, but here's details that allow
the email to be found in a Maildir, including a fast method, and a
slower one for if things have got out of sync.
It would mean nm
Ralph Corderoy wrote:
...
Can someone with Cyrus IMAP give examples of the file-name metadata.
it was dovecot not cyrus-- my apologies again to all for that confusion.
https://wiki2.dovecot.org/MailboxFormat/Maildir
--
P Vixie
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-
Ralph Corderoy wrote:
...
Right, like http://man.cat-v.org/plan_9/4/upasfs
...
Would it be presenting a read-only view of the master storage, and that
storage can still be diddled with by any Unix command?
read-only would be a successful MVP, but eventually, read-write is nec'y.
--
P Vixi
Ken Hornstein wrote:
... So it would be helpful if we supported Maildir as a mailbox
format, because then we could use nmh directly on the backend store
without going through IMAP (to me that suggests that really you want
IMAP support in nmh, but, whatever). ...
if MH could speak IMAP and if
Ken Hornstein wrote:
... In my mind a mail DROP is where an MTA drops off email
for some later program to pick up, not necessarily where mail is stored
for manipulation by a MUA, and a lot of the Maildir documentation is
talking about how there's a special delivery directory ("new"). But
since
Ken Hornstein wrote:
the imap service's relationship to its backing store is none of my
business as an imap client. as long as invariants are preserved, the
precise form of magic, or even what upstream rules might be getting
broken, are "all fine by me".
Well, I didn't care that much about wh
Andy Bradford wrote:
Thus said Ken Hornstein on Tue, 13 Feb 2018 11:30:38 -0500:
We've talked a lot about the subtle change to move MH to Maildir, and
we never quite work out all the wrinkles, and I'd sure like to that.
I hear people say this, and I have to wonder ... what's the goal here?
Ken Hornstein wrote:
You know, it might be interesting to see the output from inotifywait
when you do a drag and drop across folders. I am presuming that
Thunderbird doesn't know about the Cyrus-IMAPd index and Cyrus IMAPd just
figures it out. If that's the case then that is fine.
the imap
Ken Hornstein wrote:
... Well, good question! I believe the answer to that is "no".
You can read the base specification here:
https://cr.yp.to/proto/maildir.html
The idea is when you are delivering a new message into a Maildir, you
first write it to the "tmp" directory, then rename
as promised, i asked bert hubert how he uses C++ in PowerDNS without
damaging himself:
On Mon, Feb 12, 2018 at 12:43:16PM -0800, Paul Vixie wrote:
you seem to have made peace with C++. i predict that you did this by
declaring some subset of its features that you'd be willing to use
Michael Richardson wrote:
... I tried to build the other one (uw-imap?) that had MH support, but
it was too much effort because the "libmh" library was pretty much impossible
to build/configure.
sorry about that. (i was the maintainer in the years up until mark's
death.) the ruinously bad pr
Ken Hornstein wrote:
in that world, inc would speak Maildir format
Done! inc has been able to grok Maildir format for ... over 6 years now.
i underspoke. i mean inc could only write into Maildir format folders,
and all MH folders would become read-only, available translucently, or
conver
Ken Hornstein wrote:
We've talked a lot about the subtle change to move MH to Maildir, and we
never quite work out all the wrinkles, and I'd sure like to that.
I hear people say this, and I have to wonder ... what's the goal here?
If the goal is to share your mailbox with another client (or
Michael Richardson wrote:
...
So what you mean is that you want an MH-like file arrangement consistently
provided over many transports via FUSE. I'm with you on this.
On top of that, I'd like a personal IMAP server, *solely* so that my local copy
of Thunderbird (or maybe my smartphone IMAP cl
Bakul Shah wrote:
On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie wrote:
if we wanted the effort of an actual rewrite, we would need to justify
the time expenditure with a potentially larger user population, which
means reconsideration of features that younger people actually depend
on, like
David Levine wrote:
Ralph wrote:
The aim would be for the existing users to
have a code base that allowed more rapid, stable development of new
features, deprecating old warts, and improving consistency.
+1
I'd rather see more of all the above, even if it means giving up some
current capab
Ken Hornstein wrote:
Some smart-ass on this list recently gave me a flippant response when
I made a similar lament regarding valgrind on MacOS X. Who was that
again? :-)
i normally hate people like that, but did he say, here kid, here's a
nickel, get yourself a better C library for accessin
Ken Hornstein wrote:
...
you said:
And the programs I tried worked fine. Running best scan time
for 200K messages, scan+gc takes 13.5 seconds while the
regular scan 7.4 seconds.
To me a performance penalty of 50% is not worth it, but I'd be willing
to hear from others.
the various design
Ralph Corderoy wrote:
Hi Paul,
that's a knee-jerk reaction.
Very true. A regurgitation of a long-held view.
bert hubert at powerdns found a subset he can live with, and ways to
enforce it. basically there are no operators overloaded and no
subclassing.
I've struggled to find something
Ralph Corderoy wrote:
Hi Paul,
if we wanted a better code base for the same graying user population,
wouldn't we do a gradual rewrite in some well-disciplined subset of
C++ instead?
No, everyone has a difference subset so we won't agree. There's nothing
to enforce it automatically. No sub
Ken Hornstein wrote:
...
But ... one nasty problem raises it's head. That is the lack of _time_.
We have plenty of great ideas, but those of us who want to implement
them all suffer from a lack of time to work on them. Rewriting nmh in
Go seems like it would take a long time. Slowly switchi
i do all new work in Go.
i just don't know whether MH can attract new users through a rewrite.
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken Hornstein wrote:
...
When I wrote that comment, nothing in the format engine would ever
call free() on component names, so it wasn't a problem. scan() isn't
expecting anyone to free those buffers that it is malloc()ing.
i think that there's no way to be selectively uncaring. if we don't f
Ken Hornstein wrote:
...
I am wondering if the buffer reuse in scansbr.c is still warranted; should
we just accept the price of a bunch of malloc/free calls?
it's 2018 and my smart phone has more cpu power than all the pdp-11's in
the world had when MH was designed. so, yes.
--
P Vixie
Ken Hornstein wrote:
Six is ABRT. Have you tried `make check' with valgrind?
Sigh, there are a ton of exclusions I have to put in valgrind to
make it useful on MacOS X. I'm chipping away at them slowly.
my first thought was "here kid, here's a nickel, get yourself a real
computer." howev
Ralph Corderoy wrote:
...
A lot of it is duplicate dribble pasted over the decades and it could
probably be halved in size. Along the way, I'm sure many bugs, lack of
error checking, and inconsistencies would be found, and fixed.
sounds like a great beer-and-pizza expedition.
...
I built
oops.
Ken Hornstein wrote:
...
- Messages in IMAP are immutable, so if you overwrite ~/mail/inbox/42, in
theory you should get a new UID for that message. But maybe our "internal"
IMAP implementation wouldn't care. I do wonder how UW-IMAP deals with
that, since it claims to be able to
Ken Hornstein wrote:
...> - Messages in IMAP are immutable, so if you overwrite
~/mail/inbox/42, in
theory you should get a new UID for that message. But maybe our "internal"
IMAP implementation wouldn't care. I do wonder how UW-IMAP deals with
that, since it claims to be able to se
Bakul Shah wrote:
On Tue, 06 Feb 2018 16:15:38 -0800 Paul Vixie wrote:
Paul Vixie writes:
in the broader context of our work, we might ask, do we want the size of
the MH user community to ever again grow,
How likely is that?
unless we reinvent in a way that's an impedance match for
Ken Hornstein wrote:
...
First off .. normally MH memory management has been terrible, because the
programs are all short-lived. This makes it hard to do some interesting
long-term things, like create a set of library routines for other programs
to use. This is all part of cleaning that up so
Ken Hornstein wrote:
Yes, I like asprintf(), but it's not POSIX. snprintf(NULL, 0, fmt, ...)
is POSIX and returns the strlen() of what would have been written,
allowing a second call to do the work, again, for real this time.
A quick glance suggests to me that even while asprintf() is not pa
oops.
Ralph Corderoy wrote:
...
There was a long `strncpy(3), die, die, die.' thread back in 2016 about
this, including that strncpy() pads to the full 8 KiB with NULs. My
to-do list summarises what I think was the conclusion.
- Add trunccpy() for when truncation is correct, e.g. the start
Ralph Corderoy wrote:
...> There was a long `strncpy(3), die, die, die.' thread back in 2016 about
this, including that strncpy() pads to the full 8 KiB with NULs. My
to-do list summarises what I think was the conclusion.
- Add trunccpy() for when truncation is correct, e.g. the start of a
if we're doing global search/destroy on nmh command line processing,
please consider:
http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Bakul Shah wrote:
fmttest.c: Avoid `++' with bools, silencing compiler warnings.
i hate that perfectly reasonable, traditional idioms have to be avoided
for this reason.
No strong reason to use type bool in the first place. It didn’t show up till
c99.
pointers aren't booleans. integ
Steven Winikoff wrote:
...
My proposal is to simply edit out shell metacharacters (add # and ! like
David suggested) in those strings. That seems simple and reasonable to
me. Well, maybe replace them with an _ or something.
For what it's worth I'd prefer the "replace them with _" option, bu
Steven Winikoff wrote:
...>> My proposal is to simply edit out shell metacharacters (add # and
! like
David suggested) in those strings. That seems simple and reasonable to
me. Well, maybe replace them with an _ or something.
For what it's worth I'd prefer the "replace them with _" option,
Ken Hornstein wrote:
for MH we should allow only metacharacters we handle explicitly, and we
should use strsep() rather than /bin/sh to make our argument vectors,
and we should call execve() rather than popen().
Geez, Paul, we HAD this food fight already! :-)
http://lists.nongnu.org/archi
i do not think that we can ask for the shell's help with metacharacter
expansion, because even on unix, the syntax it understands may not be
what the user expects.
because i call sendmail from popen() in cron, i had this problem with
MAILTO= values. i first decided to accept only @, %, ::, and
Ken Hornstein wrote:
That's not right, it should be:
while ((pp = strchr (pp, '\''))&& buflen> 3) {
pointers aren't booleans. in BSD style as used in BIND, this would be:
while ((pp = strchr(pp, '\'')) != NULL&& buflen> 3) {
Forgive my stupidity ... but this is just a matter of
must we call /bin/sh -c "$foo", or can we call execve on the command
itself, after cracking it into an argv[] ?
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine wrote:
Steven wrote:
I see that the first hunk is trying to match on
while ((pp = strchr (pp, '''))&& buflen> 3) {
That's not right, it should be:
while ((pp = strchr (pp, '\''))&& buflen> 3) {
pointers aren't booleans. in BSD style as used in BIND, this would
Ken Hornstein wrote:
...
I just double-checked RFC 5322, and as far as I know this is valid.
Specifically, "To:" is defined as having an address-list:
address-list = (address *("," address)) / obs-addr-list
And the other relevant bits are:
address = mailbox / group
gr
Ken Hornstein wrote:
connect to the imap service and authenticate
open a unix domain socket and listen() to it
on each connection:
So, alright, I admit that you're more experienced than I especially at
the "big picture", so I want to understand exactly what you're proposing.
Is this, essenti
Ken Hornstein wrote:
the top of thread shows a prediction of likely performance impact from
opening and closing an imap session every time an mh command starts or
stops. i'm arguing against that, because state is necessary in order to
receive push notifications, and so to me, the reason to keep
Bakul Shah wrote:
On Fri, 27 Oct 2017 00:41:58 +0200 Paul Vixie wrote:
Paul Vixie writes:
there's a think in imap called "push", which is part of why i keep
Not sure what you mean. Perhaps you mean having to push
locally created messages to the imap server on reconnect?
T
Bakul Shah wrote:
On Thu, 26 Oct 2017 17:26:37 -0400 valdis.kletni...@vt.edu wrote:
valdis.kletni...@vt.edu writes:
AIUI, the big issue has always been that nmh has expected message numbers
to remain static until explicitly changed (i.e. message 35 *stays* message 35
until 'folder -pack' or s
Bakul Shah wrote:
...
The local socket part is easy. Connect to /tmp/mhd/$USER. [Calling
this daemon mhd for short] If the socket doesn't exist or a write to
it fails, kick off mhd.
indeed, yes, that's how to do it. see also "prayer", an imap server:
Prayer is yet another Webmail interface
Jon Steinhart wrote:
Ken Hornstein writes:
The hooks cover everything so that one can keep track of what message exist
and where they are. The work for me, but I don't use all of the gritty nmh
features so there might be bugs for some complex cases. ...
Well, yes, buuuttt ... we never sat
Ken Hornstein wrote:
this is MH, after all. we should borrow sendmail's config format and
address parser, to make it more user-configurable, no?
Geez Paul, I can never tell if you're kidding or not. You really want to
put all of the sendmail.cf functionality into nmh? :-)
:-). i think it sh
this is MH, after all. we should borrow sendmail's config format and
address parser, to make it more user-configurable, no?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
valdis.kletni...@vt.edu wrote:
> On Thu, 13 Apr 2017 09:55:19 -0400, Ken Hornstein said:
>
>> Normally I would suggest deprecating this feature and then removing it
>> after the next release, but it's impacting reasonable behavior NOW, and
>> fixing the core dump issue here just means trying to
Ken Hornstein wrote:
> ...
>
> Right, I think that people forget Maildir was not designed as a mail
> _folder_ but instead as a mail _drop_ (a place where you store mail to
> retrieve it). Yes, Dovecot uses it as a mail store, but I believe it does
> a lot of caching. One of my plans for redoi
i think that rcvstore would also become very slow, unless we're caching
the next message number rather than discovering it every time.
huge mboxes are one of the reasons i eventually expect to have to
abandon Maildir. what i wish i had is a set of MH-like utilities that
hid the backend storage fro
On Sunday, 8 January 2017 09:34:35 PST David Levine wrote:
> ..., nmh doesn't have a way to generate a globally unique message
> or content ID. The default form is (and has been in MH), by way of
> example:
>
> Message-ID: <3325.1483884629@localhost.localdomain>
>
> where the number portion
On Wednesday, 4 January 2017 00:08:43 PST Ken Hornstein wrote:
> ...
>
> If we had everyone who used m_draft use the same protocol, that might
> solve that problem. We'd need to make sure everyone who adds messages
> to a folder calls folder_addmsg(), though. It ends up being a huge
> pain to ma
On Tuesday, 3 January 2017 10:50:11 PST Ken Hornstein wrote:
> >> - The file is created with creat(), which as you know does get called
> >> with O_CREAT, but does not include O_EXCL.
> ...
> At least in the case of comp(1), by the time creat() is called it is
> writing a new draft into that file.
Ken Hornstein wrote:
>> That kind of dependency should be removed. ...
>
> Since it's been around forever, I'm not sure we can easily change it
> without breaking a lot of existing format files. ...
do you have a sense of the actual magnitude of the MH user base? that
is, how many format file
Ralph Corderoy wrote:
> They don't need to be checked because they're only used in those cases
> where truncation, but still NUL-terminated, is valid. Kind of like when
> `%.42s' is used in a lexer error message in case the token is runaway,
> or 'cut -c 42'. Ken's saying that some of them are
Ralph Corderoy wrote:
> Hi Ken,
>
>>> If this is what I think it is ... you know, I think this truncation
>>> is benign.
>
> What if benign truncations were trunccpy(), instead of the strncpy dance
> where the reader is unsure if it's benign or not, and then abortcpy()
> could be the strncpy()
Steffen Nurpmeso wrote:
> Paul Vixie wrote:
> |...
>
> I think the former and latter of the above have the problem that
> they return useless information: the size that would be necessary
> to store the result in a non-truncated form. If that information
> would be col
Ralph Corderoy wrote:
> Perhaps a complainant could be told of the secret $NMHNOBARF to stop
> TRUNCCPY from aborting? Though it would still complain for the first N
> goes?
i think the moment that the state of the program becomes undefined, you
should abort.
malloc and asprintf helpfully retu
Todd C. Miller wrote:
> On Mon, 24 Oct 2016 16:40:36 -0400, valdis.kletni...@vt.edu wrote:
>
>> In other words - if the source string doesn't fit, it will create
>> a non-NULL-terminated destination string for you. Repeat that,
>> slowly, until it sinks in.
>
> It says nothing of the sort, ple
Ken Hornstein wrote:
I know it bugs you, and I understand why. But I doubt you'd notice, in
practice, on a modern system. Also ... you have 100 MB attachments?
But anyway ...
as i've explained to the KDE "KMail" team, assume 100 MByte attachments.
don't keep them in memory, and don't make
Ken Hornstein wrote:
MIME broke all that. a lot of UI's can't cope with attachment trees
where one rfc822 includes another which has attachments. the way modern
graphical MIME UI's work is by iterating down through the forwarded
message's MIME tree and attaching each attachment to the top level
n...@dad.org wrote:
I don't recall when attachments first came into nmh, if I ever knew. But I
don't understand why the feature I talked about was not added to forw at that
time. Maybe it was because, for some reason I don't understand it is
difficult??
RFC 934 style attachments, as practiced
n...@dad.org wrote:
I don't know what I "want". Nor will I until I understand better.
But what I would have thought -- indeed once did think -- that the
default for forw, would be that all the attachments to all the messages
being forwarded would be attachments to the new message, possibly wee
Ken Hornstein wrote:
That's what I implemented in mhfixmsg: just Content-Type name and
Content-Disposition filename.
I think we're all fine with that; I'm wondering if we should see if it's
an RFC 2047-encoded filename and just decode it automatically.
that would follow the principle of lea
Ken Hornstein wrote:
That's what I implemented in mhfixmsg: just Content-Type name and
Content-Disposition filename.
I think we're all fine with that; I'm wondering if we should see if it's
an RFC 2047-encoded filename and just decode it automatically.
that would follow the principle of le
Lyndon Nerenberg wrote:
Call me Grumpy[2], but any system with a packaged install of nmh that
doesn't include the man pages[1] is broken. So yes, that's a
non-starter in my books. It's not a scenario to cater to, because
the fix is to not break the packages in the first place.
you are not b
Lyndon Nerenberg wrote:
On Mar 16, 2016, at 6:04 PM, Paul Vixie wrote:
prayer is the simplest and faster webmail system i ever found for my family's
use while traveling.
But. How. Does webmail have anything to do with this?
webmail and mh both have a fork+exec before every oper
Lyndon Nerenberg wrote:
On Mar 16, 2016, at 4:56 PM, Ken Hornstein wrote:
And I believe
it makes it WORSE; each nmh command starts with a brand-new scan of a
folder, so messages added or removed between commands work out fine.
But a FUSE interface would have no idea when an nmh command is sta
Conrad Hughes wrote:
Ken> it makes it WORSE; each nmh command starts with a brand-new scan of a
Ken> folder, so messages added or removed between commands work out fine.
Ken> But a FUSE interface would have no idea when an nmh command is starting
Ken> or stopping, so you'd have to do a lot
Ken Hornstein wrote:
i don't know exactly how to match mime to the simplicity of show(1), and
i've been violently repulsed any time i tried to use mhshow(1), but i
I can't really blame you on that one. But really, mhshow(1) is really just
the old mhn, slightly rewritten. And mhn was a horri
Ken Hornstein wrote:
Well, it depends on the message. Sometimes I get a message with 20 photos
attached. I just want to be able to easily go from one to the next without
having to type their part number.
But ... what's wrong with doing something like:
mhstore -type image
Then you can deal
Ken Hornstein wrote:
i believe that the gnu team has an MH-like tool set that's designed this
way. if so then we might just tell people like me to go use that.
If you're talking about GNU mailutils, then yes. I mean, it does
include a MH-compatibility layer and works with IMAP; I do not know
Jon Steinhart wrote:
OK. That's a really cool idea. One could even contemplate using gmail as a
mail store to make it easier for the NSA to read your mail. Maybe the hooks
should be replaced by one of the DLLs. This sounds like a huge change in
the codebase, so hopefully someone is up for i
Jon Steinhart wrote:
...
Are you saying that you'd like to see the nmh cli abstracted to the point
where it could work on different flavors of mail store? If so, that seems
like a big change. Sort of like the hooks, but with a DLL interface
instead of the shell?
yes.
--
P Vixie
__
Jon Steinhart wrote:
...
I think that we should keep the mail store as is. I agree that the MIME
and character set stuff has made it less grep-able than it used to be,
but it's still useful.
useful for what? i have no remaining use cases of my own.
I am emboldened by David's posting regard
Andy Bradford wrote:
What's wrong with the way nmh does it today? Maildir is certainly
superior for some of the reasons detailed below, but nmh's Mail store
isn't very far off:
http://cr.yp.to/proto/maildir.html
some of us have converted to Maildir, but we miss MH's CLI capability.
Ken Hornstein wrote:
My reading of the maildir specification (such that it is) says that the
filename before the colon should be unique. Although ... despite what
people say, it seems like Maildir is not really designed to be a mail
_store_ (someplace where you keep your mail long-term) but mo
Michael Richardson wrote:
Lyndon Nerenberg wrote:
>> So, each message has a (U?)UID? Are the integers a subset of that?
> UIDs increase monotonically within a folder. Sequence numbers are just
> the index number into the dynamic array that represents the current set
>
On Tuesday, March 8, 2016 9:19:57 PM PST Ken Hornstein wrote:
> ... I hate
> to be the the one who has to explain this ... that hasn't been a realistic
> goal since the advent of MIME. The model that "email is text" just
> isn't valid anymore.
i know. which is why i don't see much value in the mh
Ken Hornstein wrote:
> ...
Is the real goal to search a Maildir store, or an IMAP store? The latter
is something I've been thinking about on and off for a while noe. That should
be relatively straigtforward to implement.
i'd like something close to the full command line power of MH, when
d
1 - 100 of 261 matches
Mail list logo