SecurityGateway for Email Servers v4.5 发布说明

凭借 20 多年来久经考验的邮件安全专业技术所开发的 SecurityGateway,以经济实惠的价格提供邮件安全功能。它能防范垃圾邮件、病毒、网络钓鱼、欺诈和其他形式的恶意软件,这些恶意软件对企业的合法邮件通讯构成了日益严重的威胁。

点击此处可了解有关 SecurityGateway for Email Servers 的更多信息

SecurityGateway 4.5.1 - 2017年5月9日

主要新功能

[15657] SecurityGateway 现在与 RPost® 的 RMail™ 服务集成。

RMail™ 的使用非常直观,无需您的收件人安装任何专用的软件。RMail™ 为各行各业各种规模的企业和消费者提供电子邮件服务。

RMail™ 服务由 RPost Registered Email® 技术提供支持,该技术是电子邮件投递证明的全球标准。RMail™ 服务扩展了您的电子邮件平台,并提供:

通过使用免费的 RPost 账户,限制每个用户每月发送/接收10封加密邮件。额外邮件可以通过使用免费的 RPost 账户,限制每个用户每月发送/接收10封加密邮件。额外邮件可以通过 RPost 进行购买。点击此处来获取有关增加邮件限制的计划/价格的更多信息。

可以从“安全 | EMail™ 页面”启用 EMail™ 服务,也可以将其作为邮件内容过滤规则的操作。

变更和新功能

修复

SecurityGateway 4.5.0 - 2017年4月4日

特殊注意事项

[18161] 出于安全和技术原因,已将“设置 / 用户 | 邮件配置 | 邮件协议”中的“准许 CRAM-MD5 验证方式”更改成默认情况下禁用此项。使用 TLS 是避免明文传输密码的首选方式。

变更和新功能

修复

SecurityGateway 4.0.1 - 2016年7月26日

变更和新功能

修复

SecurityGateway 4.0.0 - 2016年6月14日

主要新功能

[15999] 已更新Web 界面来使用“移动第一响应设计”( Mobile First Responsive Design)

已更新 web 界面来使用移动第一响应设计。浏览器支持仅限于 IE10+、最新版本的 Chrome、最新版本的 Firefox 以及用于 Mac 和 iOS 的最新版 Safari。已知在 Android Stock 浏览器上存在滚动问题,不过 Chrome 可以在 Android 设备上出色运行。

该设计完全基于正在使用的窗口的大小。 无论用户正在使用手机、平板电脑、还是计算机,相同的窗口大小具有相同的外观。 此处最重要的变更是菜单。 宽度小于等于 956 像素时,将在浏览器的左侧隐藏菜单。 可以使用两种方式来显示菜单。 如果使用触屏设备,向右滑动即可显示次级菜单。 无论设备是否正在使用,在其左上角还有一个“菜单”按钮,它将显示次级菜单。 轻击菜单顶部附近带有左箭头的菜单标题,将显示主菜单。 此外,右上角的帮助、关于和注销菜单也将基于屏幕宽度进行变化。 屏幕宽度大于等于 768 像素时,将显示文字形式的帮助、关于和注销。 屏幕宽度为 481 - 767 像素时,仅显示图标。 屏幕宽度小于等于 480 像素时,仅显示一个“齿轮”图标,在点击该图表时将显示一个含有帮助、关于和注销选项的下拉菜单。 具有多列的列表视图有一个开/关列的按钮。

[11232] DMARC

已添加 DMARC(基于域的邮件验证、报告和一致性)支持。DMARC 定义了邮件发送组织可以凭此进行表达的一种可扩展机制,使用“域名系统”、域级别策略和首选项进行邮件验证、处理和报告,而邮件接收组织可以使用这些策略和首选项来改善邮件处理。可以从以下链接找到 DMARC 规范及其作用和如何运作的完整详情: http://www.dmarc.org/

DMARC 允许域拥有者表达如何处理声称来自其域内(但是并非由他们发送)的邮件的意愿。提供以下可用的邮件处理策略选项:“无操作”表示 SecurityGateway 不采取任何操作,“拒收”表示 SecurityGateway 在其 SMTP 会话期间拒收邮件,“隔离”表示 SecurityGateway 将以下报头(“X-MDDMARC-Fail-policy: quarantine”)放入各封邮件,由此来轻松简便地过滤到您用户的垃圾邮件文件夹。只有在DMARC 的检查结果为“失败”时才添加这个报头。可以配置 SecurityGateway 即使在 DMARC 请求拒收邮件时也接收那些邮件。实际上,这是默认的操作模式。在这些情况下,如果您希望进行更严格的过滤,SecurityGateway 会将一个“X-MDDMARC-Fail-policy: reject”报头放入邮件中。

DMARC 取代了 ADSP 和 SPF 的邮件处理功能。不过,您仍然可以将它们和 DMARC 结合在一起使用。如果启用了DMARC 验证,将在 DMARC 处理过后进行 ADSP 和 SPF 邮件拒收操作。

DMARC 部分依赖“公共后缀列表”的使用。互联网用户可以直接在“公共后缀”下注册姓名。一些公共后缀的示例如下:.com、.co.uk 和 pvt.k12.ma.us。“公共后缀列表”是所有已知公共后缀的列表。SecurityGateway使用 Mozilla Foundation为社区维护的一个公共后缀列表,可以从以下链接找到:https://publicsuffix.org/。会将此列表的一个副本安装到您的 \App\ 文件夹中,作为 effective_tld_names.dat。现在没有这种列表的综合或单一的权威来源,这是互联网社区应该解决的一个问题。经过一段时间,该文件就会过时,必须通过从 https://publicsuffix.org/list/effective_tld_names.dat 重新下载文件并将其保存到您的 \App\ 文件夹来替换旧文件。SecurityGateway将定期自动下载该文件并作为日常维护事件的一部分,大约每隔两周安装一次这个文件。可以在新的 DMARC 配置屏幕上找到对此进行管理的各种控件。主用户界面内“安全”选项卡中的DMARC 日志和全新的 DMARC 窗口将包含更新结果和所有其他 DMARC 处理操作。必要时您可以设置一个不同的文件下载 URL,不过下载的数据必须符合 Mozilla 为其文件指定的格式。您可以从上述 URL 阅读相关信息。SecurityGateway严格遵循由Mozilla 指定的解析算法。如果您想亲自替换或编辑 effective_tld_names.dat文件,而且需要 SecurityGateway 在不重启的情况下进行加载,请创建一个名为“PUBLICSUFFIX.SEM”(可能为空)的文件并将其放入 SecurityGateway 的 \App\ 文件夹中。

要将 DMARC 用作一个邮件发件人,您必须在您域的 DNS 设置中发布 DMARC TXT 记录。可以从 http://www.dmarc.org 找到如何定义和构建这个记录的信息。当您向 DNS 发布一个 DMARC 记录时,您可能开始通过电子邮件收到来自大量不同来源的 DMARC 报告。这些报告作为一个经过压缩的 XML 文件提供,其格式由 DMARC 规范制约。耗用这些报告在 SecurityGateway 的 DMARC 实施范围之外。不过,这些报告内的数据可以为以下内容提供一些重要的见解,包括域的邮件流、不恰当的域使用、DKIM 签名的完整性、以及 SPF 邮件路径的准确性/完整性。在您创建 DMARC 记录时,可以由您来配置这些报告的发送目标地址。

在为您的一个或多个域设置 DMARC 记录时,请慎用 p=reject。如果您的域提供邮件账户供人类用户进行常规使用,请特别小心。如果这些用户注册了任何邮件列表,使用邮件转发服务,或期望使用像“和朋友分享这篇文章”这样的常规事项,您现在应该知道 DMARC p=reject 会使上述这些事情完全不可能。只有在对用来控制如何使用其邮件账户(例如,交易邮件、自动化(非人类)账户、或对企业外部的账户使用强制执行公司策略)的域应用 DMARC p=reject时,它才极其有用。

为了支持 DMARC 汇总报告,SecurityGateway 将存储它稍后要使用的数据来按照 DMARC 规范生成汇总报告。SecurityGateway 忽略 DMARC “ri=”标签,只生成指定日从 00:00:00 UTC 到 23:59:59 UTC 时段内的 DMARC 汇总报告。在午夜 UTC(不必是午夜本地时间),SecurityGateway 耗用这些已存储的数据来生成报告。SecurityGateway 需要在此时运行,否则存储的数据会持续增长,永远不会被耗用。因此,如果您不是全天候地运行您的 SecurityGateway,您不得启用 DMARC 汇总报告。默认情况下禁用 DMARC 汇总报告。

为了支持 DMARC 故障报告,已全面落实了 RFC 5965“邮件反馈报告的可扩展格式”、RFC 6591“使用滥用报告格式的验证故障报告”、RFC 6652“使用滥用报告格式的发件人策略框架(SPF )验证故障报告”、RFC 6651“用于故障报告的域名密钥标识邮件(DKIM )扩展”、以及 RFC 6692“滥用报告格式(ARF )报告中的源端口”。在触发故障报告的事件发生时,将实时创建故障报告。SecurityGateway实施 DMARC AFRF 类型的故障报告,而不是 IODEF 类型的报告。因此,在 DMARC “rf=”标签中只准许“afrf ”值。请参阅 DMARC 规范获得完整的详细信息。取决于 DMARC 记录的“ruf=”标签中的收件人数量和“fo=”标签值乘以处理期间邮件所遇到的独立验证故障数量的所得值,可以从一封邮件生成多份故障报告。当 DMARC“fo=”标签请求 SPF 相关故障的报告时,SecurityGateway将按照 RFC 6522 发送 SPF 故障报告。因此,该域的 SPF 记录中必须存在那个规范的扩展。如果不经过 DMARC 处理或缺少 RFC 6522 扩展,则不会发送 SPF 故障报告。当 DMARC“fo=”标签请求 DKIM 相关故障的报告时,SecurityGateway将按照 RFC 6651 发送 DKIM 和 ADSP 故障报告。因此,在 DKIM 签名报头字段中必须存在那个规范的扩展,而且该域必须在 DNS 中发布一个有效的 DKIM 报告 TXT 记录和/或在 ADSP TXT 记录中发布有效的 ADSP 扩展。如果不经过 DMARC 处理或缺少 RFC 6651 扩展,则不会发送 DKIM 和 ADSP 故障报告。请参阅本文中提及的各种规范来获得完整的详细信息。默认情况下禁用 DMARC 故障报告。

重要注意事项:DMARC 记录可以指定应以域拥有者的名义将这些报告发送至中介操作。当域拥有者与一个实体签订合约来监控邮件流的滥用和性能问题时将这么做。您的隐私条例、使用条款或其他类似的管制文档可能允许或不允许由第三方收到这些数据。如果您自己的内部策略约束 DMARC 报告的使用和传播,您应该进行审核并理解这一点,如果确实存在制约,您应该合理禁用 DMARC 报告。

当报告接收者提供STARTTLS 时,DMARC 请求使用它,不过无法对此进行预测和管制。但是,如果您尚未启用 STARTTLS,您应该启用它(请参阅“设置 / 用户 | 系统 | 加密”)。

已扩展“Authentication-Results(验证结果)”报头,使其包含 DMARC 处理结果。注意:“Authentication-Results”在备注中包含一些用于调试的数据,包括由域拥有者请求的 DMARC 策略(不是很有必要对邮件采取这种操作)。例如,当 DMARC 检查结果是“pass(通过)”时,则无论 DMARC 策略如何规定都无所谓,因为该策略仅在 DMARC 检查“失败”时应用。类似的,当 DMARC 检查结果是“失败”,而且策略为“拒收”时,出于本地策略原因,可能不管怎样还是会接收这封邮件。使用这个报头进行过滤时要考虑所有这些因素。另外,通过 “X-MDDMARC-Fail-policy: quarantine”或“X-MDDMARC-Fail-policy: reject”过滤器来将这些邮件过滤到垃圾邮件文件夹或执行您希望的操作。SecurityGateway将剔除每封入站邮件中的“X-MDDMARC-Fail-policy:”报头。

邮件必须符合 DMARC 15.1 节有关 RFC 5322.From 报头的内容,否则就不会对其进行处理,这基本上意味着缺少一个(一个或只有一个)格式正确(按照 RFC规范)的 RFC5322.From 报头,一般会将邮件处理成无效邮件,从而无法有效进行 DMARC 处理。

已在“Ctrl+S | 发件人验证”新增若干屏幕,帮助您设置有关 DMARC 使用的各种选项。

DMARC 要求启用 SPF 和/或 DKIM 验证,因为它基于这两个机制所提供的已验证标识。如果没有启用这种或两种技术,您无法富有成效地将 DMARC 用于入站邮件。用户界面将强制执行这点。

[3961] 绑定域到 IP 地址

对于拥有被分配到多个 IP 地址的服务器,可以将每个域绑定到特定的 IP 地址。将从这个 IP 地址发送来自此域的邮件。

也可以为此域指定 SMTP 主机名。该值是“全称域名”(FQDN),在发送此域的邮件时,将在 SMTP HELO/EHLO 指令中使用这个值。对于入站连接而言,将使用此值,除非多个域被绑定到这个 IP 地址,在这种情况下,使用的 FQDN 将与按字母顺序居于首位的域相关联。

变更和新功能

修复

Copyright ©2008-2016