On Thu, Mar 29, 2007 at 09:11:29AM -0400, John C Klensin wrote:
--On Thursday, 29 March, 2007 14:49 +0200 Arnt Gulbrandsen
<arnt(_at_)oryx(_dot_)com> wrote:
John C Klensin writes:
RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a
minimum of 100 RCPT commands must be accepted, and is quite
specific about what happens in limits are exceeded.
I thought that applies to recipients for the same message.
MAIL FROM
RCPT TO
RCPT TO
RCPT TO
...
DATA
The other case is not covered AFAICT:
MAIL FROM
RCPT TO
DATA
MAIL FROM
RCPT TO
DATA
...
That is correct. I had understood the earlier message to be
asking about recipients-per-message, not messages-per-connection.
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.
Just my opinion.
john
--
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>