Проанализируйте и отобразите MIME многослойная электронная почта на веб-сайте
У меня есть необработанное электронное письмо, (многослойный MIME), и я хочу отобразить это на веб-сайте (например, в iframe, с вкладками для части HTML и части простого текста, и т.д.). Есть ли любые модули CPAN или Шаблон:: плагины Инструментария, которые я могу использовать, чтобы помочь мне достигнуть этого?
В данный момент похоже, что я должен буду проанализировать сообщение с электронной почтой:: MIME, затем выполните итерации по всем частям и запишите обработчик для всех различных типов пантомимы.
Это - съемка общим планом, но я задаюсь вопросом, сделал ли кто-либо уже все это? Это будет долгой и подверженной ошибкам записью процесса обработчики, если я делаю попытку его сам.
Спасибо за любую справку.
3 ответа
Мне это не кажется сложной задачей:
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 (), "</pre>\n";
}
elsif ($content_type eq "text/html") {
print $part->body ();
}
# Handle some more cases here
}
print <<EOF;
</body></html>
EOF
На самом деле я справился с этой проблемой всего несколько месяцев назад. Я добавил функцию электронной почты в продукт, над которым работаю, как для отправки, так и для получения. Первая часть заключалась в отправке напоминаний пользователям, но мы не хотели управлять возвратами для наших администраторов клиентов, мы решили создать почтовый ящик для сообщений, в котором администраторы могли бы видеть отказы и ответы без нас, а администраторы могли бы заниматься настройкой адреса электронной почты при необходимости.
По этой причине мы принимаем все электронные письма, отправляемые в почтовый ящик, который мы смотрим. Мы используем VERP , чтобы связать электронное письмо с пользователем и хранить все электронное письмо в том виде, в каком оно есть в базе данных. Затем, когда администратор запрашивает электронное письмо, мы должны его проанализировать.
Моя первая попытка была очень похожа на предыдущий ответ. Если одна из частей html, покажите ее. Если это текст, покажите его. В противном случае покажите исходное необработанное электронное письмо. Это быстро сломалось с несколькими электронными письмами, созданными не с помощью sendmail. Outlook, Exchange и некоторые другие почтовые системы этого не делают, они используют составные части для отправки электронной почты. После долгих поисков и ругательств я обнаружил, что проблема не совсем документирована. С помощью просмотра MHonArc и чтения RFC (RFC2045 и RFC2046) я остановился на решении, приведенном ниже. Я решил не использовать MHonArc, так как мне было нелегко повторно использовать функции синтаксического анализа и отображения. Я бы не сказал, что это идеально, но мы использовали его.
Сначала возьмите сообщение и используйте Email :: MIME для его анализа. Затем вызовите функцию get_part с массивом частей, который Email :: MIME дает с помощью -> parts ().
get_part для каждой переданной части декодирует тип контента, ищет его в хэше и, если он существует, вызывает функцию, связанную с этим типом контента. Если декодер смог что-то нам дать, поместите это в массив результатов.
Последний кусок головоломки - это массив декодера. По сути, он определяет типы контента, с которыми я могу иметь дело:
- text / html
- text / plain
- message / delivery-status , что на самом деле также является обычным текстом
- multipart / mixed
- multipart / related
- multipart / alternate
Разделы, не являющиеся составными частями, я возвращаю как есть. Со смешанными, связанными и альтернативными я просто вызываю get_parts на этом узле MIME и возвращаю результаты. Поскольку альтернатива особенная, она содержит дополнительный код после вызова get_parts. Он вернет только html, если у него есть html-часть, или он вернет только текстовую часть, в которой есть текстовая часть. Если у него нет ни того, ни другого, он не вернет ничего действительного.
Преимущество хеширования допустимых типов контента в том, что я могу легко добавлять логику для большего количества частей по мере необходимости. И к тому времени, когда вы закончите get_parts, у вас должен быть массив всего интересующего вас контента.
Еще один момент, о котором стоит упомянуть. В рамках этого мы создали отдельный домен, который фактически обслуживает эти сообщения. Основной домен, на котором работает администратор, откажется обслуживать сообщение и перенаправит браузер на наш домен пользовательского контента. Этот второй домен будет обслуживать только пользовательский контент. Это поможет браузеру правильно изолировать контент от нашего основного домена. См. Ту же политику происхождения ( http: //en.wikipedia.org / wiki / Same_origin_policy )
Повторное использование существующего готового программного обеспечения. Конвертер MHonArc mail-to-HTML имеет отличную поддержку MIME.