Re: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL

[Tony Hansen <[e-mail]>]

I think this is totally an issue with AUTH EXTERNAL and worth mention in 
an update to that spec. However, I don't think it directly affects 4409bis.

Any other people's thoughts?

     Tony Hansen
     [e-mail]

On 5/2/2010 8:55 AM, Alessandro Vesely wrote:
> 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?