Subject: SMTP AUTH design-team meeting addendum

From: John Gardiner Myers <[email-masked]>
Date: Fri, 04 Sep 1998 17:41:39 -0700

One point brought up at the meeting that I neglected to mention:

The desire for reactive authentication appears to come from a site
policy that relay requires authentication for clients connecting from
external networks, but is allowed without authentication for clients
connecting from internal networks.

The SMTP AUTH spec should mention the principle that servers SHOULD NOT
advertise the existence of mechanisms whose use provide no benefit to
either client or server.  For example, consider a server which
implements CRAM-MD5 authentication, and has the policy that clients
connecting from certain networks have authorization which is not
affected by authentication.  Since CRAM-MD5 does not implement a
security layer, it does not itself provide a benefit to the client.  If
the policy for a given client is such that CRAM-MD5 authentication does
not affect the client's authorization, then the server should not
advertise the CRAM-MD5 mechanism to that particular client.

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Sep 1998 11:31:50 -0700 (PDT)

> advertise the CRAM-MD5 mechanism to that particular client.

I agree.  But this wording is a bit subtle.  Here's another try:

If an existing SMTP server is reconfigured or upgraded to advertise
authentication mechanisms, this is likely to cause new SMTP client UIs to
begin prompting users for their passwords.  As such a behavior change may
be undesirable at some sites, servers SHOULD NOT advertise client-only
authentication mechanisms, such as CRAM-MD5, unless they grant the client
additional delivery rights or services.
---

I wish we could include a non-normative appendix with the three primary 
usage scenairos for SMTP AUTH in combination with port 25.  But I think
this is better deferred for an applicability statement produced after SMTP
Submit and the revised SMTP specs are published:

An SMTP server on port 25 allows delivery to local users without
authentication, but requires SMTP AUTH to relay mail to non-local users.

An SMTP server on port 25 allows delivery to local users without
authentication, but requires either SMTP AUTH or access from a trusted
subnet to relay mail to non-local users. 

An SMTP server on port 25 is used only for delivery to local users, does
not advertise SMTP AUTH and does not relay mail to non-local users.  A
separate SMTP server on a different port or different machine is used to
"submit" mail and requires the use of SMTP AUTH. 

		- Chris

---

From: Randall Gellens <[email-masked]>
Date: Tue, 8 Sep 1998 12:35:47 -0700

>additional delivery rights or services.

I think that might be too strong, since some sites might want all users
to authenticate (for tracking or policy).  How about:

If an existing SMTP server is reconfigured or upgraded to advertise
authentication mechanisms, this is likely to cause local upgraded SMTP
clients to prompt users for their passwords when sending mail.  This
behavior change may be undesirable at some sites, while other sites may
desire it.  Therefore, servers SHOULD be configurable to not advertise
authentication mechanisms which do not authenticate the server to the
client or include a privacy layer, such as CRAM-MD5, unless the client
is granted additional delivery rights or services by such
authentication.

In other words, the advertisement of authentication mechanisms by the
server (in the EHLO response) is likely to cause upgraded clients to
prompt users for passwords.  Some authentication mechanisms mutually
authenticate and/or include a security layer, while others do neither,
and thus may not provide any benefit to local clients.  Some sites may
want local users (within the trusted subnet) to always authenticate (as
a matter of policy), while other sites may want only non-local users to
authenticate.  Therefore, the server SHOULD be configurable to
advertise or not various supported authentication mechanisms which do
not provide direct client benefit.

>"submit" mail and requires the use of SMTP AUTH.

I'd perhaps add one more scenario, that of a trusted relay which is not
used for submission, and does advertise SMTP AUTH.

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Sep 1998 13:41:10 -0700 (PDT)

> Submit and the revised SMTP specs are published:

I agree. I also think that waiting for some experience in the field would be
wise. Based on numerous conversations with customers over the years I *think* I
know how people are going to use SMTP AUTH, but experience has shown that
deployment of a facility can lead to uses its designers and/or implementors
never thought of. And given the rapid uptake we're seeing on SMTP AUTH already
I suspect we'll be surprised at the things people come up with.

> "submit" mail and requires the use of SMTP AUTH.

I'd put your #2 before your #1, but otherwise this seems like the right
set of initial applications for SMTP AUTH. But as I say, we may be surprised
at how this plays out.

				Ned

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 14 Sep 1998 16:01:00 -0700

> I agree.  But this wording is a bit subtle.  Here's another try:

The wording was subtle for several reasons:

1) This document is avoiding the political morass of specifying anything
that pertains only to message submission.  The suggested replacement
wording explicitly pertains to client UIs.  The only clients with UIs
are submission clients.  If there is wording which is specific for the
use of authentication in mail submission, it should go into the
submission document.

2) I do not want to recommend specific site policies or require
implementations to support specific site policies, unless such
recommendations or requirements are necessary for interoperability or
security.  The most the document should say is "if you want to have
such-and-such policy, the best technical way to implement it is to do
such-and-so."

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Sep 1998 11:31:50 -0700 (PDT)

- Chris

---

From: Randall Gellens <[email-masked]>
Date: Tue, 8 Sep 1998 12:35:47 -0700

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Sep 1998 13:41:10 -0700 (PDT)

Ned

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 14 Sep 1998 16:01:00 -0700