Если вы измените политику на strict
:
Parser(policy=policy.strict).parse(eml_file)
, парсер вызовет email.errors.StartBoundaryNotFoundDefect
, описанный в документах как:
StartBoundaryNotFoundDefect
- Начальная граница, указанная в заголовке Content-Type, так и не была найдена.
Если вы анализируете сообщение с помощью policy.default
и затем просматриваете его defects
, оно содержит два дефекта:
[StartBoundaryNotFoundDefect(), MultipartInvariantViolationDefect()]
MultipartInvariantViolationDefect
- Сообщение, заявленное как составное, но не найдено.Обратите внимание, что когда сообщение имеет этот дефект, его метод is_multipart () может возвращать false, даже если его тип содержимого претендует на то, чтобы быть составным.
Следствием StartBoundaryNotFoundDefect
является то, что синтаксический анализатор прекращает синтаксический анализ иустанавливает полезную нагрузку сообщения для тела, которое было захвачено до сих пор - в данном случае ничего, поэтому полезная нагрузка представляет собой пустую строку, вызывающую исключение, которое вы видите, когда запускаете свой код.
Возможно, фактчто Python не проверяет, является ли полезная нагрузка list
, прежде чем вызвать copy()
, это ошибка.
На практике вы должны обрабатывать эти сообщения, либо заключая итерацию вложений в try/except
, обуславливая итерацию для содержимого msg.defects
, либо анализируя с policy.strict
, и отбрасывая все сообщения, сообщающиедефекты.