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

"John R. Levine" <> Thu, 06 May 2010 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B052428C0DB for <>; Thu, 6 May 2010 09:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.306
X-Spam-Status: No, score=-9.306 tagged_above=-999 required=5 tests=[AWL=1.893, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OTd0tPUfr4Jb for <>; Thu, 6 May 2010 09:37:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 548103A69A2 for <>; Thu, 6 May 2010 09:36:40 -0700 (PDT)
Received: (qmail 46223 invoked from network); 6 May 2010 16:36:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1005; bh=i8Kd8Azabmba7OyrvO3F1UQ4JBzTBcD/ZKg3QtKF/x4=; b=H6RmoUucI1pvF10kLqrdHBBpkGVs95kic99N107fClr8Gwk3vTudnrPm+NbqWI3DozpMHPNs7nJ7JDbPMt7AGQSvPGRgSF08gVQ95nrjpFZIJW9IgkiRamlPFWWnDY8ooECsjEnWhWQE3hAyduh90btJtIYcTSxegJhAdd6fang=
Received: (ofmipd with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 May 2010 16:36:04 -0000
Date: 6 May 2010 12:36:22 -0400
Message-ID: <alpine.BSF.2.00.1005061226330.26048@joyce.lan>
From: "John R. Levine" <>
To: "Chris Newman" <>
In-Reply-To: <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90> <> <> <alpine.BSF.2.00.1005061043150.26027@joyce.lan> <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
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 16:37:13 -0000

> Having as few protocol commands as possible actually trigger a state change 
> makes it simpler to verify correct implementation.

Well, gee, in your model one command triggers a state change.  In my 
model, zero commands trigger a state change -- if you're externally 
authorized, you're authorized and you go ahead and do what you're going to 

> SMTP doesn't get this benefit as long as we support legacy submission, 
> but Submission port 587 can have this benefit.

Huh?  Only if you want to break every ISP's SUBMIT server which implicitly 
auth's anyone connecting from an IP inside the ISP's network, or that uses 

To look at it another way, maybe I'm missing something, but it is my 
impression that if AUTH EXTERNAL fails in whatever protocol, you're going 
to report back to the user that he's not authorized and give up.  How is 
that better than the de facto alternative, where you get the same response 
and the same action when you try to do something?  You're not saving any 
code, the commands to do something are going to have to check that they're 
authorized either way.