Email: Explained from First Principles

Re:Email: Explained from First Principles by layer8 on Sunday February 19, 2023 @04:30PM (#34862051)

I love such thorough expositions, although it isn’t quite as thorough as I would like. Two examples that caught my attention in the parts I read:

1. It doesn’t mention the old convention for writing an email address with display name as

  [email protected] (John Doe)

instead of:

  John Doe <[email protected]>

2. It states that subject prefixes like “Re:” have no technical relevance. That’s not entirely true, because email clients recognize existing prefixes when replying/forwarding, in order to not add a redundant one. There are several issues here:

- Localized email software sometimes uses a different prefix than “Re”, based on the local language. This is an issue when having an email thread between email clients who don’t recognize each other’s local-language prefixes. (Arguably, it would be better for everyone to stick with “Re” regardless of language.)

- Some email clients have the convention of adding a count to the “Re”, e.g. “Re[2]:”, “Re[3]:”, and so on. When you write an email client, you may want to consider recognizing those.

Due to the variety in subject prefixes, some email clients allow users to configure a regex.

[ Parent | on HN ]

Re:Email: Explained from First Principles by codetrotter on Sunday February 19, 2023 @04:44PM (#34862171)

> This is an issue when having an email thread between email clients who don’t recognize each other’s local-language prefixes.

https://en.wikipedia.org/wiki/List_of_email_subject_abbrevia...

RE:SV:RE:FWD:AW:FWD:AW:FWD:REF:RIF:Verbale della riunione, venerdì 7

But yaeh, I think the big email clients are good at recognizing these across different languages.

[ Parent | on HN ]

Re:Email: Explained from First Principles by sbuk on Sunday February 19, 2023 @05:51PM (#34862706)

Email clients don’t really have a spec to follow other than parsing messages that are received via POP or more likely IMAP these days (not forgetting MAPI either). Adding FWD or RE to a subject field doesn’t appear anywhere in the email message RFCs, starting with 822. As such they are undocumented conventions or extensions to the specs, and as the article points out technically irrelevant - no MDAs, MTAs or MUAs that do not “support” features that utilise these conventions will fail to parse a message.

[ Parent | on HN ]

Re:Email: Explained from First Principles by Alex3917 on Sunday February 19, 2023 @09:04PM (#34864148)

To plug my own software, I've been working on an API to normalize raw email messages so that e.g. they can be easily displayed within web apps.

https://github.com/fwdeveryone/email-parsing-api

Right now building even the simplest products on email takes several years because of needing to support all of these undocumented "features", but I'm trying to make it no more difficult than building any other Django or Rails app.

[ Parent | on HN ]

Re:Email: Explained from First Principles by justinator on Sunday February 19, 2023 @07:56PM (#34863668)

> 2. It states that subject prefixes like “Re:” have no technical relevance. That’s not entirely true, because email clients recognize existing prefixes when replying/forwarding, in order to not add a redundant one.

Sort of. That can just be a clever regex. There is a In-Reply-To header that may actually give some suggestion on if this is a reply to something by telling you what it's a reply of.

[ Parent | on HN ]

Re:Email: Explained from First Principles by KasparEtter on Monday February 20, 2023 @11:50AM (#34869898)

Hi layer8, thanks for the feedback! I must say that your standards for thoroughness are pretty high. Since I claimed at the very top that my article covers all aspects of modern email, I don't mind your criticism at all.

I haven't thought about the prefix chaining issue, and I'm happy to mention this in a future revision of the article. I would still argue that this is below a reasonable level of technical significance as neither conversation grouping nor message delivery is affected by it. It's more like displaying "(No subject)" instead of actually displaying no subject.

Do you have any source for what you say is an old display name convention? I've just checked the standards, and as far as I can tell after a quick glance, RFC 822 (https://datatracker.ietf.org/doc/html/rfc822#section-6) doesn't mention display names at all, and its successor RFC 2822 (https://datatracker.ietf.org/doc/html/rfc2822#section-3.4) mentions display names only with angle brackets.

PS: I have quite a few topics on my todo list, which I should add in a future revision of the article in order to live up to the claim of covering all aspects of modern email. These include MAPI, Microsoft's autodiscover mechanism, direct mailbox addressing, domain-to-domain encryption, and link rewriting in incoming mails. Some information is also no longer up to date by now.

[ Parent | on HN ]

Re:Email: Explained from First Principles by account42 on Wednesday February 22, 2023 @08:57AM (#34895527)

Arguably, the Re: prefix should not have been added to the subject at all but implied by the In-Reply-To or References headers, allowing clients to display it in whatever language they want. Trying to standardize an in-band redundant flag in the subject header is probably not worthwile. Does Gmail and other clients with thread views even display the supplied subject when replying to a known mail?

[ Parent | on HN ]