13/03/2010

L’email : un vilain petit cafardeur !

« Page précédentePage suivante »


Dompter son Mail Transfer Agent (mta)



Je suis un utilisateur satisfait de sendmail (www.sendmail.org) depuis quelques années maintenant. Je vais donc vous parler de ce magnifique et ô combien trollifère mta.

Quel périmètre et que dit la RFC ?

Comme précisé dans la première partie, notre périmètre d’action est restreint : du (mua) jusqu’au dernier mta sous notre responsabilité.
La RFC précise que pour des raisons de traçabilité un mta ne doit pas procéder à de la destruction de « Received »/« timestamp ». Comprenez qu’en prenant la responsabilité de couper une partie de la chaîne de réponse vous devez vous engager à garder une trace dans votre système.

Ne modifiez rien si :

  • Vous n’avez pas d’outils de logs fiables
  • Vous n’êtes pas sûr de toutes les machines en amont de votre mta
  • Vous êtes backup-MX
  • Vous n’êtes pas sûr de toutes les utilisateurs en amont de votre mta
  • Vous n’êtes pas sûr de toutes les logiciels en amont de votre mta
  • Vous n’êtes pas sûr de ce que votre mta va supprimer, il serait DOMMAGE de supprimer des informations concernant les mails entrants (ceux venant du Great Ternet)

Pesez-bien cette décision, agissez en responsable. Si vous êtes sous FreeBSD vous pouvez recevoir une synthèse par mail quotidienne et la coupler à un daemon syslog sur une autre machine.

`hostname`.cf & `hostname`.mc

Nous allons jeter un oeil dans la configuration de sendmail (`hostname`.cf ) au niveau de la gestion du HEADER. Nous trouvons sans difficulté ceci :

HReceived: $?sfrom $s $.$?_($?s$|from $.$_)
$.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)
$.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version}
(version=${tls_version} cipher=${cipher} bits=${cipher_bits} verify=${verify})$.$?u for $u; $|;
$.$b$?g
(envelope-from $g)$.

Que nous pouvons réduire à :

HReceived: id $i; $b

Modifier `hostname`.cf est généralement une mauvaise idée, sendmail vous propose l’utilisation de macro m4, autant en profiter. Voici donc la correspondance dans `hostname`.mc

define(`confRECEIVED_HEADER',`id $i; $b')

Comparaisons de configurations

Commençons par faire un email vide de test :

$ cat mail.txt
helo toi
mail from:<qualite@bidule.ath.cx>
rcpt to:<x@machin.ath.cx>
data
subject:Ok
ok
.

Que nous utilisons comme ceci :

$ nc localhost 25 < mail.txt

Avec un sendmail en configuration par défaut, le correspondant reçoit :

Received: by machin.ath.cx  with ESMTP id o2BK1BKu031170; Thu, 11 Mar 2010 21:01:11 +0100
Received: from toi (localhost [127.0.0.1])
        by bidule.ath.cx (8.14.3/8.14.3) with SMTP id o2BK13FB043209
        for <x@machin.ath.cx>; Thu, 11 Mar 2010 21:01:03 +0100 (CET)
        (envelope­ from qualite@bidule.ath.cx)
Date: Thu, 11 Mar 2010 21:01:03 +0100 (CET)
From: Qualite <qualite@bidule.ath.cx>
Message­Id: <201003112001.o2BK13FB043209@bidule.ath.cx>

Avec le nouveau HReceived nous obtenons :

Return­Path: <qualite@bidule.ath.cx>
Received: by machin.ath.cx  with ESMTP id o2BJxVBK031165; Thu, 11 Mar 2010 20:59:31 +0100
Received: id o2BJxOpC042941; Thu, 11 Mar 2010 20:59:24 +0100 (CET)
Date: Thu, 11 Mar 2010 20:59:24 +0100 (CET)
From: Qualite <qualite@bidule.ath.cx>

Que retenir de cette partie ?

Vous conviendrez que notre mta est devenu moins bavard.
Nous avons ici abordé sendmail, mais il existe par exemple postfix qui, dixit bragon, “Tout ce que fait sendmail, postfix le fait en mieux”. Je pense que vous n’aurez pas de difficulté a porter cette modification dans le conf de postfix, peut-être que LeCoyote nous honorera d’un commentaire à ce sujet ;).
Autre point à noter, il n’a été question QUE de `hostname`.(mc|cf) et pas de `hostname`.submit.(mc|cf) qui n’est en aucune manière concerné par cet article.

« Page précédentePage suivante »
internet, Logiciel , , , ,