Comments 15
докерфайл с примерами конфигов надо на гитхаб выложить, а в статье описать проблему, ключевые моменты решения, сомнения и т.д.
с гитхаба легко стянуть и попробовать, а выковыривать код с хабра — сомнительное удовольствие ))
с гитхаба легко стянуть и попробовать, а выковыривать код с хабра — сомнительное удовольствие ))
я больше скажу: в докерхабе образов, решающих данную задачу как за баней достаточно. :)
Проблему и ключевые моменты дополнил. Опасений пока не имею когда начну пользоваться наверное появятся. Сделать репозитарий на githab и выложить контейнер в общий доступ думаю. Но нужно еще провести дополнительную работу для этого. Подумать немного чтобы было более универсально. Боюсь что например bcc нужно из общедоступного репозитария выбросить т.к. кто-нибудь включит эту фичу для дублирования почты там где это совсем не нужно или даже неуместно.
Мне одно непонятно — зачем?
Если надо отправить почту из приложения которое крутится внутри контейнера, можно:
а) подключиться к локальному MTA на хосте из докера (локально оно слушает всегда на 127.0.0.1:25)
или
б) отправлять по API через предназначенные для этого сервисы (а не заморачиваться с настройкой своего mail-сервера, а то адрес отправителя и IP очень быстро улетит в замечательный spam-blacklist)
Если надо отправить почту из приложения которое крутится внутри контейнера, можно:
а) подключиться к локальному MTA на хосте из докера (локально оно слушает всегда на 127.0.0.1:25)
или
б) отправлять по API через предназначенные для этого сервисы (а не заморачиваться с настройкой своего mail-сервера, а то адрес отправителя и IP очень быстро улетит в замечательный spam-blacklist)
Дополнил в статье проблемы которые возникают при подключении к postfix из докера на localhost. За 25-й порт спасибо за дополнение в дальнейшем учту. По пункту б) сервер улетает в spam-лист если он действительно рассылает спам или если он не нестроен до конца. В частности, докеризация предполагает такую комплексную настойку, в частности совместно с dkim сервисом, который в этой статье не описан, но в тех репозитариях на которые даны ссылки в дополнении к статье этот вопрос решен комплексно.
Другая часть этих настроек конечно должна быть проведена в настройках домена. Что к сожалению не всегда выполняется правильно. И поэтому почта часто попадает в серые и черные списки или отвергается некоторыми серверами.
Другая часть этих настроек конечно должна быть проведена в настройках домена. Что к сожалению не всегда выполняется правильно. И поэтому почта часто попадает в серые и черные списки или отвергается некоторыми серверами.
Другая часть этих настроек конечно должна быть проведена в настройках домена. Что к сожалению не всегда выполняется правильно. И поэтому почта часто попадает в серые и черные списки или отвергается некоторыми серверами.
Так я вот именно поэтому и спрашиваю — зачем? Настройка полноценного мейл-сервера, которому другие сервера будут доверять, это дело очень сложное (DNS A/AAAA, DNS PTR, DNS SPF это как минимум, еще добавим TLS, DKMS и прочее), что все достоинства использования контейнеров сходят на ноль, совсем.
При этом в интернете тысячи (ну или хотя бы сотни уж точно) сервисов, которые делают отправку почты через API банальным делом (например — AWS SES, не знаю какие сервисы для этого популярны в России).
Хотя бы для этого docs.aws.amazon.com/ses/latest/DeveloperGuide/postfix.html
Дополнил статью ссылкой на AWS
Может для бесплатной массовой рассылки в 100тыс клиентов?
Технически любой сервер может отправить спам и 100 тыс. и 1 млн. клиентов. Сложнее (практически невозможно) сделать так чтобы эта почта была принята принимающим сервером. Увы это так. У меня более простая задача отправить почту на корпоративный сервер админами которого я всегда могу договориться чтобы они включили мой адрес в белый список. Однако и там не без проблем это все. Т.к. всяческих фильтров иногда совершенно неожиданных для отброса спама больше чем можно себе вообразить. Например я отправляю письмо менеджеру продаж и копию на общий почтовый ящик. Почта не пропускается правилом которое гласит то два письма с одним контентом это уже спам.
По-моему
postconf -e "smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination"
postconf -e "smtpd_client_restrictions = permit_sasl_authenticated,reject_unauth_destination"лучше заменить на
postconf -e "smtpd_relay_restrictions = permit_sasl_authenticated,reject_unauth_destination"
postconf -e "smtpd_recipient_restrictions = reject" # (reject_unauth_destination - если хотите локальный bcc)smtpd_recipient_restrictions после версии 2.10 (я уверен, у вас старше) предназначен для ограничений на "локальную" доставку, вы же хотите настроить relay, поэтому лучше использовать соответствующий параметр.
smtpd_client_restrictions — это generic ограничения
Причем, правило reject_unauth_destination — это правило из раздела smtpd_recipient_restrictions, и в smtpd_client_restrictions оно будет иметь силу только если стоит smtpd_delay_reject = yes (значение по умолчанию).
И получается что вы одно и то же написали 2 раза.
Тут написано подробнее
И последний момент
myhostname = example.comсоветую все таки вписывать именно имя хоста docker-mx.mycompany.com (а не просто доменную часть) ведь именно так он будет представляться в HELO/EHLO при отправке почты. И на это имя вы будете заводить dkim/spf/dmark записи, а так же PTR запись в днс, а то рискуете попасть в спам.
Если представляться надо как-то иначе, то можно воспользоваться параметром smtp_helo_name.
Спасибо, очень ценное дополнение. Когда проверю дополню статью и свои конфигурации. К сожалению параметров у postfix довольно много и не все сразу доходит до понимания.
Полностью убрал параметр smtpd_recipient_restrictions и smtpd_client_restrictions
Задал параметр smtpd_relay_restrictions. Задание параллельно и параметра smtpd_recipient_restrictions как оказалось перекрывает значение smtpd_relay_restrictions и с другого адреса почта по прежнему не отправляется.
Задал параметр smtpd_relay_restrictions. Задание параллельно и параметра smtpd_recipient_restrictions как оказалось перекрывает значение smtpd_relay_restrictions и с другого адреса почта по прежнему не отправляется.
Так, кажется, я в первый раз неверно понял задачу. Меня сбил первый абзац о том что вы хотели что-то там прописывать в relay_domains.
Я и подумал что вы relayхотите:
The relay domain class.
Purpose: mail forwarding to remote destinations that list your system as primary or backup MX host. For a discussion of the basic configuration details, see the BASIC_CONFIGURATION_README document. For a discussion of the difference between canonical domains, hosted domains and other domains, see the VIRTUAL_README file.
Но по итогу вам нужен обычный
The default domain class.
Purpose: mail forwarding to the Internet on behalf of authorized clients. For a discussion of the basic configuration details, see the BASIC_CONFIGURATION_README file. For a discussion of the difference between canonical domains, hosted domains and other domains, see the VIRTUAL_README file.
Тогда, конечно, вы были правы с классом
postconf -e "smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination"просто smtpd_client_restrictions лишние были
Sign up to leave a comment.
Отправка почты из Docker-контейнера (докеризация postfix и sasl)