Résumé

  • Hetzner applique le blocage des ports mail par compte : un serveur transféré vers le projet d’un autre propriétaire relève des règles de celui-ci.
  • Un mois de relation client et le paiement de la première facture permettent de demander le déblocage des ports 25 et 465 ; ils ne constituent pas une approbation automatique.
  • Le port 587 vers un service externe est une solution documentée, mais sa disponibilité ne garantit ni l’acceptation par ce service ni l’arrivée du message.

Ce que la réception du serveur ne dit pas

Une agence pourrait remettre à son client une application qui dépend de courriels. Le serveur apparaît dans le projet du client et la liste des actifs est correcte. Ce scénario hypothétique ne suffit pourtant pas à prononcer la fin du travail. La FAQ des serveurs Cloud de Hetzner précise que le blocage des ports est appliqué par compte. Après transfert vers un projet appartenant à un autre compte, les règles du nouveau propriétaire s’imposent.

Il ne s’agit pas du récit d’une panne. Si le destinataire dispose déjà des autorisations nécessaires, la différence peut ne causer aucune interruption. Sinon, le fait que l’application ait envoyé des messages chez l’ancien propriétaire ne prouve pas qu’elle possède la même voie chez le nouveau. Hetzner demande explicitement de vérifier les ports 25 et 465 du destinataire avant un transfert qui les utilise.

La qualification importante porte donc sur le compte, pas sur l’âge du serveur. Une ressource existante conserve une histoire technique, mais cette histoire n’est pas un titre permettant de transmettre une exception accordée à une autre partie. Confondre les deux transforme une opération d’infrastructure en preuve d’acceptation de l’application.

L’accès au projet n’est pas sa propriété

La FAQ générale Cloud décrit un transfert vers un autre compte par déplacement dans un projet que possède ce compte. Le destinataire crée le projet et invite le propriétaire actuel, qui déplace la ressource. Le guide de migration des produits expose l’échange d’un serveur Cloud dans sa propre rubrique.

Ces étapes rendent nécessaire la distinction entre collaboration et propriété. Inviter une personne dans un projet ne change pas automatiquement le compte propriétaire. La FAQ distingue les rôles, réserve la sortie des ressources au propriétaire du projet source et attribue la facture au propriétaire du projet. L’équipe doit donc savoir quelle opération change réellement la partie qui gouverne le serveur.

Il faut également conserver le périmètre produit. Les procédures relatives aux serveurs dédiés dans Robot, aux domaines ou à d’autres services ne démontrent pas que les règles mail du Cloud puissent être conservées ou contournées. Une procédure connue sur une autre offre ne vaut pas autorisation pour celle qui est transférée.

Une demande recevable n’est pas une permission

Hetzner motive le blocage par défaut des ports 25 et 465 par la lutte contre les envois abusifs et les fraudes. Sa FAQ anglaise donne deux conditions pour demander une exception : un mois comme client et le paiement de la première facture. Il faut présenter un usage valable, et la décision reste individuelle. La FAQ allemande décrit elle aussi un examen, non une libération automatique.

L’acheteur doit séparer l’éligibilité, la demande et son approbation. Une facture réglée n’est pas un reçu de déblocage. Le passé opérationnel du serveur n’établit pas que le nouveau compte a franchi les mêmes étapes. Rien dans les documents examinés ne transmet cette autorisation avec la machine.

La FAQ générale explique par ailleurs que les demandes de limite sont traitées manuellement pendant les heures ouvrables. Les sources ne donnent pas de délai garanti pour cette décision sur les ports. Un calendrier de remise fondé sur une réponse immédiate ou automatique ajouterait donc une hypothèse non établie.

La logique économique est compréhensible sans mesurer un résultat de sécurité. Une capacité de calcul facilement accessible peut servir une application légitime ou un expéditeur abusif. Le coût de l’abus touche des destinataires et d’autres opérateurs, pas seulement l’acheteur du serveur. Le contrôle par compte permet de considérer la partie qui reçoit l’autorité, plutôt que l’existence d’une machine facturable.

Le port 587 déplace la dépendance

Hetzner documente une autre possibilité : utiliser le port 587 vers un service externe d’envoi, sans cette demande de limite. Le port n’est pas bloqué selon la politique publiée. Ce choix peut modifier un projet légitime, mais il ne consiste pas nécessairement à remplacer un nombre dans une configuration de relais direct.

RFC 6409 sépare soumission et relais des messages et réserve 587 à la soumission. Le service externe introduit sa propre relation d’autorisation. La disponibilité réseau ne prouve pas que l’application y est acceptée, encore moins que le message atteindra la boîte du destinataire.

Deux arrangements doivent donc rester distincts : conserver une voie directe soumise aux règles du compte d’arrivée, ou établir une dépendance de soumission externe prise en charge. Ils répartissent différemment le travail et le contrôle. Les sources examinées ne fournissent ni comparaison de prix ni résultat de délivrabilité permettant de proclamer une solution universellement meilleure.

Ce n’est pas un conseil de contournement par un relais dissimulé ou un proxy. L’alternative officielle constitue un autre service à organiser. Son intérêt est de rendre la dépendance visible, non de faire croire que l’autorisation de l’architecture d’origine serait devenue sans importance.

La ressource facturée et le service prêt

La FAQ de facturation Cloud précise qu’un serveur créé reste facturable tant qu’il existe, même éteint. L’arrêt n’est donc pas une suspension générale des frais de cette ressource pendant l’attente. Ce constat n’est ni une recommandation de supprimer un serveur client ni un calcul de pertes.

Il rappelle qu’une capacité peut être achetée sans être entièrement mise en service pour son application. Le serveur peut être présent et facturé alors qu’une permission nécessaire reste ouverte. L’investissement doit conserver cette possibilité sans inventer un délai, une somme ou une fréquence de refus.

La conclusion est ciblée : le transfert établit où se trouve la ressource et qui la possède, pas que l’autorité mail de l’ancien compte l’accompagne. La remise doit examiner le compte destinataire et la dépendance de messagerie choisie. Un inventaire peut être complet tandis que cette preuve demeure incomplète.

Sources