Re: [Jmap] Submission

Ned Freed <ned.freed@mrochek.com> Mon, 24 April 2017 00:58 UTC

Return-Path: <ned.freed@mrochek.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 99879124217 for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 17:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 uMQcwXXCDnCB for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 17:58:32 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A5B1204DA for <jmap@ietf.org>; Sun, 23 Apr 2017 17:58:32 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QDIWQDJNC0008AMC@mauve.mrochek.com> for jmap@ietf.org; Sun, 23 Apr 2017 17:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1492995206; bh=hd6lzE1wthVcJ50S4su7q2Gl1AJa6zhobdmZQ3MworA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=e5cAeCY6tUnJ1gwcNfRJjtIPVlJ3b7Tqk/dFYjEKbO1huK70jjRLPtj424FAWKEq6 embtTzP1c+vZfeDpYX2to95n1jWAPwdR5TxRDJiCkgtWWdcFhTuzNti/nyKr0r3k+U bgMnIU1cCBHHJwwQo3i3L0vatHIrfRd64PgXk9Zc=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QD64433M0W00005B@mauve.mrochek.com>; Sun, 23 Apr 2017 17:53:23 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, "jmap@ietf.org" <jmap@ietf.org>
Message-id: <01QDIWQBJR5K00005B@mauve.mrochek.com>
Date: Sun, 23 Apr 2017 17:42:24 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 24 Apr 2017 00:29:40 +0000" <em388d79dd-ef11-4b05-89ce-7b61247940d0@bodybag>
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>
To: Adrien de Croy <adrien@qbik.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/HGI7UfAeP6JcdWOhxst2mGMABdg>
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 00:58:34 -0000


> ------ 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.

> 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.

> 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.

				Ned