[Emailcore] Re: Christopher Inacio's Discuss on draft-ietf-emailcore-as-29: (with DISCUSS and COMMENT)

[Viktor Dukhovni <[e-mail]>]

On Sun, Sep 13, 2026 at 05:36:01PM -0400, John C Klensin wrote:

> (i) Unlike the clear requirement for a scope statement for TS
> document in the second paragraph of Section 3.1 of RFC 2026 (a
> requirement the IESG has sometimes ignored), there is no equivalent
> requirement for TS documents in Section 3.2.  It is my belief that
> the requirements of Section 3.2 are met by the Introduction.

There we find:

   [...]         An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see section
   3.3).

which then expanded to include:

   The broadest type of AS is a comprehensive conformance specification,
   commonly called a "requirements document", for a particular class of
   Internet systems, such as Internet routers or Internet hosts.

With that in mind, FWIW the scope of AS is in my view systems that perform
relaying of email messages, especially across ADministrative Management
Domains (ADMDs, Section 2.3 of RFC5598).

The transport of email messages within an ADMD may be highly specialised
to a single vendor's techology stack, or a uniform set of practices that
depart materially from those seen on the public Internet.  Authenticated
TLS between internal email relays may be required in some deployments,
with perhaps GSSAPI authentication of client (almost never seen in
cross-ADMD scenarios).  Routing of email to the appropriate nexthop
may not be MX based, ...

> If it would move things along to change the title of Section 1 to
> "Introduction and Scope Statement", I don't imagine there would be any
> objection but doubt that the best interests of the IETF or the
> Internet community would be particularly well-served by holding the
> document up for that change.

If cross-ADMD email handling is the principal scope of the AS, then
the introduction's:

    In order to promote interoperability amongst senders, receivers, and
    intermediaries, it includes discussions and recommendations about
    selected features of SMTP, IMF, and certain extensions to them that
    are required, recommended, or to be avoided except in special cases.

could be somewhat more explicit, but it is also unclear to me that such
clarification warrants another round of discussion and edits.

> (ii) If this is really about making a statement about the public
> versus private Internet(s), as some earlier comments suggested, I
> think that would be a mistake.  I, and others, have tried to explain
> the problem before, but can't remember the distribution lists, so let
> me try to summarize.  Because of its history and the large variety of
> arrangements for originating and receiving messages, email is a
> strange creature.  For example, on the origination and submission
> end, constructing and sending a message over a web interface will
> typically be on the public Internet but a user of a traditional Mail
> User Agent (MUA) will often be operating on a private network with
> the boundary between that private network and the public one
> occurring either between the MUA and the client side of a Submission
> Server or between the Submission Server and the next hop.  That is
> further complicated by the common use of SSH (or SSH-like) tunnels
> between the MUA and whatever comes next and, for this document, by
> the fact that the WG Charter fairly explicitly put Message Submission
> (RFC 6409, etc.) out of scope.

Leaving submission out of scope (and any use of SSH, Web UIs, ...) is
entirely consistent with a primary focus on cross-ADMD message delivery.

> Certainly, if the IESG insisted and
> the WG was agreeable, we could write text to explain those issues,
> but it would probably be long, not help reduce any confusion that
> existed among actual email implementers or those trying to make
> decisions about choices of systems, and raise issues about the limits
> of the WG charter.
> 
> If you believe more is needed, can you be a little bit more specific
> about what you are looking for?

I am not opposed to adding context, but don't see a glaring need.

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