后端通信【免费下载链接】maddy✉️ Composable all-in-one mail server.项目地址https://gitcode.com/gh_mirrors/ma/maddy点击查看免费下载本文是 maddy 邮件服务器出站投递安全体系的技术指南围绕 docs/seclevels.md 展开系统讲解 maddy 如何在服务器到服务器server-serverSMTP 场景下应对MX 记录认证与TLS 强制两大核心安全问题并深入剖析其安全等级Security Level与策略Policy的实现原理。读完本文你将掌握 maddy 的mx_auth策略组配置方法、min_tls_level/min_mx_level的取值与含义以及 MTA-STS、DNSSEC、DANE 各自能抵御何种攻击、又有哪些已知局限。一、安全 SMTP 面临的两类问题maddy 将出站投递安全拆解为两个相互独立的问题MX 记录认证MX record authentication与TLS 强制TLS enforcement。两者分别回答该把邮件发给谁和如何在传输中保证机密性与真实性。1.1 MX 记录认证DNS 不可信的根源当 MTA 需要向某个远端域名的邮箱投递邮件时它通过查询收件人域名的 DNS MX 记录来发现目标邮件服务器。问题在于DNS 本身没有任何密码学保护任何恶意攻击者理论上都可以篡改 DNS 响应使其指向任意服务器而 MTA 会毫无察觉地使用该服务器。解决该问题的两个协议MTA-STSSMTP MTA Strict Transport Security要求 MTA 将所使用的记录与收件人域名通过 HTTPS 发布的一组规则进行比对校验。DNSSEC对记录本身进行密码学签名从根源上保证记录的完整性。1.2 TLS 强制STARTTLS 可被隐藏默认情况下服务器之间的 SMTP 传输是不加密的。如果远端服务器支持 TLS它会通过名为 STARTTLS 的 ESMTP 扩展来通告这一能力但控制通信信道的恶意攻击者可以隐藏对 STARTTLS 的支持迫使发件方 MTA 退回明文传输。因此必须存在一条带外out-of-band的、经过认证的通道用来指示 TLS 支持的存在并强制其使用。解决该问题的两个机制MTA-STS当其策略处于enforce模式时MTA 被强制要求在与远端服务器投递消息时使用 TLS。DANEDNS-based Authentication of Named Entities作用与 MTA-STS 类似但改用 DNSSEC 签名的 TLSA 记录来实现。二、maddy 的两级安全模型MX 安全等级与 TLS 安全等级maddy 用两个取值来刻画一条出站投递有多安全MX 安全等级MX security level对应 MX 记录认证问题TLS 安全等级TLS security level对应 TLS 强制问题。投递时maddy 会为与远端服务器建立的连接按这两个维度进行评级ranked再将结果与一系列策略包括本地配置逐一比对如果有效等级低于要求等级连接会被关闭并尝试下一个候选服务器如果所有候选都因此失败投递即告失败若在策略检查过程中出现临时错误则投递被推迟/重试。从源码结构看这两个等级在 framework/module/mxauth.go 中被定义为有序枚举const ( TLSNone TLSLevel iota TLSEncrypted TLSAuthenticated ) const ( MXNone MXLevel iota MX_MTASTS MX_DNSSEC )等级从低到高排列策略通过数值比较mxLevel l.minMXLevel、tlsLevel l.minTLSLevel判定是否达标见 internal/target/remote/security.go 中localPolicy的CheckMX/CheckConn实现。2.1 安全等级定义与防护能力总表maddy 文档给出了下表汇总各级别定义及其能提供的防护MX/TLS levelNoneEncryptedAuthenticatedNone-PPMTA-STS-PPA (见注 1)DNSSEC-PPA图例P—— 抵御被动攻击passive attacksA—— 抵御主动攻击active attacks。各级别的精确定义如下MX 等级 NoneMX 候选来自收件人域名的 DNS 查询结果未做任何额外检查。MX 等级 MTA-STS所使用的 MX 与收件人域名发布的 MTA-STS 策略匹配即使该策略处于 testing 模式也算数。MX 等级 DNSSECMX 记录已签名DNSSEC 验证通过。TLS 等级 None建立了明文连接TLS 不可用或建立失败。TLS 等级 Encrypted建立了 TLS 连接但服务器证书未通过 X.509 与 DANE 验证。TLS 等级 Authenticated建立了 TLS 连接且服务器证书通过了 X.509或DANE 验证。注 1能够持续控制网络连接的持久性攻击者可以干扰策略刷新从而将防护降级为仅能抵御被动攻击——这正是 MTA-STS 相对 DANE 的固有弱点。2.2 为什么Encrypted不等于Authenticated从表中可以读出 maddy 安全模型的核心理念加密Encrypted只能防窃听认证Authenticated才能防中间人。证书验证失败X.509 不过、无 DANE 匹配时maddy 会把等级降为 Encrypted 而非直接断连——因为加密仍优于明文但若策略要求 Authenticated则该连接会被拒绝使用。这一降级行为在 internal/target/remote/connect.go 的connect函数中有完整实现先尝试带 X.509 验证的 STARTTLS若验证失败isVerifyError回退到InsecureSkipVerify的无认证 TLS等级降为TLSEncrypted若 TLS 整体失败再回退明文等级为TLSNone。三、maddy 安全策略体系mx_auth 与五种策略模块maddy 将上述机制抽象为MX 认证策略MXAuthPolicy。策略在配置中通过remote目标的mx_auth指令块启用未指定mx_auth时默认不启用任何机制——文档特别提醒这会令出站 SMTP 暴露于多种降级攻击之下因此不推荐。策略的启用方式与配置入口详见 docs/reference/targets/remote.md基础示例mx_auth { dane mtasts }若机制支持可为其单独开配置块例如mtasts { cache ram }3.1 策略执行顺序policy_group 的固定编排各策略之间存在依赖关系某些策略依赖先前策略的结果因此 maddy 通过mx_auth策略组模块internal/target/remote/policy_group.go固定了应用顺序mtasts—— 先于其他策略其判定出的MX_MTASTS等级会阻止后续sts_preload生效sts_preload—— 已废弃的 STS 预加载列表模块仅存桩见 internal/target/remote/security.godane—— 通过 TLSA 记录提升 TLS 等级dnssec—— 通过签名 MX 记录提升 MX 等级local_policy——必须放在最后因为它要基于前面各策略设置的等级做最终门槛校验。对应地每个策略模块都实现了 framework/module/mxauth.go 中定义的MXAuthPolicy接口核心方法包括Weight()策略的相对应用权重0–1000PrepareDomain/PrepareConn在 MX 查询 / 建连前异步预取必要数据如 MTA-STS 策略、TLSA 记录CheckMX判断策略是否允许使用某个 MX并可提升 MX 等级CheckConn判断策略是否允许使用这条连接并可提升 TLS 等级Reset为下一条消息重置内部状态。实际投递流程中internal/target/remote/connect.go 的attemptMX会先对每个候选 MX 依次执行所有策略的CheckMX建立连接后再执行所有策略的CheckConn最终把两个等级写入连接对象conn.mxLevel、conn.tlsLevel并记录到 OpenMetrics 指标mxLevelCnt、tlsLevelCnt。3.2 MTA-STS 策略MTA-STS 会检查收件人域名的 MTA-STS 策略为投递提供认证与 TLS 强制但如注 1 所述对持久性主动攻击存在部分脆弱性。只要使用的 MX 与策略匹配即便策略未处于 enforce 模式MX 等级就会被置为mtasts。配置项docs/reference/targets/remote.mdmtasts { cache fs fs_dir StateDirectory/mtasts_cache }cache取值fs|ram默认fs。fs使用文件系统目录缓存ram使用内存缓存。文档建议优先用fs否则服务器重启会丢弃缓存、导致 MTA-STS 安全保护消失内存缓存在高负载且运行稳定的配置中才有意义。fs_dircache为fs时使用的缓存目录默认StateDirectory/mtasts_cache。实现细节internal/target/remote/security.go缓存在Init阶段按cache取值创建mtasts.NewFSCache/mtasts.NewRAMCache其解析器挂载 maddy 默认 DNS 解析器StartUpdater启动后台协程启动时立即刷新一次缓存考虑到可能停机多时此后每 12 小时通过cache.Refresh()刷新CheckMX中若 MX 不匹配策略且策略为ModeEnforce直接返回 550/5.7.0 错误Failed to establish the MX record authenticity (MTA-STS)非 enforce 模式仅记录日志并返回MXNoneCheckConn中enforce 模式下若 TLS 握手未完成或证书链未通过验证VerifiedChains nil均返回 451/4.7.1 错误强制 TLS。3.3 DNSSEC 策略DNSSEC 策略检查 MX 记录是否签名若是则把 MX 等级置为dnssec。maddy自身并不验证 DNSSEC 签名而是依赖上游解析器验证失败时让查询失败验证通过且区域已签名时设置 AD 标志。作为安全措施若解析器不是 127.0.0.1 或 ::1AD 标志会被忽略。另注意DNSSEC 目前不支持 Windows 等没有标准格式/etc/resolv.conf的平台。配置极其简单dnssec { }实现见 internal/target/remote/security.goCheckMX直接依据调用方传入的dnssec布尔值返回MX_DNSSEC或MXNone。该布尔值来自 internal/target/remote/connect.go 的lookupMX当配置了扩展解析器时调用extResolver.AuthLookupMX获取签名状态否则使用普通LookupMX此时dnssec恒为 false。3.4 DANE 策略DANE 策略检查收件人 MX 的 TLSA 记录提供抗降级的 TLS 强制downgrade-resistant。若存在有效且匹配、且 usage 类型为DANE-EE3或 DANE-TA2的 TLSA 记录TLS 等级被置为authenticated。DANE 依赖 DNSSEC 支持才能工作dane { }实现细节internal/target/remote/security.go 与 internal/target/remote/dane.godiscoverTLSA使用 EDNS 扩展解析器先校验 A/AAAA 记录的 AD 标志若 A 记录未被 DNSSEC 认证则跳过 TLSA 查询除非是 CNAME 场景且 CNAME 本身已签名并遵循 RFC 7672 对非认证 RRset 的处理任何 I/O 错误含 SERVFAIL按 RFC 7672 视为应延迟投递的临时错误verifyDANE只采信 usage 2/3、selector 0/1、matching type 0/1/2 的记录若无可用记录则不做强制有记录但HandshakeComplete为 false 时返回 550/5.7.1TLS is required but unsupported or failed (enforced by DANE)DANE-EE 记录直接对服务器叶子证书做 TLSA 匹配不校验 SAN/CN、过期证书也可接受符合 RFC 7672 3.1.1DANE-TA 记录则把匹配的 CA 证书加入信任根池再走标准 X.509 链验证没有任何记录匹配时返回 550/5.7.0No matching TLSA records。3.5 本地策略 local_policy本地策略检查有效 TLS / MX 等级由其他策略设定是否满足本地配置的门槛docs/reference/targets/remote.mdlocal_policy { min_tls_level none min_mx_level none }min_tls_levelnone|encrypted|authenticated默认encrypted。设定所有出站消息要求的最低 TLS 安全等级。min_mx_levelnone|mtasts|dnssec默认none。设定所有出站消息要求的最低 MX 安全等级。使用local_policy off等价于两项都设为none。实现见 internal/target/remote/security.goInit通过cfg.Enum校验取值并映射到module包定义的枚举CheckMX/CheckConn中一旦发现有效等级低于门槛返回 451/4.7.x 的临时性 SMTP 错误附带mx_level、required_mx_level等诊断字段且错误被统一标记为临时错误以便管理员排查问题时不丢信。3.6 共享策略组与完整配置示例mx_auth模块支持在顶层定义策略组、通过引用语法在多个remote实例间共享同一套策略docs/reference/targets/remote.mdmx_auth outbound_policy { dane mtasts { cache ram } } # ... elsewhere ... deliver_to remote { mx_auth outbound_policy }仓库自带的 maddy.conf 给出了生产级完整示例——默认配置同时启用 DANE、MTA-STS文件缓存与本地策略target.remote outbound_delivery { limits { destination rate 20 1s destination concurrency 10 } mx_auth { dane mtasts { cache fs fs_dir mtasts_cache/ } local_policy { min_tls_level encrypted min_mx_level none } } }3.7 与 REQUIRETLS 的联动投递安全等级还与 internal/target/remote/connect.go 中 REQUIRETLS 的处理相关当消息带有 REQUIRETLS 选项时maddy 要求tlsLevel TLSAuthenticated且mxLevel MX_MTASTS否则拒绝550/5.7.30。同时为避免连接池投毒攻击者通过复用弱安全旧连接使消息无法投递带 REQUIRETLS 的消息会绕过连接池缓存强制新建连接。relaxed_requiretls选项默认true则允许向未通告 REQUIRETLS 的 MX 投递其假设是 MX 极可能就是最终目的地只需保障到 MX 这一段的安全。四、各机制的安全特性对比与选型建议结合 docs/seclevels.md 的等级总表与源码实现可将各机制总结如下机制提升的等级抗被动攻击抗主动攻击关键依赖局限MTA-STSMX →mtastsenforce 时强制 TLS是是有限HTTPS 策略发布、策略缓存持久性攻击者可干扰策略刷新降级防护DNSSECMX →dnssec是是上游解析器做 DNSSEC 验证AD 标志依赖解析器配置非标准 resolv.conf 平台不可用DANETLS →authenticated是是DNSSEC TLSA 记录要求收件方发布 TLSA需 EDNS 扩展解析器local_policy门槛校验不提升等级——前序策略结果仅设下限本身不提供认证能力选型建议基于文档与默认配置推断基础防护至少启用local_policy { min_tls_level encrypted }确保所有出站连接加密推荐组合danemtastsdnsseclocal_policy即 maddy.conf 的默认方案兼顾认证与加密对安全要求严格的场景可将min_mx_level提至mtasts甚至dnssec把不满足认证条件的投递直接拒绝。五、验证与测试依据maddy 为这套安全体系提供了较完整的单元测试可作为理解行为边界的佐证internal/target/remote/mxauth_test.goMX 认证策略相关测试internal/target/remote/dane_test.go 与 internal/target/remote/dane_delivery_test.goDANE 的 TLSA 验证与投递行为测试含verifyDANETime钩子用于覆盖 DANE-TA 验证时间internal/target/remote/remote_test.go使用 mock DNS 区域测试完整投递链路其中testSTSPolicy、testDANEPolicy分别以cache ram和空配置初始化策略模块。例如 internal/target/remote/remote_test.go 展示了 MTA-STS 策略以内存缓存初始化的测试路径印证了cache ram配置项的实际作用。六、小结maddy 通过MX 安全等级 TLS 安全等级的二维评级模型把出站投递安全从模糊的尽量用 TLS升级为可量化、可强制、可审计的工程体系MTA-STS 与 DNSSEC 解决发给谁MX 认证MTA-STS enforce 与 DANE 解决怎么传TLS 强制而local_policy提供统一的本地兜底门槛。理解这套等级与策略编排是正确配置 maddy 出站投递、排查 451/550 投递失败与降级攻击问题的前提。所有机制均可在remote目标的mx_auth指令中自由组合具体参数以 docs/reference/targets/remote.md 为准RFC 8461 第 10.2 节Preventing Policy Discovery是 MTA-STS 策略防探测设计的规范依据。赞分享后端通信【免费下载链接】maddy✉️ Composable all-in-one mail server.项目地址https://gitcode.com/gh_mirrors/ma/maddy点击查看免费下载相关推荐Mailu安全配置详解TLS、DANE、MTA-STS强化指南Mailu安全配置详解TLS、DANE、MTA STS强化指南 在当今网络安全威胁日益严峻的环境中邮件服务器的安全配置变得尤为重要。Mailu作为一款基于D后端通信docker-mailserver 的 MTA-STS 实战指南出站 STARTTLS 强制策略、DANE 冲突与入站配置docker mailserver 的 MTA STS 实战指南出站 STARTTLS 强制策略、DANE 冲突与入站配置 本文基于 docs/content后端通信云原生maddy remote 投递目标基于 DNS MX 记录的出站邮件投递与安全策略配置指南maddy remote 投递目标基于 DNS MX 记录的出站邮件投递与安全策略配置指南 导读 target.remote 是 maddy 邮件服务器中负责后端通信上一篇老游戏还能不能跑GTA III / 罪恶都市 / 圣安地列斯在 Windows 10/11 上的兼容性修复指南下一篇NocoBase FlowEngine 响应式机制解析基于 Observable 的数据流与视图同步原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考