La Quality Of Service (QOS) , qualité de service en français, intervient principalement au niveau 3 du modèle OSI.
Il faut donc placer ses scripts de QOS sur la passerelle de votre réseau, c’est la raison pour laquelle, mettre en place de la QOS sur la eeegw prend tout son sens.
N’hésitez pas à revenir sur les précédents articles sur la eeegw :
eeegw part I
eeegw part II
Filtrer les web-espions (google analytics, xiti …) n’est qu’un début. Le nombre de fichiers javascript, css et images en tout genre destinés à vous profiler est non négligeable, mais le pire est en fait le nombre de publicités pourrissant votre expérience utilisateur. Comment peut-on intégrer dans bind9, les filtres adblock que l’on a construit minutieusement ?
Les régies de publicité ne sont pas honnêtes, elles proposent de la pornographie (bon ça c’est pas grave), des jeux en ligne (ça ne touche que les cons qui croient gagner face à un logiciel), des faux antivirus (là c’est moins drôle) voire des mouchards (là je ne ris plus du tout).
Filtrer les pubs est parfois considéré comme une attitude hostile vis à vis de l’éditeur du contenu que vous vous apprêtez à consommer. Vous refusez la contrepartie d’un service gratuit, vous êtes fourbes, vous mériteriez d’aller casser des cailloux à Cayenne et qu’on fasse un lolcat avec votre chien.
StatsCounter, SiteMeter, Google Analytics & Urchin, Xiti… sont les plus populaires des outils de statistiques proposés aux webmestres. Ils sont très simples à mettre en œuvre et proposent des résultats très pertinents.
L’intérêt de ces outils est surtout le profilage à des fins techniques (versions, systèmes d’exploitations et résolutions des navigateurs…) et à des fins de positionnement sur le web (liens directs, liens indirects, durée moyenne de lecture).
La contre-partie de la gratuité de ces outils est la valorisation commerciale de vos profils. Le webmestre rémunère l’éditeur du service avec votre profil… sans votre consentement.
D’un point de vue éthique, ce procédé est peu honorable. D’un point de vue technique c’est guère mieux : augmentation sensible du nombre de requêtes, charge processeur superflue, stockage de cookies inutile, bande passante gaspillée.
Quand on parle de la dernière version de l’HTML introduite par le W3C, beaucoup le résument à l’élément <video>. Pourtant, le W3C a introduit de nombreux autres balises, attributs et API pour mieux coller au web d’aujourd’hui, ainsi que des innovations qui vont permettre de rattraper l’écart entre les applications natives et les WebApps tout en rendant le web plus accessible.
Le but de ce howto est de vous présenter ma façon de filtrer mes mails de tous mes comptes pop/imap, afin de les centraliser dans une même interface.
Afin de filtrer les mails qui arrivent nous allons utiliser “sieve” un merveilleux ajout disponible dans le packet dovecot, qui permet de filtrer les messages directement AVANT qu’ils arrivent dans la casserole IMAP.
Traditionellement, les serveurs UNIX utilisent mbox pour stocker les mails. Pour mbox, chaque dossier de votre boîte mail (Reçu, Envoyés, Archive, Corbeille, etc) est representé par un fichier, ou tout les mails sont enregistrés à la suite, séparés par une ligne vide.
Ce format, très simple à utiliser, pose de nombreux problèmes. Premièrement, on ne peut pas faire d’accès parallèles, même sur des mails différents, puisque le fichier est le même (problème de verrou). Deuxièment, les serveurs POP/IMAP (comme Dovecot) ont souvent un support limité de mbox. Dovecot est obligé de placer un mail “interne” dans la boîte, pour garder l’arborescence et l’organisation des dossiers. Courier ne supporte pas mbox.
L’avantage principal de mbox, c’est le fait qu’il soit très répandu. Il est supporté par tout les MUA (mailutils/mail, bsd-mailx, mutt, emacs, Kmail, thunderbird, evolution). Mais les problèmes récurrents qu’il pose ont poussé le principal développeur de qmail a créer un nouveau format : Maildir.
