Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Michael Richardson]

Anthony J. Bentley  wrote:
> Michael Richardson writes:
>> And given EFAIL, it seems that we were wise.

> nmh wise? I dunno. Part of EFAIL was that the mail client downloaded
> bits from the Internet and interleaved them seamlessly into the
> message.

No, that downloading from the Internet was entirely a normal thing.
It's that the MUAs failed to run the HTML bits in seperate sandboxes.
(Or that they ran the HTML bits at all)

> That seems like an inherently dangerous thing to do... and nmh does it
> with one of the messages in this very thread: Ralph Corderoy's message
> contains a 'Content-Type: message/external-body; access-type="url";
> url="..."' bit that was promptly fetched and displayed in the middle of
> the message. How do I disable this behavior, and why does nmh have it
> turned ON by default!?

I don't remember how to turn it off; I don't think it is on by default.
Did you build from source, or from a package?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ralph wrote:

> This seems to work here.
>
> nmh-access-url: printf '\e[31;1mexternal-body: %q\n'

Perfect, thanks!

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Bob Carragher]

I'm definitely in favor of, by default, disabling anything that
causes automatic external data fetches to sites I might be
unaware of!

Bob

On Sun, 27 May 2018 10:15:29 -0400 Ken Hornstein  sez:

> >> I don't know.  History, probably.
> >> We used to assume everyone played nice.
> >
> >nmh-access-{ftp,url} were added less than 4 years ago.  Ken,
> >should we revisit?  I don't have strong feelings, the only
> >messages I've received that use it are from you and Ralph.
> 
> So, I read Anthony's email, and while I don't agree with all of
> his concerns I do understand where he is coming from.
>
> My reading of the historical MH code is that it would always
> try to fetch external-body content.  But ... the assumption in
> MH 6.8 was that MIME content was rare and presumably a human
> would look at it before they would run "mhn".  The
> external-body methods supported in MH 6.8 were "afs",
> "anon-ftp", "ftp", "local-file", and "mail-server".  I think
> "ftp", "anon-ftp", and "mail-server" probably were at a similar
> level of danger to "url" today.
>
> Thinking about the history ... along the way we moved towards
> always parsing MIME messages (because most messages nowadays
> are), which meant that external-body content would always be
> displayed (BTW, "turns out "mhn-access-ftp" was supported even
> back in MH 6.8).  I added the URL support and my motivation
> there was really just updating the MIME support to more modern
> stuff, I went along with how the ftp support worked and didn't
> think about the larger concerns.
>
> I think maybe the smartest thing to do would be to default to
> NOT displaying any external content in nmh when viewing content
> with show(1)/mhshow(1), but instead just show the MIME
> paramters to the user.  Then a user could chose to display that
> with -showexternal (or whatever).  A more trusting user could
> add -showexternal to their profile.  That might have to wait a
> while, though.  Thoughts?
> 
> --Ken
> 
> -- 
> nmh-workers
> https://lists.nongnu.org/mailman/listinfo/nmh-workers

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>> I don't know.  History, probably.
>> We used to assume everyone played nice.
>
>nmh-access-{ftp,url} were added less than 4 years ago.  Ken, should we
>revisit?  I don't have strong feelings, the only messages I've received
>that use it are from you and Ralph.

So, I read Anthony's email, and while I don't agree with all of his concerns
I do understand where he is coming from.

My reading of the historical MH code is that it would always try to fetch
external-body content.  But ... the assumption in MH 6.8 was that MIME
content was rare and presumably a human would look at it before they
would run "mhn".  The external-body methods supported in MH 6.8 were
"afs", "anon-ftp", "ftp", "local-file", and "mail-server".  I think "ftp",
"anon-ftp", and "mail-server" probably were at a similar level of danger
to "url" today.

Thinking about the history ... along the way we moved towards always
parsing MIME messages (because most messages nowadays are), which meant
that external-body content would always be displayed (BTW, "turns out
"mhn-access-ftp" was supported even back in MH 6.8).  I added the URL
support and my motivation there was really just updating the MIME
support to more modern stuff, I went along with how the ftp support
worked and didn't think about the larger concerns.

I think maybe the smartest thing to do would be to default to NOT
displaying any external content in nmh when viewing content with
show(1)/mhshow(1), but instead just show the MIME paramters to the
user.  Then a user could chose to display that with -showexternal (or
whatever).  A more trusting user could add -showexternal to their
profile.  That might have to wait a while, though.  Thoughts?

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi David,

> Alright, the user could call a script to sanitize the URL.
> Or not display it, such as by prepending with /bin/true.

This seems to work here.

nmh-access-url: printf '\e[31;1mexternal-body: %q\n'

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ralph wrote:

> Content-Type: message/external-body; access-type="url";
>   url="http://^[[39;1mexample^[[0m.org/^[[8;24;40t;

Alright, the user could call a script to sanitize the URL.
Or not display it, such as by prepending with /bin/true.

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi David,

> nmh-access-url: echo ^[[31\;1mSuppressed loading of

Thanks.




-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Anthony,

> - It leaks the IP address of my mail client simply by reading an
> email.

IIRC that was the motivation for me trying it;  how many distinct IP
addresses hit the URL.  Related to your point, I could know the
recipient viewed the email three times a couple of days ago, once from
somewhere he denies going, the rake, yet still hasn't replied.

> - Curl's user agent contains a version number (could allow OS
>   identification, or targeting of vulnerable curl versions).

curl(1) has `-A' to set the user agent.  Perhaps mhn-defaults should
plonk nmh in there with an escape for a version?  Your point still
applies.

curl also offers cookie jars though I don't know if they're used by
default with mhn.default's simple invocation, but perhaps the `.curlrc'
loaded by default as we don't give `-q' might.  This means the URL can
benefit from their values.

> - Fetching http content is subject to man-in-the-middle attacks.

Third-party services like httpbin.org offer URLs that delay before
serving, slowing down mail viewing.

Small emails that get under fetchmail's `-l' limit may still cause high
usage of network budget.

> - It can be used to poke intranets (http://192.168.x.y/admin.php?...)

Yes, though any output would be seen.  GETing Internet URLs may also
have a side effect.  `Vote for me!'.

This telnet-schema URL doesn't work because curl's stdin isn't
/dev/null, but the TTY.  And the dict-schema one can't use `DEFINE
jargon recursion' as the path because nmh strips whitespace from `url',
the comment referring to RFC 2017.







curl(1) supports quite a few other schemas, though libcurl is compiled
without some of them here.  SFTP supports lots of file manipulation
commands, but again the whitespace removal is a hindrance.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Anthony J. Bentley]

Ken Hornstein writes:
> Respectfully ... the vulnerability with EFAIL was NOT that people downloaded
> stuff via HTTP.

I suppose I shouldn't say that *was* the vulnerability; but if mail
clients didn't fetch URLs embedded in the mail by default, EFAIL would
not have been possible.

> To the larger point ... I do not think there is any fundamental
> difference between being emailed a text/plain part and fetching it via
> HTTP; they both are coming across the wild Internet, and I think this
> applies to any content.  The only possible disadvantage I can think of

Here are a few more:

- It leaks the IP address of my mail client simply by reading an email.
  (Sending email leaks the IP of my SMTP client, which I'm not keen
   on either, but I already expect *sending* email to be leaky.)
- Curl's user agent contains a version number (could allow OS
  identification, or targeting of vulnerable curl versions).
- Fetching http content is subject to man-in-the-middle attacks.
- It can be used to poke intranets (http://192.168.x.y/admin.php?...)

I don't think a niche feature with these disadvantages is a desirable
default. Other mail clients like GMail block images for similar reasons.

-- 
Anthony J. Bentley

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>Michael Richardson writes:
>> And given EFAIL, it seems that we were wise.
>
>nmh wise? I dunno. Part of EFAIL was that the mail client downloaded
>bits from the Internet and interleaved them seamlessly into the message.
>That seems like an inherently dangerous thing to do... and nmh does it
>with one of the messages in this very thread: Ralph Corderoy's message
>contains a 'Content-Type: message/external-body; access-type="url";
>url="..."' bit that was promptly fetched and displayed in the middle of
>the message. How do I disable this behavior, and why does nmh have it
>turned ON by default!?

Respectfully ... the vulnerability with EFAIL was NOT that people downloaded
stuff via HTTP.  Kind of the exact opposite, actually ... MUAs were given
a previously-encrypted message and tricked into decrypting it and uploading
it by stitching together HTML content across multiple MIME parts.  E.g.:

--BOUNDARY
Content-Type: text/html

http://efail.de/
--BOUNDARY
Content-Type: application/pkcs7-mime; [...]
Content-Transfer-Encoding: bae64

[... message attacker wants to decrypt ...]
--BOUNDARY
">
--BOUNDARY--

A poorly-written MUA would decrypt the message and then "fetch" the
image because they would interpret all of the HTML parts as one
continuous HTML content (notice the opening quote in the first HTML
part does not contain a closing quote), and the URL would contain the
decrypted text the attacker is interested in (presumably they got that
via some other mechanism).  And it turns out there are a lot of poorly-
written MUAs!

I looked at this when it came out; I do not believe that even if we
supported S/MIME or OpenPGP natively we would be vulnerable to EFAIL,
because we pass each HTML part to it's own HTML converter, so there is
no HTML "state" that would be preserved across multipart boundaries.
And even if it was an issue, they default HTML-to-text converters
we use do not fetch images.

To the larger point ... I do not think there is any fundamental
difference between being emailed a text/plain part and fetching it via
HTTP; they both are coming across the wild Internet, and I think this
applies to any content.  The only possible disadvantage I can think of
is that it would evade a virus checker than runs on your mail server,
but since relatively few MUAs support message/external-body messages now
I suspect it's highly unlikely that anyone would choose to distribute a
virus in this way.  I am open to being proven wrong, of course.

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ralph wrote:

> Hi Anthony,

> > How do I disable this behavior
>
> Possibly by nobbling nmh-access-url in an mhn.defaults, e.g. /etc/nmh,

Or, add these to your profile:

nmh-access-ftp: echo ^[[31\;1mSuppressed loading of
nmh-access-url: echo ^[[31\;1mSuppressed loading of

The ANSI control sequences aren't necessary, they just red bold the
output.  The ^[ pair must be replaced by ASCII ESC.

> > and why does nmh have it turned ON by default!?
>
> I don't know.  History, probably.
> We used to assume everyone played nice.

nmh-access-{ftp,url} were added less than 4 years ago.  Ken, should we
revisit?  I don't have strong feelings, the only messages I've received
that use it are from you and Ralph.

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Anthony,

> Part of EFAIL was that the mail client downloaded bits from the
> Internet and interleaved them seamlessly into the message.

IIRC it was that different adjacent parts were catenated if both
text/html before being sent to something to interpret the HTML.  This
meant the join could produce something unwanted that wasn't detected
when they were separate.

> Ralph Corderoy's message contains a 'Content-Type:
> message/external-body; access-type="url"; url="..."' bit that was
> promptly fetched and displayed in the middle of the message.

About time someone's noticed.  :-)  It's not the first time, though it's
not common.  This time it seemed apt given my pondering about too much
done `out of the box'.

> How do I disable this behavior

Possibly by nobbling nmh-access-url in an mhn.defaults, e.g. /etc/nmh,
though I haven't tested it.  It's `curl -L' here, that should probably
have an `-sS' too.

> and why does nmh have it turned ON by default!?

I don't know.  History, probably.
We used to assume everyone played nice.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Anthony J. Bentley]

Michael Richardson writes:
> And given EFAIL, it seems that we were wise.

nmh wise? I dunno. Part of EFAIL was that the mail client downloaded
bits from the Internet and interleaved them seamlessly into the message.
That seems like an inherently dangerous thing to do... and nmh does it
with one of the messages in this very thread: Ralph Corderoy's message
contains a 'Content-Type: message/external-body; access-type="url";
url="..."' bit that was promptly fetched and displayed in the middle of
the message. How do I disable this behavior, and why does nmh have it
turned ON by default!?

-- 
Anthony J. Bentley

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi,

Michael Richards, message ID <2726.1527268876@localhost>:
  ~
> And given EFAIL, it seems that we were wise.

Or not?  I've been surprised by the odd bit of decoding nmh has done for
MIME parts, giving a text summary of the content.  I suspect the
programs used, e.g. netpbm, have bugs to do with their decoding, just as
they definitely have bugs elsewhere, and they've not been pored over for
flaws as more https://www.coreinfrastructure.org/ has done, e.g.
Google's fuzzing.

I can see why it's handy for the new nmh user to have as much MIME
content handled as possible `out of the box', and /etc/nmh/mhn.defaults
has a lot of definitions on most systems, but I think I'd like starting
with zero and then adding them as required, after consideration.  This
might be as simple as uncommenting an entry supplied with nmh.



-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Bob Carragher]

On Fri, 25 May 2018 20:39:26 -0400 Ken Hornstein  sez:

> >Count  me as  another one  of  those few  people who  actually uses  the
> >text/plain content. :-) For the most  part, I don't read emails that are
> >HTML only  unless I  absolutely have  to and if  there's a  text/plain I
> >manage with that unless it's terrible.
> 
> My original draft of that email said "you're probably the only person
> who uses the the text/plain content", but then I remembered what mailing
> list I am on :-)

Guilty as charged.  ^_^;;;

> My larger point is that, sadly, I've seen a distressing number of times
> when the text/plain version of a multipart/alternative message is not
> useful.  I really wish people who have a shitty text/plain part would
> simply NOT bother and just generate text/html; I don't know why they
> even bother to generate such a lousy text/plain part, but this is the
> world we live in.  I suspect we (nmh users) might be the only users who
> actually look at the text/plain content versus the text/html content.

It's almost certainly the case that the percentage of people that
see the crap-HTML is tiny.  Otherwise outfits like Yahoo! would
be overwhelmed with complaints.  B-[

Bob

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ken wrote:

> I don't know why they
> even bother to generate such a lousy text/plain part, but this is the
> world we live in.

One airline based in America sends empty (just the newline)
text/plain parts in their purchase confirmation messages:

$ mhlist -noheader
  65   multipart/alternative 143K
 1 text/html 143K
 2 text/plain   1
$ mhshow -prefer text/plain -form mhl.null -noheader
[ part 1 - text/plain -   1B  ]

This in spite of my reports going back over 5 years.

> I suspect we (nmh users) might be the only users who
> actually look at the text/plain content versus the text/html content.

In case anyone wants to give mhfixmsg -replacetextplain a quick,
nondestructive try on an errant message that does have a text/html
part (12.3KB output not shown here):

$ mhfixmsg -replacetextplain -out - -noverbose | \
  mhshow -prefer text/plain -form mhl.null -noheader -file -
[ part 1 - text/plain -   12.3KB  ]

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Jón,

> Ken writes:
> > I've seen a distressing number of times when the text/plain version
> > of a multipart/alternative message is not useful.

Yesterday's fun was working out why a `reset your password' URL didn't
work.  Fill in the web page, submit, `Please correct the highlighted
errors', but no highlights present, just the form to fill in, again.

The email had the same URL twice, once in the text/plain, again in the
text/html.  It ended in `..'.  There were no other `.' in the URL's
path.  They were part of the URL.  Terminals tend to assume they're
trailing punctuation and drop them from the opened URL.  The site didn't
care on presenting the form, only on its submission, but had a buggy
error message.  I've suggested they append `#'.
https://example.com/foo..#

> I have even seen a text/plain part of an event announcement that was
> for the previous event! The mind boggles as to what kind of software
> could cause that to happen.

I subscribe to a weekly paper magazine.  The accompanying summary email
was the same two weeks in a row.  More precisely, the text/plain was
identical, the text/html correctly differed.  They must have to prepare
and paste both separately rather than have software produce one from the
other.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Tom,

> > sed 's/$/\n/' "$@" |
>
> Another idiom is: sed -eG.

Oh yes, that's better.

> > fmt -su |
>
> Interesting switches for fmt.

Well, I thought you could play around with what you prefer.
It's GNU fmt, which has annoying behaviour.  Bring back _Software Tools_!

$ yes foo | fmt -60 | uniq -c | sed 3q
 67 foo foo foo foo foo foo foo foo foo foo foo foo foo foo
  3 foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
 67 foo foo foo foo foo foo foo foo foo foo foo foo foo foo
$ 

The `-u' doesn't turn `foo. Bar' into two spaces, just shortens multiple
spaces to one or two, unfortunately.  On the other hand, `e.g.  gripper'
would then need fixing up.

$ fmt -u
Apple   banana  cherry.Doughnut  eclair.
^D
Apple banana cherry.  Doughnut eclair.
$ 

I've ~/bin/owpl, one word per line, and fmt does know to use two spaces
when joining lines of different sentences.

$ owpl | fmt
Distinct. Lack. Of. Spaces.
^D
Distinct.  Lack.  Of.  Spaces.
$ 

> > cat -s

This can be sed too, and it irks to be using an option to cat(1)  :-)
But I go for ease over recall.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Jon Fairbairn]

Ken Hornstein  writes:

> My larger point is that, sadly, I've seen a distressing number of times
> when the text/plain version of a multipart/alternative message is not
> useful.  I really wish people who have a shitty text/plain part would
> simply NOT bother and just generate text/html; I don't know why they
> even bother to generate such a lousy text/plain part, but this is the
> world we live in.  I suspect we (nmh users) might be the only users who
> actually look at the text/plain content versus the text/html content.

Sadly true.  I have even seen a text/plain part of an event
announcement that was for the previous event! The mind boggles
as to what kind of software could cause that to happen.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk



-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>Count  me as  another one  of  those few  people who  actually uses  the
>text/plain content. :-) For the most  part, I don't read emails that are
>HTML only  unless I  absolutely have  to and if  there's a  text/plain I
>manage with that unless it's terrible.

My original draft of that email said "you're probably the only person
who uses the the text/plain content", but then I remembered what mailing
list I am on :-)

My larger point is that, sadly, I've seen a distressing number of times
when the text/plain version of a multipart/alternative message is not
useful.  I really wish people who have a shitty text/plain part would
simply NOT bother and just generate text/html; I don't know why they
even bother to generate such a lousy text/plain part, but this is the
world we live in.  I suspect we (nmh users) might be the only users who
actually look at the text/plain content versus the text/html content.

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[nmh]

Hi Ralph:

I appreciate your examples below, my comments about them are to show, I'm more 
or less
following them.  I'll probably use ideas from them in future bash functions.  

On Thu 5/24/18 14:56 +0100 Ralph Corderoy wrote:
> > For the yahoo email client, no word wrapping is added to the received
> > email, ie. there are no '\n's within the received paragraph (unlike
> > gmail). Most importantly, for the yahoo client, each paragraph in the
> > body of the original has to end in '\n\n\n' in order for there to be a
> > single empty '\n' in between paragraphs in the received email. In the
> > yahoo email client the email looks just fine visually with only '\n\n'
> > as and ending to paragraphs, but then the received email does *not*
> > end up having an empty line between paragraphs.
> 
> This looks like
> https://forums.yahoo.net/t5/Features-and-settings/Line-spacing-issues-in-composing-email/td-p/79841/page/2

So the plain text part of yahoo email is munged due to their bug apparently.

> I did get mhl(1) that's run by show(1) to use fmt(1).
> Perhaps you can do that selectively on troublesome emails since repl(1) will 
> use mhl too.
> 
> $ cat mh-profile
> Path: mail
> context: context
> $
> $ cat fmtspc
> #! /bin/sh
> 
> sed 's/$/\n/' "$@" |

Converts to double space
Another idiom is: sed -eG.

> fmt -su |

Interesting switches for fmt.

> cat -s

Squeeze multiple empty lines to single empty line

> $
> $ MH=mh-profile show -form <(echo body:nocomponent,format) \
> > -fmtproc $PWD/fmtspc 42

Interesting syntax, a simple 1 line form.

> conveyances Hood's palatable economically NP Arabist's railroader's
> Nair's influxes complexion recolonize speak prickliness loadstones
> relaunch's treachery's slowdown's bosh's Deccan countermoves arranger's
> vacuousness's wisteria's mesquite's hocked Petra's necrophilia LAST
> 
> iPod's Poe's neurotic's imploded lance stepladder malignancies Poole
> monogamy's jeopardized immaculateness schoolwork's optometry's
> readability's Kayla buckshot's pickax's nasal's backcloth bleep
> reformative divisibility's merrymaker's Tbilisi proof's azures
> departmentalises waived Hellenism fabrication manning adjudication
> reproducer bullied marketer clayier eschewing GIF misinterpreting Sagan
> footlights fiords Feb's azimuth dingbat's conclaves shalt Iphigenia
> sterilises kickstand's Emily dishwasher syrupy loadstar's logrolling's
> cray jehads snowball's Barlow ichthyologist Nevada nonslip prorate
> farmyard begrudges fleeced Hondurans plunderers sparely self Lou wreaked
> Iago airgun angstrom recrystallizes dipsomania's engorges Dubcek's
> Yesenia departmentalized feebleness duckweed clamp's wretchedness basked
> tachograph vivarium photocell podded Tyler's paisley eventually rubbery
> affidavit Flatt quint's entrenched Galloway overoptimism punks LAST
> 
> $

Thanks Ralph!

--Tom

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Michael Richardson]

Andy Bradford  wrote:
>> So, I don't think this is necessarily a nmh problem, like I said. From
>> a  practical standpoint,  you're probably  one of  the few  people who
>> actually USES the text/plain content instead of the text/html content.

> Count  me as  another one  of  those few  people who  actually uses  the
> text/plain content. :-) For the most  part, I don't read emails that are
> HTML only  unless I  absolutely have  to and if  there's a  text/plain I
> manage with that unless it's terrible.

I also am like this.
And given EFAIL, it seems that we were wise.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Andy,

> > you're probably one of the few people who actually USES the
> > text/plain
>
> Count me as another one of those few people

#MeToo.  Given mhshow(1)'s -prefer, it's quite easy.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Andy Bradford]

Thus said Ken Hornstein on Thu, 24 May 2018 19:28:25 -0400:

> So, I don't think this is necessarily a nmh problem, like I said. From
> a  practical standpoint,  you're probably  one of  the few  people who
> actually USES the text/plain content instead of the text/html content.

Count  me as  another one  of  those few  people who  actually uses  the
text/plain content. :-) For the most  part, I don't read emails that are
HTML only  unless I  absolutely have  to and if  there's a  text/plain I
manage with that unless it's terrible.

Andy
-- 
TAI64 timestamp: 40005b082e22



-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>> Oh, good point; I had looked at mhfixmsg but it didn't seem like that
>> would have worked (but maybe it wasn't obvious to me how to make that
>> work).
>
>mhfixmsg has a -replacetextplain switch.  But the html-to-text conversion
>is based on whatever the external converter does.  Maybe pipe it through
>Ralph's sed+fmt+cat?

Well, judging by the sample messages provided w3m worked fine on them, so
I think using an external converter would be fine.

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ken wrote:

> Oh, good point; I had looked at mhfixmsg but it didn't seem like that
> would have worked (but maybe it wasn't obvious to me how to make that
> work).

mhfixmsg has a -replacetextplain switch.  But the html-to-text conversion
is based on whatever the external converter does.  Maybe pipe it through
Ralph's sed+fmt+cat?

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>> From a practical standpoint, you're probably one of the few people who
>> actually USES the text/plain content instead of the text/html content.
>
>> So, solutions?
>
>Given your discovery the the text/html looks good, another possibility
>might be to use it via repl's -convertargs switch.  E.g., from
>docs/contrib/replaliases:
>
>  repl -filter mhl.replywithoutbody -convertargs text/html ''

Oh, good point; I had looked at mhfixmsg but it didn't seem like that
would have worked (but maybe it wasn't obvious to me how to make that
work).

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ken wrote:

> From a practical standpoint, you're probably one of the few people who
> actually USES the text/plain content instead of the text/html content.

> So, solutions?

Given your discovery the the text/html looks good, another possibility
might be to use it via repl's -convertargs switch.  E.g., from
docs/contrib/replaliases:

  repl -filter mhl.replywithoutbody -convertargs text/html ''

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Tom,

> For the yahoo email client, no word wrapping is added to the received
> email, ie. there are no '\n's within the received paragraph (unlike
> gmail). Most importantly, for the yahoo client, each paragraph in the
> body of the original has to end in '\n\n\n' in order for there to be a
> single empty '\n' in between paragraphs in the received email. In the
> yahoo email client the email looks just fine visually with only '\n\n'
> as and ending to paragraphs, but then the received email does *not*
> end up having an empty line between paragraphs.

This looks like
https://forums.yahoo.net/t5/Features-and-settings/Line-spacing-issues-in-composing-email/td-p/79841/page/2

I did get mhl(1) that's run by show(1) to use fmt(1).
Perhaps you can do that selectively on troublesome emails since repl(1) will 
use mhl too.

$ cat mh-profile
Path: mail
context: context
$
$ cat fmtspc
#! /bin/sh

sed 's/$/\n/' "$@" |
fmt -su |
cat -s
$
$ MH=mh-profile show -form <(echo body:nocomponent,format) \
> -fmtproc $PWD/fmtspc 42
conveyances Hood's palatable economically NP Arabist's railroader's
Nair's influxes complexion recolonize speak prickliness loadstones
relaunch's treachery's slowdown's bosh's Deccan countermoves arranger's
vacuousness's wisteria's mesquite's hocked Petra's necrophilia LAST

iPod's Poe's neurotic's imploded lance stepladder malignancies Poole
monogamy's jeopardized immaculateness schoolwork's optometry's
readability's Kayla buckshot's pickax's nasal's backcloth bleep
reformative divisibility's merrymaker's Tbilisi proof's azures
departmentalises waived Hellenism fabrication manning adjudication
reproducer bullied marketer clayier eschewing GIF misinterpreting Sagan
footlights fiords Feb's azimuth dingbat's conclaves shalt Iphigenia
sterilises kickstand's Emily dishwasher syrupy loadstar's logrolling's
cray jehads snowball's Barlow ichthyologist Nevada nonslip prorate
farmyard begrudges fleeced Hondurans plunderers sparely self Lou wreaked
Iago airgun angstrom recrystallizes dipsomania's engorges Dubcek's
Yesenia departmentalized feebleness duckweed clamp's wretchedness basked
tachograph vivarium photocell podded Tyler's paisley eventually rubbery
affidavit Flatt quint's entrenched Galloway overoptimism punks LAST

$

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[nmh]

On Wed 5/23/18 10:24 -0400 Ken Hornstein wrote:
> >I agree it may not be a bug; it may be something in my nmh (or other?)
> >config files. I'm running fedora 27, with sendmail/procmail/rcvstore.
> 
> So what EXACTLY is this bug you are reporting?  I think that is the
> thing I don't understand.

Attached is a number of test email sends from either gmail or yahoo
web email clients to a host with my nmh mail client.  None of these
tests involve replying. The issue is apparent in the received email
body.

If one ends a paragraph with \n\n in the sending **gmail** client,
everything is OK. The received email has lines "\n" wrapped at
about 78 columns, with empty lines between paragraphs.

For the yahoo email client, no word wrapping is added to the received
email, ie. there are no '\n's within the received paragraph (unlike
gmail). Most importantly, for the yahoo client, each paragraph in the
body of the original has to end in '\n\n\n' in order for there to be a
single empty '\n' in between paragraphs in the received email. In the
yahoo email client the email looks just fine visually with only '\n\n'
as and ending to paragraphs, but then the received email does *not*
end up having an empty line between paragraphs.

--
It may come down to educating end users on how to delimit
their paragraphs.  The yahoo email client is more likely to show the
problem.

--
Tom


longline_paragraph_tests.tar.gz
Description: longline_paragraph_tests.tar.gz
-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[David Levine]

Ken wrote:

> So what EXACTLY is this bug you are reporting?  I think that is the
> thing I don't understand.

+1

Tom, I assume you're not using repl -convertargs.  And my guess is that
your issue is on the repl side.  I don't thing there have been any
significant changes to rcvstore in the last decade or two.  You could
verify by looking at the received messages.

Based on that, the first thing I would try would be with a pared down
profile, e.g.,

$ mhparam -comp Path -comp context -comp repl >/tmp/mh_profile
$ MH=/tmp/mh_profile repl ...

David

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ken Hornstein]

>I agree it may not be a bug; it may be something in my nmh (or other?)
>config files. I'm running fedora 27, with sendmail/procmail/rcvstore.

So what EXACTLY is this bug you are reporting?  I think that is the
thing I don't understand.

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[nmh]

On Wed 5/23/18 9:23 -0400 Ken Hornstein wrote:
> >I have saved two example emails from two people I know, received after
> >my nmh 1.71 upgrade, with plain text content that have **no newlines**
> >in between paragraphs.  My understanding is these authors are lay
> >people that write paragraphs that depend on "word wrap"; ie they have
> >no newlines within paragraphs, but have one newline to separate each
> >paragraph.
> 
> I am confused ... what exactly is the bug you're reporting?  That someone
> is sending you emails with long lines?  I don't see how that's an nmh
> bug at all, unless the senders are also using nmh.

Hi Ken:

I agree it may not be a bug; it may be something in my nmh (or other?) config 
files.
I'm running fedora 27, with sendmail/procmail/rcvstore.

I asked the sender of one of the emails if they
put an empty line in between paragraphs, and they claim they always do so.

The other sender has been sending me email for a long time, and I
do not recall having this issue prior to the 1.7.1 upgrade. When
replying, I do not remember having to infer where one paragraph (in
the "> " quoted text) ends and another starts. "\n\n" to end a paragraph
visually clear, vs just a single "\n".

--
thanks,
Tom

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

[Ralph Corderoy]

Hi Tom,

> I have saved two example emails

Can we see a part of the body from the mail's file for the detail.
If it's sensitive, run it through

tr A-Za-z a <`mhpath .` | tr 0-9 0

SMTP has a line-length limit and some MTAs, e.g. Sendmail, will forcibly
split lines that are too long, inserting "!\n", so there's presumably
some encoding in place that stops that happening.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers