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

Kaspar Etter <> Tue, 25 May 2021 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EF203A0A29 for <>; Tue, 25 May 2021 03:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GeUV4ydcA1hX for <>; Tue, 25 May 2021 03:40:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B6F23A0A26 for <>; Tue, 25 May 2021 03:40:07 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id EA86A1C000D; Tue, 25 May 2021 10:40:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gm1; t=1621939203; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aKl8Rdeutf/lS0zyfzwB0h5lzAwifnyw64badWg9HJg=; b=b6rUm1LNIho6g93iNShGaIcoCrmFHMtS+g88c3emfnqCS1V/MfdN6MyMuxsU8aJFsoPaxV uVEcCDFqENbfiD8meoLiy0FpDD2/lSYzQ7DVRa4zFJkQR+yMf381vUT0Q3PbnCMPdScSnY fOBOq0bWABxPmLwE7oFRXg/mxTkhgiXZxs7I52lIvySyrNrFo/hgOfK0XrHpb925xkpTO0 VVOYG3CMagLFIEVXuvbR9pPIc5hDzpl00W1gSxN+rXtbYKFJHdes5b2uN+SbXHkS5hal6/ 7AK250ipLXAdeon1ESRZyIcPFGMD74RBOfW+IbuCj5gibNHo9NhPomXrYzVexA==
From: Kaspar Etter <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4B1418C3-6E3C-4C8D-AC50-F5D014966032"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 25 May 2021 12:40:01 +0200
In-Reply-To: <>
Cc: SMTP Interest Group <>
To: Alessandro Vesely <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [ietf-smtp] Followup to your reply on the IETF-SMTP mailing list
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 10:40:14 -0000

On 24 May 2021, at 12:43, Alessandro Vesely <> wrote:
> 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 offered a “Download message” option next to the “Show header” option. This would have made it straightforward to import your message into my mailbox.

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

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 <>: “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: <>

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

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