Config avancée
[ Accueil ] [ Les bases ] [ les Profondeurs ] [ Un SMTP "perso" ] [ Installation de Postfix ] [ Config avancée ] [ Conclusions ]
Vous l'aurez compris, cette possibilité de monter soi-même un SMTP, si elle rend des services évidents, présente malheureusement aussi quelques inconvénients.
Quoi de plus simple, en effet, que d'utiliser cette méthode pour envoyer du spam, sans passer par les éventuels contrôles de votre FAI ?
Bien entendu, l'humanité n'étant pas encore parfaite, ça n'a pas manqué de se produire, amenant les administrateurs de SMTP à prendre plus de précautions et à verrouiller de plus en plus leurs systèmes.
Quelques restrictions imposées
les administrateurs imposent donc de plus en plus de restrictions sur l'origine des messages qu'ils reçoivent. En voici quelques unes.
Le domaine de l'expéditeur
Celle là, nous l'avons déjà vue et nous avons vu comment la passer. Il suffit de s'arranger pour que l'adresse présente dans le champ de l'émetteur fasse référence à un domaine connu. Cette protection n'est hélas pas suffisante, puisque n'importe quelle fausse adresse, forgée sur un nom de domaine officiel, passera le contrôle. Ainsi, si vous envoyez des messages avec comme adresse d'émetteur : iamaspamer@aol.com , il y a des chances que ça passe.
EHLO
ESMTP propose la commande EHLO (ou HELO). Celui qui envoie le message en hélant un SMTP envoie cette commande avec comme argument son nom d'hôte.
Cette commande est une sorte de carte de visite. Dans un passé proche, cette présentation n'était pas forcément obligatoire. Elle le devient de plus en plus, et il est possible de paramétrer un serveur SMTP :
- de manière à ce qu'il se contente de connaître le nom de l'émetteur, ce qui ne présente bien entendu pas un grand intérêt,
- de manière à faire une vérification DNS pour voir si ce nom est connu sur Internet, c'est déjà plus efficace, mais n'importe quel nom valable devrait faire l'affaire, il ne semble pas y avoir de vérification sur l'IP, du moins dans le cas de Postfix,
- de manière à vérifier que ce nom d'hôte correspond à un MX (Mail Exchanger) connu comme tel sur les DNS.
Comme il n'est bien entendu pas question ici de savoir si la chose est falsifiable ou non, nous dirons que cette barrière sera incontournable, sauf si nous disposons d'un nom de domaine et que nous avons fait référencer notre machine comme étant MX sur les DNS qui gèrent notre domaine. Mais ça voudra aussi dire que l'on devrait pouvoir recevoir des messages @notredomaine.tld. Il est possible de jouer sur les priorités, mais là n'est pas notre propos.
Blacklists
Comme tout ça ne suffit visiblement pas, les SMTP peuvent se référer à des listes noires. Ces listes contiennent des IPs qui ont été repérées comme étant émettrices de spams, ou plus largement, qui font partie de blocs d'IPs dans lesquels des spammeurs ont été détectés.
Vous voyez le problème, si vous avez droit à une IP dynamique, votre SMTP pourra tomber sur une IP blacklistée, parce qu'un spammeur aura utilisé cette IP avant vous.
Ca vous fera peut-être rire de savoir qu'à l'heure où je rédige ce paragraphe, les adresses IP utilisées par les clients Wanadoo Câble de Marseille (et peut-être aussi d'autres villes) sont toutes blacklistées ?
Et, bien entendu, ces protections sont cumulables.
Ainsi, toujours à l'heure où je rédige ces lignes, les destinataires @.univ-paris8.fr sont injoignables directement depuis un SMTP personnel.
Contourner les interdits de certains FAI
Du plus radical au plus compliqué, vous pourrez :
Tout faire passer par le MTA de votre FAI
La solution la plus simple consiste alors à tout envoyer sur le MTA de votre FAI. Lui, il est obligé de les accepter, c'est dans le contrat. C'est lui qui se chargera alors de transmettre aux destinataires.
Si vous désirez faire ceci, il suffit d'ouvrir main.cf, de rechercher le paramètre
relayhost
et de lui attribuer le nom du smtp de votre FAI. Par exemple :
relayhost = smtp.wanadoo.fr
Cette méthode est simple et définitive, mais introduit au moins une étape de plus et une source de panne supplémentaire. Son unique avantage est que les clients du réseau local dialoguent avec un MTA proche et rapide. En cas de lenteur du smtp de votre FAI, les clients ne seront pas perturbés, c'est votre MTA qui gèrera au mieux les faiblesses du MTA du FAI.
Le problème, c'est que tous vos messages sortants sont pénalisés par cette solution.
Faire un tri sélectif, donc écologique
Il est possible de travailler plus "finement" en délivrant directement les messages aux destinataires qui les acceptent et en passant par le smtp du FAI pour les autres.
Nous allons le faire, par exemple pour les domaines aol.com et aol.fr
- Créer un fichier texte /etc/postfix/transport_maps
- écrire dedans les lignes suivantes :
aol.com smtp:smtp.wanadoo.fr .aol.com smtp:smtp.wanadoo.fr aol.fr smtp:smtp.wanadoo.fr .aol.fr smtp:smtp.wanadoo.frCeci veut dire en français que pour les messages à destination de domaines aol.com, aol.fr et leurs sous domaines, nous utiliserons le protocole smtp pour transmettre ces messages à smtp.wanadoo.fr (bien entendu, c'est pour les abonnés Wanadoo. les autres doivent interpréter).
- Créer la base de données correspondante avec la commande :
postmap /etc/postfix/transport_maps
- Modifier le fichier main.cf en y ajoutant la ligne suivante :
transport_maps = hash:/etc/postfix/transport_maps
- Relancer postfix avec postfix reload
De cette manière, seuls les domaines qui posent problèmes seront acheminés via le MTA de votre FAI, tous les autres étant joints directement. C'est plus efficace, mais vous aurez probablement à modifier votre configuration suivant l'humeur des divers FAI.
Donner à votre machine un nom chrétien
Ce qui est bien sûr une façon de parler...
Vous serez probablement intéressé de savoir qu'à l'IP que votre FAI vous prête, est attaché un nom, souvent fort poétique d'ailleurs. Par exemple, actuellement je dispose de l'IP 80.8.163.152.
Si je fais une recherche DNS inverse, je trouve :
gw1:~# host 80.8.163.152
152.163.8.80.in-addr.arpa domain name pointer ca-marseille-36-152.w80-8.abo.wanadoo.fr.
Joli non ?
Bien entendu, ce nom changera chaque fois que vous changerez d'IP...
Une possibilité serait alors de réaliser un script qui permettrait de changer le nom d'hôte de votre machine, chaque fois que l'IP change. C'est réalisable assez simplement, par exemple comme ceci :
Avec Mandrake, si vous utilisez PPPoE, allez dans le répertoire :
/etc/ppp/
et créez-y un script intitulé :
ip-up.local
de la forme suivante :
#!/bin/bash
# Ce script met à jour le nom d'hôte local à chaque changement d'IP
# et envoie un e-mail à une adresse extérieure, contenant :
# -- La nouvelle IP de la machine
# -- Son nouveau nom DNS
adresse="christian.caleca@free.fr"
sujet="gw1 : Nouvelle session PPPoE"
# la ligne suivante effectue la recherche inverse sur l'IP
# contenue dans le paramètre $4, et extrait le nom dans $monhote
monhote="`host $4 | awk '{print substr($NF,1,length($NF)-1)}'`"
# puis utilise la commande "hostname" pour mettre à jour le nom de la machine
/bin/hostname $monhote
/usr/sbin/postfix reload
# Le reste sert à envoyer l' e-mail
texte="$4 -- $monhote"
echo $texte | mail -s "$sujet" $adresse
Attention, en faisant ça, vous perturbez votre environnement, dont celui de Postfix !
En effet, Postfix, comme beaucoup d'autres applications, utilise une fonction appelée "gethostname" pour connaître le nom d'hôte.
Dans le cas de Postfix, les valeurs de "myhostname" et aussi de "mydomain" seront affectées. C'est d'ailleurs bien le but de la manoeuvre, mais pensez alors à configurer "mydestination" autrement, si vous utilisez un service de messagerie locale.
Soyez donc prudent si vous voulez essayer cette méthode, et vérifiez bien qu'elle n'introduit pas de perturbations sur d'autres éventuels services.
Au final, vous pourriez avoir un fichier /etc/postfix/main.cf de la forme (débarassé de tous les commentaires, pour faire court):
command_directory = /usr/sbin daemon_directory = /usr/lib/postfix alias_maps = hash:/etc/postfix/aliases mail_spool_directory = /var/spool/mail mailbox_command = /usr/bin/procmail -Y -a $DOMAIN smtpd_banner = ESMTP $mail_name debug_peer_level = 2 debugger_command = PATH=/usr/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 4 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-1.1.11/samples readme_directory = /usr/share/doc/postfix-1.1.11/README_FILES alias_database = hash:/etc/postfix/aliases transport_maps = hash:/etc/postfix/transport_maps mydestination = gw1.maison.mrs, localhost.maison.mrs, maison.mrs myorigin = gw1.maison.mrs sender_canonical_maps = hash:/etc/postfix/sender-canonical header_checks = regexp:/etc/postfix/header_checks