用独立邮箱管理每台设备的告警邮件

许多设备除了电子邮件以外，竟然没有其他通信方式。备份设备、网络监控系统、楼宇管理系统、打印机、工业控制器和旧式仪器都会通过 SMTP 发送告警，因为它们在设计时只能采用这种集成方式。为每台设备设置一个邮箱，可以把这个麻烦转变为易于管理的架构。

大多数场所采用的替代方案，是让所有机器都向同一个共享地址发信。只要不需要从四十台设备中找出究竟哪台正在报错，这种方式看起来一直有效。

为什么一个共享地址不够用

让所有设备都向 alerts@ 发信是最直观的做法，但它必然会逐渐失去可用性。

不同厂商采用不同格式，因此邮件主题和发件人名称并不统一。事后分类只能根据各台设备碰巧发出的文字来编写规则。固件升级时，厂商可能不作通知便修改措辞，原有规则也随之失效。

邮件数量还会放大问题。一台过于频繁发信的设备，例如状态反复切换的监控器，或不断重试失败任务的设备，就能产生数百封邮件，把其他告警全部淹没。使用共享地址时，无法只静音一个来源而不同时停用接收所有设备邮件的规则。

来源归属也会变得模糊。每台设备使用独立邮箱后，地址本身就能标明发信设备，无需先阅读邮件内容。

让路由不再依赖猜测

每台设备一个邮箱的主要优势，是让路由由架构决定，而不是靠解读邮件文字。

无需解析即可识别。发到 ups-basement@ 的邮件来自地下室的 UPS。无需编写规则，无需匹配主题，厂商更改模板后也不会产生歧义。

独立处理。一台设备可以单独静音、限制频率或忽略，不会影响其他设备，因为它有自己的收件地址。

设备退役更干净。设备下线时删除一个邮箱即可，无需修改过滤器，也不用担心是否还有其他对象依赖这条规则。

按来源自动处理。脚本只读取一台设备的邮箱，就能确切知道应当面对哪种格式。与解析多个来源混在一起的邮件流相比，这种方式可靠得多。具体模式见通过电子邮件接收数据。

成本问题

只有在邮箱不按用户收费的情况下，为每台设备设置邮箱才合理。这也正是这种做法并不常见的原因。

如果每个用户席位收费 $7，四十台设备仅为接收机器告警每年就要支付 $3,360，任何理性的负责人都不会批准。在按套餐等级限制数量的方案中，四十个设备邮箱无需在现有套餐之外额外付费。Pro 每个域名可使用 300 个邮箱，Agency 可使用 1,000 个。

不过，这些邮箱会占用共享存储空间。机器从不停发，设备邮件也会不断积累。因此，每个设备邮箱都必须设置容量配额和保留规则，而不是可有可无。具体原因见邮箱存储配额。

多数情况下，别名更合适

坦率地说，许多场所真正需要的不是每台设备一个邮箱，而是每台设备一个别名。

如果系统并不单独读取每台设备的邮件，你只想识别来源，那么别名既能提供具有识别作用的地址，又无需管理独立邮箱或占用单独的存储空间。所有邮件集中到一个地方，但收件地址仍能表明来源。

如果需要独立处理每台设备的邮件，设备属于不同团队且各团队不应看到彼此的告警，或者不同设备需要采用不同的保留期限，就应选择真正的邮箱。如果所有内容都由一个人阅读，唯一需求只是知道哪台设备发了什么，则应选择别名。

Starter 中每个邮箱可以使用 30 个别名，Pro 为 50 个，Agency 为 100 个。对于大多数设备群而言已经足够，完全不必大量增加邮箱。

配置设备

每台设备一个邮箱的实际困难往往出在设备端，最好在决定采用这一方案前有所了解。

不同厂商对现代邮件提交技术的支持程度差异很大，设备群的使用年限也决定了工作量。过去五年内购置的设备几乎都能直接使用。拥有二十年历史的楼宇管理系统则不会如此，下面介绍的中继服务器是这类环境的标准方案，并不罕见。

旧设备往往只支持通过 25 端口发送未经身份验证的 SMTP 邮件，不支持 RFC 6409 定义的身份验证邮件提交，或者只支持早已弃用的认证机制。有些设备甚至完全不支持 TLS。这些机器无法直接向现代邮件服务发信。通常应在本地网络中部署中继服务器，接收设备未经身份验证的邮件，再以正确的身份验证方式转发出去。

对于支持现代邮件提交的设备，应为每台设备分配独立凭据，而不是共用一套。在不能完全信任的网段上，让设备持有共享凭据会带来安全风险，独立凭据可以消除这种风险。轮换一台设备的密码时，也不会干扰其他设备。

测试设备时应触发一次真实告警，而不是只按内置测试按钮。厂商的测试邮件经常走与实际告警不同的代码路径，可能出现测试成功而真实告警发送失败的情况。