Salut,
jdh a écrit :Est ce parce que c'est plus intéressant intellectuellement qu'il faut prendre le risque de louper quelque chose ?
Certes non ! D'ailleurs, si je défends un peu plus la solution de réception locale directe, j'ai bien précisé que c'est avec SME qui résoud facilement certains problèmes que tu soulèves très judicieusement (par exemple en ce qui concerne l'open relay, ou simplement le fait d'avoir à laisser le serveur mail allumé 24/7, obligation remplie pour une SME qui héberge un site web).
J'aurais dû préciser plus clairement dans quel cadre je parlais : désolé, je n'ai pas fait attention que nous n'étions pas sur le forum SME
Si j'ai insisté, c'est surtout que je pense qu'Arnaud056 aime expérimenter, aime les solutions "intellectuellement intéressantes" et surtout fait tout ça sur SME.
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 !
jdh a écrit :La solution 1 [...] semble même agaçante parce qu'on ne reçoit pas les mails instantanément mais sous 2'30 en moyenne !
Comme tu le dis si bien plus loin, smtp n'est pas un protocole de messagerie instantanée. Il n'est pas rare que certains mails mettent plusieurs minutes, voire bien plus, pour parcourir le circuit entre l'expéditeur et la boite mail du destinataire. Alors, effectivement, que sont 2'30 ou même 5' pour la récupération dans la boite hébergée à l'extérieur ?
L'utilisation de SMTP pour des besoins de discussion immédiate sur des documents venant d'être envoyés est une erreur : même si dans bien des cas les mails sont acheminés très rapidement, rien ne le garantit et la solution choisie n'est donc pas du tout en adéquation avec le besoin ! Et donc, là encore, les 2'30 ajoutés en moyenne sont négligeables si la solution est adaptée aux besoins.
jdh a écrit :J'ai juste un peu oublié de parler d'ip fixe pour la solution 2 :
sans ip fixe, comment faire hors d'un nom dynamique peu professionnel ?
(même si un MX est nécessairement un CNAME)
Me trompe-je ?
Je ne suis pas sûr de bien comprendre la question ? Je suppose que tu veux dire qu'avec une ip dynamique, on est obligé de passer par un prestataire de DNS dynamique qui va proposer un nom de domaine du genre tartempion.ipdynamic.com (en fait, un sous-domaine d'un de ceux appartenant au dit prestataire) ?
C'est vrai que, même si les noms de domaine sont assez bien choisis, ça ne fait quand même pas "pro". Quoique, entre
masupersociete@orange.fr et
service-commercial@masupersociete.societesuper.com, le second me semble quand même meilleur (bien qu'un peu long)
Mais bon : pour 12€ annuels et des bricoles, je peux avoir masupersociete.fr, et donc des adresses du type
service-commercial@masupersociete.fr. Y compris (et je crois que c'était là ta question ?) avec une IP dynamique : en effet, si le registrar permet de choisir les serveurs DNS (c'est le cas chez GANDI, et comme j'en ai toujours été content je n'ai jamais changé de crèmerie) et que le prestataire de DNS dynamique autorise à utiliser les siens (ça me semble la moindre des choses ! En tous cas, dyndns (une autre crémerie que je n'ai jamais jugé utile de changer) le fait), on peut utiliser son nom de domaine avec une IP dynamique. C'est ce que je pratique avec bonheur depuis longtemps, tant pour moi que pour mes clients.
Par contre, il peut peut-être y avoir un problème au moment du changement d'@IP. On imagine la scène : on commence le dialogue SMTP avec masupersociete.fr qui a l'adresse 123.132.231.213, et au cours de la procédure, l'adresse change ! Pire, même : 123.132.231.213 est affectée à Mme Michu dont le notebook tout neuf sous Cévennes Home Edition est infesté par un virus faisant office d'open relay ! J'avoue que je ne sais pas trop ce qui se passe dans ce cas, mais en toute logique la transaction va avorter (comment un serveur SMTP pourrait-il comprendre et accepter une transaction débutée ailleurs ?), et un nouvel essai va être tenté, cette fois avec la nouvelle (et bonne) adresse.
En tous cas, je n'ai jamais constaté le moindre problème.