Re: [ietf-smtp] Email explained from first principles

[Bron Gondwana <[e-mail]>]

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=[e-mail]>

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
  [e-mail]