Комментарии 9
Как надёжный вариант решения проблемы с подстановкой дисклеймера всем входящим письмам: вешать эту штуку не на общий smtpd postfix-а, а на submission-сервис (который вешается на порт 587, см. вторую запись в master.cf)?
Правильно понимаю, что 587 порт будет использоваться как дополнительный к 25у порту? И придется использовать 587 порт в настройках SMTP у сотрудников? Если так, то может возникнуть проблема, когда кто-то из сотрудников будет использовать 25 порт, вместо 587, например с личного телефона, либо кто-то сам установит или переустановит почтовый клиент на рабочем месте, где выставятся настройки по умолчанию на 25ый порт. Со временем можно запутаться в этих настройках, и корпоративная подпись в письмах не будет подставляться у части сотрудников. Все-таки submission-сервис лучше использовать для того, чтобы не перезагружать работой основной сервис, работающий на 25 порту.
Вы неправы.
В такой конфигурации 25-й порт используется только для подключения внешних серверов. Например, никакой клиентской аутентификации на нём нет, и у сотрудника просто ничего не заработает по 25-му порту.
Не бойтесь, никаких проблем не возникает. Submission сервис нужен не для «разгрузки», а именно для того, чтобы можно было надёжно различать почту исходящую и проходящую или входящую, потому, что иначе всё это для сервера вообще никак не различается. А как следствие различения — все плюшки, такие, как разные правила обработки, защиты от брутфорса и тому подобное.
Что касается умолчаний, то во-первых наоборот шансов получить автоматически 587 больше (например, он по умолчанию в андроидском почтовом клиенте, а вовсе не 25), а во-вторых, существует такая волшебная вещь как сервер автоконфигурации, которая в итоге свела нам уровень техподдержки почты (а почтовых доменов разных клиентов у нас несколько десятков) практически к нулю, потому, что настраивается всё само.
Так вот, я и предлагал гарантированно различать, «наша» это почта или нет, по сервису, который письмо принял.
В такой конфигурации 25-й порт используется только для подключения внешних серверов. Например, никакой клиентской аутентификации на нём нет, и у сотрудника просто ничего не заработает по 25-му порту.
Не бойтесь, никаких проблем не возникает. Submission сервис нужен не для «разгрузки», а именно для того, чтобы можно было надёжно различать почту исходящую и проходящую или входящую, потому, что иначе всё это для сервера вообще никак не различается. А как следствие различения — все плюшки, такие, как разные правила обработки, защиты от брутфорса и тому подобное.
Что касается умолчаний, то во-первых наоборот шансов получить автоматически 587 больше (например, он по умолчанию в андроидском почтовом клиенте, а вовсе не 25), а во-вторых, существует такая волшебная вещь как сервер автоконфигурации, которая в итоге свела нам уровень техподдержки почты (а почтовых доменов разных клиентов у нас несколько десятков) практически к нулю, потому, что настраивается всё само.
Так вот, я и предлагал гарантированно различать, «наша» это почта или нет, по сервису, который письмо принял.
Спасибо за разъяснения, буду иметь в виду на будущее. А то у меня были сомнения, по поводу использования Submission для таких целей. Правда пока не думаю, что буду переделывать текущий сервер в виду того, что данная проверка на «свой-чужой» уже прописана в самом скрипте "disclaimer".
Я понимаю. Я в процессе перехода с одной схемы на другую несколько лет держал сервер, который поддерживает обе — чтобы создать минимум проблем.
А вообще ваша схема может страдать от одной проблемы. Представьте себе, что из вашей сети отправляют почту куда-то наружу, а там она пересылается обратно на ваш сервер, при этом адрес источника (SMTP Envelope Mail From, а также заголовок From в теле письма) не меняется. В итоге ваш сервер получает извне письмо с адресом, который он посчитает «своим». Насколько я понимаю, ваш сервер допишет второй дисклеймер (первый он дописал при отправке письма наружу). Использование для исходящей почты отдельного submission, естественно, исключает это.
А вообще ваша схема может страдать от одной проблемы. Представьте себе, что из вашей сети отправляют почту куда-то наружу, а там она пересылается обратно на ваш сервер, при этом адрес источника (SMTP Envelope Mail From, а также заголовок From в теле письма) не меняется. В итоге ваш сервер получает извне письмо с адресом, который он посчитает «своим». Насколько я понимаю, ваш сервер допишет второй дисклеймер (первый он дописал при отправке письма наружу). Использование для исходящей почты отдельного submission, естественно, исключает это.
Когда понял, что подпись будет вставляться в каждое письмо, то исследовал и эту проблему тоже. Действительно, иногда в письмах заголовки "From:" могут повторяться несколько раз во время переписки, но, оказывается, что эта проблема решена в первичном скрипте "disclaimer". Дело в том, что там есть такая строчка:
В ней фильтр происходит по первому нахождению строки "From:". Получается, будет это ответ на письмо или его пересылка, первое вхождение строки "From:" будет с реальным значением адресата, кто отправил письмо, поэтому в любое входящее письмо не будет подставлена подпись. На практике, мне пока еще не попадались такие входящие письма, чтобы не был изменен адрес источника "From:" при первом его нахождении в письме.
- from_address=`grep -m 1 «From:» in.$$ | cut -d "<" -f 2 | cut -d ">" -f 1`
В ней фильтр происходит по первому нахождению строки "From:". Получается, будет это ответ на письмо или его пересылка, первое вхождение строки "From:" будет с реальным значением адресата, кто отправил письмо, поэтому в любое входящее письмо не будет подставлена подпись. На практике, мне пока еще не попадались такие входящие письма, чтобы не был изменен адрес источника "From:" при первом его нахождении в письме.
Разве подпись при ответе должна цитироваться? Ряд почтовых клиентов вполне успешно опускают её при ответе.
Графической логотип в подписи — зло. Вроде как, большинство это понимает — лично мне довольно редко встречается.
Графической логотип в подписи — зло. Вроде как, большинство это понимает — лично мне довольно редко встречается.
Разве подпись при ответе должна цитироваться?
Должна цитироваться подпись или нет — это выбор каждого. Нравится — цитируйте, не нравится — не цитируйте. Жестких требований пока никто не выдвигал, да и статья то не об этом…
Графической логотип в подписи — зло.
Тут все просто:
- Убедите в этом руководство — будете делать без addAttachFilter
- Не убедите — будете делать комплексно
Хочу поделиться еще двумя "подводными камнями" с автоподписью и способами их решения.
Postfix + внешние фильтры = частично обрезанные входящие письма
Эта проблема подходит для любого типа фильтра, который используется в Postfix, например AntiSpamFilter, AntiVirusFilter и т.д.
Иногда на сервер приходят письма, которые с виду похожи на обычные письма, но обрезанные.
Вид писем может быть разный, и если прислать адресату письмо повторно, то письмо обрежется в том же месте, при этом, как правило, все вложения в письме тоже обрезаются.
Происходит это из-за того, что утилита 'sendmail' или 'dovecot-lda' (зависит от того, чем вы пользуетесь в фильтрах) по умолчанию проверяет письма на наличие строк, содержащих одну единственную точку.
Если такая строка есть, то это признак конца почтового сообщения в интерпретации 'sendmail' или 'dovecot-lda', после чего всё остальное содержимое ниже точки обрежется.
Для игнорирования таких строк с точкой, используйте следующую конструкцию в своих фильтрах:
Редкий баг с обрезкой писем должен пропасть.
А нужна ли картинка в автоподписи именно в 'этом' исходящем письме?
Бывают такие структуры писем, при которых письмо определяется как текстовое.
Соответственно в таких случаях нам НЕ нужно в письмо вставлять картинку.
'altermime' хорошо справляется с этой особенностью структур и умеет вставлять правильно нужный тип подписи, включая комбинированный (text, html и base64).
Но вставлять картинку приходится другой утилитой 'addAttachFilter', и нам нужно понимать, когда это нужно делать, а когда нет.
Нужно ознакомиться со структурой 'Content-Type: ', чтобы разобраться со структурой писем.
За счет этой структуры формируется отображение всего письма и определяется то, будет ли письмо в текстовом или HTML формате.
Ссылка для ознакомления: Почтовые сообщения с типом вложений
Рассмотрим варианты 'Content-Type: ', при которых письмо будет текстовым:
Во всех остальных случаях письмо будет в формате HTML.
Для выполнения такой проверки, измените скрипт следующим образом:
Удалите строки (смотри "Третий подводный камень"):
Добавьте вместо них следующий код:
Таким образом, картинка будет добавляться только в HTML письма.
Postfix + внешние фильтры = частично обрезанные входящие письма
Эта проблема подходит для любого типа фильтра, который используется в Postfix, например AntiSpamFilter, AntiVirusFilter и т.д.
Иногда на сервер приходят письма, которые с виду похожи на обычные письма, но обрезанные.
Вид писем может быть разный, и если прислать адресату письмо повторно, то письмо обрежется в том же месте, при этом, как правило, все вложения в письме тоже обрезаются.
Происходит это из-за того, что утилита 'sendmail' или 'dovecot-lda' (зависит от того, чем вы пользуетесь в фильтрах) по умолчанию проверяет письма на наличие строк, содержащих одну единственную точку.
Если такая строка есть, то это признак конца почтового сообщения в интерпретации 'sendmail' или 'dovecot-lda', после чего всё остальное содержимое ниже точки обрежется.
Для игнорирования таких строк с точкой, используйте следующую конструкцию в своих фильтрах:
/usr/sbin/sendmail -oi "$@" < in.$$ # ключ -oi игнорирует строки, содержащие одну единственную точку
Редкий баг с обрезкой писем должен пропасть.
А нужна ли картинка в автоподписи именно в 'этом' исходящем письме?
Бывают такие структуры писем, при которых письмо определяется как текстовое.
Соответственно в таких случаях нам НЕ нужно в письмо вставлять картинку.
'altermime' хорошо справляется с этой особенностью структур и умеет вставлять правильно нужный тип подписи, включая комбинированный (text, html и base64).
Но вставлять картинку приходится другой утилитой 'addAttachFilter', и нам нужно понимать, когда это нужно делать, а когда нет.
Нужно ознакомиться со структурой 'Content-Type: ', чтобы разобраться со структурой писем.
За счет этой структуры формируется отображение всего письма и определяется то, будет ли письмо в текстовом или HTML формате.
Ссылка для ознакомления: Почтовые сообщения с типом вложений
Рассмотрим варианты 'Content-Type: ', при которых письмо будет текстовым:
- Отсутствует (пустое письмо в формате 'text/plain' без вложений);
- Первое вхождение — 'text/plain' (например обычное текстовое письмо);
- Первое вхождение — 'multipart/mixed', второе вхождение — 'text/plain' (например письмо с вложением);
- Первое вхождение — 'multipart/mixed', второе вхождение — любое, отличное от 'text/html', 'multipart/related' и 'multipart/alternative' (например пустое письмо с вложением);
Во всех остальных случаях письмо будет в формате HTML.
Для выполнения такой проверки, измените скрипт следующим образом:
Удалите строки (смотри "Третий подводный камень"):
cat in.$$ | $INSPECT_DIR/addAttachFilter.pl > pic.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
cat pic.$$ > in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
Добавьте вместо них следующий код:
ContentTypeFirst=`grep -m 1 '^Content-Type: ' in.$$ | cut -d " " -f 2 | cut -d ";" -f 1`
ContentTypeMixed=`grep -m 2 '^Content-Type: ' in.$$ | cut -d " " -f 2 | cut -d ";" -f 1 | tail -n 1`
isHTML=true
if [ "$ContentTypeFirst" = "" ] || [ "$ContentTypeFirst" = "text/plain" ]; then isHTML=false; fi
if [ "$ContentTypeFirst" = "multipart/mixed" ] && [ "$ContentTypeMixed" = "text/plain" ]; then isHTML=false; fi
if [ "$ContentTypeFirst" = "multipart/mixed" ] && [ "$ContentTypeMixed" != "text/html" ] && [ "$ContentTypeMixed" != "multipart/related" ] && [ "$ContentTypeMixed" != "multipart/alternative" ]; then isHTML=false; fi
if $isHTML ; then
cat in.$$ | $INSPECT_DIR/addAttachFilter.pl > pic.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
cat pic.$$ > in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
fi
Таким образом, картинка будет добавляться только в HTML письма.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Унифицированная динамическая корпоративная подпись с логотипом Postfix + alterMIME + addAttachFilter + Active Directory или MySQL