postfix как узнать версию

АНДРЕЙ БЕШКОВ

Postfix: диагностируем и устраняем неисправности

Postfix прост и надежен в эксплуатации, словно автомат Калашникова. Но все же неискоренимое человеческое любопытство нет-нет, да и заставляет нас задумываться над вопросами: Что будет, если в один прекрасный день Postfix перестанет работать? Смогу ли я понять, почему это произошло? Удастся ли мне его починить?

В предыдущих статьях [1, 2] мы говорили о том, как Postfix устроен изнутри, почему я считаю его одним из лучших SMTP MTA и как с его помощью построить корпоративный почтовый сервер. Многие читатели, ознакомившись с этими материалами, принялись за создание собственных систем на основе Postfix. Судя по откликам, 99% из них преуспели в этом начинании, у подавляющего большинства почтовый сервер работает в штатном режиме без каких-либо проблем уже год или более.

Все, о чем будет говориться сегодня, проверялось на версиях Postfix 2.2 под FreeBSD, Solaris и несколькими дистрибутивами Linux. Под всеми перечисленными системами приемы, которым я вас научу, работают практически одинаково. Мелкие различия в формате вывода информации на экран или названии директорий, в которых лежит тот или иной файл, в данном случае несущественны. Поэтому я думаю, что у вас не возникнет проблем с применением полученных знаний.

Итак, представим, что неприятности все же случились. Произошло это по вине неловкого администратора или аппаратного сбоя – неважно, наша задача – найти неполадки и исправить их. Каменщики обычно пляшут от печки, а мы начнем диагностику с проверки, запущен ли главный процесс Postfix. Сделать это проще всего командой:

В некоторых дистрибутивах Linux того же эффекта можно добиться командой:

# service postfix status

Убедившись в том, что процесс запущен, нужно переходить к следующему этапу и проверить, принимает ли он входящие соединения на 25-м порту нужных нам интерфейсов:

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

Теперь неплохо было бы приказать Postfix самому провести внутреннюю диагностику.

Как видите, в данном случае проблема состоит в неправильном синтаксисе файла main.cf. Впрочем, эта команда работает не только с конфигурационными файлами, заодно она позволяет убедиться, что все необходимые служебные файлы и директории имеют надлежащие права и принадлежат кому положено. Стоит отметить тот факт, что, если в результате проверки будут обнаружены проблемы с какими-либо директориями, Postfix попытается самостоятельно исправить их атрибуты. В случае успешности этого действия на экране не появится никаких предупреждений. Ну а если самостоятельно разобраться с проблемами не удастся, сообщения об ошибках будут достаточно детализированы и легко понятны даже начинающему администратору. Иногда случается так, что служебные директории бывают полностью удалены, в этом случае Postfix постарается самостоятельно восстановить их. Единственное, чего он не умеет создавать – бинарные выполняемые файлы взамен утраченных. После выполнения команды check неплохо было бы перезагрузить Postfix, в идеале это требуется редко, но иногда лучше перестраховаться:

Если все вышеперечисленные действия не спасли «отца русской демократии» и почта все еще не работает – значит пришло время заняться анализом протоколов работы почтовой системы. Обычно они находятся в /var/log/mail/ или /var/log/maillog. Если вам не удалось найти нужный файл, то в зависимости от того, какая система syslog у вас используется, посмотрите в /etc/syslog.conf или /etc/syslog-ng.conf. Поищите в этих файлах строки, где встречается mail, и вам сразу все станет понятно. Итак, с местонахождением протоколов мы определились, теперь следует посмотреть, что в них записано. В общем виде записи в протоколе должны выглядеть так:

Каждая запись состоит из нескольких компонентов. Перечисляем по порядку: дата и время события, имя хоста, имя компонента postfix и ID процесса, ну и, наконец, само сообщение.

Я уже упоминал, что Postfix является не монолитной программой, а целым содружеством демонов, во главе которых стоит процесс master. С точки зрения безопасности это неоспоримое преимущество, потому что отказ одного компонента не приведет к падению всех остальных. Но в то же время благодаря такому подходу каждая программа подсистемы самостоятельно отвечает за протоколирование результатов своей работы. Получается, что, несмотря на свое главенство, процесс master обладает лишь необходимым минимумом информации о подчиненных процессах. К примеру, он может сообщить, что, судя по коду ошибки, у процесса с определенным ID проблемы, но сути их master все равно не знает. В большинстве случаев поиск по ID процесса, на который пожаловался master, дает исчерпывающую информацию о неполадках в системе.

Для указания серьезности ошибки служат специально зарезервированные слова. Давайте рассмотрим их значение.

Посмотрим на одну из самых типичных записей об ошибке:

Jun 12 17:41:28 altlinux postfix/smtpd[24506]: fatal: open database /etc/postfix/helo_restriction.db: No such file or directory

Jun 12 17:41:29 altlinux postfix/master[23846]: warning: process /usr/lib/postfix/smtpd pid 24506 exit status 1

Судя по сообщению от postfix/master[23846], процесс postfix/smtpd[24506] аварийно завершил свою работу, потому что не смог найти файл служебных таблиц /etc/postfix/helo_restriction.db.

Делается это, к примеру, вот так:

Следующей весьма полезной для отладки командой является postconf. Она выводит на экран огромное количество информации о состоянии внутренних переменных и таким образом позволяет посмотреть, каковы на данный момент настройки postfix. Кстати, стоит отметить, что значение практически всех переменных, выводимых postconf, вы можете переопределить в файле main.cf. К примеру, узнать версию Postfix можно, выполнив:

# postconf | grep version

Представим, что нам необходимо посмотреть, что стало с тем или иным письмом. Подобная задача довольно часто встает перед администратором почтовой системы, когда пользователь звонит и жалуется, что ему два дня назад отправили письмо, а он его до сих пор не получил. Отследить путь прохождения письма довольно просто: нужно открыть файл протокола, найти сообщения о соединении с интересующего хоста. К примеру, нам интересно увидеть, куда делось письмо от vasa@unreal.net к ira@unreal.net. Ищем в протоколе vasa@unreal.net, например, с помощью grep и находим следующие строки:

Jun 12 19:11:19 altlinux postfix/smtpd[27445]: connect from clif.unreal.net[10.10.21.75]

Jun 12 19:12:09 altlinux postfix/smtpd[27445]: F29D3562E: client=clif.unreal.net[10.10.21.75]

Jun 12 15:12:27 altlinux postfix/cleanup[27482]: F29D3562E: message-id=20050612151145.F29D3562E@mailhost.unreal.net

Jun 12 19:12:27 altlinux postfix/qmgr[27342]: F29D3562E: from=, size=363, nrcpt=1 (queue active)

Jun 12 15:12:29 altlinux postfix/smtpd[27445]: disconnect from clif.unreal.net[10.10.21.75]

Из них следует, что письмо было принято от clif.unreal.net[10.10.21.75], и ему присвоен ID F29D3562E почтовой очереди. Выполним следующую команду:

# grep /var/log/maillog F29D3562E

Jun 12 19:12:27 altlinux postfix/local[27491]: F29D3562E: to=, relay=local, delay=42, status=sent

Jun 12 19:12:27 altlinux postfix/qmgr[27342]: F29D3562E: removed

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

Иногда бывает нужно проверить, как передается почта между нашим сервером и каким-либо другим. В случае если администрируемый сервер доступен для нас по SMTP, выполнить это достаточно просто. А что делать, если сервер предназначен для внутренней почты компании и находится в закрытой сети, соответственно у нас к нему есть доступ только по ssh или telnet? Первый способ – проверить прохождение почты: отправить письмо из командной строки с помощью команды mail и затем проанализировать то, что будет написано в файлах протокола. Большинство администраторов делает именно так, но есть более удобный путь. С помощью команды sendmail можно проверить прохождение почты гораздо более простым способом.

После доставки письма к vasa@unreal.net все данные, касающиеся этого факта, будут не только записаны в протокол, но еще и отправлены почтой пользователю, от имени которого была запущена программа. В нашем случае это пользователь root.

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

Еще одним удобным способом посмотреть, что происходит во время SMTP-сессии, является директива debug_peer_list из файла main.cf. Глобально включать отладку всех SMTP-соединений было бы очень накладно, поэтому в нее стоит добавлять только список хостов, взаимодействие с которыми мы хотим отслеживать тщательнее, чем обычно. К примеру, для наблюдения за передачей писем между нами и yandex.ru, mail.ru, pochta.ru и 10.10.10.23 строка могла бы выглядеть вот так:

debug_peer_list = yandex.ru, mail.ru pochta.ru 10.10.10.23/32 10.10.10.0/24

Как видите, хосты можно перечислять двумя путями – через запятую и через пробел. Впрочем, как вы уже убедились, никто не мешает в качестве хоста указывать IP-адреса или целые подсети вроде 10.10.10.0/32. С данной возможностью стоит обращаться очень осторожно, потому что каждая SMTP-сессия, попадающая под наш фильтр, записывает в файл протокола примерно 20 Кб текста. При большом потоке писем между нами и наблюдаемым хостом стоит немного зазеваться, и место на файловой системе /var может закончиться довольно быстро. Директива debug_peer_level указывает, насколько подробными должны быть отчеты. По умолчанию ее значение равно 2.

Ну а если и это не помогло, можно провести отладку с помощью интерактивного отладчика xgdb или его не интерактивного собрата gdb. За этот функционал отвечает директива debugger_command из файла main.cf. Впрочем, я сильно сомневаюсь, что она пригодится кому-то из вас. По крайней мере мне за последние три года ни разу не пришлось воспользоваться ею, даже под большой нагрузкой, Postfix работал без каких-либо нареканий.

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

Источник

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

Set up a mail server with PostfixAdmin

Это первая публикация. которая описывает создание необходимых записей DNS и объясняет, как установить и настроить Postfix Admin, Nginx с бесплатным сертификатом Let’s Encrypt, PHP и MySQL.

Прежде чем приступить

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

Настройки DNS

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

Обратный DNS (PTR)

Большинство почтовых серверов выполняют обратный поиск DNS по IP-адресу, который пытается подключиться к ним, и могут не принимать электронные письма от сервера, если не установлена ​​запись PTR.

В большинстве случаев записи PTR можно установить через веб-интерфейс вашего хостинг-провайдера или связавшись со службой поддержки и попросив их настроить правильную запись PTR для вас.

Вы можете использовать команду dig, чтобы узнать обратный DNS данного IP-адреса.

Создать системного пользователя

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

Следующая команда создаст новую группу и имя пользователя vmail и установит для домашнего каталога пользователя значение /var/mail/vmail :

Все виртуальные почтовые ящики будут храниться в /var/mail/vmail каталоге.

Установите Nginx PHP и MySQL

Выполните следующую команду, чтобы установить Nginx, PHP и все необходимые модули PHP:

Вам будет предложено создать корневой пароль MySQL во время установки.

Скачать и настроить Postfix Admin

На момент написания статьи, 3.1 это последняя стабильная версия Postfix Admin.

Загрузите архив Postfix Admin с помощью следующей команды wget :

После завершения загрузки распакуйте архив :

Переместите исходные файлы администратора Postfix в /var/www каталог и создайте templates_c каталог (кэш smarty):

И Nginx, и PHP-FPM работают под пользователем, www-data поэтому нам нужно сменить владельца /var/www/postfixadmin этого пользователя:

Postfix Admin будет использовать базу данных MySQL для хранения информации о пользователях, доменах и конфигурации приложения.

Авторизуйтесь на сервере БД MySQL :

Создайте нового пользователя и базу данных MySQL используя следующие команды:

Вместо того, чтобы редактировать конфигурацию Postfix Admin по умолчанию, мы создадим новый файл с именем, config.local.php который перезапишет настройки приложения по умолчанию:

Откройте файл с вашим текстовым файлом:

Вставьте следующий код php:

В приведенной выше конфигурации мы определяем тип базы данных и учетные данные для входа. Также мы указываем псевдонимы по умолчанию, отключаем fetchmail и включаем квоту.

Затем выполните следующую команду, чтобы создать схему для базы данных Postfix Admin:

После того, как база данных заполнена, мы можем продолжить и создать нашего первого пользователя PostfixAdmin superadmin, используя postfixadmin-cli инструмент.

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

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

Не забудьте изменить пароль ( P4ssvv0rD ) для учетной записи superadmin на более безопасный.

Установите бесплатный SSL-сертификат Let’s Encrypt

Мы собираемся использовать сертификат SSL для доступа к нашей установке Postfix Admin и включить шифрование Dovecot и Postfix SSL / TLS.

После того, как вы сгенерировали сертификат SSL, следуя приведенному выше учебнику, отредактируйте свой блок сервера Nginx следующим образом:

Перезагрузите службу Nginx, чтобы изменения вступили в силу:

Вывод

В этом руководстве вы установили Postfix Admin.

Источник

Диагностика почтовых протоколов

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

Материал разбит следующим образом:

1. Введение

В сети достаточно материалов по отдельным пунктам, но все разбросано по разным местам и, когда возникает необходимость выполнить ту или иную операцию, приходится по разным ресурсам вспоминать нюансы авторизации, способы быстрой кодировки в base64, ключи к openssl и tshark. Здесь все собрано вместе, а также добавлена информация о дешифровке SSL/TLS трафика.

Обозначения

$ — приглашение в обычном шелле, указанная после него команда выполняется от обычного пользователя

# — приглашение в рутовом шелле, указанная после него команда выполняется с правами администратора

## — строка с комментарием

Запрос клиента в почтовых сессиях выделен жирным шрифтом.

Почтовые порты

Основные порты, использующиеся в работе почтовых серверов по RFC (документы, регламентирующие работу сети интернет и ее основных компонентов):

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

Используемые и рекомендуемые утилиты

В статье используются telnet, openssl, tshark. Для наглядности взаимодействия сервера и клиента, использования команд протокола. На регулярной основе и для автоматизации каких-то процессов можно использовать утилиты, которые скрывают от нас все эти детали, но которые проще включаются в скрипты. Из таких утилит могу порекомендовать скрипт на perl smtp-cli (http://www.logix.cz/michal/devel/smtp-cli/), обладающий широкой функциональностью, в том числе и возможностью SMTP авторизации. Также рекомендую утилиту imtest из состава cyrus-clients, которой можно протестировать IMAP протокол. smtp-sink, утилиту из состава postfix, которая эмулирует почтовый сервер. С ее помощью можно отлаживать работу почтового клиента в том случае, если нет ни доступа к существующим почтовым серверам, ни возможности включения в настройках клиента подробного журналирования.

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

По этому выводу видно, что на сервере доступны SMTP/IMAP порты, но недоступны порты для
POP3 протокола.

Через netstat можно посмотреть не только прослушиваемые и используемые порты, как часто предполагают, но и процессы, связанные с этими портами. Вот вывод netstat для этого же почтового сервера:

В этом примере в качестве SMTP сервера используется postfix и dovecot в качестве IMAP. POP3 в списке отсутствует, так как в настройках dovecot этот протокол отключен, как неиспользуемый.

В современных дистрибутивах пакет net-tools уже часто не ставится, считается устаревшим. В качестве замены испольуется утилита ss из состава iproute. Это более узко заточенная и в свой области, вероятно, более функциональная утилита с возможностью настройки фильтров как в tcpdump/tshark. Но мне, например, не нравится, как у нее отформатирован вывод информации. Чтобы чуть это исправить, можно использовать sed:

*) для удобства использования можно поместить следующую bash функцию в

2. Примеры сессий

Здесь приведены примеры сессий по SMTP/IMAP/POP3 протоколам. Для соединения используется клиент телнет, который либо в системе установлен по-умолчанию, либо устанавливается из репозиториев:

Источник

Установка и настройка Postfix и Dovecot на Ubuntu 20.04

Postfix – это программный продукт, позволяющий организовать почтовый сервер. Он был создан как альтернатива Sendmail – старейшему агенту передачи почты (MTA – Mail Transfer Agent). Postfix распространяется с открытым исходным кодом и используется разработчиками для маршрутизации и пересылки почтовых писем внутри системы Linux.

В ходе сегодняшней статьи мы подробно рассмотрим, как выполняется установка и настройка Postfix на сервере Ubuntu 20.04, а также поговорим о том, что представляет собой Dovecot и как правильно его установить в связке с Postfix.

Требования

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

Обратите внимание на то, что настройка хоста будет выполняться с доменным именем типа email.example2.com. В последующем вам потребуется заменить все подобные значения на свое собственное доменное имя.

Как установить Postfix

По умолчания Postfix включен в репозиторий операционной системы Ubuntu, поэтому с установкой не должно возникнуть никаких проблем. Провести ее мы можем с использованием команды apt.

Первым делом обновляем кэш пакетов:

Затем устанавливаем непосредственно сам пакет Postfix. Здесь важно обратить внимание на значение DEBIAN_PRIORITY=low – оно позволяет нам подключить некоторые дополнительные опции.

В результате перед нами отобразится ряд вопросов и сообщений. Отвечаем на них следующим образом:

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

На этом установка Postfix на Ubuntu завершена, теперь можем переходить к более детальным настройкам.

Настройка Postfix

Большинство настроек конфигурации Postfix заданы в файле main.cf, который можно найти по адресу /etc/postfix/main.cf. Здесь мы можем пойти следующим образом: изменять параметры непосредственно в самом файле либо воспользоваться командой postconf.

Для настройки Postfix первым делом нам потребуется прописать расположение почты обычного пользователя Ubuntu. В нашем случае мы используем формат Maildir – в нем сообщения выделяются в отдельные файлы, перемещаемые между каталогами. Также вы можете хранить сообщения в формате mbox или любом удобном для вас.

Указываем значение Maildir для переменной home_mailbox. Настроить ее можно с помощью команды:

Прописываем расположение таблицы virtual_alias_maps, где все учетные записи почты сопоставляются с аккаунтами системы Linux. Также активируем еще одну команду, с помощью которой мы сопоставим расположение таблицы с файлом базы данных хэша в /etc/postfix/virtual:

Теперь мы можем начать сопоставление учетных записей почты с профилями пользователей в ОС Linux. Для этого создадим файл в nano, вы же можете выбрать любой другой текстовый редактор:

Записываем все адреса, для которых мы хотим получать электронную почту, а также прописываем пользователей Ubuntu Postfix, которым будут приходить письма. Для примера возьмем следующую ситуацию: нам нужно получать все письма на адреса excontact@example2.com и exadmin@examlpe2.com и отправлять их пользователю операционной системы Linux с именем UserNameZ7. В таком случае настройка файла будет выглядеть следующим образом:

После успешного ввода данных сохраняемся и выходим из файла. В нашем случае это редактор nano, поэтому зажимаем на клавиатуре комбинацию клавиш «CTRL+X, Y» и жмем «Enter». После этого осуществляем сопоставление строчкой кода:

Затем перезагружаемся командой:

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

Готово! Настройка Postfix на Ubuntu 20.04 прошла успешно. Теперь было бы хорошо его протестировать на почтовом клиенте, но сделать этого мы пока не можем. Прежде чем установить почтовый клиент, для начала нам нужно внести некоторые корректировки в параметры сервера Ubuntu.

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

В данном разделе мы установим пакет s-nail для взаимодействия с доставляемой почтой. Перед тем как начать установку, рекомендуем проверить настройку переменной среды «MAIL». Клиенту эта переменная необходима для того, чтобы определять места почты для пользователя.

Если необходимо гарантированно задать переменную MAIL, вне зависимости от способа доступа к учетной записи, потребуется указать ее в файле /etc/bash.bashrc и добавить в /etc/profile.d, чтобы она использовалась всеми юзерами.

Для этого введем следующее:

Чтобы прочитать переменную текущего сеанса, можно ввести:

Теперь мы можем переходить к установке клиента s-nail. Прописываем для этого:

Пока что не запускаем его, добавим в него несколько записей. Сначала откроем файл в редакторе nano:

В конец вставим следующее:

Расшифруем каждую строчку:

На этом с файлом заканчиваем – сохраняемся и закрываем его. Теперь нам потребуется выполнить еще одно действие – инициализировать структуру Maildir. Чтобы это сделать, необходимо отправить себе электронное письмо командой s-nail. Так как файл sent доступен только после создания Maildir, потребуется отключить запись в этот файл. Для этого воспользуемся командой -Snorecord.

Для отправки письма добавим строку в команду s-nail. Обратите внимание, что в конце указывается имя пользователя – вам потребуется изменить его на свое.

В ответе вы можете увидите сообщение:

Это нормально – такое сообщение обычно появляется только при первой отправке.

Убедимся, что каталог был создан:

В результате должно отобразиться примерно следующее:

Теперь мы можем перейти к тестированию почтового клиента.

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

Для начала запустим клиент, для этого используем команду:

Чтобы отправить сообщение, передадим содержимое текстового файла в процесс s-nail. Откроем для этого текстовый редактор:

Пропишем туда сообщение, например:

Сохраняемся и закрываем редактор. Для передачи сообщения в s-nail, используем команду cat. Она может принимать следующие значения:

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

После этого на указанную электронную почту должно прийти письмо. Чтобы проверить отправленные сообщения через s-nail, нужно прописать file +sent, где file – ваше уникальное название.

Установка и настройка Dovecot

Dovecot – это свободный IMAP- и POP3-сервер, разработанный с упором на безопасность. Нам он потребуется для того, чтобы подключить авторизацию по протоколу SMTP.

Устанавливаем Dovecot с компонентом для работы с СУБД:

Настраиваем способ хранения сообщений, для этого откроем файл:

Пропишем в него следующее:

В данном случае сообщения будут храниться в уже известном нам формате Maildir.

Далее настраиваем слушателя для аутентификации:

В файле прописываем:

На этом примере мы настраиваем сервис для аутентификации и создаем два прослушивателя: /var/spool/postfix/private/auth – для возможности Постфиксом использовать авторизацию через Dovecot, auth-userdb – сокет для авторизации через dovecot-lda.

В этот же файл добавляем:

Переходим к настройке аутентификации в Dovecot, открываем файл 10-auth.conf:

Задаем в нем следующие значения:

Открываем файл 10-ssl.conf командой vi /etc/dovecot/conf.d/10-ssl.conf и настраиваем в нем использование шифрования:

Добавляем автоматическое создания каталогов в файле vi /etc/dovecot/conf.d/15-lda.conf:

Настраиваем подключение к базе данных. Для начала открываем нужный файл:

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

Переходим к корректированию файла с настройками работы mySQL:

В конце файла добавляем:

Таким образом, мы смогли настроить запрос на получение данных из БД. Осталось сконфигурировать интерфейс, на котором мы будем слушать Dovecot:

В этот файл прописываем:

По умолчанию Dovecot слушает и на ipv6 (listen = *, ::). Если на сервере не используется 6-я версия протокола TCP/IP, то в логах могут быть ошибки.

Разрешаем запуск Dovecot:

Изменение конфигурации Postfix для Dovecot

Так как для отправки писем мы используем протокол SMTP через Dovecot, нам потребуется внести некоторые изменения в основном файле. Откроем его:

Изменяем в нем следующее:

Также комментируем строки:

Вместо них прописываем:

Откроем файл sudo nano /etc/postfix/master.cf и раскомментируем в нем строчку:

Осталось перезагрузиться в Postfix:

Теперь вы можете протестировать отправку почты. Обратите внимание, что у Dovecot также есть лог – чтобы его включить, необходимо открыть файл sudo nano /etc/dovecot/conf.d/10-logging.conf и внести в него корректировки:

Первая строка указывает на путь к логу, а вторая показывает неудачные попытки авторизации.

Заключение

Теперь вы знаете, как выполняется установка и настройка Postfix и Dovecot на Ubuntu 20.04. Начинающим системным администраторам на первый взгляд это может показаться непосильной задачей, но с данными инструкциями все должно получиться. Удачи!

Источник

Вам также может понравиться

Ставка в одну к одному: смысл и значение выражения

Выражение «сто к одному» является привычным

Компромисс и согласие: Расшифровка выражения ‘стерпится-слюбится’

Выражение «стерпится-слюбится» является популярным

Анализ выражения стать поперек горла

Выражение «стать поперек горла»

Что значит выражение cтановиться на задние лапки

Выражение «становиться на задние лапки»