MIME-Version: 1.0
References: <0786af40-4c4a-4670-a71e-eeed0596c7d8@lear.ch>
 <arADNYbear-_QgRh@chardros.imrryr.org>
 <1FE6D8319E6156C7A0044D7E@PSB>
In-Reply-To: <1FE6D8319E6156C7A0044D7E@PSB>
From: Rob Sayre <sayrer@gmail.com>
Date: Sun, 20 Sep 2026 15:13:45 -0700
Message-ID: 
 <CAChr6SzLtYQczhK+ErEhP0g=8=FuDCEFy1FRTguX1KYdjwG=0A@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary="0000000000001e441e065bf173fa"
Message-ID-Hash: R5ACQQR6G5KYUYSVYYKOGISO5MICJH6C
CC: emailcore@ietf.org, Last Call <last-call@ietf.org>
Precedence: list
Subject: [Emailcore] Re: [Last-Call] Re: Re: Re: Your (Roman's) DISCUSS on
 draft-ietf-emailcore-as and status of the document
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/emailcore/dqMODjWNc5JztczqcMSkhg065oc>

--0000000000001e441e065bf173fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 20, 2026 at 10:41=E2=80=AFAM John C Klensin <john-ietf@jck.com>=
 wrote:

>
>
> --On Monday, September 21, 2026 02:00 +1000 Viktor Dukhovni
> <ietf-dane@dukhovni.org> wrote:
>
> > On Sun, Sep 20, 2026 at 11:05:37AM +0200, Eliot Lear wrote:
> >
> >> We are not the protocol police, and we have no army.  MUST is
> >> *practical* *advice* to deployments about how best to
> >> interoperate with others, in this case balanced against potential
> >> harm.  That balance has already been decided operationally by
> >> public deployments, [...]
> >>
> >> Moreover, I am one of but a very few people party to this
> >> discussion who is in a position to reject unencrypted SMTP
> >> transactions (of course I don't).  I know of nobody who does.
> >
> > I concur, but should perhaps concede that a small minority of
> > Postfix MTA operators have self-reported choosing (against
> > generally better advice) to reject non-TLS mail transactions.
> > Their MTA is "able to accept mail with or without confidentiality",
> > their "particular circumstances" apparently make rejecting
> > cleartext transactions an acceptable risk.
>
> Ok.  But what does it mean _for the document_ to "concede" that?
>

Just say less. The document does a good job describing the interoperability
concern in the paragraph above.

TLS can be a compliance requirement, and a great way to ensure compliance
is to use an SMTP server that doesn't support cleartext at all.

thanks,
Rob


Here are the Google Workspace settings:

You can reject non-TLS emails in Google Workspace by configuring a Secure
transport (TLS) compliance setting or requiring TLS on an inbound mail
gateway in the Google Admin Console.

How to Require TLS for Specific Senders or Domains:
Sign in to the Google Admin Console using an administrator account.
Go to Menu > Apps > Google Workspace > Gmail > Compliance.On the left,
select your target organizational unit.
Find Secure transport (TLS) compliance and click Configure (or Add another)=
.
Enter a setting name, choose Inbound, Outbound, or both, and select or
create an address list for the domains/emails you want to enforce.
Check options like Require CA signed certificate and Validate certificate
hostname for robust security, then click Save.

How to Require TLS via an Inbound Gateway:
In the Google Admin Console, navigate to Apps > Google Workspace > Gmail >
Spam, phishing, and malware.
Select your organizational unit on the left, then scroll to Inbound gateway
and click Configure or Edit.
Enter your gateway's public IP address or range.
Check the box for Require TLS for connections to reject incoming connection
attempts that do not use TLS.

--0000000000001e441e065bf173fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 20,=
 2026 at 10:41=E2=80=AFAM John C Klensin &lt;<a href=3D"mailto:john-ietf@jc=
k.com">john-ietf@jck.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><br>
<br>
--On Monday, September 21, 2026 02:00 +1000 Viktor Dukhovni<br>
&lt;<a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@d=
ukhovni.org</a>&gt; wrote:<br>
<br>
&gt; On Sun, Sep 20, 2026 at 11:05:37AM +0200, Eliot Lear wrote:<br>
&gt; <br>
&gt;&gt; We are not the protocol police, and we have no army.=C2=A0 MUST is=
<br>
&gt;&gt; *practical* *advice*=C2=A0to deployments about how best to<br>
&gt;&gt; interoperate with others, in this case balanced against potential<=
br>
&gt;&gt; harm.=C2=A0 That balance has already been decided operationally by=
<br>
&gt;&gt; public deployments, [...]<br>
&gt;&gt; <br>
&gt;&gt; Moreover, I am one of but a very few people party to this<br>
&gt;&gt; discussion who is in a position to reject unencrypted SMTP<br>
&gt;&gt; transactions (of course I don&#39;t).=C2=A0 I know of nobody who d=
oes.<br>
&gt; <br>
&gt; I concur, but should perhaps concede that a small minority of<br>
&gt; Postfix MTA operators have self-reported choosing (against<br>
&gt; generally better advice) to reject non-TLS mail transactions.<br>
&gt; Their MTA is &quot;able to accept mail with or without confidentiality=
&quot;,<br>
&gt; their &quot;particular circumstances&quot; apparently make rejecting<b=
r>
&gt; cleartext transactions an acceptable risk.<br>
<br>
Ok.=C2=A0 But what does it mean _for the document_ to &quot;concede&quot; t=
hat?=C2=A0<br></blockquote><div><br></div><div>Just say less. The document =
does a good job describing the interoperability concern in the paragraph ab=
ove.</div><div><br></div><div>TLS can be a compliance requirement, and a gr=
eat way to ensure compliance is to use an SMTP server that doesn&#39;t supp=
ort cleartext at all.</div><div><br></div><div>thanks,</div><div>Rob</div><=
div><br></div><div><br></div><div>Here are the Google Workspace settings:</=
div><div><br></div><div>You can reject non-TLS emails in Google Workspace b=
y configuring a Secure transport (TLS) compliance setting or requiring TLS =
on an inbound mail gateway in the Google Admin Console.<br><br>How to Requi=
re TLS for Specific Senders or Domains:<br>Sign in to the Google Admin Cons=
ole using an administrator account.<br>Go to Menu &gt; Apps &gt; Google Wor=
kspace &gt; Gmail &gt; Compliance.On the left, select your target organizat=
ional unit.<br>Find Secure transport (TLS) compliance and click Configure (=
or Add another).<br>Enter a setting name, choose Inbound, Outbound, or both=
, and select or create an address list for the domains/emails you want to e=
nforce.<br>Check options like Require CA signed certificate and Validate ce=
rtificate hostname for robust security, then click Save.<br><br>How to Requ=
ire TLS via an Inbound Gateway:<br>In the Google Admin Console, navigate to=
 Apps &gt; Google Workspace &gt; Gmail &gt; Spam, phishing, and malware.<br=
>Select your organizational unit on the left, then scroll to Inbound gatewa=
y and click Configure or Edit.<br>Enter your gateway&#39;s public IP addres=
s or range.<br>Check the box for Require TLS for connections to reject inco=
ming connection attempts that do not use TLS.</div></div></div>

--0000000000001e441e065bf173fa--