Re: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
Alessandro Vesely <vesely@tana.it> Sun, 02 May 2010 12:54 UTC
Return-Path: <vesely@tana.it>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969343A698E for <yam@core3.amsl.com>; Sun, 2 May 2010 05:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.759
X-Spam-Level:
X-Spam-Status: No, score=-3.759 tagged_above=-999 required=5 tests=[AWL=-2.840, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnpZ8U5OYDXa for <yam@core3.amsl.com>; Sun, 2 May 2010 05:54:45 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 4E5363A69E9 for <yam@ietf.org>; Sun, 2 May 2010 05:54:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1272804864; bh=jYajmKcNLHYeUGldWTc5BiLZoj4tUuutvN+SI4LWM6M=; l=2155; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DLYPfNRQx9uBDXA5xGultzoGkbUJ6evHkQta+1BbsT6qth11zXmGkPEXZSODEMu/c tw/hv56uJl6du1eMdI32/d48UksNW5dQqQUIB1PlCB6M85a9+0Z8U9hY23Sr08VQ6r xlRwO5p1j0Y2vTDAro4EgOAJtO7atm2NEAPR2dUo=
Received: from mach-4.local (93-32-132-43.ip33.fastwebnet.it [93.32.132.43]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 02 May 2010 14:54:24 +0200 id 00000000005DC035.000000004BDD7600.00001D6B
Message-ID: <4BDD762E.5020606@tana.it>
Date: Sun, 02 May 2010 14:55:10 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: yam@ietf.org
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
In-Reply-To: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 May 2010 12:54:46 -0000
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] Interop problem: SMTP submission, STARTTLS,… Chris Newman
- Re: [yam] Interop problem: SMTP submission, START… John R. Levine
- Re: [yam] Interop problem: SMTP submission, START… Tony Finch
- Re: [yam] Interop problem: SMTP submission, START… Alessandro Vesely
- Re: [yam] Interop problem: SMTP submission, START… Tony Hansen
- Re: [yam] Interop problem: SMTP submission, START… Arnt Gulbrandsen
- Re: [yam] Interop problem: SMTP submission, START… John R. Levine
- Re: [yam] Interop problem: SMTP submission, START… John C Klensin
- Re: [yam] Interop problem: SMTP submission, START… John C Klensin
- Re: [yam] Interop problem: SMTP submission, START… Chris Newman
- Re: [yam] Interop problem: SMTP submission, START… John R. Levine
- Re: [yam] Interop problem: SMTP submission, START… SM
- Re: [yam] Interop problem: SMTP submission, START… Ned Freed
- Re: [yam] Interop problem: SMTP submission, START… Tony Hansen
- Re: [yam] Interop problem: SMTP submission, START… Arnt Gulbrandsen