Le
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #26537613
Le Fri, 07 Feb 2020 09:43:40 +0100,
Vrai.Ou.Faux
JKB
Le Thu, 06 Feb 2020 18:37:26 +0100,
Vrai.Ou.Faux
- Tu gères toi-même ton serveur de mail

C'est un boulot à plein temps, raison pour laquelle les serveurs de
mails des FAI grand public sont devenus aussi moisis. Je ne suis pas
sûr que ce soit réellement une idée. Cela fait 25 ans que je gère
des serveurs de mails, il devient de plus en plus difficile de
réussir à envoyer ses mails sur tous les domaines, le dernier gag
étant l'invalidation d'une partie des protocoles SSL par les
nouveaux SMTP (quand on envoyait sur des trucs gérés par des pieds
et pas mis à jour, on se tapait des erreurs SSL et des mails qui se
perdaient !).
Par ailleurs, à moins d'avoir un serveur hébergé dans un datacenter,
il faut un accès internet professionnel (pour éviter les IP
résidentielles), une ou plusieurs IP fixes et savoir ce que l'on
fait pour ne pas avoir de problèmes de réception. Sur la simple
journée d'hier, j'ai eu plus de 99,5% de connexions foireuses
(comprendre en provenance de réseaux zombies) et sur ce qui reste,
encore beaucoup de spam. Exemple (obtenu avec un greeting delay) :
Feb 7 08:14:20 rayleigh sm-mta[3415900]: 0177E9KZ3415900: ip-38-57.ZervDNS [92.118.38.57] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Feb 7 08:14:24 rayleigh sm-mta[3415902]: 0177EDU83415902: ip-38-57.ZervDNS [92.118.38.57] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Feb 7 08:14:33 rayleigh sm-mta[3415912]: 0177EMHn3415912: ip-38-57.ZervDNS [92.118.38.57] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Feb 7 08:14:34 rayleigh sm-mta[3415914]: 0177EV8a3415914: [185.234.219.101] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Feb 7 08:14:42 rayleigh sm-mta[3415915]: 0177EVRk3415915: ip-38-57.ZervDNS [92.118.38.57] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Et là, on ne parle que de la réception. Pour l'envoi, il faut
maîtriser son DNS, SPFv1, DKIM et j'en passe (certificats SSL par
exemple). Bref, tout cela n'est pas à la portée du premier venu.
JKB

Gérer un serveur mail n'est pas à la portée du premier venu, mais ce n'est
pas très compliqué si on a un peu d'ordre et de méthode.

On a beau avoir de l'ordre et de la méthode, on ne maîtrise qu'un
seul côté de la chaîne. Et on est contraint de faire avec les
configurations baroques qu'on peut trouver de l'autre côté. Il fut
un temps, les MX de SFR étaient les pires qui puissent être, j'avais
dû créer des queues rien que pour eux. Dans le projet
milter-greylist auquel je participe, on a une liste des serveurs
notoirement "cassés" et ne respectant pas les RFC. C'est assez
instructif. On trouve là-dedans (liste non exhaustive) :
list "broken mta" addr {
...
12.107.209.244/32 # kernel.org (unique sender)
12.107.209.250/32 # sourceware.org (unique sender)
...
64.12.136.0/24 # AOL (common pool)
64.12.137.0/24 # AOL
64.12.138.0/24 # AOL
...
64.233.160.0/19 # Google
66.94.237.16/28 # Yahoo Groups servers (common pool)
66.94.237.32/28 # Yahoo Groups servers (common pool)
66.94.237.48/30 # Yahoo Groups servers (common pool)
...
66.218.66.0/23 # Yahoo Groups servers (common pool)
66.218.67.0/23 # Yahoo Groups servers (common pool)
66.218.68.0/23 # Yahoo Groups servers (common pool)
66.218.69.0/23 # Yahoo Groups servers (common pool)
...
66.102.0.0/20 # Google
66.249.80.0/20 # Google
72.14.192.0/18 # Google
74.125.0.0/16 # Google
152.163.225.0/24 # AOL
...
205.188.0.0/16 # AOL
...
207.171.168.0/24 # Amazon.com
207.171.180.0/24 # Amazon.com
207.171.187.0/24 # Amazon.com
207.171.188.0/24 # Amazon.com
207.171.190.0/24 # Amazon.com
...
216.33.244.0/24 # Ebay
216.239.32.0/19 # Google
...
}
Or les mails à destination de ces domaines (qui ne respectent pas
l'intégralité des RFC) doivent aussi arriver. Tu vas me dire qu'ils
ne les respectent pas dans le sens sortant, tu auras raison. Mais
mon expérience me souffle que s'ils ne les respectent pas dans un
sens, il n'y a aucune raison qu'ils les respectent dans l'autre
sens. Et c'est d'autant plus dur à détecter que les mails n'arrivent
_jamais_ sur ton MX.
Il y a aussi les vendeurs de listes grises/noires. Tu peux te
retrouver à perdre un temps infini avec tes adresses blacklistées
pour des raisons étranges (parce que le vendeur de liste blackliste
par exemple tout un /24). Pour sortir de ce genre de chose, c'est
une grosse galère et une perte de temps assurée.
Donc soit on investit du temps et on sait exactement ce que l'on
fait, soit on se contente de bricoler quelque chose avec des "tutos"
sur le grand ternet, ce qui amène généralement des tas d'effets de
bords non maîtrisés en se disant "advienne que pourra".
Je le fait depuis des lustres à titre pro et ça fonctionne très bien.
Ce n'est en aucun cas un boulot a plein temps pour gérer un seul serveur.
Tout est une histoire de (bonne) configuration.

Je ne peux pas être d'accord. Aujourd'hui, des MX comme gmail ou
hotmail changent de paramétrage très régulièrement et une
configuration qui fonctionnait se met à ne plus fonctionner. Dernier
gag de gmail : 5 mails/h vers la même adresse, c'est trop et on se
prend une erreur temporaire (en plus, ça dépend des jours ou de
l'humeur du MX). Je passe sous silence les paramètres
DKIM et autres joyeusetés. Lorsqu'on gère des gros domaines, il faut
toujours avoir l'oeil sur les files d'attente et les messages
d'erreur. Lorsque tu mets ton serveur à jour pour raison de
sécurité, tu peux aussi te retrouver en panade en ne pouvant plus
envoyer des mails vers certains MX. J'ai donné à de trop nombreuses
reprises à tel point que j'ai dû patcher sendmail pour cela pour
avoir la paix (le serveur d'Orange était jusqu'à très récemment géré
par un pied qui n'autorisait en SSL/TLS que des algorithmes que
tout bon système Unix refusait comme algorithmes percés.
Visiblement, les clients ont gueulé assez fort pour que le MX soit
patchéi correctement.).
Au passage, depuis la semaine dernière, il y a un nouveau truc sur
le MX de Free qui coupe autoritairement une transaction qu'il trouve
trop lente. Pas encore trouvé la solution, mais je suis preneur. Mes
SMTP sont sur deux liaisons SDSL à 4Mbps et un mail avec une pièce
jointe de 6 Mo ne passe plus !
Un petit serveur dédié est bien évidemment indispensable pour tout cela.

Deux si on veut faire les choses proprement. Plus un bind9 géré
localement pour avoir par exemple un certificat letsencrypt géré
automatiquement (pour utiliser nsupdate).
Donc si on reprend : avoir son propre serveur de mails, c'est savoir
administrer correctement une machine (deux) de type Unix/OpenVMS sans que
ce soit un énorme trou de sécurité. C'est se taper la gestion d'un
domaine (avec SPFv1/DKIM et j'en passe), la gestion des certificats
SSL/TLS et là-dessus un machin comme sendmail (mon truc à moi, je
suis un vieux barbu), postfix, exim ou autre, et un serveur pop/imap.
Je mantiens que si on veut que ça fonctionne raisonnement avec tous les
MX distants et tous les SMTP, c'est un énorme boulot à la
configuration et un énorme boulot de surveillance.
Raison pour laquelle mon premier conseil (qui semble t'avoir échappé)
était de prendre une adresse gmail ou laposte.net ...

Ce qui t'a sans doute échappé, c'est que je répondais exclusivement
à la seconde proposition, raison pour laquelle j'ai coupé la
première.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme