云邮件安全沙箱（安全附件）的动态投递会带来哪些运维副作用？

传统反恶意软件依赖已知特征匹配，对首次出现的样本无能为力。安全附件的做法是把附件放进隔离环境实际打开并观察行为——是否释放文件、是否发起外联、是否尝试持久化。判据从「长得像不像」变成「做了什么」。

定位要清楚：它是对特征扫描的补充而非替代，两者串行工作，不要因为启用了沙箱就放松基础的反恶意软件配置。

沙箱引爆需要时间。若同步等待判定完成再投递，用户会明显感到邮件变慢。动态投递的折中是：正文先送达，附件在判定完成后再补上。

由此产生的典型现象是——用户收到一封「说好有附件却看不到附件」的邮件。这会稳定地产生一类工单，且用户容易误以为发件方忘了添加附件而去追问，造成双方困扰。

处置：启用动态投递时必须提前做用户告知，说明附件延迟出现属正常现象、大约多久会补齐、什么情况下需要报障。这条沟通成本远低于事后逐个解释。

• 仅监视：只记录不拦截。适合上线首周用来摸清判定量级与误报面。
• 阻止：整封拦下。安全性最高，对误报的容忍度最低。
• 动态投递：正文先到、附件后补。适合对时效敏感的业务部门。
• 替换：移除附件、保留正文并加说明。用户体验比静默丢弃好，因为用户知道发生了什么。

推荐节奏：先全员仅监视 → 依据数据分部门切换 → 对外联密集部门用动态投递，对高风险岗位用阻止。

沙箱引爆的耗时受附件类型与大小影响，不是固定值。在启用前需要与业务方明确：哪些邮件流对延迟零容忍（如交易确认、生产告警、验证码类）。

对这类邮件流，正确解法不是关闭沙箱，而是让它们本来就不该带附件——把告警与验证码类改为纯文本正文，从源头绕开这个矛盾。

• 加密压缩包：沙箱无法解密，也就无法引爆。攻击者把密码写在正文里正是为了绕过检测。应当在传输规则层面对「无法扫描的加密附件」单独设策略，而不是默认放行。
• 指向外部网盘的链接：附件本身不存在于邮件中，沙箱无从检测，这部分由链接类保护承接。

把这两类纳入考虑，才算完整评估了附件通道的风险。

• 是否已先在仅监视模式下运行并取得基线数据。
• 启用动态投递的范围内，用户告知是否已发出。
• 对时效敏感的邮件流是否已单独评估。
• 加密压缩包的处置策略是否明确。
• 被拦附件的申诉与放行路径是否对用户可见。