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
Hi,
exit(3) values are zero for success, non-zero for failure. The value is
eight bits wide but shells map signals onto [0x80, 0xff] so exit(128 +
14) would be ambiguous to the parent.
$ sh -c 'kill -14 $$'
Alarm clock
$ echo $? $(($? - 0x80))
142 14
Shells also nab the top few
>mhparam(1) deviates.
>
>EXIT STATUS
>mhparam returns the number of components that were not found,
>but limits the return value to 120 to avoid ambiguity, e.g. 127
>is used by shells to indicate ‘command not found', and 256 would
>wrap to 0, falsely indicating s
>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
Is there some reason why I shouldn't always give mhstore a -check argument,
other than perhaps not wanting to possibly waste machine cycles?
Norman Shapiro
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo
>Is there some reason why I shouldn't always give mhstore a -check argument,
>other than perhaps not wanting to possibly waste machine cycles?
I think you will find that almost no MUA other than nmh will generate a
Content-MD5 header. And nowadays nmh won't do that unless you specifically
tell it
Hi Ken,
> And nowadays nmh won't do that unless you specifically tell it to (via
> the -check switch to mhbuild).
I do that. :-) mhlist(1) and others also have -check. mh-chart(7)
lists the -check options, and some of them have the same meaning as
mhstore's and mhlist's.
> because of how easy
>> because of how easy it is to create a matching MD5 hash for arbitrary
>> content).
>
>I figure it helps spot buggy corruption by something that handled the
>bytes along the way, and I need all the help.
I have to ask ... does that actually HAPPEN? Like, ever? Also, your
message you sent out d
