On Mon 17/May/2021 03:33:20 +0200 Bron Gondwana wrote:
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/
Interesting effort. I just gawked at it. I hope I'll find time to read some
more...
I'm interested in your feedback and criticism: Did I get anything wrong? Is
an important aspect still missing?
One thing is the definition of /email service provider/. The wikipedia article
you link to is correctly named /Mailbox provider/. A number of people consider
ESPs a different kind of business. Others, especially foreigners, don't grok that.
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.
I'd note that the author's email address is usually considered more private
than the (temporary) IP address used for submission. Yet, in this respect,
protocols are not clear about what submitters are allowed to put in the
From:/MAIL FROM addresses. Even if the SMTP operator DKIM signs From: and
restricts MAIL FROM by SPF, it is not formally required to check those values.
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.
+1, perhaps that's why it's not much used.
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
<https://explained-from-first-principles.com/email/#quoting-html-messages>
and https://explained-from-first-principles.com/email/#different-appearances
For a nit, s/they will see USD 100/she will see USD 100/.
The usual scam is to invite readers to go to <a href="hell">paradise</a>.
Did you find clients that execute Javascript?
Oh yeah, HTML is a horrible choice for this. But, like democracy, it's better
than all the alternatives!
Text/plain _is_ a better alternative (to HTML, not to democracy...)
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.
OTOH, resolvers can deliver the target without requiring an extra call. And
the number of calls is the only thing an SPF verifier can/should count.
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.
It is interesting to consider the similarity between ARC and Dave's Use of
Sender[*]. Both aim to allow an intermediate to add something to the header so
that the recipient should put a DMARC=pass notwithstanding the letter of RFC
7489 would mandate DMARC=fail given the final From:. In both cases, the
legitimacy of the stuff added to the header cannot be verified by the recipient.
[*] https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-sender
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
<mailto:40ef1p(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org>>
Because the IETF list has to rewrite due to your domain's policy.
The latter point, the need to munge From:, proves that ARC is not necessary.
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
IMHO, putting *Trust anchor* first would better convey the intention of DANE.
Then, there are some other alternatives (!=3) to generate TLSA RRs. Are they
used?
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.
Neither am I. However, I'd note a couple of points:
* It's not clear who provides web hosting for MTA-STS. Is it a third role?
* Domain owner should prepare new TSLA RRs /before/ the MX operator changes
key/certificate. Failure to sync might entail a few days of blackout.
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp