Сколько значений может быть вложена строка формата 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 указанного сообщения?

Спасибо за ваше время, я с нетерпением жду вашего ответа.

Источник

3 ответа

Решение

Я нашел свой ответ, хотя в rfc204x и rfc3501 нет никаких ограничений, каждый пробный почтовый сервер налагает свои собственные ограничения, поскольку преувеличенное вложение MIME, похоже, является распространенным способом обойти различные фильтры, такие как спам, блокировка.exe и т. Д. " Вложение MIME превышает предел безопасности ", по-видимому, является популярным сообщением, которое возвращается при отправке 15+ уровней десятичных знаков.

Источник

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))
Источник
Другие вопросы по тегам