Marcin wrote:
> >> David Levine wrote:
> >> >> I was also wondering if we should give the user to abort waiting
> >> >> for a lock with ^C.
> >> >
> >> > I tried, and ^C works for me (on Linux).
> >>
> >> That'
Marcin Cieslak wrote:
> >> David Levine wrote:
> > Marcin wrote:
> >
> >> >> David Levine wrote:
> >> >> >> I was also wondering if we should give the user to abort
> >> >> >> waiting for a lock with ^C.
>
Marcin wrote:
> >> David Levine wrote:
> > Marcin wrote:
> >
> >> With a failing setgid() (fixed by another patch already) I am getting:
> >>
> >> % inc
> >> inc: unable to set group to 6 setegid: Operation not permitted
> >> inc:
Marcin wrote:
> While I was researching locking vs. signals issue I found m_chkids()
> function in context_save.c
>
> I think this function is no longer necessary? without it
> context_save() can be simplified a bit.
>
> I believe we no longer have setuid binaries, do we?
You're right, we don't.
Ralph wrote:
> I've found switching to it [UTF-8] is better for most things.
Let me second that. It's the default on the platform I use, but I
unintentionally disabled it for a while. After fixing that, I now
see characters such as ½ that I'd rather not miss. And those
gratuitously messy quote
Norm wrote:
> But the best way to get the message numbers having such a component,
> WITH the corresponding contents of the component is not obvious to
> me.
Some variation of (assuming bash and GNU grep):
msgs=last:45
for i in $(pick $msgs --X-Spam-Status score=); do
[ $i -ne 0
Norm wrote:
> Looks like that will do it,
I would try something like this first:
pick last:45 --X-Spam-Status score='[3-6]\.'
It should work out of the box and is easy to maintain.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https:
Norm wrote:
> In summary, I vote no, unless the fix is trivial.
The format addition itself would be trivial, but with documentation
and tests, would touch 7 code files. I'd rather not.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https:/
I merged the convertargs branch to the main trunk. The only
change in default behavior is that mhshow/show now display a
formatted version of iCalendar (.ics) attachments instead of
their raw text. See the "Convert Interface" section of the
mhbuild(1) man page if you want to disable that, and for
Bob wrote:
> > [Ken:]
> > If your mts.conf has a setting of "sendmail/smtp" or
> > "sendmail/pipe" for "mts", you can temporarily override that
> > via the -mts switch (you want smtp for the MTS).
>
> What program do I use -mts with? It is not a valid option for
> send(1), at least with version 1
Conrad wrote:
> Oh also if I might offer a suggestion for the default use of 'w3m
> -dump', maybe consider adding in
>
> -o display_link_number=1
>
> .. so that link URLs get listed at the end of emails?
I'd rather we didn't start down the path of picking w3m options.
There are a zillion o
Hymie wrote:
> Is there any mechanism where I can have NMH, instead of reading
> a list of BCC addresses, read a file that contains a list of BCC
> addresses?
How about putting an alias instead of a filename in the draft.
Then, put the https://lists.nongnu.org/mailman/listinfo/nmh-workers
Bob wrote:
> Funnily enough I was just starting to think about how to deal
> with this. My first thought was to maintain 2 .mh_profile files
> and alias commands to set a soft link to the appropriate
> depending on the recipient. Essentially, I just need to "comment
> out" the "send" entry in my
Paul F. wrote:
> i've recently started getting messages with multiple MIME-Version
> headers. they all say "1.0", of course.
> i see nothing (just a quick read) in RFC 2045 regarding multiple
> MIME-Version headers.
The BNF shows exactly one, so I'd say the messages don't conform.
Are they from
Ralph wrote:
> I'm unhappy the warning has been removed and not let on by default. I
> like to know when I get sent bum emails and complain. Fix the
> Internets!
I don't think the warning should be on by default (for this benign
nonconformity). When I'm showing a message, I usually have more
i
Ken wrote:
> ... maybe? It's always done it that way, even back in the original
> MH. No one noticed until now.
My guess is that there aren't that many custom postprocs
in the wild. And who knows what's in them.
> >Have the interface to post(8), and thus postproc, include the
> >`file' parame
Kevin wrote:
> I get this message from the contributed replyfilter script
>
> Unable to exec par: No such file or directory
> HTML converter process exited with 2
You'll need to install par. It's available for some Linux
distributions and Cygwin, at least. Source code is available
from http
Paul F. wrote:
> from my "man find":
>-daystart
> Measure times (for -amin, -atime, -cmin, -ctime, -mmin, and
> -mtime) from the beginning of today rather than from 24 hours
> ago. This option only affects tests which appear later on the
> command lin
Ken wrote:
> I think a -daystart (or whatever we want to call it) option should
> apply to all dates on the command line that lack a specific time.
Sounds good to me. Maybe call it something else to avoid confusion.
-midnight?
David
___
Nmh-workers m
Valdis wrote:
> Outlook/Exchange sends a borked MIME structure for meeting invites, that
> is stacked like this:
>
> multipart/alternative
> text/html
> text/plain
> text/calendar
Per kre's observation, are you sure that isn't:
multipart/alternative
text/plain
text/html
t
Bob wrote:
> 127.0.0.1 localhost ayukawa ayukawa.
> 127.0.1.1 ayukawa
Does this solve your problems?
127.0.0.1 ayukawa.localdomain localhost.localdomain localhost
::1 ayukawa.localdomain6 localhost6.localdomain6 localhost6
I rely on my local network's DNS
Bob wrote:
> I'm not actually replying directly to Robert's message. Rather,
> I'm noting that I never received the copy from the mailing list;
> only the one sent directly to me, and after a 33-hour delay
> between Oz and GMail:
>
> [...]
> Received: from munnari.OZ.AU (munnari.OZ.AU.
Paul F. wrote:
> you've just reminded me of one of my favorite special-purpose scripts,
> posted long ago (perhaps to the qmail list) by its author. it parses
> Received headers, converts them all to local time, and prints them in
> "reverse" (i.e., timeline) order, in a uniform format.
Thanks,
I wrote:
> I might add a special case for GMT.
Or use Mikko Hänninen's derivative, http://www.wizzu.com/mutt/mailroute.pl
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Anthony wrote:
> However, I don't want to see the quotes in show(1) output, just as I
> already don't have to type them in my outgoing messages. Can nmh be
> configured that way?
That's easy to configure, by filtering (decoded) addresses through
the unquote format function,
$ fmttest -addre
I wrote:
> Anthony wrote:
> > Should displaying the quotes be the default behavior?
>
> I think that would be the best solution. Any objection?
I meant: I think that not displaying quotes would be the best
solution. This would apply to scan(1) as well.
David
Ralph wrote:
> For me, "" appearing in scan output is a strong signal it's spam, but
> that could just be my ham recipient pool. :-)
I have enough correspondents that use "lastname, firstname" to
make that test unreliable for me.
> Changing the default: does that mean changing the format files
Ken wrote:
> >> Anthony wrote:
> >
> >> > Should displaying the quotes be the default behavior?
> >>
> >> I think that would be the best solution. Any objection?
> >
> >I meant: I think that not displaying quotes would be the best
> >solution. This would apply to scan(1) as well.
>
> I'm also f
Hi,
Should nmh try to get out in front with email address
internationalzation (EAI)? See resources below.
>From the MUA perspective, IIUC, it relies on native support on the
host to handle unencoded UTF-8 addresses. Would nmh support just be a
matter of 1) not encoding addresses (controlled by
I'd be fine with assuming UTF-8 by default, and using it internally.
It'd be even better to parameterize that. In addition to supporting
users who want something else now, it might help us (or more likely
our descendants) at some point in the future. That should be easy if
we always feed everyth
Kevin wrote:
> Should an email address of this form
>
> From: first.last
>
> produce an error like this:
>
> repl: bad addresses:
> first.last -- no at-sign after local-part (<)
If first.last is not quoted, it should. Periods are not allowed in
unquoted display names, per RFC 5322
Kevin wrote:
> In my OP I mentioned that I'm running nmh-1.5. I looked at the
> website just now and see that I'm a minor version behind. I'll build
> 1.6 and see how that behaves.
You did note 1.5 in your OP, and Ken thought this has been fixed. I
think so, too:
- Added quoting of local pa
Jeff wrote:
> I can confirm that this bug is not fixed in nmh 1.6:
>
> jch@schlepp[501]:~$ mhshow -version
> mhshow -- nmh-1.6 [compiled on CFT at Sun Jul 6 02:39:27 UTC 2014]
>
> I even ran repl from the command line (I normally use mh-e).
What exactly is the problem? This works for me:
$
Kevin wrote:
> On 31 August 2015 at 16:55, David Levine wrote:
>
> > What exactly is the problem? This works for me:
> >
> > $ cat `mhpath +drafts 29`
> > From: A. User
> > Subject: test
> >
> > The From: contains an invalid u
Tom wrote:
> I would put the true blame on whatever decided to add -ansi -pedantic
> (particularly the latter) to the compiler switches.
That would be me. I'm willing to remove them (and add them to
build_nmh). Ok with you, Ken?
David
___
Nmh-worker
> >> I would put the true blame on whatever decided to add -ansi
> >> -pedantic (particularly the latter) to the compiler switches.
> >
> >That would be me. I'm willing to remove them (and add them to
> >build_nmh). Ok with you, Ken?
>
> Yeah, I'm fine with that.
Done. The easiest way for me to
Hymie wrote:
> So I'm just wondering what other people are doing. Are you going into
> your raw email, stripping out HTML, undecoding base64, removing extra
> "multipart" parts, things like that?
See mhfixmsg(1) in nmh 1.6 or the current git repo. Its main motivation was to
allow grepping of m
Hymie wrote:
> Does Base64 have anything similar? As far as I can tell, it's just
> lines of unadorned text.
Right, but it sounds like you might need to know how MIME uses it.
See RFC 4648, https://datatracker.ietf.org/doc/rfc4648/?include_text=1
David
_
Richard wrote:
> Anyway, the attached patch adds all of mhshow's documented switches to
> show's handling, on the notion that nmh's pieces should know about each
> other.
Patch applied.
Ken is more familiar with this than I am. But seeing as how he didn't
respond within his usual 10 minutes, I
Conrad wrote:
> I often enough get an error message for emails with a bad
> Content-Transfer-Encoding, telling me to correct it to 7-bit or 8-bit; I
> don't recall mhfixmsg being mentioned in the error report (but maybe I
> just read straight past it); if it isn't, that'd be a great place to
> int
Richard wrote:
> It seems that using a non-absolute MH variable doesn't work when an MH
> program chdir's and exec's a child that needs to read the
> profile. (Example below involving show and mhshow.)
>
> By inspection, setting MH to the resolved, absolute pathname inside
> context_read suffices
Conrad wrote:
> I often enough get an error message for emails with a bad
> Content-Transfer-Encoding, telling me to correct it to 7-bit or 8-bit; I
> don't recall mhfixmsg being mentioned in the error report (but maybe I
> just read straight past it); if it isn't, that'd be a great place to
> int
Wolfgang wrote:
> Conversion attempt 1:
>
> $ mhfixmsg +inbox 174 -decodetext 8bit -verbose -outfile ...
> mhfixmsg: 174 part 2, decode text/plain; charset="iso-8859-1"
> mhfixmsg: 174 part 1, decode text/html; charset="iso-8859-1"
>
> The resulting file is identified by "file"
Wolfgang wrote:
> I've constructed a test message that shows the issue. The original
> test message is "200", and my attempts to convert it (the text part)
> are 201 (no specified, thus charset="iso-8859-1"; file is OK, but I
> want UTF8)
Right, per my previous message, -notextcharset is the de
Wolfgang wrote:
> Well, at least the HTML part is still marked as charset="iso-8859-1"
> and Content-Transfer-Encoding: 8bit, and indeed it contains ISO-8859-1
> characters.
Right, mhfixmsg (currently) only converts text/plain content.
> Either fixmhmsg should not touch the HTML part at all, i.
Wolfgang wrote:
> And I feel that parsing and modifying the actual content
> of the message parts is something that should NOT be done.
> OTOH, we might always have such a problem. We cannot know if even
> a text/plain part comes in some internal format that includes
> information about the used
Wolfgang wrote:
> So should I kind of file a "feature request" to add some option to
> mhfixmsg that makes it decode "text/plain" only, while leaving other
> text parts (like "text/html" in my case) alone?
>
> [Or an option that allows to pass a list of Content-Types which shall
> be processed, so
Valdis wrote:
> mhfixmsg: unable to open for writing /home/valdis/Mail/mhfixmsg6zYphW: Too
> many open files
Well, I can't say that I'm surprised, but of course this shouldn't happen.
mhfixmsg uses the MH MIME parser and it likes tmp files. I tried to be careful
with mhfixmsg but it's possib
I wrote:
> Wolfgang wrote:
>
> > So should I kind of file a "feature request" to add some option to
> > mhfixmsg that makes it decode "text/plain" only, while leaving other
> > text parts (like "text/html" in my case) alone?
> >
> > [Or an option that allows to pass a list of Content-Types which s
Wolfgang wrote:
> Dear David,
>
> In message you
> wrote:
> >
> > I added a -decodetypes switch to mhfixmsg:
> >
> > -decodetypes type/[subtype][,...]
>
> Cool. where can I find that, please?
It's in the git repo. If you haven't been using that, these will download from
master, build,
Wolfgang wrote:
> However I notice that not only the "text/plain" part has been
> modified; the "text/html" part has _also_ been modified:
> originally, it was a base64 encoded HTML file with UNIX line endings
> (plain LF); now it is a base64 encoded file with DOS line endings (CR
> + LF).
>
> So
Wolfgang wrote:
> mhfixmsg: ... part 1.2, will not decode because it is binary (line length > 9
> 98)
>
> This is because the HTML message is actually a single, very long line
> (don't ask my why Android creates something like that).
>
> But the result is double ugly: decoding of the text/plain pa
Wolfgang wrote:
> mhfixmsg -verbose -decodetypes text/plain
>
> gives:
>
> mhfixmsg: Don't know how to convert ..., there is no mhfixmsg-format-text/htm
> l profile entry
That is due to a different transformation, not decoding. By default
(-reformat), mhfixmsg tries to add a text/plain part cor
Wolfgang wrote:
> Yes, I'm sure about that. mhfixmsg issues the error message above,
> and leaves the whole message unchanged, i. e. it does not touch the
> text/plain part either.
I can't replicate that. I added a check to test-mhfixmsg (and it
passed even before today's fix to mhfixmsg).
I d
Wolfgang wrote:
> In message <4e5f7dec-3dfc-4bbf-9d64-955f71aaf...@hubcas2.seas.wustl.edu> you
> wrote:
>
> > That is due to a different transformation, not decoding. By default
> > (-ref> ormat), mhfixmsg tries to add a text/plain part corresponding
> > to each text part that doesn't have one. I
Ken wrote:
> [Wolfgang:}
> >> However I notice that not only the "text/plain" part has been
> >> modified; the "text/html" part has _also_ been modified:
> >> originally, it was a base64 encoded HTML file with UNIX line endings
> >> (plain LF); now it is a base64 encoded file with DOS line ending
Ken wrote:
> according to the RFCs (see RFC 2046, §4.1.1, paragraph 1).
>
> Now, should mhfixmsg correct that? Weeelll ... good question. The
> reason it is happening is because our MIME parser is now doing the
> 'right' thing, and essentially the whole message is being regenerated.
> Fixing tha
Paul F. wrote:
> i think it would be helpful for the man page to be very explicit about
> what mhfixmsg does by default (it's only somewhat implicit, now),
There's a DEFAULTS section near the end.
> perhaps along with some example invocations for the most common
> problems/solutions.
Yes, those
I wrote:
> mhfixmsg currently strips CRs out of text parts that it's decoding, which is
> wrong. I'll fix that, with default behavior. But I plan to add an option to
> strip/not add CRs.
I just added -[no]crlflinebreaks switches to mhfixmsg:
By default, carriage return characters are pr
Paul F. writes:
> in the meantime, any objections if i add this new section to
> mh-folders.man, or something like it?
> Naming
> nmh folders can be given arbitrary names, with one exception:
> folders should not be given all-numeric names. This limitation
> results from nmh
Ralph wrote:
> I wrote:
> > So this should stop happening when I fix the locking? Is that true?
>
> strace(8) shows inc is using fcntl(2)'s F_SETLK, and,
mhparam can also tell you how nmh was configured:
$ mhparam spoollocking
fcntl
That might be interesting to look at, because flock(2
Norm wrote:
> Maybe Contributions should have a tutorial script or two which
> illustrate good ways to do that?
How about adding this to the man page?
EXAMPLES
Basic usage
To run mhfixmsg on the current message in the current folder, with
default transformations to fix MIME boun
Ken wrote:
> So, in short: cut a 1.7, yes or no? Anything people would like in there?
> My list is:
>
> - Incorporate XOAUTH support
> - Fix character conversion on message bodies (right now it aborts if it
> cannot convert characters to the target character set).
Sounds good to me. I'd also
Eric wrote:
> I can freshen up the branch. Did anyone ever review it? Should I merge it
> as is? We should settle the api key management issue too.
I looked at it, but not even close to review. How about leaving it on the
branch and we'll look it at there. I really do want to use it, just have
Norm wrote:
> David Levine writes:
>
> >Translate text/plain parts to UTF-8
> >To translate all text/plain parts in the current message to UTF-8, in
> >addition to all of the default transformations:
> >
> >mhfixmsg -textcharset utf-8
>
> How do I t
Norm wrote:
> The bulk of the non-spam mail I receive still has a utf-8 or a quotedPrintabl
> e part. I would like to apply UNIX text processing tools (grep, wc, sort,
> uniq, perl, etc) to these messages. It would be nice if the next release made
> that reasonably easily possible.
That's the
Jerrad wrote:
> I use slocal with rcvstore and at various times either MIME-hooks or the
> following .mh_profile entries
>
> add-hook: /usr/local/bin/mhfixmsg
> mhfixmsg: -decodetext 8bit -reformat -replacetextplain
Note that -decodetext 8bit and -reformat are defaults, so they're not necess
Conrad wrote:
> Yes, seems so; I guess I'd just like a "best practice" section in the
> mhfixmsg man page which shows (for example) a recommended command line
> invocation (more-or-less covered a few emails back) and a procmail recipe.
There's been a procmail recipe in the man page since March
Norm wrote:
> I want to output to stdout all the lines of that part that contain the
> string "family". What command go I feed into 'grep family"?
Well, it depends whether you want to modify the message on disk or not.
If you do want to modify the message permanently:
$ mhfixmsg
$ grep
Laura wrote:
> but I would be seriously inconvenienced if mh directory mail store
> went away.
Enough of us would also, I expect, that this won't happen. At least at some
layer that the user can see.
David
___
Nmh-workers mailing list
Nmh-workers@no
Norm wrote:
> Much of that was not clear to me from the man page. But that may say more
> about me than about the man page.
I don't know about that. In any case, I added all of it to the man page this
morning. I expect that it will be useful to others. Keep the questions coming.
David
_
Valdis wrote:
> So trying to debug why a message got eaten by procmail.
What does "mhlist -file t1" say about the message? mhfixmsg -verbose?
Would you please send me some reasonably complete extract of the message so
that I can debug it?
David
___
Valdis wrote:
> Sending you the message as an attachment via private e-mail.
The MIME boundaries didn't match, and the one at the end of the message was
broken across two lines. mhlist did notice.
I committed a fix to mhfixmsg to not modify the message. At all. Thanks.
David
__
Eric wrote:
> I think we decided my names were ok? I don't mind at all if someone
> wants to change them now.
I think they're fine.
> > - Repeating -user for each command is possibly odd. Maybe put
> > -user on mhlogin and save it in the cred file. Arguably easier
> > -for the user this wa
Greg wrote:
> I'm running OS X 10.9.5 and my username on this machine
> "gregory.nisbet". I believe this is causing one of the tests to fail.
Yeah, I'm not surprised. I'll take a look later.
David
> Hi everyone,
>
> I'm running OS X 10.9.5 and my username on this machine
> "gregory.nisbet". I
Greg wrote:
> I'm running OS X 10.9.5 and my username on this machine
> "gregory.nisbet". I believe this is causing one of the tests to fail.
I just committed a fix. Without -user, slocal would default to a user based on
addr. It would removed characters before the first period, if any. It's
Hymie wrote:
> The easy way:
>
> from the "what now" prompt, answer "attach /full/path/to/filename"
Yes, that's the easiest way. The whatnow(1) man page describes the commands
for managing attachments.
David
___
Nmh-workers mailing list
Nmh-workers@
John wrote:
> I hope this report is useful to you.
> I ran configure --prefix=ONETHING --exec-prefix=ANOTHERDIR
> make
> make test and got two errors (see below).,
> As the errors will show, I was attempting to build/install in AFS.
I don't have AFS installed so I can't debug these. Would you be
Thomas wrote:
> If I understand correctly, initialtls is TLS and tls is STARTTLS.
Yes, where initialtls encrypts the entire SMTP transaction. I bring that up
because it might explain the following (in the other direction):
> I didn't manage to receive POP mail from nmh with inc,
If you want t
I added a program, docs/contrib/sendfrom.c, that selects the SMTP server based
on the draft's From: address.
The source code can be viewed at
http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/contrib/sendfrom.c
An excerpt from the usage notes is below.
It can take full advantage of nmh's
Conrad wrote:
> Do you have anything set up to automatically alter From addresses when
> replying?
Here's the relevant part of my replcomps:
%<(nonnull(getmyaddr{to}))From: %(myname) <%(getmyaddr{to})>\
%?(nonnull(getmyaddr{cc}))From: %(myname) <%(getmyaddr{cc})>%>
If one of my addresses isn't
Ken wrote:
> My only quibble is perhaps that the implementation
> is a bit inelegant but on further reflection it's probably the best
> that can be done given the current API.
If you're referring to the special handling for whom, that doesn't need to
migrate to send. A lot of the other code doe
Ken wrote:
> I had a few questions; I guess Eric is probably the best person to
> answer them,
Right, but I'll take a stab at them in the hope that I can save him
the trouble.
> - From looking at the protocol document and the source code, it seems
> that (using RFC 6749 termology) mhlogin gets
Ken wrote:
> It occurs to me that this makes it hard to have a postproc that sends
> to different mail servers based on the "From" address ... because this
> mechanism is unique in that it requires "send" to generate the access
> token, and you can't change things when postproc is called.
Well, y
Ken wrote:
> I'm just thinking about a hypothetical world where there would be two
> different mail servers that support XOAUTH; you don't get to make the
> choice in postproc, because send(1) is the guy who generates the bearer
> token.
Actually, you do get to make the choice, because postproc c
Ken wrote:
> Errr ... I'm not sure what you mean there, but it certainly does parse
> the draft to decide who to deliver the message to (also, to set the
> SMTP envelope address, process Fcc, and a few other things). Unless I
> misunderstand what you mean, of course.
My mistake, I should have sa
Ken wrote:
> >[David:]
> >I added a program, docs/contrib/sendfrom.c, that selects the SMTP
> >server based on the draft's From: address.
> >
> >The source code can be viewed at
> >
> >http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/contrib/sendfrom.c
>
> I think this is great. My only qui
Hi,
post(1) -snoop currently doesn't decode base64-encoded smtp
authentication information. I'm thinking of decoding it to make it
easier to use, and to not mask it. For example, -snoop currently
shows this with AUTH LOGIN:
(tls-decrypted) <= 334 VXNlcm5hbWU6
(tls-encrypted) => dXNlckBl
Ken wrote:
> I personally have no objections ... but my only caution is that sometimes
> the base64 encoded SASL tokens are actually binary, so you should make
> sure you use a pretty-printer that can handle binary.
Right, I was thinking of hexifying non-printable characters, e.g.,
displaying [0x
Ken wrote:
> I don't think you can make an assumption what the _decoded_ base64 SASL
> tokens are; that is just talking about what appears in the AUTH messages,
> not what the tokens contents are. I mean, we can't even make an assumption
> with regards to character set without knowing more about
The attempted base64 decoding of -snoop traffic has been committed. Here's
an example of what an AUTH PLAIN request will look like:
AUTH PLAIN b64
I also tried to handle XOAUTH2, AUTH LOGIN, and any line including or following
a 334 request from the server.
If the base64 is invalid, a warni
Ralph wrote:
> $ mhparam folder
> -nocreate
> $ folder +/this/does/not/exist
> $ echo $?
> 1
>
> I'd expect something on stderr.
Well, the man page doesn't promise that:
Specifying -nocreate will cause folder to exit without creating
a non-existant folder.
It wouldn'
Ralph wrote:
> Well, folder(1) is kind of cd and mkdir in one. With -nocreate, I'm
> cd-ing to the folder, and cd complains when the directory's missing. I
> agree I should notice the lack of "/this/does/not/exist+ has no
> messages.", but the Unix norm is silence if all's well so I've been
> co
Ken wrote:
> But it turns out that it just appends the message-id to the existing
> header without wrapping ... and if you get into a long email thread, that
> can exceed the maximum email header limit. This seems like poor behavior.
I think that appending the message-id on a new continuation li
Ken wrote:
> Hrm. I thought about that, but it seems like it's slightly suboptimal;
> You'd have to deal with a header that would take up a lot of space.
As in more lines? I see 3 or even 4 screenfulls of header fields in typical
messages these days, so a few more lines won't matter.
> Also, i
Ken wrote:
> > [Ralph wrote:]
> > 1 memmove(0x13e61a0, "\n\nab\n", 5) = 0x13e61a0
>
> That looks like it happens in sbr/m_getfld.c:read_more().
I think that first character is missed here:
> > 2 memcpy(0x13ec980, "b\n", 2) = 0x13ec980
That's this line (738) in m_getfld
I wrote:
> In spite of the comment, I don't know why readpos needs to be incremented.
After sleeping on it: it doesn't. I committed the fix.
Thanks, Ralph and Ken.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/m
Ron wrote:
> Before answering, keep in mind that I will likely need to configure the
> SMTP server on the remote VM (postfix) in such a way that my home machine
> will be able to authenticate to it, you know, in order to send outbound
> mail. (The last time I tried something like this I think I g
Ken wrote:
> [Norm:]
> >Is there a way to forward messages so that all the attachments of
> >the forwarded messages are attachments to the new message, other than
> >a script using mhlist?
>
> If you want to create a new message which just happens to contain all of
> the attachments from another m
Laura wrote:
> My nmh displays base-64 encoded mail just fine, but if you try to reply
> or forward with the message quoted, it doesn't convert.
nmh 1.6 has docs/contrib/replyfilter, it contains usage instructions.
nmh 1.7 will have (and current master has) docs/contrib/replaliases, it
also cont
801 - 900 of 1611 matches
Mail list logo
