Can I Email: ‘Can I Use’ for email
caniemail.com
caniemail.com
HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
I mean, different mime versions of the same content are a possibility to do this transition: Send both plaintext, HTML and markdown, and the receiver could choose to display markdown if he otherwise would display plain text.
To be honest, this won't come. Google is pushing AMP into mails, that's exactly the opposite direction.
This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.
(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
"The AMP version of the message is embedded into the email as a new MIME part, in addition to the HTML and plaintext, ensuring compatibility across all mail clients"
From https://amp.dev/documentation/guides-and-tutorials/start/cre...
I want to see email clients start to support Markdown, so I can just send it to everyone.
Markdown is also not any better than HTML in terms of security - most markdown parsers allow passing through arbitrary HTML, and then depend on sanitizing the HTML for security.
What you are asking for is effectively a smaller subset of HTML to be used for for email (which is kind of how it started...)
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
I've yet to see what I'd really like: preformatted text being surrounded by markers that make it easy to paste in, like so:
Some regular text
vvvvv
Preformatted text
^^^^^
From Gruber’s Markdown spec:
> Readability, however, is emphasized above all else.
Some regular text
```
Preformatted text
```
Markdown is fast to type for the majority of use cases since you have:
- bullet points
- headings
- __bold__
- __italic__
- `inline code`
- etc
```
fn you_even(_have: &str) -> &str { "nifty little code blocks without needing to indent" }
```
And more importantly, markdown syntax preserves the structure of the document without harming legibility, unlike say latex or HTML. That limits it, since the syntax is small, but also reduces friction in learning/writing markdown.
Also, Reddit + GitHub.
I thought hacker news used markdown, but I guess has its own thing.
I can see the severely constrained formatting options of hacker news has both positive and negative consequences.
Try out the online examples.
Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
The actual markup MJML generates is terrifying, and can be very large payloads. A simple hero graphic, some styled body text, a few buttons, and a footer was around 60KB/message. It got gnarly for us as our MTA had a max-payload size per API 'send' call (Mandrill) so our max send rates were partially constrained by MJML's fat markup.
But totally worth it to not spend _as_ much time satisfying the mail clients of the world.
Things feel a little stale.
For example (from this week of my adventures with Foundation for Emails) Google Fonts almost sort of work for email, but there's just no real easy way to tell this framework to use them, or call any web font.
I've used it on several projects, it speeds things up quite a bit
Factoid of the day: Netscape added support for a <blink> tag to text/enriched bodies, and that support remains in every client that's still using Netscape's MIME code. The comment above this code just says: "Of course, both text/richtext and text/enriched must be enhanced somehow... Or else what would people think."
> There are other text formatting standards which meet some of these criteria. In particular, HTML and SGML have come into widespread use on the Internet. However, there are two important reasons that this document further promotes the use of text/enriched in Internet mail over other such standards:
> 1. Most MIME-aware Internet mail applications are already able to either properly format text/enriched mail or, at the very least, are able to strip out the formatting commands and display the readable text. The same is not true for HTML or SGML.
> 2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML have many features which are not necessary for Internet mail, and are missing a few capabilities that text/enriched already has.
> For these reasons, this document is promoting the use of text/enriched until other Internet standards come into more widespread use. For those who will want to use HTML, Appendix B of this document contains a very simple C program that converts text/enriched to HTML 2.0 described in [RFC-1866].
It sounds to me like text/enriched was being proposed not so much as a replacement for HTML, but because HTML and related technologies were not yet mature enough. This wording expressly frames text/enriched as a stop-gap measure.
https://github.com/mozilla/releases-comm-central/blob/master...
More importantly, though, I convinced all mail clients I use to just show plain text when viewing and writing my emails. Often there are HTML emails in which I do not see all the content, or content at all. For me this is nice because most HTML emails I get are spam, marketing related, or organizational nonsense.
http://alpine.x10host.com/alpine/alpine-info/misc/mime.html
But I might be wrong. I thought both pine and mutt would handle html through w3m or something?
I think that https://www.caniemail.com in many cases would be a timewaster. Because you spend your time exploring each individual CSS/HTML feature availability and later on realizing something can not be done in fully crossbrowser/cross-email-client way. Instead you could just accept the limitation of MJML and start coding the final version right away.
I switched to a Windows on my work laptop about 6 months ago, and the native Win 10 email client is probably the worst offender out there. Even the popular mailing lists (like IH, PH, etc) are completely broken to the point of unreadable in Windows 10 Mail.
Mailchimp has a pretty good guides on how to create cross-compatible layouts:
And this tool to test emails before sending: https://litmus.com/
> No results found. Why not suggest this feature to be added?
It's worth sending a pull-request.
Very few enterprises these days provide a “Text only, please” option in their E-Mail subscription options. Jira is, by all means, terrible software, but at least they do have this feature. I guess it's one of those situations where few people understand what it is and why you would want that. And even less people who care.
EDIT: Hmmm found this[1], and this[2]. They talk about using TROFF, TEX, Postscript, voice data, etc. I wonder if something like that ended up implemented somewhere.
EDIT 2: I opened an issue[3].
[1] https://tools.ietf.org/html/rfc1049
The Outlook ecosystem has to die.
Sorry Microsoft, but the PC world is not Windows-only anymore.
ie don't any mua let you use UTF8?
𝔻𝕠𝕖𝕤 𝕥𝕙𝕚𝕤 𝕨𝕠𝕣𝕜?
Line 1:
" You have wøn a prize! "
Unincluded line; my sister got bitten by a prize once. Or a terminal. Onto line twø: two:
Line two: (2:)
" ie don't any mua let you use UTF8? "
And three:
" Does this work? "
All the lines for all the good people. The " signs " are a delimiter for each line. They're, or should be pretty verbatim, minus the unrenderability.
Have fun.
Is it correct to have "overhang" into the line below? Isn't it a case of incorrect layout?
For those who don’t know, it’s was Microsoft WYSIWYG website builder that looked similar to Word, from 20 years ago.
I had depressed thoughts when I discovered I would be having to debug Internet Explorer in 2019.
And so on... Funny how trying to do the slightest thing with technology (send some mathematics over email) immediately turns into a research project.
(This was with the images self-contained in the email, which seems to be implemented under the hood by having them be attachments and referring to them in the body, so the loading happens out of order... I haven't tried with the images being loaded as external images, but that has its own problems such as Gmail probably not loading them by default, or having to ensure the images will be available over the internet for as long as anyone might want to read the email which if you're sending it to a mailing list is ideally forever, etc.)
<img src="data:image/png;base64,iVBORw0K...=">[1] https://addons.thunderbird.net/en-US/thunderbird/addon/latex...
Inline base64 should perform fine for small images up to ~10k images I'd guess on most hardware.
If your email contains more than 10k math equations, perhaps email isn't the right tool...
But honestly, this is way more portable then mathjax or MathML or whatever. Consider using a latex enabled chat when it really differs.
Sidenote: you can always avoid the hassle of testing HTML/CSS across email clients by just using plain text. :P
Arguably there's situation where an image will help in conveying information, or where a table will make information more readable. There's no situation where CSS is required.
Formatting lists or indented quotes (also common in “normal” email usage) using white spaces and other semi-arbitrary characters is tedious and brittle.
The “rich text” features of HTML email definitely improve readability and understanding when used with restraint.
My 3845743985793847948 gigabyte Linux ISO. Is here, in email-contextual plain text: http:/linux.iso/3845743985793847948/gib
My xes tapes? All stored at this address http://xes.sepat/all
What's the problem. Email works. Without formatting.
99% of important transactional email I get is HTML. Kind of nice to have your boarding passes and two-factor authentication emails easily visible.
Click this link to reset your password or some such.
Luckily, HTML only (or its bastard cousin: including a text/plain part that is horribly broken or just says "please enable HTML viewing") isn't seen that often around here.
<h1>Hello</h1>
<p>...</p>
<p>...</p>
<em>Thanks!</em>
Hello
...
...
Thanks!... or common sense.
(and I don't have common sense either)
<b>Hello</b><br>
...<br>
...<br>
<em>Thanks!</em>Well... Good luck with shady VML tricks!
% I'm all over for using cutting edge CSS solutions but when it comes to HTML email, I'm just:
% <h1>Hello</h1> % <p>...</p> % <p>...</p> % <em>Thanks!</em>
Let's make two billion dollars great again. Unpolitically.
% and it's done :)
Die poor.
- readable under any mail client and any text editor
- smaller size files
- safer
- better accessibility and compatibility with screen readers
In plain text, what do you get? "dash bla bla"? Though I hope screen reader are more intelligent than that, but it seems like a more complex problem than just using information given by a well-formed HTML text.
Basically almost everyone puts anything there so that they get some visually pleasing result, the markup semantics be damned.
One would think that lack of features of various mail clients would lead to using the lowest common denominator of some basic tags like b, i, a, hr, and maybe img.
Not so in reality.
One bank I've seen e-mails from even abuses invalid parsing of HTML comments, to produce whatever insane result someone somewhere dreamed up, like this:
<!--><div style="some:crap"><!-->...
(Experiences from writing a web mail client to be used in a real world.)
> (Because every test is done manually, some features might not have been tested on every email client.)
I wonder, could they not create a single test email exercising all 58 features? Then one would just have to open the test email in a given client and compare it to a reference rendering. (Kind of like the Acid1/2/3 tests of yore.)
The only tangible benefit Markdown provides is letting people write HTML who don't like the aesthetics of HTML tags.
Aside: it's nice that the site checks <bdi>, but dir/direction is much more widely used in practice and should be added.
If an email client does not, it's a bug.
Actually, I'd prefer if they added something like CommonMark and removed HTML.
Like all things, we need competition in this field. The Gmail web interface is already the most prevalent mail client. Because of this, Google can and has already started controlling the future of email. Just look at AMP for email. I agree with standardization, but not by having only one email client.
* Blocking of remote resource loads
* Which resources can be loaded via multipart/related and cid: links.
* How are doctype-less HTML bodies loaded
* "Leaking" of HTML parts in a multipart/mixed message
However this seems to lack the most important thing (for me): the global usage percentage of a particular feature, which is the #1 deciding factor whether to use a HTML/CSS feature or not.
The only people who can really use the headers to identify which email clients are in use are people who maintain very large ISPs. Although, even then, keeping track of the results of the IMAP ID command are probably more useful.
> Nor, the MS quoting issue.
-G
The last thing I want is for someone else to control the appearance of my email...
I currently rely on https://emailclientmarketshare.com/ (by Litmus) for this but if someone's aware of a better data source, I'd like to know.
But email? The usual way statistics are collected are by embedding 1×1 tracking pixels in email messages and noting who requests those images. But that will undercount any email client that has the option to refuse to load remote images, especially any one that turns that option on by default (such as Thunderbird). Another way is to look at the headers of large corpora of email, but the only ones that are publicly available are going to be mailing list archives, which will tend to have a more skewed distribution.
[1]: http://sgmljs.net
It supports responsive email designs and has many examples which you can alter to your needs.
You can see the power here: https://mjml.io/try-it-live the basic 15 line example expands to 188 lines of html so that it looks the same everywhere.
Zurb Email is like Bootstrap/Zurb Foundation, for email. They are common styles that apply to your HTML.
MJML, in other hand, is not HTML. You write MJML, instead of HTML, and it compiles to HTML.
It's really fantastic.
It doesn't seem much different to me.