采用 postfix 发送邮件，默认没有采用 TLS 加密传输，对方的服务器有可能会提示告警（例如 gmail）。另外，邮件传输采用明文，如果不加密，也存在被人窥视的风险。因此建议修改 postfix 的配置，默认采用 TLS 加密。当然，这需要对方的服务器也支持加密，目前绝大多数邮件服务器都支持 TLS 传输。
修改 /etc/postfix/main.cf 文件，增加以下一行配置即可：
smtp_tls_security_level = may修改了配置文件，使用命令重启 postfix：
sudo systemctl restart postfix
默认情况下，SSH服务器会启用各种尽可能的加密算法，其中包含一些很弱的加密算法，这确保了客户端广泛的接入，但是的确会引入一些风险。企业环境中设备是可控的，因此可以去掉弱加密算法而只保留特定的强加密算法。
Linux环境中查询以下帮助，可以了解包含算法在内的各项配置信息：
man 5 sshd_config
修改/etc/ssh/sshd_config文件，指定Ciphers采用强加密算法即可，例如，将下列语句直接加入到该文件后面：
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes256-cbc
当然，最后要重启ssh服务才能使配置生效。
DNS污染可能是一个比较普遍的问题，主要表现在：（1）DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在，要么就是个和域名完全无关系的地址。（2）IP地址虽然可能是对的，但是其他参数被莫名修改，例如TTL参数等。
测试了各类DNS服务器，例如阿里DNS、DNSPod（鹅厂）、Google DNS等。无一例外，最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲，DNS协议本身非常随意、非常粗糙，是典型的互联网蛮荒时代的产物，比如面向UDP、无加密、无鉴权等，因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段，当然能解决这个问题，不过既然目前绝大部分设备还只支持IPv4协议栈，因此我们还是不得不修修补补来解决这个污染问题。
最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式，不过不太通用，需要私有的客户端程序配合。实际上可以不用搞这么复杂，自己建立加密通道，传递DNS消息即可。例如，参考下图的拓扑逻辑：
在这个网络中，有两个关键程序：dnsProxy和dnsAgent。
dnsProxy顾名思义就是个Proxy，本身并不负责DNS协议的解析，也不保存DNS的查询结果等信息，只是单纯地将DNS消息传递给真正的DNS服务器，并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接，例如TLS、SSL加密等，甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口，这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口，网络上那些看不见的手，往往就是扫描并篡改53接口的数据包。这个小程序跑在境外（大家都懂的）的一台VPS设备上，推荐采用DigitalOcean，专业的云计算服务商，采用SSD硬盘，价格公道，我们一直用TA，如果你有兴趣的话，请点击这里自行了解细节。
dnsAgent是另一个小程序，主要负责建立与dnsProxy的加密连接，接收普通设备的DNS请求并将其传递给dnsProxy，同时返回DNS结果给普通计算设备。对于网内设备而言，dnsAgent就是个伪装的DNS服务器。同样，dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中，dnsAgent跑在一台常年吃灰的树莓派上（还是第一代的）。
实现这些仅仅需要一点UDP、TCP的网络知识，甚至不需要了解DNS协议的细节，无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然，有些网站始终是打不开的，这是另一个与DNS无关的话题了。
首先必须要说明的是：webRTC是非常好的技术，以至于我现在仍然在怀疑，放弃webRTC是不是个明智的决定，内心依然是忐忑不安。
然而现状就是将webRTC从MSS新版本中砍掉了。下面试图说明清楚做决定时的一些考虑。
从webRTC技术的发展脉络看，感觉ta更适合于公共网络的通信，尤其是越来越像专为google hangouts服务。由于是服务于公共网络，因此“加密”提高到一个非常重要的位置，几乎达到了神经质的地步。webRTC设计之初就没有考虑过传统的VoIP网络（尽管该技术来自于收购的GIPS团队，而该团队本身就是为VoIP网络开发出身的），从传输到业务，基本都特立独行。当然，这没什么不好，只是由于与传统VoIP网络切割开来，实在让人经常感到惋惜。
既然没有考虑传统VoIP网络，当然就更不可能考虑网络部署的多样性。全方位加密固然让自己显得安全，带来心理上的安慰，但也增加了网络部署的复杂性（VoIP本身已经够复杂了）。就一般的VoIP应用而言，“salt+MD5”以及SRTP已经足够保证通信的安全性和私密性。而最新的webRTC（不特别说明的话，这里我们总是指Chrome的webRTC实现）要求getUserMedia等操作必须是来自加密（HTTPS）的网站，websocket也必须进行加密。这也就是说，用户必须要为webRTC服务器（通常也是呼叫服务器或者IPPBX）部署单独的签名加密（TLS或者SSL）。对于提供公众服务的网站而言，部署TLS/SSL不是太大问题，而要求中小企业申请签名并部署在呼叫服务器中，这毫无疑问极大地增加了系统的复杂度，增加了部署难度，而且这样做的意义又有多大了？在企业通信网络里与其这样增加复杂度（网络复杂度和管理复杂度），还不如干脆直接建立VPN网络，方案很成熟，加密更全面，保护更周到，方式方法也简单得多。
这就是我们感觉webRTC只适合公众网络并且已经神经质的原因之一。何况，“加密”有时候更多的是个管理问题而不是技术问题。
webRTC另一个宏大的目标是提供各平台统一的用户体验。愿望是很美好的，但是是否能实现值得商榷。把所有的处理都放入浏览器，固然增加了可移植性，但最大的问题也就是牺牲了平台的独特性和高效性。比如在移动平台，webRTC的耗电量就明显偏高。而且在移动平台各种莫名其妙的设定，极大地损害了用户体验，比如播放ring-back tone，居然要求用户必须点击一个按钮才能继续（是我out了么？），这实在是太扯了。
而最被我们诟病的是兼容性。webRTC基本没有什么兼容性可言。按道理已经发布这么久了，多少应该在一些关键点上考虑一下兼容性，然而并没有。这对一个像google hangouts这样的网站来说，不是大问题，用户无非升级一下chrome好了。而对部署在许许多多用户voip网络中的PBX或者webRTC服务器而言，就是噩梦了。用户升级了Chrome，就必须同时升级服务器，如果不升级服务器，就必须降级Chrome。与之相比，microsoft对兼容性的考虑简直贴心贴肺。
这种对兼容性的唾弃有时候甚至直接表现在产品本身。比如当初的Gtalk，直接就放弃了，我们花费大量时间精力对接Gtalk，最后也是然并卵。对webRTC也会产生同样的顾虑。
webRTC当然有很多非常优秀的技术特点，比如源自GIPS的回音消除技术、超强的语音编解码技术等。思虑再三，决定还是不再跟随，砍了算了，以后再说吧。