要約

  • Hetzner はメールポート制限をアカウント単位で適用する。別アカウント所有のプロジェクトへ移したサーバーは新所有者の規則に従う。
  • 顧客になって一か月が経過し、最初の請求を支払うと、25と465の解除を申請できる。条件を満たすことと承認は別である。
  • 外部メールサービスへの587利用は公表された代替案だが、ポートの利用可能性はサービスの受け入れや受信箱への到達を保証しない。

引き渡し完了の意味をそろえる

制作会社がメール送信を必要とするアプリケーションを顧客へ渡す場面を考える。サーバーは顧客のプロジェクトに現れ、資産台帳も新所有者を示す。これは仮定の場面であり、確認された障害ではない。だが、完了を判断するには Hetzner の Cloud サーバー FAQにある境界が重要になる。メールポートの制限はアカウントに適用され、移転後は新所有者の規則が有効になる。

移転先に必要な許可が既にあれば、違いが中断を起こすとは限らない。許可がなければ、旧所有者のもとで送信できたことは新所有者の経路の証拠にならない。25と465を使う場合、公式説明は移転前に新所有者の解除状態を確かめるよう求めている。

したがって、古いサーバーであること自体は答えにならない。機器の稼働履歴と、事業者がある利用者に認めた例外は別だ。インフラの所有権操作を、アプリケーション依存の利用準備まで証明する結果として扱うことはできない。

プロジェクトに参加できることと所有は違う

Cloud 全般の FAQでは、別アカウントへの移転を、そのアカウントが所有するプロジェクトへの資源移動として説明する。受取側がプロジェクトを作成して現所有者を招待し、現所有者が資源を移す。製品移行の説明にも Cloud サーバーの交換手順が独立して記載されている。

この手順は、共同作業への参加と所有を区別する。プロジェクトへ招待された人が管理できても、それだけで所有アカウントが変わるわけではない。全般 FAQ は役割を分け、移動元から資源を出せるのはそのプロジェクトの所有者であり、移動先の所有者が以後の費用を負担すると説明する。

引き渡すチームが確認すべきなのは、誰に画面アクセスがあるかだけではなく、どの操作が支配する所有者を変えるかである。他の製品の経験も、その確認を代行しない。Robot の専用サーバーやドメインの移行手順を、Cloud のメール許可の引き継ぎ根拠にすることはできない。

申請できることは、許可されたことではない

Hetzner は25と465の既定の遮断を、迷惑メールや詐欺への対策と説明する。英語 FAQ は、顧客関係が一か月続き最初の請求を支払った後、有効な用途を示して解除申請できるとしている。判断は案件ごとだ。ドイツ語 FAQも個別審査を示し、自動解除とは説明していない。

公表条件を満たすこと、申請すること、承認されることを分ける必要がある。支払い済み請求は解除証明書ではない。旧アカウントで動いた機器の過去も、移転先が許可された証拠ではない。確認した方針には、機器の歴史によって新所有者へ条件が移るという説明がない。

全般 FAQ は、制限変更の申請を営業時間中に手作業で審査すると説明している。このポート判断について保証された完了時間は示されていない。すぐに承認される前提で引き渡し日程を確定すれば、資料にない時間の約束を計画へ加えることになる。

その裁量には経済的な背景もある。容易に調達できる計算資源は、正当な用途にも悪用にも使える。悪用の影響の一部は受信者や他のネットワークが負う。アカウント単位の管理は、請求できる機器の存在よりも、権限を受け取る主体を評価する仕組みとして読める。ただし、ここで防止効果を測定したわけではない。

587は依存先を変える選択

Hetzner は外部メール配送サービスへ587で送る方法を、当該申請が不要な代替案として示している。公表方針上、このポートは遮断されていない。正当な運用計画を変える余地はあるが、直接送信の設定に別の数字を入れれば同じ構成になるという意味ではない。

RFC 6409はメッセージの提出と中継を区別し、587を提出用に位置付ける。外部サービスを使えば、そのサービスとの認可関係が加わる。ネットワーク上で使えるポートは、アプリケーションが受け入れられた証拠ではなく、受信箱への到達保証でもない。

移転先アカウントの規則に従う直接経路を維持する案と、外部提出サービスを組み込む案は、仕事と管理を別々に配分する。確認した資料に比較料金、サービス枠、配送結果はない。一方が常に安価または安全だとは判断できない。

これはプロキシや隠した経路で規則を回避する提案でもない。公式の代替案は別のサービス関係である。誰が提出を認め、誰が運用するかを明確にするための選択であり、元の構成の許可問題を消すための言い換えではない。

課金された資源と使えるサービス

Cloud の請求 FAQによれば、作成済みサーバーは存在する間、電源を切っていても課金対象になる。待機中に停止すれば、その資源の料金を一般的に止められるわけではない。この事実は顧客機器の削除勧告でも、移転損失の計算でもない。

容量の取得とアプリケーションの稼働準備は、別の節目だとわかる。資源が存在して費用を伴っていても、必要な許可はまだ未解決という場合を想定できる。投資判断はその可能性を残せばよく、待機日数、損失額、拒否率を作る必要はない。

結論は移転を否定するものではない。何が証明されたかを限定するものだ。Hetzner Cloud サーバーの移動は、新所有者と資源の所在を示す。旧利用者のメール許可が一緒に移ったことまでは示さない。引き渡しは移転先アカウントと選んだメール依存について判断すべきであり、サーバー台帳だけでサービスの準備完了とはできない。

出典