对于组织而言,使用 电邮加密或通过 私密电邮转发服务来发送电邮已变得越来越普遍,这种服务会隐藏原始发送人的电邮身份和域名。虽然这两个系统中的任何一个都 可能 与 Zendesk 兼容,但其结果在很大程度上取决于发送或转发的电邮的状态,以及该部分的转发过程。对于私密电邮服务,其成功取决于其如何维护对话讨论串的一致性,以及如何遵守允许此情况发生的协议。
在可能的情况下,并确保您遵守所有的法律、安全和隐私协议或要求,当您能够验证您这样做的安全性和安全性时,最好向 Zendesk 发送或转发未加密的电邮。
Zendesk 无法为您加密电邮,就好像我们是预期收件人一样,我们拥有必要的身份来处理电邮,或为您提供任何有用的信息,说明谁是发送电邮给您的使用私密转接服务。加密(加密过程需要身份验证)的目的是防止信息被意外拦截。Zendesk 用作信息库,但在整个流程中,经常扮演中间接听的角色。私密电邮转发的目的是隐藏发送者的身份和发送者的真实域名。
虽然加密电邮或确定被隐藏的发送人的身份 在 数学上几乎是不可能的,但如果要对其进行加密,则可能违反了州或联邦隐私法律。
Zendesk 负责维护通讯安全,包括加密或私密电邮的发送服务。
这篇文章包含以下组别:
电邮加密
今天有几种形式的 电邮加密 。最常用的两个是 S/ MIME 和 PTP/ MIME。
- S/ MIME(安全/ MIME)是使用最广泛的,因为它内置于几个大型电邮供应商的基础设施 ——OSX、iOS、 Outlook、 Gmail 等。
- Pgp/ MIME(Pretty好隐私/ MIME)依靠去中心化模型和第三方加密工具。
还有各种其他,包括完全专有的加密协议。其中一些仅当电邮在传输中时可用,因此对在其已通过身份验证的客户端中查看电邮的终端用户不可见。其他人则要求用户进行严格的身份验证,然后电邮才能可读。当电邮转发到另一项服务时,就像到达 Zendesk 的入站处理服务器时经常发生的一样,我们完全依靠电邮到达的加密状态。
Zendesk 当前仅支持机会性 TLS 作为终端到终端电邮加密协议。这意味着,在呼入和发出的电邮中,如果发送或收件人服务器也支持该协议,我们将接受或发送 TLS 加密的电邮。这里是 我们安全功能的概览文章。
私密电邮转发
这些服务旨在隐藏发送者的身份。在最好的情况下,我们虽然使用代理电邮地址,但仍可正常互动。通常会出现问题的地方是使用密钥化的"回复到:"地址。这些页首字段向收件人指示任何回复应发送到的地址。当您单击"回复"或"全部回复"时,它将变为您的电邮客户端(MS Outlook、 Mac Mail、 Gmail、雅虎等)的"收件人"字段中的地址。私密电邮转接必须用除了原始发送人的电邮地址之外的其它内容填充此字段,否则转接将不是私密的。通常,这些服务依靠一个标记化的地址,该地址只能根据电邮地址的本地部分,以及反映私密电邮转接资源的电邮地址的域名部分来进行分析和转接,而不是原始发送人。这些密钥作为其提供的服务的基础方面,已受到保护,以避免被收件人转换。
Zendesk 理解客户与您的任何沟通都很重要,但这些类型的电邮的发送人希望其信息仅由其指定的收件人可见,这一点也很重要。如果您要将电邮转发给我们,那么您自己的转发地址很可能是目标收件人。导航到该转发客服电邮地址的收件箱,可能为您了解更多关于这些类型电邮转发的信息。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。