On Fri, May 14, 2021, at 23:27, Kaspar Etter wrote:
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?
Thanks Kaspar,
It's clear you've put a lot of work into putting this together. Unfortunately
I don't have time right now to do it justice and review the whole thing! I'm
not sure that anyone else is likely to either. This is one of the ongoing
challenges for any work, it's more interesting to do the work than to review it!
But that actually raises the more interesting question out of all of this. Are
you interested in engaging with the IETF community and helping to progress your
ideas within the IETF? Because that's going to involve the messiness of human
interaction and building relationships so that people make the time to review
your work because they know you will return the favour when they need reviews
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
I wonder if you'd be interested in the work happening in the GNAP working group.
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
This is an interesting question. Are you entitled to such privacy from the
recipient? If so, on what basis? This kind of thing is very much a tradeoff
of various concerns, and by removing your IP address, the server to which you
are making the submission is taking on additional responsibility for the
content of your message.
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
I strongly agree with you on this one :) Immutable content and completeness
are a big deal to me. It's somewhat solveable by clients fetching the content
and caching it immediately - or servers doing the same and rewriting the links.
But upgrading from where we are to there is a big project - who's going to do
the work? Both in defining something better, and persuading the world to move
to it. These are both hard problems, because the something better needs to be
persuasive.
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
Oh yeah, HTML is a horrible choice for this. But, like democracy, it's better
than all the alternatives! Defining a subset and getting people to use it
would be great, but see my response to 3. How do you sell this to all the
involved parties and have an upgrade path which doesn't lead to all multipart
emails having 3 parts, text/plain, text/html and text/the-better-one ?
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
See previous.
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
As with anything where it's not really clear, the only safe assumption is to
assume the least favourable to you of all possibilities, so - don't use CNAME
records and if you do, they'll be counted towards the lookup limit! Which I
see you've already mentioned.
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
It's an attempt to solve the mailing list problem and the forwarder problem.
At least for pure forwarding the simple solution is to keep the bytes intact so
that DKIM still passes, but for messages without DKIM it will at least maintain
some integrity tracking on the SPF check that was done when it entered
ARC-supporting servers.
I have written a bit on this, and I do feel that having an additional DMARC
policy of reject-unless-arc-trusted is necessary for the intermediate to know
whether the far end will reject - but the problem is that there's no clean
bootstrap path either way, because you fail either too open or too closed. The
intermediate doesn't know if it needs to address-rewrite anyway to make sure
the mail gets through.
Note for example that this email is listed as being:
From: Kaspar Etter <kaspar=40ef1p(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org>
Because the IETF list has to rewrite due to your domain's policy.
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
I'm not an expert in this area so I won't try to respond to these two.
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.
There's a discussion in the IETF generally about how to deal with the backlog
of errata. Again as I mentioned right up the top - getting people to do the
boring grunt work of reading others' work and providing insightful feedback is
tricky! Finding time to process things is tricky.
Clearly you've found an enormous amount of time to put all this together, and
it's really excellent work. It feels like the kind of thing that you should be
getting academic credit for, to the extend of being a published paper, at least
to the "Honours Degree" level - it's carefully researched and meticulous.
I hope you have the time and the willingness to engage with the IETF community
as a contributor and to work within the ebb-and-flow of human relationships to
progress some of your ideas and your work further. We could do with the energy
that you're bringing - it's just a lot to bite off so much all in one go!
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong(_at_)fastmailteam(_dot_)com
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp