Новый почтовый сервер Ubuntu 16.04 может получать, но не может отправлять электронные письма
Я следовал пошаговому руководству, найденному на Digitalocean, как настроить почтовый сервер на Ubuntu с Postfix, Dovecot, Mysql (последний я заменил на MariaDB) .
Проблема, с которой я столкнулся, заключается в том, что я могу получать письма, но не могу их отправлять.
Возможно, полезно знать, что я выполнил всю установку с моим пользователем и ключевым словом sudo .
Так что у меня уже есть эта проблема в течение 2 недель и я перепробовал так много вещей, что пришло время попытать счастья здесь.
При запуске sudo service postfix status я вижу следующее сообщение об ошибке, возвращающее
May 06 09:27:05 mailserver01 postfix/qmgr[8494]: 6AC1F2C093A: from=<info@mydomain.be>, size=652, nrcpt=1 (queue active)
May 06 09:27:05 mailserver01 postfix/postdrop[25691]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
May 06 09:27:06 mailserver01 postfix/sendmail[25689]: warning: command "/usr/sbin/postdrop -r" exited with status 1
May 06 09:27:06 mailserver01 postfix/sendmail[25689]: fatal: info@purewebdesign.be(1001): unable to execute /usr/sbin/postdrop -r: Success
May 06 09:27:06 mailserver01 postfix/pipe[25688]: 6AC1F2C093A: to=<jav@gmail.com>, relay=spamassassin, delay=147723, delays=147722/0/0/1, dsn=4.3.0, status=deferred (temporary failure. Command output: postdrop: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied sendmail: status=deferred (temporary failure. Command output: postdrop: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1 sendmail: fatal: info@purewebdesign.be(1001): unable to execute /usr/sbin/postdrop -r: Success )
May 06 09:33:48 mailserver01 postfix/submission/smtpd[25746]: connect from cust-228-37-109-94.dyn.as47377.net[94.109.37.228]
Возможно, это может быть проблема с разрешениями, о которых я знаю, но только для того, чтобы будьте ясны, я уже пытался создать новую группу с root, postfix, myuser, dovecot, spamd в качестве пользователей этой группы. Затем я дал этой группе права на чтение и запись в этой папке и подпапках postfix. Не повезло ...
вот разрешения на сегодня:
-rw-r----- 1 root root 153 Apr 28 12:51 dynamicmaps.cf
-rw-r--r-- 1 root root 2674 May 5 09:05 main.cf
-rw-r----- 1 root root 1388 Apr 28 14:23 main.cf.orig
-rw-r----- 1 root root 6261 May 5 09:49 master.cf
-rw-r----- 1 root postfix 142 May 1 13:07 mysql-virtual-alias-maps.cf
-rw-r----- 1 root postfix 130 May 1 13:08 mysql-virtual-mailbox-domains.cf
-rw-r----- 1 root postfix 129 May 1 13:07 mysql-virtual-mailbox-maps.cf
-rw-r----- 1 root root 21233 Apr 13 2016 postfix-files
-rwxr-x--- 1 root root 9344 Apr 13 2016 postfix-script
-rwxr-x--- 1 root root 29446 Apr 13 2016 post-install
drwxr-x--- 2 root root 4096 Apr 13 2016 sasl
Кто-нибудь знает, как это исправить?
postdrop обычно имеет установленный бит setgid, что означает, что когда другие процессы, такие как spamassasin, используют его для доставки почты, процесс выполняется под другим пользователем процессов (например, spamassasin), но postdrop ' s group:
$ ls -la `which postdrop`
-r-xr-sr-x 1 root postdrop 14328 Feb 5 2015 /usr/sbin/postdrop
^ ^
| |
setgid bit set executed with postdrop's privileges
Теперь журнал сообщает вам, что postdrop не может получить доступ к файлу конфигурации, который он должен прочитать:
May 06 09:27:05 mailserver01 postfix/postdrop[25691]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
Если посмотреть на права доступа к файлу, файл доступен для чтения и записи пользователю root, и читается корневой группой. Он не читается кем-либо еще (и это хорошо).
-rw-r----- 1 root root 153 Apr 28 12:51 dynamicmaps.cf
Чтобы решить эту проблему, измените владельца файла на группу postdrop ( chown postdrop /etc/postfix/dynamicmaps.cf). Разрешения на чтение должно быть достаточно, поэтому нет причин изменять разрешения. Если для других файлов также требуются отрегулированные привилегии, делайте это один за другим (или только с тщательным пересмотром необходимых привилегий). Часто серверные процессы отрицают выполнение каких-либо операций, если они распознают привилегии, выданные в широком смысле, чтобы уведомить вас об устранении проблем безопасности, вызванных, в частности, разрешениями на чтение и запись для всех в системе.