Jon Fairbairn writes:
> Paul Vixie writes:
>
>> dovecot is mapping a thing that does not change (IMAP UID) to another
>> thing that does not change (message file name). therefore they never
>> have to edit or rewrite this file. if MH used a text file then we would
>> have to copy it to mumble.ne
Definitely agree on ditching MM_CHARSET and enabling MIME code
regardless of any locale settings.
MH-E developers: please rack your brains and the SourceForge trackers
for changes to MH that would benefit MH-E. Thanks!
Ken Hornstein writes:
> Okay, the recent messages about nmh have driven me t
On 2011-12-12, at 2:03 AM, Ken Hornstein wrote:
> Yeah, I think we're all on the same page here. I'm all in favor of reducing
> our #ifdef mess.
I'm on the road for the next week and a bit, but as soon as I get back I'll
push my POSIX work onto the working branch I created. It's not complete
>I'd make the case that SunOS 4.1 from 25 years ago (still mentioned in
>the MACHINES file) is sufficiently remote from today's definition to qualify
>as "non-UNIX-like" ;)
Yeah, I think we're all on the same page here. I'm all in favor of reducing
our #ifdef mess.
--Ken
___
> --===6840960053006057842==
> Content-Type: multipart/signed; boundary="==_Exmh_1323651731_10493P";
>micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
>
> --==_Exmh_1323651731_10493P
> Content-Type: text/plain; charset=us-ascii
>
> On Sun
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 fo
>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 understanding
>of which is a barrier to getting new work done.
I see a lot of stuff in there for older UNIX systems, but I'm trying to
think of examples for
Been trying to convince myself to stay out of this, mainly because I haven't
had the time to contribute the work that's been on my to-do list for years.
I'm pretty happy with nmh as is; I don't want to see the one-message-per-file
thing change as some have mentioned. That's one of the big strengt
Jon Fairbairn writes:
>> The idea makes me wonder if git could be used as a mailstore.
>> With a blob for each message and tag-blobs for classifying
>> messages. Could be nice if you can push and pull mail between
>> machines.
>
>That does have a certain appeal.
It's something I've been thinking
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
system
Valdis Kletnieks:
> > 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
> > reproduce the signature too.
>
David Levine writes:
> I'm also wary of changing the message file naming scheme.
> anno modifies messages, so it is inconsistent with a naming
> scheme that includes file size, hash, or other properties.
> I could probably live without anno, but someone else might
> consider it important.
Me, for
Hi Valdis,
> > One more thing, the headers would be made simpler to use. I'm
> > particularly thinking of having one physical line per header, no
> > continuation.
>
> procmail to the rescue:
>
> :0 hwf
> | formail -c
>
> There ya go.
Thanks. And it seems http://tools.ietf.org/html/rfc5322#s
Oliver Kiddle writes:
> Jon Fairbairn wrote:
>>
>> Long ago, before mh I used an email system that stored email in
>> files with unique ids, which suggests a way to do this. Switch
>> to storing messages in (say) date-named accession order folders
>> with unique filenames (derived from the messa
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 t
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 encry
On Sat, 10 Dec 2011 12:55:05 GMT, Ralph Corderoy said:
> One more thing, the headers would be made simpler to use. I'm
> particularly thinking of having one physical line per header, no
> continuation.
procmail to the rescue:
:0 hwf
| formail -c
There ya go.
pgpf2awJ0Lgfw.pgp
Description: PG
>I'm more sure about the other two: dist(1) could recreate
>a mime mail, since we need that mime-creation functionality
>anyways. And as stated before I think one should verify a
>mail only once. The first time you show(1) a PGP/MIME mail
>it (asks for the password and decrypts and) tries to verify
+ Ralph Corderoy --+
> +-- Yoshi Rokuko ---+
> > for what do you guys need original MIME mails?
>
> Investigating problems; what did nmh receive? Sending
> them on with dist(1). I expect there are others, like
> the signature-c
Hi Yoshi,
> > > I thought about breaking up the MIME parts, but I decided that the
> > > problem with that was that I believe there is value to still
> > > having the original message around.
> >
> > You're right, there is. In regurgitating long ago thoughts I
> > ommitted that bit. It could be
> > I thought about breaking up the MIME parts, but I decided that the
> > problem with that was that I believe there is value to still having
> > the original message around.
>
> You're right, there is. In regurgitating long ago thoughts I ommitted
> that bit. It could be available under a path
> > > If all textual parts were stored in UTF-8 on disk things would
> > > improve once again. Perhaps even a mail/inbox/42 for a UTF-8
> > > summary of the email, headers and the body laid out as text where
> > > possible
One more thing, the headers would be made simpler to use. I'm
particularl
Hi Ken,
> > MIME breaks this. If all textual parts were stored in UTF-8 on disk
> > things would improve once again. Perhaps even a mail/inbox/42 for a
> > UTF-8 summary of the email, headers and the body laid out as text
> > where possible, and a mail/inbox/42/... with the headers and each
> >
Earl Hood:
> On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein wrote:
> > I thought about breaking up the MIME parts, but I decided that the
> > problem with that was that I believe there is value to still having
> > the original message around.
>
> Just think of SMIME, PGP, DKIM, et.al. Preserving
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 b
On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein wrote:
> I thought about breaking up the MIME parts, but I decided that the
> problem with that was that I believe there is value to still having the
> original message around.
Just think of SMIME, PGP, DKIM, et.al. Preserving the original
message is
>MIME breaks this. If all textual parts were stored in UTF-8 on disk
>things would improve once again. Perhaps even a mail/inbox/42 for a
>UTF-8 summary of the email, headers and the body laid out as text where
>possible, and a mail/inbox/42/... with the headers and each part as a
>separate file,
On Fri, Dec 9, 2011 at 18:58, Earl Hood wrote:
> On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig wrote:
>
> > I have my fetchmail scripts ignore messages with a duplicate messageid
> > (using a history of messageids I've received during the last 30 days or
> so)
> > to avoid duplicate mail.
>
> De
We are getting dangerously close to an observation i've made
a few times recently, which is that "We've discovered Metadata!"
moreover, the "metadata" about a "file" is now as important as
the "data". We've poked and futzed with where to store metadata
for files, though I think "hide" is a better
Hi,
Oliver Kiddle wrote:
> If you're going to do that, you might aswell name the files using an
> SHA hash.
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 s
On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig wrote:
> I have my fetchmail scripts ignore messages with a duplicate messageid
> (using a history of messageids I've received during the last 30 days or so)
> to avoid duplicate mail.
Depends on what you mean by "duplicate". From a mail archiving p
On Fri, Dec 9, 2011 at 18:13, Oliver Kiddle wrote:
> Jon Fairbairn wrote:
> >
> > Long ago, before mh I used an email system that stored email in
> > files with unique ids, which suggests a way to do this. Switch
> > to storing messages in (say) date-named accession order folders
> > with unique
On 12/9/2011 11:13 PM, Oliver Kiddle wrote:
> Jon Fairbairn wrote:
>> Long ago, before mh I used an email system that stored email in
>> files with unique ids, which suggests a way to do this. Switch
>> to storing messages in (say) date-named accession order folders
>> with unique filenames (derive
Jon Fairbairn wrote:
>
> Long ago, before mh I used an email system that stored email in
> files with unique ids, which suggests a way to do this. Switch
> to storing messages in (say) date-named accession order folders
> with unique filenames (derived from the message-id, or simply
> accession nu
Paul Vixie writes:
> dovecot is mapping a thing that does not change (IMAP UID) to another
> thing that does not change (message file name). therefore they never
> have to edit or rewrite this file. if MH used a text file then we would
> have to copy it to mumble.new with changes, and rename it b
On 12/7/2011 3:39 AM, Ken Hornstein wrote:
> I was thinking that if we want to have something that IMAP already uses
> to refer to messages that is close to how message numbers work today
> in exmh, then that would be useful. But you say below that you want
> something more permament than how mess
It seems that IMAP has the concept of a "message sequence number",
which is a number from 1 to the number of messages in a folder; that
might be the right thing to use.
>
>no. MH message numbers can have holes and can be reassigned. IMAP is
>always 1..N, no holes.
I was thinking tha
>i committed a band-aid fix for this to cvs, back in april - see
>http://article.gmane.org/gmane.mail.exmh.devel/977>.
>
>the debian versions since 2.7.2-22 (ie. testing and unstable)
>include that fix.
I found that fix when researching the problem. But I believe that it
doesn't really get to t
On Tue, 06 Dec 2011 17:45:43 EST, valdis.kletni...@vt.edu writes:
>>And if you figured out how to get exmh to use the "fixed" font
>> with the most recent version of Tk, that would be super-awesome :-) (As
>> an aside ... from my brief investigation, it seems that with the changes
>> to the fo
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 leas
On 12/6/2011 8:43 PM, Ken Hornstein wrote:
>>> Alright, I'll the limits of my knowledge here. UIDL is a POP thing,
>>> right? Do you mean UID when talking about IMAP?
yes.
>>> It seems that IMAP has the concept of a "message sequence number",
>>> which is a number from 1 to the number of messag
On Tue, 06 Dec 2011 17:24:44 GMT, you said:
>
> valdis.kletni...@vt.edu writes:
>
> >One of you probably has MM_CHARSET defined and the other doesn't. 'scan'
> >(IIRC) doesn't even try to do 2047 quoting if that variable isn't set.
>
> Nope:
>
> leto:~% MM_CHARSET=1 scan +spam/unsure 652
>> - For those of you who care about this, do you have any thoughts about how
>> a mapping from an MH message number to a particular Maildir filename
>> would work? At first glance that's the thing that leaps out at me
>> as the most obvious problem without a simple solution.
>
>agreed, this
On 12/6/2011 7:57 PM, Ken Hornstein wrote:
> ... in terms of shared library support we have two options: libtool
> and hand-written code for each operating system. I'm not interested in
> working on the latter, but if someone else wants to work on it I won't
> stand in the way. If there are other o
>regardless of what tool chain we use to maintain it, moving 95% of MH
>into a shared library is important. while i do still want to use MH from
>shell scripts, i think the major use of MH will be in non-shell non-text
>mail user agents.
Well, shoot, I'm convinced ... I'll look at libtoolization a
On 12/6/2011 6:07 PM, Ken Hornstein wrote:
> ... It seems to me that we should start
> assuming that you should always do MIME, and always do the stuff that was
> previously only turned on my MM_CHARSET.
+1.
>> While we have the phrase "nmh libraries" on the table, would it be
>> interesting
>>
(Replying to a bunch of messages ...)
>One of you probably has MM_CHARSET defined and the other doesn't. 'scan'
>(IIRC) doesn't even try to do 2047 quoting if that variable isn't set.
It might be that I am running something newer than 1.3, and Tethys is not.
Anyway, something to look into. It s
Thus spake valdis.kletni...@vt.edu:
>
> I've been getting close to getting peeved enough at exmh's behavior on replie
> s to
> multiparts and QP/base64 encoding to fix it, but it's ugly to do it in Tcl if
> there's
> no nmh support. Having said that, I'm not sure exactly what the nmh side sho
>
Thus spake Brian Cottingham:
> On 12/05/2011 09:03 PM, Ken Hornstein wrote:
> > I propose just taking the current HEAD and making it nmh 1.4.
>
> Not sure if you already have, but I vote to get the maildir patch merged
> in before tagging 1.4.
Me too!
--
J.
__
valdis.kletni...@vt.edu writes:
>One of you probably has MM_CHARSET defined and the other doesn't. 'scan'
>(IIRC) doesn't even try to do 2047 quoting if that variable isn't set.
Nope:
leto:~% MM_CHARSET=1 scan +spam/unsure 652
652 2011.12.05 "=?UTF-8?Q?Priority= =?UTF-8?Q?
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
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 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
Am 06.12.2011 um 03:03 schrieb Ken Hornstein:
>
>
> - Long term - better MIME/charset handling
>
> Specifically, scan can decode RFC 2047 headers, but it seems that show
> cannot (okay, mhshow seems to decode some headers, but not others).
> Also, the whole replying to messages that are quot
Ken Hornstein writes:
>You say that rpm says that the version is 1.3-3; is that some snapshot
>version? Or actually based on 1.3?
It's 1.3, and it's the third build that Fedora have made from that release.
It's usually rebuilt if an extra patch is added or if there's an update to
a static libra
On 12/05/2011 09:03 PM, Ken Hornstein wrote:
I propose just taking the current HEAD and making it nmh 1.4.
Not sure if you already have, but I vote to get the maildir patch merged
in before tagging 1.4.
___
Nmh-workers mailing list
Nmh-workers@nong
>> 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:
>[...]
Interesting, because I actually tested that before I sent that email.
That's part of the problem
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:
leto:~% scan `pick -from PriorityClubeStatement`
461 2011.05.19
Okay, the recent messages about nmh have driven me to write this
email, but it's been brewing for a while now. Maybe just getting
back from the Happiest Place On Earth helped.
Here are my thoughts about what we should be doing with nmh in the near,
medium, and long(er) term. In all of these case
59 matches
Mail list logo
