Почтовый сервер на Linux / RUVDS.com corporate blog / Habr

Как наладить работу почтового сервера, умеющего принимать и отправлять электронную корреспонденцию, бороться со спамом, взаимодействовать с клиентами? На самом деле, всё довольно просто.

Сегодня поговорим о почтовых серверах на Linux. Мы расскажем о том, как настроить сервер, о широко распространённом в интернете протоколе SMTP, а также о других протоколах, таких, как POP и IMAP. В итоге вы окажетесь обладателем полноценной системы для работы с электронной почтой.

Начнём с SMTP-сервера на Linux

SMTP-сервер

Протокол SMTP (Simple Mail Transfer Protocol) определяет правила пересылки почты между компьютерами, при этом, он не регламентирует правила хранения или визуализации сообщений. Это системно-независимый протокол, то есть, отправитель и получатель почты могут иметь различные ОС.

SMTP требует лишь чтобы сервер был способен отправлять обычный ASCII-текст другому серверу, используя порт 25, который является стандартным портом SMTP.

Сегодня в большинство дистрибутивов Linux встроены две наиболее распространённых реализации SMTP: sendmail и postfix.

Sendmail — это популярный почтовый сервер с открытым кодом, используемый во многих дистрибутивах Linux. К его минусам можно отнести несколько усложнённую архитектуру и недостаточно высокий уровень защиты.

Postfix — система немного более продвинутая, при разработке этого почтового сервера особое внимание было уделено вопросам безопасности.

Компоненты почтовой службы

Типичная почтовая служба состоит из трёх основных компонентов:

Почтовый клиент, который ещё называют почтовым агентом (Mail User Agent, MUA). Именно с ним взаимодействует пользователь, например — это почтовые клиенты Thunderbird или Microsoft Outlook. Они позволяют пользователю читать почту и писать электронные письма.

Почтовый сервер, или агент пересылки сообщений (Mail Transport Agent, MTA). Этот компонент ответственен за перемещение электронной почты между системами, этим занимаются, например, Sendmail и Postfix.

Агент доставки электронной почты (Mail Delivery Agent, MDA). Этот компонент ответственен за распределение полученных сообщений по почтовым ящикам пользователей. Например, это Postfix-maildrop и Procmail.

Установка почтового сервера

Для настройки нашего сервера был выбран пакет Postfix. Это — популярный среди системных администраторов выбор, стандартный почтовый сервер в большинстве современных дистрибутивов Linux.

Начнём, проверив, установлен ли Postfix в системе:

 $ rpm -qa | grep postfix

Если обнаружить Postfix не удалось, установить его, например, в дистрибутивах, основанных на Red Hat, можно с помощью такой команды:

$ dnf -y install postfix

Затем запустим службу postfix и организуем её автозапуск при загрузке системы:

$ systemctl start postfix
$ systemctl enable postfix

В дистрибутивах, основанных на Debian, вроде Ubuntu, установить Postfix можно так:

$ apt-get -y install postfix

В ходе установки будет предложено выбрать конфигурацию сервера. Среди доступных четырёх вариантов (No configuration, Internet site, Internet with smarthost, Satellite system and Local only), мы выберем No configuration, что приведёт к созданию необходимых Postfix учётных записей пользователя и группы.

Настройка сервера

После установки почтового сервера Postfix, его нужно настроить. Большинство конфигурационных файлов находятся в директории /etc/postfix/ .

Главный конфигурационный файл Postfix можно найти по адресу /etc/postfix/main.cf. Здесь имеется множество параметров, рассмотрим самые важные.

myhostname

Этот параметр используется для указания имени хоста почтовой системы. Это — имя хоста в интернете, для которого Postfix будет получать почту.

Типичные примеры имён хостов почтовых серверов — mail.example.com и smtp.example.com.

Настраивают этот параметр так:

myhostname = mail.example.com

mydomain

Эта настройка позволяет указать почтовый домен, обслуживанием которого занимается сервер, например — example.com:

mydomain = example.com

myorigin

Этот параметр позволяет указать доменное имя, используемое в почте, отправленной с сервера. Присвоим ему значение $mydomain:

myorigin = $mydomain

В настройках можно ссылаться на параметры, добавляя знак $ перед именем переменной.

mydestination

Этот параметр содержит список доменов, которые сервер Postfix будет считать конечными пунктами назначения для входящей почты.

В нашем случае здесь будут имя хоста сервера и доменное имя, но данный параметр может содержать и другие имена:

mydestination = $myhostname, localhost.$mydomain, $mydomain, mail.$mydomain, www.$mydomain

mail_spool_directory

Почтовый сервер Postfix может использовать два режима доставки почты:

• Непосредственно в почтовый ящик пользователя.
• В центральную директорию очередей, при этом почта попадает в папку /var/spool/mail, где имеется файл для каждого пользователя.

mail_spool_directory = /var/spool/mail

mynetworks

Эта переменная — важный параметр настройки. Она позволяет указывать то, какие сервера могут пересылать почту через сервер Postfix.

Обычно разрешают передачу почты только от локальных клиентских компьютеров. В противном случае вашим сервером могут заинтересоваться спамеры.

Если неправильно настроить параметр mynetworks, спамеры вполне смогут воспользоваться сервером как ретранслятором почты. Это очень быстро приведёт к тому, что какая-нибудь система борьбы со спамом поместит его в один из чёрных списков, вроде DNS Blacklist (DNSBL), или Realtime Blackhole List (RBL). Как только сервер попадёт в подобный список, очень немногие смогут получить письма, отправленные с его помощью.

Вот как может выглядеть настройка этого параметра:

mynetworks = 127.0.0.0/8, 192.168.1.0/24

smtpd_banner

Эта переменная позволяет задать ответ, который возвращает сервер при подключении клиентов.

Лучше всего поменять это значение так, чтобы оно не указывало на то, какой именно используется почтовый сервер.

inet_protocols

Эта переменная позволяет задавать версию IP, которую будет использовать Postfix при установлении соединений.

inet_protocols = ipv4

Для того, чтобы изменения, внесённые в конфигурационные файлы, вступили в силу, службу Postfix надо перезагрузить:

$ systemctl reload postfix

На самом деле, в конфигурационном файле Postfix можно ещё много чего настроить. Например — управлять уровнями безопасности, задавать опции отладки и другие параметры.

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

$ postfix check

С помощью этого средства можно найти строку, в которой допущена ошибка, и исправить её.

Проверка очереди сообщений

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

Для того чтобы проверить очередь сообщений, воспользуйтесь такой командой:

$ mailq

Она выведет сообщения, находящиеся в очереди. Если очередь переполнена и на отправку сообщения уходит по несколько часов, можно инициировать процесс отправки сообщений такой командой:

 
 $ postfix flush

Если теперь проверить очередь, она должна оказаться пустой.

Тестирование почтового сервера

После настройки сервера на Postfix, его надо протестировать. Первый шаг в тестировании — использование локального почтового клиента, вроде mailx или mail (это — символьная ссылка на mailx).

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

$ echo "This is message body" | mailx -s "This is Subject" -r "likegeeks<[email protected]>" -a /path/to/attachment [email protected]

Затем попробуйте принять письмо, отправленное с другого сервера.

Если вы столкнётесь с проблемами — проверьте логи. В дистрибутивах, основанных на Red Hat, то, что вам надо, можно найти по адресу

/var/log/maillog. В Debian-дистрибутивах нужный файл можно найти здесь: /var/log/mail.log, или же по пути, заданному в настройках rsyslogd. Вот, если нужно, материал о логировании в Linux, и о том, как настраивать rsyslogd.

Если проблемы всё ещё не решены, попытайтесь проверить настройки DNS, взгляните на MX-записи, используя сетевые команды Linux.

Борьба со спамом

Существует немало решений для выявления среди почтовых сообщений нежелательных писем — спама. Одно из лучших — проект с открытым исходным кодом SpamAssassin.
Установить его можно так:

$ dnf -y install spamassassin

Затем надо запустить соответствующую службу и добавить её в автозагрузку:

$ systemctl start spamassassin
$ systemctl enable spamassassin

После установки SpamAssassin, взгляните на его настройки в файле /etc/mail/spamassassin/local.cf.

SpamAssassin умеет отличать обычные письма от спама, основываясь на результатах исследования корреспонденции с помощью различных скриптов. Результаты проверок оцениваются в баллах.

Чем выше итоговая оценка письма — тем выше и вероятность того, что оно является спамом.

В конфигурационном файле параметр required_hits 5 указывает на то, что SpamAssassin пометит сообщение как спам, если его рейтинг составляет 5 или выше.

Параметр report_safe принимает значения 0, 1, или 2. Установка его в 0 означает, что письма, помеченные как спам, пересылаются в исходном виде, но их заголовок модифицируется с указанием на то, что они являются спамом.

Если этот параметр установлен в значение 1 или 2, SpamAssassin сгенерирует отчёт и отправит его получателю.

Разница между значениями 1 и 2 заключается в том, что в первом случае спам-сообщение будет закодировано в формате message/rfc822, а во втором — в формате text/plain.

Кодирование text/plain безопаснее, так как некоторые почтовые клиенты исполняют сообщения формата message/rfc822, что при определённых условиях может привести к заражению клиентского компьютера вирусом.

После установки и настройки SpamAssassin, нужно интегрировать его с Postfix. Пожалуй, легче всего это сделать с помощью использования procmail.

Создадим файл /etc/procmailrc и добавим в него следующее:

:0 hbfw
| /usr/bin/spamc 

Затем отредактируем файл настроек Postfix — /etc/postfix/main.cf, задав параметр mailbox_command следующим образом:

mailbox_command = /usr/bin/procmail

И, наконец, перезапустим службы Postfix и SpamAssassin:

$ systemctl restart postfix
$ systemctl restart spamassassin

Надо сказать, что SpamAssassin не всегда распознаёт спам, что ведёт к наполнению почтовых ящиков ненужными письмами.

К счастью, сообщения, прежде чем они достигнут почтового сервера на Postfix, можно фильтровать, используя Realtime Blackhole Lists (RBLs). Это снизит нагрузку на почтовый сервер и поможет сохранить его в чистоте.

Откройте конфигурационный файл Postfix /etc/postfix/main.cf, измените параметр smtpd_recipient_restrictions и настройте другие параметры следующим образом:

strict_rfc821_envelopes = yes
relay_domains_reject_code = 554
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unverified_recipient_reject_code = 554
 
smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client dsn.rfc-ignorant.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net,
permit 

Затем перезагрузите сервер Postfix:

$ systemctl restart postfix

Вышеприведённые чёрные списки используются чаще всего, но вы можете найти и другие подобные сервера.

Защита SMTP-соединения

Лучше всего передавать SMTP-трафик по TLS для защиты его от атаки через посредника.
Для начала нужно сгенерировать сертификат и ключ с использованием команды openssl:

$ openssl genrsa -des3 -out mail.key
$ openssl req -new -key mail.key -out mail.csr
$ cp mail.key mail.key.original
$ openssl rsa -in mail.key.original -out mail_secure.key
$ openssl x509 -req -days 365 -in mail.csr -signkey mail_secure.key -out mail_secure.crt
$ cp mail_secure.crt /etc/postfix/
$ cp mail_secure.key /etc/postfix/

Затем надо добавить в файл настроек Postfix /etc/postfix/main.cf следующее:

smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/mail_secure.crt
smtpd_tls_key_file = /etc/postfix/mail_secure.key
smtp_tls_security_level = may

И, наконец, нужно перезагрузить службу Postfix:

$ systemctl restart postfix

Теперь, при подключении клиента к серверу, нужно выбрать TLS. Тут вы, при первой отправке почты после изменении настроек, увидите предупреждение, так как сертификат не подписан.

Основы протоколов POP3 и IMAP

Итак, мы наладили процесс отправки и получения электронных писем по SMTP, но на этом организация полноценной почтовой службы не заканчивается. Рассмотрим следующие ситуации:

• Пользователям нужны локальные копии электронных писем для их просмотра без подключения к интернету.
• Почтовые клиенты пользователей не поддерживают формат файлов mbox. Это — простой текстовый формат, который могут читать многие консольные почтовые клиенты, вроде mailx и mutt.
• Пользователи не могут постоянно пользоваться быстрым подключением для доступа к файловой системе сервера и для работы с mbox-файлами, в итоге нужно сделать локальную копию для работы с ними без подключения к сети.
• Ограничения безопасности указывают на то, чтобы у пользователей не было прямого доступа к шлюзу электронной почты, например, не допускается работа с общедоступными папками очередей сообщений.
  

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

Сильнее всего распространены два популярных протокола доступа к почте — POP (Post Office Protocol), и IMAP (Internet Message Access Protocol).

В основе POP лежит очень простая идея. Центральный почтовый сервер на Linux всё время подключён к интернету, он получает и сохраняет письма для всех пользователей. Все полученные письма остаются в очереди на сервере до тех пор, пока пользователь не подключится к нему по протоколу POP и не загрузит письма.

Когда пользователь хочет отправить письмо, почтовый клиент обычно передаёт его через центральный сервер по SMTP.

Обратите внимание на то, что SMTP-сервер и POP-сервер могут без проблем работать на одной и той же машине. В наши дни это — обычная практика.

Возможности, вроде хранения исходных экземпляров писем пользователей на сервере с хранением на клиенте лишь кэшированных копий, в POP отсутствуют. Это привело к разработке протокола IMAP.

Используя IMAP, сервер будет поддерживать три режима доступа к почте:

• Онлайн-режим похож на прямой доступ к файловой системе на почтовом сервере.
  
• Оффлайн-режим похож на то, как работает POP, когда клиент отключается от сети после получения своих писем. В этом режиме сервер обычно не хранит копии писем.
  
• Автономный режим позволяет пользователям хранить кэшированные копии своих писем, а сервер так же хранит копии этих писем.
  

Существуют различные реализации IMAP и POP, в этой сфере весьма популярен сервер Dovecot, который позволяет работать с обоими протоколами.

Сервера POP3, POP3S, IMAP, и IMAPS слушают, соответственно, порты 110, 995, 143, и 993.

Установка Dovecot

Большинство дистрибутивов Linux содержат предустановленный Dovecot, однако, его можно установить и самостоятельно. В системах, основанных на Red Hat, это делается так:

$ dnf -y install dovecot

В системах, основанных на Debian, функционал IMAP и POP3 предоставляются в двух разных пакетах:

$ apt-get -y install dovecot-imapd dovecot-pop3d

Тут вам предложат создать самозаверенный сертификат для работы с IMAP и POP3 по SSL/TLS. Ответьте на вопрос yes и, при появлении соответствующего запроса, введите имя хоста вашей системы.

Затем можно запустить соответствующую службу и добавить её в автозагрузку:

$ systemctl start dovecot
$ systemctl enable dovecot

Настройка Dovecot

Главный файл настроек Dovecot расположен по адресу /etc/dovecot/dovecot.conf. В некоторых дистрибутивах Linux этот файл размещается в папке /etc/dovecot/conf.d/ и, для подключения файлов настроек, используется директива include.

Вот некоторые из параметров, используемых для настройки Dovecot.

protocols: протоколы, которые надо поддерживать.

protocols = imap pop3 lmtp

Здесь lmtp означает Local Mail Transfer Protocol. listen: IP-адрес, который будет слушать сервер.

listen = *, ::

Здесь звёздочка означает все интерфейсы IPv4, двойное двоеточие означает все интерфейсы IPv6.

userdb: база данных пользователей для аутентификации.

userdb {
 driver = pam
}

mail_location: это запись в файле /etc/dovecot/conf.d/10-mail.conf. Выглядит она так:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

Dovecot поставляется со стандартными SSL-сертификатами и файлами ключей, которые используются в файле /etc/dovecot/conf.d/10-ssl.conf.

ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem

Когда пользователь пытается подключиться к Dovecot, сервер покажет предупреждение, так как сертификаты не подписаны. Если нужно, подписанные сертификаты можно приобрести в подходящем центре сертификации.

Не забудьте открыть порты сервера Dovecot на файрволе.

$ iptables  -A INPUT -p tcp --dport 110 -j ACCEPT
$ iptables  -A INPUT -p tcp --dport 995 -j ACCEPT
$ iptables  -A INPUT -p tcp --dport 143 -j ACCEPT
$ iptables  -A INPUT -p tcp --dport 993 -j ACCEPT

И про SMTP-порт не забудьте.

$ iptables -A INPUT -p tcp --dport 25 -j ACCEPT

Затем сохраните правила. Если хотите освежить в памяти особенности работы с iptables в Linux, взгляните на этот материал.
Или, если вы используете firewalld, можете поступить так:

$ firewall-cmd --permanent --add-port=110/tcp --add-port=995
$ firewall-cmd --permanent --add-port=143/tcp --add-port=993
$ firewall-cmd --reload

А, если что-то пошло не так, посмотрите лог-файлы /var/log/messages, /var/log/maillog, и /var/log/mail.log.

Итоги

Теперь вы можете настроить почтовую службу на своём Linux-сервере. Как видите, много времени это не займёт. Конечно, у рассмотренных здесь пакетов, вроде Postfix, уйма настроек, но если вы освоили описанную здесь последовательность действий и разобрались с основами, то всё, что вам понадобится, несложно будет выяснить из документации.

Уважаемые читатели! А как вы настраиваете почтовые сервера на Linux?

Почтовый сервер — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 18 мая 2018; проверки требуют 2 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 18 мая 2018; проверки требуют 2 правки.

Почтовый сервер, сервер электронной почты, или мейл-сервер — в системе пересылки электронной почты так обычно называют агента пересылки сообщений (англ. mail transfer agent, MTA). Это компьютерная программа, которая передаёт сообщения от одного компьютера к другому. Обычно почтовый сервер работает «за кулисами», а пользователи имеют дело с другой программой — клиентом электронной почты (англ. mail user agent, MUA).

Схема взаимодействия

К примеру, в распространённой конфигурации клиентом электронной почты является Outlook Express, однако в последнее время часто используются полноценные версии почтового клиента от Microsoft — Outlook, а также клиента от Mozilla — Thunderbird. Когда пользователь набрал сообщение и посылает его получателю, почтовый клиент взаимодействует с почтовым сервером, используя протокол SMTP. Почтовый сервер отправителя взаимодействует с почтовым сервером получателя (напрямую или через промежуточный сервер — релей). На почтовом сервере получателя сообщение попадает в почтовый ящик посредством агента доставки сообщений MDA. MDA может быть частью POP/IMAP сервера (например, deliver и lmtpd у Cyrus-IMAP), частью SMTP сервера (например, mail.local у Sendmail, хотя чаще с Sendmail используют Procmail), или отдельным ПО (например, Procmail). Для финальной доставки полученных сообщений используется не SMTP, а другой протокол — часто POP3 или IMAP — который также поддерживается большинством почтовых серверов. Хотя в простейшей реализации MTA достаточно положить полученные сообщения в личный каталог пользователя в файловой системе центрального сервера («почтовый ящик»).

Часто почтовый сервер включает программное обеспечение для организации рассылок электронной почты.

Yandex «Почта для домена» как почтовый шлюз для ваших серверов / Plesk corporate blog / Habr

Каждый раз поднимая новый сервер в облаках, вы получаете случайный IP-адрес. Не все понимают, что IP-адрес может попасть к вам с «историей». Часто приходится тратить время на удаление IP из публичных черных списков. В моём случае в последний раз это была очень неторопливая переписка с mail.ru, которая ни к чему не привела. После этого, создав новый сервер, я задумался: как же сделать так, чтобы не огребать проблем с такими IP-адресами?

Введение

Несмотря на то, что серверы у меня могут быть как постоянные так и «на поиграться», почту на всех них я не обслуживаю, но очень хочу получать сервисные письма от своих скриптов и системных служб.

Очевидное решение — сделать свой «порядочный» почтовый шлюз и все остальные серверы настраивать на пересылку почты через этот шлюз. Минусы такого решения очевидны:

• Отдельный сервер стоит денег, даже если это дешевая VPSка
• IP-адрес надо постоянно отслеживать в черных списках
• Настройка почтового шлюза требует времени, которое зависит от ваших скиллов

Из-за вышеперечисленных причин я пошёл искать другое решение, и, что характерно, нашёл.

Решение

Я обнаружил возможность схалявить, воспользовавшись сервисом «Почта для Домена» от Yandex. На тот момент у меня было поднято 3 сервера и в DNS были следующие А-записи:

Хост	Тип	Значение
example.com	A	123.123.123.120
server1.example.com	A	123.123.123.121
server2.example.com	A	123.123.123.122
server3.example.com	A	123.123.123.123

Я зарегистрировал свой технический домен в «Почте для Домена» и создал аккаунт: [email protected]. Попробовал отправить письма с одного из своих серверов, используя этот SMTP-аккаунт и получил следующую ошибку:

553 5.7.1 Sender address rejected: not owned by auth user.
envelope from address [email protected] not accepted by the server

Yandex не разрешает подставлять какие попало данные в envelope-from. Но как же быть, если хочется понимать, с какого сервера пришло то или иное письмо, без дополнительных ухищрений?

Чтобы соблюсти правила Yandex’a, нужно выполнить следующие шаги на стороне их сервиса:

1. Зарегистрировать основной домен и его поддомены в pdd.yandex.ru. Проще всего пройти подтверждение домена через добавление CNAME-записи:

   
   

   Хост	Тип	Значение
   example.com	CNAME	verification-code
   server1.example.com	CNAME	verification-code
   server2.example.com	CNAME	verification-code
   server3.example.com	CNAME	verification-code

   
   

2. Так же для каждого домена создаем MX-запись:

   
   

   Хост	Тип	Приоритет	Значение
   example.com	MX	10	mx.yandex.ru
   server1.example.com	MX	10	mx.yandex.ru
   server2.example.com	MX	10	mx.yandex.ru
   server3.example.com	MX	10	mx.yandex.ru

   
   

3. В настройках основного домена указать поддомены как алиасы этого домена.

   
   
   

4. Создаём почтовый аккаунт [email protected], если он ещё не создан

   
   
   
5. Обязательно нужно зайти в аккаунт через веб-интерфейc и активировать его, иначе получите ошибку:

   535 5.7.8 Error: authentication failed: Please accept EULA first. https://mail.yandex.ru/for/example.com

   
   

Дальше требуется работа на нашей стороне — настраиваем сервера:

1. Устанавливаем msmtp — миниатюрный SMTP-клиент, который предоставляет свою реализацию sendmail

2. Настраиваем его:

   defaults
   
   syslog LOG_MAIL
   
   tls_certcheck off
   tls on
   
   auto_from on
   # server hostname
   maildomain server1.example.com
   
   account default
   
   host smtp.yandex.ru
   port 25
   
   auth on
   user [email protected]
   password 123qwe

   
   
3. Отправляем тестовое письмо с отладкой:

   echo -e "test message" | /usr/bin/msmtp --debug -t -i [email protected]

   и смотрим результат:
   

   loaded system configuration file /etc/msmtprc
   ignoring user configuration file /root/.msmtprc: No such file or directory
   falling back to default account
   using account default from /etc/msmtprc
   host = smtp.yandex.ru
   port = 25
   proxy host = (not set)
   proxy port = 0
   timeout = off
   protocol = smtp
   domain = localhost
   auth = choose
   user = [email protected]
   password = *
   ntlmdomain = (not set)
   tls = on
   tls_starttls = on
   tls_trust_file = (not set)
   tls_crl_file = (not set)
   tls_fingerprint = (not set)
   tls_key_file = (not set)
   tls_cert_file = (not set)
   tls_certcheck = off
   tls_min_dh_prime_bits = (not set)
   tls_priorities = (not set)
   auto_from = on
   maildomain = server1.example.com
   from = [email protected]
   add_missing_from_header = on
   add_missing_date_header = on
   remove_bcc_headers = on
   dsn_notify = (not set)
   dsn_return = (not set)
   logfile = (not set)
   syslog = LOG_MAIL
   aliases = (not set)
   reading recipients from the command line and the mail
   <-- 220 smtp3h.mail.yandex.net ESMTP (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)
   --> EHLO localhost
   <-- 250-smtp3h.mail.yandex.net
   <-- 250-8BITMIME
   <-- 250-PIPELINING
   <-- 250-SIZE 42991616
   <-- 250-STARTTLS
   <-- 250-AUTH LOGIN PLAIN XOAUTh3
   <-- 250-DSN
   <-- 250 ENHANCEDSTATUSCODES
   --> STARTTLS
   <-- 220 Go ahead
   TLS certificate information:
   Owner:
       Common Name: smtp.yandex.ru
       Organization: Yandex LLC
       Organizational unit: ITO
       Locality: Moscow
       State or Province: Russian Federation
       Country: RU
   Issuer:
       Common Name: Yandex CA
       Organization: Yandex LLC
       Organizational unit: Yandex Certification Authority
       Country: RU
   Validity:
       Activation time: Mon 12 Oct 2015 03:41:24 PM MSK
       Expiration time: Wed 11 Oct 2017 03:41:24 PM MSK
   Fingerprints:
       SHA1: B7:0E:62:55:E1:3A:C0:F3:08:12:35:B2:9D:4B:25:D0:B8:C1:C6:39
       MD5:  BC:15:CE:B6:D4:FF:0D:95:4F:E5:1A:A7:3A:DF:DA:65
   --> EHLO localhost
   <-- 250-smtp3h.mail.yandex.net
   <-- 250-8BITMIME
   <-- 250-PIPELINING
   <-- 250-SIZE 42991616
   <-- 250-AUTH LOGIN PLAIN XOAUTh3
   <-- 250-DSN
   <-- 250 ENHANCEDSTATUSCODES
   --> AUTH PLAIN AhJvb3ARY29uzMlntS5ydQBXYw5VcMMlazk=
   <-- 235 2.7.0 Authentication successful.
   --> MAIL FROM:<[email protected]>
   --> RCPT TO:<[email protected]>
   --> DATA
   <-- 250 2.1.0 <[email protected]> ok
   <-- 250 2.1.5 <[email protected]> recipient ok
   <-- 354 Enter mail, end with "." on a line by itself
   --> From: [email protected]
   --> Date: Mon, 06 Jun 2016 16:17:00 +0300
   --> test message
   --> .
   <-- 250 2.0.0 Ok: queued on smtp3h.mail.yandex.net as 1465219021-86hlZkGCpZ-H0J8ORE2
   --> QUIT
   <-- 221 2.0.0 Closing connection.

   Отлично, успех! Письмо ушло, правда, найдем мы его в спаме, так как оно почему-то пустое. Давайте проверим более привычным и «человеческим» способом:
   

   echo "test message" | mailx -s 'test subject' [email protected]

   Вот, теперь в ящике нормальное письмо. Здорово!

   
   

   DKIM & SPF

   А еще можно для каждого домена прописать записи DKIM и SPF. Если вы, как я, используете свой DNS-хостинг, то просто скопируйте соответствующие значения из “DNS редактора” в интерфейсе Яндекса. Внимание: для каждого домена и алиаса свой ключ!

   
   

   Хост	Тип	Значение
   mail._domainkey.example.com	TXT	v=DKIM1; k=rsa; t=s; p=MIGf…
   mail._domainkey.server1.example.com	TXT	v=DKIM1; k=rsa; t=s; p=MIGf…
   mail._domainkey.server2.example.com	TXT	v=DKIM1; k=rsa; t=s; p=MIGf…
   mail._domainkey.server3.example.com	TXT	v=DKIM1; k=rsa; t=s; p=MIGf…

   Отсылаем с сервера письмо и смотрим в заголовки:

   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail; t=1467009762;
       bh=Pb6s/Xlf4...
   Authentication-Results: smtp14.mail.yandex.net; dkim=pass [email protected]

   Лепота!

   В случае если отправка почты для домена будет происходить только через сервера Яндекс и с заранее известных IP-адресов, то можно смело прописать SPF-записи в соответствии с документацией https://yandex.ru/support/pdd/troubleshooting/dns.xml#step2

   
   

   Хост	Тип	Значение
   example.com	TXT	v=spf1 redirect=_spf.yandex.net
   server1.example.com	TXT	v=spf1 redirect=_spf.yandex.net
   server2.example.com	TXT	v=spf1 redirect=_spf.yandex.net
   server3.example.com	TXT	v=spf1 redirect=_spf.yandex.net

   
   

   Нюансы

   Скорее всего, вы молодцы, и ваше приложение работает не из под root’а. Попытка послать письмо из-под обычного пользователя опять приведёт к знакомой ошибке в логе msmtp:

   Jun  6 14:21:24 server1 msmtp: host=smtp.yandex.ru tls=on auth=on [email protected] [email protected] [email protected] smtpstatus=553 smtpmsg='553 5.7.1 Sender address rejected: not owned by auth user.' errormsg='envelope from address [email protected] not accepted by the server' exitcode=EX_DATAERR

   Можно решить эту проблему по-разному. Например, можно явно указывать пользователя, отключив опцию auto_from off в msmtp. Но я уже решил, что меня это не устраивает.

   Правильное решение — добавить пользователя как алиас для нашего основного адреса:

   
   
   

   Если вам требуется локальный SMTP-релей, то данная конфигурация вам тоже подходит. Нужно просто заменить msmtp на postfix или exim, настроенные на использование серверов Яндекса в качестве smart host’a (гуглить можно, например, по ключевым словам exim smarthost).

   
   

   Резюме

   Теперь любой сервер, который я поднимаю для своих задачек, сразу же получает настроенный канал отправки почты. В DNS и pdd.yandex.ru я заранее прописал несколько поддоменов про запас. Так как сервера я разворачиваю через SaltStack, то конфигурацию msmtp мои сервера получают автоматически.

   Что я получил в итоге:

   
   
   1. Самое главное — нет заморочек с черными списками и IP-адресами серверов, так как письма уходят через сервера Яндекса
   2. DKIM/SPF «из коробки» — письма не попадают в спам
   3. msmtp простой SMTP-клиент, которому даже в памяти сервера висеть не нужно — запускается по необходимости
   4. msmtp — простейшая настройка в отличие от «взрослых» postfix, exim
   5. можно не беспокоиться о PTR-записях для ваших IP-адресов с точки зрения почтовой системы.

   Надеюсь эта инструкция кому-нибудь пригодится. Буду рад узнать из комментариев, кто и как решает подобную проблему.

Почтовые ящики для стандартных сервисов, ролей и функций / Habr

Недавно столкнулся с неприятной ситуацией — почтовый сервер попал в спам-листы. Дыру быстро нашли и залатали, но компания Oracle уже занесла наш сервер в свой черный список, причем блокировали нас ещё на стадии соединения.
Возник вопрос — куда писать? На сайте была только форма для клиентов, [email protected] предназначался для них же.
После недолгих раздумий, появилась мысль — а нет ли стандарта, определяющего почтовые адреса по которым надо писать в таком случае? Оказалось, что есть и описан он в RFC 2142.

Самое интересное содержится в таблицах, которые приведены ниже.

1. Деловая информация

Адрес	Зона	Использование
INFO	Маркетинг	Информации об организации, продукции и сервисах
MARKETING	Маркетинг	Маркетинговой информации и контакты
SALES	Продажи	Информации связанной с приобретением продукции
SUPPORT	Обслуживание пользователей	Решения проблем с продукцией и услугами

2. Сетевые службы

Адрес	Зона	Использование
ABUSE	Отношения с клиентами	Жалобы на неуместное содержимое
NOC	Эксплуатация сети	Сетевая инфраструктура
SECURITY	Сетевая безопасность	Запросы и бюллетени безопасности

3. Интернет-сервисы

Адрес	Сервис	Спецификация
POSTMASTER	SMTP	[RFC821], [RFC822]
HOSTMASTER	DNS	[RFC1033-RFC1035]
USENET	NNTP	[RFC977]
NEWS	NNTP	Синоним для USENET
WEBMASTER	HTTP	[RFC 2068]
WWW	HTTP	Синоним для WEBMASTER
FTP	FTP	[RFC959]

Очень часто встречаю странные адреса в whois или в разделе связи на сайтах, например, в базе RIPE для моего провайдера указан адрес info, а в RIPN какие-то древние адреса на mail.ru и support.
Используйте адреса из рекомендаций хотя бы в виде синонимов к существующим ящикам — это основы сетевого этикета.

P.S. А с Ораклом всё закончилось хорошо, Postmaster ответил в тот же день и, после объяснения ситуации, с нами опять стали дружить 🙂

Настройка почтовых клиентов | REG.RU

Thunderbird — бесплатный почтовый клиент от Mozilla, с помощью которого можно легко и удобно управлять электронными почтовыми ящиками. Thunderbird является кроссплатформенным и доступен для установки на Windows, Linux и MacOS. У него встроенный спам-фильтр, благодаря которому можно тонко настроить прием входящей корреспонденции, а также удобная многофункциональная книга контактов.

С помощью Mozilla Thunderbird вы также можете перенести почту с одной услуги хостинга на другую: Как перенести почту с помощью Thunderbird?

Параметры настройки:

Для нешифрованного соединения с сервером используются порты:

• SMTP: 25 или 587;
• IMAP: 143;
• POP3 110.

Для шифрованного SSL/TLS соединения с сервером используются порты:

• SMTP: 465;
• IMAP: 993;
• POP3: 995.

Важно: Настройка шифрованного соединения доступна только на Linux-хостинге. Для настройки шифрованного соединения в качестве сервера входящей и исходящей почты необходимо указывать mail.hosting.reg.ru.

Как настроить Thunderbird:

1. 1.

   Откройте меню почтового клиента, в правом верхнем углу выберите Создать — Настроить имеющейся у вас учётной записи электронной почты.

2. 2.

   Введите ваше имя и фамилию, полный адрес почтового ящика и пароль. Нажмите Продолжить.

   

3. 3.

   Нажмите кнопку Настройка вручную:

   

4. 4.

   Выставьте настройки в соответствии со скриншотом. Нажмите Готово:

   

Проверьте конечные настройки. Нажмите правой кнопкой мыши и выберите пункт «Параметры»:

Сервер входящей почты. Если порт 143, то методом аутентификации должен быть «Обычный пароль». Если порт 993 — «Зашифрованный пароль»:

Сервер исходящей почты:

Готово. Вы настроили почтовый клиент.

(Почему) Почта Mail.Ru включает строгий DMARC / Mail.ru Group corporate blog / Habr

На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) — протокол, позволяющий администратору доменной зоны опубликовать политику приема и отправки отчетов для писем, не имеющих авторизации. В качестве протоколов авторизации используются протоколы SPF (RFC 7208) и DKIM (RFC 6376).
При получении письма, у которого в поле отправителя (From:) используется домен example.org, сервер получателя запрашивает политику DMARC домена example, которая публикуется в DNS в виде TXT-записи, например

_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;"


Для письма проверяется SPF и DKIM; кроме этого, проверяется соответствие (alignment) домена, прошедшего проверку SPF или DKIM, и домена, используемого во From:. Чтобы домен прошел авторизацию DMARC, необходимо, чтобы хотя бы один из механизмов SPF или DKIM прошел авторизацию для домена, совпадающего с точностью до домена организации из адреса From:. Если письмо не проходит авторизацию или домен не совпадает (например, использована DKIM-подпись стороннего домена или адрес в envelope-from не совпадает с адресом From:), применяется политика (в данном случае none, т. е. никаких специальных действий не требуется; возможны также политики reject — не принимать письма и quarantine — складывать письма в папку «Спам»). Статистические отчеты по срабатыванию политики и прошедшим письмам будут отправляться на адрес [email protected]. Также домен, публикующий политику, просит отправлять форензик-отчеты (т. е. отчеты, содержащие как минимум заголовки полученного письма) по всем письмам, не прошедшим авторизацию SPF или DKIM, на адрес [email protected].

Mail.Ru первым в Рунете поддержал серверную часть DMARC более двух лет назад. А теперь DMARC будет защищать от подделки домены mail.ru. Ранее строгая политика DMARC была включена только для служебных доменов Mail.Ru Group (например, corp.mail.ru), поскольку именно они чаще всего подделываются фишерами. В настоящее время она также применяется для доменов mail.ua и bk.ru, а 18 мая будет распространена на все домены бесплатных почтовых ящиков (list.ru, inbox.ru и mail.ru).
DMARC устраняет самую серьезную проблему электронной почты — отсутствие проверки адреса отправителя. Чаще всего причиной для ввода DMARC называют борьбу с фишинговыми письмами. Отчасти это действительно так — ввод строгой политики DMARC всего несколькими крупными банками США в 2014 году привел к снижению фишинга посредством электронной почты на 6% за год в целом по отрасли. В PayPal объем фишинга за два года после введения политики снизился на 70%.

В случае доменов публичной почты основной причиной является не фишинг. Мы хотим, во-первых, в целом снизить объем спама в Сети: большая его часть идет именно с поддельных адресов, в некоторые дни число таких писем с поддельными адресами mail.ru более чем в 15 раз превышает количество писем, отправляемых пользователями Mail.Ru. Во-вторых, DMARC позволяет оградить пользователей от вторичного спама. Очень часто спамные письма с поддельных адресов генерируют сообщения о невозможности доставки (NDR) и автоответы, которые идут на ящики легитимных пользователей, не отправлявших письмо. Распознать такую ситуацию может быть достаточно сложно, так как в NDR и автоответе отсутствует «спамный» контент. По нашему опыту, внедрение строгой политики DMARC снижает объем вторичного спама в несколько десятков раз.

SPF (RFC 7208) совсем не защищает адрес отправителя, так как работает только с адресом envelope-from, который невидим пользователю. DKIM (RFC 6376) тоже совершенно не защищает адрес отправителя, поскольку является алгоритмом подписи и не указывает, как поступать, если подписи нет или она некорректна. Sender ID (RFC 4406) прикрыт патентами Microsoft и «не взлетел». Ближайшим по функционалу к DMARC был протокол ADSP (RFC 5617), но, в отличие от DMARC, он также «не взлетел» и в 2013 году был переведен в статус Historic, так как почти все крупные игроки рынка отказались от него в пользу DMARC. В отличие от ADSP, работавшего только поверх DKIM, DMARC может использовать разные протоколы аутентификации. В базовом стандарте применяются и DKIM, и SPF. Фактически DMARC комбинирует механизмы, задействованные в Sender ID и ADSP, и дает возможность расширять их в будущем, что значительно улучшает «непрямое» прохождение почты (indirect flows). Уже сейчас можно не сомневаться, что протокол DMARC работает, — серверная часть DMARC поддерживается всеми серьезными почтовыми службами, все крупные игроки либо уже включили DMARC на своих доменах, либо заявили о таком намерении. Среди публичных почтовых служб, включивших DMARC на своих доменах (и принявших основной удар критики от владельцев списков рассылки, о чем речь пойдет ниже), — Yahoo и AOL. С их стороны это было рискованным, но очень нужным решением — иначе протокол могла бы постичь судьба Sender ID и ADSP.
Естественно, у любого протокола есть недостатки. DMARC требует аутентификации отправителя, из-за этого в нескольких ситуациях возникают проблемы:

1. Пользователь посылает письма «напрямую» в обход почтового сервера с аутентификацией. Например, веб-мастер отправляет регистрационные письма PHP-скриптом, используя во From: адрес публичной почты. К сожалению, единственное решение — так не делать. Зарегистрируйте почту для своего домена. Mail.Ru предоставляет для этого бесплатный сервис. Даже если вы перейдете на отправку с адреса другой публичной почты, скорее всего, это решение будет временным, поскольку DMARC для своих доменов станут внедрять все крупные почтовые сервисы.
2. Списки рассылки. Да, с ними опять есть проблемы, и более существенные, чем в случае с SPF, так как SPF оказался бесполезным именно из-за попыток сохранить совместимость со списками рассылки. Чтобы не нарушать авторизацию DMARC, необходимо либо «не трогать» заголовки, подписанные DKIM (в частности, не менять тему письма), либо перезаписывать отправителя из From:. К счастью, основные менеджеры списков рассылки уже поддерживают корректную работу с DMARC.
3. Форварды. В некоторых случаях почтовые серверы меняют содержимое при пересылке, например структуру MIME-частей или разбивку на строки, что может приводить к нарушению DKIM-подписи. В таких случаях мы рекомендуем вместо пересылки почты использовать сбор почты по протоколам POP3/IMAP (reverse POP / reverse IMAP). Mail.Ru первая из почтовых служб реализовала сбор почты по IMAP с сохранением структуры папок. Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC. Если письма от известного форвардера или списка рассылки блокируются нами по политике DMARC — пожалуйста, сообщите об этом. В будущем проблема форвардов может быть решена реализацией протокола ARC (Authenticated Received Chain), пока этот протокол находится в стадии обсуждения.
4. Есть и другие проблемы DMARC, в том числе связанные с безопасностью, особенно при предоставлении forensic-отчетов. Например, возможность раскрывать перенаправления (и таким образом деанонимизировать пользователя) или подписчиков списков рассылки. Все это возможно и без DMARC, но DMARC заметно облегчает задачу. Поэтому мы реализовали функцию анонимайзера — как альтернативу пересылок или разовых/скрытых адресов для списков подписки. Из соображений безопасности мы не планируем предоставлять forensic-отчеты с полной идентификацией получателя недоверенным сторонам.

…я обычный пользователь почты

Ничего делать не требуется. Скорей всего, вы ничего не заметите, только избежите ситуаций «кто-то получил спам/фишинг с моего адреса, а я его не отправлял» и не будете получать непонятные «отлупы».

…я пользуюсь Почтой для бизнеса для своего домена

Изменения затронут только публичные домены Mail.Ru. Чтобы ваш домен был защищен DMARC, необходимо самостоятельно опубликовать политику.

…я отправляю письма через почтовый сервер своего интернет-провайдера

Для адресов обслуживаемых Mail.Ru необходимо настроить отправку через SMTP-серверы mail.ru с авторизацией по инструкциям.

…я пользуюсь перенаправлениями для сбора почты с нескольких аккаунтов на разных сервисах в общий ящик

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

…я пользуюсь перенаправлениями для заведения скрытых/временных адресов

Перенаправления могут быть обнаружены и раскрыты (для этого достаточно поддержки DMARC сервером получателя, т. е. практически любым сервером). Если это критично для вас, используйте функцию анонимайзера.

…я пользуюсь функционалом «отправлять как» на Gmail (или аналогичным) для отправки писем с адреса Mail.Ru

Следует проверить настройки адреса отправки в Gmail и убедиться, что отправка идет через сервер SMTP mail.ru (smtp.mail.ru, порт 465 с использованием SSL), c корректным логином и паролем. Письма будут отправляться через сервер Mail.Ru с авторизацией отправителя и пройдут проверки SPF/DKIM/DMARC.

…я пользуюсь обратным адресом публичной почты для отправки писем через скрипты на сервере

Так делать не следует. Используйте «Почту для бизнеса» для заведения ящиков в вашем собственном домене (hint: для этого не обязательно обладать бизнесом, достаточно обладать доменом). Используйте адрес собственного домена во всех серверных, автоматических или автоматизированных рассылках.

…я предоставляю клиентам услуги доставки электронных сообщений (ESP)

Не используйте для заголовка From: сообщений адрес отправителя из доменов бесплатной почты. Зарегистрируйте отдельный домен для клиентов, не имеющих собственного домена, настройте для него SPF, DKIM и DMARC. Выделяйте клиенту адрес в этом домене для использования в качестве адреса отправителя и прописывайте перенаправления с выделенного адреса в вашем домене на ящик электронной почты клиента. Клиентам, имеющим собственный домен, рекомендуйте брать адреса из этого домена в качестве адреса отправителя. Можно продолжать использовать адрес клиента в домене бесплатной почты для заголовков Sender: и Reply-To:.

…я администрирую списки рассылки

Обновите программное обеспечение списков рассылки и настройте его в соответствии с рекомендациями совместимости DMARC. Корректно работают Sympa с версии 6.2.6, Dada Mail с версии 7.0.2, Mailman с версии 2.1.16 (лучше 2.1.18), GroupServer с версии 14.06. Возможно, придется включить функцию, которая называется «Sending on behalf of» / «Munge the From: header». Если рекомендации выполнить невозможно (например, используется устаревшее или неподдерживаемое ПО), постарайтесь минимизировать нарушения DMARC, отказавшись от изменения служебных заголовков и содержимого писем, отправляемых в список рассылки, — т. е. не меняйте темы, не добавляйте хидер/футер к письмам, чтобы не нарушать DKIM-сигнатуру письма. Если проблемы с доставкой сохраняются, обратитесь в службу поддержки сервера, который не принимает сообщения.

…я администрирую почтовый домен и хочу опубликовать свою DMARC-политику

Настройте SPF и DKIM для всех отправляемых писем, при этом учтите специфику требований новых версий стандартов. Последняя версия стандарта SPF (RFC 7208) требует наличия SPF-записи не только для основного почтового домена, но и для имен из команды HELO/EHLO, которые, как правило, совпадают с каноническими именами почтовых серверов. Это необходимо для прохождения SPF в случае пустого отправителя, используемого в NDR/MDN. Опубликуйте DMARC-запись с политикой none. Настройте адреса для сбора отчетов rua/ruf. Обратите внимание, что стандарт DMARC требует, чтобы домен, в котором находятся данные адреса, соответствовал домену, для которого запрашиваются отчеты, либо публиковал специальную политику приема отчетов, поэтому получать отчеты на адреса публичных почт так же не получится. Проанализируйте поступающие отчеты, устраните проблемы, связанные с SPF, DKIM и несоответствием (misalign) доменов из вашей сети, идентифицируйте возможные источники легальных писем вне ее (например, рассылки, организованные через внешние сервисы рассылок) и подстройте SPF и DKIM для всех легальных писем. Можно пользоваться услугами специализированных сервисов — Agari, proofpoint, Dmarcian. Сервис Dmarcian, помимо платных услуг, предлагает удобный бесплатный инструмент для визуального представления XML-отчетов DMARC. Когда все проблемы будут устранены, переключите политику на reject или quarantine.

…я администрирую почтовый сервер и хочу фильтровать письма по DMARC

Интегрируйте соответствующий фильтр. Фильтрация по DMARC поддерживается практически во всех антиспам-решениях. В качестве отдельных бесплатных DMARC-фильтров, совместимых с основными Linux/UNIX MTA, можно порекомендовать OpenDMARC и yenma.

…я администрирую почтовый сервер/домен и этот ваш SPF/DKIM/DMARC не знаю и знать не хочу

По мере внедрения строгой политики DMARC другими почтовыми доменами ваш домен, не защищенный политикой DMARC, будет все чаще использоваться спамерами как источник фальшивых адресов отправителей, что приведет к постоянному росту вторичного спама и, как следствие, жалоб пользователей. Скорее всего, в результате вы все равно будете вынуждены реализовать SPF/DKIM/DMARC. Но даже если вы сохраните стойкость, когда-нибудь домены без опубликованной политики могут начать восприниматься как подозрительные, в том числе самообучающимися фильтрами, что приведет к проблемам с доставляемостью писем.

…я администрирую почтовый сервер/домен и у меня есть вопросы

Вы можете задать их здесь в комментариях или на Тостере, я стараюсь отслеживать тематические хабы.

Электронная почта часто позиционируется критиками как неменяющийся динозавр из прошлого тысячелетия — но это не так: она развивается, и очень активно. Все актуальные версии основных стандартов электронной почты приняты в течение последних восьми лет, DMARC стал стандартом всего год назад, а в настоящее время идет работа по стандартизации, например, протоколов Authenticated Received Chain и SMTP Strict Transport Security. Но переход на новые стандарты и протоколы невозможен без поддержки всеми сторонами, и мы очень надеемся, что эта статья поможет и вам включиться в процесс построения более современной, удобной и безопасной экосистемы электронной почты.

Список бесплатных SMTP серверов для рассылки электронной почты

В этом разделе собран список бесплатных SMTP серверов, где можно создать аккаунт электронной почты для массовой отправки email через скрипт BiMailer. Использование любого из серверов, предполагает предварительную регистрацию, пройти которую можно постеив соответсвующую ссылку из таблицы. Особое внимание при ознакомлении со списком SMTP среверов для рассылки стоит уделить графе Нюансы. Для удобства загрузки в скрипт списков серверов, предусмотрен модуль загрузки SMTP из файла.

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

Название	Адрес SMTP и реквизиты	Нюансы
Яндекс	Адрес сервера: smtp.yandex.ru Порт: 465 SSL/TLS: Да Логин: логин при регистрации (адрес ящика без доменной зоны @yandex.ru) Пароль: указанный при регистрации	Проверяет текст исходящих email сообщений и может заблокировать аккаунт с формулировкой SPAM
Mail.ru	Адрес сервера: smtp.mail.ru Порт: 465 SSL/TLS: Да Логин: Полное имя почтового ящика, включая логин, @ и домен (*[email protected]) Пароль: указанный при регистрации	Требует подтверждение телефона при регистрации. Не позволяет отправялть письма с чужим email адресом отправителя. По этому скрипт email рассылки настроен заменять поле FROM — на адрес аккаунта mail.ru при отпрвке с этого SMTP
Рамблер	Адрес сервера: smtp.rambler.ru Порт: 465 SSL/TLS: Да Логин: Полное имя почтового ящика, включая логин, @ и домен (*[email protected]) Пароль: указанный при регистрации	Может заблокировать аккаунт за превышение количества отправляемых email писем в определенный промежуток времени
Гугл	Адрес сервера: smtp.gmail.com Порт: 465 SSL/TLS: Да Логин: Полное имя почтового ящика, включая логин, @ и домен (*[email protected]) Пароль: указанный при регистрации	Всегда меняет чужой адрес отправителя на адрес аккаунта @gmail.com. В зависимости от способа регистарции требует телефон. Может заблокировать аккаунт за превышение количества отправляемых email писем в определенный промежуток времени.
Microsoft Outlook	Адрес сервера: smtp-mail.outlook.com Порт: 25 SSL/TLS: Нет Логин: Полный email адрес, включая логин, @ и домен Пароль: указанный при регистрации	Всегда меняет чужой адрес и имя отправителя на свои в зоне @outlook.com или @hotmail.com. Если аккаунт регистрировался через outlook.com то нужно создать электронную почту по ссылке. Может заблокировать аккаунт за превышение количества отправляемых email писем в определенный промежуток времени.
QIP.ru	Адрес сервера: smtp.qip.ru Порт: 25 или 2525 SSL/TLS: Нет Логин: Полный email, включая логин, @ и домен (*[email protected]) Пароль: указанный при регистрации	Требуется телефон при регистрации. Не позволяет отправялть письма с чужим email адресом отправителя. По этому скрипт email рассылки настроен заменять поле FROM — на адрес аккаунта mail.ru при отпрвке с этого SMTP. После регистрации нужно войти в почту и нажать на кнопку создания почтового ящика. Подождать от 1 до 5 минут.
sibnet.ru	Адрес сервера: smtp.sibnet.ru Порт: 25 SSL/TLS: Нет Логин: Полный почтовый адрес, включая логин, @ и домен (*[email protected]) Пароль: указанный при регистрации	—