[Top] [All Lists]

Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax

2007-07-15 12:21:54

--On Sunday, July 15, 2007 7:25 PM +0200 "Peter J. Holzer" <hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:

On 2007-07-14 22:25:43 -0700, SM wrote:
Note that the draft-04 mentions that "Server implementations"
should  support both VRFY and EXPN and leaves it to local
installations to  disable them if need be.  By dropping them,
we are removing  functionality that is useful for debugging.

They could be moved to an extension. EXPN is already optional
and while VRFY must be supported it can be (and is frequently)
turned off - so in practice you can't rely on it. The only
difference to other extensions is that they are specified in
the core SMTP spec instead of in a separate RFC.

Moving them to a separate RFC would reflect current practice.
However, this may be too large a change for the transition
from proposed to draft standard.

In my opinion, they cannot be moved to an extension for the procedural reason that RFC 1123 requires their support. The dancing around about servers being required to support them but installations taking them out --and how that was supposed to be done/reflected down to specific reply codes-- was a DRUMS decision reflecting that 1123 requirement. Despite some other tuning, 2821bis has not changed that part of the specification in any substantive way.

That is probably just another way of saying what Peter suggests above: this is too big a change for proposed-> draft just because, although the rules in 2026 and its successors are much better designed for new specifications rather than updating old (full)standards, the baseline here is presumably the 821/ 1123 requirements, not the clean slate of a new proposed standard.

That said, I could see doing something else if there was general consensus that it would be worthwhile. Partially because of the circumlocutions and security consideration issues, there is a lot of text about VRFY and EXPN in 2821bis. I may regret saying this but, without looking at the spec, I think I could separate that material out into a separate document called "SMTP VRFY and EXPN Commands" or words to that effect. This would not change the basic specification or requirements at all, but would shorten the SMTP spec itself, keeping text that that did not have any VRFY/EXPN details.

The arguments against doing that are that any major textual change risks getting things wrong and it would require that the now-long-overdue ABNF revision project break the ABNF up for two separate documents.

Again, just my personal views.