Re: SMTP AUTH design-team meeting addendum

[Randall Gellens <randy@xxxxxxxxxxxx>]

At 11:31 AM -0700 9/8/98, Chris Newman wrote:


>On Fri, 4 Sep 1998, John Gardiner Myers wrote:
>> 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.
>
>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 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.

>---
>
>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.

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