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

From: Shawn Steele <[email-masked]>
Date: Fri, 21 Jan 2011 01:00:21 +0000

> > But note that its use after the EHLO cannot be enforced by the server. It
> > needs to take the form:

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

Well, but the server still couldn't "enforce" that the client not send it.  It could fail or something if the client went ahead and did it, but the server can't prevent bad client behavior.

-Shawn

---

From: [email-masked]
Date: Thu, 20 Jan 2011 17:46:58 -0800 (PST)

> Well, but the server still couldn't "enforce" that the client not send it. 

Ah, that makes more sense. Of course it can't.

> It could fail or something if the client went ahead and did it, but the server
> can't prevent bad client behavior.

Very true. I just don't want servers to be required to check for it in this
case.

				Ned

---

From: Shawn Steele <[email-masked]>
Date: Fri, 21 Jan 2011 01:49:51 +0000

I figure new servers will probably check (since they sent it), and old servers won't check :)

-----Original Message-----
From: Ned Freed [mailto:[email-masked]] 
Sent: Thursday, January 20, 2011 5:47 PM
To: Shawn Steele
Cc: [email-masked]
Subject: Re: [EAI] Consensus Issue #2: new parameter to VRFY/EXPN only after EHLO with UTF8SMTPbis?

> > > But note that its use after the EHLO cannot be enforced by the 
> > > server. It needs to take the form:

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

> It could fail or something if the client went ahead and did it, but 
> the server can't prevent bad client behavior.

Very true. I just don't want servers to be required to check for it in this case.

				Ned