sendmail не может отправить почту из за ограничения доступа

PrivacyOptions - это не про то, это про работу по smtp.

«/usr/share/sendmail/sendmail cron-msp» - это про что ? Что есть тут «sendmail», и что есть «cron-msp» ? И что значит «обработать очередь» ? Обработчик основной очереди основным процессом и так запускается регулярно, дополнительно его можно дёрнуть посредством sendmail -q (но bin/sendmail). Обработчик клиентской очереди тоже должен быть запущен сам по себе:

108541 ? Ss 0:00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue

Subject: Cron <smmsp@pc-server-noname> test -x /etc/init.d/sendmail
			 &&  /usr/share/sendmail/sendmail cron-msp
You do not have permission to process the queue

это письмо администратору, соответственно cron-msp скорее всего демон(он же обработчик основной очереди, он же запущен сам по себе, его же можно дернуть посредством sendmail -q) который отправляет почту из очереди сообщений которые находятся в папках /var/spool/mqueue и /var/spool/mqueue-client
если что версия Debian GNU/Linux 7.1, почта по дефолту, единственное удалял и создавал заново папки mqueue из за спама в несколько гб.

ИМХО. Если есть возможность - замени sendmail на postfix либо exim

Есть возможность поменять, но проблемма как я понимаю не в самом sendmail а в правах доступа smmsp.
Не вижу смысла менять sendmail на postfix или exim если от почты нужно всего лишь отослать письмо во время регистрации пользователя.

замени sendmail на postfix либо exim

Обоснуй. :-)

Это заморочки именно sendmail. А поскольку крайне неудобен в настройке ( и скорее всего это не случайность ), его сейчас практически никто не использует

Гугли по «sendmail You do not have permission to process the queue»

У меня оно вот так (ALT Linux)

drwxrwx--- 2 smmsp smmsp 4096 Jan 10 12:05 clientmqueue
drwxr-x--- 4 root wheel 4096 Sep 9 19:51 mqueue

# ls -l mqueue
total 1016
drwxr-x--- 2 root wheel 499712 Jan 10 12:04 queue001
drwxr-x--- 2 root wheel 532480 Jan 10 12:05 queue002

По поводу queue001/queue002 - это
define(`QUEUE_DIR',`/var/spool/mqueue/queue*')

замени sendmail на postfix либо exim

Обоснуй. :-)

Их конфиги не нужно компилировать с помощью m4 ( тот ещё подарок ). Их конфиги более читаемы и предназначен не только для роботов и американосексуалистов.

Вот кстати

Привожу строчку из /etc/mail/sendmail.cf по умолчанию

А ты не забыл откомпилировать конфиг после изменения?

PrivacyOptions - это не про то, это про работу по smtp.

А вот здесь сказано, что именно про то.

Это заморочки именно sendmail.

Остальным MTA плевать на права доступа к каталогам ? :-)

( и скорее всего это не случайность )

Что же тогда с BSD-то вообще... :-) Толерантнее надо быть, толерантнее... ;-)

Остальным MTA плевать на права доступа к каталогам ? :-)

Остальные MTA поддерживают мейнтейнеры. И они к пользователям относятся дружелюбнее.

Толерантнее надо быть, толерантнее... ;-)

Мне доводилось настраивать sendmail на нескольких серверах. И я исчерпал на этот процесс весь свой запас толерантности на 10 лет вперёд.

А вот здесь сказано, что именно про то.

Ну так у него там про smtp опции перечислены.

Привожу строчку из /etc/mail/sendmail.cf по умолчанию

А ты не забыл откомпилировать конфиг после изменения?

Зачем, если он _уже_ из sendmail.cf строку показывает ?

Ну так у него там про smtp опции перечислены.

И restrictqrun

Зачем, если он _уже_ из sendmail.cf строку показывает ?

А вдруг он его вручную редактировал?

Остальные MTA поддерживают мейнтейнеры.

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

Мне доводилось настраивать sendmail на нескольких серверах.

Мне тоже. Ничего сложного, если по-умолчанию sendmail.cf собран хорошо. А чем не угодил m4, вообще непонятно - он и в autotools сейчас используется вовсю.

Гугли по «sendmail You do not have permission to process the queue»

Серьезно? Нет ты серьезно? Че? Правда что ли? Я убил полтора дня на гугле и яндексе, если бы нашел что то внятное здесь вопрос не задавал бы.

restrictqrun

А, ну да. Не дочитал. :-)

А вдруг он его вручную редактировал ?

И что ? killall -HUP sendmail достаточно. Ну или рестарта.

restrictqrun

А, ну да. Не дочитал. :-)

А вдруг он его вручную редактировал ?

И что ? killall -HUP sendmail достаточно. Ну или рестарта.

Насколько я знаю, откомпилированный конфиг sendmail напрямую загружается в память. И править его вручную - безумие.

Все верно, вручную! Сейчас загуглю как компилировать.

да рестарт делал, но ничего не компилировал

единственное удалял и создавал заново папки mqueue из за спама в несколько гб.

А до того работало ? Если да, надо тогда именно сверять права.

уже после этого работало, что случилось, неясно.

Сейчас загуглю как компилировать.

Это он про прототип конфига в mc. Если правишь в cf, не надо.
m4 sendmail.mc > sendmail.cf
Но если cf корректировал, а не mc, то исправления потеряешь.

Все верно, вручную!

То есть, cf правил всё же ?

Если правишь в cf, не надо

А его в принципе допустимо редактировать вручную?

А его в принципе допустимо редактировать вручную?

Конечно. m4 когда-то совсем не было. Но надо знать синтаксис. Ну и в рулесетах, действительно, можно запутаться. Вообще, в рулесеты последний раз руками я лет 15 назад лазить пробовал.

правил в sendmail.cf
потом делал /etc/init.d/sendmail restart

правил в sendmail.cf

А исходный sendmail.cf сохранился ? Может, именно исправления и виноваты ? Или все исправления - именно PrivacyOptions ? Если да, то надо посмотреть про restrictqrun, который router упомянул. Я, на вскидку, не помню, а у меня там пусто почти: PrivacyOptions=authwarnings

Эти изменения я как раз и делал чтобы избавиться от ошибки «You do not have permission to process the queue» потом вернул все обратно.
А исходный файл автоматически генерируется если его удалить и переустановить sendmail

Тогда так.

drwxrws--- 2 root smmsp 151552 Янв 10 10:20 mqueue-client

Это вот если поменять: chown smmsp: mqueue-client
Что получается ? Я правильно понимаю, что именно mqueue-client используется в Debian, как clientmqueue в ALT ? Ну и chown root: mqueue тоже надо, наверное.

Ещё, что касается прав, Sendmail не любит Group Writable каталоги. Так что, если это надо по условиям сборки/работы, надо дописать

O DontBlameSendmail=GroupWritableDirPathSafe

Или, если в mc, то
define(`confDONT_BLAME_SENDMAIL',`GroupWritableDirPathSafe')

Вот если поменять: chown smmsp mqueue, mqueue-client то возникают проблемы записи в эти папки, что возвращяет меня на предыдущий шаг(
К сожалению флаг GroupWritableDirPathSafe не помогает.
А вообще я получаю сообщение вида /var/log/mail.info

Jan 10 16:56:24 pc-server-noname sendmail[8149]: s0ACuOpe008149: from=www-data, size=688, class=0, nrcpts=1, msgid=<201401101256.s0ACuOpe008149@pc-server-noname.mysite.com>, relay=www-data@localhost
Jan 10 16:56:24 pc-server-noname sendmail[8149]: s0ACuOpe008149: to=mypochta@mail.ru, delay=00:00:00, mailer=esmtp, pri=30688, dsn=4.4.3, stat=queued

Jan 10 17:00:01 pc-server-noname sm-mta[8270]: s0AD01q9008269: to=administrator, ctladdr=<smmsp@pc-server-noname.mysite.com> (123/132), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30991, dsn=2.0.0, stat=Sent

У Sendmail всё должно совпадать по queue id. s0AD01q9008269 из второго не совпадает с s0ACuOpe008149. В общем, этот момент точнее надо отслеживать.

Но, главное, это понять, что с правами. Какие права у меня, я показал чуть раньше:
sendmail не может отправить почту из за ограничения доступа (комментарий)
Видимо, должно быть как-то похоже.

Я вот только не понимаю, почему переустановка-то не помогает... Я с deb, правда, дел не имел практически, но это странно. Там один пакет, или на несколько подпакетов разбито ?

Не совпадает потому что это разные письма, первое это неотправленое, а второе системное для администратора о ошибке.
Насчет прав, они даже немного выше.
Оказалось все более странно, нужно было просто перезагрузить сервак, хотя я сносил, пере запускал, танцы с бубнами получились какие то, 2 дня убил на этот бред и чтение системных логов(.

Насчет прав, они даже немного выше.

Это не менее плохо, чем ниже - Sendmail их проверяет, со слишком высокими не работает уже сам. Хотя это всё в логе пишется, по идее.

Оказалось все более странно, нужно было просто перезагрузить сервак

Действительно странно. Может, не все процессы sendmail убивались ? Хотя, если «killall -HUP sendmail» делался, конфиги должны были перечитывать, всё равно, все...

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

Не важно, если это о неотравленном (сильно заредактированный фрагмент):

sendmail[16687]: s0FANLcP016679: to=... stat=User unknown
sendmail[16687]: s0FANLcP016679: s0FANTcP016687: postmaster notify: User unknown
sendmail[16687]: s0FANTcP016687: to=postmaster@...

По поводу прав на папки, он писал ошибку если только 777 было.
kill процесса не делал, делал перезагрузку sendmail

/etc/init.d/sendmail restart

kill процесса не делал, делал перезагрузку sendmail

Тогда надо посмотреть в этот init.d/sendmail, что именно он там делает, и есть ли вероятность неперезапуска по restart. Хотя, это и сейчас можно проверить. Посмотри

ps ax|grep -i "accepting connections\|Queue runner"

со слишком высокими не работает уже сам.

Ты путаешь с sshd, а sendmail только ругается, но работает.

Ты путаешь с sshd, а sendmail только ругается, но работает.

Не путаю. Давно уже не работает, но не помню, с какой версии. Я выше по тексту писал про «O DontBlameSendmail», пока там специальные разрешения не опишешь, работать не будет.

Вот, убрал DontBlameSendmail=GroupWritableDirPathSafe:

Starting sendmail service: 451 4.0.0 /etc/mail/sendmail.cf: line 1846: Xmilter-mailfromd: local socket name /var/lib/mailfromd/mailfrom unsafe: Group writable directory

Хотя, он тут не запустился даже, так что, видимо, это было неправильное предположение, раз процесс не завершался.