Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs
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
>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
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
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
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] sndmail program with parameters?
Thank you Ralph. Sorry for missing that in the docs. -- Eduardo Alvarez ealva...@fastmail.com On Sat, May 26, 2018, at 11:42 AM, Ralph Corderoy wrote: > Hi Eduardo, > > > send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc" > > > > however, send is interpreting -C as an argument to istself, rather than > > taking > > everything between quotes as the argument to -sendmail. Is this expected? > > Yes, unfortunately. mh_profile(5) says > > Shell quoting conventions are not available; each token is separated > by whitespace. > > > Is there a way to pass parameters to the sendmail program? > > No, you'd normally have a shell-script wrapper, perhaps in your > `mhpath +' directory. > > -- > Cheers, Ralph. > https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] sndmail program with parameters?
Hi Eduardo, > send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc" > > however, send is interpreting -C as an argument to istself, rather than taking > everything between quotes as the argument to -sendmail. Is this expected? Yes, unfortunately. mh_profile(5) says Shell quoting conventions are not available; each token is separated by whitespace. > Is there a way to pass parameters to the sendmail program? No, you'd normally have a shell-script wrapper, perhaps in your `mhpath +' directory. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] sndmail program with parameters?
Hello, list, I use msmtp as my sendmail program, and keep my configuration file in a nonstandard place. I tried including this in mh_profile as follows: send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc" however, send is interpreting -C as an argument to istself, rather than taking everything between quotes as the argument to -sendmail. Is this expected? Is there a way to pass parameters to the sendmail program? Kind regards, Eduardo alvarez -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs
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
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
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
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
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
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
