[tips] Envoyer du mail depuis un post de développement

Le développement d'applications web nécessite souvent l'envoi d'emails, ne serait-ce que pour la gestion d'un espace membre par exemple. On a deux façons de voir les choses quand on est encore en phase de développement :

  • Utiliser un serveur de mail "fake" qui va délivrer une copie du mail si il avait été envoyé
  • Utiliser un vrai serveur d'envoi de mail

La première méthode est pas mal du tout, cependant il arrivera le moment où il faudra vraiment envoyer le mail, ne serait-ce que pour s'assurer qu'on n'est pas passé à côté de quelque chose (comme un problème lié aux clients mails). Ainsi, je suis assez partisant d'envoyer du vrai mail, même dans la phase de développement.

Pour se faire, deux nouvelles solutions s'offrent à nous :

  • Passer par un serveur de mail en local pour délivrer le mail
  • Passer par un relais SMTP pour délivrer le message

Dans le premier cas, vous avez 1 chance sur 100 que le message ne soit pas bloqué par les services anti-spam. Du coup, on va préférer passer un relais SMTP qui lui ne devrait pas poser de problème.

Pour se faire, on va installer un serveur de mail en local puis configurer un relais SMTP. Ça veut dire que le serveur de mail va faire office de client pour se connecter à un autre serveur de mail pour délivrer nos messages. Le principal intérêt de cette méthode est que quelque soit le programme qui enverra du mail en utilisant le serveur de mail "localhost" pourra faire transiter les messages vers le relais SMTP et les délivrer correctement.

Le seul pré-requis est d'avoir un relais SMTP sur lequel se connecter. En d'autres mots, vous devez avoir un prestataire d'envoie de mail qui n'est pas trop restrictif (donc pas Free par exemple) : OVH, Gandi, Gmail, …

Il faut déjà installer un serveur de mail sur sa machine. Je vous propose d'utiliser Postfix dont la renommée n'est pas à faire :

Afficher/masquer le code
$ su - 
# aptitude update
# aptitude install postfix

Éditions à présent le fichier de conf (/etc/postfix/main.cf) :

Afficher/masquer le code
[...]
myhostname = exemple.fr

relayhost = serveur.smtp.relais # exemple : mail.deblan.fr
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
[...]

Il est nécessaire de prévoir un fichier pour s'authentifier sur le serveur SMTP relais :

Afficher/masquer le code
# touch /etc/postfix/sasl_passwd
# echo "serveur.smtp.relais login:password" > /etc/postfix/sasl_passwd

Modifiez le login et le password, si le login contient un "@", remplacez le par "#".

Afficher/masquer le code
# postmap /etc/postfix/sasl_passwd (à faire à chaque modification du fichier)
# chown root:root /etc/postfix/sasl_passwd*
# chmod 600 /etc/postfix/sasl_passwd*
# service postfix restart

À présent, si le relais mail n'est pas bloquant et que les identifiants sont bons, vous passerez par un "vrai" serveur de mails pour délivrer les messages de votre espaces de développement (et pas que).

Si vous envoyez le mail au nom d'un domaine qui n'est pas celui du serveur de mail, il faudra prendre le temps de faire une configuration SPF pour rendre l'envoi de mail légitime depuis ce serveur relais. À titre d'exemple, j'ai deux serveurs de mails qui peuvent délivrer des messages avec comme domaine d'expédition "deblan.fr". Les ip's associées sont 5.135.190.125 et 109.190.159.83. Voici les entrées DNS que j'ai créées :

Afficher/masquer le code
$ dig -t TXT deblan.fr
[...]
deblan.fr. 10739 IN TXT	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN TXT	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

$ dig -t SPF deblan.fr
[...]
deblan.fr. 10739 IN	SPF	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN	SPF	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

Si je fais un test de query SPF, voilà résultats :

Afficher/masquer le code
$ spfquery -i 5.135.190.125 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 5.135.190.125 as permitted sender) client-ip=5.135.190.125; envelope-from=foo@deblan.fr;
'
$ spfquery -i 109.190.159.83 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 109.190.159.83 as permitted sender) client-ip=109.190.159.83; envelope-from=foo@deblan.fr;

$ spfquery -i 1.2.3.4 -s foo@deblan.fr | tail -n 1
Received-SPF: softfail (spfquery: transitioning domain of deblan.fr does not designate 1.2.3.4 as permitted sender) client-ip=1.2.3.4; envelope-from=foo@deblan.fr;

Les 2 ip's que je rend légitimes passent le test sans problème alors que le 3ème est en échec. Ce test SPF devient très important et par expérience, c'est la source de beaucoup de rejets. Si vous avez des IPV6, pensez à les déclarer, je me suis fais avoir il y a quelques jours encore :)

J'espère que ça vous sera utile :)

Utiliser la console de débug sous Firefox mobile

La vue adaptative de Firefox est très intéressante mais je ne couvre pas tous les problèmes d'affichage d'un Firefox mobile. En effet, j'ai déjà rencontré des cas où Firefox mobile ne réagissait pas du tout pareil que sur la vue adaptative.

Il est possible d'utiliser la console de débug de votre Firefox PC pour inspecter votre Firefox mobile. Ça fonctionne à l'aide d'ADB. Ainsi, la première chose à faire est d'installer le SDK Android sur votre machine. Vous le trouverez ici et vous aurez simplement à décompresser l'archive quelque part.

Une fois le SDK disponible sur votre machine, activez le débogage USB sur votre terminal Android (Paramètre > Option de développement > Débogage USB). Branchez votre terminal sur votre machine et lancez Firefox mobile. Dans les paramètres, allez dans "Outils de développement" et cochez "Débogage distant".

Pour tester si l'Android est détecté, lancez cette commande :

Afficher/masquer le code
$ /chemin/vers/sdk/platform-tools/adb devices

La sortie devrait ressembler à ça :

Afficher/masquer le code
List of devices attached   
xxxxxxxxxxxxx	device

Ouvrez la console de débug et activez le débogage distant (à gauche de l'onglet "Console").

La dernière étape de configuration consiste à forwarder le port 6000 de votre machine vers le terminal Android :

Afficher/masquer le code
$ /chemin/vers/sdk/platform-tools/adb forward tcp:6000 tcp:6000

En plus de message de confirmation d'ADB, on pourra s'assurer que ça fonctionne avec netstat :

Afficher/masquer le code
$ netstat -nl | grep 6000
tcp        0      0 127.0.0.1:6000          0.0.0.0:*               LISTEN

Ouvrez une page sur votre Firefox mobile, puis, dans votre Firefox PC, allez dans Outils > Développeur Web > Se connecter. Une demande confirmation s'affichera sur votre terminal Android. Vous pouvez à présent débugger plus facilement vos sites web sur Firefox mobile :)

[Astuce] i3wm : liste des processus les plus actifs

Quand j'utilisais conky, l'un de mes objectifs était de connaître la liste des processus les plus actifs. En effet, il n'était pas rare (et ça continue aujourd'hui) qu'un programme s'affole un peu en mangeant un peu trop de ressources. Mon passage à i3-wm m'a légitiment fait abandonner conky puisque j'ai toujours une fenêtre affichée en plein écran. Du coup, j'ai décidé d'ajouter une barre qui s'affiche uniquement quand j’appuie sur une touche.

Voici un aperçu : i3-wm : barre de processus

Le code source du script est en shell :

Afficher/masquer le code
#!/bin/sh                                          

echo "{\"version\":1}"

INFO='#E9F1FF'
NORMAL='#B3FF6C'
WARNING='#FF6836'
CRITICAL='#FF474A'

echo "[[]"

while true; do
	(
		echo -n ",["
		
		ps ux --sort -%cpu | head -n 30 | sed 's/\s\{2,\}/ /g' | cut -d" " -f3,11 | uniq | grep -v uniq | egrep -v '^0.0' | egrep '^[0-9.]* [a-z]' | while read cpu bin; do
			if [ $(echo "if (${cpu} < 3 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$INFO
			elif [ $(echo "if (${cpu} < 40.0 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$NORMAL
			elif [ $(echo "if (${cpu} < 70.0 ) 1 else 0" | bc) -eq 1 ]; then
				COLOR=$WARNING
			else
				COLOR=$CRITICAL
			fi
			echo -n "{\"full_text\": \" $bin ($cpu%) \", \"color\": \"$COLOR\"}," 
		done
		
		echo "]"
	) | sed 's/,\]/]/'
		
	sleep 5
done

Au niveau de la conf de i3, voila comment j'ai procédé :

Afficher/masquer le code
bar {
    status_command /chemin/vers/le/script
    workspace_buttons yes
    position top
    tray_output none
    mode hide
    modifier mod1

    /* d'autres confs */    
}

That's all folks!

Chiffrement des données sur le Wall

Une mise à jour majeure a été déployée sur le colorisateur de code. En effet, il est maintenant possible de chiffrer les sources que vous envoyez.

J'ai choisi d'utiliser l’algorithme AES avec une clé de 256-bit et une passphrase de 256 caractères.

La clé est placée dans l'URL via une ancre. Coté serveur, je n'enregistre que le message chiffré. Le chiffrage (comme le déchiffrage) est fait par votre navigateur uniquement.

Voici un code chiffré sans clé : https://wall.deblan.org/x1a29/texte/0/, et le lien complet pour le lire correctement : https://wall.deblan.org/x1a29/texte/0/#aes=pmCMT59...

Je rappel que le Wall est un projet libre et que vous avez la possibilité de le forker :

Afficher/masquer le code
$ git clone git://git.deblan.org/wall-deblan.git