Subject: Re: mailing list last call: pop and smtp sasl

From: Chris Newman <[email-masked]>
Date: Mon, 01 Dec 1997 10:26:27 -0800 (PST)

On Wed, 26 Nov 1997, Rob Earhart wrote:
>   (Is there any reason why this is being discussed on the ietf-acap
> mailing list, instead of ietf-sasl, where it started?)

[Moving conversation to SASL list]

>   Personally, I'm with John; POP3's useful if you need to interact
> with legacy systems, but it seems a bit silly to take the time and
> effort to work on POP3 to the point of defining a generic extension
> mechanism that'll be good in the long run, since in the long run,
> everything ought to transition to IMAP anyway.
> 
>   Encouraging the use of POP3 seems harmful at this point; I'd rather
> see it just go away.

I disagree.  I'm of the opinion that use of IMAP for the offline access
mode (as opposed to online or disconnected) is actively harmful and
usually results in lost email.  Therefore, anyone using offline access
mode should use POP3.  It's much simpler to explain to users that "POP3"
means copy the email to your desktop machine and "IMAP" means keep the
authoritative copy on the server.  That's not strictly required by either
protocol, but it results in a clean and safe architecture.

There are few, if any, released disconnected mode IMAP clients.  Until
such clients are widely available and of comparable quality to POP
clients, POP will have a long and useful life.  Therefore POP deserves the
same attention to security as any other widely used IETF protocol.

Now it is unfortunate that there are released products supporting a
nonstandard extension to the POP AUTH command which lists SASL mechanisms. 
But does that mean we must standardize the POP AUTH listing in a way which
is different and inferior to the method used in other protocols?

		- Chris

---

From: [email-masked] (John Myers)
Date: Mon, 01 Dec 1997 14:01:49 -0800

Chris Newman wrote:
> usually results in lost email.

Let's break out one of the assumptions in this statement:

This statement assumes the "download and delete" model of offline access
that was pervasive about three years ago.  Since then, the UIDL command
has become widely deployed and the "leave mail on server" option of
various POP clients has become fairly popular.

A "leave mail on server" model of offline access does not have the
problem you describe.

> Therefore, anyone using offline access

The architecture is not any cleaner or safer: A user who mixes a
"download and delete" POP client with an server-authoritative IMAP
client is still going to lose their email.  It just that the terminology
used to explain to the hapless user why they lost their mail becomes
more convenient.

> clients, POP will have a long and useful life.

This is an installed-base argument.  It is good for establishing the
short-term or medium-term importance of POP, but is not effective in
establishing long-term importance of POP.

> Therefore POP deserves the

To benefit from attention to POP in any area, one has to replace both
the server and client base.  Since your argument for paying attention to
POP is that the installed base is entrenched, this is slightly
contradictory.  To keep from having to replace one's infrastructure, one
will have to replace one's infrastructure.

In actuality, there is a balance to be found between the benefits to
people replacing their POP infrastructure with a new POP infrastructure
and the cost of taking resources away from IMAP.

It is arguable that security is critical enough to warrant POP
extension.  But your POP extension proposal is not necessary for
security and goes into numerous areas that are in no way related to
security.

> is different and inferior to the method used in other protocols?

The "nonstandard extension" represented consensus at the time, and the
only reason it is not currently on the standards track is because it got
procedurally held up by the inordinately long delay in the base SASL
spec.

The existence of an installed base requires one to consider the cost to
said installed base when evaluating new proposals.

---

From: Chris Newman <[email-masked]>
Date: Tue, 02 Dec 1997 09:55:32 -0800 (PST)

On Mon, 1 Dec 1997, John Myers wrote:
> ...

The "leave mail on server" POP model is a poor man's disconnected mode
access, IMHO.  IMAP should be used instead for that purpose.

However, I maintain that POP is the preferred protocol for the "download
and delete" model and I don't forsee that usage model disappearing.  It's
far to useful for home users.  Building "download and delete" IMAP clients
is misleading to users and increases the risk of lost email.

> will have to replace one's infrastructure.

There is a difference between upgrading the POP server/client and
switching to a different usage model.  The former will be done by a good
system manager periodically anyway, while the latter requires a testing,
training and transition period.

> security and goes into numerous areas that are in no way related to

The extension proposal also documents deployed variations in POP3 servers
which are currently manually configured at the clients.  If people ignore
it, no harm done, if they use it, it simplifies things for the users.

> said installed base when evaluating new proposals.

Here are the choices:

(1) The capability command notes the presence of AUTH, but does not list
mechanisms.  Legacy clients which use AUTH to list mechanisms won't have
to change.  Newer clients will have an extra round trip on every
connection and may break against servers which disconnect after two failed
commands.  Legacy servers will have to add the capability command if it
becomes popular.
Pros: low impact on legacy AUTH list clients
Cons: bad architecture for new clients
      dissimilar to other SASL profiles
      works poorly with TLS

(2) The capability command lists mechanisms as does the AUTH command.
Legacy clients don't have to change.  Newer clients will work better.
Legacy servers will have to add the capability command if it becomes
popular.
Pros: low impact on legacy AUTH list clients.
Cons: duplicate paths for same function creates possibility for silly
state.

(3) The capability command lists mechanisms, no requirement that AUTH
command does.  Legacy clients will have to be upgraded to interoperate
with newer servers.  Newer clients will work better.  Legacy servers will
have to add the capability command if it becomes popular.
Pros: clean architecture
Cons: upgrade to clients is a pain
      may have to deal with unpleasent server variations

(4) Just use AUTH command.
Pros: No impact on legacy AUTH list clients/servers.
Cons: clients have to be manually configured
      bad architecture for new clients (probing)
      dissimilar to other SASL profiles
      works poorly with TLS

I'd say that (2) or (3) is best, although I could live with (1).  What do
others think?

		- Chris

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Dec 1997 10:04:34 -0800 (PST)

> is misleading to users and increases the risk of lost email.

Perhaps an anecdote will help support this point.

UIDL is easy to support with a VMS MAIL backing store so we implemented it
fairly early. But after implementing it we almost immediately started receiving
some pushback on it -- it makes "leave mail on server" operation a lot
more attractive, and a significant number of our customers didn't want that.
So we added options to disable UIDL.

Since then we've continued to receive pushback on practically every feature of
POP3 that can be used to facilitate the "leave mail on server" approach. We've
implemented increasingly draconian settings to make this operational mode less
and less attractive over time.

Simply put, there are a lot of sites that want to operate dropboxes, not
message stores. And while it is theoretically possible to configure IMAP4 to
operate in a dropbox mode, I doubt very much that a server implementing
such a mode would successfully interoperate with any extant IMAP client.

Now, one can argue that the cost of hardware is now so low that the cost of
running a full message store isn't all that great even for large numbers of
users, and besides you can charge more for the increased functionality a
message store provides over a simple dropbox. (And of course this can then be
countered by saying that the real increase cost is in management of the store,
not in equipment and software, and that even if the management costs are
somehow held down the fact remains that significant numbers of people aren't
willing to pay more for message store functionality when a dropbox does
all they want.)

But all this market analysis is irrelevant, really. The bottom line is that a
significant number of people want to continue to use POP3 as a dropbox protocol
rather than try to turn IMAP4 into one and they are going to enhance POP3 in
various ways (mostly security related) rather than move to IMAP4. And the only
choice we have is whether or not we impose some sort of structure on POP3 or
cope with any additional enhancements that like it or not are going to happen
on a case by case basis.

> training and transition period.

Our experience has been that the training involved is considerable, the costs
are often quite high, and the transition is often quite painful.

> I'd say that (2) or (3) is best, although I could live with (1).  What do

I prefer (2). I could live with (3) or (1). The TLS issues make (4) more
than a little problematic for me.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 2 Dec 1997 11:40:22 -0800

>I'd say that (2) or (3) is best, although I could live with (1).  What do

I agree.  I'd prefer (3), that is, that servers MAY respond to an empty
AUTH with a list of supported mechanisms, with a note in the spec about
existing code that does so.  However, I'd also settle for (2).

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 02 Dec 1997 11:44:40 -0800

>cope with any additional enhancements that like it or not are going to happen

I have to agree with Ned here. In our talks with the press about IMAP
adoption, we find that few companies that want to do dropbox want to go to
IMAP, even with all the clients that are out there now.

It seems prudent to continue to improve the POP standard until there is a
groundswell of movement to IMAP. That hasn't happened yet.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 3 Dec 1997 10:27:51 -0800

>existing code that does so.  However, I'd also settle for (2).

Same for me - prefer (3), could live with (2). I'd prefer to have to
implement only one way to discover the AUTH options.  If two are acceptable
some servers will do one, others may do the other, and the client really
has to start probing to do the best job. Probing makes the implementations
significantly messier.

LL

---

From: Randall Gellens <[email-masked]>
Date: Wed, 3 Dec 1997 11:38:42 -0800

>has to start probing to do the best job. Probing makes the implementations

Maybe the spec should say a server MUST support the capabilities
response which lists the SASL mechanisms, and SHOULD respond to an
empty AUTH by listing the mechanisms, and that clients SHOULD (MUST?)
use the capabilities command to discover mechanisms.  That way legacy
code still works, but new code uses the capabilities command.  A new
client only has to implement one method, but a new server should
support both.

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 03 Dec 1997 15:17:59 -0800

Let me propose (5):

Reserve a SASL mechanism name STARTTLS.  There is no such mechanism, but
the name is used in POP3 AUTH-no-args to indicate the presence of the
STARTTLS extension.  Clients which want to use the capability command do
so after authentication.

Pros: returned capabilities are protected by any session integrity
protection layer of TLS or SASL.
most compatible with installed base

Cons: Ugly

---

From: Randall Gellens <[email-masked]>
Date: Wed, 3 Dec 1997 19:32:32 -0800

>most compatible with installed base

There's an extra round-trip over (2) or (3), plus it turns AUTH-CRLF
into a super-capabilities command.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 4 Dec 1997 09:45:53 -0800

So do we have consensus.....?

The POP extension/capabilities returns something like this:
  +OK
  USER
  APOP
  SASL=CRAM-MD5 KERBEROS_V4 SCRAM-MD5 PLAIN
  STLS
  .
indicating it support
  1939 User/Pass
  1939 APOP
  2195 CRAM-MD5
  Kerberos version 4
  Scram
  The SASL plain mechanism from the Newman draft
  The STLS command from the Newman draft

Also a server *MAY* return the following list in response to AUTH
  +OK
  CRAM-MD5
  KERBEROS_V4
  SCRAM-MD5
  PLAINTRANS
  .

If the AUTH command with no arguments is not supported, it returns
  -ERR AUTH command must give SASL mechanism

I expect nearly all servers will respond to AUTH with no args, because it's
very easy to implement and provides good backwards compatibility.  I expect
all future clients will always use the extension/CAPA command in preference
to AUTH with no arguments because it is more efficient and easier to
implement.

LL

---

From: Chris Newman <[email-masked]>
Date: Thu, 04 Dec 1997 17:05:55 -0800 (PST)

> So do we have consensus.....?

At this point I support:

Some form of capability command.  New clients MAY use AUTH listing only if
capability command not present.  Servers MUST implement AUTH listing (I
can't think of a good reason not to, given backwards compatibility issue).

This is easy for servers to implement (the SASL API I'm working on makes
it almost trivial).  This is fully backwards compatible with old clients,
and will attain the one round trip and no probing goal with newer
client/server combinations.

This also permits the POP AUTH command to move forward in its current
state with only the addition of a reference to a future capabilities
command.

The alternative of turning AUTH with no arguments into a capability
command is acceptable to me as long as there is a systematic way to  
distinguish SASL mechanisms from capability items (e.g., by requring
extension items to contain or end with an "=", or have all capabilities 
occur after a "CAPABILITIES:" item and all SASL mechanisms occur before
it).

		- Chris

---

From: Randall Gellens <[email-masked]>
Date: Thu, 4 Dec 1997 18:28:16 -0800

>can't think of a good reason not to, given backwards compatibility issue).

I agree with this.

>occur after a "CAPABILITIES:" item and all SASL mechanisms occur before

I really don't like this.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 5 Dec 1997 07:46:14 -0800

>can't think of a good reason not to, given backwards compatibility issue).

I'm happy requiring servers to support AUTH listing.

>state with only the addition of a reference to a future capabilities

I'd actaully prefer we pull back on it and rewrite it to use the POP
extensions mechanism.  That will make the POP standards significantly
cleaner in the long run. As things are going now, there are going to be
over half a dozen drafts/standards that an implementor will have to read to
get the POP authorization stuff working well. I would hope we could reduce
that to two or three, perhaps just the POP extention standard, and the POP
authentication standard.  (It would still be a SASL mechanism, but SASL is
more directed at designers or AUTH mechanisms, than implementors, so they
probably don't need it to write code).

>occur after a "CAPABILITIES:" item and all SASL mechanisms occur before

You don't really want to allow overloading AUTH with such wonderful
extensions as removing QP encoding, translation to Russian, grammar
checking and gziping before downloading...? :-)  I would prefer to keep the
AUTH verb separate from the extensions verb.

On the XTND XMIT, I don't know it's all that critical, and would probably
rather see SASL based SMTP and Randy's submit draft go forward. The salient
characteristics are authorization and batch submission.

LL

---

From: Randall Gellens <[email-masked]>
Date: Fri, 5 Dec 1997 12:01:11 -0800

>characteristics are authorization and batch submission.

I agree.  Authenticated SMTP and the submission protocol are the way to
go, not XTND XMIT.

---

From: Chris Newman <[email-masked]>
Date: Mon, 01 Dec 1997 10:26:27 -0800 (PST)

- Chris

---

From: [email-masked] (John Myers)
Date: Mon, 01 Dec 1997 14:01:49 -0800

---

From: Chris Newman <[email-masked]>
Date: Tue, 02 Dec 1997 09:55:32 -0800 (PST)

Here are the choices:

		- Chris

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Dec 1997 10:04:34 -0800 (PST)

Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 2 Dec 1997 11:40:22 -0800

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 02 Dec 1997 11:44:40 -0800

--Paul Hoffman, Director

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 3 Dec 1997 10:27:51 -0800

LL

---

From: Randall Gellens <[email-masked]>
Date: Wed, 3 Dec 1997 11:38:42 -0800

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 03 Dec 1997 15:17:59 -0800

Let me propose (5):

Cons: Ugly

---

From: Randall Gellens <[email-masked]>
Date: Wed, 3 Dec 1997 19:32:32 -0800

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 4 Dec 1997 09:45:53 -0800

LL

---

From: Chris Newman <[email-masked]>
Date: Thu, 04 Dec 1997 17:05:55 -0800 (PST)

At this point I support:

		- Chris

---

From: Randall Gellens <[email-masked]>
Date: Thu, 4 Dec 1997 18:28:16 -0800

I agree with this.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 5 Dec 1997 07:46:14 -0800

LL

---

From: Randall Gellens <[email-masked]>
Date: Fri, 5 Dec 1997 12:01:11 -0800