Re: [ietf-smtp] draft-freed-smtp-limits

I always supported Ned’s (rip) work with advertising ESMTP limits.  It is applicable in controlled areas where it can help clients with the EHLO posting of session and transaction limits.

What I don ’t see in my review of the 05 draft are Connection Limits.   Example is sending bulk mail to yahoo.com <http://yahoo.com/>.  Out of the box, its connection limit is 4.    Exposure of a CONNMAX=4 can better trained smart smtp clients to calm down their outbound clients.

LOL, I always wanted to say it — Ship it!! <g>

—
HLS

> On Aug 4, 2023, at 10:47 AM, John C Klensin <john-ietf@jck.com> wrote:
> 
> Hi.
> 
> As a few of you might have noticed, I, with some help from
> Murray, got draft-freed-smtp-limits-05 posted yesterday (it
> should have gone up Friday, but that is another story that you
> can probably deduce at least part of from the note at the top if
> you are interested).  It contains changes/ corrections that,
> with two major exceptions, reflect all of the
> comments/suggestions I could find on the mailing list since the
> prior version was posted in early November.  Those exceptions
> were:
> 
> * Suggestions for significant changes in the protocol such as
> adding additional limit keywords.  I decided to put them aside
> on the grounds that I have no way to know how Ned would have
> felt about them and that, in turn, would violate the boundary
> I'm trying to keep about keeping his name on the document iff
> any changes are clearly aligned with what he would have wanted.
> Especially given the low-pain registration plan for new keywords
> (see below), deferring those suggestions seems reasonable but
> I'm happy to hear arguments to the contrary.
> 
> * The whole business about caching (Section 3.8). Dave pointed
> out an issue or two in November and Murray pointed out a
> different set in an AD review of the draft.  I fixed the issue
> Dave raised that was obvious, but then there are the others.
> While I've been trying to ignore the issues, that clearly will
> not work.  Those issues include conditions under which the
> cached data should be reset, what a new EHLO command in the same
> session, or a different session, in which the extension is not
> mentioned means (including where a server response should
> include limit values or whether that is optional, etc.  Options
> that I can see now include just dropping the subsection or
> trying to identify and cope with all of the cases the current
> text leaves uncertain.  The latter would take us into "what
> would Ned have wanted" territory as well and some non-trivial
> technical issues.  Thoughts?
> 
> There is also an odd complication with the IANA considerations
> and registration of new limits (See Section 7.2).  The text says
> "Specification Required" but the current registry and
> subregistry for Service Extensions and their parameters specify
> Standards Action or IESG-approved Experimental.  We went through
> the problems that causes, and why Specification Required isn't a
> good answer either, in EMAILCORE and I think the two-model
> system specified there is probably right for this case,
> especially since approval of 5321bis will change the
> requirements for those registries.  So, unless we want LIMITs
> and its parameters to be unique among extensions, either I need
> to write some tricky text, or we need to create a normative
> reference to 5321bis (holding up publication of this), or the
> either long-promised revision to 8126 or the long-threatened
> update to it to include just that option (an I-D I started on
> two weeks ago when I noticed the "need to do something about
> this" note in 5321bis).   Thoughts?
> 
> Finally, I'd appreciate people looking at what I've done with
> the Acknowledgments (Appendix A), seeing if it feels about right
> and, if not, making suggestions.
> 
> The draft clearly needs another revision before going to IETF
> LC, but I'd like to get that posted while things are fresh in
> our minds.  So, comments and suggestions would be very much
> appreciated, but, please, soon.
> 
>   john
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
> 