DKIM2-Signature: i=1; m=1; t=1790905647; d=fastmailteam.com;
	mf=PGJyb25nQGZhc3RtYWlsdGVhbS5jb20+;
	rt=PGVtYWlsY29yZUBpZXRmLm9yZz4=;
	s=fm2:rsa-sha256:UKi77DKaq+FBUC6pOu4DdCNnrievvT0szKL5hU/kEIMnkd0
	wnmeHnT3SSelNnLKs30HW9qinRrY4nhGst5AW/rUG3ks3FsY42Mvs5fzgCwu04R2
	SKb7lUEkjPrW+hh7jqykZAb7XmyBbhkW8oz6+Kmw7q11g0B/uOs4kneYQTmatOTY
	o7ewTxWMRHUINC6Lvw2xp2W86HN7AWFn+QcKE+mxSC4XWJKjchAN1cLSdmjvHAuC
	bSn8A4CTfa7saIZVaw0VclOj0wuGtH4l6q/OCrcWOzUothXISyHH9BFrGU4IsNAE
	rnXwD+gE7yr984VZGXTM2rnO4gxyWgSuESTYEEw==;
Message-Instance: m=1;
 h=sha256:lVXOo6v3x3fPVzfaWtZqR5Xz5oM35G+PN1CuEi7wRSM=:a4jSPPkj/doxvoVLn3i25YpsEBN1oip+483X11rc9bw=;
Feedback-ID: i2d7042ce:Fastmail
MIME-Version: 1.0
Date: Thu, 01 Oct 2026 21:47:07 -0400
From: "Bron Gondwana" <brong@fastmailteam.com>
To: "Rob Sayre" <sayrer@gmail.com>, "EmailCore WG" <emailcore@ietf.org>
Message-Id: <8ce5cc87-abc5-4b55-a8ca-e6d9093f4819@app.fastmail.com>
In-Reply-To: 
 <CAChr6SxdJ24B=xH30nX9UspOs2f4jR=Rfze=g-jS5o6gm1WMjw@mail.gmail.com>
References: 
 <CAChr6SxdJ24B=xH30nX9UspOs2f4jR=Rfze=g-jS5o6gm1WMjw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary=e51bcd270282c30698439e6489d027ad7e171261
Message-ID-Hash: NROWIMWWNMAMZB65QJSMBHKZ3MEH5PPW
Precedence: list
Subject: [Emailcore] Re: [Last-Call] draft-ietf-emailcore-as some mail stats
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/emailcore/bcjWtC2SpU9wunA5F2uhSU0KKbM>

--e51bcd270282c30698439e6489d027ad7e171261
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, Oct 1, 2026, at 21:36, Rob Sayre wrote:
> Bron Gondwana <brong@fastmailteam.com> wrote:
> > From the last 24h of logs we have about 96% TLS, 4% without TLS.
> > Plenty of which is spam of course, but I did enough of a random
> > sampling to see that not all is.
> 
> I believe you.
> 
> But the standard is not only for general purpose email providers.
> 
> There are many implementations that don't need to cope with that 4%, and should not be required to.
> 
> Besides, there is not a hardline approach here. The idea is just to say nothing.
> 
> It's always an option to support RFC 5321 and its predecessors too. After all, the proverbial printers in the basement will not be updated for this new RFC.
> 
> It's disappointing to have this deletion repeatedly misstated as a requirement. Please, everyone, stop doing that. It is intellectually dishonest, whether intentional or not.

This whole mountain in a teacup is entirely about the question of whether you can write software which claims to support this document without allowing the operator to configure the ability to accept mail without STARTTLS.

Unfortunately we have a lot of civil-war re-enactment fanatics or whatever the equivalent is who want to die on hills about this exact text, so here we are, years after the bloody thing should have been published, and there are still people dug into their trenches and polishing their muskets.  The IETF looks exactly as unable to publish documents as its detractors claim it is.  A pox upon all of us (including me).

I should take the advice I gave a particularly odious interlocutor on another mailing list and go form my own standards group with blackjack and high-proof alcohol, I swear.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  brong@fastmailteam.com

--e51bcd270282c30698439e6489d027ad7e171261
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div style=3D"fon=
t-family:Arial;">On Thu, Oct 1, 2026, at 21:36, Rob Sayre wrote:<br></di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div>B=
ron Gondwana &lt;<a href=3D"mailto:brong@fastmailteam.com">brong@fastmai=
lteam.com</a>&gt; wrote:</div><div>&gt;&nbsp;From the last 24h of logs w=
e have about 96% TLS, 4% without TLS.</div><div>&gt; Plenty of which is =
spam of course, but I did enough of a random</div><div>&gt; sampling to =
see that not all is.</div><div><br></div><div>I believe you.</div><div><=
br></div><div>But the standard is not only for general purpose email pro=
viders.</div><div><br></div><div>There are many implementations that don=
't need to cope with that 4%, and should not be required to.</div><div><=
br></div><div>Besides, there is not a hardline approach here. The idea i=
s just to say nothing.</div><div><br></div><div>It's always an option to=
 support RFC 5321 and its predecessors too. After all, the proverbial pr=
inters in the basement will not be updated for this new RFC.</div><div><=
br></div><div>It's disappointing&nbsp;to have this deletion repeatedly m=
isstated as a requirement. Please, everyone, stop doing that. It is inte=
llectually dishonest, whether intentional or not.</div></div></blockquot=
e><div style=3D"font-family:Arial;"><br></div><div style=3D"font-family:=
Arial;">This whole mountain in a teacup is entirely about the question o=
f whether you can write software which claims to support this document w=
ithout allowing the operator to configure the ability to accept mail wit=
hout STARTTLS.</div><div style=3D"font-family:Arial;"><br></div><div sty=
le=3D"font-family:Arial;">Unfortunately we have a lot of civil-war re-en=
actment fanatics or whatever the equivalent is who want to die on hills =
about this exact text, so here we are, years after the bloody thing shou=
ld have been published, and there are still people dug into their trench=
es and polishing their muskets.&nbsp; The IETF looks exactly as unable t=
o publish documents as its detractors claim it is.&nbsp; A pox upon all =
of us (including me).</div><div style=3D"font-family:Arial;"><br></div><=
div style=3D"font-family:Arial;">I should take the advice I gave a parti=
cularly odious interlocutor on another mailing list and go form my own s=
tandards group with blackjack and high-proof alcohol, I swear.</div><div=
 style=3D"font-family:Arial;"><br>Bron.<br></div><div style=3D"font-fami=
ly:Arial;"><br></div><div id=3D"sig56629417"><div class=3D"signature">--=
</div><div class=3D"signature">&nbsp; Bron Gondwana, CEO, Fastmail Pty L=
td / Fastmail US LLC</div><div class=3D"signature">&nbsp; brong@fastmail=
team.com</div><div class=3D"signature"><br></div></div></body></html>
--e51bcd270282c30698439e6489d027ad7e171261--