Martin wrote:
> I am probably just setting up .mailfilter wrong, but so
> far, it doesn't seem to understand that it should behave in an
> mh way. It wants to put mail in a .mbox format in just about any
> directory except $HOME/Mail/folder/message# in the normal mh
> style.
It looks like m
Ralph wrote:
> Is some means of specifying type/subtype handling needed for the command
> line instead of always being ~/.mh_profile?
There isn't. I suppose we could add switches. But it
doesn't seem like that would be much easier to use than an
alternate mh_profile, even if that was created on
Ralph wrote:
> I considered a temporary mh_profile but that's a bit icky too IMHO.
Agreed.
> Further, since its raison d'être is to cat to stdout, the subtype isn't
> needed so I just need one entry for each type.
>
> mhcat-store-application: -
> mhcat-store-text: -
>
> Unfortunately,
Ralph wrote:
> Hi David,
>
> > I quickly prototyped an -outfile switch to mhstore, let me
> > know if you want me to finish it up and add it.
>
> I think ~/bin/mhcat linked to mhstore might do me, thanks.
I might add it anyway, unless there's objection real soon. I
often do mhstore+mv, this wo
I wrote:
> Ralph wrote:
>
> > Hi David,
> >
> > > I quickly prototyped an -outfile switch to mhstore, let me
> > > know if you want me to finish it up and add it.
> >
> > I think ~/bin/mhcat linked to mhstore might do me, thanks.
>
> I might add it anyway, unless there's objection real soon.
Ralph wrote:
> Hi David,
>
> > > > Though with mhstore -outfile - 2>/dev/null, that's not necessary.
> > >
> > > True, though I dislike discarding the known unknowns so tend to do
> > > more
> > >
> > > pick ... 2> >(sed '/^pick: no messages match specification$/d')
> > >
> > > to explicit
Paul Fox wrote:
> sorry to have to report another corruption issue. inc corrupts the
> DKIM-Signature header in the attached message from:
> (i don't know whether the issue is this header, or something previous.)
If the 512th byte of a header was a newline, that would
happen. Fixed.
> i went
Valdis wrote:
> At current HEAD, I get this. Apparently something is still not
> backwards-combatable in the 'credentials' code.
Apparently. Of course I'd like to fix this, but as a temporary
workaround, does adding this to your profile help?
credentials: file:.netrc
David
Valdis wrote:
> On Thu, 02 May 2013 13:03:36 -0400, David Levine said:
> > Valdis wrote:
> >
> > > At current HEAD, I get this. Apparently something is still not
> > > backwards-combatable in the 'credentials' code.
> >
> > Apparent
Valdis wrote:
> On Fri, 03 May 2013 15:48:33 -0400, Ken Hornstein said:
>
> > Your analysis of the situation is correct; the temporary file is
> > explicitly chmod'd to 0600 (which seems like the right thing to do).
> > But it seems to me that perhaps the right thing to do here is have
> > refile
Ralph wrote:
> mhshow(1):
>
> If a display string is not found, mhshow has several default values:
>
> mhshow-show-text/plain: %pmoreproc '%F'
> mhshow-show-message/rfc822: %pshow -file '%F'
>
> That suggests to this reader that one can use `moreproc' in one's own
> entries,
Ken wrote:
> It occurs to me that it would be reasonable to apply Msg-Protect to
> messages stored with -file, since that's another way of taking a
> random file and storing it in a MH file. What do others think?
Yes, I assumed that.
David
___
Nmh-wo
Norm wrote:
> This is the first I've ever heard of this rejection reason. The
> message consi sted, almost entirely, of an attachment,
> Spec_05_04_10:04.zip, a 471,282 byte zip file.
That's tiny, it shouldn't cause the problem.
> Is there anything I can do, short of breaking the attachment into
Joel wrote:
> If you're using a stock version of par, this won't affect you, but if
> you're using a par with the i18n patch, then you might want my patch for
> the above problem.
>
> For more details (including my patch), see the bug I filed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=9
Norm wrote:
> As I read, RFC822, Section 5.1, the zone filed field of
> Date components, is required. Do I misread it? I have
> encountered one Email, for which it is missing. It there a
> de defacto standard which makes it optional?
I agree that it is required by RFC 822. And also by RFC
2822,
Lyndon wrote:
> We can do "#define GOING_AWAY_*' for things that will go away after
> the next-after-next major release.
I don't think it's worth polluting the code, esp. for things
that are obviously useless.
Should '*' expansion be added to the deprecated features list in
pending-release-notes
Jerry wrote:
> Recently, I was made aware that when I send a null body message, the
> receiver winds up with a blank Subject: line and all the headers in the
> body.
Can you provide more information? What does the draft look
like, esp. near the bottom? Or are you using mhmail? The
mhmail in nm
Ken wrote:
> I just tried to do this myself, and I got the expected result. So I
> am not sure this is nmh's fault.
I DO see it when I send through AT&T. And, that's with
the latest code base.
I DON'T see it when I send through another SMTP server.
Wierd.
Talking directly to AT&T's SMTP serv
> >Talking directly to AT&T's SMTP servers is a tad inconvenient
> >now that they require SSL. But I'll try later.
>
> I think we have SSL support in send now, don't we? Even the broke-ass
> SSL required by AT&T? :-) Okay, I don't think we have -initialtls
> in 1.5.
Right. I was thinking of t
> >Agreed. I did notice something else wierd, the SMTP server
> >sometimes complains:
> >
> > post: posting failed; [BHST] premature end-of-file on socket
> > send: message not delivered to anyone
>
> Hm. It would be interesting to see what -snoop shows when you get that.
Here's the excerpt s
Norm wrote:
> Every instance of "separated by spaces" should be "as separate
> arguments", or some such.
Fixed in mh-sequence.man.
This is in mh-format.man:
The shell quoting conventions are not available in the
.mh_profile; each token is separated by whitespace.
I left it alone, I thi
Fixed.
I also changed all "RFC-n" to "RFC n".
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken wrote:
> The problem here really more of a bug in the I18N handling _at the
> output stage_, and is really kinda obscure; the issue in my mind is:
> how do we deal with that? This also comes up with other headers,
> like Subject; I expect the same thing would happen there. Part of
> me think
> >And isn't that necessary to protect against potentially
> >dangerous behavior: what if Valdis had an alias that
> >matched the degenerate address that ended up in his draft?
>
> Sure, that would have been bad. But if instead the invalid character
> had been replaced by a ?, everything would h
> >> Sure, that would have been bad. But if instead the invalid character
> >> had been replaced by a ?, everything would have worked fine.
> >
> >That doesn't remove the possibility, it just makes it very,
> >very unlikely. If we're going to change something, we might
> >as well do it right. An
> >The spaces prevent it. But if there weren't any and the
> >brackets were trash:
> >
> > To: MrFoo?Bar?f...@bar.com?
>
> Some experimenting leads me to believe that this _still_ would not
> be accepted as an alias. Specifically, the @ means it gets parsed
> by the address parser and has a val
> No worries mate. Glad you're here!
Very glad. We've had MH and then nmh for all these years
(36!) thanks to Norm. And to other people, of course, but
Norm is still actively making it better and easier to use.
David
___
Nmh-workers mailing list
Nmh
> Ok, I'm trying to understand how this is a _new_ problem. I mean, if
> you end up with this:
>
> To: somelocalalias
>
> That's _already_ going to cause a problem, without any character
> substitution.
> I mean, I'm trying to understand how character replacement makes this a
> new problem.
Do
> >Do we do any character replacement now, other than the
> >insertion of quotes around the display name that you mention
> >below? If not, character substitution could introduce bad
> >behavior that we don't have now.
>
> Actually ... yes! If you use %(decode), we totally replace those
> charac
> >I don't think that's a good idea. Decoding and conversion should do
> >only what they're suppose to. If they can't, they shouldn't produce
> >something different. Esp. if the input is in error. They should
> >flag the error and give up.
>
> Ok, fine ... but we're not talking about that, are
> >In general, I don't think the question is easy to answer.
> >What if an attacker, or mistake, moves the divider
> >between the display name and angle address? And it's
> >even more complicated because an "address" can be an nmh
> >alias.
> I am trying to envision this attack you describe, and
Lyndon wrote:
> I have an Oracle Solaris 11.1 builder running now. It's failing a
> couple of regression tests.
Thanks. Fixed a couple, working on the last one.
There are a couple of legit "warning: statement not reached"
compile warnings on Solaris about this kind of thing:
exit (RCV_MOK
> >My concern is that something like boss=?utf8?Q?=2cX=excluded,
> >where X is a invalid UTF byte, will get converted to
> >boss=?utf8?Q?=2c?=excluded, which is a legal encoding of
> >boss,excluded. If you can guarantee that kind of thing won't
> >ever happen in an nmh draft, great.
>
> I guess I
> >Would it be very difficult for mhfixmsg to have an option
> >(maybe -reformat -reformat ?) to update the text/plain
> >version in a message? Constant Contact only updates the
> >text version of a newsletter when an administrator explicitly
> >does so by hand. Consequently I often see out of date
> >I don't think we want -remove text/plain because that would
> >remove all text/plain parts.
>
> Hm, well ... if you have a "simple" message that is just a
> multipart/alternative, maybe you do?
I'm coming around to that way of thinking. Removing all
text/plain subparts from multipart/alternat
I just added a -replacetextplain switch to mhfixmsg. If
enabled, -reformat will replace any existing text/plain part,
such as those that are empty or that don't match their
corresponding text/html part.
David
___
Nmh-workers mailing list
Nmh-workers@no
I wrote:
> The mh-folders(5) man page has a description of the directory
> and file structure used by nmh.
That man page is one of the post-1.5 additions. If you want to
download just that file, it's available at
http://git.savannah.gnu.org/cgit/nmh.git/plain/man/mh-folders.man
David
_
Brenda wrote:
> I'd like to switch to using nmh for email handling. I've been using
> thunderbird for the last few years.
Welcome to nmh! My first suggestion would be to make sure
that you're using nmh 1.5. Each of the nmh commands will
show the version using its -version switch.
Or if you'd
Hi,
There was brief discussion a while back about nmh support
for iCalendar (text/calendar, .ics, RFC 5545) attachments.
It looks like calcurse, http://www.calcurse.org/, will let
us view, send, and respond to calendar requests easily,
though a bit crudely. It's packaged for Macs and many Linux
a
Michael wrote:
> What I would prefer is an MH-level filter that transforms
> format=fakeflowed into real format=flowed. (I would really like
> that filter to stick in front of mailman too..). So the stuff on
> disk would be format=flowed!!!
mhfixmsg? Though it will only transform encoded MIME
Norm wrote:
> Ken Hornstein writes:
> >Hope it didn't come across like I was picking on you ... you
> >had explained (from what I remember) that a correspondent of
> >yours complained that your emails looked "funny", so you
> >eventually settled on just making your paragraphs one long
> >line.
N
Ken wrote:
> While we will never encode text parts with base64
> (although that might change in the future), I also think
> we get them wrong on display or storing. Does everyone
> agree that text parts encoded in base64 should be decoded
> and converted to Unix line conventions? It looks like
>
Ken wrote:
> > [Norm wrote;}
> >In that perfect world, the conversion from quoted-printable
> >to straight text, would have to be done by inc.
I agree, and that's my world now. But I use rcvstore via
procmail instead of inc.
Off the top of my head, my suggestion would be to create a shell
alias
Joel wrote:
> I've noticed recently that I'm getting some mojibake in messages from
> a few sources. Both examples I have handy have a quoted-printable UTF-8
> encoded text/html part, and one also has a quoted-printable UTF-8
> encoded text/plain part.
>
> The one which is HTML only happens also
Norm wrote:
> Is there a good way to get a list of message numbers into a bash script,
> without the prefixes normally attached by mhpath and mark. What I've been
> doing is something ugly like:
>
>
> $(mhpath first:3 17 last:4| sed -e "s@.*/@@" -e "s@\n@@"
>
> Is there a cleaner way?
Ye
Joel wrote:
> Would it be possible to roll out a 1.5.1 which contains that patch?
If you don't like Ken's answer, it's really easy to build
nmh on Fedora:
$ git clone git://git.savannah.nongnu.org/nmh.git
$ cd nmh
$ docs/contrib/build_nmh -di
build_nmh will ask for confirmation of several
Ken wrote:
> For those of you that don't spend too much time looking at RFC 822/2822/5322,
Also RFC 6854. It just allows group support in some header
fields that 5322 doesn't. I bring it up because it was
proposed in March 2013, so apparently there's still interest
in developing group support.
> >I vote for just updating the documentation. Because the
> >trailing semicolon isn't required, maybe we shouldn't call
> >it group support, just blind list? And maybe that would
> >avoid Ralph's objection?
>
> I'm not sure how to write some documentation here that is clear; I
> prefer using RF
If you're living off the git repo, please update to pick up a
fix to m_getfld(). When I fixed the bug that Paul Fox reported
back in May, I broke handling of headers bigger BUFSIZ
(typically 8K on Linux, et al.). Both bugs are fixed now.
Thanks,
David
___
Paul wrote:
> this reminds me of a question: how likely is it that a checkout of
> any arbitrary git commit will work well?
Right now would be fine :-)
> i'd like a sense of whether i'm likely to hit the middle of
> development churn.
In general, if it's been quiet for a few days, I would expe
I wrote:
> Paul wrote:
>
> > this reminds me of a question: how likely is it that a checkout of
> > any arbitrary git commit will work well?
>
> Right now would be fine :-)
More generally: if the test suite ("make check") passes, I'd
have very high confidence that the checkout will work well.
Ralph wrote:
> Hi Valdis,
>
> > ! Need to go! Need ... to ... go!
> > !Need to go! Need ... to ... go!
> >
> > I have zero clue why mhfixmsg is apparently adding 2 leading blanks to
> > the line.
>
> Give us a clue about the third. ;-)
:-)
Valdis, what platform is this on? And what does
Valdis wrote:
> Verdict: elinks is introducing the 3 blanks.
Thanks, I'll install elinks and see what I can do to handle it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Lyndon wrote:
> The Solaris issue is putting /usr/xpg4/bin ahead of /bin.
> That should have happened in the last century ...
>
> I should remember to do that for the buildbots, but
> sometimes I forget ...
On the other hand, if you don't then we're more likely to
run on other oddball platforms t
Ken wrote:
> >[Ralph wrote:]
> >If "attach" instead appended an mhbuild directive to the draft, would
> >that make the path after that simpler?
>
> No.
>
> My feeling is that if you put a mhbuild directive in the draft,
> you're prepared to deal with any issues arising from it. But I
> don't th
> >Why wouldn't that be reasonable? The logic would be simpler:
> >
> >In WhatNow?
> >
> >- If you run "mime", run mhbuild on the draft.
> >- If you "attach", add the appropriate mhbuild directive. Do not do
> > this if there is a MIME-Version header.
> >
> >In post(8):
> >
> >- Run "mhbuild -au
> >I think it'd be worth trying to solve that. Could we look for
> >false mhbuild directives and escape them if not already escaped?
>
> I think it would be challenging; the code that does that is the regular
> MIME parsing code. Also, the syntax is that if it's not something that
> is recognize
Jon wrote:
> Gave this a bit more thought. What *exactly* is the issue?
I'll take a shot, but Ken can probably do better: we want
nmh to always produce mime messages without getting confused
by text that isn't a mhbuild directive but looks like it,
while still supporting attach.
> Is it a lack
I wrote:
> Valdis wrote:
>
> > Verdict: elinks is introducing the 3 blanks.
>
> Thanks, I'll install elinks and see what I can do to handle it.
The test relies on diff -b to compare the text lines.
Two problems here:
1) POSIX diff only has -b (not -w), and it says that a line with
no space
Ralph wrote:
> sed 's/^/ /' on both files beforehand would make -b happy? Expected can
> be done once, actual each time...
That works.
> > 2) elinks inserts some non-breakable spaces (U+00A0), and GNU diff
> > doesn't recognize them as whitespace (my LANG is en_US.UTF-8).
>
> Here, this elinks
I wrote:
> I put in that awk magic.
Ah, but it busts on Solaris:
awk: syntax error near line 1
awk: bailing out near line 1
At least we know where the problem is. What's your sed
equivalent of cat -s?
David
___
Nmh-workers mailing list
Nmh-work
Robert wrote:
> awk 'length($0) == 0 && e == 1 { next }
> { e = length($0) == 0 }
> { print }'
results in:
awk: syntax error near line 2
awk: illegal statement near line 2
Ralph wrote:
> Oh, line 1. `awk --posix' here suggests length would like parenthesis.
>
>awk '!length
Rickard wrote:
> Forgive me for maybe being silly due to ignorance of Nmh internals, but
> 'elinks -dump' introducing leading whitespace might perhaps be remedied by
>
> > elinks -eval 'set document.browse.margin_width = 0' -dump [...]
Nice, I added that option to the elinks command used by
Ralph wrote:
> Apparently, /usr/xpg4/bin/awk is POSIX compliant. Can build and
> test instructions for nmh on Solaris not state /usr/xpg4/bin needs
> to be up the front of PATH?
Yes, but then our buildbot provider, maintainer, and
gracious host would have to actually do that :-) But
seriously,
Peter wrote:
> Does anyone have an mts.conf setup that works with Fastmail.fm?
> Ideally, I'd like to use their proxy server,
> smtps-proxy.messagingengine.com, since my employer blocks outgoing
> smtp connections.
Are you using SSL and authentication? If not, I expect
that you'll have to. Your
Lyndon wrote:
> My preference would be for the configure script to detect it is
> being run on Solaris and fudge $PATH appropriately. That way we get
> consistent source builds on Solaris even when the person building
> doesn't have the XPG4 tools at the front of their path.
At some point, the p
Ken wrote:
> I don't know anything about fastmail.fm, but does it actually speak
> SMTP on port 80?
Sure looks like it. This is through an ssh tunnel:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.messagingengine.com ESMTP ready
Ken wrote:
> Huh. Well, I can't speak to that ... when I try connecting to it remotely,
> I get a web server on port 80.
See below, he's using a different server.
> You would want this in your .mh_profile:
>
> send: -server mail.messagingengine.com -port 587 -tls -sasl -user
> usern...@fastma
Peter wrote:
> On Sun, Dec 8, 2013, at 04:10 PM, David Levine wrote:
> >
> > > You would want this in your .mh_profile:
> > >
> > > send: -server mail.messagingengine.com -port 587 -tls -sasl -user usernam
> e...@fastmail.fm
> >
> > You'
Peter wrote:
> Looks like one of the post-build tests failed:
We of course want to figure that out, but in the mean time
you should be able to "make install" and then try to send.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists
Valdis wrote:
> On Sun, 08 Dec 2013 00:27:28 +0100, Rickard Carlsson said:
> > Forgive me for maybe being silly due to ignorance of Nmh internals, but
> > 'elinks -dump' introducing leading whitespace might perhaps be remedied by
> >
> > > elinks -eval 'set document.browse.margin_width = 0' -d
Ken wrote:
> Can the people who want to have "attach" append mhbuild directives
> explain what their thinking is, specifically why they think their
> approach is preferrable? I went back and looked at the thread very
> carefully, and none of the proponents of this approach really covered
> why th
Paul wrote:
> that's an interesting point, and i just realized that it's one reason
> i've never been comfortable with attach. my editor supports enough
> filename completion that when inserting the mhbuild directive (via a
> helper script), i can be sure that the filename is spelled correctly
>
Ken wrote:
> Well, let me make this alternate proposal:
>
> - "attach" adds Nmh-Attachment headers as per usual. Maybe we'll add
> something like: "attaching foo.pdf to message as application/pdf" so
> the user can see what MIME type is being used (really, that's all
> I care about).
>
>
Lyndon wrote:
> I have added an OpenBSD 5.4 (amd64) buildbot slave to the mix.
>
> Their auto{conf,make}s require some environment variables be set to
> pick which version of the tools to run under the hood. For now I
> have wired a hack into autogen.sh, but a better solution is
> required.
Cool
Paul F. wrote:
> mainly it's because attach removes attachment from the flow of
> composition -- i have to remember to attach _after_ i've written out
> my draft, which to me is the "ready to send" point. i forget to
> include the attachment often enough as it is -- i much prefer adding
> an atta
Ken wrote:
> >One question: would it make sense to put the entire mhbuild
> >directive in the Nmh-Attachment header instead of just the
> >path? Users could then edit it as they wish.
>
> I feel the answer is "no". I would like to give users the option to
> add their own Nmh-Attachment headers
Jon wrote:
> Ken writes:
> > >[David wrote:]
> > >It depends on priorities: I'd rather be able to customize
> > >an attachment than manually insert a simple Nmh-Attachment
> > >header (I think that's the option you mention). I've never
> > >done that.
> >
> > It's just that when I hear the word
Pascal wrote:
> On Thu, 12 Dec 2013 19:52:54 -0500, David Levine wrote:
> > test-manpages fails because of a slew of these:
> >
> > man8/post.8:1: warning: unbalanced .el request
> >
> > Any ideas?
>
> To me, this looks like it could be caused by a loca
Pascal wrote:
> rand()/srand() are not cryptographically secure PRNGs. Some systems
> have the much better suited arc4random() family of functions; there's no
> reason to not use it if it is available. Make m_rand() just a wrapper
> around arc4random_buf() in that case. (There's no need to ever
Pascal wrote:
> On Thu, 12 Dec 2013 19:52:54 -0500, David Levine wrote:
> >
> > test-manpages fails because of a slew of these:
> >
> > man8/post.8:1: warning: unbalanced .el request
> >
> > Any ideas?
>
> To me, this looks like it could be ca
Paul F. wrote:
> i'm having trouble with the next two points:
>
> > > - If you try to "attach" after a "mime", you get an error.
> > >
> > > - send runs "mhbuild -auto -nodirectives". "-auto" means, "don't
> > > error out if there's a MIME-Version header, just don't process the
> > > draft
Paul F. wrote:
> how do i use whatnow's attach to attach a file, like a mail
> message, with a specific Content-Type? i.e., if i use this:
> Nmh-Attachment: /home/pgf/Mail/inbox/2902
> i get a Content-Type of text/plain rather than message/rfc822
I've been thinking about this. It's possible
Norm wrote:
> I'm confused. Are you saying that a file not in the hierarchy
> starting at the user's MH directory, cannot be a message file?
No, I'm saying that I don't want to parse the file to determine
if it's a message. But Jon has a good way around that.
David
Jon wrote:
> David Levine writes:
> > I've been thinking about this. It's possible, though maybe
> > a bit tricky, to determine if the file is a message in the
> > user's MH folders. If it is, should attach set the
> > Content-Type for the part to
Jon wrote:
> So my opinion is to live with it for now. If you're happy with
> attach, then use it. If you want to use mhbuild, go ahead. Just
> don't use both. Save your energy for a coding effort with a greater
> value proposition.
The movtivation behind all this is to always produce MIME
me
tractions.
Ingo wrote:
> Actually, David Levine already agreed in private mail that
> an audit would make sense
Well, my exact words were:
Maybe we'll get to that task some day. In the meantime,
the significant noise from the linker could obscure more
pressing problems. Th
Ralph wrote:
> I was thinking more of every nmh command optionally running under
> valgrind for all the tests.
That's been on my wish list for a while. Patches welcome :-)
The test suite does run every undeprecated nmh command, that's a
start.
David
___
Ken wrote:
> - Really, this overuse of strcpy/strcat results from our usage of fixed
> sized buffers. We should be switching to dynamically-allocated strings
> whenever possible. Fixing that means dealing with idea of who actually
> owns a particular memory object and is responsible for fr
Jon wrote:
> David Levine writes:
> > Paul F. wrote:
> >
> > > how do i use whatnow's attach to attach a file, like a mail
> > > message, with a specific Content-Type? i.e., if i use this:
> > > Nmh-Attachment: /home/pgf/Mail/inbox/2902
>
Jon wrote:
> Cool. Thanks. BTW, would it make sense to have a -v option on "al"
> at whatnow where -v would mean verbose and show the mime type, etc?
> That way the hard core among us could check and fall back to mhbuild
> if they didn't like the way that it looked.
Yes, I'd use that. That's n
Lyndon wrote:
> I just took a peek at Mac OS; it uses 'file --mime-type' :-P But it
> also supports a a '--mime-encoding' flag that adds a charset parameter
> to the output.
Does it support "file --mime" as well? I'm not asking what the
man page says :-) It looks like --mime was left out of th
Ken wrote:
> - Default to 8bit C-T-E (when required)
If we always run the draft through mhbuild, will that ever
be required? Just trying to save work here.
Unless you're referring to really sending 8-bit content, but
is there demand for that?
David
Ken wrote:
> >Unless you're referring to really sending 8-bit content, but
> >is there demand for that?
>
> Are you asking if people compose drafts with 8-bit characters in
> them? Seems like the answer to that is "yes". If you're asking if
> people want a C-T-E of 8bit ... well, it would be fr
I wrote:
> Ken wrote:
>
> > >Unless you're referring to really sending 8-bit content, but
> > >is there demand for that?
> >
> > Are you asking if people compose drafts with 8-bit characters in
> > them? Seems like the answer to that is "yes". If you're asking if
> > people want a C-T-E of 8bi
> >> I agree that 8bit would be friendlier. The question is
> >> whether we should try to get it into 1.6.
> >
> >And another possible issue: I'm not sure that our MIME
> >parser can handle 8-bit input. I don't have evidence
> >at hand, but I tried quickly a while back and ran into
> >trouble.
>
Ralph wrote:
> So C-T-E 8bit is nice because it means I can comp(1) UTF-8 in vim and
> the dcc-copy is still 8bit UTF-8 in ~/mail/inbox so great for grep(1),
> etc. Unlike QP or base64.
I'll put in a plug here for mhfixmsg -decodetext, though I agree
that it's better to simply avoid the encoding
Robert wrote:
> Norm,
>
> I hope I speak for all of us when I say we all hope, and expect,
> that you will be with us for many years to come.
I am certain that you do speak, and very well at that, for all of us.
Thank you, Norm, for MH and your contributions to its derivatives.
And, Happy Birt
Ralph wrote:
> I was thinking more of every nmh command optionally running under
> valgrind for all the tests.
Done. If the NMH_VALGRIND environment variable is set when the
test suite is run ("make check"), it will try to use valgrind
when running the program under test.
It found a couple of p
Ralph wrote:
> My rmmproc creates filenames like ,10139,1388316255.094920554
> so as more of those pile up, less entries fit in the 32KiB and
> more calls to it are needed and there's more entries starting
> with `,' to be skipped over. Clearly, I need to switch to ','
> + base254-encoding. ;-)
401 - 500 of 1610 matches
Mail list logo
