Subject: [EAI] EAI review topic: VRFY/EXPN

From: John C Klensin <[email-masked]>
Date: Mon, 27 Dec 2010 19:21:35 -0500

(writing as co-chair and incorporating the introduction to the
note I sent a few minutes ago by reference)

Topic: The description of VRFY and EXPN handling in 5336bis is
not adequate.  Whatever is done, we will have to change/fix it.
In the questions below, I've mentioned VRFY but I assume that
EXPN would get exactly the same treatment.

Questions: 

(1) Should VRFY be retained as is, with the parameter, but with
a restriction that the parameter MUST NOT be used without EHLO
appearing first.

(2) Should VRFY be retained as is, with the parameter and
without the "ok to use VRFY without a session, i.e., without
EHLO first".  Note that this would be the first time an SMTP
extension has been permitted without explicit server permission
via EHLO and that it involves a small risk of non-EAI-aware
servers parsing the parameter as part of a name sent by a client.

(3) Should we move toward a new command, replacing VRFY, but
with more specific syntax that explicitly provides for
parameters and, presumably, a mail session?   Note that, if the
answer to this is "yes", someone would need to generate a
proposal that could be processed separately from the EAI effort.
While generating the proposal is no problem, the specification
of the new command would create a normative dependency from
5336bis and that might slow things down in terms of publication
of 5336bis/ 5335bis/ 5337bis.

Discussion references: Many notes on the mailing list in the
last several days.

    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 29 Dec 2010 17:05:10 +0900

In the hope to move the debate forward, and after the clarifications by 
Alex and Ned, but not an email infrastructure insider, my preferences below.

> a restriction that the parameter MUST NOT be used without EHLO

That seems like an easy fix.

> servers parsing the parameter as part of a name sent by a client.

It seems that this is what the reviewers have advised against, so I 
guess we should give up on it.

> of 5336bis/ 5335bis/ 5337bis.

I'm not sure why this would need to be separate from EAI. It's obviously 
for EAI. Of course, we have to come up with new command names, but that 
should be easy (some already circulated on the list). Apart from that, 
take the current syntax, and change text from "new syntax on old 
command" to "new command", which I'd guess is mostly a clerical 
exercise. Or did I get something wrong?

Anyway, my order of preference would be (1), (3), (2).

Regards,   Martin.

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Dec 2010 04:38:29 -0500

--On Wednesday, December 29, 2010 5:05 PM +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>...
>> parameters and, presumably, a mail session?   Note that, if
>> the answer to this is "yes", someone would need to generate a
>> proposal that could be processed separately from the EAI
>> effort. While generating the proposal is no problem, the
>> specification of the new command would create a normative
>> dependency from 5336bis and that might slow things down in
>> terms of publication of 5336bis/ 5335bis/ 5337bis.

> I'm not sure why this would need to be separate from EAI. It's
> obviously for EAI. Of course, we have to come up with new
> command names, but that should be easy (some already
> circulated on the list). Apart from that, take the current
> syntax, and change text from "new syntax on old command" to
> "new command", which I'd guess is mostly a clerical exercise.
> Or did I get something wrong?

For the record, my mentioning "new command" was to be sure the
WG considered all options and because a discussion, I hope
brief, of what a new command would do for us may help to
illuminate this issues and risks of the other choices.  I did
not mention it to advocate going down that path: the essence of
the argument against it is that it involves fairly high cost to
avoid a problem that is unlikely to ever occur in practice.

That said, the reason for "separate from EAI" is that there is
specific syntax in RFC 5321 for parameters for MAIL and RCPT
(Section 4.2).  It does not do so for DATA and, even though the
base command does not accept arguments, making the syntax is
mind-numbingly obvious, we invented a new command (BDAT) for a
parameterized version in RFC 3030.  In theory, and following the
same path now being suggested for VRFY/EXPN, we could have
simply added more parameters to DATA rather than making up BDAT.
If I recall, the big concern was that such parameters would
simply be ignored as noise or comments on the DATA command -- a
slightly different situation than with VRFY.

But, while the "extra stuff gets ignored" concern probably does
not apply to VRFY (or EXPN) any more than they would to MAIL or
RCPT, VRFY and EXPN do accept arguments and have been
misunderstood and misused in ways that make it impossible to
distinguish between the last part of the argument String and a
parameter with 100% confidence.  If we need to specify a syntax
for parameters with VRFY (technically speaking, whether with a
new command name or not), we don't have an established model for
adding parameters to VRFY and EXPN.  Establishing a syntax for
VRFY-with-optional-parameters (or
NewCommand-with-optional-parameters) is an RFC 5321 update
issue, but not an EAI issue.   

At least that is how I understand the situation and the concern.

best,
    john

---

From: [email-masked]
Date: Wed, 29 Dec 2010 10:46:28 -0800 (PST)

> That seems like an easy fix.

Agreed, as long as there's no requirement that servers MUST enforce this
restriction.

> guess we should give up on it.

I'm less worried about this than others are, but it's a legitimate concern.

> > proposal that could be processed separately from the EAI effort.

I would hope that any refinement of VRFY would, in addition to allowing actual
addresses to be specified (and defining the semantics for what such a query
means), also provide for structured return value. In short, if we're going to
go down the new command path, we should look at what additional needs could be
met by such a mechanism. But all this is far outside of EAI's scope.

> I'm not sure why this would need to be separate from EAI.

The main reason, aside from the obvious process issues, is that this isn't
quite the right group to design and review such a proposal.

> It's obviously for EAI.

Well, that depends on how far the proposal goes. If all we're doing is defining
VFY8/EXP8 and changing nothing else, then sure, this could be part of EAI, just
as adding a parameter to the existing commands can be. (I've already explained
why I strongly prefer a parameter to additional single-purpose commands.)

But once you sit down and define a proper replacement, at an absolute minimum
you're going to want to make it able to accept addresses. And as I noted, this
isn't the right group for that.

> Of course, we have to come up with new command names, but that

> Anyway, my order of preference would be (1), (3), (2).

That's mine as well.

				Ned

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Dec 2010 10:34:49 -0000

> Anyway, my order of preference would be (1), (3), (2).

+1 (with especial emp[hasis on (1)).

If you add John Levine's STARTEAI command as (4), then my preference would  
be
(1), (3), (4), (2).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5