Сколько значений может быть вложена строка формата IMAP MIME BODYSTRUCTURE?
Есть ли способ, чтобы строка формата MIME была вложена более чем в 3 десятичных знака при извлечении отдельных частей с сервера IMAP? Например, в разделе 6.4.5 RFC3501, pg56, когда описывается, как анализировать сообщения 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 не конкретизирует это. Если возможно более 3 десятичных знаков в строке формата MIME, как будет выглядеть BODYSTRUCTURE указанного сообщения?
Спасибо за ваше время, я с нетерпением жду вашего ответа.
Решение
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...
Кажется, это явно говорит о том, что верхней границы нет.
Что касается того, что такое сообщение будет использоваться, я не знаю,
Другие решения
Там нет верхнего предела. Дольше всего я видел этого маленького ребенка, где сообщения Content-Description были отредактированы и теперь содержат номера деталей:
* 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))
Я нашел свой ответ, хотя в rfc204x и rfc3501 нет никаких ограничений, каждый пробный почтовый сервер налагает свои собственные ограничения, так как преувеличенное вложение MIME кажется распространенным способом обойти различные фильтры, такие как спам, блокировка .exe и т. Д. » Вложение MIME превышает предел безопасности «, по-видимому, является популярным сообщением, которое возвращается при отправке 15+ уровней десятичных знаков.