Archive

Archives pour la catégorie ‘Courrier électronique’

Analyser un mail via Spamassassin en console

23/01/2009

Il est parfois utile de passer un mail à spamassassin manuellement pour voir le détail des tests entrepris et surtout la conclusion à la fin du traitement.

Copiez-collez le mail entier (headers + corps) dans un fichier texte et tapez la commande suivante:

spamassassin -D -t < mail.txt 2>&1

S’affichera alors le détails des actions entreprises. Vous pouvez faire un grep sur les mots clés qui vous intéressent (par exemple pour voir le résultat de l’examen SPF).

Courrier électronique

Ajout du support TLS pour Postfix

22/01/2009

Si vous souhaitez permettre à vos utilisateurs de se connecter de manière sécurisée à votre serveur SMTP afin que les informations tranitant (mails et login/mot de passe) ne circulent pas en clair sur tout le réseau, vous pouvez activer une couche TLS directement dans Postfix.

Vous pouvez donc acheter un certificat auprès de l’autorité de certification de votre choix ou l’auto-générer si cette solution vous convient.

Dans le fichier /etc/postfix/main.cf, ajoutez les lignes suivantes:

smtpd_use_tls = yes
smtpd_tls_cert_file = /path/to/server.crt
smtpd_tls_key_file = /path/to/server.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Vous pouvez ensuite redémarrer Postfix et activer le support TLS dans votre client mail.

Note: SSL a été renommé TLS suite au rachat du brevet de Netscape par l’IETF en 2001.

Courrier électronique , ,

Utilisateur master avec Dovecot

21/01/2009

Il est parfois utile de pouvoir se connecter sur une des boites mails hébergées sans connaître son mot de passe pour diverses raisons:

  • via un script pour analyser d’éventuels mails identifiés comme spam/ham par l’utilisateur;
  • via un script pour archiver des emails anciens;
  • directement afin de reproduire un bug signalé par l’utilisateur.

Il est évident que cette technique ne peut être utilisée simplement pour consulter les emails des utilisateurs à leur insu; c’est une atteinte à la vie privée qui peut être poursuivie par les tribunaux. Vous êtes donc prévenu, et comme pour tous les articles de ce blog, vous mettez ce qui suit en oeuvre sous votre entière responsabilité et en assumez pleinement les éventuelles conséquences.

Cette mise en garde étant faite, le concept est donc de définir un couple login/mot de passe ayant accès à toutes les boites mails hébergées sur votre serveur. Cet utilisateur master n’a rien à voir avec les utilisateurs mail déjà existants.

Dans le fichier /etc/dovecot/dovecot.conf, rajoutez la directive auth_master_user_separator=*. Puis, recherchez la section auth default et complétez-la pour qu’elle ressemble à ce qui suit:

auth_default {
  passdb passwd-file {
   args = /etc/dovecot/passwd.masterusers
   master = yes
  }
}

Le fichier /etc/dovecot/passwd.masterusers est de type htaccess. Voici les commandes pour le générer:

touch /etc/dovecot/passwd.masterusers
htpasswd -s /etc/dovecto/passwd.masterusers admin

Vous donnez alors le mot de passe de l’utilisateur admin. Vous pouvez répeter la dernière ligne autant de fois que désiré avec d’autres noms d’utilisateurs.

Les utilisateurs master pourront alors se connecter au moyen de adresse@domaine.com*admin et du mot de passe associé au compte admin.

Courrier électronique

Petit résumé des bonnes pratiques pour l’envoi de mails en masse

19/01/2009

Si vous gérez un site web ou directement le serveur d’hébergement, certaines bonnes pratiques sont indispensables si vous voulez que l’envoi de mails à partir de votre serveur ne devienne pas un cauchemar. Dans le cadre d’une mailing liste ou newsletter,  il faut s’assurer que l’internaute qui donne son adresse est d’accord pour recevoir les mails que vous lui envoyez, qu’il a bien tapé son adresse lui-même et qu’elle est valide. Voici comment il est possible de s’en assurer:

  • vérifier que le domaine utilisé existe et possède un champ de type MX. Si ce n’est pas le cas, l’internaute a probablement fait une faute de frappe; vous pouvez donc lui représenter le formulaire en lui disant de vérifier le nom de domaine entré;
  • vérifier que vous avez affaire à un internaute et pas à un robot. Pour ce faire, vous pouvez utiliser une image de type captcha, ou positionner des champs cachés dans le formulaire qu’un utilisateur normal laissera vide (puisqu’il ne les voit pas). Tandis que le robot a tendance à mettre n’importe quoi dans tous les champs qu’il trouve. Si l’image ne vous plaît pas pour diverses raisons, il est aussi possible d’utiliser une autre vérification, par exemple un calcul simple de type « combien font deux plus trois »;
  • envoyer un email à l’adresse en demandant à l’internaute de cliquer sur un lien pour valider son inscription. Le mail doit idéalement ne pas être kilométrique, rappeler qu’il a donné son adresse, que s’il ne fait rien il ne recevra rien et que dans le cas où il valide il lui est toujours possible de se désinscrire à tout moment. C’est ce qu’on appelle le double opt-in.

Ensuite, il existe une série de chose qu’il est possible de mettre en place côté serveur pour espérer que les mails passent au mieux:

  • posséder un reverse valide sur vos IP. Il faut que la chaîne IP -> reverse -> IP soit valide. C’est à dire que le reverse donné par votre IP doit donner l’IP;
  • insérer un champ SPF dans les entrées DNS de votre nom de domaine. Ce champ désigne les adresses IP qui envoient des emails à partir de votre nom de domaine. Si on reçoit un email à partir d’une IP non déclarée dans le SPF, on peut être quasi sûr que ce mail est un spam vu qu’il n’a pas été émis depuis un serveur de courrier autorisé.
  • utiliser la technique DKIM/Domain Keys qui ajoute une empreinte cryptographique dans les headers des emails envoyés. Grosso modo, vous générez une paire de clé RSA et publiez dans les entrées DNS de votre domaine la clé publique. La clé privée est gardée secrète et vous permet de signer les emails. Si le mail est altéré pendant son transfert, la signature ne sera plus valide. Comme avec SPF, on peut également vérifier que le mail a bien été envoyé depuis un des serveurs autorisés via cette technique.

Gérer une mailing liste ou newsletter impose aussi de gérer les retours d’erreurs des emails envoyés. Des adresses peuvent cesser d’exister, être en overquota permanent, il est alors nécessaire d’enlever ces adresses de la base afin de garder continuellement un fichier propre.

Courrier électronique , , ,

Classement du courrier côté serveur avec Sieve

06/01/2009

Lorsque vous consultez votre courrier en IMAP depuis plusieurs clients différents (webmail et client sur le PC, par exemple) et que vous avez implémenté sur votre PC des règles de tri de courrier, le classement n’est pas fait lorsque vous consultez votre courrier sur le Webmail et que celui-ci n’a pas encore été classé par votre PC qui devrait resté allumé pour classer en temps réel.

La solution est de réaliser le classement directement côté serveur, afin que votre MDA (Mail Delivery Agent) réalise directement ce classement. Ainsi, peu importe l’endroit où vous vous connectez, le classement sera toujours réalisé.

Un langage, Sieve défini par la RFC 5228 permet de réaliser facilement ces traitements, sur base des en-têtes du courrier reçu. Ainsi, il est facile de vérifier la valeur d’un en-tête (l’expéditeur du mail, son destinataire, le sujet, …) ou son existence (est-ce que l’antispam a placé l’en-tête indiquant le caractère indésirable du courrier ?).

En utilisant le MDA de Dovecot, un plugin nommé cmusieve est disponible. Il suffit de l’activer dans le fichier /etc/dovecot/dovecot.conf, dans la section lda, de la manière suivante:

protocal lda {
  mail_plugins = cmusieve
}

Ensuite, après avoir redémarré dovecot, pour les utilisateurs nécessitant un filtrage, rajouter à la racine de leur boîte mail un fichier nommé .dovecot.sieve (qui doit appartenir à l’utilsateur utilisé pour le mail, généralement vmail). A chaque modification du fichier, dovecot créera une version compilée, nommé .dovecot.sievec. En cas de problème avec votre fichier (erreur de syntaxe), un fichier .dovecot.sieve.err sera créé.

Ce fichier contient les règles propres à chaque utilisateur. En voici quelques exemples :

Classement du spam dans le folder Junk:

require "fileinto";

if exists "X-Spam-Flag" {
  fileinto "Junk";
}

Marquer le courrier provenant de l’adresse mail@example.org comme lu:

require "imapflags";

if address :is ["From"] "mail@example.org" {
  setflag "\\Seen";
}

Supprimer le courrier provenant de l’adresse mail@example.org:

if address :is ["From"] "mail@example.org" {
  discard;
}

Dans le cas du classement du courrier dans un folder précis, il est indispensable de configurer votre client mail pour qu’il idle sur tous les folders (par défaut ce n’est que sur la Inbox principale).

Il est possible de définir des script globaux à tous les utilisateurs et de créer des répondeurs. Nous verrons cela dans un prochain article.

Courrier électronique , ,

Accepter les connexions SMTP sur un port supplémentaire

01/01/2009

Certains FAI bloquent le port 25 en sortie de leur réseau, ce choix étant justifié par deux raisons précises:

  • vous obliger à utiliser leur serveur SMTP;
  • luter contre les machines zombies. Une machine zombie est une machine sur laquelle a été installé à l’insu de son utilisateur un logiciel généralement inoffensif pour la machine en elle-même, mais qui s’en sert pour envoyer du spam, lancer des scans, du flood, …

Si vous souhaitez utiliser le serveur SMTP d’un serveur précis, cela est alors impossible puisqu’il vous est impossible de le contacter sur le port 25. Pour les utilisateurs nomades, qui se connectent sur différents réseaux au gré de leur déplacements, le même problème survient, puisqu’ils ne connaissent pas le serveur SMTP local; et même s’ils le connaissent, c’est un paramètre à modifier à chaque fois, ce qui devient vite handicapant pour gérer efficacement son courrier.

Une solution à ce double problème est d’ouvrir un second port sur votre serveur SMTP.

Pour postfix, puisque c’est un des objets de ce blog, cela se fait facilement (comme toute manipulation sous Postfix ;-) ) en éditant le fichier /etc/postfix/master.cf.

Il suffit de rajouter une ligne de la forme

5025      inet  n       -       -       -       -       smtpd
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

où 5025 représente le numéro du port que nous allons ouvrir. Il vous est loisible de rajouter les directives que vous souhaitez à la fin de la ligne (par exemple pour faire appel à un filtre de contenu).

Nous indiquons à Postfix de n’accepter sur ce port que les personnes s’authentifiant en SASL. En effet, si les spammeurs découvrent que votre serveur accepte les connexions sur un autre port sans filtrage, je crois que vous croulerez vite sous le spam !

Vous pouvez rajouter autant de lignes similaires que vous le souhaitez, en modifiant le numéro du port à la valeur désirée. N’en ouvrez tout de même pas des millions, ça ne sert à rien. Les ports au dessus de 1024 ne sont généralements pas filtrés par les FAI et autres réseaux d’entreprise, un seul devrait donc suffire …

Il faut évidement redémarrer Postfix après cette manipulation.

Courrier électronique , , ,

Postfix: mails en double lors de la livraison vers une boîte avec copie vers une autre

29/12/2008

Voici un problème couramment rencontré sur un serveur de courrier équipé d’un logicel antispam ou anti-virus. Une boîte mail a un transfert automatique (via un alias ou un bcc) du courrier vers une autre boîte. Le courrier se trouve en double dans la boîte en copie.

La cause de ce problème est en réalité assez simple. Un mail arrive de l’extérieur, il est injecté dans postfix. Postfix regarde alors dans la table des alias ou des BCC et voit que l’adresse destinataire intègre une deuxième destination, le mail est donc dupliqué vers la deuxième destination. Les deux mails sont ensuite passé au filtre antispam ou antivirus, puis réinjectés dans postfix, qui reprend le même processus : le destinataire intègre une deuxième destination et le mail est à nouveau dupliqué. Trois copies du mail orginal existent alors: celle vers l’adresse de base, celui vers la deuxième destination, dupliqué avant le filtre de contenu, et enfin, celui vers la deuxième destination dupliqué après le filtre de contenu. Deplus, votre filtre a été appelé deux fois, le mail ayant été dupliqué avant son appel.

Mais, rassurez-vous, il existe une solution à ce problème. Il est en effet possible de dire à postfix de ne pas traduire les alias. Pour ce faire, éditer le fichier /etc/postfix/master.cf, et à la ligne smtpd, qui contient -o content_filter=nomdufiltre (c’est généralement la première ligne), rajouter -o receive_override_options=no_address_mappings. Ne pas oublier de redémarrer postfix pour prendre en compte la nouvelle configuration.

Le comportement sera alors normal lors de la réception d’un mail: il est passé au content_filter, et seulement après sa réinjection, les alias sont interprétés.

Courrier électronique , , ,