Subject: [lemonade] Comment on draft-fanf-smtp-quickstart-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Apr 2007 17:36:10 +0100

Below are my comments after reviewing -00, most of them are editorial:

3.  QUICKSTART SMTP service extension definition

 [...]

   o  The QUICKSTART EHLO keyword value has four OPTIONAL parameters
      ("QTLS", "AUTH", "QHLO=<qhlo-id>", and "STARTTLS") to which more
      can be added by future specifications.

I suggest you add a forward reference here for each optional parameter.
I saw this list in section 4. I suggest you move it here.

5.  The QHLO command

   The QHLO command has two forms.  Support for the basic form defined
   in this section is REQUIRED.  The full form is OPTIONAL, and is
   defined in Section 8.

IMHO, it would be better if you can quickly explain here how the two
forms differ, i.e. the full form includes an extra qhlo-id parameter.

   An SMTP client that supports QUICKSTART MUST first ensure that the
   server supports it by checking the server's greeting against the
   syntax specified in Section 4.  The client then issues QHLO as its
   first command instead of EHLO.  The basic form of QHLO has the same
   semantics as the EHLO command, except that it MAY be pipelined if the

In a way it seems more similar to the HELO command, as it doesn't return
the list of supported extensions.

   server also supports PIPELINING [RFC2920],

How can the client know if PIPELINING is supported?
(There is no keyword for PIPELINING in the qsmtp-greet)

Suggestion: make PIPELINING REQUIRED everywhere in the document.

   and the server's 220
   response to QHLO does not include its list of supported extensions.

7.  Changes to the AUTH command

   This section describes an OPTIONAL change to the behavior of the
   AUTH command [RFC2554], support for which is indicated by the
   presence of the AUTH parameter after the QUICKSTART keyword in the
   list of extensions supported by the server.  This change is also
   specified by [RFC4468], so if the server lists support for BURL and

This change is now formally defined in 2554bis (SMTP AUTH).

   QUICKSTART and PIPELINING then it MUST include the QUICKSTART AUTH
   parameter.

   If the client uses a SASL mechanism which can be completed in one
   round trip, such as EXTERNAL [RFC4422] or PLAIN [RFC4616], then it
   MAY pipeline the AUTH command.

Suggestion: just reference 2554bis here.

   If the authentication fails, the
   server SHOULD reject all subsequent commands other than AUTH, NOOP,

Why is this requirement?
If authentication is optional, surely this is not a problem?

Does this requirement only apply to pipelined command?

   HELO, EHLO, QHLO, or QUIT with a "530 Authentication failure" reply.
   If the server supports ENHANCEDSTATUSCODES [RFC2034] [RFC3463], the
   status code to be returned SHOULD be 5.7.0.

8.  Issuing commands early

 [...]

   Support for this is OPTIONAL, and is indicated by the presence of the
   "QHLO=<qhlo-id>" parameter after the QUICKSTART keyword in the list
   of extensions supported by the server.  The server MUST also support
   PIPELINING [RFC2920].

Just to make the last sentence more clear:

 The server that advertises "QHLO=<qhlo-id>" MUST also support 
PIPELINING [RFC2920].

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Apr 2007 15:16:36 +0100

> Below are my comments after reviewing -00, most of them are editorial:

Thanks for looking through it!

> I suggest you add a forward reference here for each optional parameter.

Optional parameters will be going away.

> forms differ, i.e. the full form includes an extra qhlo-id parameter.

Variant forms of QHLO will be going away.

> the list of supported extensions.

Noted in my current version.

> (There is no keyword for PIPELINING in the qsmtp-greet)

Section 4 says the server SHOULD include PIPELINING in its extension
keyword list in the greeting. (MUST in my current version.)

> Suggestion: make PIPELINING REQUIRED everywhere in the document.

Already done :-)

> This change is now formally defined in 2554bis (SMTP AUTH).

Hmm, I'm worried that this silent change will cause interoperability
problems. For example, Exim advertises AUTH and PIPELINING but forbids
pipelined AUTH (drops the connection). So you can only make this change to
the protocol if the server advertises another EHLO keyword to tell the
client it is OK to use the new feature. BURL and QUICKSTART serve this
purpose.

> If authentication is optional, surely this is not a problem?

The client is expecting to establish its credentials and if this fails
then its later commands won't be interpreted by the server in the way the
client expects. For example, consider a dual-purpose server that acts as a
submission server if the client authenticates and as an MX otherwise. If
authentication fails then the client's messages will be accepted or
rejected (by the anti-relaying check) depending on whether the recipients
are local or not.

> Does this requirement only apply to pipelined command?

Yes, because with non-pipelined AUTH the client knows whether or not the
AUTH worked before it issues more commands.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: MAINLY NORTHERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE. FOG PATCHES AND ISOLATED SHOWERS. MODERATE OR GOOD, OCCASIONALLY
VERY POOR.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 17 Apr 2007 02:32:19 +0200

[Tony Finch]:
>   Section 4 says the server SHOULD include PIPELINING in its
>   extension keyword list in the greeting. (MUST in my current
>   version.)

(in the current 01-draft, it seems PIPELINING support is only
mandatory in the presence of QHLO, but your comment above indicates to
me you've made PIPELINING mandatory for all QUICKSTART
implementations, which I think is the way to go.)

isn't this just wasteful?  a QUICKSTART client will know PIPELINING is
implied, other clients will use EHLO to get the capability list once
more, and look for PIPELINING there.  sure, it's only 16 bytes, but in
any case I don't think it is helpful to give the impression that you
may have to add special code to handle a QUICKSTART server which
doesn't advertise PIPELINING.

as you mention in section 10, the capabilities in <qsmtp-banner>
should be ignored when considering the EHLO response.  in my opinion
this means omiting PIPELINING in the banner makes more sense, since it
doesn't tempt clients to carry its presence over into normal EHLO
mode.

I have some more questions, but I'll hold off until I see your current
copy since I assume a lot has happened since February.
-- 
Kjetil T.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Apr 2007 08:33:20 +0100

> doesn't tempt clients to carry its presence over into normal EHLO

I've decided that it's simpler if the server's capability lists are always
consistent between EHLO and QUICKSTART, especially for "full" QUICKSTART.
This implies that the server has to offer both QUICKSTART and PIPELINING.
It's easier to allow differing capabilities in "simple" QUICKSTART and as
you say it is probably worth doing so.

I've split the draft into -a (simple) and -b (full) versions so that each
looks more like a final spec. They should be out RSN. I'm still undecided
about which to go with because I want more opinions from other people
about expedience versus generality. I prefer the -b version because it is
more powerful.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT PORTLAND: NORTH OR NORTHEAST 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE. SHOWERS WITH FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR.