IETF Logo Mail Archive

Re: [Jmap] Submission

"Adrien de Croy" <adrien@qbik.com> Mon, 24 April 2017 01:32 UTC

Return-Path: <adrien@qbik.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896041277BB for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 18:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbJgfGOjouLP for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 18:32:27 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120A312426E for <jmap@ietf.org>; Sun, 23 Apr 2017 18:32:26 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001027868@smtp.qbik.com>; Mon, 24 Apr 2017 13:32:24 +1200
From: Adrien de Croy <adrien@qbik.com>
To: Ned Freed <ned.freed@mrochek.com>
Cc: Ned Freed <ned.freed@mrochek.com>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, "jmap@ietf.org" <jmap@ietf.org>
Date: Mon, 24 Apr 2017 01:32:24 +0000
Message-Id: <em2f5b4b3b-8f11-4593-af0e-bf8efd6bd11c@bodybag>
In-Reply-To: <01QDIWQBJR5K00005B@mauve.mrochek.com>
References: <20170419163429.8556.qmail@ary.lan> <87d1c873cf.fsf@fifthhorseman.net> <alpine.OSX.2.20.1704191353500.43511@ary.qy> <01QDEV2QM6XC00005O@mauve.mrochek.com> <BC098A22-2837-4316-822A-27232A896EF1@fugue.com> <4471fa93-2321-4a7e-87b0-fbb00927d584@gulbrandsen.priv.no> <01QDIUI7C57800005B@mauve.mrochek.com> <em388d79dd-ef11-4b05-89ce-7b61247940d0@bodybag> <01QDIWQBJR5K00005B@mauve.mrochek.com>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/HUxUrwAcss3LshuZo7v13lTmp9c>
Subject: Re: [Jmap] Submission
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 01:32:29 -0000


------ Original Message ------
From: "Ned Freed" <ned.freed@mrochek.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Ned Freed" <ned.freed@mrochek.com>; "Arnt Gulbrandsen" 
<arnt@gulbrandsen.priv.no>; "jmap@ietf.org" <jmap@ietf.org>
Sent: 24/04/2017 12:42:24 PM
Subject: Re: [Jmap] Submission

>
>
>>------ Original Message ------
>>From: "Ned Freed" <ned.freed@mrochek.com>
>> >
>> >Proxy authentication is widely if not universally supported using any
>> >number of techniques. And again, you don't get rid of the need to
>> >perform any number of actions based on the submitters identity just
>> >because
>> >the user already authenticated to JMAP.
>
>>I can think of one major platform (Windows) where this approach will 
>>be
>>highly problematic.
>
>We used to have a Windows implementation. Curiously, I don't recall it 
>having
>any problems with proxy authentication.
Maybe we have different things in mind when we think about proxy 
authentication, or even proxy.

In JMAPs case, I would suggest it's probably not a proxy, not in the way 
an HTTP proxy is.

>
>
>>Are we talking about a JMAP proxy (e.g. the client talks real-time via
>>the JMAP server to the SUBMIT server), or are we talking about a 
>>system
>>where the JMAP server accepts the message, and MAYBE forwards it via
>>SMTP or SUBMIT depending on the destination.
>
>In answer to your question, we are not talking about any particular
>architecture. That's a point I've been trying to make, I guess 
>unsuccessfully,
>since I first starting posting in this thread.
Ok, except when working with existing systems such as challenge response 
auth protocols that take opaque blobs, then the architecture can be 
impinged upon.

>
>
>>If the latter, I would suggest that building a system that requires
>>individual user credentials to be presented to the next hop will be
>>highly problematic.
>
>Then I guess I should be thankful I never suggested it do such a thing.

OK, does this mean you intended that the auth was of the JMAP server to 
the SUBMIT server not on behalf of (using creds of) a JMAP user?

In that case, it's a fairly trivial issue.

Adrien

>
>
>     Ned

v2.23.0 | Report a Bug | By Email