我试图更好地了解 OS X 登录过程，以确定实现VPN 单点登录的最佳方式。
如果我错了，请纠正我，但我相信——
launchd(8)调用gettyent(3)并因此确定 fromttys(5)执行loginwindow.appfor /dev/console。
loginwindow.app尝试获取system.login.console授权权限，授权数据库为此指定了以下机制（与我对其功能的理解一起列出）；那些有特权的在authd进程中运行（作为 root），而那些没有特权的在SecurityAgent进程中运行（作为 _securityagent）：
builtin:policy-banner（显示登录窗口横幅，如果设置）。loginwindow:login （提示输入凭据）。builtin:login-beginbuiltin:reset-password,privileged（使用 Apple ID执行密码重置）。builtin:forward-login,privileged （在启动时从 EFI 转发凭据）。builtin:auto-login,privileged （在启动时应用自动登录凭据）。builtin:authenticate,privileged（所调用pam_authenticate(3)用于authorization服务;集“UID”上下文值）。PKINITMechanism:auth,privileged （通过获取 TGT 来初始化 Kerberos）。builtin:login-successloginwindow:success （保护登录会话免受未经授权的远程访问；在系统的 utmp 和 utmpx 数据库中记录登录；设置控制台终端的所有者和权限）。HomeDirMechanism:login,privileged （挂载用户的主目录）。HomeDirMechanism:status （显示主目录安装进度）。MCXMechanism:login （应用配置文件）。loginwindow:done （重置用户的首选项以包括全局系统默认值；使用用户的首选项配置鼠标、键盘和系统声音；设置用户的组权限；从目录服务中检索用户记录并将该信息应用于会话；加载用户的计算环境——包括首选项、环境变量、设备和文件权限、钥匙串访问等；启动 Dock、Finder 和 SystemUIServer；启动用户的登录项）。 …我们在 OS X 10.10 Yosemite 上运行 KDC，我们添加了一个用于远程访问（旧）主机的服务主体：
$ kadmin add -r host/a.b.c.d@REALM
由于主机仅支持des-cbc-crc密钥加密，因此我们尝试（未成功）添加以下内容：
$ kadmin add_enctype -r host/a.b.c.d@REALM des-cbc-crc
kadmin: bad enctype "des-cbc-crc"
认为默认情况下 DES 已（非常明智地）禁用，我们尝试将其置于allow_weak_crypto=true的[libdefaults]部分/var/db/krb5kdc/kdc.conf并重新启动该kdc过程，但无济于事。
折腾了好几个小时，但没有结果。当然苹果公司还没有编译的Kerberos任何对DES的支持？我们如何解决这个问题？
所有其他类型的消息（即，标准跟踪 RFC 不要求具有空反向路径的任何消息）应该以有效的非空反向路径发送。
为免生疑问，RFC 2119 §3将“应该”定义为“在特定情况下可能存在忽略特定项目的有效理由，但在选择不同的课程之前必须理解并仔细权衡全部含义。 ”
正在考虑的“特殊情况”是 Alice不希望收到传递状态通知（与她发起的电子邮件相关）的情况。
她有几个选择：
当她收到任何此类通知时，忽略/丢弃它——显然这种行为是完全正确的，但它很麻烦（并且浪费了她的资源）；
拒绝在较低级别接受此类通知——可以说反向路径将不再“有效”（遗憾的是未在 RFC 中定义），如果是这样，这种行为与 RFC 的建议相反；或者
使用 null 反向路径发起电子邮件，以便从一开始就不会生成通知——这显然与 RFC 的建议相反。
我很确定这些情况构成了忽略上面引用的 RFC 建议的“正当理由”——但我想确定我已经理解了选项 2 和 3 的“全部含义”。
我特别注意到：
在选项 2 下，某些代理可能会检测到反向路径无效
在选项 3 下，某些代理可能会将具有空反向路径的邮件视为特殊情况
无论哪种方式，代理可能因此拒绝接受/中继/发送电子邮件，或者可能使用此类信息来增加其被标记为垃圾邮件的可能性。这些措施在实践中有多普遍？
我还应该考虑其他任何问题/影响吗？