使用 电邮加密或通过 私密电邮中继服务发送电邮已变得越来越普遍，该服务会掩盖原始发件人的电邮身份和域名。Zendesk 可能会 同时使用这两个系统，但这在很大程度上取决于所发送或转发电邮的状态，以及该电邮在相应转发流程中所用的形式。对于私密电邮服务，成功取决于其如何保持对话讨论串的一致性，并遵守相关协议。
在可能的情况下，并确保遵守所有法律、安全和隐私协议或要求，最好向 Zendesk 发送或转发未加密的电邮，并确保您可以安全可靠地这样做。
Zendesk 无法为您解读电邮，即使我们是预期收件人，但我们拥有必要的身份来对电邮进行操作，或为您提供任何有用的信息，了解使用私密转发服务向您发送电邮的发件人。加密（需要对解锁过程进行身份验证）的目的是防止信息被意外拦截。Zendesk 的作用是作为信息存储库，但通常在总体流程中扮演中间人的角色。私密电邮中继的目的是掩盖发件人的身份及其真实域名。
尽管从数学角度上看不可能对电邮进行破译或确定被屏蔽的发件人身份，但尝试对电邮进行破译则违反了我们的安全和隐私政策，并可能违反 州 或联邦隐私法。
Zendesk 负责维护通信的安全，包括加密或私密电邮的发送服务。
本文章包含以下部分：
电邮加密
目前在用的 电邮加密 方式有多种。其中，S/MIME 和 PGP/MIME 是最常用的两种。
- S/MIME（安全/MIME）是使用最广泛的一种，已内置于多个大型电邮提供商的基础设施中，例如 OSX、iOS、Outlook、Gmail 等。
- PGP/MIME(Pre Ty Good Privacy/MIME) 依赖于去中心化模式和第三方加密工具。
还有许多其他协议，包括完全专有的加密协议。其中一些仅在电邮传输过程中起作用，因此对于在其已通过身份验证的客户端中查看电邮的终端用户不可见。还有些则要求对用户进行严格的身份验证，然后才能由人工读取电邮。当电邮被转发给其他服务时，就像通常到达 Zendesk 的入站处理服务器时一样，我们完全依赖于电邮到达时的加密状态。
Zendesk 当前仅支持机会性 TLS 作为端到端电邮加密协议。这意味着，对于入站和出站电邮，如果发送或收件人服务器也支持该协议，我们将接受或发送 TLS 加密的电邮。以下是 关于我们安全功能的概述文章。
私密电邮中继
这些服务旨在掩盖发送者的身份。在最好的情况下，我们可以正常互动，但需要使用代理电邮地址。通常出现问题的是标记化 Reply-To: 地址的使用。这些标头字段向收件人电邮服务表明任何回复应发送到的地址。当您单击回复或全部回复时，它就会成为电邮客户端（MS Outlook、Mac Mail、Gmail、Yahoo 等）“收件人：”字段中的地址。私密电邮转发必须在此字段中填写原始发件人电邮地址以外的内容，否则此转发不是私密的。通常，这些服务依赖于令牌化地址，而该地址只能根据电邮地址的本地部分中的令牌化字符串进行分析和路由，以及电邮地址中反映私密电邮转发资源的域名部分，而不是电邮地址的域名部分。原始发件人。作为接收者提供服务的基本要素，这些密钥不会被接收者转换。
Zendesk 深知客户与您之间沟通的重要性。同样重要的是，此类电邮的发件人希望其信息仅供其指定的收件人看到。如果您转发电邮给我们，那么您自己的转发地址很可能就是预期收件人。导航到该转发客服电邮地址的收件箱可能会提供一些见解，并有助于获取更多关于这些类型的电邮中继的信息。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。
0 条评论