Chris Newman wrote:
Option 1: relevant to YAM -- Clarify 4409 section 4.3 to state that
providing client authentication during TLS does not constitute
"independently established authentication" [...]
Pros: [...] Consistent with IMAP+STARTTLS and POP+STARTTLS.
Even if SUBMIT mandates authentication, it inherits the SMTP trust
model, which is different from that of IMAP and POP. Section 4.3
just allows such compatibility. An historical trait.
Option 2: Incompatible change to RFC 3207 (SMTP STARTTLS) when an SMTP
client provides a client certificate the server deems valid for
authentication purposes, the server MUST enable the SASL EXTERNAL
mechanism (advertising it in EHLO and allowing it in AUTH). If the
client issues "MAIL FROM" without issuing an AUTH command in this
situation, the server MUST behave as if an implicit "AUTH EXTERNAL ="
was issued by the client.
This option may cause difficulties with the paragraph in rfc 4954
that says
Restrictions:
After an AUTH command has been successfully completed, no more
AUTH commands may be issued in the same session. After a
successful AUTH command completes, a server MUST reject any
further AUTH commands with a 503 reply.
In case an implicit "AUTH EXTERNAL =" had been assumed by the server
when a previous transaction started, the client cannot repeat it for
the whole session. For an MTA, non-authenticated transactions are
allowed, so it may be unclear whether the server should assume it in
any case.
I note that SMTP-AUTH does not allow a client to query its current
authentication state, nor to learn what authorizations such state
implies (e.g. relaying, specifying trusted AUTH parameters.) I think
the problem you describe results from that design.
I'd agree if rfc4409bis will informatively mention that "AUTH
EXTERNAL =" may be used by a client to check the status of an
independently established authentication --in case the server has
such mechanism. Additionally, section 3.3 may want to mention client
TLS certificates. Would that bring any good?
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
