> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Groupes de distribution

> L'alias à l'échelle de l'organisation qui se déploie vers plusieurs destinataires, en JMAP : des membres de trois genres, l'imbrication avec un plafond de profondeur et un cache aplati, qui voit les membres, la garde du nom contre l'éclipse d'un collègue, les alias historiques et le budget de diffusion par organisation.

Un `DistributionGroup` est une extension JMAP d'OxiMail (`urn:oximail:params:jmap:distributiongroups`) : un alias au domaine de l'organisation qui résout vers N destinataires. `equipe-dev@example.com` atteint `alice`, `bob` et `carol` ; `partenaires@` atteint une adresse externe et un autre groupe. C'est un **alias**, rien de plus : pas d'état d'adhésion côté destinataire, pas de modération, pas d'archive. Ce qui arrive dans la boîte d'un membre montre toujours `equipe-dev@example.com` dans `To:`, jamais la liste des membres.

## L'objet de capability

```json theme={null}
"urn:oximail:params:jmap:distributiongroups": {
  "maxNestingDepth": 10,
  "maxFlatSize": 1000,
  "maxGroupsPerTenant": 1000,
  "maxGroupsPerOwner": 100
}
```

Ce sont les plafonds **durs**, annoncés pour qu'un client refuse une modification trop grande avant le serveur. L'exploitant règle la profondeur effective sous le plafond dur : `[distribution_groups] max_depth` (3 par défaut, plafonné à 10), `max_flat_size` (1000), `fanout_per_minute` (5000) et `enabled`.

## Objets et méthodes

| Objet | Méthodes | Notes |
| - | - | - |
| `DistributionGroup` | `get`, `set`, `query`, `queryChanges`, `changes` | `id`, `name` (la partie locale), `displayName`, `description`, `ownerAccountId`, `membersVisibleToTenant`, `memberCount`, `members`, `aliases`, `createdAt`, `updatedAt`. |

Un **membre** est de l'un de trois genres, étiqueté par `kind` : `account` (`accountId` ; l'`email` affiché est résolu par le serveur à la lecture et jamais lu à l'écriture, si bien qu'un client référence par l'identifiant seul), `email` (une adresse externe), `group` (`groupId`, imbriqué ; son `name` est une copie d'affichage, même règle). Une mise à jour modifie l'appartenance par `addMembers` et `removeMembers` plutôt qu'en remplaçant la liste.

`DistributionGroup/query` n'accepte encore ni filtre ni tri : un filtre ou un tri fourni est refusé (`unsupportedFilter`, `unsupportedSort`), jamais exécuté comme s'il était absent.

## Comportements à connaître

* **N'importe qui peut créer ; le propriétaire ou un administrateur peut modifier.** Une création par n'importe quel membre de l'organisation en fait le propriétaire ; nommer un autre `ownerAccountId` exige un administrateur. La mise à jour et la destruction sont au propriétaire ou à un administrateur. Chaque mutation d'appartenance et chaque destruction écrivent une ligne d'audit dans la transaction du gestionnaire, puisqu'un groupe utilisé dans un droit `shareWith` change les droits effectifs de N comptes.
* **Un groupe ne peut pas éclipser un collègue.** À la réception, l'expansion passe avant la résolution du compte, à dessein, si bien qu'un groupe portant la partie locale d'un collègue détournerait son courrier vers les membres en silence ; la création et le renommage refusent tout nom déjà porté par un groupe vivant, un alias historique, une adresse de compte ou un alias d'adresse de l'organisation. La garde est par organisation : un groupe `equipe` dans une organisation ne déploie jamais un message envoyé à `equipe@` au domaine d'une autre, qui est transmis tel quel.
* **Renommer garde l'ancien nom vivant.** Le `name` précédent devient un alias historique, servi dans `aliases` (le plus ancien d'abord), et `ancien-nom@` continue de résoudre.
* **Qui voit les membres.** Un administrateur, le propriétaire (qui gère l'appartenance doit pouvoir la lire), un membre, ou tout le monde quand `membersVisibleToTenant` est vrai ; les autres reçoivent `members: null`. `memberCount` est toujours servi.
* **L'imbrication est bornée et précalculée.** Un `set` recalcule l'expansion aplatie du groupe **et de chacun de ses ancêtres** dans la même transaction, en refusant un cycle, une profondeur au-delà du plafond et une taille aplatie au-delà du plafond par une erreur typée ; l'objet refusé revient à son point de sauvegarde pendant que les autres objets de l'appel continuent. La livraison et la soumission lisent ensuite le cache aplati, une seule requête SQL et aucune récursion.
* **Un budget de diffusion par organisation.** Chaque expansion consomme N unités d'une fenêtre glissante d'une minute (`fanout_per_minute`) ; au-delà, la résolution échoue au lieu d'envoyer, si bien qu'un expéditeur emballé ne peut pas faire d'un groupe une inondation.
* **Un membre plein est sauté.** À la livraison à un groupe, un membre dont la boîte dépasse son quota est sauté, journalisé et compté ; les autres membres reçoivent le message ([stockage](../operator/mailboxes-storage#les-quotas)). Quand un collaborateur part, `oximail account offboard` nomme les groupes dont il est membre et n'en modifie aucun : le courrier de groupe suit déjà la redirection de l'adresse membre par membre ([CLI](../operator/cli)).

Les règles de rigueur sont identiques à la [surface courrier](./jmap-mail) : identifiants inconnus dans `notFound`, `invalidProperties` plutôt qu'une coercition, `stateMismatch` sur `ifInState`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.