Appel à la comunauté | Branchons nos serveurs SMTP

philpep-tlse · Le 27/03/2009, à 17:36

Salut,

J'observe ici beaucoup de gens qui montent eux mêmes leurs serveurs SMTP, c'est bien. Mais quand le serveur tombe (que ce soit à cause d'une panne ADSL ou d'une panné d'électricitée) c'est vachement moins bien.

Donc l'idée c'est de former une communautée pour se fournir des MX secondaires, tertiaires etc.
Pour dire vrai, les fournisseurs de MX secondaires sont rares et même s'il en existe j'ai plus confiance en chaqu'un d'entre vous qu'en eux. Ce forum, la liste du wiki, IRC font que je connais de vue certains membres de la communauté et je leurs ferrais confiance s'il faut héberger mon mail pendant une panne ADSL.

Vous connaissez le principe j'imagine, si le MX primaire (là ou il y a les boites mail) n'est pas joignable, le MX secondaire prend les mail, les gardes jusqu'à ce que le MX primaire soit de nouveau opérationel et ce pendant un temps variable (définit par maximal_queue_lifetime dans postfix).

Problèmes techniques :
Il est préférable de maintenir pour chaque MX une liste d'emails valables pour lui eviter d'accepter n'importe quel SPAM. Si on fait quelque chose à petite echele on pourra s'envoyer des liste, sinon ou peut mettre en place un serveur SQL si les liste de mail changent plus qu'une fois tous les mois.

--------------
Configuration de postfix pour être un MX secondaire : (ceux qui utilisent sendmail se débrouillerons seul vu qu'il on déjà réussi à le faire marcher correctement )

# Les hote pour lesquels on accepte le relay
relay_domains = host1.tld, host2.tld  
# La liste des emails des relais ici par un fichier DB unix (TODO : sql si la liste est trop "mouvante")
relay_recipient_maps = hash:/path/to/config/postfix/relay_recipients

Puis dans le fichier /path/to/config/postfix/relay_recipients :

user1@host1.tld            un_truc
user2@host1.tld            un_truc
....
user1@host2.tld            un_truc
user2@host2.tld            un_truc
....

Ne pas faire attention à un_truc c'est juste la création d'une base de donnée unix qui le veux vous pouvez mettre n'importe quoi.

ensuite un petit

postmap /path/to/config/postfix/relay_recipients

Et let's rock's !

Tous les intéréssés peuvent venir en discuter, que ce soit sur le principe même ou pour les problèmes technique. Je ne prétend pas connaitre parfaitement postfix donc plus on est de fous plus on rit devant main.cf.

Soit on en discute ici, soit sur IRC chez moi : irc.philpep.org port 6667 (celui par defaut) sur le chan #staff (Attention, mon IRCD refuse les nick de plus de 9 caractères )

À bientôt

philpep

EDIT : Je suis opérationnel pour héberger un MX secondaire : http://forum.ubuntu-fr.org/viewtopic.ph … 5#p2548225

Dernière modification par philpep-tlse (Le 10/04/2009, à 15:11)

Nikonoel · Le 27/03/2009, à 17:54

Sur le principe, je dis +42

Après... il faut que je me lance dans l'installation de mon serveur mail !
J'espère vraiment que cette initiative va fonctionner !

꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳ · Le 27/03/2009, à 17:57

J'aime beaucoup l'idée, mais je doute d'avoir les compétences requises ...

philpep-tlse · Le 27/03/2009, à 19:30

Pas besoin de compétences pour monter un serveur mail hein, suffit d'avoir envie, lire de la doc et ça marche tout seul. Une fois que tu comprend ce qu'est un serveur mail tu saura configurer un serveur mail.

D'ailleurs vu le nombre de post sur le mail ici je pense qu'on a pleins d'astuces à se partager vu les battons dans les roues que nous mettent les gros opérateurs.

Par exemple si vous avez une ip de particulier AOL refuse tout contact avec votre serveur. Donc juste pour aol mes mails sont relayés par Free. (transport_maps dans postfix)

Dernière modification par philpep-tlse (Le 27/03/2009, à 19:32)

꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳ · Le 27/03/2009, à 19:34

philpep-tlse a écrit :

Pas besoin de compétences pour monter un serveur mail hein, suffit d'avoir envie, lire de la doc et ça marche tout seul.

Je veux bien apprendre. Si tu as déjà de la doc synthétique sous la main, je suis preneur.

philpep-tlse · Le 27/03/2009, à 19:54

superpapalolo a écrit :

philpep-tlse a écrit :
Pas besoin de compétences pour monter un serveur mail hein, suffit d'avoir envie, lire de la doc et ça marche tout seul.
Je veux bien apprendre. Si tu as déjà de la doc synthétique sous la main, je suis preneur.

http://www.postfix.org

Bon ok c'est de l'anglais.
Moi j'ai beaucoup apris dans le livre : "Posfix La référence" aux éditions O'Reilly , il doit se trouver dans toute bonne bibliothèque universitaire de science (Celle de Toulouse III en tout cas).

Mais le plus important c'est de savoir prendre son temps et de ne pas vouloir installer postfix + serveur IMAP/POP + webmail + SASL + SpamAssassin + ClamAV tout d'un coup

Une chose à la fois c'est plus facile. Savoir faire des test SMTP en telnet etc. Je compte faire une doc là dessus (postfix, dovecot, roundcube, mail virtuel) mais quand j'aurais passé mes partiels (si on les passe un jours).

Dernière modification par philpep-tlse (Le 10/04/2009, à 10:11)

꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳ · Le 27/03/2009, à 19:58

merci pour le lien, je suis nativement bilingue, ça devrait aller. Et Tlse n'est pas bien loin, si la bibliothèque locale ne veut pas acquérir le livre.

꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳ · Le 27/03/2009, à 20:03

#hehedotcom\'isback a écrit :

sinon j'ai des liens qui vont bien

N'hésite pas, c'est toujours intéressant de partager ce genre de choses.

Ras' · Le 27/03/2009, à 20:04

+42 aussi pour l'idée. J'avais suggéré ça dans un autre topic, mais vu que j'ai pas encore de serveur, c'est pas pratique.

Sinon j'avais deux ou trois questions :

Vous connaissez le principe j'imagine, si le MX primaire (là ou il y a les boites mail) n'est pas joignable, le MX secondaire prend les mail, les gardes jusqu'à ce que le MX primaire soit de nouveau opérationel et ce pendant un temps variable (définit par maximal_queue_lifetime dans postfix).

Comment faire en sorte que tant que les mails ne sont pas chez le destinataire final les mails soient chiffrés (et donc illisible par les MX secondaires) ? Sans que l'expéditeur n'ait à faire quoique ce soit de particulier ?

Et aussi :

Problèmes techniques :
Il est préférable de maintenir pour chaque MX une liste d'emails valables pour lui eviter d'accepter n'importe quel SPAM. Si on fait quelque chose à petite echele on pourra s'envoyer des liste, sinon ou peut mettre en place un serveur SQL si les liste de mail changent plus qu'une fois tous les mois.

Je comprends pas du tout ce truc.
En gros tu veux qu'on passe à notre MX secondaire une liste des gens succeptibles de nous mailer, pour qu'il n'accepte que les mails de ces gens là et ainsi éviter le SPAM ?
Problème de confidentialité déja, j'ai pas spécialement envie que Mr X connaisse les mails de mes amis (enfin perso je m'en fout mais y'en a que ça froisse), et problème de fonctionnement aussi, on peut pas savoir qui va nous mailer demain...
En général pour le SPAM on utilise plutôt une blacklist non ?

Bref, sinon je suis 100% pour, il faudra juste que je trouve de bons tutos pour créer un webmail et pour le configurer au niveau des MX secondaires et en avant !

Kurokame · Le 27/03/2009, à 20:08

philpep-tlse a écrit :

http://www.postfix.org
Bon ok c'est de l'anglais.

http://x.guimard.free.fr/postfix/

Valère · Le 27/03/2009, à 20:15

J'en profite pour m'abonner car ce sujet/projet m'intéresse, au passage un tutoriel bien complet qui m'a permis de monter mon serveur mail : http://www.starbridge.org/spip/spip.php?article12

philpep-tlse · Le 27/03/2009, à 20:32

Ras' a écrit :

Comment faire en sorte que tant que les mails ne sont pas chez le destinataire final les mails soient chiffrés (et donc illisible par les MX secondaires) ? Sans que l'expéditeur n'ait à faire quoique ce soit de particulier ?

Je dis pas que c'est impossible, mais juste pas vraiment utile. Le chiffrement doit se faire coté client (GNUPG etc). De toutes façon si le mail passe à un moment en clair sur le net il est légitime de devenir parano sur la confidentialité des données. D'autant plus s'il touche des serveurs SMTP qui ne t'appartiennent pas.

En gros tu veux qu'on passe à notre MX secondaire une liste des gens succeptibles de nous mailer, pour qu'il n'accepte que les mails de ces gens là et ainsi éviter le SPAM ?
Problème de confidentialité déja, j'ai pas spécialement envie que Mr X connaisse les mails de mes amis (enfin perso je m'en fout mais y'en a que ça froisse), et problème de fonctionnement aussi, on peut pas savoir qui va nous mailer demain...
En général pour le SPAM on utilise plutôt une blacklist non ?

C'est une liste d'utilisateur ayant effectivement une boite mail sur le domaine dont on est le MX secondaire qu'il faut maintenir. (pas d'expediteur mais de destinataire)

En fait quand ton serveur SMTP reçoit un mail (en gros) il regarde si la destination est pour un domaine qu'il gère, si non alors il le refuse. Ensuite il regarde si la boite (coté gauche de l'adresse) existe si oui il place le mail là ou il faut, si non il refuse le mail.

Concrètement, si le MX secondaire ne connait pas les adresses valides du MX primaire il les accepte tous et bon nombres de SPAM arrivent dans des adresse inéxistantes.

Exemple simple : le <title> de ma page internet http://philpep.org est lighttpd@philpep.org , cette adresse n'est pas valide et mon serveur SMTP refuse ~5 spam par jours sur cette adresse, si il l'avait accepté le spammeur va se dire : "tiens il accepte , ce doit être une adresse valide, je peux lui envoyer plus de spam".

Dernière modification par philpep-tlse (Le 27/03/2009, à 20:58)

Ras' · Le 27/03/2009, à 20:57

C'est une liste d'utilisateur ayant effectivement une boite mail sur le domaine dont on est le MX secondaire qu'il faut maintenir. (pas d'expediteur mais de destinataire)

Ah ben... Ca parait logique... enfin moi ça me parait logique ^^ je vois pas comment ça pourrait marcher autrement...

Je dis pas que c'est impossible, mais juste pas vraiment utile. Le chiffrement doit se faire coté client (GNUPG etc). De toutes façon si le mail passe à un moment en clair sur le net il est légitime de devenir parano sur la confidentialité des données. D'autant plus s'il touche des serveurs SMTP qui ne t'appartiennent pas.

Je suis pas très calé en chiffrement... Mais au final, le mail ne circulera jamais en clair, et ne sera en clair que sur le serveur du destinataire, c'est ça ? Donc pas besoin de chiffrer par dessus ?

Neros · Le 27/03/2009, à 21:31

Faut pas avoir Orange non plus =/

Kurokame · Le 27/03/2009, à 21:44

Ras', c'est aussi une question de confiance. Si tu ne fais pas confiance à celui qui héberge le relai, tu acceptes de t'en passer ou bien tu en changes.
Par contre si je fais ça, je ne prendrai pas forcément la peine de tenir une liste/base d'utilisateurs acceptés par le MX secouru.

Ras' · Le 27/03/2009, à 22:55

Je fais confiance, mais un minimum de cryptage peut être sympa quand même... Rien ne me dit que le serveur de mon gentil et honnete sauveteur est hyper sécurisé, ou que quelqu'un de moins bien intentionné n'a pas un accès physique à la machine... Une petite sécurité supplémentaire n'est pas de refus à mon goût...

Enfin j'y connais rien pour l'instant, mais ça me parait tout de même louche que ça ne soit pas crypté, c'est pour ça que je demandais une confirmation sur ce point

꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳ · Le 27/03/2009, à 23:07

#hehedotcom\'isback a écrit :

Je ne peux pas me permettre de mettre le site Ubuntu-fr à défaut . En revanche, il est fort probable que le facteur passe malgré l'heure

Merci tout plein !

philpep-tlse · Le 28/03/2009, à 00:38

Ras' a écrit :

Je fais confiance, mais un minimum de cryptage peut être sympa quand même... Rien ne me dit que le serveur de mon gentil et honnete sauveteur est hyper sécurisé, ou que quelqu'un de moins bien intentionné n'a pas un accès physique à la machine... Une petite sécurité supplémentaire n'est pas de refus à mon goût...
Enfin j'y connais rien pour l'instant, mais ça me parait tout de même louche que ça ne soit pas crypté, c'est pour ça que je demandais une confirmation sur ce point

Voilà une partie d'un header mail comme il y en a plein :

Received: from smtp1.voila.fr (smtp1.voila.fr [193.252.22.174])
        by philpep.org (Postfix) with ESMTP id F01082F4A4
        for <XXXXX@philpep.org>; Tue, 10 Mar 2009 14:00:21 +0100 (CET)
Received: from me-wanadoo.net (localhost [127.0.0.1])
        by mwinf4019.voila.fr (SMTP Server) with ESMTP id 9107D70000C7
        for <XXXXX@philpep.org>; Tue, 10 Mar 2009 13:59:28 +0100 (CET)
Received: from wwinf4618 (wwinf4618 [10.232.13.62])
        by mwinf4019.voila.fr (SMTP Server) with ESMTP id 7EC697000082
        for <XXXXX@philpep.org>; Tue, 10 Mar 2009 13:59:28 +0100 (CET)

Voilà, ce mail qu'on m'envoie à touché 3 machines avant d'arriver chez moi, et ce ne sont pas des petits.

Non sans rire, si tu veux faire du mail sécurisé y'a 2 solutions :
- Que ta correspondance soit sur le même serveur
- Que ton mail soit crypté dès qu'il arrive sur le net.

Si quelqu'un veut vraiment choper tous les mails qui sortent en clair de ton serveur il réussira.

Je prèfère que mon mail de temps en temps passe par chez toi Ras' que chez n'importe quel industriel du Net.

Link31 · Le 28/03/2009, à 00:59

philpep-tlse a écrit :

Je prèfère que mon mail de temps en temps passe par chez toi Ras' que chez n'importe quel industriel du Net.

Personnellement, tant qu'à sacrifier la confidentialité, je préférerais être noyé dans la masse des innombrables clients d'un gros serveur mail, plutôt que de m'en remettre personnellement à un particulier.

Un particulier ne résistera pas longtemps à la tentation de lire les mails qui transitent pas son serveur, et vu le faible volume il y prêtera encore plus d'attention. Tandis que le postmaster d'un gros SMTP, même s'il le voulait, serait dans l'incapacité de faire de même.

Ça c'est du point de vue de la confidentialité uniquement. Côté technique, je suis le premier à dire que la centralisation n'est pas vraiment une bonne chose sur internet, et que plus un service est décentralisé et dispersé, mieux c'est (j'ai toujours en tête le spectre, de plus en plus réel, du Minitel 2.0).

Dernière modification par Link31 (Le 28/03/2009, à 01:01)

philpep-tlse · Le 28/03/2009, à 02:28

Link31 a écrit :

philpep-tlse a écrit :
Je prèfère que mon mail de temps en temps passe par chez toi Ras' que chez n'importe quel industriel du Net.
Personnellement, tant qu'à sacrifier la confidentialité, je préférerais être noyé dans la masse des innombrables clients d'un gros serveur mail, plutôt que de m'en remettre personnellement à un particulier.
Un particulier ne résistera pas longtemps à la tentation de lire les mails qui transitent pas son serveur, et vu le faible volume il y prêtera encore plus d'attention. Tandis que le postmaster d'un gros SMTP, même s'il le voulait, serait dans l'incapacité de faire de même.
Ça c'est du point de vue de la confidentialité uniquement. Côté technique, je suis le premier à dire que la centralisation n'est pas vraiment une bonne chose sur internet, et que plus un service est décentralisé et dispersé, mieux c'est (j'ai toujours en tête le spectre, de plus en plus réel, du Minitel 2.0).

C'est pas totalement faux. Mais soyons clair, une panne d'élétricité ou d'ADSL en france sauf circonstances exeptionelles ou FAI verreux (qui a parlé de SFR?) dure rarement plus d'un jour. Donc le mail ne restera en général pas longtemps et si posfix possède une option pour sauvegarder une copie de chaque mail même en relay alors il faudra être clair entre nous et la desactiver.

Après c'est une question de confiance, faudra sans doute établir une charte du bon MX secondaire. Mais pour moi c'est clair que sur les gros SMTP, tout est archivé bien rangé dans des dossiers et des programmes robots prets à scanner 100 mails à la seconde. Je suis un peut parano oui, mais il parait que c'est dans l'air du temps.

J'ai 5 utilisateurs sur mon mail, toutes des personnes que je connais physiquement et que je vois régulièrement. Ça fait moins d'une vingtaine de mail par jours qui passent par mon SMTP. Et c'est le même rapport de confiance (pire encore puisque je fais partie de leur sphère privée). Même si je suis un peu accro au "tail /var/log/mailog" c'est juste pour voir que tout ce passe bien et qu'il n'y ai pas de spam qui passe. D'ailleurs je leurs conseille d'utiliser POPS et de télécharger leurs mails pour éviter qu'il y ai trop de données sur le disque dur qui pourrait tomber en panne.

Dernière modification par philpep-tlse (Le 28/03/2009, à 03:15)

Ras' · Le 28/03/2009, à 08:04

Je suis un peu de l'avis de Link31...
Enfin, un peu mitigé en fait...
Ca m'empechera pas de faire parti du projet je pense (j'ai pas une vie si confidentielle que ça, et en général je fait confiance aux gens), mais ça me chiffone un peu tout de même...

toniotonio · Le 28/03/2009, à 10:41

vous avez un pb majeur dans le concept de mx secondaire: ce dernier doit avoir les memes filtrages que le mx principal.

En clair, si votre mx secondaire ne s'occupe pas de filtrage ou a minima, et qu'il relait vers le mx principal, qui lui filtre plus serieusement, alors un bounce va etre généré par le MX secondaire et il va devenir une source de backscatter. (et au final etre blacklisté)

la seule solution correcte serait d'avoir le MEME niveau de filtrage sur chaque serveur MX (primaire et secondaire) ce qui dans le cas d'un projet de ce style est difficilement envisageable.

et puis il faut aussi esperer que le serveur MX primaire n'aura pas de pb de configuration, sinon un bounce sera egalement générer.

Bref les mx secondaire ce n'est pas aussi simple qu'il n'y parait.

philpep-tlse · Le 29/03/2009, à 16:54

@toniotonio, ouais j'avais pas pensé à tout ça au début.

La seule chose qui génère un bounce chez moi c'est une adresse inexistante. Spamassassin marque les mails mais ne génère pas d'erreur à l'envoyeur.

D'où la liste des adresses valides à mettre sur le MX secondaire, mais c'est tout non ?

toniotonio · Le 29/03/2009, à 18:48

pourras tu etre certain que la configuration de tous les serveurs cibles ne generera pas de bounce ?

c'est le pb quand tu n'as pas le controle des plateformes

philpep-tlse · Le 09/04/2009, à 01:33

Bon, voilà je commence alors

Si quelqu'un veux un MX secondaire chez moi je lui offre. Il suffit de me donner une liste d'adresses mails valides de son/ses domaines. Ensuite de rajouter un champs MX avec une priorité plus élevée que son MX primaire (Le MX primaire est celui avec la plus basse priorité même si ça parait illogique, mais vous savez on compte à partir de 0 alors on est pas à ça près ), et qui pointe vers mail.philpep.org.

En langage gandi (registar bien connu) ça donne quelque chose comme ça :

# En remplaçant 50 par une priorité plus élevé que votre MX primaire
@ 10800 IN MX 50 mail.philpep.org.

Les mails vont en queue pendant une semaine maximum (temps à négocier).

Comme l'a dit toniotonio, essayons de garder les mêmes rêgles de filtrages. Donc d'une manière générale, il faut accepter tous les mails pour son domaine (pouvu que l'adresse existe) et faire le filtrage ensuite avec procmail, spamassassin etc. Et si on veut vraiment blacklister complètement un domaine ou une adresse, il faut en informer le MX secondaire rapidement car si le MX primaire refuse des mails que le MX secondaire lui transmet alors c'est la cata

Si ça intéresse quelqu'un : phil ate philpep.org

Dernière modification par philpep-tlse (Le 10/04/2009, à 15:14)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 27/03/2009, à 17:36

Appel à la comunauté | Branchons nos serveurs SMTP

#2 Le 27/03/2009, à 17:54

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#3 Le 27/03/2009, à 17:57

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#4 Le 27/03/2009, à 19:30

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#5 Le 27/03/2009, à 19:34

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#6 Le 27/03/2009, à 19:54

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#7 Le 27/03/2009, à 19:58

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#8 Le 27/03/2009, à 20:03

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#9 Le 27/03/2009, à 20:04

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#10 Le 27/03/2009, à 20:08

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#11 Le 27/03/2009, à 20:15

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#12 Le 27/03/2009, à 20:32

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#13 Le 27/03/2009, à 20:57

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#14 Le 27/03/2009, à 21:31

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#15 Le 27/03/2009, à 21:44

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#16 Le 27/03/2009, à 22:55

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#17 Le 27/03/2009, à 23:07

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#18 Le 28/03/2009, à 00:38

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#19 Le 28/03/2009, à 00:59

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#20 Le 28/03/2009, à 02:28

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#21 Le 28/03/2009, à 08:04

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#22 Le 28/03/2009, à 10:41

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#23 Le 29/03/2009, à 16:54

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#24 Le 29/03/2009, à 18:48

Re : Appel à la comunauté | Branchons nos serveurs SMTP

#25 Le 09/04/2009, à 01:33

Re : Appel à la comunauté | Branchons nos serveurs SMTP

Pied de page des forums