摘要

  • RFC 1440 允许发送者在目标主机没有账号或登记的情况下，主动把非邮件文件送到接收守护进程。
  • NULL ACK 只确认一条命令；EOF 或连接关闭只界定传输结束，都不能证明收件人已经接收、打开或使用文件。
  • 文件进入共享暂存区后，容量、保留期、身份验证、收件人处置以及伪用户任务执行都属于接收端的独立责任。

先送到门房，再等真正的收件人

传统文件传输往往从取件一方开始：用户连接远端系统，提供访问身份，再要求存取某个文件。RFC 1440 把动作倒过来。Sender-Initiated File Transfer 也叫 Unsolicited File Transfer；这里的“未经请求”仅指接收方没有发起交易，并不表示文件一定不受欢迎。

设计者想到的是 NJE 和 BITNET 一类网络。在那里，文件可以作为非邮件对象送给另一名用户，不必进入邮件用户代理。RFC 用包裹而不是信件作比喻。发送者无需在目标主机拥有账号，收件人也可以等到以后再取。

少一步并不等于少一份工作。发送端变得轻便，接收端却必须常驻监听、识别本地收件名、判断容量、保存等待中的对象，并在无人处理时清理。状态没有消失，只是从发送者会话搬到了接收者的基础设施里。

一条连接里有两份材料

UFT 守护进程监听 TCP 608 端口。同一条 socket 先接收 ASCII 命令，再接收二进制数据。RFC 把整个作业流解释为控制文件和数据文件的串接。它们一起运输，却不能混成同一个对象。

FILE 声明发送者、大小和可选的认证票据；USER 指向本地用户或服务；TYPE 说明表示形式。三者必须在 DATA 之前出现。NAME、DATE 和记录格式参数可以补充说明。EOF 结束当前文件，ABORT 要求丢弃不完整对象，QUIT 结束全部工作。

接收端可以把命令序列和数据体分开保存，从而避免 TCP 监听进程立即理解陌生格式。但这样做会产生新的完整性责任：哪套命令属于哪段数据、实际写入多少、最后采取了什么处置，都必须保持关联。

一个零字节只回答一个问题

正向确认极其简短：响应包以数值为零的字节开头。这个 NULL ACK 只承认一条命令。它不是整个交易的合格证。

FILE 的大小用于回答“有没有地方放”，而且允许是近似值。服务器可能先接受 FILE，随后发现 USER 不存在；也可能接受所有元数据，却在写数据时耗尽空间。最初的容量判断只是当时基于声明值的准入判断，不能预先证明后续每个字节都能落盘。

服务器连接后还会发送包含主机名、UFT 版本和软件版本的问候语。它可用于同步和协议级别协商，却不是经过认证的主机身份证明。FILE 中的 auth 明确尚未实现，RFC 直接说明协议没有保证认证。

暂存区开始了另一只钟

到达的文件会进入一个共享区域，示例路径是 /usr/spool/uft。它在那里等待收件人接收或拒绝，也可能因超龄而由系统删除。“public”在这里表示共用空间，不表示任何人都能访问；最大文件和保留多久由本地管理决定。

因此至少有三条时间线。网络传输有结束时间；主机托管有起止时间；收件人的决定另有发生时间。三者可能相隔很久，也可能第三件事永远不发生。

超龄删除不是收件人的拒绝。对象从暂存区消失也不能反推已经被使用，因为清理、隔离、错误和主动拒绝都会造成同样表象。只有带主体、时间和结果的处置记录才能回答。

RFC 建议在收件人行动前尽量少处理数据体。无法理解的类型应当按二进制保留。这维护了原始表示的选择空间，却不能证明文件没有损坏、没有危险或适合任何程序。

分段长度也是控制点

普通 DATA 命令带一个 burst-size。服务器精确读完这批字节后回到命令模式。一个文件可以分成多批，一条连接也能继续传多个文件。在批次之间，协议重新获得确认、终止或继续的明确边界。

“大胆者”可省略长度进入快速模式。此时接收端一直读到客户端关闭连接，不再发送 EOF 或 QUIT；数据流中也无法使用 ABORT。连接关闭同时承担了数据分界和会话终止两项含义。

减少往返换来的不是抽象速度，而是更少的回退机会。正常结束和意外断线呈现相同信号。若没有声明量、实收量、校验值和关闭原因，socket 的结束状态不足以证明对象完整。

收件名有时是一台执行机器

USER 可以不是人，而是软件服务引擎，例如用伪用户表示的作业入口队列。这使得暂存文件可能成为自动化输入。

但名字能解析不代表有权执行。发送者身份、提交权限、格式验证、资源配额、隔离、调度、实际执行和结果证据仍需逐层决定。监听器接受 USER，只能证明本地命名规则当时认识这个目标。

这条边界尤其重要，因为 RFC 没有提供完整的安全方案。认证票据未实现，安全问题也没有讨论。取消发送者账号要求降低了摩擦，同时把信任判断留给了实现者。

借邮件通行，会换一套证据

有些主机没有直接 IP 连接，有些不愿再运行守护进程，防火墙也可能只允许邮件。RFC 1440 因而允许把 UFT 装进 MIME：命令成为 application/octet-stream 的参数，数据体经 Base64 编码后进入邮件。

MIME 解决的是表示和运输。它不会把邮件路径的到达变成 UFT 收件人的接收。证据结构也随之改变：直接 TCP 有问候语、逐命令 ACK 和数据批次；邮件有存储转发节点，并依赖邮件系统可能提供的认证。RFC 明确把后一种认证交给邮件系统。

这仍是一项实验协议。RFC 1499 后来仍以 Experimental 概括它；今天 IANA 仍记录 sift-uft 与 608 端口。文档状态和注册记录只能证明标准档案存在，不能证明现实部署或普及程度。

把“送达”拆回动词

RFC 1440 最值得保存的不是胜负，而是一串各有主人的动作：发送者发起，监听器准入，主机收取，暂存区保管，收件人接收或拒绝，程序也许随后处理。前一层不能替后一层说话。

可靠记录应当保留传输对端、问候语、每条命令及其 ACK、声明与实收大小、类型、数据体哈希、暂存完成时间、保留期限、收件人查找、处置事件和应用结果。只写一个“已送达”，就会让最便宜的信号夺走它从未拥有的权威。

来源