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

Ned Freed <> Thu, 06 May 2010 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 648B03A6934 for <>; Thu, 6 May 2010 14:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.068
X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_50=0.001, J_CHICKENPOX_54=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shSGh5pmWWMJ for <>; Thu, 6 May 2010 14:38:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 057CF3A6A35 for <>; Thu, 6 May 2010 14:37:54 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Thu, 6 May 2010 14:37:31 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <>; Thu, 06 May 2010 14:37:26 -0700 (PDT)
Message-id: <>
Date: Thu, 06 May 2010 13:20:36 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Thu, 06 May 2010 08:45:41 -0700" <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90> <> <> <alpine.BSF.2.00.1005061043150.26027@joyce.lan> <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
To: Chris Newman <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mauve; t=1273181433; bh=OfiBIQlyI+RHPDJJM3ji2ZhoYMc3Y4+Oy6H6XeozjOw=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=QPc4C0EzAMJhQwT0d0BxOwTkg+lOyP7cUxE5x2sxLF9l727xvhfScRrdEzWIhZLXs HLVdN1JNTp+8JBFpyUvfRn45SFd3OtrrTvN0PJdA528qFWFxQNrEa46vIVRlxUyuJp W09j5SkCi2tTj+x4lios8jvQolDgDqyyv3bi+epY=
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 21:38:03 -0000

> --On May 6, 2010 10:44:37 -0400 "John R. Levine" <> wrote:
> >> 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?

> I respectfully disagree that this is an AUTH-only problem.  It is a problem
> that impacts implementations of SMTP+Submission+STARTTLS (without AUTH),
> smtps (without AUTH), SMTP+Submission+AUTH+STARTTLS and smtps+AUTH.
> Unfortunately the only protocol specification we have that applies to all
> four problem scenarios is RFC 4409 (its application to smtps is by virtue
> of the fact smtps is only used for submission because it can't be an MX
> target).

While it would be a lot more convenient if this weren't the case, I have
to agree with Chris here.

> > Agreed.  Honestly, I don't understand what problem AUTH EXTERNAL is
> > supposed to solve.  In the software I'm familiar with, any auth-age that
> > AUTH EXTERNAL might do happens automatically, whether the client asks for
> > it or not.

> AUTH EXTERNAL solves two problems.

> First, for protocols with an explicit state model (e.g. POP3 and IMAP4), it
> causes a state change from the not-authenticated state where the protocol
> starts to the authenticated state.  The state model is actually very
> helpful when writing security-sensitive software as the threat-surface of
> the protocol can be significantly reduced when in the not-authenticated
> state.  Having as few protocol commands as possible actually trigger a
> state change makes it simpler to verify correct implementation.  SMTP
> doesn't get this benefit as long as we support legacy submission, but
> Submission port 587 can have this benefit.

Agreed that this is a real and tangible benefit.

> Second, AUTH EXTERNAL (or more specifically the SASL authorization ID
> feature present in mulitple SASL mechanisms) allows a feature I like to
> call "administrative proxy authentication" where an administrator or more
> likely an automated tool will use administrative credentials to
> authenticate as a specific user.  For example, in a unified messaging
> system the voice mail system may wish to clear the "seen" flag for the
> voice mail in a user's INBOX after it has played that information to the
> user over a telephone interface.  Arguably, the AUTH= parameter in the SMTP
> AUTH spec provides an alternative and perhaps better mechanism to do this
> for SMTP, although I've seen implementations that (incorrectly) claimed to
> implement SMTP AUTH and failed to implement the AUTH= parameter.

The main problem with AUTH= seems to be that people don't have a clue how or
when to use it. I'd like to be able to blame this on the text in RFC 4954, but
when I read it I find very little to criticize. Perhaps an example in the
document showing how to use AUTH= for proxy authentication would help, but
regardless of the cause, deployment of this approach has been problematic,
whereas authorization IDs have been more successful.

I will say that any update to RFC 4954 needs to specifically address the
distinction between SMTP submission and relay.

> So I will accept an argument that AUTH EXTERNAL provides little value
> specifically to SMTP (beyond and explicit protocol indication that the
> client certificate was acceptable for SMTP-level authentication to the
> server, something that helps the client to produce better end-user
> diagnostics), which is why I proposed option 2.  But I do consider AUTH
> EXTERNAL an important mechanism in general.

Agreed. I personally prefer to have a consistent approach across protocols,
which would argue for option 1 or 3, not 2, but I don't think the "it can all
be dealt with in an AUTH EXTERNAL update" idea passes technical muster.