Subject: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis?

From: Joseph Yee <[email-masked]>
Date: Mon, 17 Jan 2011 12:15:42 -0500

Issue #2:  new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis?
http://trac.tools.ietf.org/wg/eai/trac/ticket/2

Description 
---------------

Should the new parameter to VRFY/EXPN only be permitted after the SMTP client issued EHLO command and saw a response that included UTF8SMTPbis?

---------------

Please use this thread or the issue tracker for discussion. The end date of discussion is Tuesday, Jan 25 - 9pm Pacific Time and conclusion will be drawn afterwards.    

Best,
Joseph

---

From: Troy Starr <[email-masked]>
Date: Mon, 17 Jan 2011 22:39:12 -0800

Yes, it should only be permitted after the SMTP client issued an EHLO command and saw a response that included UTF8SMTPbis.

In general, I am leery of trying to establish a parameter extensibility model to any of the SMTP commands in this RFC.  It seems like the kind of thing that should happen in the core SMTP RFC (such as RFC 5321) while the actual extensions that take advantage of that extensibility model would be defined in separate RFCs like this EAI RFC.  So in the future, if someone wanted to define another parameter extension for these SMTP commands, but not imply EAI support, they may have to reference the very specific portions of the EAI RFC that deals with parameter extensibility while explicitly ignoring everything else.

That said, we are where we are and we need to be able to move forward.  I think both the server and client MUST explicitly indicate that they want the EAI behavior for these commands, and that the client MUST NOT include parameters on these commands if the server has not indicated support for them.  The EHLO advertisements from the server and a parameter on the commands from the client seem quite reasonable to achieve this.  I have no reason to believe this change will be a significant burden on implementers.

It might be useful to write a specific section that defines an extensibility model for VRFY/EXPN for easier external reference by other RFCs, and then a section that defines the explicit parameter that we'll be introducing for EAI support.

- Troy Starr

-----Original Message-----
From: Joseph Yee [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 9:16 AM
To: EAI WG
Subject: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis?

Description 
---------------

---------------

Best,
Joseph

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 09:25:11 -0500

yes

--On Monday, 17 January, 2011 12:15 -0500 Joseph Yee
<[email-masked]> wrote:

> Issue #2:  new parameter to VRFY/EXPN only after EHLO with
> UTF8SMTPbis? http://trac.tools.ietf.org/wg/eai/trac/ticket/2
> 
> Description 
> ---------------
> 
> Should the new parameter to VRFY/EXPN only be permitted after
> the SMTP client issued EHLO command and saw a response that
> included UTF8SMTPbis?

---

From: John Levine <[email-masked]>
Date: 18 Jan 2011 16:07:57 -0000

>Yes, it should only be permitted after the SMTP client issued an EHLO
 command and saw a response that included UTF8SMTPbis.

+1

>It might be useful to write a specific section that defines an
>extensibility model for VRFY/EXPN for easier external reference by
>other RFCs, and then a section that defines the explicit parameter
>that we'll be introducing for EAI support.

I'd rather not step into that tarpit.  When the followon to 5321 is
written, I have no doubt that whoever is writing it will be aware of
what EAI did, and can consider whether VRFY and EXPN need an
extensibility model.  Since this is, as far as I can tell, the first
extension in 30 years, probably not.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jan 2011 12:54:40 -0500

--On Tuesday, 18 January, 2011 16:07 +0000 John Levine
<[email-masked]> wrote:

>> extensibility model for VRFY/EXPN for easier external
>> reference by other RFCs, and then a section that defines the
>> explicit parameter that we'll be introducing for EAI support.
> 
> I'd rather not step into that tarpit.  When the followon to
> 5321 is written, I have no doubt that whoever is writing it
> will be aware of what EAI did, and can consider whether VRFY
> and EXPN need an extensibility model.  Since this is, as far
> as I can tell, the first extension in 30 years, probably not.

Procedurally, that would be a new feature and would presumably
cause a reset to Proposed, It would change the conformance model
so one might be able to get away with it with enough
procedural-lawyering, but I'm not convinced that it would be
desirable.   I think the right advice about this, for other than
the narrow EAI case, is the same as the advice for all other
general extension models for SMTP -- develop a separate I-D to
put the extension through at Proposed, diligently pursue
implementation reports etc., to get that spec to Draft Standard,
and then, timing permitting, argue for including the feature in
5321bis when it is prepared for Full Standard.

For the record, I am neither volunteering to do that work nor
recommending that anyone else do so -- just pointing out what
would be procedurally correct if someone were so inclined.

    john
\

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 19 Jan 2011 16:04:59 +0900

> http://trac.tools.ietf.org/wg/eai/trac/ticket/2

Yes.

Regards,   Martin.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Jan 2011 12:22:30 -0000

>
> Should the new parameter to VRFY/EXPN only be permitted after the SMTP  
> client issued EHLO command and saw a response that included UTF8SMTPbis?

Yes.

But note that its use after the EHLO cannot be enforced by the server. It  
needs to take the form:
    "Clients MUST NOT use this parameter unless ..."
If clients fail to heed that, then "garbage in - garbage out" will apply.

-- 
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

---

From: [email-masked]
Date: Thu, 20 Jan 2011 16:47:52 -0800 (PST)

> But note that its use after the EHLO cannot be enforced by the server. It

Well, it could, since the server can in theory keep track of whether or not
EHLO has been issued, and refuse to allow the parameter if no EHLO has been
seen.

But this opens up a can of worms. Suppose, for example, you want to further
restrict use of UTF8SMTPbis to clients that have done a STARTTLS, or have
authenticated with the correct identity, or whatever. (RFC 5321 makes it very
clear that sites are free to impose these sorts of policy-based restrictions.)
So it might be the case that the iniitial EHLO response the client got from
the server didn't include UTF8SMTPbis but the one it got later did.

So now the server has to track whether or not it sent back an EHLO response
with the "right stuff" in it. This is added complexity for no tangible benefit,
and is why I oppose saying "Servers MUST NOT accept VRFY/EXPN with the
parameter without first having offered the extension in an EHLO response."

>     "Clients MUST NOT use this parameter unless ..."

That's exactly the wording that I think needs to be used.

> If clients fail to heed that, then "garbage in - garbage out" will apply.

Yep.

				Ned

---

From: John Levine <[email-masked]>
Date: 21 Jan 2011 01:33:12 -0000

>> But note that its use after the EHLO cannot be enforced by the server.

Standards tell you how to write your code to interoperate with other
systems that have implemented the same standard.  The answer to
questions about what happens if you do something other than what the
standard says boil down to "Who knows?" and "Don't do that."

So if you want your EAI VRFY to work, insofar as VRFY works at all,
say EHLO first.

>That's exactly the wording that I think needs to be used.

Right.

R's,
John

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 12:23:19 +0100 (CET)

>>> client issued EHLO command and saw a response that included UTF8SMTPbis?

YES!

>> If clients fail to heed that, then "garbage in - garbage out" will apply.

correct. Let's add "Clients MUST NOT use this parameter unless ..."

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

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca