Hetzner 服务器转移与账户级邮件权限

摘要

设想一家服务商把需要发送通知邮件的应用交给客户。服务器已经转到客户项目，资产表写上了正确的新主人。这个假设场景仍有一个不能略过的问题：Hetzner 云服务器问答明确说明，邮件端口的阻断按账户执行；转到另一账户的项目后，机器受新账户规则约束。

这里没有报告客户事故。若接收账户已经开放应用所需端口，区别未必造成任何中断。若尚未开放，旧主人曾经成功发送邮件，就不能证明新主人享有相同路径。对于使用25和465的服务器，官方要求在转移前确认新所有者已经解除相关限制。

这使服务器年龄不再是关键证据。机器可以带着软件和运行历史进入另一个项目，却不能用这些历史替新账户证明一项运营商授予的例外。基础设施的转移动作完成，与应用依赖已经可用，是两个需要分别验收的结果。

Hetzner 云服务通用问答把跨账户转移描述为：接收方建立自己所有的项目，邀请当前所有者，后者将资源移入。产品迁移说明也为云服务器单独列出交换步骤。它不是笼统地把一项访问邀请当成所有权更换。

协作权限与所有权因此必须分开。某个人能够看见或管理项目，并不意味着项目已经归其账户所有。通用问答区分成员角色，说明只有来源项目的所有者能够把资源移出，并由目标项目所有者承担之后的资源费用。交接需要弄清的是哪一步改变了机器归属，而不只是哪些人获得了界面访问。

产品范围也不能混用。Robot 下的独立服务器、域名或其他服务有自己的移交说明；这些说明不证明云服务邮件端口规则能够绕开，或当然继承给接收方。熟悉另一类产品的流程，不能代替当前资源的授权边界。

Hetzner 将默认阻断25和465解释为防止垃圾邮件与欺诈。英文问答说明，客户关系满一个月、支付首张账单后，可以就有效用途提出解封申请，决定逐案作出。德文问答同样描述单独审查，而不是自动开放。

三个状态不能相互替代：符合公布条件、已经提交申请、申请获准。已付账单不是端口开放回执；旧账户的获准历史，也不是新账户已获例外的凭证。本次查阅的政策没有说明这些条件可以借由一台旧服务器的历史传给新主人。

通用问答还说明，额度请求在工作时间人工审查。它没有给这项邮件端口决定提供保证完成时限。把交接计划建立在“马上批准”或“付钱后自动开放”上，便是在官方说明之外补出一项时间承诺。

这个控制有明确的激励背景。容易取得的计算资源同时服务合法应用与滥用发送者，滥用的后果却部分由收件人和其他网络承担。按账户审查，使运营商面对的是获得权限的主体，而不只是一个可以开账单的机器对象。这是对政策结构的解释，不是本次测量了它阻止多少垃圾邮件。

Hetzner 列出的另一条路，是通过外部邮件投递服务使用587，不需要提出上述额度请求；按公开政策，该端口没有被阻断。对合法应用，这可以改变部署选择，却不等于把直接投递配置里的数字换成587，就会保留原来全部工作方式。

RFC 6409区分邮件提交与邮件转送，并把587用于提交。外部服务引入了自己的授权关系。网络端口可用，不证明服务已经接受该应用，也不证明接收方最终把消息放进收件箱。

采购与交接应比较两种安排：保留受新账户规则约束的直接路径，或建立由外部服务承接的提交依赖。工作与控制可能由不同主体承担。本次材料没有提供可比价格、服务额度或送达成绩，不能宣布哪一种一律更便宜、更安全。

这也不是借代理或隐蔽路由规避控制的建议。官方替代方案是一项不同的服务关系。它的价值在于把依赖说清楚，而不是假装原来架构里的账户许可已经不重要。

云服务计费问答说明，创建完成的服务器只要仍然存在，就继续计费，包括关机状态。因此，关机不是等待期间暂停该资源费用的通用按钮。这只是有边界的计费事实，不是建议删除客户服务器，也没有算出迁移损失。

它提醒买方，取得容量与把应用投入服务不是同一个里程碑。资源可以已经存在、已经承担费用，某项必要权限仍待确定。投资文件应承认这种可能性，而不虚构等待天数、损失金额或被拒概率。

结论并不否定跨账户转移，而是限制它能证明什么。Hetzner 云服务器成功移交，说明资源到了哪里、由谁所有；它没有证明旧账户的邮件权限一起到了。验收应面对目标账户与实际采用的邮件依赖。机器清单能够证明机器，不能独自证明服务。