smtp协议中关于字符替换的总结

最近研究邮件加密技术时，总结了发送电子邮件的一些准则。关于邮件透明加密,推荐一款产品--天御云安推出的隐秘邮，在确保邮件内容加密的同时，部署对于用户也是透明的，既满足加密需求也不影响用户使用习惯。网址： https://mail.tyyunan.com/

互联网电子邮件不是一个完美的系统。邮件可能会在邮递到最终目的地的几个阶段中被损坏。具体来说，通过互联网发送的电子邮件可能会跨越许多网络技术。许多网络和邮件技术不支持SMTP传输中可能的全部功能环境。穿越这些系统的邮件很可能会被修改以便它可以运输。

 

互联网上存在许多广泛部署的不符合要求的MTA。这些MTA使用SMTP协议，可以随时利用它们所在主机的内部数据结构实施更改消息，或者只是简单的中断破坏。

 

以下指南可能对更改数据格式（媒体类型）的所有人都有用，该数据格式应该能够承受最广泛网络技术和已知的损坏的MTA。注意以任何base64方式编码的内容都将满足这些规则，但是一些众所周知的机制，特别是UNIX uuencode工具，将不会。还要注意任何以Quoted-Printable方式编码的内容要在大多数网关上保证无损，但可能有一些网关不会连接到使用EBCDIC字符集的系统。

 

（1）在某些情况下，用于数据的编码可能作为普通网关或用户代理操作的一部分进行更改。特别是从base64转换到Qp编码，反之亦然可能是必要的。这个可能会导致CRLF序列与行混淆并在文本主体中断开。因此，CRLF永远不能被定义为的其他功能除了作为一行的结束符之外。

 

（2）许多系统可以选择描述和存储文本数据使用本地的新建约定。本地新建约定可能不符合RFC822的 CRLF约定 - 已知的系统使用普通CR、普通LF、CRLF或计数记录。结果单独的CR和LF字符通用性不好; 他们可能会在某些系统上丢失或转换为分隔符，并且因此不能使用。

 

（3）NULs的传输（US-ASCII值0）是Internet邮件中存在问题。（这在很大程度上是NUL被作为许多C语言的常用的标准运行时库的终止字符）。使用NUL作为终止字符的习惯如今已经根深蒂固，邮件消息不应该依赖于它们被保存。

 

（4）TAB（HT）字符可能会被误解或可能被错误的自动转换为可变数量的空格。这在某些环境中是不可避免的，特别是那些不基于US-ASCII字符集。这样转换是非常不赞成的，但它可能会发生，因此邮件格式不能长久依赖于TAB（HT）           字符。

 

（5）长度超过76个字符的行可能被包裹或在某些环境中截断。换行或着邮件传输过程强行截断行是非常不赞成的，但在某些情况下不可避免。需要长行的应用程序必须以某种方式区分行数据的软和硬断点。（一个简单的方法是使用quoted-printable编码。）

 

（6）在一行数据上使用“空白空格”字符（空格，TAB（HT））可能会被传输代理丢弃，而其他传输代理可能会用这些字符来填充这些行数据，以便邮件文件中的所有行都是等长。因此，后面的空白空格的持久性，必须不能依赖。

 

（7）许多邮件域使用US-ASCII字符集的变种，或使用如其中包含大部分但不是全部US-ASCII字符的EBCDIC字符集。字符转换网关不能依赖于不在“不变”集中的字符正确翻译。例如，这个发送未解码信息到BITNET(世界教育网路”比特网”)时就存在问题，它是一个EBCDIC系统。类似问题无需穿越网关依然可能会发生，因为许多互联网主机使用US-ASCII以外的字符集。可打印字符串的定义在X.400中增加了一些特殊的限制案例。仅有字符在已知的所有网关中都是一致的，与大写和小写相对应的字符字母A-Z和az-，10位数字0-9，和以下十一个特殊字符：

 

        “'”    （US-ASCII十进制值39）

        “（” （US-ASCII十进制值40）

        “）” （US-ASCII十进制值41）

        “+”  （US-ASCII十进制值43）

        “，” （US-ASCII十进制值44）

        “ - ” （US-ASCII十进制值45）

        “”    （US-ASCII十进制值46）

        “/”   （US-ASCII十进制值47）

        “：” （US-ASCII十进制值58）

        “=”  （US-ASCII十进制值61）

        “？”  （US-ASCII十进制值63）

 

      一封最简易的邮件将限制本身在相对较短的文本行中，而这些文本和行的组成都             来自上面所述的73个字符集中。base64编码遵循此规则。

 

（8）一些邮件传输代理会破坏包含某些字母的字符串的数据 。特别是，一行数据中目前已知会被一些SMTP服务器给损坏，和从五个字符“From ”（第五个字符是一个空格）开始的一行数据也常常被破坏。一个严谨的代理组织可以防止因对数据编码而造成的数据损坏（例如，在QP编码中使用“= 46rom”代替由“From ”开头的一行数据中“From ”，“= 2E”代替一行上的单独句号(“.”)）。请注意，上面的列表不是MTAs推荐的列表的做法。RFC 821 中MTA禁止改变空白空格或着截断一个比较长的行数据。这些不好的习惯和做法在已经建立的网络上存在了，但是在处理它们可能导致的不良影响时，实现应该是健壮的。

关键字：smtp  邮件安全  透明加密

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69911143/viewspace-2641989/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/69911143/viewspace-2641989/