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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp