Subject: Re: [ietf-smtp] Followup to your reply on the IETF-SMTP mailing list

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 May 2021 12:43:06 +0200

Hi Kaspar,

On Sun 23/May/2021 15:16:57 +0200 Kaspar Etter wrote:
> 
> I wasn’t subscribed to the IETF SMTP mailing list when you wrote 
> https://mailarchive.ietf.org/arch/msg/ietf-smtp/Lqfwg9DfaxmYAv_S5WGiOPsJFCw/. 
> Since I’m too lazy to compose this followup message manually, I can’t continue 
> the conversation on the mailing list, and so I decided to write to you personally.

As the discussion is fully non-personal, I think you don't mind if I CC the list.

>> 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.
> 
> I don’t like the term “mailbox provider” because these companies provide much 
> more than just a mailbox, namely email submission and delivery, spam 
> prevention, and message filtering with Sieve or some other interface. For me, 
> email service provider is a suitable equivalent to Internet service provider 
> (ISP). Do you think of Mailgun, SendGrid, Postmark, etc. when you hear “email 
> service provider”? I called them SMTP service providers or email delivery 
> vendors in the box about reputation 
> (https://explained-from-first-principles.com/email/#reputation).

Hm... /email delivery vendor/ sounds interesting.  Unfortunately, ESP is well 
established already (among the people who knows what that is).

Mailbox provider was told me by JD Falk when I was caught in the same trap:
https://web.archive.org/web/20100613121358/http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000360.html

Even if MPs offer many more services, mailboxes are associated with email 
addresses, which are the most noteworthy elements of visibility.

An alternative name is MSP (without 'E'), defined in email arch. as:

    Transit:    Mail Service Providers (MSPs) that offer value-added
                capabilities for Edge ADMDs, such as aggregation and
                filtering.

>> 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.
> 
> I’m not sure what you wanted to get at, but I responded to Bron on the mailing 
> list.

Traditional email software allows to tinker with originator data, in part for 
the sake to grant anonymity.  Some providers restrict it, but no RFC require 
them to be valid.

>> Did you find clients that execute Javascript?
> 
> No. Did I imply this? I tested everything I was interested in with the same few 
> mail clients.

No, I didn't see the topic of remote code execution in your article.  However, 
Javascript can be embedded inside html pages, where browsers normally execute 
it.  I hope email clients don't, but I don't recall feature statements in this 
regard.

>>> [CNAMEs in SPF]
>> 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.
> 
> This requires the use of DNSSEC (see 
> https://explained-from-first-principles.com/email/#name-chaining-attacks, 
> but many companies use SPF without DNSSEC.

A recursive resolver doesn't have to be DNSSEC aware.  A client issues a call 
and looks for a TXT RR in the response.  A fussy client has to explicitly look 
for CNAME records in order to increase the count when it finds them.  IMHO, it 
makes no sense.  Resolving implies additional calls issued by the resolver to 
navigate any involved zone cut, and these are certainly not counted.

>> 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.
> 
> I’m not sure to whom you addressed these questions. The answer to the first 
> question is that it doesn’t matter (from the perspective of the standard).

While not important for users, a web server is not necessarily part of an email 
hosting contract.  In various circumstances, the web site operator is an extra 
party, which requires coordination with both the mail operator and the domain 
owner.

> And the beauty of TLSA records is that the MX operator maintains them. All I
> have to do as a domain owner is to deploy/enable DNSSEC on my domain.

You're right.  I assumed the TLSA record was not a CNAME.  I guess you mean:

_25._tcp.my-domain.example. IN CNAME _25._tcp.MX-operator.example.

Best
Ale
--

---

From: Kaspar Etter <[email-masked]>
Date: Tue, 25 May 2021 12:40:01 +0200

> As the discussion is fully non-personal, I think you don't mind if I CC the list.

No, I don’t mind, but as a result, we still broke the conversation threading. It would be nice if mailarchive.ietf.org offered a “Download message” option next to the “Show header” option. This would have made it straightforward to import your message into my mailbox.

>>> ESPs a different kind of business.  Others, especially foreigners, don't grok that.
>> I don’t like the term “mailbox provider” because these companies provide much more than just a mailbox, namely email submission and delivery, spam prevention, and message filtering with Sieve or some other interface. For me, email service provider is a suitable equivalent to Internet service provider (ISP). Do you think of Mailgun, SendGrid, Postmark, etc. when you hear “email service provider”? I called them SMTP service providers or email delivery vendors in the box about reputation (https://explained-from-first-principles.com/email/#reputation).
> 
> 
> Hm... /email delivery vendor/ sounds interesting.  Unfortunately, ESP is well established already (among the people who knows what that is).
> 
> Even if MPs offer many more services, mailboxes are associated with email addresses, which are the most noteworthy elements of visibility.
> 

Thank you for the additional context. Personally, I strongly object to the idea that mail service provider (MSP) and email service provider (ESP) can stand for different things. In the context of email, mail and email are used interchangeably. But there is also another reason why I don’t like the term “mailbox provider”: The term “mailbox” is used to refer to both an email account, which is identified by an email address, and a message folder in such an account, as defined by the IMAP standard. While I use the term only in the former meaning, some mail clients such as Apple Mail use the latter. Moreover, the term “email service provider” is too generic to refer only to transaction emails and bulk mailings, in my opinion. I will add a note about the different usages to my article, though.

> I didn't see the topic of remote code execution in your article.  However, Javascript can be embedded inside html pages, where browsers normally execute it.  I hope email clients don't, but I don't recall feature statements in this regard.

I wrote in https://explained-from-first-principles.com/email/#html-emails <https://explained-from-first-principles.com/email/#html-emails>: “For security reasons, mail clients don’t execute sender-provided JavaScript.”

However, some email service/mailbox providers support dynamic content with a whitelisted JavaScript framework: https://explained-from-first-principles.com/email/#dynamic-content <https://explained-from-first-principles.com/email/#dynamic-content>

> A recursive resolver doesn't have to be DNSSEC aware.  A client issues a call and looks for a TXT RR in the response.  A fussy client has to explicitly look for CNAME records in order to increase the count when it finds them.  IMHO, it makes no sense.  Resolving implies additional calls issued by the resolver to navigate any involved zone cut, and these are certainly not counted.

You make a good point here. I still think this aspect should be clarified in the standard so that an SPF record with CNAME indirections and 10 lookups is either valid for all clients or none of them.

> _25._tcp.my-domain.example. IN CNAME _25._tcp.MX-operator.example.

No, I meant that DANE-aware ESMTP clients first resolve the MX indirection and look for TLSA records on the “target/MX” domain.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 May 2021 12:35:35 -0400

> No, I meant that DANE-aware ESMTP clients first resolve the MX
> indirection and look for TLSA records on the “target/MX” domain.

Indeed, e.g. this is how it works form ~1.2 million domains that are
MX-hosted by one.com MX hosts.  The hosted domain just needs to be
DNSSEC-signed and to point its MX records at the provider.  The DANE
TLSA RRs and all responsibility for managing them are on the MX host side:

    simonvikstrom.se. IN MX 10 mx1.pub.mailpod7-cph3.one.com. ; NoError AD=1
    simonvikstrom.se. IN MX 10 mx2.pub.mailpod7-cph3.one.com. ; NoError AD=1
    simonvikstrom.se. IN MX 10 mx3.pub.mailpod7-cph3.one.com. ; NoError AD=1
    ;
    mx1.pub.mailpod7-cph3.one.com. IN A 185.164.14.86 ; NoError AD=1
    _25._tcp.mx1.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 3b8e75c279f1dda9ca462b79077ba25b63f4a016d01e3fbbca6ab6620ae04421 ; NoError AD=1
    _25._tcp.mx1.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 ab91ea8a9ae477de45828410679aa1e6c290b3a28835f47e3eac9d0bd1894c2f ; NoError AD=1
    ;
    mx2.pub.mailpod7-cph3.one.com. IN A 185.164.14.87 ; NoError AD=1
    _25._tcp.mx2.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 3b8e75c279f1dda9ca462b79077ba25b63f4a016d01e3fbbca6ab6620ae04421 ; NoError AD=1
    _25._tcp.mx2.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 ab91ea8a9ae477de45828410679aa1e6c290b3a28835f47e3eac9d0bd1894c2f ; NoError AD=1
    ;
    mx3.pub.mailpod7-cph3.one.com. IN A 185.164.14.88 ; NoError AD=1
    _25._tcp.mx3.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 3b8e75c279f1dda9ca462b79077ba25b63f4a016d01e3fbbca6ab6620ae04421 ; NoError AD=1
    _25._tcp.mx3.pub.mailpod7-cph3.one.com. IN TLSA 3 1 1 ab91ea8a9ae477de45828410679aa1e6c290b3a28835f47e3eac9d0bd1894c2f ; NoError AD=1

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 25 May 2021 14:31:35 -0400

It appears that Kaspar Etter  <[email-masked]> said:
>Thank you for the additional context. Personally, I strongly object to the idea that mail service provider (MSP)
>and email service provider (ESP) can stand for different things.

Unfortunately, you're at least a decade too late.  The terms are well established in the industry
and there is no point in trying to change them now.

R's,
John