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 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.
Aller plus loin
- Site d'OpenSMTPD (995 clics)
- Dépêche LinuxFR sur la sortie de la version 5.3 en 2013 (95 clics)
- Liste de diffusion d'OpenSMTPD (73 clics)
- Manpage SMTPD(8) (105 clics)
# Merci aux contributeurs
Posté par Zwordi (site web personnel) . Évalué à 5.
Merci aux contributeurs pour leur aide.
# relais ouvert ?
Posté par Jeremy Monnet . Évalué à 6.
"accept for any relay" ça n'en fait pas un relais ouvert ? (ce qui est mal)
[^] # Re: relais ouvert ?
Posté par Moonz . É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 Sufflope (site web personnel) . Évalué à 5.
Y a pas « from local » dans l'exemple.
[^] # Re: relais ouvert ?
Posté par Zwordi (site web personnel) . É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 Gilles Chehade (site web personnel) . É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:
et
pour obtenir un open-relay il faut explicitement le demander:
[^] # Re: relais ouvert ?
Posté par navaati . Évalué à 0. Dernière modification le 19 février 2014 à 18:16.
accept from localEdit : wow, j'aurais du reload avant de poster, vous pouvez moinser…
# /etc/hosts
Posté par kursus_hc . É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 Krunch (site web personnel) . É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 kursus_hc . Évalué à 0. Dernière modification le 19 février 2014 à 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 Zwordi (site web personnel) . Évalué à 3.
Pour l'info voici mon fichier hosts:
[^] # Re: /etc/hosts
Posté par Krunch (site web personnel) . Évalué à 3.
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.
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 claudex . Évalué à 6.
Ç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 Krunch (site web personnel) . É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 kursus_hc . Évalué à -1.
Moi je ne croirais pas quelqu'un qui emploie l'expression "raconter des couilles".
# Utilisateur de postfix
Posté par al-info . É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 Loïc Blot (site web personnel) . É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
Veepee & UNIX-Experience
[^] # Re: Utilisateur de postfix
Posté par Loïc Blot (site web personnel) . É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
Veepee & UNIX-Experience
[^] # Re: Utilisateur de postfix
Posté par jihele . É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 pikapika . É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 jihele . Évalué à 2.
OK. Dans Postfix, j'ai quelque chose de similaire pour Dovecot :
[^] # Re: Utilisateur de postfix
Posté par Patrick Lamaizière (site web personnel) . É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 Loïc Blot (site web personnel) . É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 ?
Veepee & UNIX-Experience
# OpenSMTPd est vraiment génial pour un serveur perso
Posté par 0xfg . É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.
[^] # Re: OpenSMTPd est vraiment génial pour un serveur perso
Posté par pikapika . Évalué à 1.
Il est même packagé pour debian jessie
# Gmail
Posté par Axioplase ıɥs∀ (site web personnel) . É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 Thierry Thomas (site web personnel, Mastodon) . É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 Axioplase ıɥs∀ (site web personnel) . É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 Vincent . É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 al-info . É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 Axioplase ıɥs∀ (site web personnel) . É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 zul (site web personnel) . É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 kursus_hc . É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 Axioplase ıɥs∀ (site web personnel) . É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 zul (site web personnel) . É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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
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 Juke (site web personnel) . Évalué à 4.
https://bitbucket.org/wuzzeb/notmuch-web
[^] # Re: Gmail
Posté par rakoo (site web personnel) . É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 claudex . É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 barmic . É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 Antoine . É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 Zwordi (site web personnel) . É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 Almacha (site web personnel) . Évalué à 4.
Au lieu de
je pense que vous vouliez dire
En tout cas merci pour cette dépêche.
[^] # Re: touch -> echo
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.