听闻大多数邮件服务提供商只会在邮件传输时使用 TLS 加密,在储存时并不会加密,这是真的吗?为什么?
1
felixcode 2021-02-14 14:30:41 +08:00 via Android 1
加解密是有很大的 CPU 开销的,也没必要,用户有需求应该在用户端做加密
|
2
ferock 2021-02-14 14:50:36 +08:00 via iPhone 1
这个问题推而广之,服务器上的文本文件是不是都应该被加密?哪个文件不需要加密?…
|
3
BigbyWolf 2021-02-14 16:06:49 +08:00
因为原初设计时就没有设想提供存储加密功能。
你可以将传输内容处理至寄收双方外第三方不可读,这些都可以像我们对现实世界邮政系统的认知来体会,传输过程加密就像设计相关方法规制经手者窥探通信隐私,至于邮政系统为什么会有拆查、限制通信的能力(显而易见的),对这些行为动机的揣测也当好套 163 、qqmail 云云头上。 对已加密的邮件,可以选择不保存解密后的邮件。已加密的邮件是指发送者在发送之前对邮件本身进行加密,不是指加密传输。如果邮件本身已加密,则没有必要进行加密传输。对非加密的邮件(指发送者在发送之前没有对邮件本身进行加密,至于是否使用加密传输是另一回事),邮件的储存安全就如同于其他文件的储存安全一样,重点在于防范非授权使用。当然,就如同可以对一般文件进行加密一样,也可以对这些非加密的邮件在收到后进行加密。 |
4
cmdOptionKana 2021-02-14 16:14:39 +08:00 via Android
因为加密会很麻烦,收邮件的人怎么解密?你想想,这个加密解密的流程,让服务器做并不合理,还不如让用户自己搞加密。
|
5
BigbyWolf 2021-02-14 16:20:52 +08:00
对加密功能天然应当的认知是因提供此功能服务商提申必要等在近期接收到的信息做参照而形成的,这些古早邮件服务提供商不提供(设计)存储加密功能也是同样原因。
|
6
wd 2021-02-14 16:47:32 +08:00 via iPhone
你可以自己发密文。看看 pgp
|
9
iloveayu 2021-02-14 17:15:20 +08:00
是真的,甚至传输的 TLS 加密都是可选的,SMTP 协议本身是可以明文传输邮件的。
大部分用户不需要也不在乎服务器存储的邮件是否加密,服务商搞这个没利可图呀,明文存还方便搞搞机器学习,“窥探窥探”用户隐私弄点数据,有这个需求的就收发两端自己搞就好了。 你也可以选用明确服务器端加密存储的邮局服务,如 Proton 、Tutanota 这类的,当然了,服务商那边有没有备用密钥可以解,只能看服务商良心了。 如果对邮件安全有很高要求,那基本只能自建了,然后强制 TLS 传输,不加密传输的直接拒绝连接,本地加密存储自己搞。 |
10
wangkun025 2021-02-14 17:15:56 +08:00
如果要加密的话,用什么加密方法?谁掌握私钥?私钥放在哪里?
用非对称加密保存的文本,用户自己丢了私钥的话,是没办法的。 感觉要实现的话,成本太高。 不如让邮件发发送者自己加密。 |
11
dingwen07 2021-02-14 17:28:42 +08:00 via Android
大把的公司传输 TLS 都没开。。。
个人就 PGP,商业 S/MIME,直接签名 /加密。 |
12
akira 2021-02-14 18:42:23 +08:00
没这个需求
|
13
340244120w 2021-02-15 01:41:14 +08:00 via iPhone
搞加密,搜索咋做哦。。。
|
14
flynaj 2021-02-15 12:07:19 +08:00 via Android
需要加密的在用户端做,服务器上没有文件,都是存数据库的。mail 协议发明的时候还没有加密的说法。
|
15
whypool 2021-02-15 12:19:12 +08:00 via Android
加密搜索直接废了
|
16
thedrwu 2021-02-15 20:20:49 +08:00 via Android
搜索没问题。
全局 PGP 加密用了许多年了。 |
17
julyclyde 2021-02-16 13:09:16 +08:00
邮件传输的中间步骤很大程度依赖于邮件的 header 和内容
以至于,即使传输过程中 TLS 了,那也是针对协议而不是邮件本身。服务器自己也必须能够看到明文,而不可能把一个加密内容送给反垃圾、杀毒、记录日志的组件 至于最后落盘的时候是否加密,那纯粹是懒得加,嫌费电 |