Dessine moi une archi mail.

Exchange intégre OWA ( Outlook Web Access ), qui fera office de webmail, c'est fait pour ! L'exchange étant derrière une IP qui utilisait déjà le port 80 et le 443, j'en ai profité pour mettre en place un Vulture. Vulture est un reverse-proxy SSO ( Single Sign On ) avec forward de l'authentification aux applications. Bon, ça paraît compliqué comme ça, mais c'est tout simple : Vous vous identifiez une première fois sur le portail SSO de Vulture, avec votre login et mot de passe Active Directory ( Vulture va chercher tout ça dans l'annuaire de votre contrôleur de domaine ). Il vous reconnaît comme vous même ( ouf ! ), il faut maintenant montrer patte blanche sur l'OWA ! Vous admettrez que s'identifier une première fois sur le reverse proxy pour avoir le droit d'accèder à votre portail mail qui utilise exactement le même login, donc taper le même login deux fois, et pire, si vous êtes paranoïaque, le faire transiter deux fois sur le web, c'est assez agaçant ! Vulture va donc propager vos précédent logins sur l'authentification HTML d'Exchange ( vous devez le configurer pour, évidemment .. ). Vulture sait faire celà avec bien d'autre systèmes d'authentification. Jetez un oeil sur le site de l'application.

 

Pour ce qu'il est de bon goût d'appeler le MTA (Mail Transfer Agent), il a été retenu un splendide PostFix. Postfix aura donc la charge de relayer les mails vers le bon serveur mail, étant donné que je ne relaie pas que mes mails, mais ceux d'autre gentils gens dont je ne gère cependant pas les serveurs de messagerie finaux.

Comme il faut bien faire un peu de filtrage sur les mails entrant (95% de spams à l'arrivée sur le MTA), j'ai choisi l'option la plus simple, et surement une des plus efficace, le greylisting.

Kézako ?

Le greylisting est une technique de filtrage de mail qui consiste, dans un premier temps, quand l'e-mail inconnu arrive sur le MTA, à refuser la transmission de celui-ci (il est droppé, quoi). Le programme de greylisting note le triplet : adresse IP du serveur expéditeur, e-mail de l'expéditeur, e-mail du destinataire. Le greylisting est basé sur le fait qu'un expéditeur légitime refera une demande de transmission du mail avec exactement le même triplet, après environ 15 à 20 minutes d'attente, cela dépend de la configuration du relai. Le triplet accepté est noté dans une whitelist, et tout mail se présentant de nouveau avec ce triplet est directement accepté (hourra !). Le principal problème du système est qu'il induit un retard à la livraison du premier mail. Une fois celui-ci livré, les communications se font normalement. 

Le programme de greylist pour PostFix a été nommé, non sans originalité, PostGrey. Il s'implémente très facilement sur Postfix. (C’est l'option smtpd_recipient_restrictions de la configuration de postfix). Le greylist étant déjà pas mal, il faut rajouter une couche en plus, histoire d'éliminer tout spam qui par malchance pourrait copier un relai de mail légitime avec le système des RBL. Quelques RBL en plus du greylist et voilà, vous êtes protégé. Héhé. (  et pour le coup, ça vous aura pris deux grosses heures sans se presser, et n'aura rien coûté en licence.)

Postfix / Postgrey trouve cependant vite ses limites en environnement professionnel, le système n'étant pas très scalable, surtout pour Postgrey, qui gère le triplet totalement avec un fichier texte. Il faut vite lui adjoindre d'autre solutions plus complètes ( un spamassassin, un clamAV, voir même un postgrey utilisant une base de données), voir même se porter vers des solutions propriétaires avec licence ( Sophos, Ironport - c'est du Cisco, en plus :-D ).

Pour faire tourner Postfix et Postgrey, j'ai choisi Debian, comme distribution. On s'entend bien.

Alors donc, qu'est ce que tout celà nous donne sur un mail entrant.

1°) Le mail arrive. Il est greylisté. Le triplet est pris par postgrey.
2°) Le MTA distant retry : le mail passe. Le MTA ne retry pas avant l'expiration du greylisting ( 15 à 20 minutes ) : pas de délivrance du spam.
3°) Si il y a retry, vérification que l'IP n'est pas dans les RBL
4°) Délivrance au serveur Exchange

Et pour bien cacher le serveur Exchange et pour que les mails sortant des domaines gérés sortent bien de l'IP du MX de ces mêmes domaines, l'exchange utilise le postfix pour envoyer ses mails vers l'extérieur. Les mails des domaines gérés par le postfix ne sortent donc pas des équipements contrôlés ( et c'est vachement rassurant ! ).

Ce n’est qu’une petite présentation rapide et qui n’aide pas vraiment à mettre en place le système, mais il m’aurait fallu beaucoup plus de temps pour expliquer l’installation en détail et expliciter les points de configuration important ! Une autre fois peut-être ?

Bonne soirée.