champ MX - nom du serveur de mails - SME Server

[frankyc278]

Bonjour à tous,

J'ai installé une distribution SME server dans une association qui dispose déjà d'un nom de domaine.

Le serveur web de cette association est hébergé par francetelecom.

Le champ MX correspondant au domaine pointe bien sur notre adresse IP fixe.

Quant au champ Adresse, il pointe sur l'IP du serveur qui héberge notre site web.

Mais, au niveau du champ MX, le nom du serveur de mails est mailhost, alors que sur SME il est identifié par mail.

Lors de tests d'envoi de messages sur des domaines comme wanadoo (orange) ou noos; le mail passe et arrive à destination.

Mais lors de l'envoi sur des domaines comme gmail.com ou hotmail.com, une erreur est signalée, par le mailer-daemon :

"Hi. This is the qmail-send program at xxxxx.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<hhhhhhh@hotmail.com>:
Connected to 65.54.244.8 but sender was rejected.
Remote host said: 550 Your e-mail was rejected for policy reasons on this gateway. Reasons for rejection may be related to content such as obscene language, graphics, or spam-like characteristics (or) other reputation problems. For sender troubleshooting information, please go to http://postmaster.msn.com. Please note: if you are an end-user please contact your E-mail/Internet Service Provider for assistance.

<ggggggg@gmail.com>:
209.85.135.27 failed after I sent the message.
Remote host said: 550-5.7.1 [mon.adresse.I.P] Our system has detected an unusual amount of unsolicited
550-5.7.1 mail originating from your IP address. To protect our
550-5.7.1 users from spam, mail sent from your IP address has been
550-5.7.1 rejected. Please visit
550-5.7.1 http://www.google.com/mail/help/bulk_mail.html to review
550 5.7.1 our Bulk Email Senders Guidelines. w5si3754361mue

--- Below this line is a copy of the message.

........"....puis suit le message envoyé.

A priori, ce sont les "processus" de certification, de signatures, de vérification d'identité qui invalident l'envoi et protègent les destinataires.

Je pense que ça vient du fait qu'au niveau du champ MX, on a mailhost.xxxxx.com au lieu de mail.xxxxx.com

Bravo, pour les méthodes (Caller-ID, SPF, DomainKeys.....) d'Anti-spam, mais je ne suis pas un spammeur!!!

J'ai fait une demande au service Orange Business, resté pour l'instant lettre morte.
Il faut dire que ça date de ce matin !

Mais, il me semble que cette modification sur le serveur DNS est relativement rapide !!!


Merci pour votre analyse,

Frank

[jdh]

Les mêmes causes donnent les mêmes problèmes !


Je pense qu'il est largement préférable de disposer d'un nom de domaine, de l'hébergement du site web, de l'hébergement des boites mails chez un hébergeur pro.

Il est assez facile de trouver des offres pour moins de 5€/mois avec nom de domaine, site web avec multiples bases de données, boites (jqa 200) chez les habituels Amen, 1et1, Ovh, .... (et j'en oublie).

Une fois cette offre choisie, un serveur de mail local (avec un DNS bricolé en local = le MX est ici au lieu de celui sur Internet) et un fetchmail automatique.

Tout cela fonctionne vite et bien.


Pour moi la mauvaise solution c'est d'héberger ses mails en local avec un FAI usuel genre Wanadoo/Orange. C'est AMHA une fausse bonne idée.

1er point mauvais : on règle de pair d'envoyer en direct alors qu'il FAUT passer par le smtp du fournisseur.
2me point mauvais : on configure plus ou moins bien le MX du domaine = @ip fixe fournie par le FAI, puis on comprend plus ou moins bien comment faire le renvoi de port sur le routeur ou le firewall.


Le premier message est clairement le premier cas : envoi de mail en direct = refus car @ip issues de range ADSL. J'ai donné la solution.

Le deuxième message est du même cas avec toutefois une nouveauté : le message fait comprendre que l'@ip est blacklistée.


Bref utiliser le relais smtp de Orange !

[fraedhrim]

[1/2 TROLL]

Pour moi la mauvaise solution c'est d'héberger ses mails en local avec un FAI usuel genre Wanadoo/Orange. C'est AMHA une fausse bonne idée.

Hoak ! Le débat éternel ! Tout dépend de tes enjeux. Si c'est pour faire du pro avec commerce et tout effectivement il y a risque.
Si c'est pour toi à titre perso et que tu es un bricoleur alors pourquoi pas. Quel est le risque ? D'autant qu'en général ton provider de domaine te permet soi d'heberger chez toi soit de faire des redirectiosn donc en cas de gros pépin d'accès Internet en 2 temps 3 mouvements tu bascules tout sur une boîte externe.
Pour une asso ça passe aussi.
Tout dépend de ses ambitions et de ses moyens.

Si on applique ce principe on ne fait plus rien... On ne maitrise plus rien. On ne comprend plus rien.
Et on a des emails en @hotmail.com......

[/ 1/2 TROLL]

[jdh]

Salut Fraedhrim.

Je parle d'expérience.

Je me suis occupé (moi-aussi) de l'informatique d'une asso (ici à Nantes). Le domaine est chez Gandi. Il y a un renvoi du www vers le site web perso correspondant au compte ADSL chez Free. De même il y a des renvois de mails vers des boites (gratuites) toujours chez le FAI.

Le serveur de mail interne (une Debian avec Postfix+MySQL !) récupère automatiquement les mails (avec fetchmail) et, pour l'émission, le "relayhost" est bien sur le smtp du FAI. Cela fonctionne tout à fait correctement (comme prévu).

Bien sur, pour la mise en oeuvre, j'ai testé le tout sur mon propre fw/serveur personnel. Et bien sur, j'ai testé aussi la réception directe (pour le domaine "dynamique" correspondant à mon @ip dynamique). J'ai reproduit (et je reproduis) la même chose pour plusieurs PME.

Je suis absolument POUR l'expérimentation car c'est comme cela que l'on apprend. C'est évident. (Mais il faut la curiosité pour observer TOUT ce qu'il se passe). Bien au contraire, essayez mais tracez et surtout analysez vos différents essais.

Le problème, c'est qu'il n'y a pas toujours le soin nécessaire à faire cela proprement et sûrement : il y a beaucoup à faire : open-relay, config MX, lutte contre le spam, lutte contre les infos cachées, ...


Mais en prod pour une entreprise ou même pour une asso, je recommande de ne pas héberger le MX de son domaine parce qu'il est, un, difficile d'assurer une disponibilité adaptée (24h/24h), et, deux, plus efficace de suivre la méthode que je soutiens.


Ici j'ai donné une interprétation des messages d'erreurs. Et l'origine est (clairement AMHA) la non-utilisation du relais smtp du FAI.

Free "oblige" à utiliser son serveur smtp. J'espère que la plupart des FAI vont s'engager dans cette voie. Je regrette que, ceux qui essayent d'héberger leur MX, aient du mal à comprendre le côté nécessaire de cette mesure (destinée à lutter contre le spam).



(Pour les téméraires, j'encourage à TOUJOURS tester l'open relay et à installer au moins un "grey listing").

(Cela n'empêche pas l'utilisation d'un intranet dans le cas cité).

(Tu vois Fraedhrim, mon discours n'est pas que dogmatique mais plutôt explicatif !)

[jibe]

Salut,

Puisqu'on est dans ce débat, quid d'une solution intermédiaire ?

- Réception directe (le MX pointe sur la SME),
- Envoi relayé par le FAI.

AMHA - et je parle quand même d'expérience - le seul inconvénient qu'on puisse opposer est la disponibilité du MX. Mais d'une part des solutions existent (MX Backup par exemple, merci sibsib ) et d'autre part, SME est suffisemment fiable et stable pour que, derrière un onduleur, on n'ait que très peu de coupures et des temps d'indisponibilité qui restent généralement très courts... (voir le challenge de Grand-Pa qui est arrivé à un uptime d'un an, qui n'a pas été dépassé pour un problème de disque cassé ce qui est malgré tout assez rare au bout de seulement un an)...

L'avantage est qu'on a les mails en temps réel, et la totale maitrise des BALs...

[jdh]

Salut Jibe.

Ce n'est pas une solution intermédiaire.

Il FAUT utiliser le relais smtp du FAI quand on utilise une ligne ADSL.

Pourquoi ? Parce que de plus en plus de serveur mail (MX) refusent les mails émis à partir d'une @ip situé sur les range ADSL des FAI. Par exemple, Orange/Wanadoo attribue à ses utilisateur ADSL des adresses ip situé dans des valeurs connues, alors AOL.com refusera de recevoir des mails envoyés directement par une de ces adresses.

Pour quelle raison ? Parce qu'un micro ADSL peut être (facilement) corrompu et émettre du spam à tire-larigot tandis qu'un serveur mail installé sur des @ip issues de ligne pro du même fournisseur sont supposées être moins facilement corrompus.


En définitive, l'envoi DOIT être fait via le smtp du fournisseur pour limiter les refus de réception de mails.

Et on a ensuite le choix en réception : soit héberger son MX soit utiliser un serveur hébergé en pro et fetchmailer sur le serveur interne.

Il n'empêche, et tu seras d'accord avec moi Jibe, héberger son MX exige plus de compétences ou de s'appuyer sur une solution fiable (pourquoi pas SME ?). Parce que les risques sont grands, en cas d'inexpérience, que ce serveur deviennent un relais à spam.

Comme je l'écris, il y a 2 oppositions majeures : la disponibilité (tu la cites) mais surtout la meilleure efficacité de laisser faire via un pro ce qui n'est pas du tout couteux. Dans cette dernière solution, tu reçois les mails en temps presque réel (fetchmail à 5mn), et tu n'es pas vraiment limité ni en taille et ni en nombre de boites mail. (Pour moins de 5€/mois tu peux avoir jusqu'à 200 boites et 1000 alias : si tu mets en place une messagerie pour 150 boites ... tu n'utiliseras pas une simple ligne ADSL mais une ligne pro et tu hébergeras ton MX).

Pour continuer à citer des exemples concrets et réels, je travaille actuellement pour une PME qui héberge chez Orange sa centaine de boites et qui dispose de 2 lignes SDSL pro (à 10 fois le prix d'un ADSL). Le contrat prévoit que chaque ligne pro donne droit à 30 ou 40 boites gratuites. Donc l'entreprise paie par mois l'excédent de boites soit dans mon cas, une quarantaine de boites à 2,4€ /mois. Il s'agit de simples boites accessibles par POP avec antivirus/antispam, plus webmail, et limités à 20 Mo. Ce prix n'est pas un hasard : en gros, c'est le coût moyen d'une licence exchange sur 3 ans hors la licence serveur. Ce qui veut dire que l'on paie pour 40 boites (puisque les autres sont gratuites) le même prix que si c'était exchange ... sans avoir le moindre avantage d'avoir exchange ! (Si c'est un avantage d'avoir exchange !).

Dans le même temps, pour une toute petite PME, j'ai mis en place ma solution favorite. Sur le serveur interne (une Debian + Postfix + MySQL + Courier-Imap), j'ai ajouté un partage webdav (avec Apache). J'ai installé comme client (Mail en imap) Thunderbird et le complément Lightning comme agenda. Ce dernier sait stocker les évènements du calendrier sous la forme d'un .ics (format iCalendar) sur le partage webdav. Et par conséquent, j'obtiens un calendrier partagé (comme exchange). Il manque un OpenLDAP comme carnet d'adresses commun mais vu le faible nombre de boites internes, cela ne vaut pas le coup. En gros j'obtiens un "équivalent" très acceptable d'Outlook (d'Office) et d'Exchange hors OWA (et pas mal d'autres fonctionnalités). (Certes en ayant travaillé par moi-même).


AMHA, pourquoi les grands serveur de mails, qui refusent de recevoir à partir d'@ ip ADSL, ne finiront pas aussi par refuser d'envoyer à ces mêmes adresses ?

AMHA, quand on héberge soi-même son MX, cela oblige à disposer d'une @ip fixe, ce qui est une faiblesse. Et on doit soi-même gérer (lire supprimer) les inscriptions en blacklists type RBL de cette @ip ... au cas où.


En tout cas, merci de faire vivre les réflexions autour de cette problématique. (Je ne prétends pas apporter une solution universelle mais plutôt pratique).

[fraedhrim]

On est d'accord JDH. Je disais bien "Tout dépend de ses ambitions et de ses moyens.".
A titre perso si ton trip c'est de faire un serveur tout en un chez toi et que tu mesures bien les risques il n'y a plus de problème. C'est à ce niveau que je mettais le bemol.
A titre pro ou d'une asso qui n'a pas envie ou intérêt à prendre ce risque il est clair que ce n'est pas une bonne idée de faire en local sur un accès Internet "grand public".

A+

[frankyc278]

Merci, pour vos analyses très instructives.

J'ai donc configuré SME pour qu'il se serve du serveur SMTP du FAI comme relais.
Les tests sont concluants sur les domaines comme hotmail.com et gmail.com.
Testés à l'aide du webmail et par un client de messagerie (adresse ip du serveur pour le courrier entrant et sortant et utilisation de SMTPS (465) et POP3S (995) )

Depuis l'extérieur,
l'accès au webmail est assuré par https://mailhost.xxxxx.com/webmail
et non
https://mail.xxxxx.com/webmail

la configuration du client de messagerie est la suivante :

mailhost.xxxxx.com pour le courrier entrant (données SME Server)
smtp.xxxxx.fr (correspond aux données FAI) pour le courrier sortant
==> utilisation du serveur SMTP du FAI de l'utilisateur situé à l'extérieur du réseau de l'asso.

Et dans la même logique les protocoles utilisés correspondent aux caractéristiques du FAI pour le courrier sortant (ici, SMTP (25)) et à celles de SME Server pour le courrier entrant (toujours POP3S (995) (ce que j'ai choisi en premier test))

Tests OK.

Mais autre question, est-il intéressant de chercher à se faire "déblacklister" ou plus correctement enlever des blacklists ?

[jdh]

Sans me vanter, j'ai correctement lu les messages de retour en anglais !

Comme je l'écris, utilisez le smtp du fai n'est pas un choix, c'est une évidence, que dis-je une nécessité. Donc OK.

(A noter que ce n'est pas la garantie absolue, loin de là, mais une amélioration nette d'envoi de mails).

Je recommande de
- n'ouvrir que smtp (tcp/25) en entrant vers le serveur mail recevant les mails (ici une SME).
- de vérifier que l'ip n'est pas en open-relay (SME ne l'est pas SAUF modification manuelle !).
- ne pas ouvrir ni POP3 ni POP3S : préférer le webmail (SME en inclut-il un ?).
- n'ouvrir que http (http/80) en entrant vers un webmail qui accède aux mails en IMAP.
- d'ajouter un grey-listing au serveur de mail (objectif : limiter le spam).


(Enfin ça c'est pour les téméraires ... joke)

[fraedhrim]

En fait par rapport au deblacklistage le truc c'est que certains (dont moi) utilisent des blacklistes qui contiennent les IP des fournisseurs d'accès Internet grand public du monde (quasi) entier.

Donc tu ne peux pas vraiment te faire deblacklister si c'est dans un de ces blacklistes que tu te trouves.

:/

Cela dit quand on voit les bouses qu'on arrete avec ces blacklistes, perso, je ne suis pas pres de les enlever.
Et en perso comme au boulot je conseille à tout le monde utilisant un accès Internet "résidentiel" (grand public) d'utiliser le SMTP du FAI (avec les problèmes qu'on peut avoir avec Oléane). Parce que chez moi comme au boulot les relais de messagerie utilisent les RBL qui listes ces ADSL "perso" et c'est très bien comme ça...

[frankyc278]

Pour le webmail, j'ai forwardé le port correspondant au https (443) direction sme server.

SMTP ok / POP non

Mais j'avais aussi forwardé IMAPS et POP3S........quels sont les critères pour que je n'autorise que l'accès webmail ?
les utilisateurs sont parfois très attachés à leurs petites habitudes comme l'utilisation exclusive de tel ou tel client de messagerie !! que faire contre la volonté de cette masse ?


J'étudie pour le moment tes avis sur l'open-relay et les grey-list...

Quant au déblacklistage; dans le cas de l'asso., c'est un contrat pro avec IP fixe qu'ils ont.....

Merci

[frankyc278]

Pour vérifier le "blacklistage" de l'IP de notre serveur de courriers, j'ai utilisé le site suivant :

http://www.mxtoolbox.com/blacklists.aspx


voici un extrait du résultat :

We notice you are on a blacklist

Checking xxx.xxx.xx.xx against 127 known blacklists...
Listed: 23 time(s)
Timeouts:0

............

[jibe]

Salut,

En tout cas, merci de faire vivre les réflexions autour de cette problématique. (Je ne prétends pas apporter une solution universelle mais plutôt pratique).

C'était bien un peu le but de ma question
Merci et bravo pour ces explications convaincantes

Cela dit, nous n'avons pas tout à fait la même clientèle. La mienne (artisans, TPE...) comprend très mal (formule "politiquement correcte" pour signifier qu'on me prendrait pour un voleur !) qu'on puisse lui proposer une solution payante (même quelques euros/mois ! Ces gens-là sont souvent très près de leurs sous - ou c'est la mentalité montagnarde ? ). Alors, il me reste deux solutions :

- Les bals de leur FAI, avec un anti-virus/antispam parfois payant (je ne cite personne... je pense que tout le monde connait !) et un volume généralement limité (il m'arrive souvent de voir mes mails à certains clients ayant choisi cette solution refusés pour dépassement de quota...)
- Les bals que je peux leur offrir sur leur SME.

Je crois que dans un tel contexte, il n'y a pas photo ! Cela dit, dans ton contexte, il n'y a pas photo non plus

- ne pas ouvrir ni POP3 ni POP3S : préférer le webmail (SME en inclut-il un ?).

Oui, désactivé par défaut, mais très facilement activable par le server-manager. Peut être activé en interne (LAN) seulement, ou pour accès via internet.
POP3 et IMAP ne sont accessibles que depuis le LAN par défaut. Quels sont les inconvénients de les laisser dans ces conditions ?

les utilisateurs sont parfois très attachés à leurs petites habitudes comme l'utilisation exclusive de tel ou tel client de messagerie !! que faire contre la volonté de cette masse ?

Et si en plus il s'agit d'un client, il n'y a rien à faire : le client est roi ! Tout ce qui est possible, c'est s'arranger dans le contrat pour qu'il soit bien au courant des inconvénients... dont il n'a cure, pour lui ce sont ses habitudes qui comptent avant tout !!! Et si on n'en passe pas par ses caprices, il trouvera un concurrent qui se fera un malin plaisir à prouver qu'on a tort et que la meilleure solution pour lui est un serveur sous XP avec outlook express

Le mieux est parfois l'ennemi du bien !

Mais bon, heureusement, tous ne sont pas ainsi !