Должна быть возможность отключить поддержку электронных писем HTML.
Если выбрано:
Привет @MichaelHierweck
чтобы мне было понятнее. В чем проблема (вариант использования) электронной почты в формате HTML?
Примечание: только агенты могут писать электронные письма в формате html, а также ко всем исходящим письмам прикрепляются вложения «в виде обычного текста» (так что, если вы используете pine / mutt и т. Д., У вас нет недостатков).
-Мартин
Наши деловые партнеры старомодны и заботятся о безопасности. Они ожидают, что электронные письма будут как текстовыми / обычными, так и подписанными GnuPG. Но, может быть, в 2016 году старомодно станет наследием ...;)
GnuPG хорош, а также возможен с html-сообщениями (составные с текстом + html внутри). :)
Мы оставляем этот вопрос открытым, чтобы узнать, интересует ли кого-нибудь также текстовые электронные письма.
Я также обычно использую только текстовые сообщения электронной почты. В моей почтовой программе я переключаюсь на HTML-почту только в особых случаях.
Вообще говоря, я бы сказал, что сегодня старомодные пользователи вроде меня должны принять тот факт, что HTML-сообщения являются стандартными.
В случае с zammad, я думаю, все же было бы полезно иметь текстовый редактор электронной почты: у встроенного редактора много проблем с редактированием HTML ... Сегодня, как только я обнаруживаю такую ошибку, я открываю zammad сообщения с Thunderbird и ответ оттуда. Такое случается довольно часто.
Я очень поддержу эту просьбу. Не только потому, что я, как правило, никогда не пишу электронные письма в формате HTML, но и потому, что я привык отправлять клиентам табличные обзоры и информацию с отступом, например
| row 1 | row 2 |
+----------+----------+
| field 11 | field 21 |
| sub 11 | |
| field 12 | field 22 |
+----------+----------+
что выглядит паршиво, нечитабельно и непрофессионально, если смотреть на него в отформатированной среде:
+ ---------- + ---------- +
| строка 1 | ряд 2 |
+ ---------- + ---------- +
| поле 11 | поле 21 |
| sub 11 | |
| поле 12 | поле 22 |
+ ---------- + ---------- +
Идеально было бы, если бы формат мог быть выбран для каждого письма с форматом по умолчанию, который может быть установлен каждым агентом.
Я не совсем уверен, как следует относиться к входящей почте, но, вероятно, я бы посоветовал:
только мой 2с
Это настолько важно, что я только что создал свою учетную запись на github, чтобы прокомментировать это. Письма в формате HTML не позволяют мне использовать Zammad в моем бизнесе. Моя компания выглядела бы глупо, если бы мы отправляли письма в формате HTML.
HTML для электронной почты считается злом большинством профессионалов. Это объяснено в Википедии, поэтому я ожидал, что это станет общеизвестным.
HTML используется слишком часто и вызывает слишком много проблем, среди которых:
Обычно получатель определяет, как она хочет, чтобы электронные письма были представлены / отформатированы. HTML нарушает это правило и позволяет отправителю определять причудливые (нечитаемые?) Шрифты, фоновые изображения и другие навороты, в то время как они частично или полностью исчезают в клиенте получателя, в зависимости от его настроек. Это означает, что ожидания отправителя не оправдываются, а получатель не будет знать, отображается ли почта так, как ожидалось отправителем. Этого не может случиться с открытым текстом.
Я считаю, что обработка открытого текста всегда должна быть на первом месте в разработке и иметь более высокий приоритет. HTML следует считать дополнительным, а не наоборот.
Я согласен и, следовательно, поддерживаю этот вопрос
dito, жду этого варианта с момента первого комментария.
Прежде всего, большое спасибо за ваше участие в проекте с открытым исходным кодом Zammad. Мы осознаем вашу потребность в этом. Однако в настоящее время его нет в вашем (коротком) списке предстоящих функций. Это означает, что мы, вероятно, не будем работать над этим как минимум в следующем году, если не найдем спонсора. Другой вариант - отправить запрос на перенос. Мы рады поддержать вас в том, чтобы получить его в требуемом качестве и форме, чтобы делать это способом Zammad.
Поскольку нет новых данных по определенным требованиям, которые уже достаточно ясны, я прошу вас ограничить вашу потребность в этой функции смайликами в исходном посте. Отправка комментариев создает много шума, отвлекает нас от работы над Zammad и замедляет работу. В противном случае мне придется заблокировать разговор. Не стесняйтесь начать живую дискуссию на нашей доске сообщества https://community.zammad.org/, которая является подходящим местом для этого.
Спасибо за Ваше понимание и поддержку!
Привлечение внимания к этой проблеме. Электронные письма с подтверждением адреса, приходящие от Github, теперь имеют неправильный формат html, и поэтому такие продукты, как ProofPoint, искажают электронную почту при передаче. Следует еще раз пересмотреть стремление к использованию обычного текста в электронной почте, поскольку хрупкое форматирование html вызывает проблемы с коммерческими фильтрами электронной почты. Я согласен, что неразумно ожидать, что GitHub проведет регрессионное тестирование для всех поставщиков, но отсутствие возможности контролировать формат доставки электронной почты как бы возлагает ответственность на GitHub за проведение такого регрессионного тестирования.
Я был бы готов потратить немного денег, чтобы добавить эту функцию, хотя, вероятно, недостаточно, чтобы финансировать ее самостоятельно. Я немного огляделся и увидел ряд других проблем с GitHub, помеченных как prioritised by payment
; Я предполагаю , что означает , что это возможно для пользователей в специальный фонд функции , которые они хотели бы видеть?
Мне также очень нужна поддержка обычных текстовых писем. Лучше всего, если он будет гибким, как указывает @fthommen .
Извините, это снова вышло из-под моего радара.
Свяжитесь с отделом продаж [at] zammad [dot] com.
Наши коллеги выяснят стоимость, и, если она слишком велика, также проверит, подходит ли она для пула платежей для нескольких человек, чтобы продолжить.
Я предполагаю, что это в настоящее время заблокировано будущим редактором Zammad.
Заммад в настоящее время не имеет возможности определить, можете ли вы отформатировать письмо или нет, что, на мой взгляд, может быть проблематичным на данный момент.
Вот неофициальный быстрый взлом, который пытается полностью отключить отправку html-части во всех электронных письмах.
Предупреждение: еще не тестировалось в производстве, могут сломаться другие вещи, ваш пробег может отличаться.
Это патч для экспертов, которые сами запускают Zammad и знают, как применять, тестировать и отлаживать их установку.
Однако, если вы хотите отправлять только текстовые / обычные письма (например, из соображений безопасности), вы можете попробовать.
патч
--- app / models / channel / email_build.rb.org 2021-03-18 17: 43: 54.776830273 +0100
+++ app / models / channel / email_build.rb 2021-03-18 17:49: 45.262137627 +0100
@@ -63,4 +63,9 @@
# генерировать простую деталь
attr [: body] = attr [: body] .html2text
+
`` `
(applied against zammad Version: 3.6.0-1615986441.da478686.buster from the official Debian Buster package,
/ opt / zammad`)
Некоторое время назад мы связались с отделом продаж Zammad по поводу этой функции, и казалось, что она должна была стать настоящим небольшим проектом, выходящим за рамки нашего бюджета. Вместо этого мы добровольно заплатили небольшую трехзначную сумму на https://www.zammad-foundation.org/, чтобы они получили что-то взамен за свой прекрасный бесплатный продукт и поддерживали его. Если вам понравился этот патч, подумайте также об оплате в фонд Zammad. :)
Самый полезный комментарий
Привлечение внимания к этой проблеме. Электронные письма с подтверждением адреса, приходящие от Github, теперь имеют неправильный формат html, и поэтому такие продукты, как ProofPoint, искажают электронную почту при передаче. Следует еще раз пересмотреть стремление к использованию обычного текста в электронной почте, поскольку хрупкое форматирование html вызывает проблемы с коммерческими фильтрами электронной почты. Я согласен, что неразумно ожидать, что GitHub проведет регрессионное тестирование для всех поставщиков, но отсутствие возможности контролировать формат доставки электронной почты как бы возлагает ответственность на GitHub за проведение такого регрессионного тестирования.