IMAP MIME BODYSTRUCTURE 格式字符串可以嵌套多少个值？答案

【问题标题】：How many values can IMAP MIME BODYSTRUCTURE format string be nested?IMAP MIME BODYSTRUCTURE 格式字符串可以嵌套多少个值？
【发布时间】：2016-04-21 11:57:19
【问题描述】：

在从 IMAP 服务器检索单个部分时，MIME 格式字符串是否可以嵌套超过 3 个小数点？例如，RFC3501 第 6.4.5 节，pg56，在描述如何解析来自服务器的 rfc822 消息时，如果我想从 IMAP 服务器获取电子邮件的明文版本，这是可能的（并且在处理 w/rfc822 消息时很常见 w /附件）发布

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 会是什么样子？

感谢您的宝贵时间，期待您的回复。

【问题讨论】：

标签： php imap mime mime-mail

【解决方案1】：

Rfc3501（您链接的）状态

BODY[<section>]<<partial>>

    The text of a particular body section.  The section
    specification is a set of zero or more part specifiers
    delimited by periods...

这似乎非常明确地表明没有上限。

至于这样的消息将用于什么，我不知道

【讨论】：

对我来说，“零个或多个部分说明符”没有明确声明“没有上限”。感谢您的意见，但如果您通过详细说明带有 4 个或更多句点的 BODYSTRUCTURE 的外观，使您的答案更加清晰/具体，我将不胜感激。我和我的测试人员已经解析了大量的电子邮件，但还没有找到这样的例子。在 rfc822 消息之外，我还没有在 section 参数中看到超过 2 个句点。现在，我认为理论上是可能的，但实际上不会发生。
我不知道关于 RFC 的任何正式定义 - 所以你可能是对的 - 但值得注意的是，XML 规范和正则表达式都使用了许多 n >= 0 的短语。
XML 和正则表达式是什么意思？我的问题与此无关。
抱歉，如果我不清楚。我不同意你对规范的阅读，所以我给出了几个突出的例子，其中术语“零或更多”被认为是指n >= 0，并且明确不包括上限。一个例子是regular expressions。这并不是说有人会费心以这种方式实现它——或者它曾经被使用过——只是规范说这是可能的。
无需道歉，我从技术上理解 >=、XML 和 RegEx 是什么。为了证明“没有上限”，您必须向我展示一个 BODYSTRUCTURE 来证明这一点，在此之前我必须在 MIME 消息只能嵌套到目前为止（即小数点后 3 位）的假设下对我的客户端进行编码点。虽然 RFC 没有规定上限，但上限将是 MIME 的限制。

【解决方案2】：

没有上限。我见过最长的是这个小宝贝，其中的内容描述消息已被编辑以包含零件编号：

* 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))

【讨论】：

谢谢你的回答，我想知道你什么时候插话。理论上没有上限，但目前看来，MIME 消息不可能小数点后 3 位以上？
这当然是可能的。我可以创建任意复杂的 MIME 消息，其深度可随您的需要而定。您可以在代码中设置上限，但 3 非常低。 “我在实践中只见过 3，所以我会使用 3”不是一个好的设计范式。 “我在实践中只见过 3 个，所以我会使用 16 个”会更有弹性。为什么要设置这么低的限制？
好吧，我正试图弄清楚如何准确地解析这些消息。到目前为止，我的解析器只能转到 1.2.3，但是现在你提到了，即使实际的 MIME 消息表示数据（如在真实消息中，表示真正的电子邮件结构，而不是仅仅一堆任意复杂的不代表真实数据的左括号）可能仅限于 3 个十进制数 - 我会让它有更多功能。
我对某事有点困惑，请注意第 5 个车身结构，第 3.2 部分。 BODYSTRUCTURE有2个扩展值，第一个是“混合”，下一个是原子值24。24是什么意思？
我认为导致 BODYSTRUCTURE 的消息超过 3 个？（顺便说一句，我是通过提要阅读的，所以我何时加入取决于我的提要阅读器和提要阅读的变幻莫测。）

【解决方案3】：

我找到了答案，虽然 rfc204x 和 rfc3501 没有限制，但我尝试过的每个邮件服务器都有自己的限制，因为夸张的 MIME 嵌套似乎是绕过各种过滤器（如垃圾邮件、.exe 阻塞、等等。“MIME 嵌套超出安全限制”似乎是发送 15 级以上小数时返回的流行消息。

【讨论】：

除非您打算测试所有可能的邮件服务器，否则保持稳健的唯一方法是支持任意深度。如果您在内部执行此操作并且知道您的邮件服务器有特定的限制，那么这是一种有效的方法，但如果您的代码将在野外使用，这个限制有时会咬人