[Emailcore] Re: [Last-Call] Re: Re: draft-ietf-emailcore-as-28 ietf last call Secdir review

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 30 April 2026 06:38 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: emailcore@mail2.ietf.org
Delivered-To: emailcore@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 216BAE649558 for <emailcore@mail2.ietf.org>; Wed, 29 Apr 2026 23:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777531085; bh=9KCEInuCLo4lu4j8SOH0qjqNxfjLjPfh1vXcV9W+Vtw=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=Dzu2yQPL7IFoZYQ4wKnGFOyDHZo0yqT0/14QTAcc4StM4HNgzBC8UJuSmMkN9E6nm wxRUHwyAAIjkoecsn+jqFdjiIRPdxKyxf2C5ssm+5bSCQadt7n3SMG65zoesAaDUme L5wqLtL4IKNrlFmfvuvKTzJgaUQRpVjRrp56qSdY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YATyCqyXP9Wj for <emailcore@mail2.ietf.org>; Wed, 29 Apr 2026 23:38:04 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 91C21E649550 for <emailcore@ietf.org>; Wed, 29 Apr 2026 23:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1777531080; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=9KCEInuCLo4lu4j8SOH0qjqNxfjLjPfh1vXcV9W+Vtw=; b=Gfi/uOutqb9xY0UExuYylmkkNSk4yo8a873FVNHfMVJT4liPa1CkfKd/39R+ZL5C9chy6 e9TxNLb81ewaQCOOFAgTWG1AXB/owo3cfsg5B2vYWlH+IKwg3LNADFU4liO1uid1KR7Nkpu c1WlMhPhhTN0HKq67dITfDuVJPrZ4is=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id B02C7937704; Thu, 30 Apr 2026 16:38:00 +1000 (AEST)
Date: Thu, 30 Apr 2026 16:38:00 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: emailcore@ietf.org
Message-ID: <afL4yPBbmhw7iimh@chardros.imrryr.org>
References: <5d69c4a4-e16c-4c0b-bb0e-09887d062da9@lear.ch> <CABcZeBOK0wR5i1Y9Lxa6JzgF6nxzLU25pZa4Sida01VaowBGGA@mail.gmail.com> <fc87c6da-4c02-4030-84f1-092a8511c5c3@lear.ch> <CABcZeBP5q4kWtSXYhkStC7Yc-OYmVNfEJ4Dn7Ef_RNf_g74ucA@mail.gmail.com> <16e19e54-7f69-4ecc-a5f0-dcffd7a0d3b2@lear.ch> <CABcZeBP0e0TS4F_aQvvER+pt87rgGiARudKTEKzD0roEyESvZQ@mail.gmail.com> <8DC02587-26C8-428A-9D88-44AEEFDFE1C2@episteme.net> <CABcZeBMRsVsBnvbW_g0aR8M80RcQ0QWHqYxQk5dK_9-Dm1Tccw@mail.gmail.com> <afLhV-sxsm4l5UqQ@chardros.imrryr.org> <01424307-50ed-4850-93a8-50a0d0946d92@lear.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <01424307-50ed-4850-93a8-50a0d0946d92@lear.ch>
Mail-Followup-To: <emailcore@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: BI243BCBPNZEJR6UW5INOEC64P653EHX
X-Message-ID-Hash: BI243BCBPNZEJR6UW5INOEC64P653EHX
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: emailcore@ietf.org
Subject: [Emailcore] Re: [Last-Call] Re: Re: draft-ietf-emailcore-as-28 ietf last call Secdir review
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/Dfz38TFB-R3ABHx4nU6qZWEyB8s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Owner: <mailto:emailcore-owner@ietf.org>
List-Post: <mailto:emailcore@ietf.org>
List-Subscribe: <mailto:emailcore-join@ietf.org>
List-Unsubscribe: <mailto:emailcore-leave@ietf.org>

On Thu, Apr 30, 2026 at 07:51:19AM +0200, Eliot Lear wrote:

> There are times when SMTP servers get misconfigured and simply stop offering
> STARTTLS.  I've had this happen a few times on my server where the private
> and public keys fell out of sync.  Neither sendmail nor postfix are so
> integrated with LE (for example) that things Just Work out of the box.  The
> server falls back to not offering STARTTLS.  What should the client do in
> these circumstances? Produce a 4xx or a 5xx and where is that documented?

When a server does not offer STARTTLS, clients with a typical
opportunistic TLS configuration will send in the clear.

If the server operator has published DANE TLSA records (or the related
poor-man's DANE in the form of MTA-STS, which lacks downgrade-resistant
policy discovery), or the sender requested REQUIRETLS, then the client
might either defer the message if none of the MX hosts are usable
(generally recommended by the Postfix maintainers, the specifications
are mostly silent), or bounce immediately (generally not recommended by
the Postfix maintainers, but REQUIRETLS is an exception).

MTAs acting as SMTP clients of course don't produce 4XX or 5XX result
codes, that's not their role in the protocol, but they can and do
include ehhanced 4.X.Y or 5.X.Y RFC3463 enhanced status codes in any
resulting bounce.

Postfix reports:

    - 4.7.0 when policy lookup fails
    - 4.7.4 when TLS is required by policy, but not offered.
    - 4.7.5 when policy requires TLS, but TLS is not locally
      available.
    - 4.7.5 for failure to establish a TLS connection that meets
      policy requirements.
    - 5.7.10 when REQUIRETLS is requested, but STARTTLS is refused
      by the nexthop MX.
    - 5.7.30 when REQUIRETLS is requested, but not supported by
      any nexthop MX.

Some of these choices are best effort to find closest code point,
others are a good match.

-- 
    Viktor.  🇺🇦 Слава Україні!