Vous avez un serveur Linux chez OVH ?

Certains de vos mails, mails système ou venant de script PHP, arrivent avec comme origine une adresse www-data@stock.ovh.net ou root@stock.ovh.net ?

Ou des mails n’arrivent pas, bloqués par le serveur SMTP du destinataire ?

Vérifiez le log d’Exim4, et vous trouvez probablement ce genre de messages (ça doit être le même genre d’erreur en Postifx ou Qmail):

# less /var/log/exim4/mainlog

2008-10-01 15:55:24 1KjhCh-0007RG-V2 == romain@adre.serveur.be R=dnslookup T=remote_smtp
defer (-44): SMTP error from remote mail server after RCPT TO:<romain@adre.serveur.be>:
host smtp.sgsi.serveur.be [130.104.5.67]: 450 4.1.8
<www-data@stock.ovh.net>: Sender address rejected: Domain not found

(utilisez « sudo less /var/log/exim4/mainlog » si vous êtes en Ubuntu)

Le message est très clair…

Le serveur de destination fait une vérification du domaine qui lui envoie le mail. C’est une protection contre les spams : le domaine d’origine doit exister ! … et effectivement, le domaine stock.ovh.net n’existe pas ! D’ailleurs, ce n’est pas VOTRE domaine…

Si l’erreur est claire, la solution n’est pas toujours facile à trouver.

Notre serveur est en Debian, mais je pense que c’est identique avec d’autres distributions.

Premièrement, les « www-data » ou « root », ce sont les noms des users qui ont envoyé ces mails :

• probablement un script PHP pour le www-data@… qui est le userid d’Apache (un formulaire de contact ?)
• une tâche système pour le root@…

Ca c’est clair. Il est préférable que vous positionnez l’adresse exacte d’expédition dans vos scripts PHP. C’est mieux… surtout si vous avez plusieurs sites Web sur la même machine, mais ce n’est pas la cause de rejet de votre mail par le serveur SMTP distant…

photo (c) OVH

Ce « @stock.ovh.net » ? D’où vient-il ?

Après avoir bien cherché… c’est le nom de domaine utilisé par défaut pour l’envoie de mail. Il est tout simplement spécifié dans « /etc/mailname » :

# vi /etc/mailname

stock.ovh.net

Remplacez ce « stock.ovh.net » par le nom de votre domaine (le domaine principal si votre machine supporte plusieurs sites Web de domaines différents).

par exemple :

mondomaine.be

Ne PAS mettre d’adresse mail complète ! Ne pas mettre de « @ » … Rien que le nom du domaine.

Lors de l’envoi d’un mail, si vous n’avez pas explicitement spécifié l’adresse d’origine, le système prendra le userid qui a envoyé ce mail, et y ajoutera automatiquement « @mondomaine.be » pour former une adresse mail qui cette fois vient d’un domaine valable.

A vous quand même de vérifier si une boîte mail existe pour « root » ou « www-data » pour ce domaine, sans quoi si la personne qui reçoit ce mail fait « répondre », la réponse ne vous parviendra jamais.

Dans mon billet précédent, j’ai expliqué le fonctionnement du Sender Policy Framework, càd de SPF.

Le principe est de publier dans une ligne du serveur DNS, la liste des serveurs mails officiellement autorisés à envoyer des mails pour votre domaine.

Comment définir cette ligne DNS ?

Je me base principalement sur les explications très claires venant du site www.openspf.org.

Un DNS peut contenir des lignes, des records, de plusieurs types. L’idéal aurait évidemment été d’avoir un type de record « SPF ». Malheureusement cela n’a pas été prévu à l’origine, et ajouter ce record DNS à la norme, et surtout attendre que la majorité des serveurs DNS aient été adapté aurait pris bien trop de temps.

La solution adoptée a été de publier un record de type texte (TXT), commençant par « v=spf1″, et contenant la liste de vos serveurs mails.

Je ne vais pas ici détailler le fonctionnement d’un Domain Name System (surtout que je ne le maitrise pas encore tout à fait moi-même). De nombreuses documentations existent à ce sujet.

SPF concerne toujours le domaine indiqué dans l’adresse source des mails (le « From »).

Que mettre dans ce record SPF ?

• la liste des serveurs mails autorisés pour ce domaine
• mais aussi, que faire si un mail provient d’un serveur qui n’est pas dans votre liste officielle ?

Comment indiquer le ou les serveurs officiellement autorisés ?

Plusieurs méthodes existent.

La page « SPF record Syntax » du site OpenSPF donne de très bons renseignement à ce sujet.

Plusieurs mécanismes peuvent être utilisés, et un qualifiant peut préfixer ces mécanismes.

Quand plusieurs mécanises sont présents dans le record SPF, l’analyse se fait de gauche à droite jusqu’au moment où un mécanisme matche. (Quel serait l’équivalent français de « match » ou « matcher » ?)

Les qualifiants

Les qualifiants sont :

• « + » : pass (accepté)
• « - » : failed (échoué, en théorie le mail sera bloqué)
• « ~ » : soft failed (accepté mais marqué comme suspect)
• « ? » : neutral (neutre, pas d’influcence sur l’acceptation ou le rejet du mail)

Les mécanismes

Le mécanisme « all » :

« all », comme son nom l’indique, matche avec tous les domaines. On retrouve généralement « all » en fin de record SPF, ou seul.

« v=spf1 -all »

ce domaine ne peut envoyer aucun mail !

Vous avez par exemple 2 noms de domaine : mon_site.com et mon_site.be. Vous redirigez d’office le trafic Web de mon_site.be vers le site général mon_site.com. Comme vous n’utilisez réellement que mon_site.com, aucun mail ne devrait jamais venir de mon_site.be. Tout mail ayant comme adresse d’origine mon_site.be est donc un spam !

Le mécanisme « ip4 :

Une des façons les plus simples d’indiquer un serveur mail est bien sur de donner son adresse IP. Par défaut, c’est l’adresse IP du serveur, mais cela peut aussi être un range IP, et donc couvrir plusieurs serveurs mails.

« v=spf1 ip4:91.121.98.67 -all »

votre serveur mail à l’adresse IP 91.121.98.67 (le /32 est par défaut). Le « -all » indique que vous n’avez jamais de mails envoyés d’un autre serveur. Tout mail provenant d’une autre machine devrait être bloqué car c’est certainement un spam

« v=spf1 ip4:91.121.98.67/24 ?all »

vos serveurs mails officiels se trouvent entre l’adresse IP 91.121.98.0 et 91.121.98.255 (range /24 de 256 adresses). Le comportement face à un mail venant de ce groupe de 256 adresses IP doit être positif. Il est malgré tout possible que des mails arrivent d’autres machines car vous avez indiqué « ?all« , càd que le comportement face à un mail venant d’une IP non listée (non officiel) est neutre.

Le mécanisme « ip6 :

Evidemment vous pouvez aussi indiquer l’adresse de votre serveur en IP V6.
Je reprend exactement l’exemple venant du site OpenSPF.org, car je n’ai pas encore commencé mes essais en IP V6 (c’est dans mes projets).

« v=spf1 ip6:1080::8:800:200C:417A/96 -all »

Autorise les mails venant de serveurs avec une adresse IP V6 entre 1080::8:800:0000:0000 et 1080::8:800:FFFF:FFFF. Le « -all » indique que les mails venant d’autres serveurs doivent être bloqués.

Le mécanisme « a » :

Au lieu de l’adresse IP, vous indiquez ici le nom de votre serveur.

« v=spf1 a -all »

sans nom spécifié, vous indiquez que votre serveur mail officiel est sur la même machine que votre domaine Web. Ainsi, les mails envoyés pour le domaine « mon_site.be » (sans le www !) sont supposés venir d’un serveur mail « mon_site.be » (donc de même IP)

« v=spf1 a:mon_site.be -all »

c’est entièrement équivalent au record précédent puisqu’on vérifie la provenant de mails ayant des adresses …@mon_site.be

« v=spf1 a:webmail.mon_site.be a:smtp.mon_site.be -all »

ce record indique que les mails sont envoyés depuis les machines « webmail.mon_site.be » et « smtp.mon_site.be ». Tous les autres sont rejetés.

« v=spf1 a:mail.site_externe.be/28 ~all »

Si l’adresse de « mail.site.externe.be » est 91.121.98.67, alors vous acceptez pour votre domaine, tous les mails venant d’une machine avec une IP entre 91.121.98.64 et 91.121.98.79 (range de 16 adresses /28). Le « ~all » indique ici que des mails peuvent aussi venir d’autres serveurs, mais qu’ils sont douteux. ils seront marqués comme suspects (vous pouvez configurer un SpamAssassin pour tenir compte de cela et donc augmenter le rejet des mails venant de serveurs non officiels)

Le mécanisme « mx » :

Dans un DNS, les MX records servent à indiquer quels sont les serveurs mails pouvant RECEVOIR des mails pour votre domaine. Il arrive que ce soit les même serveurs pour l’envoie et la réception de mails.

« v=spf1 mx -all »

vous n’acceptez que les mails envoyés par un des serveurs recevant les mails pour ce domaine. (il peut y avoir plusieurs serveurs mails en réception, indiqués par plusieurs MX records)

« v=spf1 mx mx:monami.be -all »

en plus des serveurs indiqués dans vos MX records, votre domaine « mon_site.be » envoie également des mails via les serveurs de réception mails (MX records) du domaine « monami.be »

« v=spf1 mx/24 -all »

Vous avez tous vos serveurs mails (envoie et réception) dans un groupe de 256 adresses IP (range /24). Vous autorisez les mails provenant de tous serveurs se trouvant dans le même range de 256 adresses que vos serveurs mails de réception (MX record de votre domaine). Le reste (« -all ») doit être bloqué.

Le mécanisme « ptr » :

Ce mécanisme est déconseillé pour une utilisation standard, mais pourrait être utile pour de grosses entreprises avec un grand nombre de serveurs mails. La vérification est faite pour tous les noms de machines se terminant par le « ptr »

« v=spf1 prt -all »

Si votre domaine est « mon_site.be », vous acceptez tous les mails provenant de serveurs dont le nom se termine par « …mon_site.be ».
Des firmes comme Hotmail, Yahoo, etc, utilisent ce mécanisme. Cela autorise par exemple, tous les serveurs mail1.yahoo.com, mail2.yahoo.com, newmail54.yahoo.com … etc… sans devoir les indiquer tous dans le record SPF (ce ne serait pas possible et il y a un maximum d’éléments que l’on peut indiquer)

Le mécanisme « exist » :

Ce mécanisme vérifie simplement si le domaine indiqué existe (càd qu’on trouve son adresse IP, sans autre vérification)

« v=spf1 existe:autre_domaine.be -all »

Si la recherche DNS sur « autre_domaine.be » ne donne rien, alors le résultat est « failed » et le mail est rejeté. Ca ne semble pas trop utile de cette façon, mais des applications existent en utilisant des macros. Pour plus d’info, voir la page de documentation de OpenSPF.

Le mécanisme « include » :

Vous indiquez utiliser les serveurs d’un autre domaine pour l’envoie de vos mails. Attention, il faut que cet autre domaine ait aussi un record SPF.

« v=spf1 include:autre_domaine.be -all »

• Si cet « autre_domaine.be » n’a pas de records SPF, le résultat est une erreur permanente. Certains serveurs mails vont rejeter vos mails en cas de « PermError »
• Si cet « autre_domaine.be » a un record SPF, par exemple « v=spf1 a -all », ce record est analysé, SAUF le -all à la fin. Le mail sera donc accepté s’il vient du serveur « autre_domaine.be » (le  » a  » dans le record SPF de « autre_domaine.be »). S’il vient d’un autre serveur, ça dépend de la fin du record SPF de « mon_domaine.be ». Dans ce cas ci, c’est aussi « -all » et donc le mail sera rejeté.

Ce n’est pas toujours aussi simple. Il faut être très prudent en utilisant le mécanisme « include: ». Là aussi je vous conseille de lire la documentation sur le site OpenSPF.org. Pour un usage courant, ce mécanisme n’est pas très utile.

Les « modifiers »

Le modifier « redirect » :

Ce modifier permet de remplacer le SPF record de votre domaine par un autre.

« v=spf1 redirect:autre_domaine.be »

Si cet « autre_domaine.be » n’a pas de record SPF, le résultat est « unkown » (inconnu)

Si cet « autre_domaine.be » a un record SPF, ce sont les définitions de ce record SPF qui sont utilisées pour vérifier si le mail provient d’une machine valide.

Le modifier « exp » :

exp=<domaine>

Ce modifier « exp » permet d’indiquer un texte que l’expéditeur du mail verra. Vous pouvez ainsi diriger l’expéditeur vers un domaine (un site Web) où vous pouvez indiquer les raisons du blocage de son mail et la façon de résoudre ce blocage.

Il reste maintenant à faire quelques exemples.

Ce sera encore le but de mon prochain billet

Les spams, vous connaissez… et ça commence à bien faire ! A défaut de savoir les éliminer, différentes techniques peuvent vous aider à les filtrer, mais aussi aider vos correspondants pour qu’ils puissent facilement reconnaître un mail envoyé réellement par vous d’un vulgaire spam à jeter.

Une des techniques qui devient assez répandue est le Sender Policy Framework.

Logo sous licence CC-by-SA 2.5

Avant d’expliquer comment l’appliquer, une explication est nécessaire pour bien comprendre ce mécanisme.

Les spammeurs utilisent plusieurs techniques pour vous inciter à ouvrir leurs mails ventant/vendant plein de choses, des magnifiques pilulles bleus aux montres Rolex garanties d’origine en passant par les prêts bancaires et les médicaments de toutes sortes. En dehors du titre du mail, le nom et l’adresse d’expédition jouent un rôle important, les spammeurs essayent de vous mettre en confiance, ou de susciter votre curiosité, en envoyant des spams qui semblent provenir de personnes que vous connaissez, de personnes célèbres, de firmes connues, ou même de vous-même ou d’adresses mails de votre propre domaine.

Vous, vous n’allez probablement pas vous laisser prendre à ce piège élémentaire… mais vos correspondants, les personnes de votre famille, vos amis… qui ne sont pas tous passionnés d’informatique ?

Expliquons cela autrement : une personne qui vous connaît, reçoit un mail semblant venir de vous. Évidemment, ce n’est pas vous qui l’avez envoyé… Comment faire en sorte que votre correspondant ne reçoive pas ce mail piège ?

Pouvez-vous empêcher l’envoie de ce spam à votre nom ? Non malheureusement… Si un spammeur décide d’utiliser votre adresse mail pour envoyer ses spams du fin fond de la Chine, Russie, ou même de la France ou des USA… ce n’est pas vous qui arriverez à l’empêcher !

Alors, il faut un mécanisme à la réception des mails : Comment votre correspondant, disons comment le serveur mails de votre correspondant, pourrait-il déterminer que ce mail est un faux, et ne vient pas de vous ?

L’adresse mail d’origine n’est pas une méthode fiable pour détecter un spam. Rien n’empèche un spammeur d’envoyer un mail avec VOTRE adresse mail comme adresse d’expédition ! Ca vous semble étonnant ? Mais… qui peut empécher quelqu’un de poster une lettre à la poste, avec votre propre nom comme expéditeur ? … Rien !

Si le nom de l’expéditeur, l’adresse mail de l’expéditeur, n’est pas un moyen fiable, une autre possibilité existe : l’adresse IP du serveur d’expédition !

S’il est facile d’utiliser un nom et une adresse mail falsifiées, l’adresse IP n’est pas falsifiable (dans CE cas ci).

Les spammeurs utilisent rarement leur propre serveur ! Trop cher… puis… ils restent discret. La plupart du temps, ce sont des armées de PC piratés qui servent pour l’envoie de ces millions de spams.

Quelque soit la machine utilisée, serveur, Pc Windows piraté, l’envoie du mail se fait en établissant une session TCP/IP entre cette machine source et le serveur mail de destination !

A ce moment, le serveur mails vers le quel est envoyé le spam, CONNAÎT l’adresse IP de la machine d’origine ! (ou du serveur mail SMTP qui a servi de relais). Il y a un dialogue entre la machine envoyant le mail (le spam) et le serveur mail de destination qui connaiît donc l’adresse IP de l’expéditeur.

Il « suffit » que le serveur qui reçoit ce mail, sache qu’il n’est pas normal que des mails à votre adresse vienne de cette machine.

Comment faire cela ? Comment certifier que vous pouvez envoyer des mails à votre adresse, et pas une autre machine ?

En ajoutant un élément dans le mail lors de l’envoie ? Non… vous ne pouvez pas faire confiance dans le contenu du mail. Les spammeurs connaissent ces méthodes, et s’il suffisait d’ajouter une ligne « server approved for mon_domaine.com » pour pouvoir envoyer des mails @mon_domaine.com, les spammeurs ajouteraient ce genre d’élement.

Le contrôle ne peut se faire qu’à la réception : il suffit d’indiquer quelque part le, ou les serveurs mails qui ont le droit d’envoyer des mails à votre adresse.
Cette liste de vos serveurs mails officiels, doit être accessible depuis Internet pour que tous les serveurs mails puissent vérifier si une machine qui envoie un mail à votre adresse est autorisée ou pas, et cette liste doit être FIABLE, càd à un endroit que VOUS contrôlez !

Cette technique, c’est le Sender Policy Framework (SPF), et cela aide grandement à vérifier si le mail qui arrive est légal ou pas.

Dans quel endroit, accessible sur Internet, pourrait-on mettre cette liste de serveur officiel ?

Mais dans le DNS !

Vous gérez votre domaine (ou quelqu’un le gère pour vous, mais vous lui faites confiance) et donc vous gérez son serveur DNS ou vous avez accès aux définitions DNS chez votre registrar.

SPF se base sur cela : une ligne « SPF » est ajoutée dans votre DNS pour votre domaine, et cette ligne SPF contient la liste des serveurs mails qui peuvent envoyer des mails pour votre domaine.

Vous y indiquez par exemple, le serveur mail de votre domaine, celui de votre fournisseur Internet à la maison, peut-être celui de votre travail, la machine qui sert de Webmail, etc.

Quand un serveur mail recevra un mail venant ou semblant venir de votre domaine, il va aller vérifier dans le DNS de votre domaine :

• si l’adresse IP de la machine qui envoie ce mail est dans la liste, alors ce mail est probablement officiel (probablement… si aucune machine de votre domaine n’a de virus ni spyware, etc)
• si l’ adresse IP du serveur d’expédition est inconnue, alors ce mail est probablement au faux, un spam (probablement… car vous pourriez être en déplacement, chez un ami, etc)

Le reste est une affaire de configuration, de décision si vous allez faire une liste STRICTE de serveurs et qu’aucun autre serveur ne pourra jamais envoyer de mails pour votre domaine, ou si cette liste indique les machines officielles mais sans rejeter la possibilité que des mails ne viennent d’autre part…

En très résumé donc :

SPF ne permet aucunement de vérifier que c’est bien la personne indiquée qui a écrit le mail. Même si on était sûr que le mail vient du PC de la personne indiquée, on ne pourrait pas encore certifier que cette personne est bien à l’origine du mail reçu (son PC peut avoir un virus, etc).

Mais SPF permet de vérifier si la machine utilisée pour envoyer un mail avec l’adresse arthur@mon_domaine.com vient bien d’un serveur officiel et reconnu par le domaine mon_domaine.com

C’est un premier filtre, très souvent efficace puisqu’il peut déjà permettre de bloquer une grande quantité de mails venant de pays lointains ou d’un autre provider.

Si on fait une comparaison avec la vie courante, on pourrait comparer SPF au cachet de la poste sur une enveloppe.

Vous recevez une lettre de votre ami Jean Dupont, habitant Liège et travaillant à Bruxelles :

• le cachet indique que la lettre a été postée à Liège ou Bruxelles : c’est logique et normal. Ca ne certifie pas que la lettre soit originale, mais c’est probable.
• la lettre reçue a été postée depuis Sydney, Paris Texas, Lagos au Niger ou depuis Dingxi au centre de la Chine… C’est pour le moins étonnant ! Et déjà c’est une indication que cette lettre est probablement un faux.

La suite dans mon prochain billet sur la définition et la syntaxe des records SPF

Exim4 pose en général peu de problèmes quand il est bien configuré. Malgré tout, parfois on a besoin de vérifier les mails en attentes, d’en supprimer, etc… et évidemment à ce moment là, on ne se rappelle plus les astuces et commandes nécessaire !

Exim Logo (c) Jennifer Greenley

Un petit rappel s’impose.

Une partie de mes explications proviennent de cette page.

Le log d’Exim se trouve dans le fichier /var/log/exim4/mainlog et les mails en attente d’envoi par Exim se trouve dans /var/spool/exim4/input .

J’ai pour le moment beaucoup de mails en attente sur mon serveur Debian à la maison.

Ce n’est pas réellement un serveur de mails, mais y tournent Apache avec quelques sites dont certains en Drupal, et des outils de monitoring comme Munin et de backup comme BackupPC. De ce fait il a besoin de pouvoir envoyer des mails et pour cela, vu que ce serveur est derrière une ligne ADSL avec IP Dynamique, il passe par le serveur SMTP de mon fournisseur EDPnet.

Un exemple de log :

$ less /var/log/exim4/mainlog

2008-08-03 06:56:34 Start queue run: pid=14058
2008-08-03 06:56:35 1KPKK7-0000DJ-Du Message is frozen
2008-08-03 06:56:35 1KP6yb-0004iT-Tq Message is frozen
2008-08-03 06:56:35 1KP4FE-00011v-Qu Message is frozen
2008-08-03 06:56:35 1KPK0j-00089V-JP Message is frozen
...

On peut aussi lister les messages « frozen », càd bloqués en attente, par la commande exim -bp.

:/var/spool/exim4/input# exim -bp

13h  1.8K 1KPcos-00082M-Te <> *** frozen ***
          webmaster@misson.net

13h  1.8K 1KPcvq-00089C-3L <> *** frozen ***
          webmaster@misson.net

13h  1.8K 1KPcyU-0008Gd-MC <> *** frozen ***
          webmaster@misson.net

...

La commande exiqgrep donne le même résultat, et exiqgrep -zi donne uniquement la liste des identifiants des messages.

Si vous voulez voir le contenu d’un de ces messages, une des solutions est d’aller directement dans le dossier /var/spool/exim4/input.

cd /var/spool/exim4/input

:/var/spool/exim4/input# ls -l 1KPcyU-0008Gd-MC*
-rw-r—– 1 Debian-exim Debian-exim 1484 2008-08-03 14:46 1KPcyU-0008Gd-MC-D
-rw-r—– 1 Debian-exim Debian-exim  725 2008-08-03 14:46 1KPcyU-0008Gd-MC-H

Chaque message est divisé en 2 fichiers, le header du mail (le -H) et le contenu (Data, le -D).

Affichez les de façon classique :

:/var/spool/exim4/input# less 1KPcyU-0008Gd-MC-H

1KPcyU-0008Gd-MC-H
Debian-exim 106 114
<>
1217767574 0
-ident Debian-exim
-received_protocol local
-body_linecount 32
-max_received_linelength 108
-allow_unqualified_recipient
-allow_unqualified_sender
-frozen 1217767575
-localerror
XX
1
webmaster@misson.net

142P Received: from Debian-exim by abrasd03 with local (Exim 4.69)
        id 1KPcyU-0008Gd-MC
        for webmaster@misson.net; Sun, 03 Aug 2008 14:46:14 +0200
037  X-Failed-Recipients: root@misson.net
029  Auto-Submitted: auto-replied
054F From: Mail Delivery System <Mailer-Daemon@misson.net>
025T To: webmaster@misson.net
059  Subject: Mail delivery failed: returning message to sender
041I Message-Id: <E1KPcyU-0008Gd-MC@abrasd03>
038  Date: Sun, 03 Aug 2008 14:46:14 +0200
1KPcyU-0008Gd-MC-H (END)

:/var/spool/exim4/input# less 1KPcyU-0008Gd-MC-D

1KPcyU-0008Gd-MC-D
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  root@misson.net
    SMTP error from remote mail server after end of data:
    host relay.edpnet.be [212.71.0.14]: 550 5.7.1 Blocked by SpamAssassin

------ This is a copy of the message, including all the headers. ------

Return-path: <webmaster@misson.net>
Received: from munin by abrasd03 with local (Exim 4.69)
        (envelope-from <webmaster@misson.net>)
        id 1KPcyU-0008GY-4u
        for root@misson.net; Sun, 03 Aug 2008 14:46:14 +0200
From: webmaster@misson.net (Cron Daemon)
To: root@misson.net
Subject: Cron <munin@abrasd03> if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
Content-Type: text/plain; charset=ANSI_X3.4-1968
X-Cron-Env: <MAILTO=root>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/lib/munin>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=munin>
Message-Id: <E1KPcyU-0008GY-4u@abrasd03>
Date: Sun, 03 Aug 2008 14:46:14 +0200

cp: ne peut créer le fichier régulier `/var/www/munin/': Aucun fichier ou dossier de ce type
cp: ne peut créer le fichier régulier `/var/www/munin/': Aucun fichier ou dossier de ce type
cp: ne peut créer le fichier régulier `/var/www/munin/': Aucun fichier ou dossier de ce type
Cannot open /var/www/munin/kimsufi.com/ks36586.kimsufi.com-cpu.html at /usr/share/munin/munin-html line 488.
1KPcyU-0008Gd-MC-D (END)

Pour ce message, il est rejeté par le SpamAssassin du serveur SMTP de mon provider Internet EDPnet… Ils n’ont pas l’air d’aimer certains types de mails techniques, mais ce n’est pas le sujet de ce billet

Si vous voulez supprimer ce message de la queue d’Exim4 :

:/var/spool/exim4/input# exim -Mrm 1KPcyU-0008Gd-MC
Message 1KPcyU-0008Gd-MC has been removed

Pour pouvoir supprimer un message, vous devez soit être l’expéditeur de ce message, soit être administrateur (root).

La commande exiqgrep peut être utilisée pour nettoyer les mails en queue :
Pour avoir la liste des mails en queue :

# exiqgrep -zi
1KP6tl-0004b9-C7
1KP6yb-0004iT-Tq
1KP73R-0004ow-IU
...

Pour la liste des mails en queue depuis plus de (-o older) 24h (86400 secondes) :

# exiqgrep -zi -o 86400

et finalement, pour supprimer les mails en queue depuis plus de 24h :

# exiqgrep -zi -o 86400 | xargs exim -Mrm
Message 1KP6tl-0004b9-C7 has been removed
Message 1KP6yb-0004iT-Tq has been removed
Message 1KP73R-0004ow-IU has been removed
Message 1KP78I-0004vH-7Y has been removed
...

Ca peut aider quand vous avez compris le problème et que les 350 mails d’erreur qui n’ont pas été envoyé vous sont maintenant inutile !

Par curiosité, le log donne ensuite ce genre de message :

2008-08-04 04:34:38 1KP9A6-0001F8-Ca removed by root
2008-08-04 04:34:38 1KP9A6-0001F8-Ca Completed
2008-08-04 04:34:38 1KP9Ex-0001Lo-61 removed by root
2008-08-04 04:34:38 1KP9Ex-0001Lo-61 Completed
2008-08-04 04:34:38 1KP9Jm-0001Te-Kx removed by root
2008-08-04 04:34:38 1KP9Jm-0001Te-Kx Completed
...

Si vous voulez releaser manuellement un message qui est en bloqué (frozen), la commande est :

exim -v -M 1KQJ9J-0001gW-FA

Mise à jour du 27 septembre 2008 :

La commande précédente est intéressante pour releaser UN mail bloqué.

Mais que faire pour releaser la totalité des mails bloqués ?

Dans /var/spool/exim4/input, vous avez tous les mails bloqués. Mais ce n’est pas pratique, car il y a (en général) 2 fichiers par mails, les -D et -H.

Plus intéressant est le dossier /var/spool/exim4/msglog !

Une commande simple, càd la même commande que tantôt mais étendue à la totalité des mails en attente, permet de libérer et relancer la totalité des mails qui se trouvent dans ce dossier :

cd /var/spool/exim4/msglog/

exim -v -M *

Et voilà ! Tous les mails sont releasés !

On trouve ce genre de messages dans le /var/log/exim4/mainlog :

2008-09-27 16:42:57 1Kispy-0000Ob-9y Unfrozen by forced delivery
2008-09-27 16:42:57 1Kispy-0000Ob-9y => dominique <nobody@mon-domaine.net> R=local_user T=maildir_home
2008-09-27 16:42:57 1Kispy-0000Ob-9y Completed
2008-09-27 16:42:57 1Kitm2-0003Te-78 Unfrozen by forced delivery
2008-09-27 16:42:57 1Kitm2-0003Te-78 => dominique <nobody@mon-domaine.net> R=local_user T=maildir_home
2008-09-27 16:42:57 1Kitm2-0003Te-78 Completed
2008-09-27 16:42:57 1Kiui9-0006WA-Ce Unfrozen by forced delivery
2008-09-27 16:42:57 1Kiui9-0006WA-Ce => dominique <nobody@mon-domaine.net> R=local_user T=maildir_home
2008-09-27 16:42:57 1Kiui9-0006WA-Ce Completed

Après avoir créé un certificat signé par l’autorité CAcert, je dois configurer mon serveur Dovecot pour utiliser ces clés et mon client mail Thunderbird pour accepter CAcert comme autorité de certification.

Dans mon cas, j’ai généré un certificat SSL CAcert multi-sites pour l’utiliser dans mon serveur mails. Mes mails sont en IMAPs et j’utilise DOVECOT.

J’ai donné des noms plus cohérents pour mes certificats :

• Misson_imap_server.pem  pour le certificat serveur qui vient de CAcert
• Misson_imap_privatekey.pem  pour la clé privée qui doit rester secrète

Je les transferts donc vers mon serveur distant :

scp Misson_imap_server.pem didier@monserveurmail:/home/didier

scp Misson_imap_privatekey.pem didier@monserveurmail:/home/didier

Adaptez évidemment les noms des clés, et le nom ou IP adresse du serveur.

Sur le serveur, au quel j’accède en SSH, je place les 2 clés dans les bons dossiers en étant en root, ou avec « sudo » suivant votre serveur :

mv /home/didier/Misson_imap_server.pem /etc/ssl/certs/

mv /home/didier/Misson_imap_privatekey.pem /etc/ssl/private/

Changez les permissons et le owner sur les 2 clés. J’autorise Dovecot à y accéder.

cd /etc/ssl/certs/

chmod u-w Misson_imap_server.pem

chown root:dovecot Misson_imap_server.pem

cd /etc/ssl/private/

chmod u-w Misson_imap_privatekey.pem

chown root:dovecot Misson_imap_privatekey.pem

Il faut maintenant indiquer à Dovecot qu’il doit utiliser ces certificats CAcert :

vi /etc/dovecot/dovecot.conf

Dans mon cas, seul IMAPS est autorisé depuis le Net, IMAP en local pour la communication entre Dovecot et SquirrelMail. J’ai bloqué le POP3.

base_dir = /var/run/dovecot/
protocols = imap imaps
protocol imap {
listen = 127.0.0.1:143
ssl_listen = *:993
}

# protocol pop3 {
# # listen = *:110
# # ssl_listen = *:995
# # }


###  mettre "no" pour le ssl_disable
###  ssl_cert est le certificat serveur de CAcert
###  ssl_key est le certificat privé

ssl_disable = no
ssl_cert_file = /etc/ssl/certs/Misson_imap_server.pem
ssl_key_file = /etc/ssl/private/Misson_imap_privatekey.pem

Il reste à configurer votre client mails.

Attention, il faut d’abord qu’il reconnaisse l’autorité CAcert, sinon il vous donnera un message d’alerte !

La documentation suivante du site CAcert explique comment ajouter les 2 certificats de classe 1 et 3 à Thunderbird, pour qu’il reconnaisse comme valide l’autorité CAcet.

Allez sur la page des certificats racines de CAcert : http://www.cacert.org/index.php?id=3

Sauvez les deux « Root Certificate » de classe 1 et de classe 3 au format PEM sur votre disque dur. Attention, vous devez le faire en cliquant avec la touche de droite de votre souris, et ensuite « enregistrer sous », sinon c’est Firefox (ou autre) qui essayera de les inclure et pas Thunderbird.

Démarrez Thunderbird et allez dans le menu « Edition » / « Préférences ». Dans le menu « Avancé » cliquez sur l’onglet « Certificats ».

Là, cliquer sur « Voir les certificats », puis sur l’onglet « Autorités » :

Importez maintenant les 2 certificats que vous aviez sauvé :

Sélectionnez les 3 cases et cliquez OK.

Faites de même pour le certificat racine de classe 3 :

Vous devriez maintenant avoir CAcert dans la liste des autorités de certification que reconnaît Thunderbird.

La prochaine fois que vous démarrerez  Thunderbird, il ne devrait plus vous donner de messages d’alerte disant que votre certificat est auto-signé ou qu’il ne connait pas CAcert comme autorité.

De mon côté, cela fonctionne parfaitement maintenant.