Re: Email explained from first principles

Dear Bron,

Thanks a lot for your response and please excuse my late reply.

> On 17 May 2021, at 03:33, Bron Gondwana <[email protected]> wrote:
> 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!

Yes, I totally understand this. While I asked for feedback and criticism, I also shared my work with this mailing list for two other reasons:

1. My work could be really useful to the IETF community by allowing you to refer people to this comprehensive introduction to modern email. (For some people here, it’s also a summary of and a tribute to their life’s work.)

2. I’m very much aware of the epistemic damage one can cause as an author, and I take this responsibility seriously. For example, confusing opportunistic use of TLS with explicit use of TLS was a big mistake. I don’t know who started this, but I tried my best to rectify this misconception. If my article becomes the definitive guide to email for newcomers (I know that this is a big “if”), any error in my text can cause a lot of work for people on this mailing list. Differing terminology is a good example of harm I might cause to the email community, and I’ve already received two remarks in this direction.

> 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

You raise a valid point. I don’t mind the messiness of human interactions and I can imagine getting involved in some IETF efforts. I’m somewhat hesitant for two reasons:

1. I might be wrong, but my impression is that most people are paid for their standardization work by a company or a university. I won’t be able to contribute a significant amount of work unless an organization is willing to sponsor me.

2. Standards alone don’t matter. During my research, I learned about many great standards which haven’t found significant adoption yet. Examples of this are SRV records for autoconfiguration and the REQUIRETLS extension to ESMTP. Innovation has to be driven by the relevant players in the field, and I’m not one of them.

Having said this, I’d be open to work on the following, relatively low hanging fruits if enough people here encourage me to do so:

1. Formalizing no reply: Many automated systems send emails but cannot handle replies. A new RFC could either acknowledge that no reply shall be sent if the local part of the sender is “no-reply” or introduce a new header field to achieve the same. (See https://explained-from-first-principles.com/email/#no-reply <https://explained-from-first-principles.com/email/#no-reply> for more context. The idea is that mail clients wouldn’t even offer a reply button for such messages.)

2. List-Name header field: Mailing lists shouldn’t rewrite the messages of others and break DKIM signatures in the process. Since my email address was rewritten due to my domain policy, I didn’t receive some of the replies to my original message because I didn’t subscribe to this mailing list immediately. The List-Unsubscribe header field makes it unnecessary to include an unsubscribe footer in forwarded messages. A new List-Name header field would make it unnecessary to prefix the Subject with the name of the list. Mail clients could simply prefix the Subject with the value of the List-Name header field according to the user’s preferences locally if desired. Anyone who moves messages to separate folders with filtering rules might not even be interested in this. In my opinion, DKIM signatures are broken for no good reason.

> I wonder if you'd be interested in the work happening in the GNAP working group.

Thanks for the hint, I wasn’t aware of this 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 <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.

Leaking the IP address of the sender to the recipient has serious implications for privacy (geolocation of the sender and tracking the sender across services) and security (denial-of-service attacks and targeted remote attacks). With broadband Internet, many households have the same IP address for months or even years. As a consequence, IP addresses are justifiably treated as personally identifiable information. Given laws such as GDPR, many lawmakers think that I’m entitled to such privacy. For similar reasons, some companies proxy remote content for their users (see https://explained-from-first-principles.com/email/#proxying-remote-content <https://explained-from-first-principles.com/email/#proxying-remote-content>), but this is pointless if they share the user’s IP address when the user hits on “reply”. And as far as reputation and domain authentication are concerned, outgoing mail servers take responsibility for my messages anyway. (To be clear: I don’t mind if companies keep logs of email submissions. There’s just no reason to share the most confidential part of such logs with all recipients.)

>> [Remote content]
> 
> 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.

I don’t have the answer either, but convincing authors of mail clients to disable remote content by default seems like a good place to start. :-) (And we already have “something better” in the form of aggregate documents: https://explained-from-first-principles.com/email/#aggregate-documents <https://explained-from-first-principles.com/email/#aggregate-documents>.)

>> 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 <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.

Yes, I understand this, but the forwarding mail system could just add a DKIM signature using its own domain and take responsibility for the message (as mentioned by the DKIM RFC if I remember correctly). Recipients are free to trust such signatures.

> 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.

Here is what I replied to someone from this mailing list who contacted me privately:

It would be valuable if RFCs could reflect the current (and original) sentiment of IETF members. A designation, such as “deprecated” or “no longer maintained”, could help external people like me a lot. You could also stop accepting errata for such RFCs then. And to most of my errata, I did get a response (see https://mailarchive.ietf.org/arch/search/?q=Kaspar%20Etter <https://mailarchive.ietf.org/arch/search/?q=Kaspar%20Etter>). But while it’s easy to find an RFC and its errata, it’s difficult for others to find the corresponding conversation. Automatically referencing the corresponding thread in the mail archive would go a long way towards making RFCs and their errata more accessible to outsiders.

> 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.

Thank you for this compliment.

> 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!

See my reply above. If someone has the capacity to mentor me, I’m confident that we can make something happen. :-)

Best regards,
Kaspar

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp