Secure Mail Gateway

À partir de Relution 26.4.0, le service autonome Secure Mail Gateway est un composant obligatoire lorsque la fonctionnalité SMG est utilisée. Cet article décrit la configuration pour les installations on-premise.

Pour la configuration de la Secure Mail Gateway dans Relution : Secure Mail Gateway →

Migration — Que faut-il faire ? #

Feature toggle pour les installations on-premise (26.3) #

Dans Relution 26.3, les installations on-premise peuvent déjà activer le nouveau mode à l’avance. Ajouter le feature toggle SMG_STANDALONE dans le fichier application.yml du serveur Relution :

relution:
  featuretoggle:
    enabledPreviewFeatures:
      - SMG_STANDALONE

Avec la version 26.4.0, le toggle est supprimé — le service autonome est alors actif sans configuration supplémentaire.

Configuration initiale #

1. Créer un Dynamic Role #

Télécharger le modèle de rôle prêt à l’emploi et l’importer dans l’organisation Global sous Paramètres > Gestion des utilisateurs > Permissions :

Télécharger le modèle de rôle SMG →

Il est également possible de créer le rôle manuellement :

1. Naviguer vers Paramètres > Gestion des utilisateurs > Permissions dans l’organisation Global
2. Ajouter un nouveau Dynamic Role
3. Activer la permission Secure Mail Gateway (service account)
4. Enregistrer le rôle

2. Créer un utilisateur technique et une clé d’accès API #

1. Créer un nouvel utilisateur dans l’organisation Global et lui attribuer le Dynamic Role créé ci-dessus
2. Accéder à la page de détail de l’utilisateur et créer une nouvelle clé d’accès API
3. Copier la clé générée — elle n’est affichée qu’une seule fois

3. Déployer le service #

Ajouter le service suivant au compose.yml existant. Ceci n’est nécessaire que si la Secure Mail Gateway est utilisée.

  smg:
    image: relution/relution-smg-standalone:latest
    restart: always
    container_name: smg
    networks:
      - reverse-proxy
    volumes:
      - ./smg/application.yml:/opt/app/config/application.yml:ro
# - ./smg/ca-certs:/opt/app/ca-certs:ro   # voir « Faire confiance à un certificat CA personnalisé » ci-dessous
# environment:
# - JAVA_TOOL_OPTIONS=...                 # voir « Proxy sortant de l'entreprise » ci-dessous

Créer smg/application.yml à côté du compose.yml :

relution:
  server:
    url: https://votre-serveur-relution    # URL de votre serveur Relution
    api-key: votre-cle-api                # Clé d'accès API créée ci-dessus
# honor-proxy-settings: true          # voir « Proxy sortant de l'entreprise » ci-dessous

Démarrer ou redémarrer les services :

docker compose up -d

Configuration du proxy inverse #

Le service SMG expose le point d’entrée /Microsoft-Server-ActiveSync sur le port 8093. Le proxy inverse doit acheminer toutes les requêtes pour ce chemin vers le service SMG — les exemples ci-dessous montrent comment procéder pour Traefik et nginx.

Traefik #

Suivre la configuration Traefik → et ajouter un routeur supplémentaire pour le chemin SMG à côté du routeur relution existant :

http:
  routers:
    smg:
      rule: Host(`external.url`) && Path(`/Microsoft-Server-ActiveSync`)
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
      service: smg
  services:
    smg:
      loadBalancer:
        servers:
          - url: "http://smg:8093"

nginx Alternative à Traefik #

Ajouter le bloc de localisation suivant à la configuration nginx :

location ~ /Microsoft-Server-ActiveSync {
    proxy_read_timeout 2100;
    proxy_pass http://smg:8093;
}

Faire confiance à un certificat CA personnalisé #

Si Exchange présente un certificat signé par une CA interne ou auto-signée, monter un répertoire de fichiers de certificat encodés en PEM dans le conteneur, exactement à /opt/app/ca-certs :

    volumes:
      - ./smg/application.yml:/opt/app/config/application.yml:ro
      - ./smg/ca-certs:/opt/app/ca-certs:ro

Ces certificats sont utilisés lors de la communication avec le serveur Exchange et Relution — aucune propriété de configuration n’est nécessaire. Si rien n’est monté, la fonctionnalité est sans effet et le TLS sortant se comporte comme avant. Ajouter, supprimer ou modifier un certificat nécessite de redémarrer le conteneur ; le répertoire n’est lu qu’une seule fois, au démarrage.

Proxy sortant de l’entreprise #

Les requêtes vers Exchange respectent les propriétés système de proxy standard de la JVM. Les définir via JAVA_TOOL_OPTIONS :

    environment:
      - JAVA_TOOL_OPTIONS=-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=3128 -Dhttps.proxyHost=proxy.example.com -Dhttps.proxyPort=3128

Ajouter -Dhttp.nonProxyHosts (une liste de motifs d’hôtes séparés par |, les jokers * sont pris en charge) pour exclure certains hôtes du proxy — typiquement Exchange lui-même, s’il est accessible directement sans passer par le proxy de l’entreprise.

Par défaut, les requêtes vers le serveur Relution ne passent pas par le proxy — il est normalement accessible directement. Si l’installation atteint Relution via le même proxy qu’Exchange, définir honor-proxy-settings: true dans smg/application.yml :

relution:
  server:
    url: https://votre-serveur-relution
    api-key: votre-cle-api
    honor-proxy-settings: true   # false par défaut ; nécessaire uniquement si Relution est également derrière le proxy

Dépannage #

En cas de problème avec le service SMG — par exemple lors de la connexion à Exchange ou du démarrage du conteneur — augmenter le niveau de journalisation aide à l’analyse. Suivre le guide Niveau de journalisation → pour l’activer.

Le plus simple est d’activer le niveau de journalisation directement dans le conteneur SMG via son application.yml, en ajoutant la section suivante à la fin :

logging:
  level:
    io.relution: DEBUG

Changelog #

Version actuellement disponible via latest : 26.0.4 (au 04.08.2026)