Live data from Hacker News

Show HN: Mail Studio – IDE for designing responsive emails

mailstudio.app

211–214 of 214 posts

Re: Show HN: Mail Studio – IDE for designing responsive emails

#211

Earlier quoted context omitted.

I think this is, aside from the security concerns, why many chat applications, forums and tools like Github/Gitlab have switched to standards like Markdown for text formatting. I can see the value in linking, embedding images, highlighting through bold and italic text, and underlining. Even code can be useful inside an email. Markdown or a similar language would serve most people very well, much better than HTML. Non…

If emails were written and parsed as markdown, I might (!) change my opinion about it. But HTML is vastly too feature-rich to be sane. I think showing images inline (such as in Github-flavored Markdown) is still too feature-rich. But lists, tables, monospaced blocks, italic, bold ... these are fine. Embedded images aren't conducive to being parsed by a script.

Inline images are very useful for diagrams, sharing screenshots and more. I can do without the stupid company logo underneath every email, but I'd much rather have to put up with those than be unable to use them. The resources need to be small enough to embed inside the email, though, and external resources should be made aa difficult as possible (always hidden by default, per rfc, with at least two clicks before they're displayed).

My perfect world email markdown will probably be different from yours. For productivity, anything more than slightly stylised text is just unnecessary, but in practice, most email isn't used for productivity anymore. Instant messaging has replaced email as a means of conversation in all workspaces I know.

Re: Show HN: Mail Studio – IDE for designing responsive emails

#212
post #195

Earlier quoted context omitted.

Someone tested [0] and the result agrees with you. And this Gmail help article [1] elaborates on the scope of protection, which is equivalent to "IP address and HTTP headers": > Google scans images for signs of suspicious content before you receive them. > These scans make images safer because: > - Senders can’t use image loading to get information about your computer or location. > - Senders can't use the image to s…

Wouldn't this image rewriting mess with e-mail signing?

To validate a signature, the code doing that validation needs direct access to the message prior to any rewriting. I don't think the proxy introduces any barriers to that access, assuming the validation occurs on Gmail servers, as the Gmail interface can present the results of that server-side validation.

If you wanted to validate it yourself instead of trusting Gmail to do it for you, you'd use the "Show original" feature which gives you the original (per its namesake) without any rewriting as well. I assume (but haven't tested) that connecting to your mailbox via IMAP, POP, etc. also causes you to retrieve the original, with the rewriting only coming into play when using the Gmail web interface.

Re: Show HN: Mail Studio – IDE for designing responsive emails

#213
post #207

Earlier quoted context omitted.

IIRC, that was the exact argument for disabling image loading when it was first introduced. The responsible thing for services like gmail and o365 to do would be to eat the resource costs and just open ALL external content within a privacy sandbox, thereby polluting the data. Then you can re-enable displaying of images for everyone and the experience for designers and end users gets better.

Gmail does exactly that, I believe? It proxies the external resources to hide your IP. What it can’t do sadly is strip out tracking functions (unique IDs and such). Dunno how that could even be solved tbh

Gmail proxies the images when you open the email.

What the parent is suggesting is for Gmail to download the images as soon as the server receives the email, thereby rendering any tracking data meaningless.

Re: Show HN: Mail Studio – IDE for designing responsive emails

#214
post #100

Earlier quoted context omitted.

The solution we have is quite complex, as it also includes a builder where client can drag-drop blocks to create template (with text variables) for mailings. Mustache is used for color/font substitutions and also for text variable (like $recipient_name) substitutions. So: JSON representation of an email -> HTML+Mustache -> HTML+Mustache (only variables) -> HTML For (live during email building) previews we skip the la…

which builder are you using? i hav ea similar mjml + mustache setup, and am using blocksedit.com for client drag/drop. would love to see your setup!

I haven't seen blockedits.com before, it looks really cool. What are your thoughts on it? Is it worth taking a deeper look at or would you choose something else if you were starting from scratch?
Post reply on HN