--On Monday, March 15, 2021 14:26 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
--On Monday, March 15, 2021 08:58 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
SMTP servers have always been able to announce a
limit, in a reply, which means that the client first
needed to issue a command. The mechanism specified
here avoids the overhead of that interactions, by
announcing limits prior to any substantive interaction.
Nice. Added.
I wonder. Along with the "first digit" rule, SMTP has been
fairly clear that SMTP clients should not depend on trying to
parse or interpret reply text except for VRFY and EXPN for
which syntax is actually given for replies.
Which establishes the precedent for parsing replies given a
signal to do so.
Except that I thought (although I can't find it right now) that
5321 called that out as an explicit exception. Certainly they
and the forwarding and "try instead" replies are the only ones
for which an exact syntax is discussed. But I think the key
phrase above is "signal to do so", with which I agree. See
below.
Assuming this is the sort
of announcement you and Dave have in mind, suppose the client
sends
MAIL FROM:<foo(_at_)example(_dot_)com>
and the server responds
250 OK. No more than 20 recipients
would we seriously expect the client to interpret and use that
information?
Of course not, but how about:
250 2.5.314159 RCPTMAX=n
And that gets into a bit of tension between the "first digit"
rule in 5321 and extended codes, perhaps particularly in the
case of MAIL, where the fourth paragraph of Section 3.3 ("This
command tells...") says, apparently very specifically 'If
accepted, the SMTP server returns a "250 OK" reply", not "250
<whatever it feels like> which the client is expected to read
and understand". But if that needs to be addressed at all, it
should be addressed in 5321bis, not in your draft... as long as
the draft does not increase the confusion. See below.
In addition, if the answer were "yes", what would prevent a
connection-opening response of
220 SNAFU SMTP Server, v 666, no more than 25 recipients
allowed
which is no less an announcement and of course avoids having
to wait for any commands to be issued, even EHLO.
You can't repeat the announcement so you need the ability to
include the response in EHLO, which is the obvious way to
revise the limits after AUTH or STARTTLS. And EHLO is required
in all three cases, so aside from not being soonest in one
case there's no downside I can see.
Good reason, but I think I wasn't clear about the point I was
trying to make, which was not about the design --with which I'm
quite happy-- but with Dave's specific paragraph which, in its
form as above, I think could add to the confusion. Why?
Because, as soon as you say "SMTP servers have always been able
to announce a limit, in a reply...", it seems to me the
immediate question is
'Sure, they can "announce" whatever they like, but how
would that work in practice? If, for example, the client
sends a MAIL comment and gets back "250..." or even
"2...", and moves on to the next command because _any_
2yz response to the MAIL commend implies "ok, move on to
the next command"'.
The server could equally respond to a MAIL command with "250 Is
it not a lovely day?". That would constitute an announcement of
sorts, but the expectation that it would be acted on would be
the same: in the absence of some spec that goes beyond 5321,
both are really comments, not announcements. Now, if the
paragraph had said, e.g., "...limit, in a reply with an enhanced
status code,..." I probably would not have batted an eyelash
because, at that point, it would be clear that the server was
asking the client to do something different than "get as far as
250 and then move on". But...
I guess I could write all these reasons down, but at some
point text about design choices becomes a hindrance to
understanding the acutal protocol. I think all this cross that
line, whereas Dave's text did not.
We are in complete agreement with your first sentence. All I've
suggesting is that, absent some additional words, Dave's text
could add confusion and become a hindrance. I am agnostic as
to whether it would be better to add the words (few of them and
perhaps using the example above) or to drop the text. The key
design choice, IMO, is to have a facility for announcing these
limits that is precisely defined (which you have, IMO, done) and
that a client that is aware of and interested in that particular
extension keyword will know, rather exactly, now to interpret
it. That is what the extension mechanism is all about.
To push that explanation a bit further, we could, in principle,
define an extension of, e.g.,
MANDATORYEXTENDEDCODES
or
YOUBETTERREADREPLYTEXT
in such a way that the server would advertise it and, if the
client did not include some sort of confirmation as part of the
MAIL command or whatever command followed the EHLO response, the
server might find it perfectly reasonable to respond
55z Then I don't want to talk with you, go away
(554 would be close, but not exact)
IMO, that would be a fairly dumb idea, but those are the only
way I can think of to make an "announcement" as part of a reply
reliable. That ultimately just demonstrates another reason why
your proposal is a better idea, but also shows, IMO, how
slippery the slope gets if you start discussing alternate
strategies... and brings me back to the line you describe above
and about which, again, I agree.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp