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

[Alessandro Vesely <[e-mail]>]

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