*** within
At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote:
I do have one minor concern regarding the current wording of the
EXPIRE setting.
The draft states:
"If the expiration policy might differ per user (that is, the EXPIRE
argument might change after authentication), the server MUST announce
in the AUTHENTICATION state the smallest value which might be used.
The server should announce the more accurate value in the TRANSACTION
state.
It is unclear to me whether the intent of this is to force the server
to keep track of the smallest setting a user currently has set, or if
it is for the server to annouce the smallest value that an
administrator could conceivably set for a particular user. If the
intent is the former, than this will be problematic for servers that
are not tightly coupled with their directory, as it effectively forces
the server to scan a list of all user settings at each log on time.
The intent is to let the client know that the server does permit mail
to be left on the server, and to present a value which is the smallest
which might be set for the user. This could be the smallest value
currently in use for any user (so only one value per server), or even
the smallest value which the server permits to be set for any user.
*** If it is the smallest value which the server permits to be set for any
user, I am happy with it.
Would it be possible for you to update the draft with the above paragraph?
If I had the question, I am sure others will... The more precise we are now
with things, will save us interoperability grief later and it really is just
a minor clarification so we won't need to worry about another last call.
(The smallest value currently in use by any user on a server is problematic
for us, but we do not have any objections if other servers want to present
this value if they can easily calculate it) This should not pose any interop
problems either. Basically, if a client wants to get the accurate setting,
they need to re-issue the CAPA command after authenticating, so i do not
really think it matters too much what was presented in the unauthenticated
state.
Having said that, perhaps a better solution would be to define another
arguement called "USER".
If a client does a CAPA and gets an EXPIRE USER, in the unauthenticated
state, it knows that the server supports per user expiry settings. It
explicitly informs the user when they need to re-issue the CAPA command
after authentication due to per user options.
This way a client can decide (because the user has told the client to
leave mail on the server for a larger number of days) if it needs to
reissue CAPA after authenticating and/or warn the user.
*** this is assuming that the client ui has something that allows the user
to specify the number of days to leave mail on the server. I believe some
clients just have a "leave mail on server" option. In this case, I guess
the client will always need to reissue the CAPA command after
authentication.
The interop problem I see is the following:
The client is running against a server where expiry is set on a per user
setting. Let's say the server allows the admin to specify per user expiry
settings. For the client that is logged on, the per user expiry is set to
30. However, on the server he is running against, there is a user who has
expiry set to 15. Or it is a server, where the lowest expiry setting is not
available, so the server reports what the theoretical minimum it can be set
to, lets say 1.
Unless things are spelled out explicitly within your draft, I can see a
client issueing only a single CAPA before authentication. Without it doing
another CAPA after authentication, the client would be spitting out bogus
warnings for the user saying "your messages will be deleted from the server
after 15 days" when really the setting is for 30 days. Being really
explicit in the draft will ensure that client writers don't make that
mistake.
Another minor nit is the wording:
"If the authentication step negotiates an integrity protection layer,
the client SHOULD reissue the CAPA command after authenticating to
check for active down-negotiation attacks."
I'd like to see the wording changed to something like:
"The client SHOULD reissue the CAPA command after authenticating to
check for active down-negotiation attacks and to get any per user
capability settings."
The intent is to not require clients to issue two CAPA commands. The
client pretty much has to issue one before authenticating, to learn
which SASL mechanisms are supported, but doesn't have to issue on
afterwards, unless the first CAPA reveals that the server supports some
capabilities whose parameters might change after authentication, and
the client needs the most accurate values (it might be able to use the
more general ones), or the client wants to check for down-negotiation
attacks.
*** Agreed. The point I was making is that it does not hurt to call out in
the doc the need to recheck parameters that might change after
authentication. The wording you have only mentions down negotiation
attacks.
A simple client that only uses a few basic SASL mechanisms,
for example, and only needs to know if the server supports TOP, UIDL,
and allows mail to be left on the server, doesn't need to issue two
CAPAs. (A client which only uses plaintext or APOP could issue only
one CAPA, after authenticating.)
Agreed. And perhaps this adds more fuel to returning USER when there are per
user settings.