德国高等教育主权学生邮件的联邦化架构

德国高等教育机构约有280万名在校生。每个人都需要一个邮箱。大多数机构提供邮箱，但主流模式——约400个机构各自运营独立邮件服务器，或外包给商业云提供商——导致了碎片化、重复的运营开销，以及学生通信数据流出到德国司法管辖区之外。

本文探讨联邦化、开源架构是否能在德国联邦教育体系的约束下解决这些问题。本文不主张建立单一集中式平台，而是提出一个映射联邦结构的模型：每个联邦州设一个实例，保留高校自主权，并通过标准协议实现联邦化。本分析有意保持保守——成本以带假设条件的区间给出，而非精确断言。

联邦背景

任何关于德国高等教育全国性基础设施的提案都必须面对一个结构性现实：教育政策是各州的事务（Kulturhoheit der Länder，文化主权）。16个联邦州对其教育体系（包括高等教育）拥有主权。联邦政府（Bund）不能强制参与，这样的强制令也不可取——它将与基本法第30条和第70条的权限分配相抵触。

这不仅仅是法律技术细节。它影响着提案的每一个方面：

• 治理： 没有任何联邦机构可以强制推行统一邮件平台。参与必须是自愿的，在州层面组织，并通过现有的联邦结构协调。
• 数据保护： 每个州都有自己的数据保护机构（Landesdatenschutzbeauftragter，州数据保护专员）。一个跨越全部16个州的集中式方案需要满足多达16个独立的监管机构，加上联邦专员。联邦模型——每个州一个实例——将数据保留在各州管辖区内，受各州数据保护机构监管。
• 采购法： 德国的公共采购受欧盟指令和国家法律（VgV、UVgO）管辖。州级采购的实例遵循州当局已熟悉的采购规则。
• 高校自主权： 基本法第5条第3款保障研究和教学的自主权。大学不仅仅是其所在州的行政单位；它们拥有机构自主权。模型必须允许各机构自行托管，或作为州实例中的租户运行，由其自行选择。

DFN（Deutsches Forschungsnetz，德国研究网络）已经运营国家研究和教育网络以及DFN-AAI联邦身份基础设施。它是协调层的天然候选者——不是作为中央运营商，而是作为中立骨干，提供共享服务（网络连接、身份联邦、共享安全），供所有州实例在此基础上构建。

规模与当前支出

具体数字有助于奠定讨论基础，但应视为具有显著不确定性的估计。

指标	估计值	不确定性
高等教育机构	~400	包括大学、应用科学大学和其他类型
学生	~280万	随学期波动
邮件存储（仅邮件，1 GB/学生）	~2.8 PB可用	经归档和清理后
入站邮件（过滤前，100/邮箱/天）	~2.8亿/天	280万 × 100；60%在边缘被拒
当前总支出	4000万–8000万欧元/年	分散在约400个预算中；难以精确验证

邮件量需要澄清：280万个邮箱每天接收估计100条消息（合法邮件和垃圾邮件，过滤前），总计约2.8亿条/天，而非1亿条。其中约60%可在网络边缘被拒绝（无效HELO、DNSBL、SPF失败），无需内容扫描，剩余约1.1亿条进入后续处理。

当前支出是最难验证的数字，因为它分散在数百个机构的预算中，会计做法各不相同。每年4000万至8000万欧元的范围涵盖邮件和基本协作的许可费、人员和硬件。这是指示性的，而非权威性的。

联邦三层模型

所提出的架构有三个层级，每个层级映射到德国教育体系中现有的结构单元。

第一层——DFN共享服务（中立骨干）

DFN运营国家研究网络和DFN-AAI身份联邦。在此模型中，DFN提供惠及所有州实例的共享服务，但不直接运营任何实例：

• 网络连接（已就位）
• 身份联邦（通过DFN-AAI和eduPerson属性，已就位）
• 共享安全服务：DNSBL信誉、MTA-STS策略分发、DKIM/DMARC监控，以及跨所有州实例的威胁情报共享
• 协调：技术标准、互操作性测试，以及州IT组织的论坛

DFN不存储学生邮箱。它提供连接组织。这尊重了其现有角色，避免了创建新的中央机构。

第二层——州实例（每个联邦州一个）

每个联邦州运营自己的实例，服务于该州内机构注册的学生。小州（不来梅、萨尔兰）可以整合资源或与邻州共享实例，将实际运营实例数量减少到约10–13个。

州实例提供：

• 邮件（SMTP、IMAP、POP3、JMAP），含垃圾邮件和病毒过滤
• 文件存储（Nextcloud）
• 日历和联系人（CalDAV、CardDAV）
• 即时通讯（Matrix，联邦化）
• 协作文档编辑
• 单点登录，集成州的身份提供者，通过DFN-AAI联邦化

每个州实例由该州的IT组织（或指定服务提供商）在该州数据保护机构下运营。实例的规模针对该州的学生人数，而非全国总数。

第三层——高校自主权（租户或自托管）

在州实例内，每所大学作为租户运营——拥有自己的域名、用户管理和行政策略。偏好完全运营控制的机构可以在自己的硬件上部署相同的开源技术栈，并与州实例及其他机构联邦化。

这是保障高校自主权的关键设计决策：没有机构被强制使用州实例，参与的机构保留对其域名、用户和策略的行政控制权。

联邦化

三个层级通过标准协议连接，而非中央机构：

• SMTP：邮件天然联邦化——州实例上的学生可以给自托管机构的员工发邮件，双方都不需要离开各自的环境。
• Matrix：跨实例和自托管部署的联邦化即时通讯。
• CalDAV/CardDAV：跨机构边界的日历和联系人共享。
• Nextcloud联邦：州实例和自托管实例之间的文件共享。
• DFN-AAI：身份联邦——学生使用其机构凭据认证，通过其所属机构的身份提供者验证。

联邦化是取代集中化的机制。没有单一运营商持有所有学生数据。每个州控制自己的实例。每个机构控制自己的域名。互操作性由开放标准保证，而非中央机构。

成本估算

以下估算有意保守，区间反映了硬件定价、人员模型和存储分配的不确定性。它们涵盖联邦模型（州实例+DFN共享服务），而非单一集中部署。

单个州实例（3年TCO）

组件	下限	上限
硬件（邮件、协作、存储、控制平面）	80,000欧元	150,000欧元
机房和连接	45,000欧元	90,000欧元
运营（0.5–1 FTE，与现有州IT共享）	120,000欧元	225,000欧元
每实例（3年）	245,000欧元	465,000欧元

共享服务（DFN层级，3年TCO）

组件	下限	上限
安全基础设施（共享DNSBL、MTA-STS、监控）	100,000欧元	200,000欧元
协调和开发（3–5 FTE）	675,000欧元	1,125,000欧元
共享（3年）	775,000欧元	1,325,000欧元

总计（13个实例+共享，3年TCO）

方案	总计（3年）	每学生每月
下限（13 × 245,000 + 775,000）	~400万欧元	~0.04欧元
中间估计（13 × 355,000 + 1,050,000）	~570万欧元	~0.06欧元
上限（13 × 465,000 + 1,325,000）	~740万欧元	~0.07欧元

这些数字假设以邮件为主的部署（1 GB/学生）。如果包含协作存储（文件存储、版本控制、备份）按10–20 GB/学生，存储成本将大幅增加——可能使下限翻倍。迁移、培训和机构集成成本不包括在内，将在初始部署阶段额外增加。

作为比较，当前总支出估计为每年4000万–8000万欧元（三年1.2亿–2.4亿欧元）。联邦模型意味着总基础设施成本的大幅减少，尽管直接比较并不完美：当前支出包括机构间接费用（本地IT人员、单独采购、按机构许可），这些不会完全消除，但会通过整合大幅减少。

每学生成本约为每月0.04–0.07欧元（以邮件为主的部署）——比典型商业云许可低约两个数量级。这反映了大规模邮件的商品性质：存储和投递的边际成本非常低。主要成本不是基础设施，而是协调——这正是联邦模型旨在解决的问题。

技术基础

各组件已在生产环境中使用：

• Stalwart Mail（AGPL-3.0）：基于Rust的邮件服务器，提供IMAP、POP3、SMTP和JMAP，具有原生全文搜索。AGPL-3.0许可证确保修改保持开放；无法遵守AGPL条款的组织可获取商业许可证。
• Nextcloud（AGPL-3.0）：文件存储、共享和协作。
• Matrix/Element（AGPL-3.0）：联邦化即时通讯。
• Keycloak（Apache-2.0）：身份和访问管理，SAML/OIDC。
• 日历、联系人和视频会议的其他组件，通过容器原生打包（Kubernetes、Helm）和配置管理（Ansible）部署。

开源许可证是混合的（AGPL-3.0、Apache-2.0、MPL-2.0）。AGPL-3.0组件（Stalwart、Nextcloud、Matrix）要求通过网络向用户提供的修改必须在相同许可证下发布——这比Apache-2.0更强的copyleft，且增强了而非削弱了主权：修改软件的机构必须共享其修改，防止私有分支侵蚀公共资源。

大规模的技术挑战是运营编排——跨多个州实例配置邮箱、每天处理约2.8亿封入站邮件、保持响应迅速的IMAP性能。这些是具有已知解决方案的扩展问题；开源生态系统已在其他领域的可比规模上解决了这些问题。

治理

联邦模型需要联邦治理。拟议结构：

• 每个州在自己的数据保护机构（Landesdatenschutzbeauftragter）下运营自己的实例。没有中央机构持有学生数据。
• DFN提供共享服务并协调技术标准，在其作为中立研究网络组织的现有角色中运作。
• 协调机构（技术咨询委员会，由州IT组织和DFN组成）制定互操作性标准并管理共享安全服务。它不运营实例。
• 资金结合州预算（按学生人数比例）、机构对增强服务的自愿捐款，以及——如果可用——通过基本法第104b条的Digitalpakt式机制提供的联邦启动资金（联邦出资，各州执行）。现有的Digitalpakt Schule针对学校；需要为高等教育建立类似工具或重新利用现有的高等教育资金线。

各层面的参与都是自愿的。没有州被强迫加入。没有机构被强迫使用其所在州的实例。通过标准协议（IMAP、CalDAV）的数据导出始终可用。不存在供应商锁定：整个技术栈是开源的，AGPL-3.0许可证确保修改保持开放。

开放性问题与局限

本分析是一个起点，而非最终提案。若干问题需要进一步调查：

1. 成本验证。 上述估算基于单个组件的生产基准，外推到国家规模。一个概念验证部署——例如在单个州实例上30天内模拟5,000个邮箱——将验证容量假设并识别运营边缘情况。

2. 州级采纳。 模型假设各州自愿参与。实际上，每个州有自己的IT战略、采购规则和政治优先级。与三到五个不同规模的州进行试点将测试治理模型并揭示协调挑战。

3. 跨管辖区数据保护。 虽然州实例将数据保留在该州内，但跨实例联邦化意味着元数据（路由信息、日历共享）可能跨越州边界。在任何试点之前，应根据GDPR第35条进行数据保护影响评估（Datenschutz-Folgenabschätzung），评估联邦化元数据流。

4. 迁移。 从现有系统——商业云、机构邮件服务器或其他提供商——迁移约280万个邮箱是一项重大的运营工作。需要迁移工具、用户沟通和过渡期（并行运行）。

5. 小州。 不来梅（约20,000学生）和萨尔兰（约35,000）可能无法证明专用实例的合理性。需要定义整合安排（与邻州共享实例，或为小州提供DFN托管的实例）。

6. 实践中的高校自主权。 模型允许自托管，但自托管的大学放弃了州实例的成本优势。自主权与整合之间的平衡是每个机构的政治问题。

结论

为德国高等教育建立主权、联邦化的邮件和协作平台在技术上可行，在经济上合理。每学生成本是当前总支出的一小部分。开源技术栈消除了供应商依赖。数据主权通过设计实现——每个州在自己的管辖区内控制自己的实例。

联邦模型不是宪法约束迫使的妥协。它是建立在州主权、高校自主权和自愿合作基础上的系统的自然架构。每个联邦州一个实例，通过DFN协调，在分担商品服务运营负担的同时保留政治问责。通过标准协议的联邦化确保没有机构被孤立——州实例上的学生可以与自托管大学的员工自然协作，如同同一平台上的两个学生一样。

剩下的不是技术问题。而是协调问题：协调16个州的政治意愿、通过DFN建立治理、用试点验证模型。技术已就绪。联邦结构已就绪。经济性有利。下一步是对话。

---

延伸阅读

1. 配套文档。 详细的容量分析和治理模型可作为技术配套文档获取。
2. 评估技术栈。 开源组件可通过Ansible playbook在单个节点上部署进行评估。
3. 与州IT组织交流。 模型设计为自愿采纳；越多州IT组织审视这些数字，协调就能越快开始。

---

联邦化不是集中化。它是不放弃的协作。