On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: >>> Sorry, but this is an archaic way of looking at the problem. >>> People have been doing this for decades now, has become the norm, >>> common practice, and really it is therefore WE who are being >>> inconsiderate by not accepting de facto standards that have been >>> widely adopted for a very long time. >> >> I disagree. You have made a "roads were built for cars" argument*: >> it assumes that today's "de facto standard" trumps historical >> precedent and considerate behaviour. >> >> I've nothing against people sending emails with multiple attachments. >> But expecting the recipient's MUA to parse multiple attachments into >> some kind of combined document is presumptuous, because clearly not >> everyone's MUA does this. > > There's a HUUUUUGE difference. Roads existed for millenia before > cars.
The timescale isn't the point. My analogy refers only to your argument that today's "de facto standard" trumps historical precedent and considerate behaviour. In this respect, the analogy is accurate. But to avoid sidetracks, I retract it. Sorry it caused confusion. > By the time e-mail was in widespread use (the mid-90's... just > because you may have had it before then does not mean it was wide > spread before that), MIME was already a standard, and the vast > majority of e-mail clients had support for it. The GUI ones had it > built in. I think you are conflating two different things: - The sending of emails with multiple parts/attachments (e.g. via MIME). As noted above, I've nothing against this as long as the attachments *don't* need the MUA to parse and combine them into a new document/rendering. I *agree* that by the mid 90s, many GUI MUAs could handle such emails. - The sending of emails that *do* require the recipient's MUA to parse and combine their parts/attachments in some way. E.g. emails that require the recipient's MUA to parse an HTML part/attachment, figure out which "src" attributes in the HTML refer to images that were also attached to the email, and render the HTML accordingly with the images inline (which requires the MUA to contain or wrap a web browser). I *disagree* that by the mid 90s, most GUI MUAs could handle this. > So your argument is a straw man. Not that I can see. >> And even if yours does: should it? As several people in this thread >> have pointed out (and as is also illustrated in the "Efail" paper by >> Poddebniak et al, linked in my footer), using such an MUA massively >> increases your attack surface. > > Just because the current batch of GUI MUAs does this does not mean > yours *needs* to. That would be the beauty of a GUI Mutt--it already > has the philosophy of not automatically exposing you to all those same > attack vectors. After all, text-based Mutt has exactly the same > attack vetctors; it just does not expose you to them by default--you > have to take action to expose yourself to them. I agree that ideally no MUA, GUI or otherwise, should automatically expose you to attack vectors. Especially not to remote resources. In the case of the Efail vulnerabilities, you will see from Poddebniak, et al, that both Claws (a GUI MUA) *and* Mutt avoided the attacks. So clearly, there are some attacks that both classes of MUA can protect against. As I say, you and I are in agreement on this point. But I disagree that text-based Mutt has "exactly the same attack vectors" as a "GUI Mutt" would have, if that "GUI Mutt" were to parse, combine and render attachments as outlined above. Why? A text-based MUA is very hard to get right. It's not coincidental that Mutt's slogan is "All mail clients suck. This one just sucks less." Nor that despite decades in development, neither Mutt nor any other feature-rich text-based MUA is definitely secure and bug-free. A web browser, especially a graphical web browser, is *much* harder to get right. It has much greater complexity, and consequently a much greater attack surface. For instance, Mutt doesn't need to protect you against the Billion Laughs attack, but an XHTML- or SVG-capable "GUI Mutt" (or the XML library that it calls) would need to. Mutt doesn't need to protect you against raster image decoding vulnerabilities, but a "GUI Mutt" (or the image decoding library that it calls) would need to. And so on. Conclusion: for the same software development resources, you can expect more bugs (including more security bugs) in a GUI MUA that includes or wraps a web browser, than in a text-based MUA. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
