SMTP QUICKSTART

IETF 68, Prague

March 2007

Tony Finch <dot@dotat.at>

Randall Gellens <randy@qualcomm.com>

Overview

Aim: fewer RTTs before the client sends the MAIL command

TCP + SMTP + TLS + AUTH typically requires 8 RTTs

QUICKSTART specifies several small modifications to SMTP
that reduce the number of RTTs to as few as 2 or 3.

Result: no SMTP startup overhead beyond raw TCP + TLS
(plus TLS session cache can now save 1RTT too)

Features

Pipelining of SMTP client hello and authentication

More streamlined TLS negotiation

Careful mechanism that allows client to skip greet-pause delays

Current draft has far too many sub-options!

Pipelining

Server capabilities in its initial greeting,
plus pipelined QHLO replacement for EHLO

save 1RTT

Pipeline AUTH if all credentials fit in SASL initial data.
e.g. AUTH PLAIN, AUTH EXTERNAL
(Also mentioned in BURL spec, but non-normatively.)

save 1RTT

TLS

QTLS alternative to STARTTLS omits server response before TLS handshake and adds server capability greeting after handshake.

save 2RTT

or client may pipeline STARTTLS command + TLS handshake
which requires interleaving SMTP and TLS data (tricky)
but works better with TLS session cache and greet-pause skip.

save 1RTT or 2RTT

(Server may offer any combination of these features)

Extended QHLO

Server includes QHLO=cookie in its capability list
Client echoes cookie in future QHLO commands
Cookie different per client, per server, per capability list

Avoids delay for initial greeting and after TLS handshake

Works best with pipelined STARTTLS

save 2RTT - 4RTT

(another optional feature)

To Do

Reduce number of options: two main alternatives:

capabilities in greeting, pipelined AUTH, basic QHLO, QTLS
- no interleaving of SMTP and TLS, min. 5RTT

capabilities in greeting, pipelined AUTH + STARTTLS, full QHLO
- harder to implement, min. 2RTT