Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2007 12:54:27 +0100

Now available at

http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: VARIABLE 3, BECOMING NORTHWEST 4 OCCASIONALLY 5. SLIGHT. FAIR.
MAINLY GOOD.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Wed, 04 Apr 2007 13:25:06 +0100

> http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt

I spotted this, and added the reference to my working copy of the 
profile bis draft - also updated the RFC2554 reference to 
draft-siemborski-rfc2554bis.

(This is at 
http://svn.dave.cridland.net/svn/ietf-drafts/draft-ietf-lemonade-profile-bis.xml 
and is in something quite close to xml2rfc format, although I use 
some preprocessor tools for references).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Steve Hole <[email-masked]>
Date: Wed, 04 Apr 2007 07:42:54 -0600

> http://www.ietf.org/internet-drafts/draft-fanf-smtp-quickstart-00.txt
Out of curiosity ... why don't you extend the EHLO command directly to 
initiate the AUTH or STARTLS sequence rather than provide the extended 
QHLO and QTLS commands?   You're not waiting for any responses from the 
SMTP server anyway, so you might as well throw it all over the fence at 
the beginning.    Success or failure of the submit transaction is 
bounded by the entire sequence of SMTP commands in the model.

Cheers.

-- 
Steve Hole 
Chief Technical Officer
PlaNet Correspondence Technologies

424-4922 (wk)
905-9116 (mb)

mailto:[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2007 15:12:35 +0100

On Wed, 4 Apr 2007, Steve Hole wrote:

> QHLO and QTLS commands?

Because the SMTP extension framework only allows extension parameters on
the MAIL and RCPT commands. If you want to change other aspects of SMTP
you have to introduce new verbs.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: WEST 6 OR 7, OCCASIONALLY GALE 8, VEERING NORTHEAST
4 OR 5. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE, THEN WINTRY SHOWERS. GOOD,
OCCASIONALLY MODERATE OR POOR.

---

From: "Vaudreuil, Greg M \(Greg\)" <[email-masked]>
Date: Wed, 4 Apr 2007 09:23:43 -0500

The SMTP extension framework is really the EHLO framework.  It is
certianly possible to provide an alternate framework based on another
HELO variant if there is compelling need.  

Greg V.

-----Original Message-----
From: Tony Finch [mailto:[email-masked]]
Sent: Wednesday, April 04, 2007 10:13 AM
To: Steve Hole
Cc: [email-masked]
Subject: Re: [lemonade] draft-fanf-smtp-quickstart-00

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: WEST 6 OR 7, OCCASIONALLY GALE 8, VEERING
NORTHEAST
4 OR 5. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE, THEN WINTRY SHOWERS. GOOD,
OCCASIONALLY MODERATE OR POOR.

---

From: Steve Hole <[email-masked]>
Date: Wed, 04 Apr 2007 08:51:05 -0600

> HELO variant if there is compelling need.  

Precisely -- vis-a-vis the LHLO command of LMTP (LMTP is really just a 
profile of SMTP). I'm thinking that you would like to doing something 
similar to the LMTP thing here.

Really I don't care all the much in the end -- I was thinking mostly 
about the state handling issues in the SMTP server implementation. 
Adding an additional command into the state sequence is likely to be 
more complex to implement that providing the additional handling of the 
extension parameters in the EHLO variant (presumably QHLO). That is, the 
support for HELO, EHLO, LHLO in many servers is handled by the same 
state processing, with variant behavior depending on the actual protocol 
verb and subsequent arguments.

At any rate, it is just a thought. I'll shut up now.

Cheers.

424-4922 (wk)
905-9116 (mb)

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2007 16:20:22 +0100

> HELO variant if there is compelling need.

Actually I suppose quickstart does vary the framework a bit, but it tries
to do so in a minimal way. It doesn't change the syntax or semantics of
existing commands, only their pipelining behaviour. It does just enough to
let us "throw it all over the fence at the beginning."

The point of QHLO is for the client to say "I've seen your capability
list, so you don't need to repeat it" which (as well as RTT elimination)
saves a few bytes compared to EHLO before compression is negotiated. The
point of QTLS is to let the client say "no chit-chat, let's encrypt" so
it's effectively a streamlined combination of EHLO and STARTTLS. (I've
made the examples clearer about this in the -01 revision of the draft.)

This seems to be pretty much exactly what Steve is asking for - apart from
AUTH, but I don't want to have to specify a whole new SASL profile, which
is what an AUTH replacement would require.

LMTP is a poor example, because if it actually followed the SMTP extension
framework then it would be signalled using an ESMTP parameter on the MAIL
command. A replacement for EHLO is unnecessary since it doesn't need to
change the protocol's startup sequence.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET: NORTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST. SLIGHT,
OCCASIONALLY MODERATE IN SOLE AND FASTNET. FAIR. MAINLY GOOD.