Personnellement, j'utilise surtout la ligne de commande, et parfois des outils graphiques quand ça apporte quelque chose, par exemple pour afficher l'arbre des commits ou ajouter des changements individuels plutôt que par fichier entier.
Chauffer sa maison avec 5W, pareil, je rigole un grand coup la.
Si t'arrives a rechauffer tes pieds dans un studio de 9m2 c'est deja le bout du monde.
Autant chauffer son salon avec briquet a ce compte la, ca chauffera pas plus mais au moins ca eclairera...
Mais je ne prétends pas que ça suffit à chauffer la maison ! Simplement que, l'hiver, 100% de l'énergie consommée par un serveur perso chez soi est utile au chauffage de la maison. Autrement dit, que 0% de l'énergie est perdue.
Encore une fois, il y a au moins un mec qui s'y connaît, qui reçoit la plus grande quantité de spams enregistrée pour une personne (un million par jour), et qui a mis au point ce qu'il faut pour trier avec une efficacité redoutable sans le moindre faux positif.
aaaaah l'écologie : c'est plus écolo d'avoir une machine up 24/24 chez toi que d'utiliser le smtp de ton fai ?
10 Watts dont 100% utilisés pour la puissance pure ton serveur personnel, et dont 100% contribuent au chauffage de ta maison l'hiver. Donc, 50% du temps seulement, c'est 10 Watts consommés en perte.
À comparer avec la consommation des serveurs du FAI, donc je pense au moins 25% sert à l'évacuation de la chaleur produite, même en hiver, chaleur qui n'est pas réutilisée. Plus la consommation des routeurs et autres équipements réseau associés.
Les commentaires partent un peu dans tous les sens à propos de noms DNS inverses. Je rappelle donc, que ce qui est important, c'est d'avoir un nom DNS inverse associé à son adresse IP, et que l'enregistrement A ou AAAA associé à ce nom donne bien la même adresse IP.
Avec un nom DNS inverse qui correspond au nom de domaine donné par son serveur (EHLO), c'est purement cosmétique. Refuser un message parce qu'il ne correspond pas est explicitement interdit par la RFC SMTP : [http://tools.ietf.org/html/rfc5321#section-4.1.4].
Avoir un nom DNS inverse qui, privé de son premier composant, correspond au nom de domaine de l'expéditeur du message (MAIL FROM:), c'est juste cosmétique. Aucun serveur sérieux ne refusera du courrier parce que ça ne correspond pas.
Enfin, toujours d'après la RFC SMTP, quand on n'a pas de nom d'hôte, par exemple quand on n'a qu'une adresse dynamique, il faut utiliser une adresse électronique comme EHLO !
Au risque de me répéter, tu peux conserver ton serveur de courrier en lui faisant utiliser le relais du FAI pour sortir. C'est moins bien que d'être complètement indépendant, mais mieux que rien tout de même.
On peut avoir d'excellentes raisons de vouloir envoyer son courrier directement. Par exemple, pour régler une politique SPF stricte : autoriser l'envoi avec <@example.com> exclusivement depuis son adresse IP, plutôt que depuis celle de mon serveur relais utilisé par tous les clients de mon FAI.
Ça, pour le coup, refuser du courrier parce que le nom DNS inverse ne correspond pas, c'est explicitement interdit par la RFC. Et ce n'est pas une mesure anti-spam efficace.
Haha, Hotmail. Eux, ils font encore plus simple : ils traitent comme spam tous les messages qui arrivent d'adresses IP qu'ils n'ont jamais vu, en gros. Mais ils les acceptent, ils les posent juste dans la boîte à spam de leurs utilisateurs.
Non, Google n'utilises pas de listes noires externes, et heureusement, c'est une très mauvaise techniques. Ces listes noires sont opaques, font des faux positifs, se font mutuellement confiance (effet cascade : une liste récupère tout d'une autre…), bref, c'est une belle merde.
Si j'ai bien compris la page d'explications, ils vérifieraient que le nom DNS inverse (verne.ortolo.eu dans mon cas) privé de son premier composant (ortolo.eu dans mon cas) correspond au domain de l'adresse d'expédition (MAIL FROM:).
C'est une connerie, et une belle, parce que :
1. aucune norme n'autorise à faire ça, au contraire, je crois que c'est explicitement défendu par les RFC ;
2. il y a une norme pour ça, c'est SPF ;
3. il y a plein de serveurs qui envoient du courrier de la part de plusieurs domaines, ne serait-ce que les serveurs mutualisés.
En outre, s'ils appliquaient cela au moment où tu as rédigé ce journal, ils ne l'appliquent plus maintenant (j'ai changé les noms de domaines, mais l'essentiel est que, entre mon nom DNS inverse privé de son premier composant, le EHLO et le MAIL FROM, rien ne correspond) :
220 mx.google.com ESMTP c28si2542700fka.44
ehlo verne.example.com
250-mx.google.com at your service, [91.121.200.164]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
mail from: <toto@example.net>
250 2.1.0 OK c28si2542700fka.44
rcpt to: <toto@gmail.com>
250 2.1.5 OK c28si2542700fka.44
data
354 Go ahead c28si2542700fka.44
.
250 2.0.0 OK 1268838382 c28si2542700fka.44
Donc, soit Google ont fait une connerie, qu'ils ont corrigés vite fait, soit ton problème est en réalité du à une interdiction au niveau SPF. Quel nom de domaine utilises-tu en MAIL FROM ?
Sommes-nous condamnés à nous envoyer des mail entre geeks possédant un serveur personnel, ou alors à utiliser le relai SMTP de notre FAI ?
Pas plus que la myriade de geeks, auto-entrepreneurs, petites entreprises et hébergeurs divers.
En revanche, nous sommes, depuis toujours, condamnés à nous abonner chez des FAI qui nous permettent d'envoyer du courrier dans de bonnes conditions : pas de blocage du SMTP sortant, DNS inverse personnalisable, adresse IP statique. Ou, chez un fournisseur de demi-accès à Internet, à utiliser son relais. Rien n'a changé.
Premièrement, ça n'a rien de nouveau, de nombreux fournisseurs d'accès déclarent les adresses IPv4 de leurs abonnés comme spammeurs potentiels, et ils se retrouvent bloqués par certains fournisseurs de messagerie.
Deuxièmement, cela affecte l'envoi de messages : ton FAI ne te permet pas d'envoyer du courrier directement dans de bonnes conditions, et t'oblige à passer par leur relais. Tu peux régler ton serveur de courrier pour cela.
Troisièmement, cela n'affecte pas la réception de messages.
Du point de vue du routeur–pare-feu, NAT ou exposition directe des machines qui sont derrière, c'est kif-kif. Dans un cas, c'est NAT et PAT fixe à la demande. Dans l'autre cas, c'est blocage des connexion entrantes et déblocage à la demande.
[^] # Re: GUI
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Des candidats pour le Google Summer Of Code sur Git ?. Évalué à 3.
Personnellement, j'utilise surtout la ligne de commande, et parfois des outils graphiques quand ça apporte quelque chose, par exemple pour afficher l'arbre des commits ou ajouter des changements individuels plutôt que par fichier entier.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 1.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 1.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 3.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
http://www.fit-pc.com/
Chauffer sa maison avec 5W, pareil, je rigole un grand coup la.
Si t'arrives a rechauffer tes pieds dans un studio de 9m2 c'est deja le bout du monde.
Autant chauffer son salon avec briquet a ce compte la, ca chauffera pas plus mais au moins ca eclairera...
Mais je ne prétends pas que ça suffit à chauffer la maison ! Simplement que, l'hiver, 100% de l'énergie consommée par un serveur perso chez soi est utile au chauffage de la maison. Autrement dit, que 0% de l'énergie est perdue.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 1.
http://acme.com/mail_filtering/
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 0.
10 Watts dont 100% utilisés pour la puissance pure ton serveur personnel, et dont 100% contribuent au chauffage de ta maison l'hiver. Donc, 50% du temps seulement, c'est 10 Watts consommés en perte.
À comparer avec la consommation des serveurs du FAI, donc je pense au moins 25% sert à l'évacuation de la chaleur produite, même en hiver, chaleur qui n'est pas réutilisée. Plus la consommation des routeurs et autres équipements réseau associés.
# Reverse
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 5.
Avec un nom DNS inverse qui correspond au nom de domaine donné par son serveur (EHLO), c'est purement cosmétique. Refuser un message parce qu'il ne correspond pas est explicitement interdit par la RFC SMTP : [http://tools.ietf.org/html/rfc5321#section-4.1.4].
Avoir un nom DNS inverse qui, privé de son premier composant, correspond au nom de domaine de l'expéditeur du message (MAIL FROM:), c'est juste cosmétique. Aucun serveur sérieux ne refusera du courrier parce que ça ne correspond pas.
Enfin, toujours d'après la RFC SMTP, quand on n'a pas de nom d'hôte, par exemple quand on n'a qu'une adresse dynamique, il faut utiliser une adresse électronique comme EHLO !
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 3.
[^] # Re: FAI et reverse
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 5.
[^] # Re: Precision sur la page d'aide
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 0.
À l'affirmation
je ne connais aucun FAI grand public qui le permet
la réponse
et si, free le fait...
est un contre-exemple tout à fait pertinent !
[^] # Re: La lutte contre le spam en 2010
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 6.
[^] # Re: Ils sont dingues
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 4.
[^] # Re: Enfin!
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 5.
[^] # Re: La lutte contre le spam en 2010
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
[^] # Re: Sortie != entrée
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 3.
[^] # Re: La lutte contre le spam en 2010
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
Si : tu deviens dépendant du relais SMTP de ton FAI.
[^] # Re: Sortie != entrée
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 6.
# Ils sont dingues
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
C'est une connerie, et une belle, parce que :
1. aucune norme n'autorise à faire ça, au contraire, je crois que c'est explicitement défendu par les RFC ;
2. il y a une norme pour ça, c'est SPF ;
3. il y a plein de serveurs qui envoient du courrier de la part de plusieurs domaines, ne serait-ce que les serveurs mutualisés.
En outre, s'ils appliquaient cela au moment où tu as rédigé ce journal, ils ne l'appliquent plus maintenant (j'ai changé les noms de domaines, mais l'essentiel est que, entre mon nom DNS inverse privé de son premier composant, le EHLO et le MAIL FROM, rien ne correspond) :
220 mx.google.com ESMTP c28si2542700fka.44
ehlo verne.example.com
250-mx.google.com at your service, [91.121.200.164]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
mail from: <toto@example.net>
250 2.1.0 OK c28si2542700fka.44
rcpt to: <toto@gmail.com>
250 2.1.5 OK c28si2542700fka.44
data
354 Go ahead c28si2542700fka.44
.
250 2.0.0 OK 1268838382 c28si2542700fka.44
Donc, soit Google ont fait une connerie, qu'ils ont corrigés vite fait, soit ton problème est en réalité du à une interdiction au niveau SPF. Quel nom de domaine utilises-tu en MAIL FROM ?
# Condamnés
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 4.
Pas plus que la myriade de geeks, auto-entrepreneurs, petites entreprises et hébergeurs divers.
En revanche, nous sommes, depuis toujours, condamnés à nous abonner chez des FAI qui nous permettent d'envoyer du courrier dans de bonnes conditions : pas de blocage du SMTP sortant, DNS inverse personnalisable, adresse IP statique. Ou, chez un fournisseur de demi-accès à Internet, à utiliser son relais. Rien n'a changé.
# Sortie != entrée
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal La mort des serveurs mail auto-hébergés. Évalué à 2.
Deuxièmement, cela affecte l'envoi de messages : ton FAI ne te permet pas d'envoyer du courrier directement dans de bonnes conditions, et t'oblige à passer par leur relais. Tu peux régler ton serveur de courrier pour cela.
Troisièmement, cela n'affecte pas la réception de messages.
[^] # Re: Incontournable
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 2.
[^] # Re: Xlib
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal catwm, encore un tiling window manager. Évalué à 2.