[HN Gopher] Can I Email?
___________________________________________________________________
Can I Email?
Author : ggregoire
Score : 630 points
Date : 2021-05-11 01:08 UTC (21 hours ago)
(HTM) web link (www.caniemail.com)
(TXT) w3m dump (www.caniemail.com)
| lionkor wrote:
| Get KMail on the list!
| stjohnswarts wrote:
| not enough users.
| lionkor wrote:
| well yeah, without builtin telemetry and government-grade
| spying, you can't tell how many users it has, fair
|
| Edit: i realize this comes off as snarky, sorry. It's meant
| as a joke. It's reasonable to say that its likely not popular
| enough.
| stjohnswarts wrote:
| Apologies, just someone who recently had a customer try to
| convince me I should rewrite my FPGA code to handle his one
| or two off product (but very expensive) product for free :)
| so I understand why developers can't target every user
| haha.
| nimbius wrote:
| >This page ranks email clients based on their support among the
| 182 HTML and CSS features
|
| No thanks. I still recoil at the sight of a read-receipt and the
| only reason most companies include any of this dreck in an email
| in 2021 is to either track me or market to me.
|
| make email text again.
| breakfastduck wrote:
| You can track people through CSS?
| hanche wrote:
| Specify a background image?
| FranchuFranchu wrote:
| Load a background image and store the IPs that asked for it.
| zeroimpl wrote:
| You could also do that even better with plain <img> tags,
| so that's not really a special attack vector.
| surround wrote:
| If companies want to have inline images in their emails, they
| should have to send the image data along with the rest of the
| message. Email clients should not allow emails to load third
| party resources.
| tzs wrote:
| > make email text again
|
| That ship sailed the instant it got named "email" instead of
| something like "etelegram".
|
| With mail, I can send anything that my printer can print, which
| is everything my word processor can handle (fonts, text
| decoration, foreground and background colors, inline images,
| graphs, tables, and more) and attach anything that fits in the
| envelope (a CD-ROM of arbitrary data in any format).
|
| It was inevitable that email would end up being able to handle
| the electronic equivalent of all those things.
|
| The problem with email is not that it now handles more than
| just plain text. The problem is that there was no early
| agreement on _how_ to handle those things, so different
| implementors came up with different ways to do it, which
| eventually converged on using HTML. Not because HTML was
| necessarily the best way to do it, but because it was something
| they all already implemented for other things or was already
| available on the systems their mail clients ran on.
|
| But modern HTML engines are designed for the web, so there
| still really needs to be some sort of agreement on a subset of
| HTML that handles the things necessary to make email like mail,
| without including things that make sense for the web but not
| for mail.
| paultopia wrote:
| "Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should."
| st_goliath wrote:
| On a very similar discussion (e-mail feature bloat;
| particularly HTML mail) I once heard somebody describe the
| software developers involved to have suffered from "Beach Boy
| Syndrome" (wouldn't it be nice if...)
| ChrisArchitect wrote:
| previous discussion:
| https://news.ycombinator.com/item?id=20948826
| sh1mmer wrote:
| It would be great if the JSON data could be easily plugged into a
| linter so you could quickly validate if you are likely to have
| issues on a given client or not.
| neop1x wrote:
| Email is not a webpage. Keep your web skills for the web, please.
| domano wrote:
| I find MJML (Mailjet Markup Language) to be a solution for many
| headaches.
| traspler wrote:
| "Outlook (Windows)" is dead last in the "rankings". That's pretty
| much the only page on there that matters sadly; Determining which
| features work on Outlook for Windows and that's the maximum that
| can go into an HTML EMail.
|
| Sure, I'd love to only send txt mails but that sadly does not
| align with the expectations/desires of the companies I've worked
| with.
| felixfbecker wrote:
| If Microsoft could just bundle their Edge/Chromium renderer
| instead of their ancient WordHTML engine, or even the EdgeHTML
| engine of the previous Edge, they'd do the whole industry a
| huge favor. It's so frustrating their holding us back. Instead,
| they allow Google to push technologies like AMP for email for
| things that could probably be solved with standard HTML.
| traspler wrote:
| The situation is wild. In older Outlook versions they've used
| IE to render the received mails but used a custom engine when
| you were writing/editing an email. You could even use Word as
| an editor so you could generate the HTML using Word as your
| WYSIWYG IDE. I can understand why that needed some
| consolidation into one editor and one engine but re-using
| Word so they wouldn't have to create a new editor wasn't the
| best decision for the ecosystem.
|
| WYSIWYG editors and rendering engines aren't things I know
| about so I wonder if there have been difficult engineering
| issues at that time or if they just went at it from a
| business standpoint of "people see mail like letters so they
| are documents for which we have word so let's use that".
|
| //Edit: Looks like they were mainly interested in providing a
| great WYSIWYG experience using tools users are already
| familiar with: https://web.archive.org/web/20110311083708/htt
| p:/blogs.offic... great quote: "There is no widely-recognized
| consensus in the industry about what subset of HTML is
| appropriate for use in e-mail for interoperability. The
| "Email Standards Project" does not represent a sanctioned
| standard or an industry consensus in this area. Should such a
| consensus arise, we will of course work with other e-mail
| vendors to provide rich support in our products." - I guess
| their argument could be that there still is no "HTML standard
| for email" so they don't have to support anything they don't
| want to?
| mschuster91 wrote:
| Biggest joke is, they're already having a decent renderer on
| macOS.
|
| You can load plain HTML as a .eml template into it and send
| it off... but not on Windows, you're stuck with some weird
| undocumented binary format there.
| unilynx wrote:
| They could easily do that. But they want to use their Word
| component to compose replies to emails. So it needs to go
| through the WordHTML at some point..
|
| And from that perspective, it's better to break the mail as
| it's coming in (so the sender gets blamed) rather than at the
| moment the user clicks reply.
| shoto_io wrote:
| Neat site!
|
| We use MJML to ensure compatibility in all mail clients, which
| works fine. Although MJML is much less flexible than pure HTML.
| mrwnmonm wrote:
| If that can be applied on a complete html file, it would be
| great. Take the html, and tell the user which tags will likely
| cause problems.
| dandare wrote:
| Hi
| overspeed wrote:
| Continuously modifying the URL with the search term wreaks havoc
| on tab history. Why not wait for the user to finish typing first?
| mvlpn wrote:
| I have no clue why something this obvious is not taken care of.
| larsnystrom wrote:
| They should just use history.replaceState() instead of
| history.pushState().
| tyingq wrote:
| I like the AMP for email table:
| https://www.caniemail.com/features/amp/
| kuon wrote:
| I really don't like HTML emails as they very often break with my
| dark theme. Especially those in Outlook, dark blue on dark gray
| is not very visible. I'd like to have only plain text emails, but
| some website do not put text version of their mails
| (notifications...).
| qwertox wrote:
| My first thought was that the higher on the list a client is, the
| more vulnerable it is.
|
| Am I wrong with this assumption?
| stjohnswarts wrote:
| Yes.
| lionkor wrote:
| I would say that, generally, higher complexity results in more
| possible attack vectors. Give that assumption, any client high
| on the list has more attack vectors than ones down the list.
|
| I also think, though, that any open source client likely does a
| good job regardless of feature density, since its likely going
| to use well vetted code in core components.
|
| Saying that, for example, Microsoft's or Apple's code isnt well
| vetted is unfair, but the amount of eyes that have seen the
| Microsoft html renderer vs the, say, WebKit one, is likely
| smaller and less diverse.
| fxleach wrote:
| At first glance I have no idea what this website does. At second
| glance I still don't.
| FranchuFranchu wrote:
| It checks whether an email client supports and HTML or CSS
| feature for rendering.
| josteink wrote:
| Weird to see Thunderbird for Mac and Windows perform so
| differently. Anyone knows what's up with that?
|
| (And what about Linux?)
| zekica wrote:
| From what I can see, they haven't tested most of the features
| in Thunderbird for Windows.
|
| From my experience, all versions (Windows, macOS, Linux) have
| the same features.
| [deleted]
| sebmellen wrote:
| I would pay an extra $0.10 per month to any service which offered
| plaintext only emails... Ah, a man can dream.
| intc wrote:
| We are soon opening https://c1.fi - Horde webmail
| (https://wm.c1.fi) can do this.
|
| (Preferences -> Mail -> Composition -> Default method to
| compose messages: "Plain Text")
| chrismorgan wrote:
| In Fastmail's webmail:
|
| Settings - Preferences - Show advanced preferences - Reading -
| View HTML, select _Always display messages in plain text_.
|
| Settings - Preferences - Show advanced preferences - Compose &
| Reply - Compose format, select _Plain text_ , plus untick _When
| replying, use the same format as the original message_.
|
| I don't think this is such a rare feature, though it's
| generally not made _obvious_ at least.
| sebmellen wrote:
| Sorry, I suppose I wasn't very clear. I do this through
| Posteo and Tutanota already (though perhaps you could sell me
| on Fastmail with your insider knowledge ;).
|
| What I mean is I wish companies would send their
| transactional emails and newsletters in plaintext. Images and
| the like could be sent as attachments, as opposed to creepy
| weblinks that track your opens and IP and everything.
|
| I would pay _each_ company $0.10 if they offered me the
| option of receiving all their emails in plaintext like this.
| oblio wrote:
| They'd probably make less money if you paid them, that's
| the problem.
|
| And you'd also need to be able to somehow force them to
| <<only>> monetize you through direct payment, because what
| most companies do is, take your money <<and>> also sell
| your data, on top of that.
| pembrook wrote:
| If you hang out on HN a lot, I can see how you might
| think "most companies" are selling your data.
|
| But this is hilariously false. Nowhere near "most"
| companies are selling your data.
|
| In fact, an _overwhelmingly vast majority_ of all
| businesses don't sell your data. This is true inside
| Silicon Valley and even more true outside of the Valley.
|
| Even in Silicon Valley, most companies understand that
| selling products and services to customers is more
| profitable than trashing a customer relationship by
| selling a customer's personal info to third parties.
| nerdponx wrote:
| They don't sell it. But they entrust a lot of it to
| disreputable 3rd parties, who exist to track me all over
| the internet and then try to show me ads.
| OJFord wrote:
| But possibly only because they haven't yet added 'tech'
| to the hip abbreviation of their industry, and realised
| that data is valuable, possibly more valuable than
| whatever their actual business is?
|
| I think people use 'selling my data' as an (inaccurate,
| sure) shorthand for 'collecting so much data about me and
| I don't really trust them not to sell it at some point'.
| nerdponx wrote:
| Handing it over during company acquisition is a form of
| sale.
| cbm-vic-20 wrote:
| > In fact, an overwhelmingly vast majority of all
| businesses don't sell your data.
|
| That's because they haven't figured out _how_ to. Or at
| least how to do it to make it worthwhile.
| mcherm wrote:
| I used to think that was true. But these days, I think a
| huge portion of companies are placing advertising or user
| tracking software on their websites produced by
| advertisers or user tracking vendors who DO capture and
| sell the data.
| oblio wrote:
| Almost every mom-and-pop store sells your data to
| Facebook & co. That's what those fidelity cards are for.
| I didn't realize that either, until recently.
|
| Secondly, we're all doomed. I recently read an article
| about Amazon's ad division being as big as AWS and
| growing as fast, if not faster:
|
| https://www.ben-evans.com/benedictevans/2021/3/14/do-
| amazon-...
|
| If even AWS isn't bigger and isn't growing faster than
| ads, what hope is there, really, for someone trying to
| just sell stuff?
| l0b0 wrote:
| That's about three levels deeper than most users are
| comfortable navigating, and as such only a negligible
| fraction of users will ever see this setting, understand what
| it does, and change it. Too bad every enterprise solution
| defaults to HTML anyway.
| TheSmiddy wrote:
| Only a negligible fraction of users care about this feature
| and it only needs to be toggled once so it's clearly in the
| right place.
| sidpatil wrote:
| Most users probably don't care about HTML versus plaintext
| emails. The ones that do care would be the ones willing to
| pay $0.10 extra per month to enforce plaintext receipt, or
| willing to dig through a few levels of configuration to
| enable plaintext receipt.
| chrismorgan wrote:
| I wrote out the full path to it, but Preferences is the
| default page in Settings, and Reading and Compose & Reply
| are just sections inside it. So it's actually more like "go
| to Settings, click _Show advanced preferences_ at the
| bottom of the page, and search for 'plain'". And yeah, it
| is an advanced preference, whether you'd prefer otherwise
| or not.
| loh wrote:
| TricepMail has granular/heritable switching between plain
| text or HTML, with or without images. For example, if you
| have a mailbox set to plain text but receive an email that
| you would like to render as HTML, it's just one click away
| for either the entire thread or just that message.
| [deleted]
| [deleted]
| dethos wrote:
| I still prefer text-only emails. I block as much external content
| as possible and usually those marketing and elaborate designs are
| all broken. It is very rare that I allow exceptions.
|
| That being said, I can see the usefulness of this tool for
| developers, I just wish people would rely more on plain text.
| timvisee wrote:
| I love companies that send both HTML and plain text!
| Liskni_si wrote:
| ...as long as they contain the same content. I've seen e-mails
| where the HTML content is up to date, and the plain text part
| contains whatever was being sent a couple years ago, and hasn't
| been updated since then. Got me quite confused until I figured
| it out.
| Grustaf wrote:
| I wish people didn't use html at all for emails...
| sleavey wrote:
| First thing I do when I install Thunderbird on a new computer:
| disable HTML, enable monospace font.
| wiz21c wrote:
| Yeah, _receiving_ email in html format is painful. With text, I
| can look at them the way I want.
| simias wrote:
| I still only send plaintext myself, but clearly that ship has
| sailed. Many mailers don't even bother adding a proper
| text/plain alternative anymore.
|
| I caved in and replaced mutt with Thunderbird personally. Not
| only for properly displaying HTML, but it was a big reason.
| Thunderbird sucks massively for composing plain text emails
| though, and no simple way to integrate an external editor...
| rauhl wrote:
| > I caved in and replaced mutt with Thunderbird personally.
| Not only for properly displaying HTML, but it was a big
| reason. Thunderbird sucks massively for composing plain text
| emails though, and no simple way to integrate an external
| editor...
|
| Have you considered emacs with notmuch and the Gnus renderer?
| It displays most HTML emails well, and when it doesn't then a
| browser is just a quick '. b' away. And of course there's no
| need to integrate an external editor, because it's integrated
| _within_ the editor!
|
| As a plus, it is simply amazing how quickly one can search
| local email.
| jeroenhd wrote:
| I'm fine with HTML myself, actually; it's stuff like CSS that
| I'm more worried about.
|
| There are plenty of use cases for <li>/<h1>/<em> in emails, and
| with some nice default user styles they can give everyone a
| pleasant experience.
|
| Sadly, CSS is often applied and the HTML people write is often
| broken.
| Grustaf wrote:
| You say that, but then a couple of times a month i get emails
| from a certain cultural society that for some reason always
| come out with the main text in one giant, one letter wide
| column... Both on the phone and outlook webmail!
| ubermonkey wrote:
| How would you support formatted text in email, then?
|
| Please don't say "there shouldn't be formatted text in email."
| That's not a reasonable position.
| Grustaf wrote:
| I'm not saying it's reasonable, I'm just saying I would
| prefer it. I also would prefer websites without ads and
| social networks without arbitrary "community rules" but it's
| not going to happen.
| rauhl wrote:
| > How would you support formatted text in email, then?
|
| RFC 1896 specifies text/enriched:
| https://datatracker.ietf.org/doc/html/rfc1896
|
| And of course nowadays there is Markdown, which basically
| codifies a lot of earlier plain-text formatting conventions.
|
| > Please don't say "there shouldn't be formatted text in
| email." That's not a reasonable position.
|
| I don't know about that, really. We got by fine with plain
| text messages for decades, and the formatting conventions
| were good enough to convey meaning and nuance.
| breakfastduck wrote:
| We got by fine for thousands of years without computers at
| all
| cezart wrote:
| If by fine you mean the life style people had in the 12th
| century, I'll pass and stick with computers..
| jesusjosephsson wrote:
| I wish I could set up automatic replies to mails lacking plain
| text.
| emaillio wrote:
| great tool for emailgeeks!
| andrewmcwatters wrote:
| As a side note, I'm amazed that it's 2021 and there's no good
| mainstream email framework. Foundation ain't it, and MJML is a
| straight up non-option.
| chiefalchemist wrote:
| Mind you, I haven't used this in too long, but when I did I
| don't recall any issues.
|
| https://get.foundation/emails/zurb-stack.html
| justinator wrote:
| There's a big problem with Foundation for Emails right now -
| the Saas workflow requires Node v10, which is now
| unsupported. You can't easily start a new project. It's
| unclear if this will ever get fixed.
| urban_alien wrote:
| You should take a look at https://heml.io/
| saos wrote:
| I'd argue against frameworks and for providers to simply update
| the HTML and CSS they support. Its still bloody tables.
| drw85 wrote:
| I think HTML emails are unnecessary. It's only useful for
| advertising, marketing and tracking. If you want to show
| fancy css and design, link a website. If email was used as
| what it was designed for, writing electronic letters to each
| other and not spam and ads and marketing, we wouldn't have
| any of these problems.
| stjohnswarts wrote:
| I can't agree. I quite like html email. I just wish that it
| had an extremely cutdown subset (just colors, a few
| "header" sizes, italic, bold, underlined links), NO CSS
| allowed, no specifying of fonts other than say mono or
| "other". Maybe inline images links so that attached images
| could insert. No tables. Only <li> or <ul> Such a system
| would still be completely readable as plain old text. Now
| everyone thinks they have to use the kitchen sink approach
| or that there's not a middle ground.
| drw85 wrote:
| I 100% agree.
|
| I would love something like very simplistic markup,
| doesn't even have to be HTML. Just something to inline
| some images and differentiate text.
|
| Everything else is just horrible.
|
| I get so many emails with basically websites in them, but
| when you click on a product, the deep link is broken and
| you just end up on the storefront.
|
| I'd much prefer a small text that talks about the product
| and explains a few things and then a working link to that
| product.
| andrei_says_ wrote:
| Not a framework but I've found Ted Goas' Cerberus templates
| very useful.
|
| I customized them, extracted them into modules and created a
| design system which I then translated to an email CMS.
|
| Coverage is pretty good although Outlook still glitches in some
| circumstances.
|
| https://tedgoas.github.io/Cerberus/
|
| FWIW caniemail is unreliable and does not have full coverage.
|
| Also with this level of complexity I'd rather start with a few
| tested patterns than navigate the insane labyrinth of email
| client inconsistencies.
| andrewmcwatters wrote:
| Yep, I think we need more tools like this around.
| [deleted]
| hokumguru wrote:
| What's wrong with MJML?
| andrewmcwatters wrote:
| I don't want a framework to lie to me about what it is that
| I'm writing.
|
| I'm not interested in learning MJML. I'm interested in
| learning what subset of HTML and CSS email clients render and
| rasterize to.
|
| That's it.
|
| I'm sick of stupid developers shilling their software product
| that I'm suppose to build other products with.
|
| They do it with these cutesy photoshop/illustrator logos and
| dribbble crafted color schemes and drop in things like made
| with love in (city) in their README.mds on GitHub.
|
| I want tools, not someone's amateur marketing campaign.
| cameronh90 wrote:
| "I'm interested in learning what subset of HTML and CSS
| email clients render and rasterize to."
|
| Doesn't sound like you want a framework. Sounds like you
| want a book.
| andrewmcwatters wrote:
| Nope, plenty of CSS frameworks out there that don't try
| and make up their own tags.
| cameronh90 wrote:
| The thing about email is that renderers aren't even
| implementing the same spec. There is no common subset to
| learn. Every client implements some vague mess of
| 1997-era HTML/CSS mixed with different random modern
| features. Any attempt to try to write anything slightly
| advanced manually will drive you insane. Mail clients
| will mangle your code in ways you can't imagine. Every
| client will mangle it slightly differently. Even the same
| client on different operating systems will behave
| differently.
|
| Tools like MJML take a compiler approach to email. Why
| waste time trying to figure out how to implement a for
| loop in machine code and keep it updated every time a new
| processor comes out when you can just let the compiler do
| it?
| andrewmcwatters wrote:
| Take the top email clients and you'll sure as hell find a
| common subset. I don't want something slightly advanced.
| Emails are text and images. That it's. There's nothing
| advanced about that, and I'm not looking for it, either.
|
| The idea we need compilers for everything is idiot
| engineering.
| sbuk wrote:
| The very site this thread is about addresses exactly
| this. The tl;dr is look at what is supported by Outlook.
| cameronh90 wrote:
| If you just want text and images, you don't need CSS.
| Just the <img> tag - and even there you'll run into
| differences if you try and use the alt attribute.
|
| And even that isn't trivial. For example, say you include
| an basic black on white icon, what happens if the user is
| using dark mode? If the image is transparent, it becomes
| entirely invisible. If it's non-transparent then it's
| ugly (white box). If you want to make it change depending
| on dark or light mode, now you have to use responsive CSS
| which works entirely differently in different mail
| clients. What happens if the image is bigger than their
| viewport? Hint: it is different in different clients.
|
| And speaking of mail clients: one of the most popular
| mail clients is Outlook, which on Windows uses the
| Microsoft Word(!) HTML renderer and on Mac it uses
| WebKit. Gmail on web has its own HTML parser that outputs
| different HTML to what you wrote (and mangles your CSS
| class names). Apple Mail is probably the easiest to deal
| with.
|
| It's not worth learning this stuff if you don't have to.
| It will not benefit your life in any way. The common
| subset you want is text/plain.
| lights0123 wrote:
| https://maizzle.com/ does that--of course, you'll then have
| to deal with using tables to layout content manually
| instead of using MJML's abstractions.
| [deleted]
| 1123581321 wrote:
| MJML is abstracted from Mailjet's email builder. It's based
| on real-world HTML needs and the stuff it renders is pretty
| easy to read. You'll end up re-implementing something like
| it if you try to go simpler but have a lot of work to do.
|
| It's also easy to teach to designers.
| SilverRed wrote:
| >learning what subset of HTML and CSS email clients render
|
| You can use Table and all its related fields, span, h_, and
| p. Anything else is risky.
|
| For CSS you can set the font color and size. Setting a font
| itself is risky. Avoid using anything else including
| margins and padding as these largely don't work properly.
| multi layered tables are your margin and padding system.
| You also can only use inline styles. No classes, style tags
| or linked styles.
|
| Thats about it for email. Have fun.
| andrewmcwatters wrote:
| Great! Now document it, create a getting started
| template, some component snippets, and examples, and you
| basically have a project that I want in my toolkit.
| function_seven wrote:
| Not being snarky here: Isn't that what MJML is? It has
| components and examples and does all the nasty nesting
| table hacks for you.
|
| Asking because all I know of it is from their site. I
| have not used it myself. Does it have its own glitches
| that come along during the attempt to patch over other
| glitches?
| andrewmcwatters wrote:
| No, it emphasizes itself over standards, and promotes
| compiling beyond the scope of inlining CSS. That's enough
| to turn me off. It's self serving. It's not serving my
| needs.
| mattwad wrote:
| Why is MJML a non-option? It was a huge time saver for me.
| Combine it with react-mjml and you can get typesafe email
| templates that work in pretty much any browser. I managed
| templates by hand for a long time, and it took me a couple
| weeks to replace everything with MJML, but it was worth it.
| tailspin2019 wrote:
| I agree, I've had pretty good results using MJML now for
| several years (and I've been doing HTML emails since _almost_
| the 90's!)
|
| This is a problem area where a good abstraction framework is
| highly useful in my opinion.
|
| That said I don't specialise in email, it's something I do
| "when I need to". So if I was spending more time doing this
| sort thing, I might be more inclined to move down an
| abstraction level back to HTML/CSS and improve my knowledge
| of various client support.
|
| To just get the job done though, MJML is highly recommended.
|
| I see also a lot of mentions on this thread about replying to
| emails breaking the layout. Part of me thinks we're fighting
| a losing battle here anyway so there is a limit to how much
| time it's worth spending to make sure even replies are
| formatted nicely across all clients. But the other thing to
| consider is whether the email template is just trying to do
| too much.
|
| I try and keep my email templates very sparse, clean and
| simple and I generally haven't had too many issues with
| reply/forward formatting (that I'm aware of).
| Eupolemos wrote:
| I'm remaking my workplace's transactional emails these days
| (order confirmation, receipt etc. for an online shop - emails
| customers also reply to when stuff doesn't go as expected).
| We want something responsive for smartphones, but are
| primarily a B2B company.
|
| I made what they wanted with MJML. Looked good in a browser,
| gmail and phone.
|
| Outlook had a few issues, can't remember which right now.
|
| But replying from Outlook simply broke the styling
| completely. Gaps between each section, complete mess. Not the
| impression you want to give the customers when their order
| goes wrong. B2B means Outlook is what out customers use.
|
| I've found that replying via Outlook is the ultimate
| integrity test of an eamil.
|
| Now I'm making them by hand and it is a madening cargo cult
| bonanza. Takes a lot of time.
|
| I guess MJML is fine for marketing.
| iamacyborg wrote:
| > But replying from Outlook simply broke the styling
| completely
|
| This is an Outlook problem, not an MJML or even an HTML
| problem.
|
| If you inspect the HTML for the email sent vs what Outlook
| sends on a reply you'll see it has changed the code.
|
| Here's an excellent highlight of this bug
| https://www.hteumeuleu.com/2016/super-mail-forward-an-
| email-...
| Eupolemos wrote:
| > This is an Outlook problem, not an MJML or even an HTML
| problem.
|
| Though you are technically correct, I just don't think
| this is a constructive attitude. Half the job of making
| emails is working around (Outlook) bugs. This is just the
| annoying world email coding.
|
| If MJML is content ignoring Outlook bugs, MJML just isn't
| a satisfying tool for email makers.
|
| Sure, it'll get the job done for some marketing, but now
| the developer isn't learning skills that will make robust
| emails beyond that.
|
| Making robust emails becomes a completely separate
| skillset and the developer who chose to invest time in
| MJML will have to start all over learninging the
| necessary skills if he needs to make email you can
| actually reply to.
| iamacyborg wrote:
| > Though you are technically correct, I just don't think
| this is a constructive attitude.
|
| I've worked in email for a decade, you do what you can
| with the tools you've been given. An email will never
| look perfect everywhere and while I agree with the
| general sentiment you're talking about regarding folks
| learning proper email code rather than relying on tools,
| I also think the quality of emails sent is substantially
| higher now thanks to those tools.
| BiteCode_dev wrote:
| The end user doesn't know that, and doesn't care.
| iamacyborg wrote:
| Your boss is not your end user. The way your boss
| interacts with the emails you send is not the way your
| end users do. Optimising for your boss is not how this
| channel should work, though I appreciate there are a lot
| of bosses out there who don't understand this.
| oblio wrote:
| I don't understand your point.
|
| Are you complaining that his boss is forcing him to
| implement something that his end users can use?
|
| If so, why isn't his boss right?
|
| Personally, I'd say that yeah, he's supposed to work for
| his end user, why would he do anything else?
| iamacyborg wrote:
| My point is that, from the perspective of email, you
| frequently receive internal feedback that doesn't
| correspond to how users actually use email.
|
| For example, if the org uses desktop Outlook but < 1% of
| your audience does, is it worth optimising the email for
| that audience based on internal feedback?
|
| If someone notices that something weird happens when an
| email is replied to or forwarded, is that something worth
| acting on based on the real world frequency of that
| action?
| [deleted]
| dsr_ wrote:
| Can you not send lorem ipsum as the text/plain part of your MIME
| message? Please?
|
| I suppose "Your mail program is broken and can't read our
| message. Please go to this URL" is worse, though.
| _jal wrote:
| I actually appreciate them. Both are high-quality signals for
| "this is something I don't care about", so they're great for
| filters.
| l0b0 wrote:
| It's tempting to make shouldiemail.com and just answer "No" for
| all these features. Seriously though, it must be years between
| every time I see an HTML email which would not have been improved
| by being plain text.
| ChrisArchitect wrote:
| Love plaintext but meanwhile, even in tech, people are sending
| more newsletters than ever
| sevrinsky wrote:
| I typically compose all messages in Markdown and then convert
| that into rendered HTML. So if you believe in the
| expressiveness of Markdown (which I hope you do), then HTML
| rendering is absolutely necessary.
|
| Unfortunately, desktop Outlook is miserable with HTML support
| [1]. In particular, code blocks and quotes become an unreadable
| mess. The only way that I've found to include readable code
| blocks is to copy from VS Code, which somehow has the magic
| HTML combination that Outlook understands.
|
| [1] https://www.caniemail.com/clients/outlook/#windows
| jonathanstrange wrote:
| Why is it necessary? The whole point of markdown is that you
| may render it but it's also fine and easy to read when it
| remains plaintext.
| nxpnsv wrote:
| HTML e-mail fill an important function. If it's html, it's a
| promotion and it gets trashed...
| mro_name wrote:
| Html emails are as selfish and disrespectful like sneezing in
| other people's faces.
|
| For the sake of presenting marketing (Logos). Disgusting. Wear
| a mask, write text.
| Wilem82 wrote:
| I mean, how are you going to use rich text otherwise?
| jonathanstrange wrote:
| Nobody needs rich text.
| mro_name wrote:
| Homer didn't need rich text to write the Trojan War.
| Neither did Shakespeare, nor Ovid for their writing. My
| emails are way less ambitioned and are fine written in poor
| text.
| FredPret wrote:
| Almost every day, I find myself sending and receiving
| screenshots placed in context with some text and bullet points.
| Dare I say it: I love HTML emails
| Dylan16807 wrote:
| You're against bold, italics, underline? Headings? Any image
| support at all?
| dredmorbius wrote:
| Camel's nose, meet tent.
| beermonster wrote:
| You mean _bold_ , /italics/, and _underline_ ? Sure :)
| Dylan16807 wrote:
| Those are just ascii characters. You really don't want them
| to touch the font?
|
| (If your client interprets them, then you're not actually
| asking for plain text anymore.)
| dredmorbius wrote:
| If the client chooses to interpret them, then the point
| of control is where it should be.
| Dylan16807 wrote:
| We still want to standardize it, though, right? Instead
| of a dozen different ad-hoc interpretations of the same
| message?
|
| Making it unobtrusive enough to still look good when
| uninterpreted is a good goal. But that's very different
| from having nothing at all.
| dredmorbius wrote:
| There's a _very_ small set of text decorations which
| would suit virtually all cases.
|
| And there was a long history (about 100 years) of
| monospaced, mono-sized, typographic conventions based on
| typewriters and cheap reproduction (carbon paper, spirit
| duplicators, xerography), before the desktop-publishing
| era brought us out of that in the 1980s. The problem with
| formatting is that, like Johnny Rocco in _Key Largo_ ,
| someone always wants _more_ , and not for your benefit
| but theirs.[1]
|
| #ThisIsWhyWeCannotHaveNiceThings
|
| https://news.ycombinator.com/item?id=27114500
|
| In the Web world, counter to an argument elsewhere in
| this thread
| (https://news.ycombinator.com/item?id=27113404), my
| experience is that Web design isn't the solution, Web
| design is the problem. Straight ASCII text (via w3m or
| other text-mode browsers), or Reader Mode (where
| supported) is vastly preferable to many, many nines worth
| of sites' prescribed designs.
|
| One thought I've had is that user agents could provide,
| at user discretion, additional typographic control to
| sites. But for the basics you're limited to 7-bit (not 8)
| ASCII. Everything else is earned, and you'd best degrade
| _very_ gracefully.
|
| I've seen websites written where every individual
| paragraph has an explicitly-specified location. I've seen
| blogs written entirely in header-level tags. I've seen
| writers who add nonbreaking whitespace to the start of
| every paragraph. I've seen blink, marquee, and carousel
| abuse. I've seen foreground and background colours you
| wouldn't believe. Attack ships on fire off the shoulder
| of Orion....
|
| ________________________________
|
| Notes:
|
| 1. https://invidious.snopyta.org/watch?v=ITs-YX1yQ7o
| jonathanstrange wrote:
| I would be fine if my client would neatly format a
| limited markdown format and other clients supported
| entering it in a WYSIWYG fashion, as long as all the
| displayed content is part of the transmitted message (no
| further connection to the net) and the client is
| guaranteed not to execute any sender-supplied code or
| transmit any data when links or images are displayed.
| teddyh wrote:
| I think you meant bold, italic, and underline.
| lexicality wrote:
| Just a heads up that screen readers will tend to read
| sentences like that as "I think you meant MATHEMATICAL
| BOLD SMALL B MATHEMATICAL BOLD SMALL O MATHEMATICAL BOLD
| SMALL L MATHEMATICAL BOLD SMALL D comma MATHEMATICAL
| ITALIC SMALL I MATHEMATICAL ITALIC SMALL T MATHEMATICAL
| ITALIC SMALL A MATHEMATICAL ITALIC SMALL L MATHEMATICAL
| ITALIC SMALL I MATHEMATICAL ITALIC SMALL C and U N D E R
| L I N E" and so on which can be extremely unpleasant
| oblio wrote:
| I don't get why you're being downvoted. Every time
| Unicode support or rich text formatting comes up on HN
| someone wants to show off how "smart" they are.
| Dylan16807 wrote:
| "Showing off" that you know some screenreaders do the
| wrong thing is not any more "smart".
| oblio wrote:
| I got an almost identical comment when I said HN doesn't
| support any formatting, except for italic and link
| formatting.
|
| Inputting by hand (or maybe with a script - who cares
| anyway?) random Unicode characters to show that rich text
| is actually possible is the opposite of "smart" in a
| discussion between reasonable adults.
| lexicality wrote:
| I don't think you need to be so negative about this.
|
| Most people are unaware that Unicode has that kind of
| character and even fewer people know what it does to
| screen readers.
|
| The difference between showing off knowledge and trying
| to be show people a cool thing you know about is intent
| and it's REALLY hard to get that across on the internet.
| oblio wrote:
| > it's REALLY hard to get that across on the internet
|
| Agreed, that's why I like emojis, for example. They're
| whimsical, and they increase a bit the bandwidth of
| written communication.
|
| Alas, HN doesn't support them because of reasons
| -\\_(tsu)_/-
| teddyh wrote:
| > _I got an almost identical comment_
|
| Yep, that was me that time as well.
|
| > _Inputting by hand (or maybe with a script_
|
| I did it by hand. There are websites to do this, but I'm
| not interested in doing this for any regular purpose, so
| I don't think I have them saved. Besides, it's more
| interesting to do it manually; you learn things about how
| Unicode works if you involve yourself in the low-level
| details once in a while.
|
| > _the opposite of "smart" in a discussion between
| reasonable adults._
|
| Or maybe it's humorous? You know, fun?
| oblio wrote:
| > fun
|
| Fun?!? On my HackerNews?!?
|
| Burn the heretic!
| chiefalchemist wrote:
| Not sure about every HTML being plain text but I do wish I had
| $20 for every overly image heavy email that has no meaning what
| so ever unless I do "show images." Don't brands understand a
| fair number of ppl have their email client *not* display images
| by default?
| tomjen3 wrote:
| Unless you are using Mutt or similar I don't think anybody
| does not show images by default. I know thunderbird has no
| problem showing me images that are included in the email.
|
| Remote images are a crime, break the ability to search ofline
| or keep a record of ones conversation but they have one key
| advantage for brands which is to spy on you.
| slaymaker1907 wrote:
| My corporate Outlook email client does not show images by
| default if the sender is external.
| tomjen3 wrote:
| Even if those images are embedded in the email?
| opan wrote:
| Rainloop web client used by Disroot and some others
| defaults to not showing images and needs you to click a
| button to display them. IIRC Protonmail is the same in its
| webmail.
|
| The only non-web client I've used much in recent years is
| aerc, which is basically covered under "mutt" in this case.
| saurik wrote:
| FWIW, I just don't support HTML email and only for a small
| handful of services and senders do I ever get burned. If my
| email client did a pass over the HTML and gave me all the text
| followed by all the links that would be sufficient (right now I
| sometimes simulate that by opening up the raw MIME and grabbing
| what I need). Like, do we live in a world where this even
| matters? How is your life being made worse by people using
| these features? E-mail was explicitly designed in a way to
| support emails that have both HTML and non-HTML, and for people
| like us--"worst case"--the HTML can be stripped to text and it
| is fine.
| slaymaker1907 wrote:
| I disagree; while fancy stylings can be excessive, being able
| to use things like screenshots, headings, and tables is very
| useful. Sure you can do images and tables through attachments,
| but that adds extra steps which are inconvenient.
| tkzed49 wrote:
| Recently, I sent a longer-form announcement email and I think
| it really benefited from simple formatting. Headers that were
| visually distinct made it easier to parse, and in one place I
| set an image to float right which I felt made it less
| disruptive. I even set a max-width on the whole email, which
| I think works far better than the hard-wrapped text that some
| people write.
| zzo38computer wrote:
| I also prefer plain text email. HTML email is no good, I think.
| However, you can use a multipart message with a plain part if
| wanted; Heirloom-mailx and other plain text email clients will
| then display the plain text part in that case.
|
| You could specify "Content-type: text/markdown" if you want
| Markdown (although I don't know which email clients will
| understand that), although I think that plain text is OK.
|
| I also dislike email newsletters or email discussion lists;
| either way, I would prefer NNTP.
| cookiengineer wrote:
| Honestly I'm using Thunderbird only because of two things:
|
| - Plain Text Mode
|
| and
|
| - uBlock Origin Extension is available (that can block also
| embedded JS)
|
| People underestimate the attack vector of emails. I'm glad
| those scammers haven't figured out (at least until now) how XSS
| could work in Gecko with XUL. Heap spraying could easily be a
| thing, given that MS Outlook also still uses their outdated
| rendering engine.
| mrweasel wrote:
| For most regular emails and newsletters I would agree. Those
| who truly care to know which HTML and css tags are available in
| email client are sending some for of ad.
|
| Say you're a webshop and a customer has signed up for you
| "newsletter" then you kinda need HTML emails to show your
| advertised product directly in an email client.
| Mandatum wrote:
| Anything that's more visual than function, like fashion or
| trendy design - text is a waste of time.
|
| Email serves every type of business, yes more could be just
| text - but some will never be served by that format.
| swiley wrote:
| Anything more visual than function shouldn't be clogging up
| my inbox.
| SilverRed wrote:
| What the average HN user and the average user want is worlds
| apart. The average person likes their emails to be nicely
| designed like a website with blocks of colour and the site
| logos.
|
| When they see a plain text email from a site they would be more
| likely to think they are being scammed than to be impressed at
| its simplicity and ability to display in the terminal.
|
| When every website is hacking around broken table layouts to
| get them to render in outlook (essentially Word), something is
| wrong and should be fixed.
| badsectoracula wrote:
| How do you know that is what the average person _likes_ or
| what they think? Are there any studies for these?
| iamacyborg wrote:
| Emails are incredibly easy to ab test given a sufficiently
| large audience size.
| lstamour wrote:
| > Now, with the emphasis on imagery across the web, users
| strongly preferred images that could be seen full screen or
| at a larger scale, looked high-quality, and showed detail
| clearly.
|
| https://www.nngroup.com/articles/newsletters/ (2017)
| MereInterest wrote:
| That article seems positively rife with weird
| assumptions, all to present email marketing in a
| favorable light. It's bad enough that I don't really
| trust the quote you gave from it.
|
| > Because several of these constraints have been remedied
| over the years, many of the concerns that users had about
| subscribing have disappeared.
|
| Read: Because we stopped asking permission and instead
| started spamming everybody who gave us their email
| address, people stopped thinking that not subscribing had
| any effect.
|
| > The increase in sheer email volume over the years has
| created a scenario where people can't possibly give all
| messages their full attention, so they care less about
| what they receive because they know they can easily
| ignore the noise or choose what they invest their time
| in.
|
| Read: Our entire industry spams people so much that
| people know it's not worth reading.
|
| > It's no longer used strictly to describe unsolicited
| email messages. Participants in our study used the word
| "spam" to describe solicited marketing emails that they
| considered random, impersonal, irrelevant, with too much
| promotional hype, or coming in high volume.
|
| Read: We required an email address for things that don't
| need one, then treated that as permission. How dare
| people consider our spam to be spam?
|
| > Now that organizations are required to include an
| Unsubscribe link in their newsletters, this task has
| become easier.
|
| If a company assumes that an email address given for
| identification can be used for marketing, or that it can
| be shared with third-parties/affiliates for marketing,
| then they are already pretty shady. I honestly have no
| way of knowing whether it's an actual Unsubscribe link,
| or whether it's a signal that the email address is
| actively read by a human and so should receive more spam.
|
| > If users keep getting unwanted newsletters, the
| messages will start to backfire and become regular
| reminders that they're annoyed with your company. Better
| to let them go.
|
| This part I do agree with. Better still would be to not
| assume permission to send marketing to somebody just
| because there was a pre-checked both on a form.
| markkanof wrote:
| I'm not the person you are responding to and I'm also a
| software dev (ie. not the average user), but I prefer a
| nice looking email that includes some simple graphics and
| formatting. So that's at least one person that prefers that
| kind of thing to a plain text email and I'm pretty sure I'm
| not alone. I think we can probably agree that there is a
| large subset of the population that likes "nice looking"
| websites, so why would emails be different.
| smsm42 wrote:
| But do they really? Most those "nicely designed" emails, to
| be honest, are spam. Either outright spam, like v14g4 and
| p3n1s pills (modern mail systems deal with those well
| enough), or only slightly more respectable spam like "you
| bought in our store once, so now we will hound you forever
| with ads for our good and services that you don't need
| anymore".
|
| Among this sea of garbage, there are rare islands of useful
| updates - like genuine newsletters I subscribed to, or email
| from my doctor about test results, or reminder from my bank
| that they are going to deduct that car payment, whether I
| like it or not, so there better be money there, etc. And of
| course Amazon shipping notifications! If all those need any
| HTML, then only the most rudimentary one.
|
| Of course, if you asked a user whether they'd want to get
| ugly marketing spam or beautiful one, I guess they'd choose
| the beautiful one. But that's not the right thing to ask.
| [deleted]
| azernik wrote:
| This is absolutely not my experience. Spam uses HTML
| formatting, sure, but it's not "nicely designed".
|
| "Nicely designed" emails are things like flight
| confirmations, invoices, shipping notices, and that kind of
| transactional email. The common thread is that some entity
| with Real Money To Spend on a graphic designer is sending a
| (usually form) email to lots of people. Most spam outfits
| do not have those kinds of resources, especially since they
| need to change up their emails constantly to avoid spam
| filters.
|
| The closest I would say that the "pretty" stuff gets to
| spam is newsletters and particularly political fundraising
| emails; I'm on a lot of political party lists after
| spending copious college free time working on campaigns.
| TeMPOraL wrote:
| The common thread about those non-spam transactional
| e-mails you mention is also that they're usually barely
| above plaintext. They usually contain some minimally
| styled table, and some of the company colors. Maybe their
| logo somewhere. That's in stark contrast from the _spam_
| these same companies send, which is where all that "Real
| Money To Spend on a graphic designer" goes. Compare e.g.
| the spam PayPal sends you vs. the e-mails confirming
| payments you've made. In my experience, this is pretty
| universal.
|
| And speaking of universal heuristic, in my experience,
| the quality and relevance of content is strongly
| inversely correlated with the quality of design. The
| prettiest websites out there are ones that deliver
| negative value. The best designed (according to modern
| trends) user interfaces are the ones with worst ergonomy,
| wasting user time the most.
|
| And yes, the subset of spam that's most recognized - ED
| pills, reproductive organ enlargement, members of royalty
| looking for help managing their finances - they tend to
| be very simply designed. But their distinguishing feature
| isn't _simplicity_ of design. It 's the _carelessness_.
| Typos, bad grammar, highly visible formatting mistakes,
| etc. When, on occasion, one of that "old school" spam
| messages tries to pose as a legit transactional e-mail,
| you can see through the deception by noticing the
| carelessness in replicating the design of the company
| being impersonated.
| cerved wrote:
| yes, they do
| jjav wrote:
| > Most those "nicely designed" emails, to be honest, are
| spam.
|
| Indeed. The number of HTML elements in an email scales
| pretty linearly with the probability of it being spam.
|
| Plain text is almost 100% certain not spam.
| yakubin wrote:
| Unless it's from a Nigerian prince.
| kureikain wrote:
| I run an email forwarding service[1] so I deal with spam
| a lot.
|
| Spam usually has bad formating, mixed charset, old/broken
| layoyt etc.
|
| Most of time, spam are odd designs. Example they only
| have HTML and didn't have the corresponding plain text
| part. They have large pictures and too little text, they
| have many "invisible" part so that hide behind element to
| trick you to click the wrong thing.
|
| Even in plain-text, spam tend to include random links,
| very long text, weird chracter etc
|
| A nicely design, or a plain-text emails(only plain text)
| with nice format all are good signal of non-spam.
|
| In other word, consistency is signal of non-spam emails.
| But sometime marketing emails-which you never explicitly
| subscribe to, you just register for an account and got
| marketing emails, can also be consider spam, but from
| google/hotmail point of view they don't consider these
| are spam and that's reason they have Promotion tab to put
| thing in there
|
| ---
|
| [1] https://hanami.run
| mijamo wrote:
| My experience is opposite. I have never received a scam
| email with HTML, is always plaintext that tried to mimic
| a regular conversation.
| stjohnswarts wrote:
| You must have a hell of a spam filter.
| SirHound wrote:
| A quick scan of my inbox and spam folders would refute
| this
| saagarjha wrote:
| I just looked through my Junk folder and it took me about
| 30 seconds to find an email that was sent as plain text.
| Most of this time was spent digging through Mail's menus
| to figure out how to show the raw message.
| zaarn wrote:
| That is completely antithetical to my experience as mail
| server operator and someone who gets a lot of spam.
|
| Nearly 100% of spam is plaintext, a small fraction uses
| badly designed HTML that barely displays in the client.
| tesseract wrote:
| This may come down to whether you consider marketing
| email from legitimate businesses to be "spam" or if you
| reserve the term for the more scammy/seedy type of mail.
| zaarn wrote:
| I unsubscribe from marketing mails, those are legally
| required to have an unsubscribe link in them. You should
| try clicking on that if you don't like marketing mail. If
| they don't stop you can threaten legal action in both EU
| and US without issue.
|
| If it doesn't have this link, it's spam. If it's trying
| to get me to buy something I didn't explicitly wishlist
| on a store, it's spam. If it's unsolicited marketing,
| it's spam.
|
| And even if I were to include all marketing email,
| including those I am interested in, then plaintext mail
| would still constitute the majority of spam mails I
| receive.
| jonathanstrange wrote:
| I personally found out that it's easier and faster to
| train my spam filter to move these mails into the spam
| folder. (I'm using claws-mail with bogofilter, which
| works quite well.)
|
| Whenever I have to interact with a company, I check the
| spam folder for their replies.
|
| The majority of mails in my spam folder is html mail.
| zaarn wrote:
| The majority of mails in my spam folder is plaintext
| mail. Second place are the extremely malformed HTML
| mails. Almost any wellformed HTML mail I receive is
| solicited at minimum.
|
| I can recommend using the unsubscribe link if you forgot
| to uncheck the newsletter checkbox during registration.
| Alternatively send them a mail to A) remind them of the
| SPAM-CAN act or your local equivalent legislation and B)
| that they should delete your mail from the newsletter.
| That works almost always, if not you can always threaten
| legal action (where I live, that's an easy 600EUR of
| profit in a courtroom).
| stjohnswarts wrote:
| It's safer as well. Some (most?) of those "unsubscribe"
| links have a unique ID hooked in with your email in some
| database so they know that they have a hit and can send
| more email to you.
| zaarn wrote:
| Well, they need something to be able to tell which email
| to remove from their DB too.
|
| Not all is as sinister as it looks.
|
| The simply solution is to just can any senders that don't
| respond to unsubscribe requests. But those will be just
| as bad in plaintext as in HTML, so I don't see why
| Plaintext means it's not spam, they can do the same thing
| Plaintext.
| varjag wrote:
| Any unsolicited marketing is spam, unsubscribe link or
| not.
| zaarn wrote:
| That's... what I said. I mentioned the unsubscribe link
| for solicited marketing mails, where that is in fact
| relevant. Unsolicited email would be pretty damn illegal
| in my home country to begin with (and a GDPR violation).
| jeltz wrote:
| It is illegal but very common. Many of those emails with
| unsubscribe links are unsolicited. They either spam all
| their former customers no matter if they have opted in or
| not or they just buy links. Yes, the unsubscribe links
| work but what they do is in obvious violation if the gdpr
| and other laws.
| FredPret wrote:
| I have a feeling that they are, in fact, solicited.
| There'll be fine print and a checkbox somewhere
| varjag wrote:
| Tricked into subscription with dark patterns is not quite
| the same as soliciting.
| zaarn wrote:
| Very few companies would risk those lawsuits, especially
| in Europe the fines can get rather exponential for repeat
| violators and I don't think it's much different in the US
| either. If the unsubscribe works, that is the end of the
| story for me, and a reminder to check for small
| newsletter checkboxes when signing up to things.
|
| I very rarely get marketing mails from any reputable
| company that are completely unsolicited. In most cases
| it's a followup from trying out an offering or updates to
| products I'm using or are adjacent to those. If I'm not
| interested, I either ignore them or unsubscribe if it's
| repeatedly not interesting.
|
| This is a much more effective "spam" strategy compared to
| "all HTML is spam".
| citrin_ru wrote:
| Spam sent to different domains (especially in different
| TLD) tends to be different so experience can be
| different.
|
| In my observations badly formatted spam exists, but have
| big intersection with the spam which is relatively easy
| to filter out. Nicely formatted HTML spam on other hand
| is hard to filter because the only difference with
| legitimate marketing email is lack of any consent from
| the sender. Sure I can hit an unsubscribe link and my be
| never will get spam from the same domain again, but
| spammer will know that this email is active and will
| include the address in spam send on behalf of other
| customers.
| zaarn wrote:
| Well, that is where the line of solicited and unsolicited
| mails fall, spammers are generally unsolicited (so no
| previous mail address confirmation), their unsubscribe
| links won't work and >90% of them are plaintext with the
| remainder having bad or illformed HTML. 99.8% of
| marketing mails I get have an unsubscribe link that works
| because it forgot to uncheck the newsletter when signing
| up, those are not an issue. And those are usually HTML
| mails with well formed formatting.
| [deleted]
| sloby11 wrote:
| I'm pretty sure that this comment was sarcasm
| TeMPOraL wrote:
| > _What the average HN user and the average user want is
| worlds apart. The average person likes their emails to be
| nicely designed like a website with blocks of colour and the
| site logos._
|
| Do they? Do they really _like_ it? Did anyone _actually
| asked_? And no, A /B testing your design's capability to
| trick the user into paying you money isn't measuring whether
| they like it or not.
|
| I have an alternative proposal: average user just accepts
| what they're given, because they have no other choice. Nobody
| listens to their opinion (again, tracking and telemetry is
| not the same as listening to people). Abusive designs and
| patterns are adopted industry-wide very quickly, so there's
| rarely an opportunity for the user to vote with their wallet
| - after all, they can't choose something that's not available
| in the first place. On top of that, the average user lacks
| the mental models and language to conceptualize _what_ is
| wrong and _how_ much better technology could be if it was
| slightly less abusive. All they can do is accept that
| computers are annoying, and casually complain about this to
| friends and family.
| oblio wrote:
| Users want nice shapes and color.
|
| There's a reason the most popular media is video and images
| and the main social media platforms are practically
| platforms for sharing video and images.
|
| The average person all over all the world is almost
| functionally illiterate (literacy level of a middle
| schooler or maybe high schooler, at best). They really,
| really don't want text. They'll only read as much as they
| have to, and they will definitely choose images over text
| if they can.
| watwut wrote:
| > Do they? Do they really like it? Did anyone actually
| asked?
|
| Oh yeah, they do like it and want it. That is why they use
| it. And yes, I talked with a guy who was literally like "I
| like the emails colorful and such, but we found through
| testing developers respond better to plain, so I send plain
| to them".
|
| Sometimes we are the odd ones and that is ok.
| libertine wrote:
| I don't even think it's a matter of liking or disliking,
| but more a matter of being blind to the standard formatting
| (something that most deal with on their jobs).
|
| At the end of the day if you see another blob of text, you
| either skim through it looking for what matters or you just
| delete/archive it.
|
| They could even hate it, but it just stands out for better
| and worst.
| kevsim wrote:
| Fully agree. When we launched our service, we used really
| simple plain text mails and we had users complaining that
| they looking unprofessional and spammy. We didn't go crazy
| with our email design, and we're certainly not pushing the
| limits of what's possible to use in an email, but just adding
| a bit of color, a log and some text formatting made a big
| difference. Haven't heard a complaint since.
| Jiocus wrote:
| _Beauty is no quality in things themselves: It exists merely
| in the mind which contemplates them; and each mind perceives
| a different beauty. One person may even perceive deformity,
| where another is sensible of beauty; and every individual
| ought to acquiesce in his own sentiment, without pretending
| to regulate those of others._ - Hume, D
|
| SS https://plato.stanford.edu/entries/beauty/#ObjSub
| cwhy wrote:
| A commercial project aims for profit, not public service.
| The previous post explains why they are popular demands.
| And it is natural for commercial project to satisfy popular
| demands.
| dredmorbius wrote:
| QED: Beauty [?] Profit
| OptionX wrote:
| Thats what the average web dev _thinks_ the average person
| wants.
| brutal_chaos_ wrote:
| And thus is what people have come to expect, sadly, IMHO.
| Except for the technically inclined/HN userbase. Though
| another comment said Germans prefer plaintext emails w/o
| attachments.
| zaarn wrote:
| Wouldn't say that is entirely true. Germans prefer HTML
| mail that amounts to simple rich text, ie bold and italic
| fonts, possibly some color highlighting if you're really
| daring. Pure plaintext isn't that well appreciated.
| iamacyborg wrote:
| > Except for the technically inclined/HN userbase.
|
| This community is as much an echo chamber as anywhere
| else. Just because an opinion is common here doesn't mean
| it's correct or reflects the wider population.
| [deleted]
| GuB-42 wrote:
| I looked at the mail I really wanted to read from the most
| reputable entities (banks, government, business
| partners,...). Usually there is a logo at the top and the
| rest is mostly plain text with minimal formatting. A nice,
| colorful email, sometimes from the same companies usually
| mean one thing: ad.
|
| This is no different from snail mail, where important
| communication is usually on standard white paper while ads
| are high quality prints on nice goossy paper.
|
| And obviously, "average users" notice the pattern. Just like
| my father who almost trashed an important tax-related mail
| just because it looked too nice, he thought it was an ad.
|
| So the "average user" prefer to see nice _ads_ , I can get
| that. But what the average user really prefers no ads at all.
| na85 wrote:
| >The average person likes their emails to be nicely designed
| like a website with blocks of colour and the site logos.
|
| I really don't think that that's true.
| jgwil2 wrote:
| This isn't an argument, it's merely contradiction!
| bosswipe wrote:
| Both the assertion and the contradiction are equally
| baseless.
| dredmorbius wrote:
| No it isn't!
|
| https://invidious.snopyta.org/watch?v=xpAvcGcEc0k
| varjag wrote:
| From what I've seen from average user, they tend to struggle
| pasting text with the same font into their email reply,
| struggle to quote parts of the message or email hyperlinks in
| usable manner.
| door101 wrote:
| > What the average HN user and the average user want is
| worlds apart. The average person likes their emails to be
| nicely designed like a website with blocks of colour and the
| site logos.
|
| Taste is generated. Cool trendy startups make "nicely
| designed" emails, users come to expect that. If scam emails
| looked "nicely designed" and Google sent emails in plaintext,
| the "nicely designed" emails would be considered
| untrustworthy. As a counterpoint, an "average user" wants
| software to work, and forcing every email client to parse
| HTML (which is far outside the scope of what an email client
| should do, especially with html as complex as it is today)
| often breaks things in unexpected ways.
|
| In my opinion, html and plaintext are both inappropriate for
| email. HTML is far too complex, and plaintext is a bit too
| simple. I think a markdown-like syntax would be the best
| balance, but I'm pretty sure that ship has sailed.
| kccqzy wrote:
| You'd love enriched text then:
| https://en.m.wikipedia.org/wiki/Enriched_text
|
| As far as I know, only old (possibly pre-Tiger) Mail.app in
| Mac OS X used to produce it.
| door101 wrote:
| This is cool, I may have to play around with it
| roydivision wrote:
| I posit that the average user doesn't want to put the time
| into reading plain text to find out if the email is worth
| their attention, images and colours are easier and quicker to
| process. A lot of information can be communicated quickly
| with some photos and a nicely formatted graphically rich
| message, probably with a large link button that takes the
| user to a relevant web page for further engagement.
|
| This is not an endorsement of the practice, just an
| observation.
| userbinator wrote:
| One oddity I've noticed is that Germans seem to like their
| emails in plain text, and without any attachments:
| https://news.ycombinator.com/item?id=15226022
|
| I've corresponded with others, also German, and they had the
| same preferences, even if not as explicitly stated as the
| examples in my other comment there.
| Semaphor wrote:
| We used to have our German newsletter available in plain
| text and styled. The vast majority of people chose the
| styled version. Not even 1 % picked text. No dark patterns
| involved, a simple radiobox. We do not offer the text
| version anymore.
| donio wrote:
| The GNKSA was the real deal. It was for Usenet but a lot of it
| applies to email too.
|
| https://web.archive.org/web/20160417105503/http://www.gnksa....
| gumby wrote:
| What's lame is when there is no plaintext alternative. A clear
| sign of someone who does not wish to communicate with me.
| tomjen3 wrote:
| If it was sent personally to you by somebody who knew your
| preference you might be right, but realistically the number
| of people who cares or who have any issue with HTML mails is
| going to be sub 0.1%, so it is almost certainly more a case
| of don't care, not worth considering.
| codetrotter wrote:
| > What's lame is when there is no plaintext alternative.
|
| Or worse yet, when the plaintext alternative version is
| broken/incomplete.
|
| I regularly receive mail where the plaintext alternative
| version has templating variable names instead of actual
| values, where the html version has the values.
|
| Also, systems that send mail where the plaintext alternative
| version is only something along the lines of "Your email
| client does not support HTML. Please read this newsletter at"
| and then a link. But of course, my client can read html too,
| I just have it set to view the plaintext version by default.
|
| One of these days I will probably just set it to always
| prefer the html version instead. I use mutt, with elinks
| taking care of html to plain text conversion. I've been
| running my mail server for years.
|
| But anyways it might soon be time for me to switch to hosted
| mail. I have a provider in mind.
| upofadown wrote:
| It at least implies a certain lack of technical expertise on
| the part of organizations that send such HTML only emails.
| The same for when they put completely unformated garbage in
| the text part. If W3M can do a better job starting with their
| HTML email you have to ask yourself why they couldn't of done
| at least that instead of whatever they did.
| citrin_ru wrote:
| Sometimes plain text alternative is so bad that one forced to
| use HTML version anyway. I've tried plain text emails in
| Atlassian Jira settings - emails it sends are badly formatted
| and have lots of empty lines, likely they make plaintext
| version from HTML one with something like `lynx --dump`.
| MayeulC wrote:
| Wouldn't that end up being a variation of
| https://useplaintext.email/ ?
| greyhair wrote:
| There is nothing I hate more than rich content email.
|
| Send me plain text email.
|
| Add attachments that I can scan for issues before I open them.
|
| If you send me links, I will be very wary of visiting them
| outside a sandboxed tab. I will not 'click through' from the
| email client.
| kleer001 wrote:
| > If you send me links, I will be very wary of visiting them
| outside a sandboxed tab.
|
| I got a link to re-up a certain type of account from my bank.
| It was very odd, I was quite confused.
| mnx wrote:
| Only 50% support for <marquee>? Where is this world going.
| jorangreef wrote:
| Another way of looking at this scoreboard is as an approximate
| inverse ranking of webmail client security and leak vectors, with
| Gmail stripping far more dangerous elements than most webmail
| clients.
|
| This is actually a great tool to find vulnerabilities in various
| webmail clients such as ProtonMail and Hey, just compare the HTML
| or CSS features they do not yet filter compared to Gmail, then do
| a search for "[feature] + exploit" to see how a feature could be
| abused, and then submit a bounty report.
|
| For example, there are alot of good reasons that you may not want
| your webmail rendering SVG images (mXSS, appcache poisoning) or
| allowing CSS variables or imports.
|
| And I'm pretty sure the list supported by Gmail could also be
| narrowed down further. There are some fantastic bounties lurking
| in here, just waiting to be discovered.
| defaultname wrote:
| So discover them. Roll in your piles of cash from those easy
| picking bounties. Prove your point because otherwise it seems
| like a rather lazy claim.
|
| Somehow I think it is significantly harder to actually do.
|
| The position itself seems like sophistry: Was Internet Explorer
| the most secure browser when it was obsolete dogshit that
| supported little?
|
| These "more/newer is scary and dangerous" positions appear on
| literally everything, always, and they're always based on a
| wink and innuendo. But I would posit that gmail supports little
| because it's overwhelmingly dominant and they simply don't
| _have_ to. Gmail has little market pressure to do much of
| anything.
| jorangreef wrote:
| > So discover them. Roll in your piles of cash from those
| easy picking bounties. Prove your point.
|
| Sure, I already did. I earned the second highest bounty for
| Fastmail back in 2019 for exactly this kind of exploit. Since
| then I've reported to dozens of programs (OpenSSL, ClamAV,
| SpamAssassin, ProtonMail, Hey, Missive, Yahoo Mail, Yandex,
| Spark, Trello, Missive, AWS, Google Chrome) and rolled in a
| few tidy piles.
|
| I have also written various pieces of open-source software
| that would have detected and prevented four separate zero-
| days, affecting Microsoft (and almost every AV engine,
| browser, and zip parser) [1][2], Gmail [3], Apple Mail [4],
| and countless open-source email servers [5].
|
| Now it's your turn.
|
| [1] https://github.com/ronomon/pure
|
| [2] https://www.usenix.org/conference/woot19/presentation/fif
| iel...
|
| [3] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-
| hid...
|
| [4] https://mikko-kenttala.medium.com/zero-click-
| vulnerability-i...
|
| [5] https://snyk.io/blog/how-to-crash-an-email-server-with-a-
| sin...
| defaultname wrote:
| I'm not quite sure what flaws in attachment handling/zip
| bombs [literally one of the oldest and most rudimentary
| features] and another to do with UI encoding has to do with
| this post. Neither have _anything_ to do with advanced HTML
| support.
|
| Software has bugs, story at 11. Should they have banned
| attachments as too scary and new?
|
| That is a completely orthogonal bit to claim authority and
| "win". And it will probably work on many (citations, even
| if wholly irrelevant -- as these are -- are a magic pixie
| dust on HN [1]). Weird.
|
| 100% of the time that someone claims something is _easy
| money_ , their claim is, shall we say, "dubious". It's
| noisy bluster.
|
| Your Fastmail bounty [2] is impressive and kudos, but again
| it looks like it has to do with Fastmail's implementation
| details to support offline use.
|
| [1] https://news.ycombinator.com/item?id=26264378
|
| [2] https://news.ycombinator.com/item?id=13099966
| [deleted]
| defaultname wrote:
| I would love to know the logic as to why my comments were
| flagged. I'll happily take every misinformed, foolish
| downvote from the Luddite crew, but flagging? Give me a
| break.
| fouric wrote:
| Probably because that comment, like this one, goes
| against not just one, but several of the HN guidelines:
| https://news.ycombinator.com/newsguidelines.html
| defaultname wrote:
| Which guideline does it go against? Can you name even
| _one_?
|
| The Luddite "ooh this is scary" posts always do well on
| HN. People are allowed to disagree. When someone cites
| completely and utterly irrelevant authority on the topic,
| it just betrays that they're playing the crowd. Amazing,
| albeit sad, how well it works here.
| schoen wrote:
| This reminds me of the classic "Did you win the Putnam?"
| thread. :-)
|
| https://news.ycombinator.com/item?id=35079
|
| Thanks for your work on e-mail security!
| defaultname wrote:
| And everyone cringed.
|
| Your are either profoundly gullible, or completely out of
| your area of expertise.
| jorangreef wrote:
| Wow, thanks Seth!
| felixfbecker wrote:
| Curious, what's the risk with SVG, assuming a CSP is used for
| it that doesn't allow anything (including no scripts)?
| jorangreef wrote:
| SVG is a minefield so massive it's hard to give an exhaustive
| list of everything that could go wrong. Especially when these
| kinds of assets might be hosted on user content domains and
| where webmail clients might allow access to the SVG content
| with inline disposition but outside of an IMG tag (most
| browsers enable/disable various SVG features such as JS or an
| app cache manifest according to context). There are also a
| ton of weird rendering modes that can be triggered for SVG
| (or MathML) and these can be used to bypass XSS sanitizers by
| means of mXSS which exploits differences in browser
| renderings when roundtripping content.
|
| And sites with strong CSPs are often especially vulnerable to
| scriptless attacks, perhaps because they feel more protected.
| For example, in 2019, there was a bug bounty disclosure to
| Fastmail about a way to intercept and proxy all email
| attachment downloads, completely client-side, and yet without
| involving any JavaScript, simply using HTML5 AppCache. This
| also affected a whole lot of other providers, but the
| Fastmail team patched this within 24 hours, a pretty amazing
| response, and the quickest by far.
|
| Here's a fantastic paper from Mario Heiderich (of Cure53)
| from 2012 on various kinds of scriptless attacks: https://cit
| eseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46...
| Pxtl wrote:
| I've said it before, I'll say it again: the web needed a
| vector answer to jpeg, but what we got was a vector answer
| to html+css with all their commensurate vulnerabilities and
| complexities.
| whatshisface wrote:
| The other major web vector format...
|
| is PDF. Yeah, PDF has drawing commands. Most vector
| formats are based on command sequences, that map 1-1 with
| what you'd find in a drawing library like Cairo. EPS and
| PDF both work that way, which makes it even more of a
| typical vector format than SVG (which only does the
| command sequence thing with paths, AFAIK). Of course,
| it's not that well supported (the in-browser reader does
| who-knows-what to get it to render, I think it's
| converted to DOM elements), but it _is_ the other major
| browser-supported vector format.
| jb1991 wrote:
| I'd love to know where FastMail ranks on here.
| jorangreef wrote:
| Fastmail's security is top notch. They're using Cure53's
| DOMPurify and their team understand these vectors really
| well, with strict filtering. Their pixel tracking blocking
| was better than Hey's when last I checked, and I reported
| three leaks to Hey that were not fixed for some time.
| Fastmail also run one of the best bounties I have ever
| participated in. I would even say significantly better than
| ProtonMail, having participated in both bug bounties.
| alvarlagerlof wrote:
| This makes me happy I chose it
| darkwater wrote:
| Nice to hear that, I'm a Fastmail customer and the Android
| up is subpar on offline access (or unreliable connections,
| looks like it's basically hitting the network for
| everything. Knowing that at least security-wise it's a good
| product makes me happier.
| noneeeed wrote:
| What are the advantages of using FastMail's android app
| over a normal mail client? I'm thinking of moving to
| Fastmail from Gmail.
| stevehawk wrote:
| _shrug_ dunno what other mail clients have but I 've used
| Fastmail's email client for over a decade and never
| thought "wonder if someone else's is better".
| paxys wrote:
| What standard/RFC does this site pull from? The list of features
| a client is expected to support seems to be pretty arbitrary.
| edoceo wrote:
| Its arbitrary cause there is no RFC about the ah-hoc choices
| email client softwares have made over the years that have kinda
| become de facto "standards"
| Forge36 wrote:
| https://github.com/hteumeuleu/caniemail
|
| This is specifically focused at HTML specs/features, and a fork
| of https://github.com/Fyrd/caniuse
|
| Targeting HTML rendering engines which are email clients.
|
| Fortunately (at least for some of the newer features to be
| included) Links to MDN are available, and caniuse both link to
| we spec). CSS min for example is working draft.
| https://www.w3.org/TR/css-values-4/#math-function
|
| With 90% desktop/mobile browser general usage support, 50%
| email usage support.
| azernik wrote:
| AFAIU this is a fork of caniuse.com; the features it tracks are
| probably a strict subset of those.
|
| The feature definitions seem to be maintained manually, at
| https://github.com/hteumeuleu/caniemail/tree/master/_feature...
| assuming it follows the caniuse.com community model,
| information about supported browsers is similarly crowdsourced.
| ipaddr wrote:
| I've been using thunderbird for probably 15 years and have
| forgotten about html emails. I can imagine they are popular but
| it is probably the great fishing surface the average user is
| exposed to.
| kilodeca wrote:
| https://useplaintext.email/
| unlimit wrote:
| I could not even understand what the site did. :-(
| PostHeat wrote:
| This seems pretty useful. I'm actually working on a project right
| now (https://postheat.com) to automate all the styling and html
| for devs and I've had to learn most of this the hard way...
|
| I think you need some example search b/c I was not sure how to
| use the tool at first.
| strenholme wrote:
| I made the mistake of giving too many companies my email address
| when those stupid black-the-page popups come up asking for my
| email. I am in the process of unsubscribing from every one of
| those emails; there is usually a small "unsubscribe" link at the
| bottom of them, and they are usually pretty good about honoring
| unsubscription requests.
|
| These days, I disable Javascript on any site which has the
| audacity to put a popup in the middle of the page as I am reading
| it. Any site with is not readable without Javascript is one I
| leave and don't go back to.
|
| The kinds of sleazy outfits which do not honor unsubscribes are
| the kinds of places email providers are really good about black
| listing.
| dang wrote:
| One past thread:
|
| _Can I Email: 'Can I Use' for email_ -
| https://news.ycombinator.com/item?id=20948826 - Sept 2019 (196
| comments)
| [deleted]
| azernik wrote:
| Oh I wish I'd heard of this 2 years ago, would have saved me a
| lot of trial and error.
| danellis wrote:
| This is going to be really useful to me as someone who doesn't
| really do this kind of thing. Very timely.
|
| But don't put every keypress from my searches into my browser
| history.
___________________________________________________________________
(page generated 2021-05-11 23:01 UTC)