LaBienPensanceMaTuer a écrit 1611 commentaires

Perso, je n'ai jamais voulu confier mes emails à gmail.
Et les webmails libres (roundcube & co) ne sont malgré tout pas encore suffisament riches pour me satisfaire.
Donc oui, j'utilise thunderbird …

Le greylisting c'est simple: soit un mail qui arrive sur ton MX:

Le mail : "Salut, j'viens de X.X.X.X, expédié par t@c.com pour machin@tondomain, tu prends ?" (Aka EHLO PLOP\nMAIL FROM:t@c.com\nRCPT TO: machin@tondomain)
Ton serveur : "Euh … je te connais pas. Dégage et reviens dans 3 minutes". (Aka 450 Try again later)

Les robots de spams auront tendance à ne pas revenir dans 3 minutes, ne respectant pas la RFC.
Alors qu'un vrai serveur SMTP réessayera.
C'est donc une technique pour lutter contre le spam balancé à coup de robot, mais au détriment d'un léger délai lors de premier échange de mail avec un nouvel expéditeur.
Ensuite, le service de greylisting conserve le tuple expéditeur/serveur/destinataire pour accepter directement le mail.

Je sais pas si tu t'en rends compte, mais tu viens de donner des arguments supplémentaires à mon avis de base: bidouiller ses enregistrements DNS pour re-router son flux de mail vers "le serveur d'un pote" c'est sale.

Sinon l'objectif n'était pas d'expliquer l'eau tiède… mais je garde toujours en tête que si toi tu connais bien le concept de TTL etc… ce n'est peut être pas le cas de tout le lectorat linuxfr et que de ce fait, une petite explication ne fait pas mal.

Mais vous êtes sérieux là ????
P*tain mais c'est hallucinant….

Faut vraiment que je démonte tout vos arguments moisis un à un ?
Bon ok…

Alors tu fais quoi si ton MX primaire tombe en carafe qd t'es en vacances rando en Corse sans connexion internet ? Tu perds simplement tes mails ?
ET si c'est ton pote qui est en vacances ? Tu rootes son serveur ?

Le MX de backup, c'est fait pour ça, ça marche tout seul, t'as rien à faire.
Là sincèrement, je vous comprend vraiment pas …

Et pour infos, ça fait pas le job … car les mails vont être "delivered" sur le serveur de son pote … donc après, comment tu fais pour les rapatrier sur ton serveur à toi ?
Un scp ? Une copie d'imap à imap ?
Encore des bidouilles crades et inutiles….

J'suis peut être pas des plus "condescendant" dans mon ton, mais j'tente d'amener des arguments techniques à mes assertions…. je me fais systèmatiquement descendre en flèche, donc je préfère abandonner et vous laisser avec vos lignes ADSL et vos bidouilles de gorets.

Je tiens juste un petit truc que j'ai déjà entendu: "un bon admin sys va travailler pendant quelques mois dans l'objectif de ne plus rien avoir à faire ensuite".

Allé, ciao :)

Euh non… c'est pas tout à fait ça le bidouillage ….

Le monsieur disait plus haut:

Sur un auto herbergement je préferais un MX en secours chez un pote (inactif) qu'on active à la main (en jouant sur les DNS) quand y'a un gros problème.

Si je comprend bien, c'est pas vraiment juste changer le TTL de la zone, mais plus changer le MX primaire "à l'arrache". Excuse moi, mais je trouve que c'est sale.

Les gens font des choses sales, certes.
Mais là, ce genre de chose, c'est faites par Bind & co automatiquement.
Comment ça marche ?
En gros un serveur DNS (disons celui de free.fr qui veut d'ailleurs t'envoyer un mail) a l'enregistrement concernant ton MX en cache. Il regarde depuis combien de temps il l'a et si il est expiré (le fameux TTL).
Si il est expiré, alors il effectuera une requête auprès des serveurs de nom faisant autorité sur ton domaine pour avoir le nouvel enregistrement, et le mettra en cache.

Cette explication est très "simplifiée". Il y a en effet plusieurs valeurs importantes au niveau DNS (refresh/retry/expire/negative cache ttl) utilisés dans différents cas de figure (DNS primaire cassé, etc…).

Mais grosso modo, ça marche comme ça.

Donc pour le coup, c'est "relativement" infaillible: le temps de propagation DNS sera au pire égale à celui de ton TTL.

Après, si le serveur de free.fr n'a pas l'IP de ton MX en cache, alors il la demandera aussitôt, et de ce fait, la propagation sera "instantanée"!

Oui ça se règle.
Mais à quoi bon se lancer dans ce genre de bidouilles quand des barbus très compétents y ont déjà pensé depuis des décennies en créant un système fiable et bien pensé, j'ai nommé "MX Secondaire" ?

Bein écoute, quelqu'un qui héberge des mails sur une ADSL en disant "pffiou … un MX2 ça sert à rien", oui je considère que c'est faire de la merde.
Après tu sais, faut pas se vexer, c'est encore une fois un échange de point de vue et je n'ai en aucun cas l'omniscience…

Méfie toi du reverse DNS … A une époque j'avais mis en place les restrictions que tu cites, mais j'ai du faire machine arrière à cause de laposte.net qui avait mal configuré le PTR pour ses serveurs de mails. Résultat, je refusais tout ce qui venait de chez eux (et mes hébergés étaient pas très content …)
Méfiance donc …

Rolalal … je reste dubitatif devant tant de mauvaise foi (à moins que ce sois un manque de compétence ou d'imagination) !!!

solution alternative tout à fait acceptable qui consiste à ne pas avoir de MX secondaire

Cette solution acceptable à tes yeux car du fait de l'hébergement amateur.
Elle ne l'est pas à mes yeux (je fais aussi de l'amateur, mais j'ai choisi de le faire bien).
Soit, chacun ses opinions. Mais ce qui me fait sauter au plafond, c'est de lire qu'un MX2 est déconseillé …. c'est n'importe quoi!!

Va trouver un autre auto-hébergé prêt à mettre en place un serveur rsync en écriture pour que tu lui envoie ta base de données et qu'il la remonte régulièrement. Bonne chance.

Bein si c'est pas Rsync, si c'est pas MySQL, tu peux tout aussi bien exporter cette liste sur un httpd que ton copain "auto-hébergeur de MX2" récupérera via un bête wget dans une crontab…. waow … trop PUISSANT !

Ah et j'oubliais une chose … "En jouant avec les DNS" … mais LOL quoi … t'as entendu parler du temps de propagation DNS ?
Par exemple, sur ton domaine, le TTL pour les enregistrements MX est de 86400… ça peut vite prendre du temps la propagation.

Sincèrement, qu'on me parle pas d'hébergement de mail si c'est pour faire des bidouilles comme celle-ci….

Encore un autre faux problème …
Je m'appuie sur du postfix avec de la base de données MySQL pour mes domaines virtuels…

Donc le MX2 n'a qu'à (au choix):
1/ Répliqué la base de données.
2/ Faire un dump dans un fichier plat toutes les XX minutes.

Effectivement, si on utilise des services lambda de backup de MX, alors oui, ça se fait pas simplement. Mais en s'arrangeant avec d'autres auto-hébergés, pas de soucis ma bonne dame!
Après, c'est sûr que si on prend la problématique de l'hébergement par dessus la jambe, alors on peut s'affranchir de MX2, mettre son MX principal sur une ligne 56k, etc…

Mais pour moi, si on veut du boulot bien fait, alors on met un MX2 synchronisé avec le primaire… ça coute qq dizaines de minutes à mettre en place et quand ton alim ou ton disque dur cramera 1 jour où ton découvert autorisé t'empêchera de le renouveller de suite, bein tu seras content de t'être pris la tête 10 minutes pour avoir un MX2 propre.

Bein non … le deuxième ça pourrait être toi, Tanguy, n'importe quel autre "auto-hebergé" avec qui je me serai mis d'accord sur un échange de bon procédé …
(A l'époque ou je faisais de l'auto-hébergement, c'est comme ça que je procédais).

Oui mais c'est justement là ou je ne suis pas d'accord … si il y a un bien un domaine ou le MX2 me parait relativement essentiel, c'est l'auto-hébergement!!!

Dixit les arguments ci dessus, en réponse à Tanguy.

L'intérêt d'un MX secondaire, c'est qu'il gardera les mails plus de 5 jours, lui …

Ca peut paraitre en effet inutile pour des vrais archi de mails (j'entend un serveur dans un datacenter avec un vraie connexion internet) ou il y a rarement plus de 5 jours de downtime.
Par contre dans le cas d'un serveur MX primaire sur une ADSL, l'utilité d'un MX secondaire me parait tout de suite plus pertinente (bein ouai, ton ADSL peut parfaitement rester cassé plus de 5j … oui, je connais le refrain de l'auto-hébergeur: ça tombe jamais en panne, blabla … jusqu'au jour ou…).

Autre argument en faveur d'un MX secondaire: les délais entre chaque tentative augmente généralement avec le temps … ainsi, après 1 ou 2 jours de downtime, les mails les plus anciens ne seront réémis que tardivement.
Sur un MX secondaire, tu forces le flush, c'est parti, tout tes mails arrivent dans l'heure, même les plus ancien.

Dernier argument pour démontrer l'utilité d'un MX secondaire: le délai de 5j est celui conseillé par la RFC.
Mais il ne s'agit en aucun cas d'une valeur codée en dure dans le MTA. De ce fait (et j'ai déjà vu faire) certains admins n'hésitent pas à réduire ce délai, afin d'éviter de pourrir leurs queue mail avec les mails des autres…

Et sinon, désolé, mais à mes yeux, un argument se basant sur "la difficulté" et, grosso modo, "la fainéantise" pour faire l'impasse sur un élément de base de la sécurité et fiabilité d'une infrastructure (quelle qu'elle soit) est sans fondement.

Une impossibilité technique, oui. La flemme, non.

Vrai/Faux problème …. en 4j de temps, tu devrais bien revoir passer le même SMTP source, et donc accepter le mail :)

Par ailleurs, il suffit que le tuple destinataire/expediteur/IP (ou classe C) ai été vu une fois pour qu'ensuite, les mails passent directement.
Donc à moins de flusher ta base tout les jours, tu devrais avoir des problèmes de délais sur les premiers emails provenant de ce genre d'infra, mais les suivants passeront comme une lettre à la poste.

Vous voulez dire que vous avez plusieurs enregistrements MX (il y en a toujours au moins un), pointant vers des serveurs différents ? Si c'est le cas, c'est en général une mauvaise idée pour un petit site http://www.bortzmeyer.org/mx-secondaire.html

Quoi ??? Mais tu dis n'importe quoi !! :)
C'est le concept même d'avoir plusieurs enregistrements MX: avoir plusieurs serveurs aptes à réceptionner le flux de email.
Ainsi si ton MX primaire est cassé, le secondaire (qui DOIT être un autre serveur) réceptionnera l'email en attendant que le primaire revienne à la vie.

Les arguments avancés dans ton post de blog sont absolument farfelus et sans fondements.
Oui, avoir plusieurs MX distincts présentent quelques difficultés supplémentaires concernant la lutte antispam… et alors ????
Plutôt que de te creuser la tête et de solutionner ces problèmes, tu préfères faire l'impasse sur un MX2 en prétendant qu'il est inutile … foutaises!

Et pour le problème du greylisting et des multiples MX, il suffit simplement d'utiliser un service de greylisting te permettant la réplication des bases de données: MySQL master/master ou Rsync de fichiers plats ….

Re-merci pour le tuto… je vais y jeter un oeil en attendant l'arrivée du bouquin fraichement commandé :)
Pour ce qui est de l'installation de l'environnement de développement, sur une Ubuntu 12.04, ça se passe tout seul …

J'oubliais le lien

… sous la forme de Bootstrap.js, framework HTML/CSS qui nous vient de twitter.

Et outre Bootstrap, je crois qu'il y a une multitude de framework du même type implémentant des systèmes de "grid".

Après, c'est sur que c'est pas du "natif", mais ça a le mérite de s'intégrer très facilement et surtout d'être très facile à prendre en main.

Merci pour ce retour, c'est ce qu'il me manquait pour me mettre au développement sur Android …
Le Java m'a laissé, depuis l'époque de l'IUT, un souvenir "traumatisant" et j'évitais jusqu'alors soigneusement de m'y frotter! Mais c'est vrai qu'un bon IDE peut changer la donne :)

Tout à fait d'accord avec toi …
A la maison, on a deux huiles: une huile quelconque pour les basses besognes (cuisson entre autres) et une huile++ qu'on est allé cherché dans une exploitation oléicole du coin pour les crudités…
Et si ma copine me voit mettre l'huile++ dans l'eau des pâtes, c'est le drame assuré :)

… tout dépend de "la sauce".
Avec une carbonara par exemple, je pense que le beurre est plus adapté que l'huile d'olive.
A l'inverse, une sauce à base de tomates sera mieux révélée par un filet d'huile.
Pour finir, pour un gratin quelconque, ce sera ni huile ni beurre mais crème
Etc… :)

Ce genre de débat ressemble à ce qu'on peut croiser 10 fois par jour sur les mailings list de divers projets, que ce soit pour des fonctionnalités, pour le nom, le logo, etc…

Je comprend pas trop pourquoi ça se retrouve ici en fait … les gens intéressés par les frasques typées "feu de l'amour sauce PiTiVi" seront déjà au courant car inscrits sur les ML du projet et les autres bein … ils s'en balancent je crois.

En fait, il y a pas réellement "d'information" dans ce journal. C'était peut être une tentative de troll, mais en fait, je vois même pas ou est le troll.

Enfin un commentaire constructif et pertinent sur ce fil !
Tout à fait, le gilet il sert à rien qd ta moto et toi êtes debout … et c'est normal!!!
Il est fait pour qu'on te voit si t'es inanimé sur la chausée…
Après, c'est vrai que de jour, ça ne sert pas vraiment à grand chose … et il y a beaucoup de motards qui ne prennent pas leurs machines de nuit.