OpenSMTPD : Premiers Pas

60
18
fév.
2014
OpenBSD

Nous utilisons tous des services de messagerie en ligne tel que Gmail, Outlook, Yahoo, … Mais si vous vouliez prendre le contrôle de vos courriels ? Comment faire ? Comparons la technologie Exchange de Microsoft avec ses CAL's, et ses licences, et son budget, avec les technologies open-source comme Sendmail, Postfix ou dans notre cas OpenSMTPD.

Afin d'avoir un service aussi complet que Gmail, il faudra mettre en place plusieurs briques et OpenSMTPD en fait partie. OpenSMTPD est un service SMTP libre utilisant le-dit protocole comme défini dans la RFC 5321. Il permet d'échanger des e-mails avec d'autres systèmes utilisant ce protocole comme Sendmail, Postfix, Exchange, etc.

OpenSMTPD

OpenSMTPD est un service "jeune" qui a voulu reprendre la simplicité de compréhension et de configuration du firewall Packet Filter (PF) d'OpenBSD. Ce service est implémenté depuis OpenBSD 4.6 dans la branche "unstable" et depuis OpenBSD 5.3 en tant que stable. Une dépêche avait été publiée ici, fin 2009, à ce sujet.

Plus d'informations sur la configuration d'OpenSMTPD dans la suite de la dépêche.

Sommaire

Configuration

OpenSMTPD fournit plusieurs pages de man :

  • smtpd - Simple Mail Transfer Protocol daemon
  • smtpd.conf - Simple Mail Transfer Protocol daemon configuration file
  • smtpctl - control the Simple Mail Transfer Protocol daemon
  • newaliases - generate aliases mappings for the Simple Mail Transfer Protocol daemon
  • makemap - generate mappings for the Simple Mail Transfer Protocol daemon
  • aliases - aliases files format
  • forward - forwarding files format
  • table - format description for smtpd tables
  • sendmail - a mail enqueuer for smtpd

Le man smtpd est la première phase de l'approche pour utiliser ce service, il fournit les premières étapes pour un déploiement propre.

smtpd is not enabled by default.In order to use it as the system
mailer, ensure the mail queue is empty, then stop sendmail(8):

     # /etc/rc.d/sendmail stop

Modify the current mailwrapper(8) settings by editing /etc/mailer.conf:
     sendmail        /usr/sbin/smtpctl
     send-mail       /usr/sbin/smtpctl
     mailq           /usr/sbin/smtpctl
     makemap         /usr/libexec/smtpd/makemap
     newaliases      /usr/libexec/smtpd/makemap

Disable the sendmail clientmqueue entry in crontab(1).

Rebuild the aliases database, and enable the daemon:

     # newaliases
     # echo "sendmail_flags=NO" >> /etc/rc.conf.local
     # echo "smtpd_flags=" >> /etc/rc.conf.local
     # /etc/rc.d/smtpd start

Maintenant que le paramétrage du service au niveau du système est fait, nous allons passer à la configuration du fichier smtpd.conf.

listen on all

table aliases db:/etc/mail/aliases.db

# Uncomment the following to accept external mail for domain "example.org"
#
# accept from any for domain "example.org" alias <aliases> deliver to mbox
accept from any for domain "dev.unix-experience.fr" alias <aliases> deliver to maildir
accept for local alias <aliases> deliver to maildir
accept for any relay

Le service est à présent configuré, il nous reste à accepter les connections externes sur le port 25 avec Packet Filter (cf. plus loin) et à redémarrer le service smtpd avec la commande /etc/rc.d/smtpd restart.

Comme pour Packet Filter (PF), on vérifie la configuration d'OpenSMTPD avec smtpd -n. Pour lancer smtpd en mode debug lancer la commande smtpd -dv.

Configurez maintenant Packet Filter (rappel: fichier /etc/pf.conf)

 pass in proto tcp to self port smtp

Vérifiez maintenant la syntaxe et chargez le jeu de règles:

# Pour vérifier la syntaxe 
pfctl -nf /etc/pf.conf

# Pour charger les nouvelles règles
pfctl -f /etc/pf.conf

Pour conclure cette partie, réalisons un test:

telnet dev.unix-experience.fr 25
Connected to dev.unix-experience.fr.
Escape character is '^]'.
220 hermes.my.domain ESMTP OpenSMTPD

Ajout d'une couche sécurité

Allons un peu plus loin dans notre configuration et renforçons la sécurité.

Chiffrement TLS:

listen on pcn0 port 25 tls-require hostname Hermes

Analysons cette ligne de configuration du fichier smtpd.conf:

  • listen on pcn0 port 25 : le service écoutera sur l'interface pcn0 sur le port 25 (si le paramètre "all" est actif, le service écoutera sur toutes les interfaces)
  • tls-require force les clients à établir une connexion sécurisée avant d'être autorisés à dialoguer avec le SMTP ; l'option tls seule peut suffire mais tls-require renforce globalement. Il faut noter que l'utilisation de ces options nécessite la création de certificats. Ces certificats peuvent être spécifiés par l'ajout de l'option certificate .crt, .key, .dh, présent(s) dans le répertoire /etc/mail/certs/. Néanmoins si cette option n'est pas présente, le service recherchera des certificats sous la forme pcn0.crt et pcn0.key , qui correspondent au nom de l'interface sur laquelle nous écoutons. Il est utile de noter que si nous ne créons qu'un certificat et sa clé, et non le CA ainsi que le DH, alors le service utilisera ces paramètres par défaut.
  • hostname Hermes permet de spécifier un nom pour la bannière smtpd.

Test d'envoi

Nous allons à présent réaliser un test d’envoi d'email via la commande mail, en ayant lancé smtpd en mode debug, ainsi nous pourrons comprendre ce qui se passe en consultant les logs.

echo "Ceci est un message de test" |mail -v -s "TEST MAIL" root@localhost
<<< 220 hermes.my.domain ESMTP OpenSMTPD
>>> EHLO localhost
<<< 250-hermes.my.domain Hello localhost [local], pleased to meet you
<<< 250-8BITMIME
<<< 250-ENHANCEDSTATUSCODES
<<< 250-SIZE 36700160
<<< 250 HELP
>>> MAIL FROM: <root@hermes.my.domain>
<<< 250 Ok
>>> RCPT TO: <root@localhost>
<<< 250 Recipient ok
>>> DATA
<<< 354 Enter mail, end with "." on a line by itself
>>> .
<<< 250 e636d771 Message accepted for delivery
>>> QUIT
<<< 221 Bye

Ceci est le détail des interactions qui ont eu lieu pendant la communication avec le serveur OpenSMTPD. On y retrouve les champs du destinataire et de l'émetteur.

Si on regarde les logs de plus près, nous pouvons observer que le service est extrêmement verbeux :

smtp-in: New session 000000001f305e85 from host 0@localhost [local]
debug: aliases_get: returned 1 aliases
debug: 0x12ad371d0000: end of message, msgflags=0x0000
smtp-in: Accepted message e636d771 on session 000000001f305e85: from=<root@hermes.my.domain>, to=<root@localhost>, size=245, ndest=1, proto=ESMTP
debug: scheduler: evp:e636d771a30c37cc scheduled (mda)
debug: lka: userinfo <getpwnam>:unixexperience
smtp-in: Closing session 000000001f305e85
debug: mda: new session 000000002962b8f8 for user "unixexperience" evpid e636d771a30c37cc
debug: smtp: 0x12ad371d0000: deleting session: done
debug: mda: no more envelope for "unixexperience"
debug: mda: got message fd 3 for session 000000002962b8f8 evpid e636d771a30c37cc
debug: mda: querying mda fd for session 000000002962b8f8 evpid e636d771a30c37cc
debug: smtpd: forking mda for session 000000002962b8f8: "/home/unixexperience/Maildir" as unixexperience
debug: mda: got mda fd 4 for session 000000002962b8f8 evpid e636d771a30c37cc
debug: mda: end-of-file for session 000000002962b8f8 evpid e636d771a30c37cc
debug: mda: all data sent for session 000000002962b8f8 evpid e636d771a30c37cc
debug: smtpd: mda process done for session 000000002962b8f8: exited okay
delivery: Ok for e636d771a30c37cc: from=<root@hermes.my.domain>, to=<root@localhost>, user=unixexperience, method=maildir, delay=1s, stat=Delivered
debug: mda: session 000000002962b8f8 done
debug: mda: user "unixexperience" becomes runnable
debug: mda: all done for user "unixexperience"

Nous pouvons alors décrire les étapes de réception de l'email par le MTA qui a recherché un alias liant le destinataire (root@localhost). Une fois identifié comme l'utilisateur "unixexperience", le MTA transmet le message au MDA interne de OpenSMTPD en attribuant alors l'evpid que l'on peut interpréter comme envelope identifier au MDA.

Ensuite une session interne s'initialise où le message va être délivré dans l'emplacement Maildir correspondant à l'utilisateur "unixexperience".

Configuration d'un relais

Nous pouvons vouloir faire relayer nos emails par notre service SMTP lorsque les ports ou la destination de notre serveur OpenSMTPD sont bloqués à notre emplacement géographique, ou tout simplement pour en faire un relais. Nous allons donc ajouter une règle qui relaiera nos emails via Gmail.

Voici à quoi ressemble notre fichier smtpd.conf:

listen on pcn0 port 25 tls-require auth hostname Hermes
listen on pcn0 port 465 smtps auth  hostname Hermes

table secrets db:/etc/mail/secrets.db
table aliases db:/etc/mail/aliases.db

accept from local for any relay via tls+ auth://label@smtp.gmail.com:587 auth <secrets>

Pour arriver à cette configuration nous avons dû réaliser plusieurs actions.

echo "label IDGOOGLE@gmail.com:PASSWD" >> /etc/mail/secrets
makemap /etc/mail/secrets
chmod 640 /etc/mail/secrets* 
chown root:_smtpd /etc/mail/secrets*

Nous avons donc créé un fichier contenant les informations d'identification pour utiliser le relais de Gmail. Ensuite nous avons créé le fichier secrets.db qui sera utilisé par smtpd, nous avons restreint les permissions sur ce fichier et changé son propriétaire et son groupe pour que celui-ci puisse être lisible par le daemon smtpd d'OpenSMTPD. Nous avons renseigné ce fichier sous cette forme dans smtpd.conf.

table secrets db:/etc/mail/secrets.db

Maintenant la règle du relais :

accept from local for any relay via tls+auth://label@smtp.gmail.com:587 auth <secrets>
  • accept from local for any : nous acceptons les envois d'email localement pour n'importe quelle destination.

  • relay via tls+auth://label@smtp.gmail.com:587 auth : nous relayons via une authentification TLS en utilisant les informations d'authentification correspondant à l'étiquette label sur le service SMTP de Gmail sur le port 587 en utilisant la table "secrets".

Ce qu'il faut retenir de OpenSMTPD

  • produit en cours de développement (ajout de nouvelles fonctionnalités dans le futur);
  • facilité de compréhension de la configuration.

Ce qui est valable aujourd'hui pour son utilisation ne le sera sans doute plus demain.

Merci à la liste de discussion d'OpenSMTPD pour m'avoir éclairé sur le fonctionnement des étiquettes et pour une relecture de l'article.

  • # Merci aux contributeurs

    Posté par (page perso) . Évalué à 5.

    Merci aux contributeurs pour leur aide.

  • # relais ouvert ?

    Posté par . Évalué à 6.

    "accept for any relay" ça n'en fait pas un relais ouvert ? (ce qui est mal)

    • [^] # Re: relais ouvert ?

      Posté par . Évalué à 5.

      Non, "for any" fait référence au destinataire, pas à l’envoyeur. La ligne limite bien aux envoyeurs locaux ("from local").

      • [^] # Re: relais ouvert ?

        Posté par (page perso) . Évalué à 5.

        Y a pas « from local » dans l'exemple.

        • [^] # Re: relais ouvert ?

          Posté par (page perso) . Évalué à 4.

          En effet erreur de ma part mea culpa.
          accept from local for any relay est la bonne expression qui permet le relai des mails pour les utilisateur identifié qui sont alors considéré "locaux"

          • [^] # Re: relais ouvert ?

            Posté par (page perso) . Évalué à 10.

            Pas de souci, l'exemple reste correct.
            Pour eviter les betises, le comportement par defaut est de considerer que toute omission signifie un comportement local par default:

            accept for any relay == accept from local for any relay
            

            et

            accept from any == accept from any for local
            

            pour obtenir un open-relay il faut explicitement le demander:

            accept from any for any relay
            
    • [^] # Re: relais ouvert ?

      Posté par . Évalué à 0. Dernière modification le 19/02/14 à 18:16.

      accept from local

      Edit : wow, j'aurais du reload avant de poster, vous pouvez moinser…

  • # /etc/hosts

    Posté par . Évalué à 1.

    Merci pour la dépêche. Dans mes souvenirs il fallait avoir un /etc/hosts dûment renseigné pour localhost afin d'être sûr que ça marche. C'est toujours le cas ?

    • [^] # Re: /etc/hosts

      Posté par (page perso) . Évalué à 6.

      Si ton système ne résoud pas localhost je pense que tu vas avoir d'autres problèmes.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: /etc/hosts

        Posté par . Évalué à 0. Dernière modification le 19/02/14 à 16:24.

        Sauf que le fichier et l'OS sont assez permissifs sur la syntaxe, contrairement aux serveurs SMTP.

        Tu disais ça juste pour un bon mot où tu as déjà mis en place des serveurs SMTP (réellement fonctionnels) dans la vraie vie ?

        Selon la configuration du /etc/hosts, tes mails peuvent arriver chez Gmail mais se faire refuser chez Yahoo.

        • [^] # Re: /etc/hosts

          Posté par (page perso) . Évalué à 3.

          Pour l'info voici mon fichier hosts:

          127.0.0.1       localhost
          ::1             localhost
          192.168.0.23  hermes.my.domain hermes
          
          
        • [^] # Re: /etc/hosts

          Posté par (page perso) . Évalué à 3.

          Tu disais ça juste pour un bon mot où tu as déjà mis en place des serveurs SMTP (réellement fonctionnels) dans la vraie vie ?

          Non, je suis un branquignole mais je connais Certaines Personnes dont c'est le métier et a qui je confierais volontiers mon infrastructure SMTP.

          < Krunch> ca te semble plausible ? "Selon la configuration du /etc/hosts, tes mails peuvent arriver chez Gmail mais se faire refuser chez Yahoo."
          < Certaine Personne> non, il raconte des couilles

          Après, si tu peux expliquer les détails techniques ça peut être comique. Je dois avouer que je préfère les bugs obscures qui ont des conséquences a priori absurdes par rapport aux pseudo explications cargocultistes mais c'est distrayant aussi.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: /etc/hosts

            Posté par (page perso) . Évalué à 6.

            < Krunch> ca te semble plausible ? "Selon la configuration du /etc/hosts, tes mails peuvent arriver chez Gmail mais se faire refuser chez Yahoo."

            Ça me semble plausible si son /etc/hosts contient des trucs du genre 127.0.0.1 smtp.yahoo.com

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: /etc/hosts

              Posté par (page perso) . Évalué à 2.

              Plutôt mta5.am0.yahoodns.net etc alors mais si tu fais ça et que tu prétends avoir mis en place des serveurs SMTP réellement fonctionnels dans la vraie vie pour du vrai tu peux aussi aller te pendre.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: /etc/hosts

            Posté par . Évalué à -1.

            Moi je ne croirais pas quelqu'un qui emploie l'expression "raconter des couilles".

  • # Utilisateur de postfix

    Posté par (page perso) . Évalué à 5.

    Je me demande (très naïvement, je ne connais pas du tout OpenSMTPD) les différences, avantages et inconvénients par rapport à postfix.

    Quelqu'un a-t-il des retours d'expérience là dessus ?

    • [^] # Re: Utilisateur de postfix

      Posté par (page perso) . Évalué à 2.

      Je pense que l'avantage est le déploiement et une configuration très compréhensible (parfois démêler un postfix est un peu compliqué quand on n'y touche pas tous les jours :p).
      L'inconvénient c'est qu'il manque des options qu'on retrouve sur Postfix (authentification LDAP ?), mais qui viendront certainement bientôt

      CNRS & UNIX-Experience

      • [^] # Re: Utilisateur de postfix

        Posté par (page perso) . Évalué à 5.

        J'ai dit une bêtise, cela supporte bien LDAP (je le vois dans les options de compilation de ma poudriere FreeBSD), ainsi que MySQL et PgSQL

        CNRS & UNIX-Experience

    • [^] # Re: Utilisateur de postfix

      Posté par . Évalué à 2.

      J'utilise aussi Postfix et c'est vrai que la config est un peu touffue.

      Il y a une partie de la config qui sert à lui indiquer d'utiliser dovecot comme Local Delievery Agent (LDA). Une autre pour que mailman puisse prendre en charge les listes de discussions.

      Tout ceci est faisable simplement avec OpenSMTPD ?

      • [^] # Re: Utilisateur de postfix

        Posté par . Évalué à 2.

        Je ne sais pas ce qu'il en est pour mailman, en tout cas je l'utilise pour mon mail perso avec dovecot très simplement :

        accept from any for domain virtual deliver to mda "/usr/lib/dovecot/deliver -f %{sender} -d %{dest}"

        j'utilise aussi du dkim avec

        • [^] # Re: Utilisateur de postfix

          Posté par . Évalué à 2.

          OK. Dans Postfix, j'ai quelque chose de similaire pour Dovecot :

          dovecot   unix  -       n       n       -       -       pipe
            flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d${recipient}
          
    • [^] # Re: Utilisateur de postfix

      Posté par (page perso) . Évalué à 2.

      Perso je suis un fan de postfix, OpenSMTPd a l'avantage d'être simple et dispo de base dans OpenBSD.
      Je ne suis pas sûr que le but soit d'avoir toutes les fonctionnalités de postfix, sinon.

      Le moins d'OpenSMTPD: la syntaxe qui a changée au fil du temps, mais ça c'est peut-être stabilisé de ce coté ?

      les pixels au peuple !

  • # Woaw

    Posté par (page perso) . Évalué à 5.

    Merci pour ce tutoriel dont tu m'avais parlé depuis un moment et qui est passionnant.
    OpenSMTPd n'est pas encore aussi abouti que Postfix, mais Woaw, le plaisir d'utiliser la syntaxe PF-like sur un SMTP pour router ses mails, un vrai plaisir :).
    Je ne vois pas d'options de vérification sur le protocole (si les noms de domaines correspondent à des MX…). Qu'en est-il ?
    Concernant la partie canonical de Postfix (réécriture d'adresses/noms de domaines à la volée), y-a-t-il des options ?

    CNRS & UNIX-Experience

  • # OpenSMTPd est vraiment génial pour un serveur perso

    Posté par (page perso) . Évalué à 4.

    Si jamais vous cherchez à héberger vos mails perso sur un petit serveur, c'est vraiment l'idéal.

    J'utilise OpenSmtpd sur un VPS depuis 1 an et ça tourne sans aucun problème.

    On peut le compiler à la main sous une Debian et la config fait même pas 10 lignes.

  • # Gmail

    Posté par (page perso) . Évalué à 2.

    Et y'a-t-y une brique qui marche comme GMail? Un truc avec des tags?
    J'espère que tu vas nous écrire une dépêche par brique !

    • [^] # Re: Gmail

      Posté par (page perso) . Évalué à 3.

      Je ne vois pas bien le rapport : en principe, de gmail, on ne voit que la partie client (webmail), mais je n’ai jamais vu d’infos sur le(s) serveur(s) utilisé(s) ?

      • [^] # Re: Gmail

        Posté par (page perso) . Évalué à 3.

        Ben, les deux premières phrases du contenu me pousse à croire qu'il va présenter comment remplacer GMail de bas en haut. Il commence en bas, je veux savoir jusqu'où il va aller. Parceque bon, installer un serveur SMTP, c'est bien, mais si c'est pour ensuite se taper une interface de merde par dessus, non merci, j'ai déjà donné. Et je veux aussi savoir s'il existe un webmail façon gmail. Depuis que gmail existe, j'en n'ai jamais vu nulle part ailleurs.

        • [^] # Re: Gmail

          Posté par . Évalué à 1.

          Tu peux essayer ce projet prometteur (mais qui est encore en alpha) et qui gère entre autre les tags : https://github.com/pagekite/Mailpile

        • [^] # Re: Gmail

          Posté par (page perso) . Évalué à 1.

          J'ai installé Roundcube, tout joli tout moderne, pour convaincre les utilisateurs que linux c'est beau et c'est pas forcément réservé aux geeks…

          Quels sont les fonctionnalités qui te font dire que Gmail y'a pas mieux ?

          • [^] # Re: Gmail

            Posté par (page perso) . Évalué à 2.

            Gmail, ça gère les tags. J'ai pas cherché depuis un bout de temps, mais j'ai pas vu ça ailleurs. Et le roundcube que me propose OVH, la dernière fois que j'ai testé, il avait pas de tags non plus. Pour moi, c'est le truc utile. Je me fous pas mal du reste (enfin, non. La réactivité de gmail est bien, l'auto sauvegarde des emails en cours de rédaction, l'utilisation des tags dans les emails (ie, "email+tag@site.com"), ses nombreux plugins que j'utilise pour savoir si je peux téléphoner malgré le décalage horaire, la possibilité d'annuler l'envoi d'un email pendant le 5 secondes suivant l'appui du bouton d'envoi, etc. Bref autant de choses dont je ne me passe pas)

            • [^] # Re: Gmail

              Posté par (page perso) . Évalué à 3.

              mutt fait ça très bien (à par pour le téléphone mais bon, on peut s'en douter, c'est un client mail :D).
              Pour savoir si tu peux téléphoner, essaye date(1) avec la variable TZ qui va bien :). Tu peux même faire un alias dans ton shell préféré.

              Sérieusement, la dépêche parle d'un serveur smtp, c'est complètement HS de parler du front-end de la mort qui tue :).

              • [^] # Re: Gmail

                Posté par . Évalué à 4.

                "Complètement HS" non, au pire "un peu HS", mais il est vrai que l'article commence par "Afin d'avoir un service aussi complet que Gmail".

              • [^] # Re: Gmail

                Posté par (page perso) . Évalué à 2.

                J'utilise pas GMail pour téléphoner, mais j'ai un plugin qui devine dans quel fuseau horaire tu es, et qui m'indique s'il est judicieux ou non de téléphoner maintenant via une petite icône.

                Quand à mutt, il gère les tags comment ? Comment tu affiches tous les mails qui ont le tag T, ou les tags T1 et T2?

                Mais encore une fois, ma question reposait sure la pile complète d'email, du serveur au client. Sinon, pourquoi donc parlerait-il de GMail au début de l'article, si c'est pour discuter quelque chose sans rapport ?

                • [^] # Re: Gmail

                  Posté par (page perso) . Évalué à 2.

                  Il est fort ce GMail ! Il dit quoi à propos de ma timezone ? :D Je suppose que ça ne marche qu'avec ta liste de contact qui eux même utilisent les services Google et/ou qui sont loggués via un Google ID.

                  Le support des tags pour mutt, c'est via notmuch déjà évoqué plus haut dans ce thread. Il y'a plusieurs approches pour l'intégrer dans mutt (mutt-notmuch, notmuch-fs ou mutt-kz) donc l'interface peut varier. Mais notmuch-query permet de faire des requêtes "complexes". Après, ce sont des extensions que je n'utilise pas donc je ne suis pas expert sur la question, j'avais juste testé rapidement. Un tri un peu intelligent à la source (via procmail / imapfilter) et les filtres mutt me suffisent largement.

                  Évidemment, il y'a le mot "GMail" dans le fil, mais le sujet c'est OpenSMTPD, la partie qui envoie des mails. Encore la partie IMAP, une question sur "des tags" gérés côté serveur aurait pu avoir un certain sens. Si un fil évoque le mot "Windows" dans un sujet sur le noyau Linux, pense-tu vraiment que le sujet principal est Windows, un système d'exploitation quoi :D

                  • [^] # Re: Gmail

                    Posté par (page perso) . Évalué à 2.

                    Il est fort ce GMail ! Il dit quoi à propos de ma timezone ? :D Je suppose que ça ne marche qu'avec ta liste de contact qui eux même utilisent les services Google et/ou qui sont loggués via un Google ID.

                    Pas forcément. Je ne connais pas Gmail, mais Horde / IMP sait utiliser GeoIP pur afficher le petit drapeau correspondant au pays de l’expéditeur. Bon, c’est sûr que ça ne résiste pas à l’épreuve de ceux qui utilisent des domaines enregistrés ailleurs que chez eux…

            • [^] # Re: Gmail

              Posté par (page perso) . Évalué à 4.

              Gmail, ça gère les tags.

              https://bitbucket.org/wuzzeb/notmuch-web

              • [^] # Re: Gmail

                Posté par (page perso) . Évalué à 2.

                Je me permets de glisser une référence à sup, l'inspiration de notmuch, et qui a l'avantage de couvrir tout (indexation + ui) par défaut.

            • [^] # Re: Gmail

              Posté par (page perso) . Évalué à 3.

              Il y a 3 plugins de tag sur Roundcube http://trac.roundcube.net/wiki/Plugin_Repository#General

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Gmail

                Posté par . Évalué à 2.

                Et il y en a un qui est bien ? (par exemple qui permet de faire des recherches ensemblistes « je veux le tag "A" et "B" mais pas le "C" »)
                Parce qu'il y en a 2 qui se mappent sur thunderbird qui fait le service minimum (enfin non il en fait moins). Les tags (dans thunderbird) ne permettent pas de classer mais juste de repérer certains mails.

                Il ne suffit pas de sortir le bon mot clef pour que ce soit bien :)

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Gmail

            Posté par . Évalué à 2.

            Roundcube, ça reste tout de même assez lent et peu pratique à l'utilisation. C'est utile pour dépanner mais c'est le jour et la nuit par rapport à un client lourd.

    • [^] # Re: Gmail

      Posté par (page perso) . Évalué à 2.

      En faite, j'ai écrit cette dépêche/article aussi pour le blog sur lequel j'écris, la prochaine étape sera la communication avec Dovecot et/ou avec spamd + sieve puis Roundcube. Je dois me replonger dans tous cela. Je ne ferais peux-être pas une dépêche dessus par contre.

  • # touch -> echo

    Posté par (page perso) . Évalué à 4.

    Au lieu de

    touch "label IDGOOGLE@gmail.com:PASSWD" >> /etc/mail/secrets
    

    je pense que vous vouliez dire

    echo "label IDGOOGLE@gmail.com:PASSWD" >> /etc/mail/secrets
    

    En tout cas merci pour cette dépêche.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.