PhenIXUS

par **jdh** » 07 Déc 2011 00:07

Ce qui est intéressant dans ce fil, c'est que des éléments de compréhension sont expliqués !

Il n'y a pas de meilleure solution qui réponde à tous les cas.
Le contexte permet de choisir la solution qui convient le mieux à ce contexte.

Pour une PME de 30 ou 200 personnes, il est peu onéreux de disposer
- d'une SDSL (2M ~200-250€) avec ip fixe,
- d'un firewall, d'un relais mail, un serveur de mail interne,
- le tout alimenté et climatisé correctement.
Il n'y a pas de difficulté à disposer d'un nom de domaine adapté (societe.fr).
(Les opérateurs français proposent des packs SDSL+nom de domaine+boites)

Pour un particulier, avec une ADSL, c'est un peu quelconque d'utiliser un nom de domaine dynamique.
Mais c'est vrai que l'on peut acheter (louer) un domaine chez les dyndns et autre freedns !
Ca ça valorise la réception directe !
Et, en effet, plusieurs distributions sont très bien adaptées : SME, Zentyal, ClearOS, Artica, iRedMail, ...

Le changement d'adresse ip d'une ADSL ne doit (devraient) pas poser de problèmes :
- le protocole SMTP prévoit le renvoi, les délais, ... (la nature asynchrone),
- le dns prévoit la durée de vie d'un définition nom -> @ip (le ttl).

par **jdh** » 07 Déc 2011 09:29

Concernant fetchmail, le temps par défaut (sous Debian) est de 5' (300 secondes).

Le problème majeur est de récupérer la totalité des mails déposés (depuis le dernier relevé) dans le temps imparti.
Si tous les mails ne sont pas récupérés, et que le daemon est relancé, il y aura des doublons de mails reçus.
On peut même arriver à un blocage total ... (avec impossibilité de récupérer quoi que ce soit et multiples exemplaires des mails).

Il faut donc prendre en considération, le nombre de mails, la taille des mails, la vitesse de récupération (débit de l'adsl).
Par exemple, avec une adsl 8M, vous pouvez transporter théoriquement environ 0,8*300=240 Mo en 5'.
Dans la pratique, au delà de 40-50 Mo en 5', cela me semble très compromis et il faut augmenter.
(Ne pas oublier qu'un mail avec une pièce jointe de 2 Mo fait environ 3 Mo réel car il faut encoder la pièce jointe.)

Au besoin, il faut augmenter ce délai, et ce n'est pas très grave puisque vous récupérez votre mail en delai/2 en moyenne.
(Par exemple Windows SBS 2003 qui proposait un "fetchmail" en pop3 avec un délai recommandé de 15'.)
Je recommande la technique que pour un nombre de boites jusqu'à 20 ou 30 boites.

par **arnaud056** » 07 Déc 2011 20:50

Titofe a écrit :Discussion très intéressante.

Plus que cela même! 8-)

J'apprécie fortement le fait que les avantages et les inconvénients de chaque solution soient présentés :!:

En effet il n'y a pas de solution meilleure qu'une autre, mais simplement plus adaptée aux besoins et attentes de celui qui la met en place.
Cette riche conversation m'a fait également revoir ma position sur ce que je vais mettre en place et je remercie jibe d'avoir présenté et défendu "sa" méthode car..... elle correspond en gros à ce que j'avais l'intention de faire: ce qui m'importe, ce n'est pas d'avoir, mais de faire et ce à ma sauce, selon mes humeurs et... mes compétences, dans un cadre purement amateur où je suis donc prêt à accepter quelques désagréments pour pouvoir bomber le torse et dire fièrement "c'est moi qu'ai fait ça!"
Dans un cadre pro, même pour une boîte où je serais seul, j'aurais de suite sauté sur un joli paquet domaine+www+mail tout préconfiguré comme il y en a en veux-tu en voilà.

Dans mon cas présent, je vais prendre un "vrai" nom de domaine chez gandi (pour frimer 8-)

et parce que les domaines "bidons" proposés par freedns se font parfois rejeter par les clients www ou par ce qu'il y a devant) et je vais émettre via le smtp de mon fai. Je ne vois plus que 2 choses qui pourraient clocher dans la liste de mises en gardes donnée par jdh:

- pas de mx-backup. Question bête (que je vais tester en coupant ma sme demain): si mon serveur n'est pas opérationnel (et que je n'ai pas de second serveur de réception), le mail ne va-t'il pas revenir à l'expéditeur accompagné d'un message d'erreur?? --> l'expéditeur s'il n'est pas trop neuneu saura que je n'ai pas reçu le message et réessayera ultérieurement (ou pas!).... En plus, en prenant la chose à la lettre: un email n'est pas un fax: on ne sais jamais s'il est vraiment arrivé chez le destinataire.
Cependant en cherchant, j'ai trouvé un free_MX-Backup. Je ne sais pas si quelqu'un a déjà essayé ceci, mais j'aimerais m'en passer car je suis sceptique : la boîte vend des anti-spams --> que faire pour assurer ses ventes?? envoyer des spams aux idiots qui enregistrent leur adresse email!!!

Une question: est-il possible dans les enregistrements dns (freedns dans mon cas) de faire un renvoi des mails à destination du domaine "domaine_arnaud.com" vers mon adresse "arnaud@fai.net" avec un enregistrement comme on en ferait pour le serveur backup-MX (cad avec un poids plus élevé que le serveur MX "normal")? :roll:

--> donc utiliser mon adresse email de chez mon fai comme zone temporaire d'où je pourrais fetcher les mails non-reçus par ma sme?

- le "open-relay":

jibe a écrit :Mais avec SME, pas de problème : on est blindés de ce côté

je ne sais absolument pas pourquoi --> il va falloir que je me documente sur le sujet et que j'apprenne à connaitre un peu les bases pour détecter si le "blindage" du serveur a été percé.

- les spams? J'ai facilement trouvé sur le wiki publié par quelqu'un dont les compétences ne sont plus à démontrer...... Je n'ai plus qu'à l'appliquer :roll:

En tous cas je suis bien heureux d'avoir maintenant à ma disposition les éléments qui me permettent de prendre "ma" décision en sachant ce à quoi je peux m'attendre! :idea:

Au cas où il me faille (c'est beau le subjonctif!) dans l'avenir me réorienter vers le paquet d'un hébergeur, je vous le ferais savoir, avec les raisons bien entendu.

@+
Arnaud

par **sibsib** » 07 Déc 2011 23:18

Bonjour,

Effectivement, discussion très intéressante :-)

Pour apporter de l'eau au moulin de jdh, je voudrais tout de même rappeler qu'une des raisons pour ne pas héberger son mail chez soi, c'est qu'une panne de réception de mail peut facilement passer inaperçue. Ou, dit autrement, il est assez facile de mettre en place son serveur de mail local, mais moins facile de savoir s'il fonctionne bien.

Ceci dit, dans la catégorie "faites ce que je dis, pas ce que je fais" :-)

je gère évidemment mon domaine de mail dans ma cave, et je "profite" donc parfois des désagréments induits (serveur planté le jour du départ en vacances pour 3 semaines, genre ;-)

)

Arnaud, pour le MX-Backup, je veux bien le prendre (quand tu auras mis ce qu'il faut en place!), si tu es intéressé, --> MP

A+,
Pascal

par **jibe** » 07 Déc 2011 23:39

Salut,

Titofe a écrit :
jibe a écrit :Je ne sais pas ce qu'il en serait sur d'autres serveurs "tout en un" comme Zentyal ou ClearOS. On peut espérer que c'est pareil (mais à vérifier, entre autres par des tests poussés d'open relay et de contournement de l'interdiction de relayage). Par contre, pour tout autre type de serveur, la solution hébergement pro + fetchmail reprend l'avantage, au moins en dessous d'un certain volume !

Par défaut sur Zentyal il faut être authentifié sur le SMTP pour pouvoir envoyer des mails.
Pour ClearOS je ne me souviens plus si c'est le cas par défaut, mais je sais qu'on peut en faire de même.
Donc je confirme qu'il n'y a pas plus de risque d'utiliser un Zentyal ou ClearOS qu'un SME pour se prémunir d'un open relay.

Attention aux affirmations pouvant induire en erreur d'autres membres et/ou risquant d'abaisser le niveau élevé que nous voulons (re)donner à ce site. J'ai parlé de tests poussés, pas d'authentification nécessaire ! Il est effectivement indispensable de s'assurer d'être blindé contre les détournements du protocole visant à tromper les serveurs et à leur faire relayer des mails. Au moins les contournements utilisant des techniques les plus souvent utilisées ! L'authentification est une chose, à supposer qu'elle ne puisse pas être contournée (parfois, un simple buffer overflow suffit !), mais le relaying se fait différemment : par envoi d'un mail à un SMTP à qui on demande de faire suivre. Là, plus question d'authentification !

D'ailleurs, il y a quelques années, j'avais découvert une faille sur SME. N'importe quel spammeur aurait pu l'utiliser pour faire son sale boulot ! Elle est corrigée maintenant, ainsi qu'une autre présentant un risque très faible. Je n'ai plus tous les détails en tête, j'avais fait ça avec un copain spécialiste de sendmail et donc du protocole SMTP, mais quand j'affirme que SME est très bien protégée contre le relaying, c'est parce que je l'ai vérifié. Avant d'affirmer que Zentyal et ClearOS sont aussi fiables, la moindre des choses serait de le vérifier également. Malgré tout le sérieux avec lequel SME a été conçue, il y avait une faille. Rien ne prouve qu'il n'y en ait pas sur d'autres distribs, y compris les plus cotées (c'était le cas de SME à l'époque où j'avais découvert la faille !).

arnaud056 a écrit :- le "open-relay":
jibe a écrit :Mais avec SME, pas de problème : on est blindés de ce côté
je ne sais absolument pas pourquoi --> il va falloir que je me documente sur le sujet et que j'apprenne à connaitre un peu les bases pour détecter si le "blindage" du serveur a été percé.

A ma connaissance, il n'y a aucun cas d'intrusion ni de relaying mail connu avec des SME non "trafiquées" (par contre, plusieurs cas d'intrusion après changement de version de PHP ! Ce pourquoi j'appelle toujours à la prudence pour toute utilisation détournée ou non prévue). C'est déjà un bon point, mais ça ne prouve au mieux qu'une probabilité de ne pas avoir ce genre de problème, pas vraiment l'efficacité de la protection !

Mais là, il y a mieux : comme je le disais, j'ai fait il y a quelques années des tests assez poussés avec un ami spécialiste de la question. Si ça t'intéresse, je peux essayer de retrouver ces tests ou de les lui redemander. En gros, les pirates ou spammeurs voulant faire relayer des mails par un serveur non open relay utilisent des techniques diverses visant à tromper le serveur SMTP, comme remplacer le @ par un %, ou faire suivre deux @, un au domaine accepté et un au domaine vers lequel relayer, genre toto%domaine.final ou toto@domaine.relay@domaine.final. Si le serveur est mal protégé contre ce genre de stratagème, il accepte le mail et le relaie. Bon, je ne sais pas si mes exemples sont bons (jamais essayé de forcer du relaying sur un SMTP, en plus je suis un très mauvais pirate :lol:

), mais il y a un bon nombre de techniques connues (nous en avions testé près d'une trentaine, si mes souvenirs sont exacts) et efficaces !

J'ai fait ces tests périodiquement pendant longtemps (ce qui m'a permis de constater qu'à l'occasion de je ne sais plus quel changement de version, les failles que nous avions constatées avaient été colmatées), puis j'ai abandonné, rassuré en voyant que la sécurité sur SME ne variait que dans le sens d'améliorations. Je me contente maintenant de surveiller les logs.

par **Franck78** » 07 Déc 2011 23:55

Pour les test de serveurs SMTP, c'est Thibaut :
http://www.pagasa.net/test-smtp/

Chez moi, j'ai depuis 5 ans mon portable qui fait office de serveur SMTP quand il est allumé.

Un serveur SMTP essaiera toutes les quatres heures pendant un deux ou trois jours (je sais plus) de joindre le SMTP du domaine récepteur. Quand on dit que SMTP est asynchrone (pas instantané) , c'est pas pour abandonner à la première anicroche :lol:

J'ai aussi mon nom de domaine chez MYNAMEUP, avec eux, on peut suffisament régler leur DNS pour obtenir ce que l'on cherche avec une IP dynamique.
En gros, il faut pouvoir ajouter au moins un CNAME !

par **jibe** » 08 Déc 2011 00:10

sibsib a écrit :Pour apporter de l'eau au moulin de jdh, je voudrais tout de même rappeler qu'une des raisons pour ne pas héberger son mail chez soi, c'est qu'une panne de réception de mail peut facilement passer inaperçue. Ou, dit autrement, il est assez facile de mettre en place son serveur de mail local, mais moins facile de savoir s'il fonctionne bien.

Certes ! Mais quels sont les risques lorsqu'on a un bon MX backup ?

sibsib a écrit :serveur planté le jour du départ en vacances pour 3 semaines

Oui, je connais :lol:

En mieux :
- J'ai une "corde à linge" (appellation brevetée par sibsib

) épissurée à presque tous les poteaux qui me sert de ligne ADSL
- Guère mieux du côté alimentation électrique (3 coupures au moins - peut-être pas tout vu cette nuit - de plus d'1/2h à plus d'1h entre cette nuit et ce matin à cause de quelques flocons :twisted:

)
- Lorsque je pars dans la famille philippine, c'est pour 2 mois, et cela déclenche presque systématiquement un orage le lendemain de mon départ.

=> Je suis obligé de faire appel à Cool34000 (je ne sais plus si je t'avais demandé aussi, Pascal) pour surveiller mes serveurs et appeler un copain pour les remettre en route en cas de panne !

Mais malgré cela, les seuls mails que j'ai constatés avoir perdu sont ceux en provenance du webmail d'Orange. Cela dit, rien ne prouve qu'il n'y en ait pas d'autres que les utilisateurs ne m'aient pas signalés.

D'ailleurs, à ce propos :

arnaud056 a écrit :si mon serveur n'est pas opérationnel (et que je n'ai pas de second serveur de réception), le mail ne va-t'il pas revenir à l'expéditeur accompagné d'un message d'erreur?? --> l'expéditeur s'il n'est pas trop neuneu saura que je n'ai pas reçu le message et réessayera ultérieurement (ou pas!)....

C'est la dernière solution la bonne ! Je n'ai jamais vu un expéditeur qui ne soit pas neuneu

(enfin... rarement !). La plupart prennent les avis de non-distribution pour du spam et les envoient direct à la poubelle sans les lire. Bon, c'est vrai qu'ils sont souvent en anglais, et que pour les non-anglophones au moins mail en anglais=spam. Ceux qui sont un peu plus malins et pourraient peut-être les voir ont réglé leurs filtres antispam pour rejeter tout mail qui n'est pas en français.

Vraiment, il ne faut absolument pas compter sur un renvoi : lorsque je m'étais penché sur le problème webmail orange, non seulement je n'ai pu avoir aucune aide de la part de mes correspondants, mais en plus je me suis aperçu que dans largement 2 cas sur 3, ils étaient persuadés que j'avais eu leur mail (je t'assure : il est dans les mails envoyés !). Très difficile de leur faire comprendre que lorsqu'ils ont donné une lettre au facteur, rien ne prouve qu'elle a été ou sera distribuée !

=> Accepte vite l'offre de sibsib

J'aurais aimé te faire la même hier soir, mais ma corde à linge (voir plus haut) ne me permet d'avoir qu'une bande passante réduite, que je réserve à mes clients...

par **jibe** » 08 Déc 2011 00:21

Franck78 a écrit :Pour les test de serveurs SMTP, c'est Thibaut :
http://www.pagasa.net/test-smtp/

Merci Franck ! Je n'avais plus l'adresse de son site sous la main...

Franck78 a écrit :Un serveur SMTP essaiera toutes les quatres heures pendant un deux ou trois jours (je sais plus) de joindre le SMTP du domaine récepteur. Quand on dit que SMTP est asynchrone (pas instantané) , c'est pas pour abandonner à la première anicroche

Ma mémoire d'Alzheimer me souffle 72h. Pas garanti, mais fort probable : je tiens certainement ça de quelque part. Cela dit, ce serait assez simple à vérifier. Mais j'ai encore plusieurs posts à lire...

par **jdh** » 08 Déc 2011 00:43

Pour la réception en interne des mails,

SME utilise qmail, Zentyal utilise Postfix comme iRedMail et peut-être ClearOS. (Les relais mail que j'ai mis en place utilisent Postfix).

Ce sont des serveurs smtp parfaitement connus et fiables, donc sans problème, surtout dans une distribution dédiée.

Sauf à faire manuellement une config très mauvaise, ils ne sont pas nativement open-relay et à considérer comme sûr.
Un professionnel fera forcément un test open-relay tel celui-cité.
(Il est assez sympa puisque qu'il explicite chaque tentative et est en français, merci Franck78).

Pour Postfix, on regarde attentivement les lignes "my_destination", "my_network", "smtp_client_restrictions", et quelques autres en suivant la doc française très pédagogique p.e. http://postfix.traduc.org/index.php/SMT ... EADME.html
Pour Qmail, il doit bien y avoir un équivalent.

AMHA les vraies difficultés sont la disponibilité 24/24 i.e. le MX secondaire, et le traitement des mails en général : la (les) machine(s) répond(ent)-elle en toutes occasions et sous toutes charges ?
(Pour une config manuelle, évidemment "l'ai je bien configuré ?)
(Si on a 2 sites avec chacune une SDSL, c'est gagné pour le MX backup !)

Pour Postfix, on gagne à lire (et relire) des install telles workaround.org (que je suis depuis plusieurs années) : il y a beaucoup d'informations pratiques sur la config de Postfix ! Par exemple, la page http://workaround.org/ispmail/squeeze/p ... strictions décrit, bien mieux que moi, pas mal de mécanismes de défense à mettre en oeuvre pour un relais mail ou un serveur de mail interne.

@sibsib, jibe : merci d'avoir rappelé que, si on choisit un hébergeur avec dns, web et mail, c'est quand même parce qu'il a 2 MX pour ses offres ! Donc on reçoit toujours ses mails, et à l'autre bout du monde, en vacances, on peut même utiliser le webmail de l'hébergeur !

NB : question subsidiaire (pour les bons élèves) : un MX secondaire doit-il faire du greylisting ?

par **arnaud056** » 08 Déc 2011 20:55

Merci bien pour les infos complémentaires et surtout à sibsib pour son aimable proposition

que j'accepte bien entendu volontiers

C'est très très collégial 8-)

Encore une petite info: gandi "offre" 5 bal avec le nom du domaine --> le fetchmail est utilisable comme solution de secours.

jdh a écrit :question subsidiaire (pour les bons élèves) : un MX secondaire doit-il faire du greylisting ?

Au risque de passer pour ce que je suis :oops:

, je réponds négativement à la question:
Si j'interprète bien les explications de wikipedia sur le greylisting, j'explique mon choix de la façon suivante:
- serveur principal MX_1 tombe en panne
- un email arrive au DNS qui ne peut donc le transmettre au MX_1
- l'email va être alors redirigé vers le MX-Backup MX_2
- MX_2 rejette l'email
- l'expéditeur qui n'est pas un spameur va poliment attendre avant de réitéré l'envoi
- MX_1 est entre-temps de nouveau en fonctionnement
- l'expéditeur réitère l'envoi
- MX_1 recoit le mail
- MX_2 ne recevra donc jamais le mail en question --> considère l'expéditeur comme un spammeur et traitera en conséquence les courriers ultérieurs qu'il recevra de sa part lors d'une prochaine indisponibilité de MX_1 --> faux positif

Autre raison:
- MX_2 refuse X fois un courrier
- à son redémarrage MX_1 (également greylisté) refuse à son tour Y fois le courrier
- l'expéditeur qui a donc vu son courrier X+Y fois refusé se lasse et abandonne --> le courrier n'arrivera jamais = ce qui serait arrivé sans MX_backup --> MX_backup inutile

Oui? Non? Alors pourquoi?

@+
Arnaud