Email explained from first principles

Dear IETF community,

I spent several months researching and summarizing all aspects of modern email in an attempt to make the email standards more accessible to a wider audience. You find the result of my work at https://explained-from-first-principles.com/email/.

I'm interested in your feedback and criticism: Did I get anything wrong? Is an important aspect still missing?

Besides summarizing more than a 100 RFCs, my article contains many suggestions for how existing standards could be improved. This mailing list is probably not the right place to discuss them, but I would still like to point out a few of them:

1. I made a security analysis of SCRAM and provided several suggestions for how its security could be improved even further: https://explained-from-first-principles.com/email/#desirable-properties-of-authentication-mechanisms and https://explained-from-first-principles.com/email/#salted-challenge-response-authentication-mechanism

2. SMTP for Submission should make it clear that the IP address of the submitter SHOULD NOT be included in the Received header field. In my view, the current practice of many email service providers violates the European General Data Protection Regulation (GDPR): https://explained-from-first-principles.com/email/#sender-towards-recipients

3. This ship sailed a long time ago, but remote content violates three fundamental principles of email and should thus never have been supported by mail clients. At the very least, subresource integrity (SRI) should be introduced and be required for all remote content: https://explained-from-first-principles.com/email/#remote-content

4. HTML emails are broken. Mail clients struggle to quote them securely, and the same message can appear differently to different recipients: https://explained-from-first-principles.com/email/#quoting-html-messages and https://explained-from-first-principles.com/email/#different-appearances

5. To fix the problem of different appearances for different recipients, a profile of CSS which ensures that content cannot be hidden should be specified and then implemented by all mail clients: https://explained-from-first-principles.com/email/#hide-content-with-css

6. Are SPF verifiers supposed to follow CNAME records and if so, do they count towards the lookup limit? I couldn't find an answer in the RFC. In my opinion, resolving CNAME records during SPF validation is undesirable for security reasons: https://explained-from-first-principles.com/email/#protecting-subdomains

7. I don't understand why Authenticated Received Chain (ARC) is necessary or even desirable: https://explained-from-first-principles.com/email/#authenticated-received-chain

8. It's rather complicated in which cases DANE applies to ESMTP. I hope I got all the cases right: https://explained-from-first-principles.com/email/#name-matching

9. RFC 8461 states explicitly that MTA-STS may not override a failed DANE validation. As far as I can tell, it isn't specified anywhere whether DANE may override a failed MTA-STS validation. In my opinion, this would be desirable because it would allow domain owners to configure transport security without the support of their email service provider: https://explained-from-first-principles.com/email/#coexistence-with-dane

As a feedback from my side to the IETF community: 6 out of the 8 errata which I reported are still not "resolved" (see https://www.rfc-editor.org/errata_search.php?submitter_name=Kaspar+Etter). I hope the errata process is revised rather sooner than later.

Best regards,
Kaspar Etter