Notes de mise à jour de SecurityGateway for Email Servers v4.5

SecurityGateway for Email Servers fournit une protection anti-spam, antivirus et un contrôle d'accès SMTP aux infrastructures de messagerie nécessitant des outils de sécurité efficaces et complets.

Cliquez ici pour en savoir plus sur SecurityGateway for Email Servers.

SecurityGateway 4.5.1 - 9 mai 2017

NOUVELLES FONCTIONNALITÉS MAJEURES

[15657] SecurityGateway intègre désormais le service RMail™ de RPost®

RMail™ est une solution intuitive, qui n'impose aucune acquisition de logiciels spéciaux aux destinataires de vos e-mails. RMail™ garantit une utilisation plus responsable de la messagerie électronique aux particuliers et aux entreprises de toutes tailles, de tous secteurs, quel que soit le service.

Le service RMail™ est fourni par la technologie Registered Email® de Rpost, standard mondial en matière de preuve de distribution des e-mails. Le service RMail™ étend les possibilités de votre plateforme de messagerie :

Avec un compte RPost gratuit, chaque utilisateur est limité à l'envoi/réception de 10 messages chiffrés par mois. Vous pouvez acheter des messages supplémentaires en vous adressant à RPost.  Cliquez ici pour en savoir plus sur les plans/tarifs de messages supplémentaires.

Le service RMail™ s'active dans Sécurité | RMail™, ou dans les actions des règles de filtrage de contenu.

CHANGEMENTS ET NOUVELLES FONCTIONNALITÉS

CORRECTIFS

SecurityGateway 4.5.0 - 4 avril 2017

CONSIDÉRATIONS SPÉCIALES

[18161] L'option "Accepter la méthode d'authentification CRAM-MD5" disponible dans "Configuration / Utilisateurs | Configuration de la messagerie | Protocole de messagerie" est désormais désactivée par défaut pour des questions techniques et de sécurité. TSL est la méthode privilégiée pour éviter la transmission de mots de passe en clair.

CHANGEMENTS ET NOUVELLES FONCTIONNALITÉS

CORRECTIFS

SecurityGateway 4.0.1 - 26 juillet 2016

CHANGEMENTS ET NOUVELLES FONCTIONNALITÉS

CORRECTIFS

SecurityGateway 4.0.0 - 14 juin 2016

NOUVELLES FONCTIONNALITÉS MAJEURES

[15999] Mise à jour de l'interface web, désormais "mobile first".

L'interface web a été mise à jour et adopte une approche "mobile first" (priorité à l'interface mobile). Les navigateurs pris en charge sont IE 10 ou plus, les dernières versions de Chrome et Firefox, ainsi que la dernière version de Safari sur Mac et iOS. Des problèmes de défilement ont été notés avec les navigateurs intégrés dans les systèmes Android. Mais tout fonctionne correctement lorsque le terminal Android utilise Chrome.

Cette approche repose entièrement sur la taille de la fenêtre utilisée. Qu'il s'agisse d'un téléphone, d'une tablette ou d'un PC, l'interface a la même apparence lorsque la taille de la fenêtre est la même. Le changement le plus important porte sur le menu. Si la fenêtre mesure 956 pixels de large ou moins, le menu est masqué à gauche. Deux méthodes sont possibles pour l'afficher. S'il s'agit d'un appareil tactile, un glissement vers la droite permet d'afficher le menu secondaire. Le même résultat est obtenu avec le bouton "Menu" en haut à gauche de l'écran. En tapant ou en cliquant sur le titre de menu à côté de la flèche gauche, le menu principal s'affiche au-dessus. Le menu en haut à droite contenant les entrées "Aide", "À propos" et "Déconnexion" varie également en fonction de la largeur de la fenêtre. À partir de 768 pixels et plus, les noms des entrées sont affichés ; entre 481 et 767 pixels, seules les icônes apparaissent ; en dessous de 480 pixels, une icône "roue dentée" s'affiche. En cliquant ou en tapant sur celle-ci, un menu déroulant s'ouvre et laisse apparaître les options "Aide", "À propos" et "Déconnexion". Les affichages sous forme de listes contenant plus d'une colonne contiennent des boutons "on/off" pour chaque colonne.

[11232] DMARC

Support de DMARC (Domain-based Message Authentication, Reporting, and Conformance). La spécification DMARC décrit un mécanisme évolutif à l’aide duquel une organisation expéditrice de courrier peut indiquer, via le système de noms de domaine (DNS), les politiques et préférences appliquées au niveau de son domaine en matière de validation, de traitement des messages, et de rapports. Une organisation réceptrice de courrier peut utiliser ces politiques et préférences afin d'améliorer la gestion des e-mails. Des renseignements complets sur le fonctionnement de DMARC sont disponibles sur : http://www.dmarc.org/.

DMARC permet aux propriétaires de domaines d'indiquer comment ils souhaitent gérer les messages qui prétendent venir de leurs domaines alors qu'ils n'ont pas été envoyés par ces derniers. Les politiques de gestion proposées sont : - "none" -- SecurityGateway n'effectue aucune action - "reject" -- SecurityGateway refuse d'accepter le message pendant la session SMTP - "quarantine" -- SecurityGateway insère l'en-tête "X-SGDMARC-Fail-policy: quarantine" dans le message pour qu'il soit déplacé dans le dossier de courrier indésirable de l'utilisateur. Cet en-tête est ajouté uniquement lorsque le résultat de la vérification DMARC est "fail" et que la politique DMARC appliquée est différente de "none". Il est possible de configurer SecurityGateway pour qu'il accepte les messages même si DMARC demande leur rejet. Il s'agit en fait du mode de fonctionnement par défaut. SecurityGateway ajoute alors l'en-tête "X-SGDMARC-Fail-policy: reject" dans le message au cas où vous souhaiteriez effectuer un filtrage plus poussé.

DMARC remplace ADSP et les options de traitement de messages SPF. Vous pouvez néanmoins continuer à utiliser ces fonctionnalités en combinaison avec DMARC. Les fonctionnalités ADSP et SPF sont exécutées après le traitement DMARC lorsque la vérification DMARC est activée.

DMARC repose en partie sur l'utilisation d'une "liste de suffixes publics". Un "suffixe public" est une extension sous laquelle les utilisateurs d'Internet peuvent directement enregistrer des noms. Parmi les exemples de suffixes publics, on retrouve : .com, .co.uk et pvt.k12.ma.us. Une "liste de suffixes publics" est une liste contenant tous les suffixes publics connus. SecurityGateway utilise la liste maintenue par Mozilla Foundation, disponible sur : https://publicsuffix.org/. Une copie de cette liste est enregistrée sous le nom "effective_tld_names.dat" dans le dossier \App\. Il n'existe actuellement aucune source complète ou faisant autorité à elle seule dans le domaine ; c'est un problème que la communauté Internet devrait résoudre. Au fil du temps, le fichier devient obsolète et doit être remplacé dans le dossier \App\ par une version plus récente téléchargée à partir de https://publicsuffix.org/list/effective_tld_names.dat. SecurityGateway télécharge et installe ce fichier automatiquement toutes les deux semaines environ, au cours du processus de maintenance quotidien. Diverses options permettant de gérer cela sont disponibles dans les nouveaux écrans de configuration DMARC. Le journal DMARC et la nouvelle fenêtre DMARC de l'onglet "Sécurité" dans l'interface principale contiennent les résultats de la mise à jour et des autres opérations de traitement DMARC. Si besoin, vous pouvez définir une autre URL de téléchargement mais les données téléchargées doivent être conformes au format de fichier spécifié par Mozilla. Des informations complémentaires sont disponibles à l'adresse mentionnée ci-dessus. SecurityGateway respecte l'algorithme d'analyse de Mozilla à la lettre. Créez un fichier "PUBLICSUFFIX.SEM" (éventuellement vide) et enregistrez-le dans le dossier \App\ de SecurityGateway si vous remplacez ou modifiez le fichier "effective_tld_names.dat" par vous-même, et que vous souhaitez que SecurityGateway le recharge sans redémarrer.

Pour utiliser DMARC en tant qu'expéditeur de courrier, vous devez publier un enregistrement TXT DMARC dans la configuration DNS de votre domaine. Des informations sur la structure de cet enregistrement sont disponibles sur http://www.dmarc.org. Lorsque vous publiez un enregistrement DMARC sur votre DNS, vous pouvez commencer à recevoir des rapports DMARC par e-mail, provenant de différentes sources. Ces rapports sont fournis sous la forme de fichiers XML compressés dont la structure est régie par la spécification DMARC. L'exploitation de ces rapports sort du cadre de l'implémentation DMARC de SecurityGateway. Cependant, les données qu'ils fournissent donnent un aperçu important sur des éléments tels que le flux de la messagerie, l'utilisation incorrecte du domaine, l'intégrité de la signature DKIM et la précision/complétude du chemin SPF. Les adresses auxquelles les rapports sont envoyés sont configurées par vos soins lorsque vous créez votre enregistrement DMARC.

Lorsque vous configurez un enregistrement DMARC pour un ou plusieurs de vos domaines, prenez garde à l'utilisation de "p=reject". En particulier si votre domaine fournit des comptes de messagerie destinés à un usage général par des utilisateurs "humains". Si ces utilisateurs se sont inscrits à une liste de diffusion, utilisent un service de transfert de courrier, ou souhaitent se servir de fonctions communes telles que "partager cet article avec un ami", vous devez savoir dès maintenant que la politique DMARC "p=reject" peut rendre tout cela impossible. La politique DMARC "p=reject" est parfaitement appropriée et utile, mais uniquement lorsqu'elle est appliquée à des domaines qui contrôlent l’utilisation faite de leurs comptes de messagerie (courrier transactionnel, comptes automatisés, autrement dit non gérés par des humains, ou application de politiques d'entreprise contre l'utilisation du compte en dehors de l'entreprise).

Pour prendre en charge les rapports globaux de DMARC, SecurityGateway enregistre les données dont il a besoin conformément à la spécification DMARC. SecurityGateway ignore la balise DMARC "ri=" et génère uniquement des rapports globaux couvrant l'amplitude horaire 00:00:00 UTC - 23:59:59 UTC pour un jour donné. À minuit heure UTC (ne correspond pas nécessairement à minuit en heure locale), SecurityGateway traite ces données enregistrées afin de générer les rapports. SecurityGateway doit être en marche à cette heure ou les données vont s'accumuler sans être jamais utilisées. Si SecurityGateway ne fonctionne pas 24h/24 et 7J/7, il est conseillé de ne pas activer les rapports globaux de DMARC. Cette fonctionnalité est désactivée par défaut.

Les RFC suivantes ont été entièrement implémentées pour le support des rapports d'échec DMARC : - RFC 5965 "An Extensible Format for Email Feedback Reports", - RFC 6591 "Authentication Failure Reporting Using the Abuse Reporting Format", - RFC 6652 "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", - RFC 6651 "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", - RFC 6692 "Source Ports in Abuse Reporting Format (ARF) Reports" Les rapports d'échec sont créés en temps réel, dès lors que des incidents se produisent. SecurityGateway implémente les rapports d'échec DMARC de type "AFRF" et non "IODEF". Par conséquent, seules les valeurs "afrf" dans les balises DMARC "rf=" sont prises en compte. Pour plus de détails, veuillez vous reporter à la spécification DMARC. Plusieurs rapports d'échec peuvent être générés à partir d'un seul message selon le nombre de destinataires indiqués dans la balise "ruf" de l'enregistrement DMARC, et selon la valeur de la balise "fo=", qui indique le nombre d'échecs d'authentification indépendants rencontrés par le message pendant le traitement. Lorsque la balise DMARC "fo=" demande un rapport sur les échecs SPF, SecurityGateway envoie les rapports d'échec SPF conformément à la RFC 6522. Par conséquent, les extensions de cette spécification doivent figurer dans l'enregistrement SPF. Les rapports d'échec SPF ne sont pas envoyés indépendamment du traitement DMARC, ni en l'absence des extensions de la RFC 6522. Lorsque la balise DMARC "fo=" demande les rapports d'échec DKIM, SecurityGateway envoie les rapports d'échec DKIM et ADSP conformément à la RFC 6651. Par conséquent, les extensions de cette spécification doivent figurer dans l'en-tête "DKIM-Signature" et le domaine doit publier un enregistrement TXT de rapport DKIM valide dans le DNS et/ou des extensions ADSP valides dans l'enregistrement TXT ADSP. Les rapports d'échec DKIM et ADSP ne sont pas envoyés indépendamment du traitement DMARC, ni en l'absence des extensions de la RFC 6651. Pour plus d'informations, veuillez vous reporter aux spécifications indiquées. Le rapport d'échec DMARC est désactivé par défaut.

Remarque importante : un enregistrement DMARC peut préciser que les rapports doivent être envoyés à un intermédiaire agissant pour le compte du propriétaire du domaine. C'est le cas notamment lorsque le propriétaire de domaine fait appel à un tiers pour surveiller les flux de messagerie, détecter les problèmes de violations et de performances. La réception de telles données par des tiers peut être ou ne pas être autorisée par votre politique de confidentialité, vos conditions d'utilisation ou tout autre document. Nous vous conseillons de passer en revue vos politiques internes afin de savoir si elles limitent l'utilisation et la transmission des rapports DMARC, auquel cas il serait préférable de les désactiver.

STARTTLS doit être utilisé par DMARC dès lors que les destinataires des rapports le permettent, même s'il n'est pas possible de le prévoir ni d'établir de politique. Par conséquent, vous devez activer STARTTLS (Configuration / Utilisateurs | Système | Cryptage).

L'en-tête "Authentication-Results" a été étendu afin d'inclure les résultats du traitement DMARC. Remarque : "Authentication-Results" contient des données sous forme de commentaires pour la correction d'erreurs, y compris la politique DMARC demandée par le propriétaire du domaine, qui ne correspond pas nécessairement à l'action appliquée au message. Par exemple, lorsque le résultat de la vérification DMARC est "pass", le contenu de la politique DMARC importe peu puisque que celle-ci s'applique uniquement lorsque le résultat de la vérification est "fail". De façon similaire, si le résultat de la vérification DMARC est "fail" et que la politique indique "reject", le message peut tout de même être accepté en raison d'une politique locale. L'utilisation de cet en-tête à des fins de filtrage nécessite de prendre en compte tous ces éléments. Vous pouvez par ailleurs utiliser "X-SGDMARC-Fail-policy: quarantine" ou "X-SGDMARC-Fail-policy: reject" pour filtrer vos messages et les envoyer dans les dossiers de spam. SecurityGateway retire l'en-tête "X-SGDMARC-Fail-policy:" de chaque message entrant.

Les messages doivent être conformes à la section 15.1 de la spécification DMARC et respecter les en-têtes "From" de la RFC 5322 ou ils ne seront pas traités. Cela signifie simplement que l'absence d'un seul champ "RFC5322.From" (un et un seul) rend le message invalide, et par conséquent invalide pour le traitement DMARC.

Plusieurs écrans ont été ajoutés dans "Ctrl+S | Anti-usurpation" pour la configuration des options DMARC.

Le contrôle DMARC nécessite l'activation de la vérification SPF et/ou DKIM car il s'appuie sur les identités vérifiées par ces deux mécanismes. Il n'est pas possible de faire une bonne utilisation de DMARC avec le courrier entrant sans qu'au moins une de ces deux technologies ne soit activée. L'interface utilisateur va dans ce sens.

[3961] Lier le domaine à une adresse IP

Lorsque les serveurs disposent de plusieurs adresses IP, chaque domaine peut être lié à une adresse IP spécifique. Le courrier provenant de ce domaine est envoyé à partir de cette adresse IP.

Un nom d'hôte SMTP peut également être configuré pour le domaine. Cette valeur correspond au nom de domaine entièrement qualifié (FQDN) utilisé dans l'instruction SMTP HELO/EHLO lors de l'envoi de courrier pour le domaine. Pour les connexions entrantes, cette valeur est utilisée sauf si plusieurs domaines sont liés à l'adresse IP. Dans ce cas le FQDN utilisé est celui associé au domaine classé le premier par ordre alphabétique.

CHANGEMENTS ET NOUVELLES FONCTIONNALITÉS

CORRECTIFS

Copyright ©2008-2016 Alt-N Technologies, Ltd.