Hi Ken,
> > Well, that's the parsing side; making the `/subtype' optional. But
> > the above comment suggests RFC-violating `Content-Type: text' would
> > arrive from ATTMail when they sent to
> > internet!nongnu.org!nmh-workers.
>
> Sure, but ... I'm still trying to understand the difference in
Hi Ken,
> I would agree this is easy to miss, and it is confusing at the top of
> the man page where you could definitely read it as saying the whole
> file is a mhbuild composition file, rather than just the body. Maybe
> you'd be willing to add some man page changes for 1.7?
I think 1.7 should
>The first mention mhbuild(1) mentions of the input format is
>
>An mhbuild “composition file” is just a file containing plain
>text that is interspersed with various mhbuild directives.
>
>In the next paragraph it says "Basically, the body contains one or more
>contents", and that's the fi
Hi Ken,
> > Well, at least it does if I'm doing comp, whatnow, mime, edit. If I
> > run mhbuild(1) then it always gives quoted-printable.
> >
> > $ mhbuild -
> > # > a£d
> > w£z
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset="UTF-8"
> > Content-ID: <17591
>Well, that's the parsing side; making the `/subtype' optional. But the
>above comment suggests RFC-violating `Content-Type: text' would arrive
>from ATTMail when they sent to internet!nongnu.org!nmh-workers.
Sure, but ... I'm still trying to understand the difference in this code
between a zero
Hi Ken,
> Where it actually ends up segfaulting is in InitText(). The original
> code from mh-6.8.5 says:
>
> if (!*ci -> ci_subtype) /* XXX: attmail bogosity! */
> ci -> ci_subtype = add ("plain", ci -> ci_subtype);
...
> I guess maybe the idea was you could do:
>
> #
> Without h
>I didn't punt on it without good reason. :-)
>It's MIME too, so it's not as if the authors had a 70s'-induced drug
>haze as a crutch.
Where it actually ends up segfaulting is in InitText(). The original code
from mh-6.8.5 says:
if (!*ci -> ci_subtype) /* XXX: attmail bogosity! */
Hi Ken,
> > Also, it SEGVs without the `/plain'. Probably because
> > get_ctinfo()'s
> >
> > 685 if (*cp != '/') {
> > 686 if (!magic)
> > 687 ci->ci_subtype = mh_xstrdup("");
> > 688 goto magic_skip;
> > 689 }
>
> You know ... I am looking
On Tue, 29 Aug 2017 15:36:57 -0400, Ken Hornstein said:
> >Also, it SEGVs without the `/plain'. Probably because get_ctinfo()'s
> >
> >685 if (*cp != '/') {
> >686 if (!magic)
> >687 ci->ci_subtype = mh_xstrdup("");
> >688 goto magic_skip;
> >689
>Also, it SEGVs without the `/plain'. Probably because get_ctinfo()'s
>
>685 if (*cp != '/') {
>686 if (!magic)
>687 ci->ci_subtype = mh_xstrdup("");
>688 goto magic_skip;
>689 }
You know ... I am looking at this now, and I cannot understand
>Well, at least it does if I'm doing comp, whatnow, mime, edit. If I run
>mhbuild(1) then it always gives quoted-printable.
>
>$ mhbuild -
>#a£d
>w£z
>MIME-Version: 1.0
>Content-Type: text/plain; charset="UTF-8"
>Content-ID: <17591.150400156...@orac.inputplus.co.uk>
>
Hi Ken,
> AFAIK, it's only in our interactions with network protocols like SMTP
> and POP3 that we see CRs because that's the definition.
Right, good.
> text/* that is encoded as base64 should technically include a CRLF. I
> BELIEVE I added the code that will convert that Unix line endings upon
Hi,
David wrote:
> Ken wrote:
> > Are you recoiling in horror, or think it's a good idea? I can't
> > tell :-)
>
> :-) I think it's a good idea. m_getfld() and its clients are
> difficult to maintain and expand.
It's not so much m_getfld()'s maintenance as getting it working. :-)
I've a reall
>> only people who build the distribution and work on git trees need those
>> tools.
>
>Right, but I want to minimize impediments to those people.
Fair enough; so, if you're the kind of person who builds from a git tree
(NOT a distribution tar file or a packaging system), is requiring bison
and f
Ken wrote:
> Are you recoiling in horror, or think it's a good idea? I can't tell :-)
:-) I think it's a good idea. m_getfld() and its clients are difficult
to maintain and expand.
> >Deciding on a common denominator for yacc/bison, and also lex/flex, could
> >be a challenge. I'd be OK with
>> Some people have been recoiling in horror at my attempts to write an
>> RFC-822 address parser in Yacc/Bison.
>
>+1
Are you recoiling in horror, or think it's a good idea? I can't tell :-)
>Deciding on a common denominator for yacc/bison, and also lex/flex, could
>be a challenge. I'd be OK w
Ken wrote:
> Some people have been recoiling in horror at my attempts to write an
> RFC-822 address parser in Yacc/Bison.
+1
Deciding on a common denominator for yacc/bison, and also lex/flex, could
be a challenge. I'd be OK with just supporting flex and bison.
David
_
>I agree RFC 5322 lines are CRLF, but RFC 4155's application/mbox are
>just LF, and Unix mbox files from Postfix, etc., are just LF. I don't
>think the code should allow /\r?\n/ for all inputs, but I don't think
>you're saying it does?
AFAIK, it doesn't.
>Is retrieving POP3 emails the only time
Hi Ken,
> > I've reproduced similar symptoms with an mhbuild-produced email
> > where I tacked on CR to the end of every line after the blank line
> > after the headers. IOW, without the headers having CR. However, I
> > still think this is an invalid format email; why should we handle
> > CR a
>I've reproduced similar symptoms with an mhbuild-produced email where I
>tacked on CR to the end of every line after the blank line after the
>headers. IOW, without the headers having CR. However, I still think
>this is an invalid format email; why should we handle CR at any
>location?
Sigh.
Hi David,
> Any objection to removing "nmh" from before "messages" from at least
> some of these?
...
> Does anyone have time to go through the others?
Doing it now.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Nmh-workers mailing lis
Ralph wrote:
> Hi Paul,
>
> > isn't that sort of the point of mhfixmsg? to fix poorly or illegally
> > formatted email?
>
> Good point, but I think it uses the stock nmh code for parsing emails
> rather than have it own code that is cluttered with wart handling.
Yes. mhparse works quite nicely
Hi Paul,
> isn't that sort of the point of mhfixmsg? to fix poorly or illegally
> formatted email?
Good point, but I think it uses the stock nmh code for parsing emails
rather than have it own code that is cluttered with wart handling.
That's why there's suppress_extraneous_trailing_semicolon_wa
ralph wrote:
> Hi Ken,
>
> > Huh, the HEADERS have ^M on them?
>
> I've reproduced similar symptoms with an mhbuild-produced email where I
> tacked on CR to the end of every line after the blank line after the
> headers. IOW, without the headers having CR. However, I still think
> this
Hi Ken,
> Huh, the HEADERS have ^M on them?
I've reproduced similar symptoms with an mhbuild-produced email where I
tacked on CR to the end of every line after the blank line after the
headers. IOW, without the headers having CR. However, I still think
this is an invalid format email; why shou
Hi Håkon,
> Trying by hand gives:
> $ unlzma ./test/testdir/tmp/11.tar
> ./test/testdir/tmp/11.tar: unknown suffix -- unchanged
...
> My lzma command comes from debian package lzma-9.22-2.
I've pushed this to the master branch and cherry-picked it to
1.7-release.
commit 937ee92013bed7b3ebd
>Confirmed, they all have ^M. Note that I'm probably abusing mhfixmsg, as
>I am trying to run it on my server at reception time, before storing the
>mail in IMAP. I'll just keep it to my own account for now, removing \r
>before and adding \r after processing. :/
Ah, okay, THAT makes more sense. I
Den 18. aug. 2017 19:19, skrev Ken Hornstein:
>>> 1) What is happening to that email when you run mhfixmsg on it?
>>
>> The mail in question (i.e. with ^M at end of every line, both headers
>> and body) ends up with nothing but a single instance of the mime
>> boundary in the body of the mail. i.
Hi Ken,
> Huh, the HEADERS have ^M on them?
I've tried slapping CR at various places on the email that was
originally attached and can't get mhfixmsg to go wrong. The original
that has the problem would be handy to find the issue and come up with a
minimum test case if it is a nmh bug. And it p
>> 1) What is happening to that email when you run mhfixmsg on it?
>
>The mail in question (i.e. with ^M at end of every line, both headers
>and body) ends up with nothing but a single instance of the mime
>boundary in the body of the mail. i.e
>
>HEAD
>
>MIME-BOUNDARY
Huh, the HEADERS have ^M
Den 18. aug. 2017 17:53, skrev Ken Hornstein:
> You know, I've only been vaguely following this, but I tried to go back
> and I am confused now. Two dumb questions:
>
> 1) What is happening to that email when you run mhfixmsg on it?
The mail in question (i.e. with ^M at end of every line, both
You know, I've only been vaguely following this, but I tried to go back
and I am confused now. Two dumb questions:
1) What is happening to that email when you run mhfixmsg on it?
2) What do you want to happen?
--Ken
___
Nmh-workers mailing list
Nmh-wo
Hi Håkon,
> Which is smaller. Update: You pointed out the carriage returns. Can
> you send the problem email as a .tar.gz or something that will leave
> everything alone.
It would still be useful to have that to reproduce the mhfixmsg problem
here.
> > > 11.tar: unknown suffix -- unchanged
>
Den 18. aug. 2017 16:11, skrev Ralph Corderoy:
> Hi Håkon,
>
>> $ mhlist -version
>> mhlist -- nmh-1.7-RC2 built 2017-08-18 11:32:04 + on garbo
>> $ mhlist 1
>> mhlist: bogus multipart content in message 1
>> msg part type/subtype size description
>>1 multipart/mixed
Den 18. aug. 2017 15:45, skrev David Levine:
> Does the -nocrlflinebreaks switch to mhfixmsg help?
>
No difference, already tried both -nocrlflinebreaks and -crlflinebreaks
> David
>
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.
Hi Håkon,
> $ mhlist -version
> mhlist -- nmh-1.7-RC2 built 2017-08-18 11:32:04 + on garbo
> $ mhlist 1
> mhlist: bogus multipart content in message 1
> msg part type/subtype size description
>1 multipart/mixed32K
And yet I got
> > $ mhlist -file 9707
Does the -nocrlflinebreaks switch to mhfixmsg help?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Den 18. aug. 2017 13:49, skrev Håkon Alstadheim:
>
>
> Den 18. aug. 2017 13:04, skrev Ralph Corderoy:
>>
>>
>> Hi Håkon,
>>
>>> Trying to run mhfixmsg on it just removes the entire body of the mail.
>>
>> Can you give a command that fails? It seems OK here.
> I'm running debian jessie which has
Den 18. aug. 2017 13:04, skrev Ralph Corderoy:
>
>
> Hi Håkon,
>
>> Trying to run mhfixmsg on it just removes the entire body of the mail.
>
> Can you give a command that fails? It seems OK here.
I'm running debian jessie which has 1.6 as package. Compiled but not
installed 1.7 from source.
Hi Håkon,
> Trying to run mhfixmsg on it just removes the entire body of the mail.
Can you give a command that fails? It seems OK here.
$ mhfixmsg -version
mhfixmsg -- nmh-1.7-RC2 1.7-RC2-1-g42b75672 built 2017-08-18 06:44:22 +
on orac
$ scan -file 9707.2.email -format '%{messa
Hi all, I'd really like to keep base64 to a bare minimum in my
mail-store, but then along comes monstrosities like the attached. Trying
to run mhfixmsg on it just removes the entire body of the mail.
I just tried running the nmh-1.7-RC2 version, but result is same.
I'm not holding my breath, but
Hi,
Corporations are increasing slapping needless, bloated, branding images
onto their emails, ones I want to keep. I've a crude `shrinkimg' script
that replaces the image's data with a tiny one whilst keeping the type,
e.g. PNG, so any internal references to it are still valid. I was
thinking m
>and mhfixmsg just went nuts when it hit that \0. The exact failure mode
>depends on how far into the bodypart the \0 is - sometimes the message
>body goes bye-bye, other times the a chunk of text disappears and the
>next line is adjoined to the front half of the previous line.
As a general note .
Valdis wrote:
> This is probably going to be a *total* joy to debug.
I'm hoping that I fixed this on Oct 21. Please tell me that
your code is from before then. The weak link was in nmh's MIME
parser, and needed help from m_getfld() for the fix.
> I admit being totally unclear as to where the \
Hi Valdis,
> 040 t a n n o u n c e d h e b \0
>20746e616f6e6e756563206465680062
> 060 031 s n o m i n a t i n g S e
>73196e206d6f6e6974616e692067
Just when you think that in a third of a century of doing e-mail
you've seen every possible way to screw things up, new ways get invented.
So I have this in my .procmailrc:
TMPFILE=`mktemp -p /home/valdis/tmp fixmsg.XX`
# Canonify to 8-bit UTF-8
:0 wf
*!^Content-type:.*multipart/signed
|
On Thu, 17 Mar 2016 11:38:01 -0400, David Levine said:
> 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 c
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
__
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
___
So trying to debug why a message got eaten by procmail. Fortunately,
I've been keeping copies because I didn't trust my use of mhfixmsg yet.
grep fix ~/.,mh_profilecomes up empty, no hits. $LANG=en_US.UTF-8
Running a git pull from March 9, HEAD was:
commit 8ff517b106543e9f8fe77ed152491a84e6
I added a new switch to mhfixmsg(1):
[-fixtype mimetype]
The -fixtype switch ensures that each part of the message
has the correct MIME type shown in its Content-Type header.
It may be repeated. It is typically used to replace
“application/octet-stream” with a more descriptiv
Paul F. wrote:
> there's another wrinkle, as well: mhfixmsg leaves cur set to the last
> message processed, which means cur is no longer what it was when inc
> was finished. so cur needs to be saved and restored, as well.
-[no]changecur? inc and mhlist have it.
David
ralph wrote:
> Hi David,
>
> > > > Alternatively, something like this (completely untested)?
> > > >
> > > > msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && mhfixmsg $msgs
> > >
> > > but then i'd lose the default output of inc.
> >
> > msgs=`inc -format '%(msg)'` && [ -n "$msgs
Hi David,
> > > Alternatively, something like this (completely untested)?
> > >
> > > msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && mhfixmsg $msgs
> >
> > but then i'd lose the default output of inc.
>
> msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && scan $msgs && mhfixmsg $msgs
Sti
Paul F. wrote:
> david wrote:
> > Alternatively, something like this (completely untested)?
> >
> > msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && mhfixmsg $msgs
>
> but then i'd lose the default output of inc.
msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && scan $msgs && mhf
david wrote:
> Paul F. wrote:
>
> > i'm having a bit of trouble understanding how to integrate mhfixmsg
> > into my workflow.
> >
> > i'd like to automatically run mhfixmsg on all mail, and, therefore,
> > keep a backup of messages that it processes. since i kind of abhor
> > the ,nnn sty
Paul F. wrote:
> i'm having a bit of trouble understanding how to integrate mhfixmsg
> into my workflow.
>
> i'd like to automatically run mhfixmsg on all mail, and, therefore,
> keep a backup of messages that it processes. since i kind of abhor
> the ,nnn style of mh backups, i'd like to keep th
i'm having a bit of trouble understanding how to integrate mhfixmsg
into my workflow.
i'd like to automatically run mhfixmsg on all mail, and, therefore,
keep a backup of messages that it processes. since i kind of abhor
the ,nnn style of mh backups, i'd like to keep the mhfixmsg backups in
a sep
I wrote:
> It turns out that the failure was not due to long lines, but to
> non-ASCII characters in what was supposed to be an ASCII html page.
Removing the -textcharset switch will allow the text/plain
part insertion to succeed.
David
___
Nmh-worker
Jerrad wrote:
> It recreates text/plain alternative parts for me, and sometimes
> creates new ones, but it fails to create them for HTML parts
> with long lines, as Ken recapped above.
It turns out that the failure was not due to long lines, but to
non-ASCII characters in what was supposed to be
Jerrad wrote:
> I've not had a chance to dig through the code yet, but it
> just occurred to me hat it doesn't really matter whether
> or not nmh would like lines greater than 998 characters.
It does matter because the output from mhfixmsg can be a
message in an MH folder. (You could use mhstore
>>However I will note that the mhfixmsg man page does not indicate that
>>it uses the mhfixmsg profile parameter, which is why I asked...
>
>Do any of the other commands say that they do? A quick check suggests
>that they don't.
No, I don't suppose they do. mh-profile(5) covers this case, but it
s
>However I will note that the mhfixmsg man page does not indicate that
>it uses the mhfixmsg profile parameter, which is why I asked...
Do any of the other commands say that they do? A quick check suggests
that they don't.
--Ken
___
Nmh-workers mailin
However I will note that the mhfixmsg man page does not indicate that
it uses the mhfixmsg profile parameter, which is why I asked...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>I have a vague memory that you just copied over some version of mhfixmsg
>from a while ago, so I don't know how old it is ... but from a tree compiled
>right now:
That was prior to my foray into MIME-hooks when I updated to a pull from git
on 2/24. I have been running both for a month now without
>What are the chances of getting mhfixmsg to heed a mhfixmsg:
>parameter from .mh_profile into 1.6? It seems like it should
>do that, but I have several switches set including -replacetextplain,
>and the seem to be being ignored :-/
I have a vague memory that you just copied over some version of m
What are the chances of getting mhfixmsg to heed a mhfixmsg:
parameter from .mh_profile into 1.6? It seems like it should
do that, but I have several switches set including -replacetextplain,
and the seem to be being ignored :-/
___
Nmh-workers mailing l
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 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
>It's bullshit like that that led Vern Schryver to state that the MIME
>multipart/alternative was usually a crock. Either the /text and /html are
>semantically equal, in which case one is superfluous, or they're not, in
>which case one is incorrect and shouldn't be sent.
I don't disagree with tha
On Sun, 11 Aug 2013 10:42:33 -0400, belg4...@pthbb.org said:
> 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
Ralph Corderoy writes:
>Hi David,
>
>> Or is there a more general solution that keeps things simple?
>
>Completely off the top of my head, and having just got in after a touch
>too much sun, how about "exploding" the email to a directory structure,
>with details of encodings, etc., as part of the
Hi David,
> Or is there a more general solution that keeps things simple?
Completely off the top of my head, and having just got in after a touch
too much sun, how about "exploding" the email to a directory structure,
with details of encodings, etc., as part of the filenames. I can then
delete p
>My only idea so far has been to add a -remove
>switch, which would apply before the other transformations
>that mhfixmsg does. It would then add a text/plain that
>corresponds to the text/html, as it does now. Mark, I think
>that would solve your problem, too?
>
>Or is there a more general solu
> >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
>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
>informat
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
information un
77 matches
Mail list logo
