从IMAP服务器检索单个部件时，MIME格式字符串是否有任何嵌套方式超过3个小数点？例如，RFC3501第6.4.5节，第56页，当描述如何从服务器解析rfc822消息时，如果我想从IMAP服务器获取明文版的电子邮件，那么它是可能的（并且在处理w时很常见）发布/ rfc822消息附件）
tag FETCH uid BODY[4.2.2.1]
因为rfc822消息可以深入嵌套。因此该格式字符串中有3个小数点。我的问题是，有什么理由，任何类型的MIME消息都可能是这样的吗？
tag FETCH uid BODY[1.2.3.4.5]
或者3个小数点是否可能有最大嵌套量？我还没有在我的测试中找到它，但在我在解析器中实现之前我需要确定，因为RFC3501并不具体。如果MIME格式字符串中有超过3个小数点，那么所述消息的BODYSTRUCTURE会是什么样的？
感谢您的时间，我期待您的回复。
答案 0 :(得分：0)
Rfc3501（您链接）状态
g++这似乎非常明确地表明没有上限。
关于这样的消息将被用于什么，我不知道
答案 1 :(得分：0)
没有上限。我见过的最长的是这个小宝贝，其中内容描述消息已被编辑为包含部件号：
* 1 FETCH (BODYSTRUCTURE (("text" "plain" NIL NIL "Part number 1" "7BIT" 9 1 NIL NIL NIL NIL)("application" "octet-stream" NIL NIL "Part number 2" "BASE64" 14 "qWXKy9s0ny8E1/5/uzNhpg==" ("attachment" ("filename" "foo.bar" "size" "8")) NIL NIL)("message" "rfc822" NIL NIL "Part number 3" "7BIT" 540 ("Thu, 20 May 2004 14:28:50 +0200" "embedded rfc822 message" (("B" NIL "b" "c.d")) NIL NIL (("A" NIL "a" "c.d")) NIL NIL NIL NIL) (("text" "plain" NIL NIL "Part number 3.1" "7BIT" 9 1 NIL ("inline" NIL) ("en" "no" "de") NIL)("application" "octet-stream" NIL NIL "Part number 3.2" "BASE64" 14 NIL NIL NIL NIL) "mixed" ("boundary" "Y") NIL NIL NIL) 24 NIL NIL NIL NIL)(("image" "gif" NIL NIL "Part number 4.1" "BASE64" 0 NIL NIL NIL NIL)("message" "rfc822" NIL NIL "Part number 4.2" "7BIT" 658 ("Thu, 20 May 2004 14:28:50 +0200" "second embedded rfc822 message" (("A" NIL "a" "c.d")) NIL NIL (("B" NIL "b" "c.d")) NIL NIL NIL NIL) (("text" "plain" NIL NIL "Part number 4.2.1" "7BIT" 9 1 NIL NIL NIL NIL)(("text" "plain" NIL NIL "Part number 4.2.2.1" "7BIT" 9 1 NIL NIL "en" NIL)("text" "richtext" NIL NIL "Part number 4.2.2.2" "7BIT" 9 1 NIL NIL NIL NIL) "alternative" ("boundary" "B") NIL NIL NIL) "mixed" ("boundary" "A") NIL NIL NIL) 34 NIL NIL NIL NIL) "mixed" ("boundary" "Z") NIL NIL NIL) "mixed" ("boundary" "X") NIL NIL NIL))
答案 2 :(得分：0)
我找到了答案，虽然rfc204x和rfc3501都没有限制，我试过的每个邮件服务器都强加了它自己的限制，因为夸大的MIME嵌套似乎是绕过垃圾邮件，.exe阻止等各种过滤器的常用方法。 “MIME嵌套超过安全限制”似乎是发送15级以上小数时返回的常用消息。