Global administrators can now allow selected domain administrators to edit the Max Users value for their domains. Domain administrators cannot lower the limit below the domain's current user count. An operator setting can require domain administrators to set a user limit when creating new domains and, when enabled, also prevents them from removing a domain's existing user limit. An optional confirmation, disabled by default, warns domain administrators that increasing the user limit may affect billing. These domain administrator billing options are available under Setup / Users > Accounts > Administrators > Options.
SecurityGateway informe désormais les administrateurs du domaine concerné lorsque le domaine atteint 75 %, 90 % ou 100 % de sa limite Max Users configurée. Les administrateurs peuvent activer ou désactiver ces notifications depuis Setup > Users > Accounts > Administrators > Options.
Quarantine reports, administrator alerts, secure message notifications, 2FA verification emails, low disk space warnings, and other system-generated messages now use a consistent branded email layout with clearer action buttons and improved mobile readability.
domain. De nombreux bots de spam envoient EHLO domain au lieu d'un nom d'hôte réel. Cette nouvelle valeur par défaut aide à arrêter ces connexions plus tôt dans la conversation SMTP. Elle est ajoutée automatiquement lors des nouvelles installations et pendant les mises à niveau.
L'interface web a été mise à jour avec une disposition plus épurée, une hiérarchie visuelle améliorée et une apparence générale plus soignée. Les thèmes clair et sombre par défaut ont tous deux été actualisés. Les navigateurs mobiles sont mieux pris en charge, en particulier sur la page du tableau de bord. Un nouveau thème classique est disponible pour les utilisateurs qui préfèrent une expérience plus proche des versions antérieures.
SecurityGateway inclut désormais une API REST/JSON standard, décrite par OpenAPI, qui facilite l’automatisation de l’administration et l’intégration du produit aux systèmes de provisionnement, aux plateformes d’identité et aux workflows personnalisés.
Gérer les objets principaux : L’API prend en charge les utilisateurs, les domaines, les alias de domaine, les administrateurs, les clés d’API, les paramètres de serveur/domaine/utilisateur, les listes d’autorisation, les listes de blocage, les serveurs de messagerie, les sources de vérification, les sélecteurs DKIM, les magasins d’archivage, les scripts de filtrage de contenu Sieve, les entrées IP Shield, les entrées Dynamic Screening et les abonnements aux webhooks, ainsi que des compteurs de performance en lecture seule.
Sécuriser l’accès avec des clés d’API : Les
administrateurs peuvent créer des clés d’API depuis Settings > API Keys.
Documentation intégrée : une documentation OpenAPI lisible par machine est disponible via le serveur web à l’adresse /api/v1/openapi et peut être importée directement dans des outils tels que Postman. La documentation HTML générée est disponible sur le disque à l’adresse /docs/api/api_openapi.htm ou via le serveur web à l’adresse /api_openapi.html.
Note de compatibilité : l’API XML-RPC existante reste disponible, mais toute nouvelle automatisation doit utiliser l’API REST. Il s’agit d’une version initiale ; davantage de points de terminaison et de fonctionnalités seront ajoutés dans les versions futures.
Les administrateurs globaux peuvent désormais contrôler les zones produit que chaque administrateur de domaine peut gérer. Les autorisations sont configurées par administrateur depuis la boîte de dialogue de modification de l’administrateur. Une nouvelle page Autorisations par défaut des administrateurs de domaine (Configuration > Administrateurs > Autorisations d’administrateur par défaut) définit les autorisations initiales pour les nouveaux administrateurs de domaine et peut appliquer ces valeurs par défaut aux administrateurs existants en masse. Les valeurs par défaut peuvent être remplacées pour chaque domaine.
Accès en lecture seule : Les administrateurs de domaine qui ne disposent pas de l’autorisation de gérer une zone de fonctionnalité conservent un accès en lecture seule à celle-ci pour leurs domaines. L’archivage et RMail™ constituent l’exception. Au lieu de passer en lecture seule, leurs pages sont entièrement masquées pour les administrateurs de domaine qui ne disposent pas de l’autorisation de les gérer. Cela préserve leur comportement antérieur à la version 12.5 et permet aux fournisseurs qui ne proposent pas ces fonctionnalités de les garder hors de vue de leurs administrateurs de domaine.
Délégation : L’autorisation "Administrateurs de domaine (Délégation)" contrôle si un administrateur de domaine peut créer ou gérer d’autres administrateurs pour ses domaines. Un administrateur de domaine ne peut pas accorder une autorisation qu’il ne détient pas lui-même.
Comportement lors de la mise à niveau : Toutes les zones de fonctionnalité disponibles pour les administrateurs de domaine avant cette version restent activées par défaut pour les administrateurs de domaine existants après la mise à niveau.
l'écran dynamique a été étendu avec des contrôles supplémentaires sur la manière dont les tentatives d'authentification échouées sont suivies et bloquées. Configurez-les sous Securité > Protection contre les attaques > Ecran Dynamique.
Temporisation flexible : Les durées de blocage et les fenêtres de suivi peuvent désormais être définies en minutes, en heures ou en jours.
Durée de blocage progressive : Un multiplicateur de récidive peut prolonger la durée de blocage lors des violations suivantes sans modifier la règle de base.
Blocage au niveau du sous-réseau : L'agrégation CIDR facultative bloque une plage réseau plus large lorsque les attaques proviennent de nombreuses adresses IP proches.
Suppression des échecs en double : Les échecs qui répètent le même mot de passe peuvent être exclus du décompte des échecs, ce qui réduit les blocages inutiles dus aux informations d'identification mises en cache tout en continuant à comptabiliser les échecs distincts.
Les domaines utilisant Google Workspace peuvent désormais vérifier les utilisateurs locaux via l’API Google Workspace au lieu des rappels SMTP. L’intégration résout les alias et utilise un compte de service Google Cloud ainsi qu’OAuth 2.0. Configurez cela sous Configuration > Sources de vérification.
Les règles de filtrage des pièces jointes peuvent désormais correspondre au type de fichier détecté en plus de, ou à la place de, l’extension de fichier. Configurez cette option sous Sécurité > Filtrage > Pièces jointes.
SecurityGateway peut désormais détecter les pièces jointes dont le type de fichier réel ne correspond pas à leur extension de fichier (par exemple, un exécutable renommé en .pdf). Les pièces jointes non concordantes peuvent être refusées, mises en quarantaine ou acceptées, avec un marquage optionnel de l’objet et un ajustement du score. Configurez ce paramètre sous Securité > Filtrage > pièces jointes deguisées.
Configuration > Serveur > Paramètres de domaine, désactivé par défaut, les domaines nouvellement créés entrent dans un état en attente et n’acceptent pas de courrier tant que le propriétaire n’a pas publié un enregistrement TXT à l’adresse _sgverify.<domain> avec le jeton affiché sur la page de modification du domaine. La vérification s’exécute à la demande depuis la page de modification du domaine ou via POST /api/v1/domains/{id}/verify, et toutes les heures en arrière-plan. Un nouvel événement de webhook domain.verified est déclenché en cas de réussite. Les administrateurs globaux peuvent ignorer la vérification pour chaque domaine lors de la création d’un domaine.
Configuration > Système > Protocole PROXY.
Archivage > Messages en échec, et en créant un lien direct vers cette vue après la connexion.
Sécurité > Listes d’autorisation > Configuration, avec les remplacements par domaine correctement respectés.