Hacker News new | ask | show | jobs
by gpvos 2477 days ago
Something like this? http://www.rfc-editor.org/rfc/rfc1896.txt
3 comments

Email is so fun, every time someone comes with a new idea, someone pulls out an RFC detailing it. Dated 20+ years back.
It even has a predecessor from 1992, see paragraph 7.1.3 of http://www.rfc-editor.org/rfc/rfc1341.txt .
Thanks for the RFC link. Yes, basically.

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.

It’s so stupid. If AMP emai ever became a thing, every single non google email client would just fetch and store the contents of the AMP page the moment an AMP email arrives. So what was the point of it?
Not so sure about that, not downloading anything extra and only showing what is embedded in the email is one of the good things with using an email client. Using AMP email is back to thinking tracking pixels works in emails
If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it.

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.

Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness.

(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.)

So you want RFC 2017 basically?
Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't.

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.

Isn't AMP for email kinda what you are describing?

"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...

Isn't markdown just turned into html?
Markdown strikes me as a much improved version of exactly this, with the advantage that you don't have to have a supporting client to read the email, since it's simply plain text.

I want to see email clients start to support Markdown, so I can just send it to everyone.

Not just email, I’d like to see browsers support Markdown natively. You can style your content. All media sites can be 100% markdown without any JS.