Kobold letters: HTML emails are a risk(lutrasecurity.com)
lutrasecurity.com
Kobold letters: HTML emails are a risk
https://lutrasecurity.com/en/articles/kobold-letters/
143 comments
Worked for a 10,000 person company, 50% engineers. There'd be several cases a year of someone using the company credit card to buy gift cards for "the CEO" or other senior execs whose details are available on linkedin or corporate sites, despite that exact case being the example in the anti-phishing training. So you'd be surprised.
I don't doubt phishing happens. I just think this specific scenario/technique is one that is probably extremely rare. The attacker likely wouldn't put this much extra effort/thought in when their basic attacks already work, like you're describing.
Security at my job pumps their numbers by pretending you fell for a phish if you click the link in their obvious phishing test emails. I clicked one to see how good of a job they did at the other end of the link trying to extract whatever they want from me, but there's nothing there! So lazy.
I got dinged for clicking "report as phishing" as part of that process forwards it to microsoft threat intelligence in outlook and so their systems said I forwarded and therefore fell for the phishing, now I look for a particular header and put all of those messages in a "phishing" folder
I run my organization's phish sims, and we had a similar issue one month. A bunch of people failed for downloading attachments. When I looked into it further, all the attachments were downloaded by the same Czech IP address. With some research, I found that it was an AVG IP address. The fix is very simple. The phish sim service has a place to exclude IP ranges. Any activity from those IPs are just ignored. I'm sure all phish sim services and software have this ability.
Question: why is clicking on the (test) phishing email's link "fail"? Isn't the whole contract between browsers and society that one can safely open any website they want (ie loading a webpage is safe), and what you do on the actual site is the actually unsafe op?
Asking because in the vast majority of cases, the phishing landing page has way more signals to recognize than the email headers.
Asking because in the vast majority of cases, the phishing landing page has way more signals to recognize than the email headers.
Unfortunately not. If there is a 0 day vulnerability, or you're running an older version of a browser for a known patched issue, you may find yourself with a remote code execution, or 0 click download. Or it could be another kind of exploit, maybe your email service is vulnerable to XSS attacks. Like operating systems, browsers can have security issues too. So trusting your browser to see if a phish is really a phish is just unnecessary risk. I've worked with clients that have ended up with crypto lockers from clicking the link. Even from the IT side, I'm not going to increase the risk by opening a known phishing link to check how good it looks. If I am, it's going to be in a system that doesn't have active logins to other systems/sites, and is in easily disposed and reset. Check out all the YouTubers getting channels hacked with session stealing. Yes, they are falling for phishing attacks, but you really don't know what the attack vector is going to be. It might just be a fake login, or it could be much more sophisticated.
Thanks, that makes sense!
Now when I see a phish, I check to see where it is coming from. 97 percent of the time, it is a test. We're getting these tests often enough that I just assume that's what it is.
Which is fine, actually. If you see it and think "oh, IT is at it again" and delete it or report it, mission accomplished, because there is still that 3/100 chance it is real.
It only works on fake fishing.
So when you look at the sender of a suspicious email and it's not the phish sim service you just go ahead and open it? That doesn't sound like a problem with the phish sim.
It's certainly a problem with the phish sim if you're trying to teach people not to open random links and instead you're teaching people not to open phish sim emails.
It fact, it can be actively harmful if it creates a false sense of security.
It fact, it can be actively harmful if it creates a false sense of security.
Many phishing simulation systems are not technically correct. Microsoft, Google and other 'security vendors' may inspect links in emails. That link inspection can sometimes be blamed on the end user. "You clicked the phishing link, now you have to take remedial security training!"
The only way to know for certain that a user fell for a phish, during a simulated exercise, is to make an HTML form that does a HTTP POST request and contains the user's credentials (that only they could type in). If a user enters their username and password and clicks submit, then they fell for the phish, otherwise no one can say for sure who or what software clicked that link that did a simple HTTP GET.
The only way to know for certain that a user fell for a phish, during a simulated exercise, is to make an HTML form that does a HTTP POST request and contains the user's credentials (that only they could type in). If a user enters their username and password and clicks submit, then they fell for the phish, otherwise no one can say for sure who or what software clicked that link that did a simple HTTP GET.
Microsoft Safe Link technology does not actually inspect the link until the user clicks on the link. This is to avoid that confirmation links, used by some service to confirm registratio or as 2FA, may be triggered by the security engine without user consent.
Our workplace outlook phishing protection does though. I was signing up to test one of our apps recently and my email was auto confirmed in 5 seconds despite me never receiving it. Turns out it was caught in the phish filter which automatically clicked the link to check it, so the above is not always true. Confirmed this with a few co-workers too.
We must use the same vendor, as I heard about that happening to my coworkers. I clicked "it's phishing you idiots" in Outlook and got a gold star. I find it funny because my organization doesn't even use email, so 100% of email I get is spam or phishing.
The dead giveaway on this email was that there was a Via: header that was like "phishingtestsforyourworkplace.com" or something.
The dead giveaway on this email was that there was a Via: header that was like "phishingtestsforyourworkplace.com" or something.
I got dinged once for using curl (in a VM) on the link get the details to pass one when I reported it.
I once got dinged for forwarding an obvious gotcha email, without ever opening it, to our security team's phish notification address, as our employee handbook instructed. I learned my lesson.
I once got dinged for not reporting. I saw an email that was clearly an internal security campaign. I deleted it. I received an email a day or two later stating that I failed to take action on a phishing attempt. Damned if you do; damned if you don't.
For a while I had a thunderbird filter to automate forwarding based on our provider's email header.
They disabled SMTP and the Gmail web client has no such ability to filter on arbitrary email headers.
They disabled SMTP and the Gmail web client has no such ability to filter on arbitrary email headers.
You can setup a Google app automation to do this for you.
I did for e.g. knowbe4 since all their test emails have the same header information. It made it quite easy to never see any of their attempts, though I did have to check every once in a while to see if I'd been signed up for any random learning and it removed those emails as well..
I did for e.g. knowbe4 since all their test emails have the same header information. It made it quite easy to never see any of their attempts, though I did have to check every once in a while to see if I'd been signed up for any random learning and it removed those emails as well..
iirc, the same company had locked down the allowed oauth apps, so you would have needed an exception from security to run one.
I doubt they'd have granted an exception to stop getting annoyed by their own training.
I doubt they'd have granted an exception to stop getting annoyed by their own training.
I did that once for the same reason, and found myself sentenced to mandatory security retraining videos with no possibility of appeal.
Thank you!
- Browser 0-day vendor
- Browser 0-day vendor
You aren't wrong. I've got a heavily locked down browser on an off-network device for working with questionable websites. While the vast majority of phishing sites aren't pushing malware spearphishing is another story.
IT still might not want you to follow the link.
* Other users might have, instead, an incompetently secured browser that they think is locked down on their work devices. It is hard for IT to distinguish between you and them.
* If the URL is personalized, it tells the attacker that the address is active. This is probably pretty limited help to the attacker. But it might tell them if your company emails follow a particular format, right?
* Other users might have, instead, an incompetently secured browser that they think is locked down on their work devices. It is hard for IT to distinguish between you and them.
* If the URL is personalized, it tells the attacker that the address is active. This is probably pretty limited help to the attacker. But it might tell them if your company emails follow a particular format, right?
> * If the URL is personalized, it tells the attacker that the address is active. This is probably pretty limited help to the attacker. But it might tell them if your company emails follow a particular format, right?
I just asked chatgpt and it knows what email format the company I work for follows, so I'm not sure this is of particular value.
I just asked chatgpt and it knows what email format the company I work for follows, so I'm not sure this is of particular value.
It's useful, even if you aren't a scammer, but it's generally not hard info to get elsewhere.
I feel truly sorry for whoever spends a browser 0-day giving RCE on me.
It's good that I otherwise don't click on links in my browser during my day-to-day work. /s
Good thing browser aren't able to display content of random unvetted third parties in exchange for money on any website you visit too :)
Adblock is a security measure at this point.
Adblock is a security measure at this point.
While I’m not saying the specific scenario will work 100% of the time, it doesn’t need to - by the email getting forwarded at all, there is some element of trust in “my manager forwarded me this email and typed ‘complete this for me’”. If this css technique increases the attackers odds, then it’s an issue.
Or for your specific example, imagine the recipient is passing their manager in the hallway: “hey, can we chat about the Acme Corp email, I’ve got some questions about it”. Response: “sorry, super busy. It’s a fairly common ask, just get it done!”
Or for your specific example, imagine the recipient is passing their manager in the hallway: “hey, can we chat about the Acme Corp email, I’ve got some questions about it”. Response: “sorry, super busy. It’s a fairly common ask, just get it done!”
Maybe it's just good to be aware.
> I just mean the people that fall for phishing don't need this sophisticated of an attack to fall for
Yes. It's more of the opposite. It's a well documented fact that the most obvious/ridiculous scams work the best, because they help select the most gullible potential victims.
https://www.microsoft.com/en-us/research/publication/why-do-...
Yes. It's more of the opposite. It's a well documented fact that the most obvious/ridiculous scams work the best, because they help select the most gullible potential victims.
https://www.microsoft.com/en-us/research/publication/why-do-...
That analysis is from the perspective of the scammer. The scammer has limited time to write to each victim once the responses come back from the initial mass-email, so the scammer is better off if only the most gullible people reply. From the perspective of the person being attacked, the counterintuitive result based on selection bias goes away, and a more convincing scheme is more of a risk to you personally. (The assumption that scammers have limited time to write to each victim may itself become less true because of LLMs.)
This is only true for high throughput spam e-mails, such as those sent to literally every e-mail address in a large data breach. Corporate phishing attacks are much, much more advanced.
That doesn't mean those scams are actually commonly successful.
It depends on the people I guess. Some managers will be annoyed of such conversations when they have to approve payments like that on multiple occasions a day - so employees might want to avoid such conversations.
The attacker could even add something like that: "I am currently on a trip. If you are unsure call me on my private mobile phone number..." and then respond with a faked voice. I think a good way of reaching targets would be a "double" forward. So the sender assumes the role of an employee forwarding the email of a manager to an administration adjacent employee. This employee unsuspectingly forwards the seemingly harmless mail (that seems to be forwarded from the manager) again for a reason like birthday wishes or sick notice. This will make it hard for the actual target to understand where the email originally comes from.
Beside that one can easily think up more creative ways to use this "feature". E.g. letting unsuspecting persons forward problematic content and then blackmail them etc.
The attacker could even add something like that: "I am currently on a trip. If you are unsure call me on my private mobile phone number..." and then respond with a faked voice. I think a good way of reaching targets would be a "double" forward. So the sender assumes the role of an employee forwarding the email of a manager to an administration adjacent employee. This employee unsuspectingly forwards the seemingly harmless mail (that seems to be forwarded from the manager) again for a reason like birthday wishes or sick notice. This will make it hard for the actual target to understand where the email originally comes from.
Beside that one can easily think up more creative ways to use this "feature". E.g. letting unsuspecting persons forward problematic content and then blackmail them etc.
One scenario where this night not be far-fetched is when such mails are sent to the accounts payable department of large companies. The people are not going to call a line manager everytime a payment request comes through email, especially if the dollar amount is small and didn't require pre-approval.
I remember even Google had fallen prey to such a scam where they were paying somebody even though no work was done. Admittedly, that case involved fictitious invoices. However, the principle remains the same.
I remember even Google had fallen prey to such a scam where they were paying somebody even though no work was done. Admittedly, that case involved fictitious invoices. However, the principle remains the same.
I think that, in theory, it could allow for more sophisticated and targeted attacks, like changing the intended recipient of a money transfer. That would be much harder to detect.
You’re right. They wouldn’t ask any questions at all, and just send the money.
Agreed, the people falling for this would already fall for a much more basic phishing attempt. Thus, the attacker has no need to put this much extra effort/thought into it.
This doesn't even need to be a hypothetical. We know that the attacked currently do not need to do this, because they don't. Darwin's law is very much in effect for scams of all types.
I agree that his seems so specific that while it is very interesting from a technical perspective, it is also much less likely compared to most phishing.
I agree the example they give seems a bit unlikely especially since the subject line is not changing (though admittedly I do not have experience in this area).
However something a little more subtle such as swapping out a routing number from a legitimate to an illegitimate one could be done and that seems harder to catch especially if the person who forwarded it to you is supposed to verify it first.
However something a little more subtle such as swapping out a routing number from a legitimate to an illegitimate one could be done and that seems harder to catch especially if the person who forwarded it to you is supposed to verify it first.
Could be a link to some kind of portal.
You ask your boss if he sent the link to the portal, he confirms, they change the link to a phishing site.
You ask your boss if he sent the link to the portal, he confirms, they change the link to a phishing site.
A more trivial gambit is logging into an attacker controlled site leaking credentials or installing malware.
Also office drones are probable targets. They won't want to waste important peoples time asking for confirmation.
Also office drones are probable targets. They won't want to waste important peoples time asking for confirmation.
I agree, but actually it's just a really bad example that takes the reader to the wrong place because it has the participants acting so irrationally.
The underlying issue is still there, they've just distracted from it by putting this in and having the reader go "hang on a second". They should have used a situation that was more believable, but also concentrated more on requests where the target likely wouldn't even seek confirmation.
The underlying issue is still there, they've just distracted from it by putting this in and having the reader go "hang on a second". They should have used a situation that was more believable, but also concentrated more on requests where the target likely wouldn't even seek confirmation.
This attack works like normal Sales calls. Hit enough of them and you'll find someone that's new, or in a rush, or distracted or ancient or challenged or a Republican idiot, or, or.
That's why it's still in use today. It works, but takes a lot of "cold calling" via phishing to find targets.
That's why it's still in use today. It works, but takes a lot of "cold calling" via phishing to find targets.
My gut says this could be more effective. After all, the initial “phish” (the innocent looking email the manager receives) isn’t fishy at all, and unlikely to trigger any concern. Once the stakes are raised and the scam is revealed, the email has already been granted some amount of legitimacy.
Sure, it can easily fail (“did you really want me to wire money to Cyprus?”), just as any phishing email can. But by bypassing the initial phishing filters of the recipient’s awareness, I could see it having a higher success rate than a cold phish that leads immediately with the scam.
No evidence or knowledge either way, just a hunch.
Sure, it can easily fail (“did you really want me to wire money to Cyprus?”), just as any phishing email can. But by bypassing the initial phishing filters of the recipient’s awareness, I could see it having a higher success rate than a cold phish that leads immediately with the scam.
No evidence or knowledge either way, just a hunch.
Still pretty cool trick though
The other day I was discussing the design for an "update" email that our designer was putting together and showing me the size of this stupid graphical header he put at the top and I was showing him how with that you can't even see the text of the title of the email without scrolling down, and then he forwards some other version to me for more feedback and suddenly started getting all disturbed and upset because something looked different to him.. like the fonts were a bit smaller.. and then he said, oh no, when you forward it, it transforms it to the desktop version, instead of the mobile version! And I'm sitting there in disbelief, just staring at him, like,... this is EMAIL we're talking about, what do you mean "desktop" version and "mobile" version? How is that even a thing? What do you mean it "transforms" it? It's literally just copying it! The fact that it "breaks" when you do that is evidence of how stupid this is. My god man, why is CSS in my email at all?
The fact that we haven't adopted something much simpler to just be able to express italics or whatever, like markdown, is just bonkers to me. It just shows how little anyone cares about actually improving the situation. And all just to cater to the bizarre corporate need to put logos and banners everything. HTML email is just ridiculous.
The fact that we haven't adopted something much simpler to just be able to express italics or whatever, like markdown, is just bonkers to me. It just shows how little anyone cares about actually improving the situation. And all just to cater to the bizarre corporate need to put logos and banners everything. HTML email is just ridiculous.
> The fact that we haven't adopted something much simpler just to be able to express italics or whatever, like markdown, is just bonkers to me.
Sounds like you want text/enriched [1], which was published in (checks notes) 1996 and has read support in likely every email client ever.
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
Sounds like you want text/enriched [1], which was published in (checks notes) 1996 and has read support in likely every email client ever.
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
Sure, and how many people use it? Available != adopted.
Responsive email frameworks are a thing, like MJML.
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup instead of HTML for rich text in emails. This would makes it easy for emails clients to decide about either showing the text as rich text or just plain text, while supporting most of the formatting that a normal user might need: bold, italic, quotes, inline images, code blocks, headers, ...
Sure it wouldn't be good for marketing emails with the super advanced HTML but I don't think anyone should care about this use-case.
Sure it wouldn't be good for marketing emails with the super advanced HTML but I don't think anyone should care about this use-case.
Something similar exists as text/enriched defined in RFC 1896. Apple Mail, among others, supports it.
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
> https://en.wikipedia.org/wiki/Enriched_text
Ironically references an article called "Why HTML is Inappropriate for E-Mail" (http://www.avernus.com/~gadams/essays/20020418-html-mail.htm...) posted way back in 2002 apparently.
We're just walking around in circles after all...
Ironically references an article called "Why HTML is Inappropriate for E-Mail" (http://www.avernus.com/~gadams/essays/20020418-html-mail.htm...) posted way back in 2002 apparently.
We're just walking around in circles after all...
This goes back to 1998 at the very least: https://en.wikipedia.org/wiki/ASCII_ribbon_campaign
It was clear from the start that using HTML in email was a bad idea.
It was clear from the start that using HTML in email was a bad idea.
This sort of dogmatic rejection of HTML ended up being the bigger problem. If instead futilely fighting against HTML email the community would have just embraced the idea, we could have a sensible spec for email (instead of just ad-hoc whatever Outlook does) and email could have had a chance to prevent its fading relevancy.
But no, we had to fight the great evil of rich text which left vendors, MS in the forefront, to their own means to fulfill the strong and justified user demand, with predictable outcome.
But no, we had to fight the great evil of rich text which left vendors, MS in the forefront, to their own means to fulfill the strong and justified user demand, with predictable outcome.
RFC 1896 defined a sensible alternative in 1996. I agree that it should have received more support, although at least a range of Unix MUAs and Apple Mail did and do support it.
Many markdown parsers allow inline html. In some languages, it’s most of them. Only a few let you turn it off. So stupid.
For better or worse, inline HTML was key part of original markdown spec:
> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
> If you want, you can even use HTML tags instead of Markdown formatting; e.g. if you’d prefer to use HTML <a> or <img> tags instead of Markdown’s link or image syntax, go right ahead.
Markdown was not really intended as standalone markup format, instead it was more just a tool for authoring HTML
> Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.
> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
> If you want, you can even use HTML tags instead of Markdown formatting; e.g. if you’d prefer to use HTML <a> or <img> tags instead of Markdown’s link or image syntax, go right ahead.
Markdown was not really intended as standalone markup format, instead it was more just a tool for authoring HTML
> Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.
Well, the markdown specification allows inline HTML, so that's to be expected. But it's true if you're taking user input as markdown and display it as rendered HTML, you need to think very carefully about escaping and sanitization.
Given that the Lynx browser (HTML in a text terminal) continues to function reasonably well, why is there any need for a different markup language?
It helps for keeping the feature set limited. With HTML, the incentive to use a full-blown implementation is just too strong, and the risk of inconsistent implementations and deliberate or accidental extensions too high.
You could also in theory just restrict which HTML elements can be used. You’d need to do that anyway for MD, especially since MD can contain HTML itself.
I’m a huge fan of MD either way ;) I’ve built entire large sites where raw content is stored in MD (along with a MD WYSIWYG) and then the MD is converted to HTML. I’ve found it’s easier and more reliable to parse MD vs HTML, unless of course you’re using a block editor or something more structured.
I’m a huge fan of MD either way ;) I’ve built entire large sites where raw content is stored in MD (along with a MD WYSIWYG) and then the MD is converted to HTML. I’ve found it’s easier and more reliable to parse MD vs HTML, unless of course you’re using a block editor or something more structured.
> You could also in theory just restrict which HTML elements can be used.
That’s not enough, because you also have to restrict what attributes they may carry (inline styles, event handlers), the type of meta tags and image formats, and so on.
But in any case, such a restricted subset was what I was already presuming in my comment.
That’s not enough, because you also have to restrict what attributes they may carry (inline styles, event handlers), the type of meta tags and image formats, and so on.
But in any case, such a restricted subset was what I was already presuming in my comment.
You don't have to restrict them at all.
You just ignore them.
You just ignore them.
That's what is meant by restricting.
Well, getting enough uptake is difficult because email standards are hard to change. We still don't have support for hyperlinking emails, though I tried to fix that recently:
https://pastebin.com/kHQs50xm
https://pastebin.com/kHQs50xm
The mid: scheme (see https://datatracker.ietf.org/doc/html/rfc2111) can theoretically do that and has been around since, uh, 1997.
Yep, and even with it being possible, no one's bothered to make it usable for email hyperlinks, hence the problem. The (attempt at an) RFC I linked avoids depending on the other side tracking the MessageID, assuming only things they would want to store.
Message-ID is something already stored in your email database, because it's necessary for a lot of stuff (in particular, threading conversations correctly). I'd be shocked if any email store didn't support querying by message-ID. Querying by body is a lot harder, since you need full-text support in the body. It's not the difficulty of implementing mid that's blocking support in clients.
Color and Size are basic, useful aspects of writing.
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad, lock themselves in the server room and destroy all the hardware while screaming “why is Outlook rendering DIFFERENT”
(Seriously though, this is a fascinating exploit)
(Seriously though, this is a fascinating exploit)
This is why I decided years ago to just pay an HTML email coding service for anything email-related. There’s a lot of bespoke knowledge required for coding HTML templates that pass litmus tests and I never want to go there again.
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags? To improve usability, email clients could include an automatic step where all Stylesheets are “compiled” to inline styles.
The only thing this would break would be advanced CSS selectors (hover etc.) but I’m not sure they would be needed.
I agree. Just baking all classes into inline styles before even presenting the mail should fix this. It makes sense to do this anyway. Pseudo classes and media queries wouldn't work, but those would pose a security risk anyway and are not supported by major mail clients (see https://www.caniemail.com/features/css-at-media/)
HTML emails have to inline CSS already due to Outlook & Gmail using decades-outdated rendering engines (outlook literally uses the 2006-era MS Word html engine).
Also, killing all style attributes would also kill mobile optimization and dark mode as well, since you cannot inline media queries.
Also, killing all style attributes would also kill mobile optimization and dark mode as well, since you cannot inline media queries.
And we all owe a great debt to Microsoft for preventing the appification of E-Mail.
This would also break the current approach for responsive emails.
Usually the default/desktop styles are already compiled and inlined, then a style tag with media query selectors is used in the `head` to improve readability for mobile devices.
Usually the default/desktop styles are already compiled and inlined, then a style tag with media query selectors is used in the `head` to improve readability for mobile devices.
The horror! Is there a real need here though as opposed to just something people do, and where does such CSS come from in the case of emails? You could be "responsive" by not doing certain things instead of actively doing something and for email content it feels fitting.
You’re asking if email CSS ever needs to be tailored to mobile devices? It’s not any different than web pages needing to be tailored to mobile devices. The answer is yes, sometimes it is necessary.
The answer is different because an email is not a standalone webpage and there are a lot of things you might want to do in a website that you won't expect to be able or need to do in an email. You probably don't want to control font sizes or page margins in an email, for instance; you probably do want to control color or override some overflow defaults. Maybe I'm off in the above but the point is that you expect to control a subset of things for an email (same as eg for RSS entries) and media selectors aren't obviously necessary for these kinds of things.
What if you want to place two divs alongside each other on desktop but stacked vertically on a phone?
How about not placing two divs alongside each other in the first place? Every time I see that, I immediately start looking for the unsubscribe link or mark it as spam.
Your preference is not everyone’s preference. It’s silly to suggest every email client disable media queries because you dislike seeing two elements side by side.
That's true, but is anyone going to be up in arms because things are not side by side in an email?
I agree with others that emails should just be plain text. It has never bothered me or anyone else I've known to just have plain text and a link that sends them to an actual webpage if HTML is absolutely necessary.
I agree with others that emails should just be plain text. It has never bothered me or anyone else I've known to just have plain text and a link that sends them to an actual webpage if HTML is absolutely necessary.
This is really clever!
Premise: CSS in HTML email allows some text to be visible only after the message is forwarded. This is a huge threat to the trustworthiness of verified email! Examples given in Thunderbird, Outlook, Gmail. Excellent work.
I read all mail in mutt, so this is officially "someone else's problem".
...
Consequently, I'll complain about something else:
> This issue was reported to Mozilla on 05.03.2024. The planned release date and a draft of the following section were communicated to Mozilla on 20.03.2024.
I agree that little-endian dates make more sense than US-style middle-endian dates.
But I will assert that any technologist who does not use ISO 8601 date formatting (2024-03-05, with or without hyphens), is doing it wrong. :)
Premise: CSS in HTML email allows some text to be visible only after the message is forwarded. This is a huge threat to the trustworthiness of verified email! Examples given in Thunderbird, Outlook, Gmail. Excellent work.
I read all mail in mutt, so this is officially "someone else's problem".
...
Consequently, I'll complain about something else:
> This issue was reported to Mozilla on 05.03.2024. The planned release date and a draft of the following section were communicated to Mozilla on 20.03.2024.
I agree that little-endian dates make more sense than US-style middle-endian dates.
But I will assert that any technologist who does not use ISO 8601 date formatting (2024-03-05, with or without hyphens), is doing it wrong. :)
Not only that, but any person using middle-endian date format is doing it wrong. It's the least rational way to write something! Little-endian at least has the virtue of just being backwards relative to how you write every other number, but middle-endian is just bonkers. (So of course it's the way Americans do it.)
Americans use "March 5th" as the verbal form of dates when the context (year) is clear. This actually makes sense -- it puts the most significant part first, and narrows from there. The numeric representation follows that form, becoming "3/5".
But of course for full context, Americans say "March 5th, 2024", yielding "3/5/24" or similar atrocities.
I'm a big fan of ISO 8601. They got this one right. It's clear, non-preferential, and (critically) it sorts lexically with expected results!
But of course for full context, Americans say "March 5th, 2024", yielding "3/5/24" or similar atrocities.
I'm a big fan of ISO 8601. They got this one right. It's clear, non-preferential, and (critically) it sorts lexically with expected results!
But if Americans follow the reasoning to put the most important information first, then why do they say "March 5th, 2024"? With that reasoning shouldn't it be "2024 March 5th"?
For spoken communication you could even extend it to "Anno Domini 2024 March 5th", following the common pattern in spoken language of adding somewhat redundant filler to indicate something worth paying attention to is coming up.
For spoken communication you could even extend it to "Anno Domini 2024 March 5th", following the common pattern in spoken language of adding somewhat redundant filler to indicate something worth paying attention to is coming up.
> But if Americans follow the reasoning to put the most important information first, then why do they say "March 5th, 2024"? With that reasoning shouldn't it be "2024 March 5th"?
Because you're falsely equating "important" and "significant". It's not about little endian vs big endian, which is all about magnitudes. Most of the time, the year is implicit (i.e., this year, or perhaps next year but that will be inferred from the month). Rolling over months happens quite often, rolling over years is rare. And in cases where the month really doesn't matter, it'll be dropped: "see you on the 5th!"
That said, I personally dislike both MM-DD-YYYY and DD-MM-YYYY. Mon DD, YYYY is fine. YYYY-MM-DD (ISO8601) is fine (and to be preferred when naming files or in any other context where you'll be seeing lots of dates at once).
Because you're falsely equating "important" and "significant". It's not about little endian vs big endian, which is all about magnitudes. Most of the time, the year is implicit (i.e., this year, or perhaps next year but that will be inferred from the month). Rolling over months happens quite often, rolling over years is rare. And in cases where the month really doesn't matter, it'll be dropped: "see you on the 5th!"
That said, I personally dislike both MM-DD-YYYY and DD-MM-YYYY. Mon DD, YYYY is fine. YYYY-MM-DD (ISO8601) is fine (and to be preferred when naming files or in any other context where you'll be seeing lots of dates at once).
> Anno Domini 2024 March 5th
Gregorian Anno Domini 2024 March 5th. :)
Gregorian Anno Domini 2024 March 5th. :)
I thought so too for most of my life but living in the states has changed my perspective since the practice is coherent with spoken language. Now I mostly write out the month to make it clear. Let me just appeal to all Americans to use slashes as separators and not dots.
Side note: Military format 12MAR24 seems both concise and unbiguous but most people understandably find that unusual (just like ISO dates)
Side note: Military format 12MAR24 seems both concise and unbiguous but most people understandably find that unusual (just like ISO dates)
The military format is ambiguous. For example, 12MAY24 means 2024-05-12 in English but it means 2024-03-12 in Manx Gaelic [1].
Also, tell me: what date is 10SKÁ11? Or 01DU02?
Furthermore, a lexicographic sort will do the wrong thing.
Better stick with ISO 8601.
[1] https://gv.m.wikipedia.org/wiki/Mayrnt
Also, tell me: what date is 10SKÁ11? Or 01DU02?
Furthermore, a lexicographic sort will do the wrong thing.
Better stick with ISO 8601.
[1] https://gv.m.wikipedia.org/wiki/Mayrnt
Yep. Numbers > names, always. I'll go even further: months shouldn't even have names (which no longer even make sense, like October)! Neither should the days of the week, like the Chinese do it.
12MAR24 is so close. If they just went with 12MAR2024 it would have been unambiguous.
Of course it lacks many advantages of ISO8601 like sorting correctly in alphabetical sorting or working across languages, but it's a huge step up from 3/12/24.
Of course it lacks many advantages of ISO8601 like sorting correctly in alphabetical sorting or working across languages, but it's a huge step up from 3/12/24.
For many years, I used "12 Mar 2024" in written form.
But the convenience of ISO 8601 for electronic form is compelling, and it has slipped into my writing as well.
But the convenience of ISO 8601 for electronic form is compelling, and it has slipped into my writing as well.
Is that March 24th, 1912?
[deleted]
I see that some of the email clients mentioned wrap the mail’s content in extra HTML tags and modify the CSS and classes names. I’m wondering why email clients don’t use sandboxed iframes to render HTML email? Do they still present security risks?
The extra HTML does not happen from the client reading the forwarded email, but when forwarding. That is expected, because the forwarding party might want to add more text to the email.
At least the person forwarding the mail could check the preview and see that the text changed.
In the past I had issues using iframes. Not for rendering or security issue (those work great in my memory). But if your email has a link to your website, and your sandbox iframe disallow Javascript, then this "security context" is carried over to the page that was opened from clicking the link inside the iframe, and you website cannot use JS.
[edit] The solution was "allow-popups-to-escape-sandbox", so I see no reason it would not work.
[edit] The solution was "allow-popups-to-escape-sandbox", so I see no reason it would not work.
A classic cut off the limb to fix the cut solution. The problem is bad standardization for email that has allowed hacks like this to rule the day.
HTML in general is susceptible to these very concerns. Plenty of emails exist that use HTML without incident. This reads as one user’s frustration with something in the wild that is dressed as a security issue.
HTML in general is susceptible to these very concerns. Plenty of emails exist that use HTML without incident. This reads as one user’s frustration with something in the wild that is dressed as a security issue.
Some possible mitigations from the top of my head (maybe ineffective):
- warn prominently on hidden elements
- randomize the number of enclosing div, on both incoming and outgoing
- compute what the forwarded message would look like on forwarding, ask for confirmation if differs significantly. Or do the opposite (probably more effective since doesn't require other clients to help)
- warn prominently on hidden elements
- randomize the number of enclosing div, on both incoming and outgoing
- compute what the forwarded message would look like on forwarding, ask for confirmation if differs significantly. Or do the opposite (probably more effective since doesn't require other clients to help)
"Why emails are a risk to your organization" there fixed it for you
At that point it's just "why communication with the outside is a risk to your organization".
This article presents an attack vector unique to HTML emails, but most attacks over email can be easily adapted to work over WhatsApp, Slack, Jira, Zoom, or whatever else people use to communicate with the outside world.
This article presents an attack vector unique to HTML emails, but most attacks over email can be easily adapted to work over WhatsApp, Slack, Jira, Zoom, or whatever else people use to communicate with the outside world.
[deleted]
When efail came out, I wrote a blogpost about the security risks of HTML mail.
It is really amazing how problematic all of this is, despite its widespread use. The HTML mail spec is really old, and contains almost no security considerations.
HTML in emails can only be a subset of HTML to be secure. But nobody has ever defined what exactly that subset is, so everyone does whatever they think. And unsurprisingly, this leads to an endless stream of security flaws.
See: https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-no...
It is really amazing how problematic all of this is, despite its widespread use. The HTML mail spec is really old, and contains almost no security considerations.
HTML in emails can only be a subset of HTML to be secure. But nobody has ever defined what exactly that subset is, so everyone does whatever they think. And unsurprisingly, this leads to an endless stream of security flaws.
See: https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-no...
Clever trick. It reinforces the position I've held since the 1990s. Emails should be text. HTML is for web pages.
I've been using exclusively plain-text email for a long time, and it's not even for security; I want to be able to respect people's font choice.
When you send HTML emails, the font is chosen by the sender, which normally is fine, but some people prefer to use dyslexic-friendly fonts (e.g. OpenDyslexic or Comic Sans) to read their email, and I don't want my message to be artificially more difficult to read.
Since most emails really don't need elaborate formatting, I'm not 100% sure why this isn't the default.
When you send HTML emails, the font is chosen by the sender, which normally is fine, but some people prefer to use dyslexic-friendly fonts (e.g. OpenDyslexic or Comic Sans) to read their email, and I don't want my message to be artificially more difficult to read.
Since most emails really don't need elaborate formatting, I'm not 100% sure why this isn't the default.
What prevents the client app from overriding this font option? Plain text disrespects readability aspect since you lose the most basic highlighting like bold/italics
I don’t think anything “stops” you from overriding the font, outside of potentially breaking formatting. It just doesn’t appear to be directly enabled on most clients; it seems like most clients will default to the font the email uses for HTML.
>...it may even be cryptographically signed ...
In general, anything you are going to sign has to be in a simple enough format to make it so that the sender and the receiver(s) can actually determine what is signed. HTML should automatically be considered unsigned. It simply is not suitable for the purpose.
In general, anything you are going to sign has to be in a simple enough format to make it so that the sender and the receiver(s) can actually determine what is signed. HTML should automatically be considered unsigned. It simply is not suitable for the purpose.
HTML in email shouldn't be as big of a nightmare as it is. It really comes down to rendering engines. If all email clients just checked for text vs HTML and when HTML switched the rendering engine to Webkit, this problem could be solved overnight.
There's zero reason why you can't render an email the same way you can as a regular page (minus JavaScript).
Out of curiosity, is anybody working on this? It seems like a standard could be produced w/ relative ease to make it easier on vendors. Imagine somebody has at least proposed the idea before...
There's zero reason why you can't render an email the same way you can as a regular page (minus JavaScript).
Out of curiosity, is anybody working on this? It seems like a standard could be produced w/ relative ease to make it easier on vendors. Imagine somebody has at least proposed the idea before...
> the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.
oh, that's sneaky. Would "plain" old rtf have been a better choice for formatted emails since that CSS complexity isn't much needed outside of spam marketing :) Why has that been surpassed by HTML&CSS
oh, that's sneaky. Would "plain" old rtf have been a better choice for formatted emails since that CSS complexity isn't much needed outside of spam marketing :) Why has that been surpassed by HTML&CSS
Don't let me start on phishing SMS texts... still around and strong. My phone will fireup a non-big-tech noscript/basic (x)html browser if I mistakenly click on an URL in it AND my phone does not run android (or an other linux based phone OS) nor iOS.
[deleted]
[deleted]
this highlights a broader issue of irreproducible content.
Another good example are group chats where some recipients see messages inconsistently or in a different order than others. It can happen due to inconsistent delivery, inconsistent ACLs, or other reasons.
How can people agree on things when they are not looking at the same thing? And people assume that everyone sees what they see by default.
Can a board make a decision when not everyone has the same presentation of facts?
Remember when you judged someone for asking a stupid question when the answer was just posted a moment ago? How do you know they even received it?
Another good example are group chats where some recipients see messages inconsistently or in a different order than others. It can happen due to inconsistent delivery, inconsistent ACLs, or other reasons.
How can people agree on things when they are not looking at the same thing? And people assume that everyone sees what they see by default.
Can a board make a decision when not everyone has the same presentation of facts?
Remember when you judged someone for asking a stupid question when the answer was just posted a moment ago? How do you know they even received it?
Between these sorts of email tricks and ability to easily voice clone using ai, it would seem that invoicing systems should put some sort of 2 factor approval/confirmation into the workflow for payouts.
If we style the kobold letter as an overlay, we can not only affect the forwarded email, but also (for example) replace any comments your manager might have had on the original mail, opening up even more opportunities for phishing.
tangentially and anecdotally, it's only occurred to me fairly recently, like within the past year or so, to configure all my mail clients, including both desktop and mobile Outlook (and OWA), to not 'automatically download new messages'. this really needs be the default setting.
Why?
so as not to automatically download any HTML content i don't want to download since those calls are trackable.
my guess is you're confused and you think i mean i've disabled mailbox sync or something...? obviously not. i don't know, man, questionable downvote first/clarify second. but you're welcome for the gratuitous privacy tip.
my guess is you're confused and you think i mean i've disabled mailbox sync or something...? obviously not. i don't know, man, questionable downvote first/clarify second. but you're welcome for the gratuitous privacy tip.
See also: The Spammers' Compendium: https://www.virusbulletin.com/resources/spammerscompendium/
> To prevent the CSS of emails to affect the style of the webmailer, Outlook modifies the email by prefixing all ids and classes with x_ and adjust the CSS accordingly.
Wait what, OWA loads emails directly into the same DOM tree as the rest of the app instead of an iFrame?
Wait what, OWA loads emails directly into the same DOM tree as the rest of the app instead of an iFrame?
So does gmail.
I feel like it’s a HUGE (silly) assumption you’d ask generically “did you send this email” instead of something more specific like “do you REALLY want me to transfer you money like this?” to which the manager would obviously be confused and the attack would likely be killed in that conversation.
This is an interesting attack vector but I am questioning how likely it is to succeed. The article paints a very specific and narrow window of events for this attack to really work. I don’t buy it, personally.
EDIT: I know phishing happens and works. I am not saying it doesn't. I just mean the people that fall for phishing don't need this sophisticated of an attack to fall for. In fact, the attacker probably narrows the chance of success by putting this much extra (very specific) effort into the attack. They are likely to just succeed with their typical phishing email.