У меня есть коллекция mbox, которую я использую для тестирования парсеров MIME.
https://github.com/jstedfast/MimeKit/tree/master/UnitTests/TestData/mbox
Эта ссылка представляет собой каталог, содержащий несколько файлов *.mbox.txt и их эквивалентные файлы сводки (это лишь некоторые метаданные о каждом сообщении, которые должно быть легко получить из сообщения после того, как синтаксический анализатор проанализировал его из mbox).
Есть также некоторые *.html файлы, которые являются только извлеченными телами HTML-сообщений, которыеиспользуются для проверки логики для выяснения, какая часть тела является фактическим телом сообщения.Вы, вероятно, можете игнорировать это, поскольку речь идет не о rfc-совместимости.
Основной mbox для просмотра и использования - это файл jwz.mbox.txt - это файл mbox, который я получил от Джейми Завински из Netscape Mail, известного вначало 2000-х годов для тестирования парсера Netscape Mail.
simple.mbox.txt - это очень короткий mbox из 3 сообщений с вложенными мультипаратами, использующими разные наборы граничных маркеров.Второе и третье сообщения - это два, которые, скорее всего, сломают парсеры (первое может сломать случайные парсеры mime, написанные новичками на sourceforge или github, но ничего серьезного не написанные).Второе сообщение имеет все вложенные мультипликаторы, используя boundary="x", что нарушит парсеры, которые не используют граничный стек.Третье сообщение имеет вложенные мультипликаторы, которые используют пустую границу строки (например, boundary="").
Затем есть content-length.mbox.txt для проверки правильности обработки синтаксическим анализатором заголовков Content-Length.
unmunged.mbox.txt похоже, что это было случайно зафиксировано - похоже, что я написал это, чтобы проверить, что Thunderbird сделал с заголовками Content-Length и без связи со строками?
В любом случае, чтобы увидеть, как я сгенерировал вывод для сводкифайлы, которые вы можете проверить https://github.com/jstedfast/MimeKit/blob/master/UnitTests/MimeParserTests.cs#L624
Такие методы, как DumpMimeTree и т. д., перечислены в списке выше этого метода в файле.
У меня есть очень похожий набор тестов для моего синтаксического анализатора C MIMEа также (если вы предпочитаете читать C, а не C #): https://github.com/jstedfast/gmime/blob/master/tests/test-parser.c
Дополнительные мысли:
При оценке синтаксических анализаторов MIME следует помнить, что вы на самом деле не хотитестрогое соблюдение rfc при разборе, потому что это означает, что многие сообщения не будут проанализированы.Что вам действительно нужно, так это библиотека, которая будет обрабатывать как можно больше ошибок при выводе новых сообщений, которые строго соответствуют rfcs (насколько это возможно, в любом случае).
Хотя эти файлы mbox должны быть полезны дляанализаторы, которые вы тестируете, по крайней мере достаточно надежны, чтобы справиться с ними, это не обязательно конец тестирования.
Одна из следующих вещей, которые я делаю при оценке синтаксического анализатора MIME, - проверка того, как анализатор анализирует заголовки адресов,Делает ли это что-то глупое, например разделение значения заголовка на ,?Если это так, это вышло.Я бы, вероятно, сказал, что лучше использовать подход токенизатора, или, возможно, даже не стоит об этом думать.
То же самое относится и к декодированию rfc2047.
Вот напыщенная речь, которую я написал в 2013 году, когда был вваша позиция в поисках достаточно хорошего парсера MIME для C # /. NET: https://jeffreystedfast.blogspot.com/2013/09/time-for-rant-on-mime-parsers.html
Это ссылка на предыдущую статью, которую я написал, в которой рассказывается о том, почему декодирование заголовков (rfc2047) трудно сделать правильно: https://jeffreystedfast.blogspot.com/2013/08/why-decoding-rfc2047-encoded-headers-is.html
Я полагаю, что проблема с попыткой оценить библиотеку MIME-парсера / электронной почты заключается в том, что вам необходимо быть близко знакомыми со спецификациями, чтобы иметь большую уверенность в попытках оценить их за пределамипросто "может ли он разобрать мой случайный набор сообщений?"
Я надеюсь, что это было полезно, но ... да, если ваш опыт похож на мой в далеком 2013 году в поисках приличного синтаксического анализатора C #,вам нужно написать свой собственный - просто, пожалуйста, пожалуйста, прочитайте и следуйте спецификациям, если вы делаете, потому что в противном случае вы просто в конечном итогепредоставление другим разработчикам электронной почты кошмаров.