Re: draft-freed-smtp-limits
Hector Santos <[email protected]> Fri, 4 Aug 2023 15:54:06 -0400
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <[email protected]> |
--===============4511217850543111152== Content-Type: multipart/alternative; boundary="Apple-Mail=_386DB3D3-1AA3-4BC1-B46F-75959A1437B7" --Apple-Mail=_386DB3D3-1AA3-4BC1-B46F-75959A1437B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I always supported Ned=E2=80=99s (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 =E2=80=99t 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=3D4 = can better trained smart smtp clients to calm down their outbound = clients. LOL, I always wanted to say it =E2=80=94 Ship it!! <g> =E2=80=94 HLS > On Aug 4, 2023, at 10:47 AM, John C Klensin <[email protected]> wrote: >=20 > Hi. >=20 > 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: >=20 > * 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. >=20 > * 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? >=20 > 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? >=20 > 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. >=20 > 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. >=20 > john >=20 >=20 > _______________________________________________ > ietf-smtp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-smtp >=20 --Apple-Mail=_386DB3D3-1AA3-4BC1-B46F-75959A1437B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">I always = supported Ned=E2=80=99s (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.<div><br></div><div>What I don =E2=80=99t see in my review of the = 05 draft are Connection Limits. Example is sending bulk mail to = <a href=3D"http://yahoo.com">yahoo.com</a>. Out of the box, its = connection limit is 4. Exposure of a CONNMAX=3D4 can better = trained smart smtp clients to calm down their outbound = clients.</div><div><div><br></div><div>LOL, I always wanted to say it = =E2=80=94 Ship it!! = <g></div><div><br></div><div>=E2=80=94</div><div>HLS<br><div><br><bl= ockquote type=3D"cite"><div>On Aug 4, 2023, at 10:47 AM, John C Klensin = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>Hi.<br><br>As a few of you = might have noticed, I, with some help from<br>Murray, got = draft-freed-smtp-limits-05 posted yesterday (it<br>should have gone up = Friday, but that is another story that you<br>can probably deduce at = least part of from the note at the top if<br>you are interested). = It contains changes/ corrections that,<br>with two major = exceptions, reflect all of the<br>comments/suggestions I could find on = the mailing list since the<br>prior version was posted in early = November. Those exceptions<br>were:<br><br>* Suggestions for = significant changes in the protocol such as<br>adding additional limit = keywords. I decided to put them aside<br>on the grounds that I = have no way to know how Ned would have<br>felt about them and that, in = turn, would violate the boundary<br>I'm trying to keep about keeping his = name on the document iff<br>any changes are clearly aligned with what he = would have wanted.<br>Especially given the low-pain registration plan = for new keywords<br>(see below), deferring those suggestions seems = reasonable but<br>I'm happy to hear arguments to the contrary.<br><br>* = The whole business about caching (Section 3.8). Dave pointed<br>out an = issue or two in November and Murray pointed out a<br>different set in an = AD review of the draft. I fixed the issue<br>Dave raised that was = obvious, but then there are the others.<br>While I've been trying to = ignore the issues, that clearly will<br>not work. Those issues = include conditions under which the<br>cached data should be reset, what = a new EHLO command in the same<br>session, or a different session, in = which the extension is not<br>mentioned means (including where a server = response should<br>include limit values or whether that is optional, = etc. Options<br>that I can see now include just dropping the = subsection or<br>trying to identify and cope with all of the cases the = current<br>text leaves uncertain. The latter would take us into = "what<br>would Ned have wanted" territory as well and some = non-trivial<br>technical issues. Thoughts?<br><br>There is also an = odd complication with the IANA considerations<br>and registration of new = limits (See Section 7.2). The text says<br>"Specification = Required" but the current registry and<br>subregistry for Service = Extensions and their parameters specify<br>Standards Action or = IESG-approved Experimental. We went through<br>the problems that = causes, and why Specification Required isn't a<br>good answer either, in = EMAILCORE and I think the two-model<br>system specified there is = probably right for this case,<br>especially since approval of 5321bis = will change the<br>requirements for those registries. So, unless = we want LIMITs<br>and its parameters to be unique among extensions, = either I need<br>to write some tricky text, or we need to create a = normative<br>reference to 5321bis (holding up publication of this), or = the<br>either long-promised revision to 8126 or the = long-threatened<br>update to it to include just that option (an I-D I = started on<br>two weeks ago when I noticed the "need to do something = about<br>this" note in 5321bis). Thoughts?<br><br>Finally, = I'd appreciate people looking at what I've done with<br>the = Acknowledgments (Appendix A), seeing if it feels about right<br>and, if = not, making suggestions.<br><br>The draft clearly needs another revision = before going to IETF<br>LC, but I'd like to get that posted while things = are fresh in<br>our minds. So, comments and suggestions would be = very much<br>appreciated, but, please, soon.<br><br> = john<br><br><br>______________________________________________= _<br>ietf-smtp mailing = list<br>[email protected]<br>https://www.ietf.org/mailman/listinfo/ietf-s= mtp<br><br></div></div></blockquote></div><br></div></div></body></html>= --Apple-Mail=_386DB3D3-1AA3-4BC1-B46F-75959A1437B7-- --===============4511217850543111152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-smtp mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-smtp --===============4511217850543111152==--