Dear Bron,
Thanks a lot for your response and please excuse my late reply.
On 17 May 2021, at 03:33, Bron Gondwana <brong(_at_)fastmailteam(_dot_)com>
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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp