Разобрать и отобразить многочастную электронную почту MIME на веб-сайте - PullRequest
Новая
       7

Разобрать и отобразить многочастную электронную почту MIME на веб-сайте

5 голосов
/ 18 июня 2010

У меня есть необработанное электронное письмо (MIME multipart), и я хочу отобразить его на веб-сайте (например, в iframe, с вкладками для части HTML и части с простым текстом и т. Д.).Существуют ли какие-либо модули CPAN или плагины Template :: Toolkit, которые я могу использовать для достижения этой цели?

В настоящий момент мне кажется, что мне придется проанализировать сообщение с помощью Email :: MIME, а затем выполнить итерацию.над всеми частями, и написать обработчик для всех различных типов пантомимы.

Это длинный выстрел, но мне интересно, если кто-нибудь уже все это сделал?Если я попытаюсь сам, то это будет длинный и подверженный ошибкам обработчик процесса записи.

Спасибо за любую помощь.

Ответы [ 3 ]

6 голосов
/ 19 июня 2010

Я на самом деле только что справился с этой проблемой всего несколько месяцев назад. Я добавил функцию электронной почты в продукт, для которого я работаю, и отправляя, и получая. Первой частью была отправка напоминаний пользователям, но мы не хотели управлять возвратами для наших администраторов клиентов, мы решили иметь входящие сообщения, чтобы администраторы могли видеть откаты и ответы без нас, и администраторы могут справиться с настройкой адреса электронной почты, если они нужны.

Из-за этого мы принимаем всю электронную почту, которая отправляется на входящие почтовые ящики, которые мы наблюдаем. Мы используем VERP , чтобы связать электронную почту с пользователем и сохранить всю электронную почту как есть в базе данных. Затем, когда администратор просит просмотреть электронную почту, мы должны проанализировать электронную почту.

Моя первая попытка была очень похожа на предыдущий ответ. Если одна из частей HTML, показать его. Если это текст, покажи это. В противном случае, показать оригинал, сырой электронной почты. Это сломалось очень быстро с несколькими электронными письмами, не сгенерированными sendmail. Outlook, Exchange и некоторые другие почтовые системы этого не делают, для отправки электронной почты они используют несколько компонентов. После долгих копаний и проклятий я обнаружил, что проблема не очень хорошо документирована. С помощью просмотра MHonArc и чтения RFC (RFC2045 и RFC2046) я остановился на решении ниже. Я решил не использовать MHonArc, так как не мог легко использовать функции синтаксического анализа и отображения. Я бы не сказал, что это идеально, но достаточно хорошо, что мы его использовали.

Сначала возьмите сообщение и используйте Email :: MIME для его анализа. Затем вызовите функцию get_part с массивом частей. Email :: MIME дает вам -> parts ().

get_part, для каждой передаваемой части декодирует тип контента, ищет его в хэше и, если он существует, вызывает функцию, связанную с этим типом контента. Если декодер мог дать нам что-то, поместите это в массив результатов.

Последний кусок головоломки - это массив декодеров. По сути, он определяет типы контента, с которыми я могу иметь дело:

  • Текст / HTML
  • текст / обычный
  • message / delivery-status , что на самом деле также простой текст
  • многочастному / смешанный
  • многочастному / связанные
  • многочастному / альтернатива

Не состоящие из нескольких частей разделы, которые я возвращаю как есть. Со смешанным, связанным и альтернативным, я просто вызываю get_parts на этом узле MIME и возвращаю результаты. Поскольку альтернатива является особенной, она имеет дополнительный код после вызова get_parts. Он вернет html, только если он имеет html-часть, или вернет только текстовую часть, в которой есть текстовая часть. Если он не имеет ни того, ни другого, он не вернет ничего действительного.

Преимущество хэша допустимых типов контента в том, что я могу легко добавлять логику для большего количества частей по мере необходимости. И к тому времени, когда вы получите get_parts, у вас должен быть массив всего контента, который вас волнует.

Еще одна вещь, которую я должен упомянуть. В рамках этого мы создали отдельный домен, который фактически обслуживает эти сообщения. Основной домен, над которым работает администратор, откажется обслуживать сообщение и перенаправит браузер в наш пользовательский контент-домен. Этот второй домен будет обслуживать только пользовательский контент. Это должно помочь браузеру должным образом изолировать содержимое от нашего основного домена. См. Ту же политику происхождения (http://en.wikipedia.org/wiki/Same_origin_policy)

4 голосов
/ 18 июня 2010

Для меня это не выглядит трудной работой: 

<code>use Email::MIME;
my $parsed = Email::MIME->new($message);
my @parts = $parsed->parts; # These will be Email::MIME objects, too.
print <<EOF;
<html><head><title>!</title></head><body>
EOF
for my $part (@parts) {    
    my $content_type = $parsed->content_type;
    if ($content_type eq "text/plain") {
         print "<pre>", $part->body (), "
\ n ";} elsif ($ content_type eq" text / html ") {print $ part-> body ();} # Handleеще несколько случаев здесь} print <
2 голосов
/ 18 июня 2010

Повторное использование существующего полного программного обеспечения. MHonArc конвертер почты в HTML имеет отличную поддержку MIME.

...