<pseudo-chair hat>
Matti's questions asking for guidance on maximum limits are in scope.
Asking for an EHLO response to indicate any such limits is out of scope.
</pseudo-chair hat>
<implementor's hat>
Side note: An implementation is free to respond with 4xx (e.g., 421,
451 or 452) to the MAIL FROM whenever it wants to shut down the
connection. And some implementations *do* choose to do so because of
local policy decisions.
</implementor's hat>
<pseudo-chair hat again>
Folks, I'd like to request a favor: Please use separate email messages
to the group to totally introduce new topics. An example is the chapter
naming style issue introduced below.
</pseudo-chair hat again>
Tony Hansen
tony(_at_)att(_dot_)com
Matti Aarnio wrote:
On Thu, Mar 29, 2007 at 09:11:29AM -0400, John C Klensin wrote:
...
However, I think the conclusion is the same: since there are no
restrictions on this now and imposing any limits (or
announcement of limits) in the client-server transaction would
require a new extension, it is probably out of scope. I imagine
we could include some general guidance if there were
sufficiently strong consensus behind it, however.
John,
I am not asking for a new extension, just clarification of
the specification so that Joe Random Spamflighter can easier
understand what is specified, and what is not.
Perhaps there should be a new Appendix that tabulates limits
in condensed manner making checking them simpler in style of
IEEE 802.* Conformance Pro Formas ?
It would list limits and references to main text for rationales.
Somewhat in style of RFC 1123 "SMTP REQUIREMENTS SUMMARY" table ?
That table is more about "feature checklist" than protocol
parameter profile listing, but applying the idea.
.. and of course, there is completely missing a text about
how many MAIL--DATA transactions there are expected to be
supported in a given connection, and how long that connection
is expected to be alive. It can be inferred, but explicite
telling is better.
Also, a style issue is that when a chapter is defining more than
one thing, that chapter should have numbered sub-chapters.
It is far easier to point to somebody that "your filter is
violating expectations at 1.2.3.4.5 of rfc-12345" than
".. at chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"
Similarly, lacking the detailed parameter conformance checklist
means that one has to go through the main text, and to spot
there all small details in very lengthy chapters.