Julien FALCONNET, Informaticien Indépendant

Migrer un serveur de production

Julien Falconnet — 2013-10-31T11:48:02Z

Ca y est ! L'heure fatidique est arrivée, votre serveur web de production doit migrer vers un nouveau serveur. Quelques nuits blanches en perspective et une bonne dose d'adrénaline dans le sang vous décidez enfin de prendre le taureau par les cornes.

Voici quelques étapes que j'ai du mettre en place.

Cadre

La migration s'effectue entre deux serveurs chez online.net. L'ancien (que l'on appellera Aragorn) part à la décharge, ils m'en ont gracieusement proposé un nouveau (que l'on appellera Elessar) plus puissant sensiblement au même prix. Par contre, c'est un serveur dédié donc à moi le cambouis de la migration.

Au niveau système d'exploitation, on en profite pour passer de Debian 6.0.7 à Debian 7.2

Aragorn : GNU/Linux 2.6.32-5-amd64
Elessar : GNU/Linux 3.2.0-4-amd64

Etape 1 : installer le nouveau serveur

installer le nouveau serveur(Elessar) ici un Debian 7.2

Pour online, l'installation se fait par l'interface l'hébergeur.
Ensuite première connexion en ssh root
Mise à jour des paquets
```
apt-get update
apt-get upgrade
```

Prendre quelques informations sur la machine (et bien les garder quelque part)

uname -a
more /etc/debian_version cat /proc/cpuinfo free
free -h
more /etc/debian_version
/sbin/ifconfig df df -h
netstat -ltp

Sécuriser ssh
- Installer un accès par clef sur un des utilisateur (Attention ne pas sauter cette étape sinon vous n'aurez plus accès à votre machine)
```
ssh-copy-id utilisateur@000.000.000.000
```
- Modifier l'accès ssh pour : changer le port par défaut, empêcher le login root et empêcher le login par mdp.
```
vi /etc/ssh/sshd_config >>Port {XXXX} (ou XXX est un port non standart)
...
>>PermitRootLogin {{no}} ...
>>PasswordAuthentication {{no}}
```
- Relancer le serveur ssh pour que les modifications soient prisent en compte
```
/etc/init.d/ssh restart
```
- modifier en local dans .ssh/config le numéro du port
- Tester une connexion par clef.
  PS : pourquoi sécuriser tout de suite ? Parce que si vous vous trompez vous êtes bon pour recommencer l'installation.
Vérifier le bon fonctionnement d'exim
- Reconfigurer pour permettre à vos site d'envoyer des mails
```
 dpkg-reconfigure exim4-config
```
- Pour tester :
```
echo "Un message de test" | mail -s "sujet de test" vous@mail.tld
```

Installer les paquets nécessaires :

LAMP : jouer sur les dépendances pour installer le nécessaire
```
apt-get install mysql-server phpmyadmin
```

NodeJS :

apt-get install mongodb build-essential git
wget http://nodejs.org/dist/v0.10.18/node-v0.10.18.tar.gz
tar xvf node-v0.10.18.tar.gz pushd node-v0.10.18/
make
make install

Sécuriser les applications serveurs

PhpMyadmin : changer au moins la ligne d'alias

vi /etc/apache2/conf.d/phpmyadmin.conf >> Alias /unnomquinarienavoiravecphpmysql /usr/share/phpmyadmin

Apache : modifier les lignes

vi /etc/apache2/conf.d/security
...
>> ServerSignature Off
...
>> ServerTokens Prod vi /etc/php5/apache2/php.ini ...
>> expose_php = Off

ps : attention il existe des guides bien plus sérieux de sécurisation d'un serveur, je n'indique ici que ce dont j'ai eu besoin.

Étape 2 : en faire le plus possible sans toucher à rien d'important

faire un maximum de sauvegardes de l'ancien (Aragorn), un Debian 6.0.7.
- tar -cvzf backup_etc.tar.gz /etc/
- tar -cvzf backup_var.tar.gz /var/ (on peut faire mieux)
- tar -cvzf backup_web.tar.gz /sites/ (pour moi le répertoire où sont stockés mes sites)
Préparer les noms de domaine
- Modifier la zone pour que ww.ndd.tld (avec 2w) redirigent sur le nouveau serveur (Elessar). Faire cela pour tous les sites qui tournent normalement sous www. Si vous avez d'autres sous domaines trouvez une variantes proche (avec un 2 à la fin par exemple).
- Pour chaque registrar impliqué (gandi, phpnet,etc)
- Si possible, préparez vos nouveaux "fichiers de zone DNS" pour ne plus avoir qu'à les activer. (ou les www dirigent sur le nouveau serveur, Elessar )

Ramener la configuration des sites
- établir un lien ssh entre les deux.
- les vhosts récupérer scp -r aragorn.dom.tld:/etc/apache2/sites-available/ /etc/apache2/sites-available/
- les fichiers des sites scp -r aragorn.dom.tld:/sites/* /sites/
- corriger les vhost htaccess pour qu'ils supportent les ww.
- comparer les /etc/apache2/mods-enabled/ pour réactiver tous les modules nécessaires (rewrite, proxy, etc)
- Remettre en place un système de sauvegarde !!!

Faire une première importation temporaire des bases de données pour pouvoir tester que les sites fonctionnent
- ssh aragorn.dom.tld 'mysqldump -q --skip_trigger -u root -p --database db1 --database db2 --database etc | mysql -u root -p
- Si vous avez importé la base mysql (important pour les user et leur droits sur les bases), les passwords risquent de ne plus fonctionner si comme moi vous passez d'une version 5.1 à une version 5.5. Vous pouvez utiliser la commande mysql_upgrade -u root -p pour résoudre ce problème.
- Recopier les crontab de tous les utilisateurs
Tester TOUS les sites sur ww. (ou les sous domaines modifiés).

Étape 3 : bascule

Il va falloir ramener les informations les plus fraîches du serveur de production vers le nouveau. Idéalement, couper l'ancien et tout rediriger sur le nouveau, pour limiter le temps ou une partie des gens seront sur l'ancien.

Donc il faut faire dans un temps le plus court possible (si ce temps es trop important, il faut mettre les sites en travaux) ;

RE migrer les bases de données
RE migrer les fichiers qui bougent (attention aux droits)
sur l'ancien serveur utiliser les htaccess pour rediriger tout le trafic du www vers le ww.
Changer les dns pour y faire disparaître l'ancien serveur.
tester, tester, tester et encore tester

Étape 4 : finaliser

La question du temps de propagation des DNS, c'est à dire le temps que les noms de domaines redirigent sur les bons serveurs est toujours une question épineuse. Il vaut mieux laisser quelques heures, idéalement 24h. Puis :

Éteindre l'ancien serveur pour vérifier si tout continue d'être ok.
remplacer le ww par www dans les htaccess locaux
Rallumer l'ancien serveur et effacer toutes les données possibles.

Installation Trac sur hébergement dédié

Julien Falconnet — 2009-11-24T13:17:33Z

Ça faisait des années que je tournais autour. On m'en avais parlé, j'en avais vu quelques uns... Mais TRAC était toujours resté la "bonne idée qu'on adopterai dès qu'on aurait le temps". D'un autre côté, l'essentiel de mes projet n'impliquaient que moi, donc je m'en sortais très bien avec mon cahier. A deux, ça passait encore. Mais à quatre, j'ai amèrement regretté de n'avoir pas un suivi de projet connecté à subversion. Je me suis finalement ressaisit et voici le résultat de mes recherches.

Choix

A titre de préambule, voici les choix que j'ai fait :
– version : tracd 0.11.1
– Subversion (SVN) comme gestionnaire de version
– trac est utilisé en serveur 'standalone' (indépendant d'un serveur apache)
– plusieurs projets sont gérés simultanément
– accès privé
– gestion des temps de développement (estimation et décompte)
– thème personnalisé
– le serveur sera lancé par un utilisateur particulier

Initialisation

Sur ma dédibox avec une installation Debian. Voici le protocole que j'ai suivi.

En tant qu'administrateur :

apt-get install trac apt-get install trac-spamfilter

Puis en tant qu'utilisateur normal (j'en créé un spécialement pour trac)

# création des environnement qui serviront à trac pour gérer chaque projet trac-admin repertoire_projet1 initenv trac-admin repertoire_projet2 initenv # génération des mots de passe et des utilisateurs htpasswd -c .htpasswd_projet1 user1 htpasswd .htpasswd_projet1 user2 ... htpasswd -c .htpasswd_projet2 user1 htpasswd .htpasswd_projet2 user3 ... # Ajout des droit admin à au moins un utilisateur trac-admin repertoire_projet1/ permission add user1 TRAC_ADMIN trac-admin repertoire_projet2/ permission add user1 TRAC_ADMIN # pour vérifier que l'identification (et l'accès admin) fonctionne tracd -p 8000 --basic-auth=repertoire_projet1,/home /TRAC/.htpasswd_projet1,TRAC_PROJ1 --basic-auth=repertoire_projet2,/home/TRAC/.htpasswd_projet2,TRAC_PROJ2 /home/TRAC/repertoire_projet1/ /home/TRAC/repertoire_projet2/ #ctl-c pour sortir

Dans un navigateur, on peut ensuite tester avec http://adressDuServeur:8000

Une fois que tout semble opérationnel on peut passer aux plugins

Plugins

J'avais besoin de trois fonctionnalités qui demandaient des plugins supplémentaire :
– La gestion des temps de développement.
– Un accès privé par défaut.
– Une interface un peu plus sympathique

J'ai donc récupéré les plugins suivants :
– TimingAndEstimation, qui permet d'estimer et de décompter le temps ticket part ticket.
– NoAnonymous, qui permet d'interdire l'accès si on est pas identifié
– GnomeBR un thème plus (trop ?) coloré.
– ThemeEngine, nécessaire pour pouvoir installer des thèmes (et nécessaire pour le précédent).

Après la procédure est assez pénible, il va falloir régénérer les plugins avec la version de python du serveur. Ce que j'ai trouvé de plus simple c'est de mettre tous les plugins récupéré dans un répertoire spécialement créé pour ça sur le serveur et d'exécuter dans ce répertoire (ATTENTION !!! pas ailleurs) le script suivant

find . -iname '*.zip' -exec unzip {} \; for setup in <code class='spip_code spip_code_inline' dir='ltr'>find . -iname 'setup.py'</code> do start=<code class='spip_code spip_code_inline' dir='ltr'>pwd</code> chmod -R 777 <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> cd <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> python setup.py bdist_egg cd $start echo <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> done find . -iname '*.egg' -exec cp {} . \;

Ensuite il ne reste plus qu'à déplacer, les .egg (attention de bien choisir ceux liés à la version de trac (pour moi 0.11) dans le répertoire plugins de mes environnement (repertoire_projet1 et repertoire_projet2)

Ensuite on peut tester chaque projet séparément et on devra sans doute mettre à jour la base de donnée :

trac-admin /home/TRAC/repertoire_projet1 upgrade trac-admin /home/TRAC/repertoire_projet2 upgrade

Petits réglages complémentaire

Dans trac.ini

les logs

log_level = DEBUG log_type = file

les mails

always_notify_owner = true always_notify_reporter = true mime_encoding = quoted-printable smtp_enabled = true base_url = http://mon.site.com:port/projet/

Mise en route

Il reste en suite à lancer pour de vrai l'application (notament pour qu'elle continue de fonctionner quand on se déloguera du ssh).

# le -d pour lancer le programme comme un daemon tracd -d -p 8520 --basic-auth=lunastars_v2,/home/TRAC/.htpasswd_luna,TRAC_LUNA --basic-auth=enov_bix,/home/TRAC/.htpasswd_enov,TRAC_ENOV /home/TRAC/lunastars_v2/ /home/TRAC/enov_bix/ &

puis quand on voudra l'arréter :
– ps aux |grep tracd
– kill le pid trouvé

Voilà, maintenant il ne reste plus qu'à explorer les fonctionnalités extraordinaire de cette application.

En espérant que cela aidera d'autres à gagner un peu de temps.

[edit : 2/12/2009] Pour pouvoir clore et ajouter du temps sur les tickets directement par les messages des commits SVN, il faut appliquer la procédure indiquée ici : http://trac-hacks.org/wiki/TimingAn...

Exim : "Message is frozen" et "unrouteable address"

Julien Falconnet — 2007-12-17T18:27:23Z

Les gestionnaires de courriers systèmes ou Mail Transfert Agent (MTA) sont sans doute ce que j'ai rencontré de plus compliqué en administration linux. Loin de dominer le sujet, je prie généralement pour que mon Exim fasse ce qu'il a à faire sans rencontrer de problème. Mais mes prières ne sont pas toujours exaucées. Récit d'une galère.

Sur ma dedibox debian favorite (un serveur dédié en somme) tourne un de mes plus jolis sites. Ce site de jeu de rôle en ligne nécessite une inscription qui est confirmée par email. Or depuis plusieurs jours, les mails ne voulaient plus partir.

La cause de cette panne n'aura jamais pu être complètement élucidée mais j'ai finalement réussi à remettre mes mails en place, et au passage j'ai appris un certain nombre de choses intéressantes.

Le problème

Tout d'abord les symptômes :

les mails ne partent plus

après quelques recherches je découvre que :

le répertoire /var/spool/exim4/input est rempli de mails en attente

le fichier /var/log/exim4/mainlog se remplit de lignes du type

2007-12-17 07:10:36 1J49BU-0004SI-IJ <= truc@mondomaine.com U=www-data P=local S=630 id=1197871836.site@mondomaine.com 2007-12-17 07:10:36 1J49BU-0004SI-IJ ** utilisateur@wanadoo.fr: Unrouteable address 2007-12-17 07:10:36 1J49BU-0004SK-OJ <= <> R=1J49BU-0004SI-IJ U=Debian-exim P=local S=1436 2007-12-17 07:10:36 1J49BU-0004SI-IJ Completed 2007-12-17 07:10:36 1J49BU-0004SK-OJ ** truc@mondomaine.com: Unrouteable address 2007-12-17 07:10:36 1J49BU-0004SK-OJ Frozen (delivery error message) 2007-12-17 07:29:15 Start queue run: pid=17137 2007-12-17 07:29:15 1J404B-0003uu-Vo Message is frozen 2007-12-17 07:29:15 1J3wWb-0003je-Q6 Message is frozen

Conclusion : les mails ne veulent pas partir, ils restent résolument sur ma machine.

La recherche

Après de nombreuses heures passées sur les forums et dans la documentation un peu difficile d'exim, je finis par comprendre quelques secrets :
– Tout d'abord, /usr/sbin/exim4 -d -bt mail permet d'en savoir un peu plus sur le niveau où cela bloque, puisque cela montre en détail toutes les tentatives pour traiter l'adressage de l'e-mail. Pour moi cela donnait quelque chose du genre :

Exim version 4.63 uid=0 gid=0 pid=3588 D=fbb95cfd Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 changed uid/gid: forcing real = effective uid=0 gid=0 pid=3588 auxiliary group list:  seeking password data for user "uucp": cache not available getpwnam() succeeded uid=10 gid=10 configuration file is /var/lib/exim4/config.autogenerated log selectors = 00000ffc 00189001 trusted user admin user seeking password data for user "mail": cache not available getpwnam() succeeded uid=8 gid=8 user name "root" extracted from gecos field "root" originator: uid=0 gid=0 login=root name=root sender address = root@domaine.com Address testing: uid=0 gid=102 euid=0 egid=102 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Testing mailtest@domaine.com >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Considering mailtest@domaine.com >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> routing mailtest@domaine.com --------> hubbed_hosts router <-------- local_part=mailtest domain=domaine.com checking domains expansion of "${if exists{/etc/exim4/hubbed_hosts}{partial-lsearch;/etc/exim4/hubbed_hosts}fail}" forced failure: assume not in this list hubbed_hosts router skipped: domains mismatch --------> real_local router <-------- local_part=mailtest domain=domaine.com real_local router skipped: prefix mismatch --------> system_aliases router <-------- local_part=mailtest domain=domaine.com checking domains domaine.com in "MAIN_LOCAL_DOMAINS"? no (end of list) domaine.com in "+local_domains"? no (end of list) system_aliases router skipped: domains mismatch --------> userforward router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) userforward router skipped: domains mismatch --------> procmail router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) procmail router skipped: domains mismatch --------> maildrop router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) maildrop router skipped: domains mismatch --------> lowuid_aliases router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) lowuid_aliases router skipped: domains mismatch --------> local_user router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) local_user router skipped: domains mismatch --------> mail4root router <-------- local_part=mailtest domain=domaine.com checking domains cached no match for +local_domains cached lookup data = NULL domaine.com in "+local_domains"? no (end of list) mail4root router skipped: domains mismatch no more routers mailtest@domaine.com is undeliverable: Unrouteable address search_tidyup called >>>>>>>>>>>>>>>> Exim pid=3588 terminating with rc=2 >>>>>>>>>>>>>>>>

Bilan : aucun des routers ne parvient à router l'adresse.

Là je dois avouer que j'ai bloqué un bon moment. En effet, n'ayant fait aucune modification sur mon serveur, il m'a fallut un moment avant de chercher dans les fichiers de configuration ce que je pouvais y changer.

Une solution

Après de nombreuses recherches dans les fichiers de configuration et sur Internet, il semblerait que mon Exim ne tente jamais d'envoyer les mails vers l'extérieur. Finalement, sous les conseils avisés de commentaires trouvés dans un fichier de conf (dans /etc/exim4/ ) je lance une reconfiguration générale d'exim :

dpkg-reconfigure exim4-config.

Là je fais bien attention à choisir une connexion directe sur Internet, et après quelques tests, j'ai le plaisir de découvrir que mes mails fonctionnent à nouveau.

Pour finir

Après tout cela, il reste encore à relancer l'expédition de tous ces messages "frozen". Ca va être essentiellement des retours à l'expéditeur mais ça videra la queue et ça sera plus carré. Pour cela la formule miracle c'est :

exim -qff (pour relancer tous les message de la queue y compris les frozens)

fldiff : un diff graphique

Julien Falconnet — 2007-11-06T01:05:50Z

La comparaison de fichier devient vite une tache incontournable pour l'administrateur, mais aussi pour le développeur. Quoique très structurés les résultats de diff en mode console sont parfois un peu pénibles à lire. Pourtant, il existe un petit outil très pratique pour comparer de manière très visuelle deux fichiers : fldiff.

Version de travail : v1.1

Présentation

Deux parties : une à gauche pour le premier fichier, une à droite pour le second fichier. Les lignes identiques sont alignée et les lignes modifiées sont coloriées en jaunes, avec éventuellement un décalage pour que les lignes identiques restent toujours en vis à vis. Entre les deux parties on trouve un ascenseur qui rappelle les zone variantes.

Apperçu de fldiff

Vue de l'interface

Extrêmement intuitif, on peut repérer instantanément la moindre variation de virgule.

Attention, il suffit d'un "espace" de différence pour que les lignes soient considérées comme différentes. Ce qui peut poser problème lorsqu'on a seulement remis en forme un code sans avoir fait de vraies modifications. Il existe une option "ignore whitespace" dans le menu Edit->Preference qui permet de régler ce problème.

Syntaxe

Outre la possibilité de choisir les fichiers à comparer grâce au menu de l'interface graphique, on peut les spécifier directement en ligne de commande.

 fldiff {fichier1} {fichier2}

Avec SVN ? Que du bonheur !

Ma principale utilisation de ce génial outil est avec le gestionnaire de version Subversion (SVN). Il permet en effet, de comparer, non pas deux fichiers mais deux versions d'un même fichier géré par svn. Pour cela il suffit de se mettre dans le répertoire de travail où se trouve le fichier et d'appeler :

 fldiff {nom_du_fichier} :{revision1}:{revision2}

fldiff {nom_du_fichier} :{revisioninitiale}

La première syntaxe compare les versions revision1 et revision2 du fichier (par exemple fldiff action.php :21:36) et la seconde version compare la version revisioninitiale et la version courante (par exemple fldiff action.php :36).

Enfin la syntaxe suivante compare la version de travail à la version de référence (utile seulement si vous avez travaillé sur un fichier depuis son dernier update).

 fldiff {fichier}

Par exemple : fldiff action.php.

Références

Le site de référence sur le sujet : http://www.easysw.com/~mike/fldiff/... (enfin il me semble)

Foutu "Brother2:net1 ;dev0" (ou Foutu "Brother2:net1 ;dev1")

Julien Falconnet — 2007-05-14T17:01:47Z

Après plusieurs heures à maudire tour à tour Brother, Debian, Ubuntu, Linux, sane et xsane, j'ai fini par trouver la solution à mon problème.

Aprés l'installation sans difficulté (enfin presque) des fonctionnalités IMPRESSION de mon imprimante multifonction Brother DCP-340CW (par wifi svp), j'ai décidé de m'attaquer aux fonctions SCANNER.

Aprés un petit tour sur le site officiel des drivers Brother pour linux, je trouve la page des scanners et je suis un petit tutoriel tout ce qu'il y a de convivial pour installer le scanner réseau.

Finalement je lance xsane, le logiciel chargé de piloter le scanner... et là message d'erreur !!! Le début d'une galère en perspective. Qu'à cela ne tienne je commence à chercher sur internet qui a rencontré une erreur similaire à la mienne :

Erreur d'ouverture du périphérique 'Brother2:net1 ;dev0'
Argument invalide

Je vais réinstaller tout depuis le début, rebooter, manquer de modifier toute ma configuration USB (avant de me dire que c'est idiot vue que c'est une imprimante réseau qui passe par le Wifi et pas par un port usb), traduire des forums en allemand par un traducteur automatique (c'est sans doute la partie où j'ai le plus ris), pour finalement etre sur le point d'abandonner... et soudain alors que je faisait autre chose, une vieille tache d'impression qui se lance enfin...

Et poum je retente xsane et ça marche.... en fait l'imprimante avait décroché du réseau. Donc il fallait juste ATTENDRE qu'elle raccroche. Et toutes les fois que je réinstallais, désinstallais, redémarrais l'ordinateur(je sais c'est pas biens sous linux, mais c'était recommandé sur un forum) ou l'imprimante, je retardais d'autant le fait que l'imprimante rapproche.

Bilan : Quand ça marche pas du premier coup, parfois faut commencer par laisser reposer, surtout quand le réseau (et encore plus un Wifi) est en cause.

Dedibox : Envoyer des mails à partir d'un site.

Julien Falconnet — 2007-03-10T00:45:15Z

Avec le durcissement généralisé de la lutte antispam, il devient de plus en plus difficile d'avoir simplement un site qui envoi des mail de récupération de mot de passe...

Après bien des soucis pour héberger la Version 1 du site Lunastars, sur un serveur mutualisé, j'ai fini par opter pour une solution dédiée chez DEDIBOX. Jusqu'à présent j'en étais plutôt content : installation facile, debian disponible, les lenteurs du dédié disparues, mes joueurs heureux.... le top quoi.

Mais après un mois, je regarde un peu les statistiques d'inscription et m'aperçois qu'aucune inscription n'a été validée depuis la migration. En le recoupant avec des mails de personnes déclarant avoir du mal à recevoir des mails du site, je me lance dans une enquete... et je découvre que j'ai une pelleté de mails refusés (pas tous par exemple les miens passent :( ). Plein de hotmail, mais aussi la poste, des domaines de particuliers etc.

Après quelques recherches sur le net, il semblerait qu'il soit en train de s'établir un système de serveur de confiance. Les serveurs qui ne seraient pas explicitement "de confiance" se verraient refusé le droit de faire transiter les mails considérés par défaut comme du spam.

Il doit bien y avoir des moyens de résoudre le problème mais lesquels. Voici le récits de mes recherches et expérimentations.

Mails insufisament renseigné

Les serveurs qui relaient les mails sont de plus en plus difficiles sur le contenus des headers des mails (la partie qui est avant le mail et qu'en général on affiche pas). En particulier la fonction PHP mail() par défaut ne rempli peut ou pas ces champs. Si les headers sont insuffisants les serveur vont carrément refuser le mail.

Diagnostic

Si des mails n'arrivent pas, et que dans vos log de message (sous Debian/Exim4 : /var/spool/exim4/msglog), vous avez des messages du type
– 501 (501 5.1.7 Bad sender address syntax, 501 Bad address syntax, 501 Invalid Address)... ou 553 (553 sorry, your envelope sender domain must exist (#5.7.1) , 501 FROM Invalid mail address, invalid domain name syntax)
– 550 5.1.0 SIZE=1576 domain missing or malformed
– 553 5.1.3 ... Hostname required

C'est probablement que les champs des headers sont mal renseignés.
Vérifiez en particulier le return-path de vos mails, la plupart des prestataires de mails en exigent un pour accepter de faire transiter les mails.

Solution au niveau code PHP
Il est possible de renseigner le 4e champs de la fonction "mail()" avec les headers (ou entêtes) importants. En particulier assurez vous que les champs ci dessous soient renseignés.

$entete = "From: Nom Expediteur \r\n"; $entete .= "Reply-To: Nom Expediteur \r\n"; $entete .= "Return-Path: expediteur@monsite.tld\r\n"; $entete .= "Message-ID: <".time().".site@monsite.tld>\r\n"; $entete .= "X-Mailer: PHP v".phpversion()."\r\n" $entete .= "X-Sender: expediteur@monsite.tld\r\n"; $entete .= "X-auth-smtp-user: expediteur@monsite.tld \r\n"; $entete .= "X-abuse-contact: abuse@monsite.tld ";

J'ai bien galéré pour en arriver là, mais rien à faire... le return-path des mails envoyés restaient déséspérément :
– Return-Path :

alors j'ai du aller plus loins ...
Solution au niveau php.ini

aprés moult recherche il semble qu'il faille modifier le php.ini (/etc/php5/apache2/php.ini) pour moi aprése une recherche de sendmail :
sendmail_path = /usr/sbin/sendmail -fenvoyeur@monsite.tld -t -i

et Oh joie Oh bonheur le return path des mails envoyé est enfin correctement modifié.

Et poum ça passe pour les @poste.fr et sans doute les autres...

Serveur en liste noire

Ca j'ai pas eu le problème, mais on sait jamais, autant garder la recherche sous le coude.

Si vous avez fait trop d'erreurs, que votre serveur a été détourné etc il est possible que votre serveur aie été mis en liste noire. Pour vérifier que le serveur n'est pas blacklisté
– http://www.mxtoolbox.com/blacklists.aspx
– http://www.spamhaus.org/sbl/index.lasso
– http://www.spews.org/
– http://dsbl.org/listing
– http://www.mail-abuse.com/cgi-bin/lookup
– http://www.senderbase.org/
– http://openrbl.org/client/
– http://www.spamcop.net/bl.shtml

SPF

Ca non plus j'ai pas encore eu besoin, mais je pense le faire bientôt (notament pour un de mes domaines qui est utilisé comme source apparente de spam). L'idée c'est de restreindre à quelques ip les serveur qui ont le droit d'envoyer un mail semblant provenir d'un domaine. Ensuite on indique cette information au niveau du DNS et les serveurs 'intelligents' peuvent 'vérifier' au niveau DNS que les mails viennent bien d'un smtp 'autorisé' avant de transmettre et dégager sinon.

Une petite définition.

Un outil pour générer le code spf : OpenSPF wizard

Spécificité de certains grands fournisseurs de mail :
– HOTMAIL (https://postmaster.live.com/snds/ nécessite un compte msn- demande une ip a enregistrer, un mail de plainte)
– AOL

Quelques références qui m'ont bien aidés :
– http://www.dedibox-news.com/viewtop...
– http://www.webmasterclub.fr/forum/t...

Dédidox bloque son port 25

Attention à partir 31 Mars 2007 mais il reste possible de l'activer manuellement par la console de gestion (Avancé- Configuration de la protection SMTP )

Cet article n'est qu'un résumé de diverses recherches sur un domaine que je maîtrise mal, il se peut que j'ai fait des erreurs de compréhension. Toutes les remarques sont les bienvenues.