| Каталог документации / Раздел "Настройка почты (sendmail, postfix, qmail)" / Оглавление документа |
| |
|
"unable to write /etc/mail/sendmail.pid"
на Solaris 2.x?
Kvirtuser к sendmail.cf?
Build
терпит неудачу потому что groff не был найден?
class hash not available"?
foo not available for
sendmail programs"?
Cannot open hash database ... Invalid
argument"?
parse error before `NDBM'"?
Используйте generics таблицу, как описано в шагах 6 и 7 на странице Virtual Hosting.
Этот вопрос обычно звучал так " Как я могу заставить пользовательскую базу данных работать с Pine или с FEATURE(always_add_domain)? ". Но пользовательская база данных - больше не рекомендуемое решение для этой проблемы, таким образом этот вопрос, соответственно, был решен.
Надлежащим решением является
использование generics таблицы, как описано ступенчато 6 и 7
на странице Virtual
Hosting. Важное замечание состоит в том, что
часть host/domain полностью-квалифицированного
доменного имени (FQDN) должна быть определена через GENERICS_DOMAIN() или GENERICS_DOMAIN_FILE().
Намерение состояло в том, чтобы иметь всю информацию о конкретном пользователе (где под именем пользователя имеется ввиду уникальное имя входа в систему (логин), а не имя и фамилия, которые, вообще говоря, не являются уникальными) в одном месте. Это решение должно было включать телефонные номера, адреса, и т.д. Особенность "maildrop"(что-то типа "почтовое преимущество"- прим.перев.) в том, что Berkeley не использует централизованный сервер почты (имеется ряд причин для этого, которые являются главным образом историческими), поэтому мы должны знать, где каждый пользователь получает его или ее доставленную почту, т.е. где находится его почтовая очередь.
UC Berkeley - находится (находился) в процессе установке своего окружения, таким образом, почта посланная просто на неквалифицированное имя "name", идет к этому человеку преимущественно через maildrop; почта посланная на "name@host" идет на тот хост. Цель "FEATURE(notsticky)" - заставить и для адреса вида "name@host" искать в базе данных пользователя для дальнейшей доставки к maildrop.
Поскольку имена и фамилия не уникальны. Например, компьютерное сообщество знает имеет двух Peter Deutsches. В одно время Bell Labs имели двух Stephen R. Bournes с кабинетами, располагающимися через несколько дверей. Вы можете создавать альтернативные адреса (например, Stephen_R_Bourne_2), но это вдвойне хуже - который из них должен осквернять свое имя таким образом? И Вы можете держать пари, что один из них получит большинство электронной почты другого.
Так называемые "имена и фамилия" - только попытка создать более длинные версии уникальных названий. Это довольно сильно убаюкивает людей в ощущение защиты, Я предпочел бы, что было бы чище, если бы эти ники были бы произвольны. Люди должны использовать хорошх почтовые клиентов, которые имеют отображения алиасов так, чтобы люди могли прикреплять произвольные названия для своего персонального использования с теми, с кем они переписываются (таких как файл алиасов MH).
Проблема вдвойне хуже вне Америки, где не - ASCII символы (например, символы с умлаутами или Норвежским Ш) используются в именах. С тех пор как не - ASCII символы не могут использоваться в конверте SMTP или заголовках электронной почты, имена и фамилия все равно будут искарежены, так или иначе.
Даже хуже - нечеткое соответствие в электронной почте может сделать хороший адрес плохим. Например, Эрик Аллман в настоящее время (как мы знаем, к лучшему) единственный "Allman" в Berkeley, так что почта, посланная <[email protected]> должна приниматься для него. Но если бы другой Allman когда-либо появился, этот адрес мог бы внезапно стать неоднозначным. Он был единственным Allman в Berkeley в течение более чем пятнадцати лет, чтобы внезапно заиметь на этот " хороший адрес " срыв почты, только потому что это неоднозначно. Это было бы отвратительно и неправильно.
Сервисы директорий должны быть настолько нечетки насколько возможно (в пределах здравого смысла, конечно). Почтовые сервисы должны быть уникальны.
Если Вы получаете такие сообщения иногда и случайно, они, вероятно, из-за временной сетевой проблемы, или отдаленной аварии хоста или же резкого завершение подключения. Если Вы получаете их много от одного конкретного хоста, имеется, вероятно, некоторая несовместимость между 8.x и тем хостом (см. Q3.12 и Q3.20). Если Вы получаете их много вообще, Вы можете иметь сетевые проблемы, которые заставляют связи сбрасываться.
Заметьте, что эта проблема иногда вызывается несовместимыми значениями MTU (Maximum Transmission Unit) в SLIP или PPP соединении. Убедитесь, что ваш размер MTU сконфигурирован так, что имеет то же самое значение, какое у вашего провайдера сконфигурировано для вашего подключения. Если Вы все еще имеете проблемы, то скажите вашему провайдеру сконфигурировать ваш размер MTU до 1500 (максимальное значение) и сконфигурируйте ваш размер MTU аналогично.
Другая возможность состоит в том, что Вы имеете router/firewall фильтрацию всех входящих ICMP сообщений, в то время как ваша OS выполняет "открытие канала MTU " (например современные версии Solaris делают это по умолчанию). Открытие канала MTU полагается на некоторые ICMP сообщения, возвращаемые обратно на хост, порождающий трафик - см. RFC 1191 для подробностей.
Я только что обновил к версии 8 sendmail и теперь, когда мои пользователи пробуют переправить их почту программе, они получают сообщения типа "illegal shell" или "cannot mail to programs" , и в итоге их почта не доставлена. Что является неправильным?
Чтобы люди были способны запускать программу от их .forward файла надлежащим образом, версия 8 sendmail настаивает, чтобы их shell (то есть shell, описаный для этого пользователя в passwd-вступлении) был "правильным" shell'ом, и означал оболочку, перечисленную в /etc/shells. Если /etc/shells не существует, используется список, заданный по умолчанию, обычно состоящий из /bin/sh и /bin/csh.
Это касается переменных окружения, которые могут иметь каталоги NFS-shared на машинах, на которых пользователи не имеют разрешения на вход в систему. Например, много людей делают свой файловый сервер недоступным, для эффективности или из соображений безопасности; и хотя пользователи имеют каталоги, их shell на сервере - /usr/local/etc/nologin или подобный. Если Вы уже разрешили им запускать программы, так или иначе Вы могли бы также разрешить им и входить на сервер.
Если Вы хотите разрешить пользователям выполнять программы от их .forward файла даже в том случае, если они не могут выполнить telnet или rsh вход(было бы разумно, если бы Вы использовали smrsh для контроля списка программ, которые пользователи могут запускать) тогда прибавьте строку:
/SENDMAIL/ANY/SHELL/
К /etc/shells. Это должно быть напечатано точно также, как здесь обозначено, заглавными буквах, с конечным слэшем.
NOTA BENE: НЕ ДЕЛАЙТЕ список /usr/local/etc/nologin в /etc/shells - это откроет другие проблемы безопасности.
IBM AIX не использует /etc/shells - список допустимых оболочек входа в систему содержится, наряду с многими другими параметрами входа в систему, в /etc/security/login.cfg. Вы можете скопировать информацию в строфу "shells =" в /etc/shells на вашей системе и таким образом sendmail будет уже иметь кое-что для использования. Не добавляйте "/usr/lib/uucp/uucico" или любую другую non-login оболочку в систему в /etc/shells.
Также замечено, что имеются некоторые таинственные вещи, которые AFS бросают в смесь, и это может "предохранять" программу от выполнения или корректного выполнения из .forward файла или системных алиасов..
См. также "smrsh" в Q2.13 и Q3.34, и "права на директории" в Q3.33.
Я только что обновил к версии 8 sendmail и внезапно соединения на порту SMTP стали занимать много времени. Что идет не так, как надо?
Это, вероятно, что-то таинственное в вашей реализации TCP, которая выполняет процесс IDENT несколько странно. На большинстве систем версия 8 sendmail пробует делать "callback" ("обратный звонок"-прим.перев.) на соединяющийся хост, чтобы получить утвержденное имя пользователя (см. RFC 1413 для подробностей). Если соединяющийся хост не поддерживает такой сервис, это быстро потерпит неудачу с сообщением "Connection refused", но правилные виды пакетных фильтров и правильные TCP реализации не допускают подобного простоя.
Чтобы проверять это (в версии pre-8.7.y sendmail), установите IDENT таймаут в ноль, используя:
define(`confREAD_TIMEOUT',`Ident=0')dnl
в .mc файле, используемом препроцессором m4 для генерирации вашего файла sendmail.cf. Как альтернатива, если Вы не используете m4, Вы можете поместить "`OrIdent=0'' в конфигурационном файле (мы рекомендуем решение с m4, так как это делает эксплуатацию sendmail намного проще для людей, которые не понимают правил перезаписи sendmail, или после того, как вы были немного далеко от этого некоторое время). В любом случае, это полностью отключит все использование IDENT протокола.
Для версии 8.7.y sendmail (и выше), Вы должны вместо этого использовать:
define(`confTO_IDENT',`0s')dnl
Другая возможная проблема в том, что Вы имеете ваш сервер имен и/или резольвер, сконфигурированный ненадлежащим образом. Удостоверитесь, что все строчки "nameserver" в /etc/resolv.conf указывают на функционирующие серверы. Если у Вас запущен свой собственный сервер, будьте уверенны, что все серверы, перечисленные в вашем корневом кэше являются современными (этот файл обычно называется как-то вроде "/var/namedb/root.cache"; см. ваш /etc/named.boot файл чтобы получить ваше название). Любой из них может вызывать длительные задержки.
Вы можете также просмотреть наши советы о том, как set up DNS for your private address space (установить DNS для вашего частного адресного пространства-прим.перев.).
Я только что обновил к версии 8 sendmail, и внезапно я получаю ошибки типа " unknown mailer error 5 -- mail: options MUST PRECEDE recipients" Что идет не так, как надо?
Вам необходимо посмотреть OSTYPE (systype) в вашем .mc файле, где "systype" должна быть установлена корректно для вашей hardware & OS комбинации, иначе конфигурация использует значение по умолчанию, которое, вероятно, не согласуется с вашей локальной почтовой системой. См. страницу конфигурации OSTYPE для подробностей.
Если это появляется на рабочей станции Sun, Вы можете также посмотреть на флаги локального мэйлера в поставляемом Sun sendmail.cf и сравнить их с флагами локального мэйлера, сгенерированными для вашей версии 8 sendmail.cf. Если они отличаются, Вы можете попробовать изменить флаги V8, чтобы они соответствовали флагам Sun.
Sendmail 8.7.y вызывает панику SunOS 4.1.3_U1 (по крайней мере для версий 1 < = y < = 3) и SunOS 4.1.3 и sendmail 8.6.x кажутся прекрасными на обеих машинах (по крайней мере для версий 9 < = x < = 12).
Проблема состоит в том, что отсутствует ядерная заплата, особенно 100584-08 (4.1.3), 102010-05 (4.1.3_U1), или 102517 (4.1.4). Это должно быть доступно от вашего поставщика аппаратуры согласно с вашим контрактом поддержки или через их онлайновые средства поддержки (включая уже доступный на SunSolve CD).
``It's not a bug, it's a feature.''"Это
не баг, это особенность." Это случается, когда Вы имеете
собственный список алиасов, и посылаете Вы также списку. V8 размножает информацию о
владельце в поле отправителя конверта SMTP (который
появляется как Unix-строка From (имеется ввиду
UUCP, где первой строкой конверта идет From без
двоеточия, затем имя отправителя и хоста в
UUCP-формате - прим.перев. ) [иногда неправильно
упоминаемое как заголовок From-space (или From_
чтобы не путать с From: - прим.перев.)] в почте Unix или как
Return-Path: header) так, что появляющиеся ошибки
будут, соответственно, возвращаться
собственному списку адресатов вместо
того, чтобы быть передаными. Чтобы сделать это
максимально незаметным, насколько возможно,
для конечных пользователяй, я рекомендую
сделать собственный указатель для "запрашиваемого" адреса,
например:
list: :include:/path/name/list.list
owner-list: list-request
list-request: eric
Это сделает сообщения, посланные на список list, выходящими с строкой "
From list-request" вместо
"From eric".
Верьте этому или нет, но это сделано намеренно. Интерпретация стандартов версией 8 sendmail группой разработчиков была таковой, что это была бы неуместная перезапись, и если бы перезапись заголовка оказалась некорректной, по крайней мере конверт содержал бы правильный обратный адрес.
Если вы используете версию 8.7.y sendmail (или более позднюю), Вы можете использовать
FEATURE(masquerade_envelope)В вашем sendmail.mc файле, чтобы изменить это поведение. Это обсуждено в больших деталях на странице конфигурации Masquerading and Relaying.
Получите нововведение протокола mail11 Китом Муром с ftp://gatekeeper.dec.com/pub/DEC/gwtools/ (с дополнениями от Пола Викси).
Когда я смотрю в директорию очереди, я вижу, что qf* файл был переименован к Qf *, и sendmail не видит его. Что является неправильным?
Если Вы посмотрите поближе, Вы найдете, что Qf файл принадлежит пользователям, отличным от root. С тех пор как sendmail выполняется как root, он отказывается доверять в не принадлежащих root директориях qf-файлам, потому переименовывает их в Qf, выбрасывает из очереди и облегчает для Вас их поиск. Обычно, причина этого двояка: во-первых, Вы имеете каталог очереди перезаписываемым для всего мира (что является, вероятно, ошибкой - это открывает другие проблемы безопасности), во-вторых, кто - то вызывает sendmail с " опасным " флагом, обычно флагом -o, который устанавливает опцию, которая может ставить под угрозу защиту. Когда sendmail видит это, он активизирует разрешения setuid root.
Обычное решение- не использовать проблематичные флаги. Если Вы должны использовать их, Вы должны создать специальный каталог очереди и обрабатывать его тем же самым uid'ом, который выполнял работу в первом случае.
Это рассматривается скорее как проблема MUA, чем проблема MTA.
Рассказывает Эрик Аллман:
Во-первых, информация о необходимости выполнения кодирования (то есть 8- > 7 бит) является неизвестной для MTA. В особенности, набор символов, использующийся для кодирования названия в заголовках НЕ обязательно тот же самый, какой используется для кодирования тела (которое уже закодировано в MIME в параметре набора символов Content-Type: header). Кроме того, это совершенно разумно для, скажем, шведа, живущего и работающего в Корее, или русского, живущего и работающего в Германии, и желающих, чтобы их имена были закодированы в их родном наборе символов; может быть даже то, что отправитель японец, получатель русский, и тело закодировано в ISO 8859-1. Если все, что я имею - 8-разрядные символы, я не могу выбирать набор символов должным образом.Точно так же при выполнении 7- > 8 битного преобразования я не хочу отбрасывать эту информацию, поскольку она необходима для правильного представления конечному пользователю.
Это обычно вызывается багом в сервере почты отдаленного хоста, или MTA. Команда ESMTP "EHLO" заставляет отдаленный сервер сбрасывать SMTP соединение. Имеются несколько MTA, которые имеют эту проблему, но одна из наиболее общих реализаций сервера может быть идентифицирована по приветствию "220 All set, fire away" которое выдается, когда Вы подключаетесь по telnet к ее порту SMTP.
Чтобы работать, обходя эту проблему, Вы можете сконфигурировать sendmail так, чтобы использовать mailertable со вступлением, сообщающим sendmail использовать простой SMTP при соединении с тем хостом:
Name.of.remote.host smtp:name.of.remote.host
Узлы, которые должны поддерживать хосты с этой ошибкой SMTP выполнения, должны делать так при наличии узла, исполняющего sendmail или какого-нибудб надежного другого (и разумно современного) SMTP MTA действующего как MX сервер для проблемного хоста.
Имеется также проблема, в результате чего некоторые TCP / IP реализации являются поврежденными, и если любая попытка соединения к удаленному узлу заканчивается выдачей "connection refused", то и *всеl* соединения к тому узлу будут закрыты. Конечно, если Вы пробуете использовать IDENT протокол через брэндмауэр (с обоих сторон), это, скорее всего, приведет к тому же самому виду "ошибки чтения".
Наладка этого проста - на машинах с ошибочными реализациями TCP / IP не пытайтесь использовать IDENT. При компилировании более новых выпусков версии 8 sendmail, компилятор должен автоматически обнаружить, находитесь ли вы на машине, которая известна как имеющая этот вид проблемы работы с сетями TCP / IP и удостоверится, что sendmail не пытается использовать IDENT. Если с тех пор вы исправили вашу машину так, что она больше не имеет этой проблемы, вы должны будете вернуться назад и явно сконфигурировать sendmail для поддержки IDENT, если, конечно, Вы хотите такую особенность.
При создании m4 Master Config (".mc") файла для версии 8 sendmail, много макрокоманд FEATURE() просто заменяют определение внутренних переменных, которые вызываются в определениях MAILER().
Чтобы удостовериться, что все работает как хочется, Вы должны проверить, что макрокоманды OSTYPE () помещены в самое начало файла, затем идут макрокоманды FEATURE() и HACK(),затем локальные определения, и в самом конце определения MAILER(). См. конфигурационную страницу Introduction and Example для более подробного объяснения.
В случаях, когда Вы находитесь позади firewall или на dial-up линии, имеются моменты, когда Вы должны быть уверены, что программы (такие как sendmail) не используют DNS вообще.
В старших выпусках версии 8 sendmail (8.7 и ранее), Вы должны перекомпилировать двоичный код и убедиться, что опция "NAMED_BIND" выключена в src/conf.h.
С версиями 8.8 и позже, Вы изменяете service switch file так, чтобы опустить "DNS" и использовать только NIS, файлы, и другие типы отображений как подходящие. Подробная информация относительно service switch file может быть найдена под опцией ServiceSwitchFile в 5.6 (Options)of the Installation and Operation Guide и всего 4.9 (Name Server Access).
Также, начиная с 8.9, этому может помочь
включение следующего в ваш .mc file:
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`accept_unqualified_senders')dnl
Отметьте, что вам придется отправлять всю вашу исходящую почту на другую машину, обозначенную как "relay"(ту, которая использует DNS, и понимает, как правильно использовать MX записи, и т.д ...), иначе Вы не сможете посылать почту на любой узел, кроме тех, которые сконфигурированы в вашем файле /etc/hosts (или любом аналогичном).
В contrib каталоге дистрибутива sendmail
есть сценарий Perl, который называется etrn.pl.
Предполагается, что вы используете sendmail или
некоторого другого SMTP MTA на одном из видов Unix
хостов, и ваш провайдер использует версию 8.8 sendmail, и
они ставят в очередь всю почту для вашего домена (вместо
помещения ее всю в один файл, который Вы должны загрузить через POP3 или
что-то подобное), команда
Etrn.pl mail.myisp.com mydomain.comсделает уловку. Вы можете узнавать о Perl на Perl Language Home Page. Книга O'Reilly также очень полезна.
Если Вы не имеете Perl, что-то вроде следующего сценария должно делать уловку:
#!/bin/sh
telnet mail.myisp.com. 25 << __EOF__
EHLO me.mydomain.com
ETRN mydomain.com
QUIT
__EOF__
Заметьте, что это выровнено для разборчивости, реальный сценарий имел бы позицию столбца #1 в файле, т.е. был бы первым печатаемым символом в каждой строке.
Конечно, вы должны будете заполнить соответствующие подробности для "mail.myisp.com", "mydomain.com", и т.д ....
Если ваш провайдер не использует версию 8.8 sendmail, Вам, вероятно, придется создавать вместе альтернативные решения. Они могут иметь сценарий "ppplogin", который выполняется каждый раз, когда ваши машины набирают их номер, и если так, Вы можете быть способны изменить этот сценарий так, чтобы поместить "sendmail - qRmydomain.com" в него (который эффективно делает то, что и команда "ETRN", но более безопасным способом).
Альтернативно, они могут иметь finger демона и, таким образом, вам надо будет поместить "finger [email protected]" в вашем сценарие. Или же они могут иметь некоторое другое решение для Вас. Однако, только они были бы способны ответить, какие приемлемые решения они имеют.
Очевидно, самым простым и наиболее "стандартным" решением является модернизация их системы к самому современному устойчивому выпуску версии 8 sendmail. См., что Q2.8, чтобы выяснить точную версию этого.
"unable to write /etc/mail/sendmail.pid"
на Solaris 2.x ?
Sendmail проверяет имеется ли доступ на
запись в директорию, в которой требуется создать файл без
использования специальных привилегий 'root'. Чтобы
sendmail работал надлежащым образом,
директориии /etc, /etc/mail, и/или /var/run должны принадлежать
root и быть перезаписываемыми своим владельцем.
Sendmail 8.8 поддерживает только Berkeley DB 1.85. Это не будет работать с более новыми версиями Berkeley DB , даже в режиме совместимости
Однако, Sendmail 8.9 включает поддержку для Berkeley DB 2. X, начиная с версии 2.3.16.
Berkeley sendmail 8.9.3 поддерживают наиболее известные разновидности UNIX, включая:
386BSD A-UX AIX Altos BSD-OS BSD43 CLIX CSOS ConvexOS Dell DomainOS Dynix EWS-UX_V FreeBSD HP-UX IRIX ISC KSR LUNA Linux Mach386 NCR.MP-RAS NEWS-OS NeXT NetBSD NonStop-UX OSF1 OpenBSD PTX Paragon PowerUX RISCos SCO SINIX SMP_DC.OSx.NILE Solaris SVR4 SunOS Titan ULTRIX UMAX UNICOS UNIX_SV.4.x.i386 UX4800 UXPDS Utah dgux maxion uts.systemV
Кроме того, версия для Windows NT таже доступна от Sendmail, Inc.
Вы должны добавить полностью-квалифицированное имя хоста и-или АДРЕС IP каждого клиента к классу R,
который устанавливает набор допустимых
релеев доменов. Для версии 8.8. X, это обычно определено файлом
/etc/sendmail.cR; для 8.9. X, это - обычно /etc/mail/relay-domains. Нота: если ваша
DNS (ДОМЕННАЯ СИСТЕМА ИМЕН) проблематична, Вы должны перечислить
IP-адреса (например, 1.2.3.4); вообще, однако, в этом не должно быть необходимости.
Как только вы модифицировали соответствующий файл,
сделайте SIGHUP вашему sendmail демону, и
Все должно быть OK.
Расширенные подробности доступны на нашей странице Allowing controlled SMTP relaying in Sendmail 8.9.
Kvirtuser к sendmail.cf?Одно только добавление
соответствующей строки Kvirtuser к sendmail.cf не
достаточно, чтобы активизировать свойство
virtual user table, ключевой компонент для виртуального
хостинга. Вы должны использовать метод m4 FEATURE(virtusertable);
более подробные инструкции перечислены на
нашей странице Virtual
Hosting with Sendmail.
Сваливание многочисленной пользовательской почты в одиночный почтовый ящик явлеется не очень хорошим методом распределения почты пользователей, но если Вы вынуждены делать это, следующее решение должно позволить приложению, подобному fetchmail отделять сообщения для индивидуальных пользователей.
FEATURE(local_procmail) в вашем .mc файле,
таким образом procmail (который Вы должны установить отдельно)
будет доставлять почту в почтовый ящик.
FEATURE(virtusertable), чтобы создать
virtual user table вступление для домена следующим образом:
@domain.com domuser+%1Где
domuser - имя пользователя почтового ящика, который Вы будете использовать. Заметьте, что "domuser"
должно быть фактическое имя пользователя,
НЕ алиас.
Может быть необходимо приобщить "@localhost" следующим образом
@domain.com domuser+%1@localhost
domuser's $HOME/.procmailrc:
DOMAIN=domain.com
ENV_TO=$1
:0f * ENV_TO ?? .
| formail -i "X-Envelope-To: "$ENV_TO@$DOMAIN
:0fE
| formail -i "X-Envelope-To: UNKNOWN"
Это вставит
X-Envelope-To заголовок с
первоначальным адресом получателя в
конверте, когда сообщение поставлено нормальный
путем через virtusertable, и UNKNOWN, если по некоторым причинам это было послано непосредственно domuser.
Вы можете соблазниться устранить переменную ENV_TO и использовать $1 непосредственно. Это не будет работать,
так что не беспокойтесь.
FEATURE(local_procmail)
заставляет sendmail поставлять электронную почту непосредственно
procmail . A. .forward файл не только ненужен,
он предотвращает использование procmail
установок $1 с необходимым текстом,
так что не используйте его.
Вам может быть
также необходимо заменить formail на /usr/local/bin/formail или
что-то подобное, в зависимости от того, может ли procmail
найти это или нет.
Build
терпит неудачу потому что groff не был найден?Вы можете получить groff от ftp://ftp.gnu.org/pub/gnu/. Но это - не большое решение, потому что:
% cp *.0 obj*
class hash not available"?
Вы сформировали sendmail и/или makemap без NEWDB, указанного в вашей DBMDEF конфигурации, но Вы определили
класс hash в sendmail.cf или в makemap команде.Класс hash
требует поддержки NEWDB, для которой
Вам необходима Berkeley database. Пожалуйста,
перейдите к разделу Database
Definitions нашей страницы Compiling
Sendmail.
Мы имели некоторые запросы относительно этого, поскольку majordomo очевидно предлагает некоторые конфигурационные значения, которые sendmail 8.9 не любит. Имеется то, что предлагает один эксперт:
Sendmail.cf содержит:
O AliasFile=/etc/aliases, /etc/majordomo.aliases
O DontBlameSendmail=Safe
/etc/aliases Содержит общие majordomo алиасы:
# Majordomo
majordomo: "|/usr/local/lib/majordomo/wrapper majordomo"
owner-majordomo: postmaster
majordomo-owner: postmaster
/etc/majordomo.aliases Содержит списки majordomo форм:
wookie: "|/usr/local/lib/majordomo/wrapper resend -l wookie
wookie-list" wookie-list: :include:/usr/local/lib/majordomo/lists/wookie
owner-wookie: head-wookie
wookie-approval: owner-wookie
wookie-request: "|/usr/local/lib/majordomo/wrapper majordomo -l wookie"
Различные каталоги владельцы/группы/права:
drwxr-xr-x 20 root root 1024 Dec 1 15:20 / drwxr-xr-x 25 root root 3072 Jan 26 01:26 /etc drwxr-xr-x 20 root root 1024 Feb 4 1998 /usr drwxr-xr-x 18 root root 1024 Jan 16 18:40 /usr/local drwxr-xr-x 5 root root 1024 Feb 6 1996 /usr/local/lib lrwxrwxrwx 1 root root 16 Dec 1 10:01 /usr/local/lib/majordomo -> majordomo-1.94.4 drwxr-x--x 5 majordom majordom 1024 Jan 25 23:12 /usr/local/lib/majordomo-1.94.4 drwxr-xr-x 2 majordom majordom 32768 Jan 26 00:49 /usr/local/lib/majordomo-1.94.4/lists -rw-rw-r-- 1 majordom majordom 655 Nov 3 17:03 /usr/local/lib/majordomo-1.94.4/lists/wookie -rw-rw---- 1 majordom majordom 14588 Jan 19 10:28 /usr/local/lib/majordomo-1.94.4/lists/wookie.config -rw-rw-r-- 1 majordom majordom 23 Jan 14 1997 /usr/local/lib/majordomo-1.94.4/lists/wookie.infoТеперь различия, которые делают эту работу, могут не быть теми же самыми, как проинструктировано majordomo командами:
majordom, группа majordom.
majordom, группа majordom.
majordom продолжать управлять списками.
Следующее взято непосредственно из раздела DIRECTORY PERMISSIONS README файла верхнего уровня в дистрибутиве sendmail.
Sendmail часто обвиняется во многих проблемах, которые являются фактически результатом других проблем, типа чрезмерно разрешающих режимов доступа к каталогам. По этой причине, sendmail проверяет режимы доступа в системных каталогах и файлах, чтобы определить степень доверия. Чтобы sendmail выполнялся без жалоб, Вы ДОЛЖНЫ выполнить следующие команды:
chmod go-w / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
chown root / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
Вероятно, Вы будете должны наладить это для вашего окружения (например, некоторые системы помещает каталог spool в /usr/spool вместо /var/spool и использует /etc/mail для файла алиасов названий вместо /etc). Если Вы устанавливаете опцию RunAsUser в вашем sendmail.cf, каталог /var/spool/mqueue должен принадлежать RunAsUser пользователю. Как общее правило, после того, как Вы откомпилировали sendmail, выполните команду
Sendmail -v -bi
чтобы инициализировать базу данных алиасов. Если это дает сообщения типа
WARNING: writable directory /etc
WARNING: writable directory /usr/spool/mqueue
Тогда перечисленные каталоги имеют несоответствующие разрешения на запись и должны быть защищены, чтобы избежать различных возможных атак на защиту.
Начинаясь с sendmail 8.9, эти проверки стали более строгими, чтобы предотвратить пользователей от способности обратиться к файлу, который они обычно не были способны читать. В частности .forward и:include: файлы в опасных путях каталогов (пути каталогов, которые являются перезаписываемыми группой или всем миром) больше не будут позволяться. Это подразумевало бы, что если бы домашняя директория пользователя Джо была бы перезаписываемой членами группы, sendmail не использовал бы его .forward файл. Это поведение может быть изменено, за счет системной защиты, устанавливая опцию DontBlameSendmail. Например, чтобы разрешить .forward файл в перезаписываемых группой каталогах:
O DontBlameSendmail=forwardfileingroupwritabledirpathИли разрешить их и в групповых, и мировых перезаписываемых каталогах:
O DontBlameSendmail=forwardfileinunsafedirpathОбъекты этих небезопасных .forward и:include: файлов будут помечены как опасные адреса - объекты не могут быть доставлены в файлы или программы. Это поведение может также быть изменено через DontBlameSendmail:
O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafeПервый флажок позволяет .forward файлу читаться, второй позволяет объектам в файле быть помеченным как безопасные для доставки к файлам и программам.
Другие файлы, на которые воздействует эта усиленная защита
включают
файлы классов (то есть. Fw /etc/sendmail.cw),
постоянный ведущий файл состояния, и файлы,
определенные опциями ErrorHeader и HelpFile. Подобные
флаги DontBlameSendmail также доступны для классов,
ErrorHeader и HelpFile файлов.
Если Вы имеете опасную конфигурацию .forward и:include:
файлов, Вы можете делать это безопасным,
найдя все такие
файлы, и выполнив "chmod go-w $FILE"
на каждом. Также сделайте "chmod go-w $DIR"
для каждого каталога в пути файла.
foo not available for
sendmail programs"?
Это значит, что Вы используете smrsh, sendmail
ограниченную оболочку; см. Q2.13 для подробностей
насчет этого. Чтобы фиксировать эту проблему, Вы должны создать sym-связь от каталога smrsh's для ограниченных программ к программе foo. Заданное по умолчанию расположение этого каталога для ограниченных программ
следующее: /usr/adm/sm.bin в Open Source версии, но версии
продавцов отличаются. Например, RedHat Linux 6.0
использует /etc/smrsh, и Solaris 8 использует /var/adm/sm.bin. Если Вы не знаете каталог для
вашей OS, сначала проверьте smrsh руководство, если это
потерпит неудачу, попытайтесь:
% strings /path/to/smrsh | grep ^/Где
/path/to/smrsh есть P= argument на
строке Mprog в sendmail.cf.
Таким образом, например:
% cd /usr/adm/sm.bin
% ln -s /usr/bin/vacation
Позволил бы программе vacation быть выполняемой от пользовательского .forward файла или алиаса, который использует
"|program" синтаксис.
Наконец, если Вы хотите отключить использование smrsh, удалите
FEATURE(`smrsh') строку из .mc файла, который
формирует sendmail.cf; см. cf/README для подробностей относительно этого.
Это весьма усложнено. На первый взгляд это могло бы быть просто: только "cat" некоторый текст (взятый из файла или чего-нибудь) в конец сообщений электроннай почты, передающихся через sendmail. Однако, имеется большая проблема: что относительно структурированых сообщений электронной почты, то есть, сообщений MIME? Они могут быть произвольно cкомплектованы и только "cat" нижнего колонтитула к концу тела сообщения может нарушить структуру MIME. (MIME понимающий MUA не будет только показывать такой нижний колонтитул, так что это довольно бесполезно в любом случае.) Но подписанные сообщения (подумайте: PGP) будут нарушаться. Следовательно, не имеется никакого простого решения этой проблемы!
Если Вы знаете достаточно относительно MIME и некоторого программирования C, то смотрите на sendmail 8.11 и libmilter/README. Это
сегодня предлагает некоторые функциональные возможности, чтобы достичь этой цели. Однако, это неподдерживаемо sendmail.org! Пожалуйста не
спрашивайте у нас вопросы относительно libmilter. (тем
не менее, мы можем наладить баги!)
Cannot open hash database ... Invalid
argument" ?Это - ошибка, возвращаемая библиотекой Berkeley DB . Это обычно означает, что db файл был сформирован с версией Berkeley DB, отличной от той, которую sendmail использует в настоящее время . Вы должны перекомпилировать makemap с той же самой версией Berkeley DB, с какой был откомпилирован sendmail , и переделать ваши карты (map) с этой новой версией makemap.
От типичной Unix 'errno' man page:
22 EINVAL Invalid argument. Some invalid argument was supplied.
(был подан некоторый ошибочный параметр)От Berkeley DB 2.x 'db_open' man page (1.x 'dbopen' подобен):
EINVAL ...
There is a mismatch between the version number of file and the software
(имеется несоответствие между номером версии файла и программного обеспечения).Berkeley DB 3.x использует специальное значение errno для этого - из его 'db_open' man page:
DB_OLD_VERSION The database cannot be opened without being first upgraded
(база данных не может быть открыта без того, чтобы вначале обновиться).К сожалению это специально не обрабатывается sendmail upto, включая и 8.11.2, что приводя к сообщению об ошибке, которое говорит что-то типа "Error -30990 " вместо " Invalid argument ".
Имеется таблица, отображающая версии Berkeley DB с соответствием версиям sendmail , в которых они поддержаны:
| Berkeley DB | Sendmail |
|---|---|
| 0.X - 1.4 (OLD_NEWDB) | 8.1 - 8.8.8 |
| 1.5 and later 1.X | 8.1 and later |
| 2.0.0-2.6.3 | 8.9.0 and later |
| 2.6.4 and later 2.X | 8.9.2 and later |
| 3.0 and later 3.X | 8.10.0 and later |
parse error before `NDBM'"?Эта ошибка в общем случае сопровождается сообщением, указывающим, в котором файле это произошло и какой номер строки этого файла вызвал эту ошибку , обычно следующим образом:
ERROR NDBM or NEWDB must be defined.Предполагается, что Вы читаете эту строку, и делаете что-нибудь в связи с этим.
Обычно на Linux и различных версиях BSD используется NEWDB, в то время как в коммерческих реализациях Unix (Solaris, HP-UX и возможных других) используется NDBM. Возможно, Вам не удалось устанавить требуемые библиотеки, когда Вы устанавливали вашу систему.
Пожалуйста, смотрите 3.31 и раздел Database Definitions нашей страницы Compiling Sendmail для допольнительных подробностей.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |