6. Modifier Definitions (修饰符定义)
6. Modifier Definitions (修饰符定义)
修饰符是名称/值对, 提供额外的信息。修饰符始终有一个 "=" 分隔名称和值。
本文档中定义的修饰符("redirect" 和 "exp")应该出现在记录的末尾, 在所有机制之后, 尽管它们在语法上可以出现在记录中的任何位置。这两个修饰符的顺序无关紧要。这两个修饰符在记录中绝对不能出现超过一次。如果它们出现, 则 check_host() 以 "permerror" 结果退出。
无论在哪里, 或多久出现, 必须忽略无法识别的修饰符。这使得符合本文档的实现能够优雅地处理在其他规范中定义的修饰符的记录。
6.1 redirect: Redirected Query (redirect: 重定向查询)
"redirect" 修饰符旨在将授权和策略合并到要在单个 ADMD 内共享的通用集合中。可以从单个记录控制任意数量的域的授权主机和策略。
redirect = "redirect" "=" domain-spec
如果所有机制都无法匹配, 并且存在 "redirect" 修饰符, 则处理如下:
redirect 部分的 <domain-spec> 部分按照第 7 节中的宏规则扩展。然后使用生成的字符串作为 <domain> 评估 check_host()。<ip> 和 <sender> 参数与 check_host() 的当前评估中保持相同。
此新评估的 check_host() 的结果然后被视为当前评估的结果, 但如果找不到 SPF 记录, 或者 <target-name> 格式错误, 则结果是 "permerror" 而不是 "none"。
请注意, 新查询的域本身可以指定 redirect 处理。
此工具旨在供希望将相同记录应用于多个域的组织使用。例如:
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
在此示例中, 来自这三个域中任何一个的邮件都由相同的记录描述。这可能是管理上的优势。
注意: 一般来说, 域 "A" 不能可靠地使用重定向到不在同一管理控制下的另一个域 "B"。由于 <domain> 保持不变, 因此不能保证域 "B" 处的记录将对域 "A" 中的邮箱正确工作, 特别是如果域 "B" 使用涉及 local-part 的机制。"include" 指令通常会更合适。
为了清楚起见, 任何 "redirect" 修饰符应该作为记录中的最后一个术语出现。如果记录中的任何地方有 "all" 机制, 则必须忽略任何 "redirect" 修饰符。
6.2 exp: Explanation (exp: 解释)
explanation = "exp" "=" domain-spec
如果 check_host() 由于机制匹配(例如 "-all")而导致 "fail", 并且存在 "exp" 修饰符, 则返回的解释字符串按如下所述计算。如果不存在 "exp" 修饰符, 则必须向调用应用程序返回默认解释字符串或空解释字符串。
<domain-spec> 进行宏扩展(参见第 7 节)并成为 <target-name>。获取 <target-name> 的 DNS TXT RRset。
如果有任何 DNS 处理错误(任何 RCODE 不是 0), 或者如果没有返回记录, 或者如果返回多个记录, 或者如果解释字符串中存在语法错误, 则继续进行, 就像没有给出 "exp" 修饰符一样。
获取的 TXT 记录的字符串在没有空格的情况下连接, 然后作为 explain-string 处理, 该字符串进行宏扩展。这个最终结果就是解释字符串。实现可以限制生成的解释字符串的长度以允许其他协议约束和/或合理的处理限制。由于解释字符串旨在用于 SMTP 响应, 并且 [RFC5321] 的第 2.4 节说响应是 [US-ASCII], 因此解释字符串必须限制为 [US-ASCII]。
评估 check_host() 的软件可以使用此字符串以简短消息或 URL 的形式从发布域传达信息。软件应该明确说明解释字符串来自第三方。例如, 它可以在解释前添加宏字符串 "%{o} explains: ", 如第 8.4 节中的示例所示。
假设 example.com 有此记录:
v=spf1 mx -all exp=explain._spf.%{d}
以下是 explain._spf.example.com 处可能的解释 TXT 记录的一些示例:
"Mail from example.com should only be sent by its own servers."
-- 一个简单的, 恒定的消息
"%{i} is not one of %{d}'s designated mail servers."
-- 一个包含更多信息的消息, 包括未通过检查的 IP 地址
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- 一个复杂的示例, 使用 check_host() 的参数构造 URL, 以便可以生成包含详细、自定义说明的网页
注意: 在递归到 "include" 机制期间, 绝对不能使用 <target-name> 中的 "exp" 修饰符。相反, 在执行 "redirect" 修饰符时, 绝对不能使用原始域中的 "exp" 修饰符。这是因为 "include" 旨在跨越管理边界, 应该提供的解释应该是来自接收 ADMD 的解释, 而 "redirect" 旨在作为在 ADMD 内合并策略记录的工具, 因此重定向的解释是应该具有优先权的解释。