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

SM <> Thu, 06 May 2010 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D52D53A6B9B for <>; Thu, 6 May 2010 12:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.665
X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-1.866, BAYES_50=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zUOJ4-8BvXUB for <>; Thu, 6 May 2010 12:35:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D32028C0F6 for <>; Thu, 6 May 2010 12:35:31 -0700 (PDT)
Received: from (IDENT:sm@localhost []) (authenticated bits=0) by (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o46JYlNa000082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 May 2010 12:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1273174518; x=1273260918; bh=Fz51Y/+66/mL3FKqj8cGJ2XMSQWcI1xXULaN3ftGsh8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=LVd1USnPMtK3kedLdyVFMbptllNlKh/5X5CfYYFeY9wsu4A7zaP3h1vAvpSApFLEg +mhEFfRwZfDpviNTAGvk2h7ifspTbx+5QSvIv6PZVr3K4FINu6h5Nt5bRICDy1sxkF q5fGn/AfvVcPpa1p5AvZmvTvVjMvPJn0+KpxQ+cA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1273174518; x=1273260918; bh=Fz51Y/+66/mL3FKqj8cGJ2XMSQWcI1xXULaN3ftGsh8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=1LfwFgn4xhEIOPQXubuDlMRHq8Bejxgx9T6sMeF3vpogwC1vF1npmJOUBrLzpiySg giahdFF1t7KnKycmdEeQ884cjHweQVpl+utqFD+f5p0ZgReFGTRsEus3jY9mRJY4vI t/cFzAr384R/jMr8jQtu8rluSjAebgYgGcN4hnBc=
DomainKey-Signature: a=rsa-sha1; s=mail;; c=simple; q=dns; b=xbQmvG2Phxa2j6s3P8qdwmL9AuybLgt9a2QTIdcUJgz4FMSrmzW496u6fgCCW1g3S ifRlJIVjfrWJPyIfPI3eTX4LHOgKk1f6m8A1oyUTxOFCETk1OLty6S8PjFoIzks1NtK lDTTIY5fPngpcbyqScnrfAGekBFqkLBhN7uHDh0=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 06 May 2010 12:34:10 -0700
To: Chris Newman <>
From: SM <>
In-Reply-To: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 May 2010 19:35:34 -0000

Hi Chris,
At 04:28 PM 4/30/2010, Chris Newman wrote:
>I've been dealing with client certificate authentication lately and 
>realized we have an interoperability problem with our 
>standards.  For SMTP submission, when an end-user wishes to 
>authenticate using a client certificate, the protocol sequence to do 
>so is unclear.
>This sequence works assuming the server enables SASL EXTERNAL and 
>the client implements it (not true of all deployed software):
>C: EHLO ...
>S: ...
>S: 220 2.5.0 Go ahead with TLS negotiation.
><negotiate TLS with client certificate>
>C: EHLO ...
>S: ...
>S: ...
>S: 235 2.7.0 EXTERNAL authentication successful.
>C: MAIL FROM:<cnewman@mydomain.example>
>C: RCPT TO:<somebody@relaydomain.example>
><relay is allowed>
>This sequence of commands may or may not work but RFC 4409 section 
>4.3 can be interpreted to permit it assuming a client certificate 
>via TLS counts as "independently established authentication":
>C: EHLO ...
>S: ...
>S: 220 2.5.0 Go ahead with TLS negotiation.
><negotiate TLS with client certificate>
>C: EHLO ...
>S: ...
>C: MAIL FROM:<cnewman@mydomain.example>
>C: RCPT TO:<somebody@relaydomain.example>
><relay may or may not be allowed>
>An SMTP submission client that implements only the latter will not 
>interoperate with an SMTP submission server that implements only the 
>former (and possibly vice versa if the client is unwilling to "just 
>try it" when AUTH EXTERNAL isn't there).  One of these two cases 
>must be interpreted or declared not valid by the standards to 
>resolve the interoperability problem.

Section 3.3 of RFC 4409 discusses about authorized submissions.  The 
user may be authenticated using several methods.

>Option 1: relevant to YAM -- Clarify 4409 section 4.3 to state that 
>providing client authentication during TLS does not constitute 
>"independently established authentication" because there is no 
>indication in the TLS layer whether that authentication was deemed 
>acceptable for SMTP submission authentication.  Perhaps note as an 
>informational reference that "AUTH EXTERNAL" can be used to 
>determine the validity for that purpose.

SMTP AUTH is a MUST according to Section 4.3 but other types of 
authentication are allowed.  Section 4.1 of RFC 3207 mentions 
authentication.  In the above example there has been some level of 
authentication.  Option 1 gets into what constitutes authentication 
and it's not a good idea to get into a discussion about it in RFC 4409.

>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.
>Pros: Doesn't break any clients.  Cons: Some previously complaint 
>SMTP STARTTLS server implementations are declared incompliant 
>(including the shipping product from my company ;-).

The better place to add that is in a RFC about AUTH EXTERNAL.  Don't 
break existing implementations unless you really have to. :-)

>Option 3: Incompatible change to RFC 3207 (SMTP STARTTLS) to declare 
>that client authentication provided via STARTTLS is not considered 
>valid authentication at the SMTP layer until the client issues an 
>"AUTH EXTERNAL" command.
>Pros: Consistent with IMAP+STARTTLS and POP+STARTTLS.  Cons: Some 
>previously compliant SMTP STARTTLS client and server implementations 
>are declared incompliant.

Section 4.3 of RFC 3207 mentions that:

   "In fact, since the submission port is by definition not a publicly
    referenced SMTP server, the STARTTLS extension can be particularly
    useful by providing security and authentication for this service."

To summarize, the question is where to solve the problem.  I don't 
think that should be done in RFC 4409.