remote CSS?
no one supports remote CSS though, inline or nothing
that's like saying you can use JS for malicious intent in an email. well yes, if anything actually allowed it.
A new attack, dubbed ROPEMAKER, changes the content of emails after their delivery to add malicious URLs and corrupt records. The assault undermines the comforting notion that email is immutable once delivered, according to email security firm Mimecast. Microsoft reckons the issue doesn't represent a vulnerability, a stance a …
Most of the emails I send are plain text. This is the way emails were in the 1970s, and it still works. The only formatting necessary is normal punctuation and the use of paragraphs, sometimes with 2 or 3 returns between them to break up content into logical blocks.
Generally with the wide variations of OS, mail client, printing, and fonts it is a good way to ensure that the recipient has a reasonable idea of what was written. If you need fancy formatting attach a PDF.
I've always done this. And I've always replied properly - snipping anything unnecessary, and interleaving my reply so that each part it is given context by what is quoted immediately above it.
I was once asked by a colleague where my reply was, because he couldn't see it.
He couldn't see it because it wasn't at the top where he expected it to be. :(
That's only true for what is nowadays a very small, old-school slice of email users.
Everybody else at the very least can't understand why anyone would tell them they can't have bold, italics, etc. in text they write to someone.
And we're not even talking about the crazy idea that people who get their news, etc. via daily emails should get it in black-and-white text with no headlines / etc. whatsoever.
Email *was* a text medium. Decades ago.
The irony here is that your markup thus:
*was*
is rendered in bold in my Thunderbird email client. Plus it will linkify a URL. This is just about the limit of anything one could want in marked-up email. CSS is *way* over the top.
Old-school? Possibly. Immune to smart-arses with nefarious style sheets? Certainly.
The '90s called and want their rant back.
Email was a text medium. Since then it has grown richer. It is true that you can express everything in words with ordinary punctuation, but being able to add emphasis, and tables (*) is just too useful for people to be prepared to give up.
*) Yes, yes. I know you can do tables with fixed width fonts and spaces - but proportional fonts are so much nicer.
I still view email as plain text by default and I still sent plain text by default. I've noticed that some HTML clients handle plain text really badly, often losing the line breaks and bunching it all up though, but that's not my problem.
As for the occasional one that turns up and all I see is a line telling me I don't support HTML so should upgrade my email client, they're straight in the bin.
I'm of the school that considers HTML email to be a security hazard, to the point that if you send me email with an HTML section and you aren't on my approved list, it will bounce (the joys of personal email rather than business). If you can't present your information clearly as plain text then too bad. Just that simple filter takes out an awful lot of spam without having to try too hard.
"Then what happens when you're told you just lost a big deal because of your paranoia"
And what happens to you when your lack of paranoia has let in malware that's closed down your IT network for a few days or allowed access that's enabled a few million of your favoured currency units to be looted?
Then what happens when you're told you just lost a big deal because of your paranoia AND that your job is now at risk AND you risk getting blacklisted meaning you may not find a replacement job, either?
If you read my original comment I noted it was personal email, so the only person who could fire me from that is me. At work I use whatever system they have set up, although if I have enough configuration control on the email client I'll set it to favour plain text both ways. It's someone else's job to keep the system secure, my only obligation is to not do something stupid like click on the dodgy link or attachment should it make it as far as my inbox.
"I'm of the school that considers HTML email to be a security hazard".
Well, yes - because it is.
I've worked with a major email server software company for many years on data integration applications - and although that software does all sort of whizzy things, because that is what the market has demanded, corporately we only ever use Plain Text.
HTML emails are stripped back to Plain Text before receipt (by the client) and any that don't have a Plain Text counterpart are treated as toxic and are opened using rubber gloves and a pair of tongs.
FWIW, I'm old school ... mail is read and written in plain text, monospaced.
But most of what I get is not. Which is annoying, since corp types really put unnecessary junk in their mails ... long disclaimers, and worst of all, company logos. In every bloody message. Which then sits on my hard drive, wasting space for nothing.
Yes I feel better now after that rant, thanks for asking.
I am with those pointing out that email has always been fundamentally a text medium. Certainly, email *could* be something else. But do we want that? Surely the purpose of email is to efficiently communicate ideas.
When writing a paper letter, I hand-write or type a plain text missive. Logos, garish colored text and fonts, overuse of bold and italics etc. could only detract from the simple act of communicating an idea in words in the English (or any other) language.
I am in the privileged position of being selective about whom I choose to hear from. If I engage with a client who cannot communicate ideas effectively in plain English, this is not a client I want.
Cost of wasted space is less than the cost of dealing with it.
I always used to swear mightily at the dodgy attachments when it was still dial-up, noticeable pause as the crap was squeezed down the phone line only to be deleted. It's interesting how things have scaled, back then when it was still small hard disks, an offensively large attachment might have been 100k in size and hold up a V.34 modem link for some time. Now it's all scaled a few orders of magnitude bigger.
I think someone at Mimecast has been watching too much prime-time TV, because if this is the quality of "security research" that they do then they are just as credible.
First of all, no reliable email client allows remote resources by default. While we normally think in terms of linked images, tracking bugs, etc. this also applies to linked CSS stylesheets.
Second, CSS can change how HTML is displayed, but it cannot change the contents of a link. CSS does not have the capability of changing an HREF attribute. The best they could do is put two links (both good and bad) into the body of the email and hide one. They wouldn't even be able to change the target of the bad link once the message was sent.
Third, while CSS does have the capability to INSERT text content, it does not have the ability to change it or remove it. The best it can do is hide it from display.
What's next, are they going to claim that they just discovered the javascript is insecure and that malware can be injected via an iframe?
In summary, if Mimecast services were affected by this to the point where they had to put in a patch or filter to compensate, then their services were already broken.
Ok I've downloaded the ROPEMAKER information from MIMECast.
Near as I can see, the attacker has to send a carefully crafted email in order for ROPEMAKER to work. It can't simply change the content of ANY email only an email that relies on a specific remote CSS file and has been crafted to take advantage of the changes to the remote CSS file.
I'm trying to figure out why anyone in their right mind would think it was a good thing to add to CSS, something that could actually change what was visibly displayed in an HTML document.
I switched back to mutt about 2 years ago but I just checked Thunderbird and it has a "block remote content" setting, which was even enabled by default. The help text leads to a link that explicitly mentions CSS also, so I'm pretty sure this attack won't work on a default installation of TB.
As for webmail, I had to laugh at the claim that this attack will "fool even the most security savvy users". Sorry, but I find it hard to apply the phrase "security savvy" to people who use webmail directly on a browser (i.e., instead of via IMAP/POP3 on a proper mail client).
And if you're using an email service that does not allow IMAP or at least POP3, you should switch as soon as possible.
Lock down an allowed subset of HTML and simple multimedia support which is universally supported. Simple CSS with none of the latest magic features (all entirely unnecessary and mostly unsupported in the most widely used desktop clients), basic image support and a functional set of tags for paragraph formatting, text layout and so on.
The key thing is to mandate accessibility and essential support for responsive design, but all this could and should be included in an inline stylesheet. Email doesn't need deluxe stylesheet features with transitions and all of the stuff modern web sites use. It's more work for the designers of commercial email design/delivery programs, but that's their job.
This could be done pretty quickly by the main manufacturers and W3C defining an RFC in consultation with a cabal of infosec orgs. It won't happen until something catastrophic happens affecting big business, but HTML email should have never been rendered with the same support as regular web sites.
I wouldn't mind that, really. Plain text means things that can't be conveyed in words, like pictures (worth a thousand words, remember?), get lost, and you can't rely on links since they can be booby-trapped (watering-hole or drive-by attack). Everything should be inline, and you can allow things beyond text; just limit it to things that would be used for formatting purposes like the basic B, I, UL tags, and so on. I mean, since when can you be pwned by a B tag? Might as well say you can be pwned by a plain-text e-mail, in which case it's probably time to abandon the Internet altogether.