[JMAP] Re: JMAP for Calendars comments
Mauro De Gennaro <mauro@stalw.art> Mon, 06 October 2025 06:01 UTC
Return-Path: <mauro@stalw.art>
X-Original-To: jmap@mail2.ietf.org
Delivered-To: jmap@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B6DA26DCC088 for <jmap@mail2.ietf.org>; Sun, 5 Oct 2025 23:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=stalw.art header.b="nHqRhCOJ"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=stalw.art header.b="qD4pGoHI"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK6m-FAftTCY for <jmap@mail2.ietf.org>; Sun, 5 Oct 2025 23:01:28 -0700 (PDT)
Received: from mail.stalw.art (mail.stalw.art [135.181.195.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2ED626DCC083 for <jmap@ietf.org>; Sun, 5 Oct 2025 23:01:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=202404r; d=stalw.art; c=relaxed/relaxed; h=Message-Id:To:Date:Subject:From; t=1759730487; bh=j8QckxNamlUw2ZzGHoA6fMN YExFHz3OV9axnCtLKvIQ=; b=nHqRhCOJdky7xS0jAPsxw/gOaN7HPTsfVoMAuuHRkFMquBuJ9+ 3Vm04j1EhtjvaxKzq+W9seL1/NKpNtOpjkhGYN0eXXX0quiOmzylkJFJa0zNRERndQ0sx+IAdAn cpM9tX/zTG6yIsGKkoiaaOd3DKa9F5xjUjuhqul7MM6oHU+kbPamq5l3ucfItJ1PW/qRKgWV7if Amjz7a3DlVIr81s8EZUMjLPUmsRbreUYbfyvhLJP669HFKzzG0beLUYXmwDv7mkev+XDQXWKFWk BqSrZnMHrn5m9u4mR0z1QPtbCAq9E/Hq+cwfxIW+XQ5h6g/QHTWpF3ol9Ylq2u4X+0Q==;
DKIM-Signature: v=1; a=ed25519-sha256; s=202404e; d=stalw.art; c=relaxed/relaxed; h=Message-Id:To:Date:Subject:From; t=1759730487; bh=j8QckxNamlUw2ZzGHoA6fMN YExFHz3OV9axnCtLKvIQ=; b=qD4pGoHIc175Sug6yoE3qo2d1Gvh1rwngdouUt25+hPsuq7ov+ wDTUUHb5YexJd0xtXryxNsgBYS8MSxCrOgCw==;
From: Mauro De Gennaro <mauro@stalw.art>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.11\))
Date: Mon, 06 Oct 2025 08:01:16 +0200
References: <101DEC25-A12F-4063-90FB-446C6E5190BF@stalw.art> <E7E219C3-EC93-4DEA-8945-2643D9FE01E6@stalw.art> <EA5E45B3-3538-48B2-8F4A-8B6864CF8C23@beonex.com>
To: Ben Bucksch <ben.bucksch@beonex.com>, IETF JMAP Mailing List <jmap@ietf.org>
In-Reply-To: <EA5E45B3-3538-48B2-8F4A-8B6864CF8C23@beonex.com>
Message-Id: <C54604A1-AAA6-4346-A204-9CF49CAAB884@stalw.art>
X-Mailer: Apple Mail (2.3731.700.6.1.11)
Message-ID-Hash: SPYBAOTG5V3VT3GGNZZA5UDQLYYO32EW
X-Message-ID-Hash: SPYBAOTG5V3VT3GGNZZA5UDQLYYO32EW
X-MailFrom: mauro@stalw.art
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [JMAP] Re: JMAP for Calendars comments
List-Id: JSON Meta Access Protocol <jmap.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/ppoyNvfLlLNCE0B7nA2XVJDHIHE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Owner: <mailto:jmap-owner@ietf.org>
List-Post: <mailto:jmap@ietf.org>
List-Subscribe: <mailto:jmap-join@ietf.org>
List-Unsubscribe: <mailto:jmap-leave@ietf.org>
1. Yes, in JMAP for Mail a user can create multiple identities and send messages from different email addresses associated with their account. However, Stalwart deliberately restricts what addresses can be added as identities. Users cannot create identities for email addresses or aliases that don’t belong to them. There are a few exceptions: for example, if the added address matches the subaddressing scheme configured by the organization, or if the address is associated with a group the user is a member of. But in general, allowing arbitrary addresses is not permitted to avoid spam, prevent impersonation of other users, and maintain clear ownership of identities. 2. The same principle applies to calendar addresses. Users shouldn’t be able to add ParticipantIdentity objects with calendar addresses that they don’t control or have access to. This is especially important because JMAP for Calendars derives certain access permissions based on these identities. For example, the ability to update RSVP status or to add oneself as a participant. If users could freely add arbitrary calendar addresses, those permission checks could be bypassed or misused. What I was proposing, for simplicity, is that since the server already knows which calendar addresses a user is allowed to use, we could just expose them directly as part of the Principal object. Similar to how CalDAV handles this with the calendar-user-address-set property. That would make it clearer which identities are valid and avoid potential issues with unauthorized addresses. Best, Mauro > On 5 Oct 2025, at 22:47, Ben Bucksch <ben.bucksch@beonex.com> wrote: > > > > Am 5. Oktober 2025 17:30:41 MESZ schrieb Mauro De Gennaro <mauro=40stalw.art@dmarc.ietf.org>: >> For example, in Stalwart, calendar addresses are derived from the account’s email address(es) and cannot be modified by users. If we allow users to add other participant identities that are not their email addresses, how should the server validate that they are authorized to use those identities? > > 1. Doesn't JMAP allow for multiple identities and email addresses that are associated with the same mail account? Presumably, if the account has multiple email addresses, then for a reason. Why would an invitation reply be restricted to only 1 of them? > > 2. If the invitation is for a particular email address, the user should be allowed to answer the invitation with the same address, even if it's different from the main email address of the account. Otherwise the user has a problem, because the wrong email address leaks. Or the organizer has a problem, because he gets an answer from an email address that he didn't invite. Or both. > > _______________________________________________ > JMAP mailing list -- jmap@ietf.org > To unsubscribe send an email to jmap-leave@ietf.org
- [JMAP] JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Ben Bucksch
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins
- [JMAP] Re: JMAP for Calendars comments Mauro De Gennaro
- [JMAP] Re: JMAP for Calendars comments Robert Stepanek
- [JMAP] Re: JMAP for Calendars comments Neil Jenkins