Последняя модифицикация 8 сентября, 2001
Русскоязычный перевод 11 декабря 2001
Оригинал документа досупен на сайте Проект "Русскоязычный Sendmail"
Комментарии и вопросы по этому FAQ должны направляться по адресу sendmail+faq@sendmail.org.
(Комментарии и вопросы
на русском языке направлять по адресу sendmail@aiq.ru
-прим.перев.)
Общие вопросы относительно sendmail должны
направляться по адресу sendmail-questions@sendmail.org.
Сообщения о багах (ошибках) должны направляться по
адресу sendmail-bugs@sendmail.org.
Сообщения по качеству русскоязычного перевода просьба направлять по адресу sendmail@aiq.ru
Если Вы посылаете сообщение в группу новостей comp.mail.sendmail и посылаете его одному из вышеупомянутых адресов, пожалуйста ясно указывайте это в заголовке вашего сообщения.
Оглавление
"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'"?unknown mailer
error 1"?
NOQUEUE: Null
connection from ..."?
"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, так что почта, посланная <Allman@Berkeley.EDU> должна приниматься для него. Но если бы другой 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 mydomain.com@theirhost.theirdomain.com" в вашем сценарие. Или же они могут иметь некоторое другое решение для Вас. Однако, только они были бы способны ответить, какие приемлемые решения они имеют.
Очевидно, самым простым и наиболее "стандартным" решением является модернизация их системы к самому современному устойчивому выпуску версии 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 для допольнительных подробностей.
unknown mailer error 1"?
NOQUEUE: Null connection
from ..."?
Если это возможно, то нет.
Уайлдкард MX записей имеет много семантического "мусора". Например, она будет соответствовать хосту "unknown.your.domain" - если Вы явно не проверяете ваш домен на неизвестные хосты, Вы получите "MX list for hostname points back to hostname"( MX список для пунктов имени хоста обратно к имени хоста" ) или "config error: mail loops back to myself" ("ошибка конфигурации: почта возвращена к началу цикла ко мне же непосредственно").
См. RFCS 1535, 1536, и 1912 (обновленный RFC 1537)для большего количества деталей и других связанный (или общих) проблем. См. также _DNS и BIND_ Albitz и Liu.
Они могут также заставлять вашу систему прибавлять ваш домен к исходящему FQDN в отчаянной попытке послать почту туда, куда она якобы адресована, но потому что *.your.domain допустим из-за уайлдкарты MX, доставка к not.real.domain.your.domain будет формировать дамп на Вас же, и Вы можете даже оказаться в цикле, поскольку домен продолжает становиться прикрепляемым все последующее время раз за разом (проблема "config error: mail loops back to myself").
Уайлдкард MX записей - только плохая идея, это очевидно и просто. Они не работают так, как вы ожидаете, и фактически никто не получает их права. Избегайте их любой ценой.
Это - проблема локального мэйлера, а не проблема sendmail. В зависимости от того, что вы делаете, смотрите на procmail (см. Q4.9), ftpmail, или Majordomo.
Самая последняя версия Majordomo может быть найдена в ftp://ftp.greatcircle.com/pub/majordomo/. Она написана на Perl и требует или Perl 4.036, или, кажется, выполняется с небольшими отклонениями только под версией 5.001a или более поздней. Для уверенности, проверьте веб-интерфейс для Majordomo называемый LWGATE в http://www.netspace.org/users/dwb/lwgate.html. Самые последние версии Perl (и 4.x и 5.x) могут быть найдены в http://www.metronet.com/perlinfo/src/. Подробная информация относительно Perl может быть найдена в http://www.metronet.com/perlinfo/perl5.html
Самая последняя версия ftpmail может быть найдена в ftp://src.doc.ic.ac.uk/packages/ftpmail или любом архиве comp.sources.misc (том 37).
Опять же, это - локальная проблема мэйлера, а не проблема sendmail. Или модифицируйте ваш мэйлер (потребуется исходный текст) или измените программу, названную "локальным" мэйлером в описании конфигурации, на новую программу, которая способна выполнять такую локальную доставку. Одна программа, которая способна выполнять это - procmail (см. Q4.9), хотя, вероятно, имеется также много других программ.
Или, я пробую использовать флаг "не передают дорогому мэйлеру" , и это доставляет почту в интерактивном режиме так или иначе. Я могу видеть, что это делается, поскольку имеется вывод " sendmail -v foo@somehost " (или Mail -v или эквивалент).
Флаг -v в sendmail (который связан с флагом -v в Mail и других программах этого семейства) указывает sendmail наблюдать транзакцию. Так как Вы явно захотели видеть то, что происходит, предполагается, что Вы не хотите использовать очередь, и поэтому эта особенность выключается. Удалите флаг -v и используйте вместо этого команду "tail -f" вашего лога (выводит последние 10 строк файла - прим.перев.) , чтобы видеть то, что происходит.
Если Вы пытаетесь использовать флаг "не передавать дорогому мэйлеру " (флаг мэйлера "e"), убедитесь, что Вы также включаете глобальную опцию "HoldExpensive" (чьё старое односимвольное название было "C") - иначе флаг мэйлера будет игнорироваться .
Я получаю такие сообщения об ошибках:
553 MX list for domain.net points back to relay.domain.net
554 <user@domain.net>... Local configuration error
Как я могу решить эту проблему?
Вы попросили почту в домен (например, domain.net)
принимать вначале на определенный хост (в этом случае relay.domain.net) используя
MX запись, но машина релея не признает себя как domain.net.
Добавьте domain.net в файл /etc/mail/local-host-names [известный как /etc/sendmail.cw до версии 8.10] (если Вы используете
FEATURE(`use_cw_file')) или добавьте " Cw domain.net "
в ваш конфигурационный файл.
Имеется пара дополнительных случаев, где Вы фактически не можете хотеть локальной доставки, и таким образом добавление domain.net к классу w не будет правильным решением:
kill -HUP `head -1 /var/run/sendmail.pid`
Я соединяюсь с сетью с помощью SLIP/PPP соединения. Иногда мой процесс sendmail зависает (хотя видно что часть сообщения была передана). Все остальное работает. Что является неправильным?
Наиболее вероятно, это проблема вообще не sendmail , а низкогоуровневого сетевого соединения. Важно чтобы MTU (Maximum Transfer Unit) для SLIP/PPP соединения был установлен должным образом с обеих сторон. Если же они не соответствуют, большие пакеты будут застревать, и подключение зависнет.
Этот вопрос обсужден на страницах 445-449 of _sendmail, 2nd Ed_ (см. страницу 319 первого издания) Брайеном Косталесом (см. вступление sendmail-faq // book/ISBN/1-56592-222-0 в Q6.1).
Чтобы посмотреть, что еще является доступным на сегодня, проверьте Comprehensive Perl Archive Network. Для получения дополнительной информации, см. the comp.lang.perl.* FAQs at ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/perl/
Если вы заинтересованы в использовании этих видов приложений, помогающих Вам осуществлять некоторый оперативный контроль вашей системы, Вы можете заинтересоваться MEWS (Mail Early Warning System). Из README:
If you've ever written a perl script to parse sendmail log files looking for errors, MEWS might be of interest to you. If you've ever thought about writing a perl script to munge sendmail log files, cringed a little and hurriedly came up with an excuse not to do it, read on. If you don't have a Solaris 2.5 machine, you can probably stop reading here. The Mail Early Warning System (MEWS) gives postmasters immediate notification of trouble spots on your mail backbone. It only works with sendmail. To explain it in a nutshell, whenever sendmail returns a 4xx or 5xx SMTP code, with the MEWS modifications, it also sends the code over UDP to a daemon which then replays the error message to interested parties. The man pages go into a little bit more detail.
(все классно, только надо Solaris - прим.перев.)Если это как-то звучит, Вы можете быть заинтересованы в получении большего количества подробностей, Вы можете найти архив MEWS в ftp://ftp.qualcomm.com/pub/people/eamonn/mews.tar.Z.
Имеется обновление от Stephane Lentz 29 июня, 2000:
См. также страницу sendmail tools Джона Оливера для указания на несколько связанных скриптов(25 мая, 2001)
Ссылки Брэда Ноулеса для popstats, smtpstats and syslog_stats были восстановлены в новом месте. (29 мая, 2001)
Рекомендуемая программа для этого - "checksendmail" от Роба Колстада. Старые версии ее доступны на различных архивных узлах, но в настоящее время единственный способ получить самую современную версию (которая была модифицирована, чтобы понимать длинный синтаксис названий опций версии 8.7 , а также теперь поддерживает и Perl 4.x и Perl 5.x) - от самого Роба.
Самый последний архив будет сделан общедоступным (наиболее вероятно через SMTPRD, выполненный Andras Salamon; см. Q6.5, entry sendmail-faq // online/index/14) сразу как только будет получен.
Программа "procmail" - замена для локального мэйлера (с различными именами: /bin/mail, /usr/bin/mail, mail.local, rmail, и т.д ...). Она была перенесена практически на каждую Unix-подобную OS, с которой вы можете столкнуться, и имеет целый набор основных особенностей. Обычно, это приблизительно на 30 % более быстрее выполнение работы локального мэйлера в сравнении с программами типа /bin/mail или /usr/bin/mail, она испытавалась на прочность настолько сильно, что это сделало ее чрезвычайно безопасной (намного более безопасной чем большинство локальных мэйлеров) и очень устойчивой. Procmail также способен помочь Вам установить квоту на пользовательский почтовый ящик через стандартый Unix-механизм квоты (см. Q4.3).
Короче говоря, независимо от того, что вы имеете, вам почти гарантируют, что procmail лучше (если нечего добавить, отмечу, что автор был способен сфокусировать большое количество времени и энергии в создание этой самой лучшей и самой быстрой доступной утилиты, в то время как большинство системных продавцов только выбрасывает кое-что так быстро, как только они могут, а затем переходят к целой паузе OS).
Однако, это только поверхность того, на что способен procmail .Наиболее важная особенность этого то, что фактически это дает Вам, стандартный способ создания правил (procmail называет их "recipes"(рецепты)) чтобы обработать вашу почту прежде чем сообщения помещаются в ваш почтовый ящик, эта особенность - одна из наиболее важных утилит, какие каждый администратор может найти в ее наборе. Фильтруя или автоматически борясь с 80 % вашего ежедневного мусора, она позволяет Вам тратить большее количество времени на более жесткие 20 % случаев.
Объявлено, что в последние выпуски версии 8 sendmail встроена поддержка использования procmail как альтернативного локального мэйлера (см. "FEATURE(local_procmail" для версии 8.7 и выше). Они также поддерживают procmail как дополнительный локальный мэйлер, если вы заинтересованы в полной замене вашего текущего локального мэйлера на procmail (см. "MAILER(procmail)" в версии 8.7 и выше).
Вы можете также установить procmail как пользователь и выполнять его из вашего .forward файла, хотя подобное имеет тенденцию быть немного медленным и менее эффективным.
Подробная информация относительно procmail может быть найдена в http://www.procmail.org/ и самая последняя версия может быть найдена в ftp://ftp.procmail.org/pub/procmail/.
Procmail - также ядро в пакете управлений списком рассылки, называемом "SmartList", так что, если вы уже получили procmail, добавление SmartList может быть хорошей опцией. Некоторые владельцы рассылок предпочитают Majordomo, Listserv, или одну из других такого рода программ, но SmartList также имеет более чем несколько сторонников. Ваши персональные вкусы диктуют, присягаете ли Вы SmartList или нет.
Я обновил sendmail, полученную от моего продавца к самой последней версии, и теперь я получаю эти сообщения об ошибках, когда выполняю "newaliases":
/etc/aliases: line 13: MAILER-DAEMON... cannot alias non-local names
/etc/aliases: line 14: postmaster... cannot alias non-local names
Как мне решить эту проблему?
Ваше локальный мэйлер не имеет специального флага "A". Редактируйте строчку Mlocal в файле sendmail.cf и добавьте "A" к флгам, перечисленным после " F = ".
Еще лучше, если вы используете последнюю версию sendmail, которая использует m4 для генерации .cf файла из .mc файла, сгенерируйте ваш sendmail.cf, и посмотрите, фиксирует ли это проблему. Не забудьте установить новый sendmail.cf и перезапустить демона sendmail.
Пожалуйста, посмотрите страницу Year 2000 Readiness Disclosure.
Сначала, Вы должны заставить sendmail не использовать DNS на вашей локальной машине таким образом, чтобы ваш хост не пытался соединиться с вашим провайдером для DNS запросов. См. Q3.22 для получения дополнительной информации.
Вы также должны определить "smart host" или внешний релей, чтобы обрабатывать всю почту, которую Вы не можете доставить локально (это и будет почтовый сервер вашего провайдера).
Вы должны сконфигурировать это так, чтобы smtp
мэйлер рассмотривался как "expensive",
добавив F=e флаг мэйлера и сообщив sendmail не соединяться с
expensive мэйлерами по умолчанию, устанавливая опцию
HoldExpensive
в True.
Вы должны добавить mydomain.com к sendmail.cw файлу, или
в строчку Cw в файл sendmail.cf. См. Q4.5.
Наконец, Вы должны запускать программу периодически, чтобы отдать ваш пакет вашему провайдеру и доставить любую почту, которая, возможно, уже стоит у провайдера в очереди для Вас. См. Q3.23.
unknown mailer error 1"?
Вообще говоря, sendmail не выполняет
конечную доставку сообщений, а полагается
вместо этого на локального доставочного
агента . Такой агент как mail.local
поставляется вместе с дистрибутивом sendmail.
Любой такой агент, которого sendmail вызывает для
доставки сообщения, как определено в
строке М в файле sendmail.cf, должен выйти с кодом 0 (успешно), или
одним из кодов неисправностей, отмеченных в src/sysexits.h. Они
обычно работают в диапазоне 64 - 78, так что 1
находится вне этого диапазона, что и
приводит к генерации sendmail вышеупомянутой ошибки.
Ситуация: Ваша система mailserver.my.domain должна действовать как
вспомогательный почтовый сервер для mailserver.destination.domain. Клиент хочет принять почту
для адреса user@destination.domain. Для этого требуется:
destination.domain. IN MX 10 mailserver.destination.domain. destination.domain. IN MX 20 mailserver.my.domain. mailserver.destination.domain. IN MX 10 mailserver.destination.domain. mailserver.destination.domain. IN MX 20 mailserver.my.domain.
Последние две записи "на всякий случай" (если
кто-то забыл о маскарадинге).
Удостоверитесь, что Вы используете реальные
имена всех систем, Mailserver.my.domain
должно быть его собственным именем, иначе вы получите известную
ошибку mail
loops back to myself.
Вместо использования MX записей, которые указывают на mailserver.destination.domain, Вы можете использовать
FEATURE(mailertable) на mailserver.my.domain как объяснено в cf/README для
routing e-mails.
destination.domain к
required
files (8.9) (или для 8.8).
Не прибавляйте destination.domain или mailserver.destination.domain к классу w на вашей системе!
ETRN
Вы не можете. Sendmail это mail transfer agent (MTA)- почтовый сервер. Создание сообщений электронной почты, включая добавление вложений или сигнатуры, является функцией mail user agent (MUA) - почтового клиента. Некоторые популярные почтовые клиенты: mutt, elm, exmh, Netscape, Eudora и Pine. Некоторые специализированные пакеты (metamail, некоторые модули Perl и т.д.) также могут использоваться, чтобы создавать сообщения с вложениями.
Выяснять, который версия выполняется фактически, сделайте извне telnet на порт SMTP (порт 25). Демон обычно объявляет свое название и номер версии, как в следующем случае:
thishost% telnet that.host 25 Trying IP_addr... Connected to that.host. Escape character is '^]'. 220 that.host ESMTP Sendmail 8.9.3/8.9.3; Mon, 2 Aug 1999 11:39:34 -0700 ^] telnet> quitСделайте второй запрос на вашем локальном хосте, следующая команда должна отобразить ее номер версии, наряду с некоторой дополнительной конфигурационной информацией, возможно включая конфигурационный номер версии:
% echo \$Z | /usr/sbin/sendmail -bt -d0
Version 8.10.2
Compiled with: MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND
NETINET NETUNIX NEWDB NIS QUEUE SCANF SMTP USERDB XDEBUG
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = knecht
(canonical domain name) $j = knecht.Sendmail.ORG
(subdomain name) $m = Sendmail.ORG
(node name) $k = knecht.Sendmail.ORG
========================================================
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 8.10.2
%
Скорректируйте путь как правильно; наиболее обычные расположения -
/usr/lib и /usr/sbin
.
В действительности Вы не должны этого делать, потому что символы верхнего регистра в именах пользователей противоречат традиции Unix . Если Вы это сделаете, то адреса электронной почты будут зависимы от регистра, так что почта к <USER@your.host> будет сброшена вместо того чтобы быть доставленой к <user@your.host>. Поскольку это противоречит ожиданиям многих, это не рекомендуется.
Но если Вы все равно настаиваете на выполнении этого, и Вы имеете версию 8.10, поместите следующее в ваш .mc file:
MODIFY_MAILER_FLAGS(`LOCAL', `+u')dnlЕсли Вы не имеете версии 8.10, Вы будете должны переопределить переменную m4
LOCAL_MAILER_FLAGS , но её первоначальное значение изменяется от OS до OS, так что это
еще одна причина не портить этот флаг.
Другая уловка - создание алиасов для локальных пользователей с символами верхнего регистра в именах в форме:
# lowercase version to real one
uppercase: UppercaseЭто будет заставлять sendmail доставлять сообщения локальным пользователям с символами верхнего регистра в именах в случае нечувствительности sendmail к регистру.
NOQUEUE: Null connection
from ..."?Сообщение подобно:
NOQUEUE: Null connection from host.domain [IP.AD.DD.RESS]В logfile означает, что
host.domain
соединился с вашим MTA, но ни
инициализировал передачу сообщения (издавая команду MAIL), ни
использовал любую из команд, которые зарегистрированы отдельно (EXPN/VRFY/ETRN). Если это не случается очень часто, Вы можете
проигнорировать это. Если же это случается очень часто, это является или
чьей-то игрой, или это - сетевая проблема.Примечание1: существенная
часть сообщения не NOQUEUE, а "Null
connection from ...". В частности NOQUEUE не
ошибка индикации,а только "метка - заполнитель" когда
идентификатор очереди не был назначен, обычно, потому что
передача совокупности сообщений не началась (все же). Это может
случаться также и в других сообщениях, и там
также существенная часть та, которая
поступает после NOQUEUE.
Примечание
2: В 8.10, текст, который вводил в замешательство был
заменен на: "... did not issue MAIL/EXPN/VRFY/ETRN during
connection to ..."
Вы не нужно делать это. Sendmail - почтовый сервер, чья главная цель состоит в том, чтобы посылать и принимать электронную почту (прежде всего через SMTP). Sendmail не выполняет никаких протоколов удаленного доступа типа POP или IMAP. Но если Вы хотите узнать больше относительно этих и других (не - sendmail) вещей, связанных с электронной почтой, пожалуйста обратитесь к нашей странице Other (Non-Sendmail) E-Mail Related Links.
Это требует заказного программирования. Вы могли или записывать фильтр почты, используя новый (в настоящее время не поддержанный) Milter API в sendmail 8.10 и позже (см. libmilter/README) или же Вы можете посмотреть на некоторые другие неподдерживаемые подсказки:
Не имеется никакого волшебного короткой команды для этого. Но это нетрудно установить: создайте пункт в файле алиасов
alluser: :include:/etc/mail/allusersНе забудьте выполнить ' newaliases'. Затем перечислите ваших пользователей, по одному в строке, в файле. Вы можете сделать это с помощью:
awk -F: '$3 > 100 { print $1 }' /etc/passwd > /etc/mail/allusers
Когда я использую sendmail V8 с файлом конфигурации Sun, я получаю строки типа:
/etc/sendmail.cf: line 273: replacement $3 out of boundsРассматриваемая линия читается так:
R$*<@$%y>$* $1<@$2.LOCAL>$3 user@etherЧто это значит? Как я могу исправить это?
V8 не признает Sun'овский "$%y" синтаксис, таким образом, как рассматривается в этом контексте, имеется только $1 и $2 (но не $3) в этой строке. Читайте Rick McCarty's документ "Converting Standard Sun Config Files to Sendmail Version 8", в contrib директории (файл "converting.sun.configs") самой последней версии дистрибутива sendmail для полного решения того, как сделать это.
Когда я использую sendmail V8 на Sun, я иногда получаю строки типа:
/etc/sendmail.cf: line 445: bad ruleset 96 (50 max)Что это значит? Как я могу исправить это?
Вы так или иначе пробуете запускать старый Sun sendmail (или sendmail.mx) с версией 8 файла конфигурации sendmail, который Sun sendmail не любит. Проверьте ваш /etc/rc.local, любые процедуры, которые были созданы, чтобы останавливать и перезапускать процессы sendmail, и т.д .... Удостовертесь, что вы переключили их все на использование нового sendmail. Чтобы сохранить эту проблему от каких-либо проявлений в дальнейшем, пробуйте следующее (удостоверитесь, что вы входите в систему как root):
mv /usr/lib/sendmail /usr/lib/sendmail.old
ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
chmod 0000 /usr/lib/sendmail.old
chmod 0000 /usr/lib/sendmail.mx.old
Предполагается, конечно, что Вы установили sendmail V8 в /usr/local/lib/sendmail.v8.
При переходе от Solaris 2.4 к Solaris 2.5 ядро изменило свое название и находится теперь в /kernel/genunix вместо /kernel/unix, так что _PATH_UNIX в conf.h указывает на неправильное местоположение.
Если Вы не можете обновить до самого последнего выпуска sendmail 8.8.z, лучшее, что можно сделать - изменить _PATH_UNIX в conf.h (в solaris2 части) чтобы указать на настраиваемый интерфейс /dev/ksyms, примерно так:
# define _PATH_UNIX "/dev/ksyms"
Наиболее вероятная проблема - в ваших библиотеках резольвера (DNS, /etc/hosts, NIS, etc...). Старые библиотеки резольвера Sun (и Solaris?) распределили достаточный участок памяти только для пяти IP-адресов для каждого имени хоста, и если какая-либо программа когда-либо попадает на имя с более чем пятью IP-адресами, программа вызывает аварийную ситуацию.
Например, это предохранило бы Вас от посылки почты к CompuServe, с тех пор как (во время написания этой записи) они перечислили одиннадцать IP-адресов для mx1.compuserve.com (одно из имен сервера MX для compuserve.com).
Это коснется Вас, даже если Вы используете версию 8 sendmail, так как это - проблема в библиотеках резольвера, а не в sendmail непосредственно.
Вы должны или получить патчи к библиотекам резольвера от Sun, или самую последнюю версию BIND (см. Q2.12) и установить их библиотеки резольвера надлежащим образом. Из этих двух вариантов, установка BIND - немного большая работа, но это, как правило, даст Вам намного более современный код, который поможет Вам сопротивляться атакам на ваши системы, более способные программы для использования при обслуживании DNS (включая поддержку IPV6 и некоторых других особенностей) и некоторые очень полезные утилиты.
Много людей испытали проблемы компиляции на Solaris, с
компилятором, обычно жалующимся относительно tm_zone или TopFrame.
Solaris section
нашей страницы Compiling
Sendmail объясняет это.
С Vn/Berkeley файлом конфигурации они идентичны.
Имеется несколько незначительных различий между 8. X с Vn/Berkeley файлом конфигурации и 8. X+Sun с тем же самым файлом конфигурации, но строкой V,
замененной на Vn/Sun. Но большинство различий -
обратные трюки совместимости, необходимые для 8. X+Sun, чтобы поддержать старый V1/Sun
файл конфигурации.
Имеются три веб-страницы, которые обсуждают это подробно: Berkeley migration (от SMI-8.6 до 8. X), Sun migration (от SMI-8.6 до 8. X+Sun), и Differences (5 разделов, сравнивающие и противопоставляющие файлы конфигурации и бинарный код).
Когда я использую версию 8 sendmail на IBM RS/6000 выполняющем AIX, системный контроллер ресурса всегда сообщает о sendmail как "недействующий", даже в том случае, когда он фактически выполняется. Что является неправильным?
При выполнении как daemon sendmail отделяется от своего родительского процесса, вводя SRC в заблуждение, что sendmail вышел. Чтобы исправить это, используйте команды:
kill `head -1 /etc/sendmail.pid`
chssys -s sendmail -f 9 -n 15 -S -a "-d99.100"
# use "-d0.1" in sendmail 8.6.x
startsrc -s sendmail -a "-bd -q30m"
# your sendmail args may vary
Теперь SRC должен сообщать о правильном состоянии sendmail. Если Вы используете версию 8.6.x, используете "-d0.1" вместо "-d99.100" (параметры отладки, несколько измененные в версии 8.7). В 8.6.x побочный эффект опции "-d0.1" - те несколько строк вывода отладки будут напечатаны на системной консоли каждый раз при запуске sendmail.
Для получения дополнительной информации читайте вывод System Resource Controller, команды lssrc и chssys в онлайн AIX документации.
Когда я использую sendmail IBM на IBM RS/6000, выполняющем AIX, и пробую послать почту на некоторые узлы, оказывается, что я могу послать на некоторые из них и не могу на другие. Что является неправильным?
Имеются две возможные проблемы:
1) Ваша версия sendmail не сконфигурирована так, чтобы распознавать MX записи в DNS. Просмотрите ваш sendmail.cf в поиске " OK MX " или " OK ALL ". Старые конфигурации закомментировали эту строку, и это заставит попытки послать почту от Вас к некоторым узлам терпеть неудачу (потому что те узлы имеют MX-записи, но никаких A записей в их DNS для определенного FQDN домена, к которому вы пытаетесь отправлять).
Для получения дополнительной информации, см. comp.unix.aix FAQ ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/.
2) Имеется негатив, баг кэширования в AIX 3.2.5 с /usr/sbin/named выполняемыми программами, которые являются длиной менее чем 103000 байтов. Просите, чтобы ваш IBM представитель дал Вам PMP 3251 или самую современный патч, который исправляет эту проблему для вашей специфической конфигурации и версии OS.
IBM, в их бесконечной мудрости, предусматривает заголовок файла, который легко неправильно компилируется. Как следствие, структуре {} для запросов DNS неправильно распределена, и обработка MX будет выражать недовольство.
Исправление 1) обновите к 8.7.5 - это даст исправляющий кода для этой проблемы.
Исправление 2) Устанавите BIND4.9.4 библиотеки и файлы для включения и достигают Формирования файла. AIX, чтобы использовать их - я *think* они Получают Это Право (если не, по крайней мере это умрет в течение, компилируют скорее чем неудача сверхъестественно во время выполнения).
Исправление 3) Крэкните Makefile.AIX, чтобы передать -DBIT_ZERO_ON_LEFT, чтобы вызвать заголовки для использования прав #ifdefs.
Не редактируйте sendmail.cf с помощью linuxconf. Этот инструмент и его модуль "mailconf" разработаны и основаны на очень старых правилах, пригодных еще к версии 8.8.7. Вы получите много неисправностей, если все-таки сделаете это. Сначала удостоверитесь, что RPM sendmail-cf установлен. Тогда создайте ваш собственный myhost.mc файл в /usr/lib/sendmail-cf/cf:
% cd /usr/lib/sendmail-cf/cf
% cp redhat.mc myhost.mc (Редактируйте myhost.mc)
% m4 ../m4/cf.m4 myhost.mc > myhost.cf (Проверьте этот новый myhost.cf;
как только это заведомо исправно, установите это:)
(Если 8.9.x или ранее:)
% cp myhost.cf /etc/sendmail.cf
% chown root /etc/sendmail.cf
(Если 8.10.x или позже:)
% cp myhost.cf /etc/mail/sendmail.cf
% chown root /etc/mail/sendmail.cf
См. /usr/doc/sendmail/README.cf (или только README) для изучения особенностей и подробных команд, как делать это.
Если Вы использовали модуль linuxconf "mailconf" только однажды, ваш sendmail.cf будет перезаписан при каждой перезагрузке, если будет видно, что sendmail.cf был изменен с помощью linuxconf. Решением будет удаление модуля mailconf из linuxconf. Запустите linuxconf, и идите к пункту
Control files and systems > Configure Linuxconf modulesПрокрутите до "Module path -> mailconf" и выключите кнопку "this module is active", затем щелкните "Accept" и "quit", чтобы выйти из linuxconf.
Это отключит управление linuxconf's sendmail. Сформируйте sendmail.cf из sendmail.mc снова (см. 5.3.1), и перезапустите sendmail.
RedHat изменила главный принцип работы sendmail. Они решили, что большинство людей нуждается в клиент-ориентированной версии sendmail. В итоге он слушает только интерфейс localhost. Проверьте RH документацию на предмет того, как изменить это:
Удостоверитесь, что Вы установили пакет "sendmail-cf" на вашей системе - он должен быть в вашем дистрибутиве.
Если это
так, проверьте файл "sendmail.mc" (вероятно, он находится в "/etc/mail").
Ищите строку "DAEMON_OPTIONS" и
закомментируйте эту строку.
Также известно, что RedHat 7.1 компонует sendmail с поддержкой tcpwrapper, и
таким образом файл /etc/hosts.deny отклоняет всю внешнюю почту
(точнее, все соединения с любым портом с
указанных адресов -прим.перев.). Добавление
Sendmail:ALL к /etc/hosts.allow решает
для sendmail эту проблему.
Последняя модифицикация 8 сентября, 2001
Русскоязычный перевод 11 декабря 2001
Комментарии и вопросы по этому FAQ должны направляться по адресу sendmail+faq@sendmail.org.
(Комментарии и вопросы
на русском языке направлять по адресу sendmail@aiq.ru
-прим.перев.)
Общие вопросы относительно sendmail должны
направляться по адресу sendmail-questions@sendmail.org.
Сообщения о багах (ошибках) должны направляться по
адресу sendmail-bugs@sendmail.org.
Сообщения по качеству русскоязычного перевода просьба направлять по адресу sendmail@aiq.ru
Если Вы посылаете сообщение в группу новостей comp.mail.sendmail и посылаете его одному из вышеупомянутых адресов, пожалуйста ясно указывайте это в заголовке вашего сообщения.
Оглавление
"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'"?unknown mailer
error 1"?
NOQUEUE: Null
connection from ..."?
7.БЛАГОДАРНОСТИ!
Специальные благодарности:
| Эрик Аллман | Основа здешнего материала - следствие из его FAQ для sendmail версии 8.6.9. Я бы не мог даже начать, если бы его не было. И если бы он не написал sendmail, очевидно, не было бы и этого FAQ. И не существовало бы такой мощной утилиты, как sendmail, в Internet. |
| Пауль Соутворт | Обеспечивает FAQ почтовый сервис, полезные комментарии относительно различных разделов, и mailclient-faq. Я бы не мог продолжать делать это без его помощи. |
| Ед Равин | Фактически весь материал об использовании sendmail на AIX - его, и большинство этого материала было перенесено дословно. |
| Андрей Громов | Фактически, без его усилий не появился бы читаемый Вами вариант русскоязычного перевода этого FAQ :))... а также проект "Русскоязычный Sendmail" |
Также спасибо:
Neil Hoggarth, Andras Salamon, Johan Svensson, Christopher X. Candreva, Bill Wohler, Matthew Wall, Henry W. Farkas, Claus Assmann, Curt Sampson, Rebecca Lasher, Jim Davis, David Keegel, Betty Lee, Alain Durand, Walter Schweizer, Christophe Wolfhugel, Al Gilman, Valdis Kletnieks, John Gardiner Myers, Paul DuBois, Adam Bentley, Dave Sill, Dave Wreski, Paul Caloca, Eamonn Coleman, Michael Fuhr, Betty Lee, Derrell Lipman, Era Eriksson, Richard Troxel, а также всем читателям и авторам группы новостей comp.mail.sendmail.( и всем посетителям сайта sendmail.by.ru :))
Полное содержание этого документа - copyright 1997 - 2000 by the Sendmail Consortium, все права сохранены.
Этот документ может свободно распространяться для некоммерческих целей (включая, но не ограничиваясь следующим: списки почтовой рассылки, телеконференции Usenet, WEB-страницы; включаться в CD-ROM или другие дистрибутивные средства; включаться в текстовые поисковые системы), пока это - самая последняя доступная версия в настоящее время, все части должны распространяться вместе, сохраняясь полностью неповрежденным без какого-либо редактирования, изменений, стирания, или добавлений. Некоммерческое распространение в соответствии с этими рекомендациями не требует контакта или одобрения владельца авторского права.
Распространение этого документа с целью получения прибыли без специального предварительного разрешения автора не разрешается. По крайней мере, будьте готовы обеспечить владельца авторского права произвольным количеством копий документа (естественно, поскольку это было бы продано заказчикам, все дистрибутивные права сохраняются), или процентом с валового дохода от распространения вышеуказанного документа с убедительными доказательствами, что целостность и набор требований к комплектации для некоммерческого распространения данного документа были выполнены.
Если владелец авторского права обнаружит распространяемую версию, которая не подчиняется вышеупомянутым требованиям, он приложит все усилия, чтобы исправить или удалить ее, а в случае неудачи, по крайней мере, отметит это с осуждением в своей новой версии. Судебный иск, направленный против распространения с целью получения прибыли, которое не подчиняется вышеупомянутым требованиям, вероятно, также будет принят.
Телеконференция Usenet comp.mail.sendmail выделена для обсуждения программы, называемой "sendmail" во всех ее различных формах. Она обычно находится на компьютерах, которые управляются самой лучшей операционной системой, известной как Unix, или клонами Unix.
Эта программа была перенесена и на другие операционные системы, но те версии как правило были перенесены частными продавцами и потому рассматриваются как частные. Имеется много версий sendmail, но первоначальный автор (Эрик Аллман) продолжает развивать специфическую версию, обычно известную как " Версия Восемь " или просто "V8". Это, как считается, многими является Единственной Истинной Версией. Это - также та версия, которая обсуждается в этом FAQ.
Если Вы имеете вопрос, который относится к вопросам типа "Как мне послать почту моему другу? ", вы находитесь в неверной телеконференции. Вы должны сначала свериться с вашим системным или почтовым администратором, администратором BBS и т.д ... прежде чем вынести ваш вопрос на всеобщее обсуждение, так как ответ, вероятно, будет очень сильно зависеть от того, какое программное обеспечение и оборудование Вы имеете. Вы также не хотите публично объявить себя некомпетентным, и при этом Вы не хотите раздражить вид людей, которые, вероятно, могут оказаться коллегами вашего системного или почтового администратора, администратора BBS и т.д ...., если же выяснение этих вопросов не дает какой-либо прок Вам, удостоверьтесь, что Вы читаете этот FAQ и другие, относящиеся к почте FAQ на архивных сайтах, перечисленных ниже.
Если у Вас есть вопрос относительно другой программы, подобной sendmail (технически упомянутый как "SMTP MTA"), пакета шлюзов SMTP, или пакета клиентов электронной почты ЛВС (IMAP, POP3, Outlook Express и т.п.- прим.переводчика), то Вы должны посмотреть, имеется ли другая группа в comp.mail иерархии, которая наиболее близко соответствует специфической программе, относительно которой Вы хотите задать вопрос. Например, SMTP MTA известный как Smail имеет конференцию comp.mail.smail, специально выделенную для этого. Клиент электронной почты (MUA) Eudora имеет две телеконференции, выделенные для него (comp.mail.eudora.mac и comp.mail.eudora.ms-windows), в зависимости от базовой платформы вашего компьютера, которую Вы используете. Если больше не имеется подходящей телеконференции, попытайте счастья на comp.mail.misc. Опять же, удостовертесь, что ваш вопрос уже не обращен в один из связанных с почтой FAQ или к другой доступной документации. См. страницу IMC (более подробно об этом см.ниже) для обзора хорошего списка связанных с почтой FAQ.
Если Вы имеете вопрос относительно старшей или продаваемой частным образом версии sendmail, будьте готовы к большому количеству ответов типа "Воспользуйтесь V8 ". Версия 8 не панацея, но она решает много проблем, которые были настоящим бедствием в предыдущих версиях, также она имеет много новых особенностей, которые делают ее намного проще для администрирования больших или комплексных узлов. Во многих случаях, по крайней мере, она делает возможным то, что до этого было фактически невозможно, и относительно облегчает то, что ранее было трудно.
Имеются, конечно, много альтернативных программ, которые попытались вырваться вперед в попытке среагировать на ту или иную слабость или исправить отдельные неисправности sendmail, но пока что ни одна из них не имела того успеха, который мог бы потребовать лишить sendmail статуса фактически стандартной программы для пересылки почты в Internet. Очевидно, этот форум не должен использоваться, чтобы обсудить достоинства любой из альтернативных программ в ущерб sendmail. Эти виды обсуждений можно взять в comp.mail.misc, или же Вы должны агитировать за то, чтобы получить новую телеконференцию или целую иерархию телеконференций, где подобная агитация приемлема (или даже норма, типа comp.mail.advocacy или news:comp.mail.mta.advocacy телеконференций).
Этот FAQ строго сконцентрирован вокруг версии 8 sendmail, по многим причинам. Прежде всего, это - область наибольших интересов той части людей, которая поддерживает этот FAQ. Во-вторых, версия 8 - то, где сконцентрировано большинство нововведений. Версия 8 sendmail также лучше всего документирована из всех SMTP MTA's, на основании книги Брайена Косталеса (см. вступление sendmail-faq // book/ISBN/1-56592-222-0 в Q6.1).
Другие версии sendmail упоминаются по ходу, также освещены некоторые интересные взаимодействия между версией 8 и различными операционными системами .
Этот FAQ предназначен прежде всего для опытного Unix-администратора/почтового администратора/ администратора DNS. Если вы ищете вводные тексты, см. ссылки в Q6.1 (не стоит пугаться, как еще стать опытным, если не узнавать ничего нового :))- прим.перев.).
Мы посылаем изменения по мере их поступления на страницу поддержки sendmail FAQ в http://www.sendmail.org/faq/.
(последнюю русскоязычную версию перевода а также русского FAQ можно найти на этом сайте - прим. перев. )
Пошлите электронную почту по адресу mxt@dl.ac.uk с командой "sub comp-news.comp.mail.sendmail full-US-ordered-email-address" в теле сообщения (с вашим правильным адресом на месте "Full-US-ordered-email-address", и с опущенными двойными кавычками во всех случаях этого примера).
Электронная почта, которую Вы хотите зарегистрировать на comp.mail.sendmail, должна быть послана по адресу comp-mail-sendmail@dl.ac.uk
В зависимости от того, насколько глубоко они касаются DNS, их можно задать здесь. Однако, вероятно, вам будут правильнее сказать, что Вы должны послать их в телеконференции Usenet comp.protocols.tcp-ip.domains (DNS вообще) или к списку почтовой рассылки информации по DNS Info-BIND (если вопрос специфический для этой программы).
Для comp.protocols.tcp-ip.domains, Вы должны находиться в Usenet. Они все еще не имеют шлюза типа "news-to-mail" (я работаю над этим), но они имеют FAQ.
Вопросы всех уровней сложности могут быть найдены на этой телеконференции (также как и люди, которые ответят на них), так что не будьте застенчивы, задаваня вопросы, которые, как Вы думаете, могут показаться слишком простыми.
Некоторая подробная информация о BIND 8.1 в
src/README file:
| URL | Цель |
|---|---|
| ftp.isc.org/isc/bind/src/cur | Текущий выпуск non-test |
| ftp.isc.org/isc/bind/src/testing | Последний общедоступный испытательный набор |
|
|
|
| Comp.protocols.dns.bind | Использование BIND |
| Comp.protocols.dns.ops | Действия DNS вообще |
| Comp.protocols.dns.std | Стандарты DNS вообще |
|
|
|
| bind-users-request@vix.com | Gw'd to c.p.d.bind |
| namedroppers-request@internic.net | Gw'd to c.p.d.std |
| bind-workers-request@vix.com | code warriors only please |
|
|
|
| www.isc.org/bind.html | домашняя страница BIND |
| bind-bugs@isc.org | Сообщения об ошибках |
Если вы вообще заинтересованы в защите ваших машин, Вы должны удостовериться, что вы по крайней мере используете недавний выпуск версии 8 sendmail (или полученной от вашего продавца или общедоступной версии, подробнее в Q2.8).
Просмотрите сертификат предупреждений ( CERT Alerts на официальном сайте sendmail - прим. переводчика ) и резюме, чтобы удостовериться, что вы используете версию, которая избавлена от известных дыр в безопасности. Однако тот факт, что sendmail программа, разработанная и поставленная вашим продавцом там не перечислена, еще не означает, что вы не уязвимы . Если ваш частный продавец или версия не перечислены, сверьтесь и с вашим продавцом, и в соответствующих списках почтовых рассылок Internet, и в телеконференциях Usenet, чтобы проверить это.
Вообще говоря, самая новая public версия обычно довольно хорошая вещь, хотя Вы должны просмотреть comp.mail.sendmail, чтобы увидеть, не регистрировал ли кто-либо недавние комментарии, которые не все были учтены в новом выпуске.
Как говорится, Вы должны учитывать то, для чего в первую очередь предназначена Ваша машина. Если она предназначена для выполнения некоторого пакета CAD/CAM на инженерном стенде, то вероятно, будет не много смысла в замене поставленной продавцом версии sendmail (предполагая, что она безопасна, согласно CERT Alert и резюме).Просто настройте машину для передачи всей исходящей почты на центральный почтовый сервер, и затем беспокойтесь как настроить центральный почтовый сервер наилучшим образом. По тем же причинам настройте, чтобы всю прибывающую почту пропускал центральный почтовый распределитель (вероятно, та же самая машина, что и центральный почтовый сервер)..
Если же Ваша машина и должна быть этим самым центральным почтовым сервером /распределителем, то мы строго рекомендуем установить лучшую версию sendmail, какую только Вы можете достать, и каковой, по нашему мнению, является самый последний выпуск версии 8. IDA sendmail тоже довольно хороша, но фактически все, что она делает, версия 8 делает лучше, и версия 8 имеет дополнительное преимущество в том, что также продолжается развиваться .
Если борьба со спамом для Вас важна, то во что бы то ни стало модернизируйте Вашу версию до версии 8.10. X. Версия 8.9. X имеет хорошие свойства анти-спама, но 8.10. X имеет больше свойств, и анти-спамовые настройки более гибкие, чем те, которые есть в версии 8.9. X.
Однако, имейте в виду, что версия 8 все еще не была перенесена (насколько мы знаем) на некоторые старые и, возможно, другие экзотические или секретные платформы, и если вы застряли, используя одну из них, у Вас будет небогатый выбор.
Некоторые продавцы начали поставлять (или объявили, что скоро поставят) версию 8 sendmail предустановленую на их машины. К сожалению, в большинстве случаев это означает, что Вы получаете откомпилированный бинарный файл и файл конфигурации sendmail.cf (который может нуждаться в небольшой доработке), что совсем небольшая часть от стандартного инсталляционного комплекта версии 8 sendmail. SGI и Hewlett-Packard, как известно, уже поставляют версию 8 sendmail таким образом.
Sun
Microsystems делали тот же самое с SunOS 5.5, 5.5.1 и 5.6,
поставляя версию, основанную на 8.6 с их собственным частным
файлом конфигурации. Тем не менее, недавние заплаты для 5.5.1 и 5.6,
являющиеся обновлением к версии, основанной на 8.8.8 только слегка
похожи на sendmail.cf. Более важно, что cf иерархия доступна под /usr/lib/mail/.
Более подробно доступно на Sun
migration page..
Для версии 8 sendmail, имеются четыре дерева выпусков.
Для тех людей, кто по какой-либо причине не может или не хочет модернизировать к версии 8.12.x, выпуски версий 8.11, 8.10 и 8.9 sendmail все еще доступны, но уже не обновляются. Последний выпуск версии 8.9 sendmail был 8.9.3; последний выпуск 8.10 был 8.10.2; последний выпуск 8.11 был 8.11.6.
Версия 8.12.0 была выпущена 8 сентября, 2001.
Версия 8.11.6 была выпущена 20 августа, 2001.
Версия 8.11.5 была выпущена 31 июля, 2001.
Версия 8.11.4 была выпущена 28 мая, 2001.
Версия 8.11.3 была выпущена 27 февраля, 2001.
Версия 8.11.2 была выпущена 29 декабря, 2000.
Версия 8.11.1 была выпущена 28 сентября, 2000.
Версия 8.11.0 была выпущена 19 июля, 2000.
Версия 8.10.2 была выпущена 7 июня, 2000.
Версия 8.10.1 была выпущена 7 апреля, 2000.
Версия 8.10.0 была выпущена 7 марта, 2000.
Версия 8.9.3 была выпущена 4 февраля, 1999.
Версия 8.9.2 была выпущена 31 декабря, 1998.
Версия 8.9.1 была выпущена 2 июля, 1998.
Версия 8.9.0 была выпущена 20 мая, 1998.
На машинах, включенных непосредственно в Internet, Вы должны или уже запускать sendmail 8.12.0 или планировать модернизацию в ближайшем будущем. Версия 8.12.0 рассматривается как устойчивая, включает настройки, которых не было в любом предыдущем выпуске, и поэтому превосходит все предыдущие выпуски.
В дальнейшем здесь не имеется никакой поддержки или упоминания предыдущих выпусков sendmail.
На анонимном FTP ftp.sendmail.org в /pub/sendmail, или (в форме URL) ftp://ftp.sendmail.org/pub/sendmail/. Если Вы требовательны к безопасности, должны быть файлы в этом каталоге, которые заканчиваются расширением ".sig",и которые Вы можете проверить с помощью PGP, чтобы удостовериться, что соответствующий архив не изменился. Вам необходимо иметь PGP ключ от Sendmail.ORG для вашего общего шифра, чтобы быть способными проверить этот архив с их связанным .sig файлом.
Не имеется никакого другого известного официального зеркала версии 8 sendmail .
Просматривайте sendmail домашнюю страницу в http://www.sendmail.org/ для получения последних серьезных обновлений и другой полезной информации.
Если Вы хотите получать сообщения относительно будущих обновлений sendmail и других потенциально интересных вещах, Вы можете подписаться на список почтовой рассылки sendmail. Пошлите ваш подписной запрос на "majordomo@lists.sendmail.org" с указанием "subscribe sendmail-announce" в теле сообщения.
См. doc/changes/changes. {мои, прим.автора} в условиях распространения. См. также RELEASE_NOTES на уровень выше.
Вообще говоря,, я твердо придерживаюсь старой аксиомы, что сначала Вы должны выбрать, какое программное обеспечение Вы хотите использовать, а только затем выбирать платформу (аппаратные средства и OS) для наилучшего выполнения этого программного обеспечения. Согласно этому , если sendmail - программное обеспечение, то последняя версия BSD Unix была бы, вероятно, лучшим вариантом, с тех пор как sendmail была разработана в UC Berkeley на BSD Unix. FreeBSD и BSD/OS - две известных реализации BSD Unix для основанного на Intel-платформе персонального компьютера (среди других базовых аппаратных платформ ), и это сделало бы ее более "родной" операционной системой для sendmail. FreeBSD свободно доступна на анонимных ftp или на CD-ROM, что касается BSD/OS, то это - коммерческий продукт.
Однако, не каждый имеет такую "роскошь". Если вы находитесь на гомогенной сети (т. е. полностью составленный из только одного типа аппаратных средств и OS), то Вы должны, вероятно, использовать ту же OS, какая установлена и на остальных машинах сети, независимо от аксиомы, заявленной выше. Вы можете иметь и другие проблемы, но Вы должны, по крайней мере, быть способны получить некоторую непосредственную поддержку на OS для вашей машины.
В любом случае, если главное назначение машины - обрабатывать "большие" объемы почты (для любого значения, как правило, Вы говорите "большое", просто "чтобы было"), я строго рекомендую получить самый последний устойчивый выпуск версии 8 sendmail.
Вы можете с удивлением найти, что для Вас проще поддерживать только одну версию sendmail для всех различных платформ чем попробовать поддержать различные уникальные для каждой платформы версии. В этом случае, самым простым решением будет установить версию 8 sendmail всюду, и не волноваться относительно частно-специальных проблем со старыми версиями.
Для получения дополнительной информации о BSD Unix вообще, см. телеконференции Usenet comp.unix.bsd, comp.bugs.4bsd, comp.os.386bsd. Для получения дополнительной информации о BSD/OS, см. BSD телеконференции, упомянутые выше, или BSD/OS home page в http://www.bsdi.com/. Для получения дополнительной информации на FreeBSD, см. телеконференции Usenet под news:comp.unix.bsd.freebsd, или FreeBSD home page в http://www.freebsd.org/.
Для получения дополнительной информации о Linux см. этот сайт (прим. переводчика)
BIND является сокращением от "Berkeley Internet Name Daemon", и является фактически стандартной Internet-программой для разрешения имен хостов в IP-адреса.
Домашняя страница BIND - http://www.isc.org/bind.html, которая содержит ссылки на самый последний выпуск BIND . Первый серийный вариант BIND -8 был выпущен в мае 1997.ISC довольно резко выступила против каких либо заплат BIND-4, связанных с защитой. Поэтому никакие новые особенности или изменения для совместимости не будут добавлены в BIND-4. Вы должны использовать BIND-8.
Говорят, что имеются баги в более ранних библиотеках резольвера (resolver), которые могут вызывать проблемы у больших узлов (которые насчитывают более пяти IP-адресов для данного имени), или представлять большую дыру в безопасности, поскольку они не проверяют возвращаемые данные, чтобы увидеть, умещаются ли они в предварительно выделенном для них месте.
Если все будет возможно, Вы должны получить самую современную версию "выпуска" BIND и сделать серьезную попытку интегрировать ее в вашу конфигурацию, поскольку с тех пор фактически все произведенные частным порядком библиотеки резольвера безнадежно устарели.
Говорят, что
поскольку вышла BIND версии 8.1, много людей,
устанавливающих sendmail, испытало проблемы
при компилировании и соединении с новым BIND,
хранящем свои файлы и библиотеки в /usr/local/. Раздел в
нашей Compiling Sendmail странице объясняет это.
Smrsh - связанная с оболочкой утилита , которая обеспечивает способность определить сквозь конфигурацию, явный список выполняемых программ. Когда smrsh используется вместе с sendmail, она эффективно ограничивает возможности выполнения sendmail только теми программам, которые указаны в конфигурации smrsh's.
Smrsh был написан с мобильностью в памяти и использует традиционные библиотечные утилиты Unix. Как правило, smrsh должен компилироваться на большинстве Unix C компиляторах.
Цель составления ограниченного списка программ, которые могут быть выполнены таким способом, состоит в том, чтобы сохранить почтовые сообщения (или через псевдоним или .напрямую файлом в домашнем каталоге пользователя) и не посылать их произвольным программам, которые, как известно, являются достаточно параноидальными в проверке такого ввода, и могут довольно легко их разрушить (это связано, но, вообще говоря, отличается от особенностей /etc/shells, обсуждаемых в Q3.11).
Подробная информация относительно CERT-CC может быть найдена на их информационном узле, http://www.cert.org. Для получения дополнительной информации о CERT Alerts и CERT Summaries, см.их консультации и резюме, соответственно.
Вы можете найти smrsh в самом споследнем sendmail в виде архива исходников. Другие очень полезные программы могут быть найдены в http://www.cert.org/other_sources/tool_sources.html.
Smap (и smapd) - инструментальные средства, выпущенные Trusted Information Systems (TIS) Firewall Toolkit (fwtk). Они были первоначально написаны экспертом межсетевой защиты Маркусом Ранумом по контракту с TIS , и TIS продолжает их техническое обслуживание при необходимости. Есть ссылка к инструментарию. Вопросы относительно поддержки инструментария можно посылать fwall-support@tis.com, в то же время Вы можете присоединиться с их списком почтовой рассылки fwall-users@tis.com, послав электронную почту к fwall-users-request@tis.com.
Концепция smap и smapd такова, что sendmail является огромной, монолитной программой, выполняемой setuid root, которую фактически невозможно проверить на предмет "правильности выполнения" и отсутствия багов (исторически сложилось, что sendmail был довольно ошибочен, что легко отмечалось и потом использовалось хакерами, но теперь с появлением версии 8 sendmail это становится намного труднее. С другой стороны, smap и smapd очень маленькие (всего несколько сотен строк кода), и относительно облегчают проверку правильного функционирования, как и положено (однако, как Вы увидите позже, мы можем подвергать сомнению их разработку). Поэтому, согласно теории, это более безопасно, и "лучше" выполнять smap и smapd как "обертку" вокруг sendmail, которая больше не нуждалась бы в необходимости быть выполняемой setuid root.
К сожалению, smap и smapd имеют несколько своих собственных проблем, и кажется, не будут модифицированный с тех пор с конца марта 1996. Тогда нашлись противоречивые сообщения о несовместимости между smapd и sendmail 8.7.y (оба одновременно не могут выполняться на одной машине, хотя, если вы выполняете sendmail 8.6.x и smap/smapd на локальной машине, люди во внешнем мире могут все еще использовать sendmail 8.7.y, чтобы общаться с Вами).
Для дальнейшей информации относительно smap и smapd, см. документацию, поставляемую с TIS Firewall Toolkit
Для получения дополнительной информации о файрволлах (межсетевых экранах) см. Firewalls FAQ в http://www.interhack.net/pubs/fwfaq/
TCP-Wrappers- другой пакет расширений безопасности. Теория следующая: Вы берете программы, выполняемые под inetd (см. /etc/inetd.conf) и прежде, чем Вы запустите программу, чтобы делать реальную работу (ftpd, telnetd, и т.д ...), Вы сначала выполняете попытку подключения через пакет, который выясняет, является ли IP-адрес исходного пакета исходящим из хоста, известного, как хороший, или плохой (Вы можете фильтровать попытки подключения по исходному именем хоста, имени домена, необработанному IP-адресу, порту, с которым они пытаются соединиться; и ,или разрешить проход заведомо хорошему соединению через себя или сбросить неизвестное соединение, или же принимать все соединения кроме тех, которые известны как заведомо плохие).
Практика TCP-Wrappers фактически следует за теорией весьма хорошо. Это - очень полезный и важный инструмент в наборе инструментов системного администратора, призванных помочь вам защитить Вашу машину от крэкеров, спаммеров, почтовых мусорщиков, и всякого сброда. Однако, он работает только для программ, которые связываются через пакеты TCP (а не UDP, такие как NFS, например) запущенные из inetd. Это не работает для RPC-основанных сервисов, и программ, которые запускают демона вне inetd и сразу завершают работу, не извлекая выгоды от подключения, которое обеспечивает исходный демон (однако, см. FTP URL ниже для других пакетов, которые могут помочь защитить RPC и portmapper-основанные услуги).
Однако, большинство инсталляций sendmail имеет тенденцию запускать демона и оставлять его выполняющимся постоянно. Если бы Вызапускали sendmail из inetd, вы теряли бы преимущества от загрузки промежуточной проверки кода, которая выполняется только в daemon режиме, для систем, которые обрабатывают много почты, это жизненно важно.
Вы можете получить TCP-Wrappers с ftp://ftp.porcupine.org/pub/security/, узла, который имеет целый комплект других полезных инструментальных средств защиты, типа securelib, portmap, satan, cops, crack, и т.д ... Вы можете также найти ссылки на многие другие полезные инструментальные средства защиты в http://ciac.llnl.gov/ciac/SecurityTools.html, и COAST архиве в http://www.cerias.purdue.edu/coast/ - истинном роге изобилия всех связанных с защитой вещей.
Для предприимчивых, Вы можете получить исходную заплату для версии 8 sendmail (созданная для 8.7.6, но в работе, используещей старшие выпуски) который возьмет ядро TCP-Wrappers кода и интегрирует его в демона так, что Вы получите лучшее из обоих миров. Однако, это не так гладко интегрировано, как это должно было быть, это не для "боязливых ", и, конечно, официально не поддержано первоначальным автором sendmail (Эриком Аллманом). Эти функциональные возможности интегрированы другим способом в версию 8.8.5 sendmail.
Вы можете найти неподдерживаемую заплату в ftp://ftp.porcupine.org/pub/security/sendmail-tcpd.patch.
В релизе выпуска 8.9. X sendmail сообщается, что в db 1.85 больше нет необходимости, поскольку поддержка для db 2. X включена (начиная с 2.3.16). Более подробно см. в Q3.25. Остальная часть этого ответа полезна только если Вы еще не модернизировали к 8.9. X.
Db 1.85 пакет как доступный от http://www.sleepycat.com/register.html обеспечивает поддержку Irix до Irix 4.05F, но 5. {2,3} нуждаются в слегка исправленной версии, так что делает HP-UX 10.20. Некоторые продавцы также обеспечивают db стандарт их OS (DEC Unix 4.0, например).
Архивl, включающий эти изменения к Irix 5.x доступен в ftp://ftp.his.com/pub/brad/sendmail/irix5.tar.gz. Это извлекакется в ./db.1.85/PORT/irix.5.2, с символической ссылкой, созданной от ./db.1.85/PORT/irix.5.3 в тот тот же самый каталог. Удостоверитесь, что Вы извлекаете этот архив в тот же самый каталог, куда Вы извлекли db 1.85 архив, доступный на ftp.cs.berkeley.edu. (См. Q3.5 для получения дополнительной информации при получении db пакета 1.85 ). Контекст ASCII, различный с этой же самой заплатой - в ftp://ftp.his.com/pub/brad/sendmail/irix4-5.diff.
Версия db 1.85, которая, возможно, была исправлена, чтобы компилироваться под Irix 6.2, была сделана доступной в http://reality.sgi.com/ariel/freeware/#db, но я не имел шанса, чтобы все же загрузить и проверить это .
Контекст diffs требуемый, чтобы получить db 1.85, работающий под HP-UX 10.20 доступен в ftp://ftp.his.com/pub/brad/sendmail/hpux.10.20.diff. Архив, включающий эти изменения доступен в ftp://ftp.his.com/pub/brad/sendmail/hp-ux.10.20.tar.gz. Он извлекается в ./db.1.85/PORT/hpux.10.20, так что удостоверитесь, что Вы извлекаете этот архив в тот же самый каталог, куда Вы извлекли db 1.85 архив, который доступен на ftp.cs.berkeley.edu.
Программа "makemap" используется, чтобы формировать базы данных, используемые версией 8 sendmail, для вещей подобных UserDB, mailertables, и т.д ....
Это распространяется как часть основной операционной системы от некоторых продавцов, но исходный текст для него также включен на корневом уровне архива sendmail (по крайней мере, это справедливо для sendmail 8.6.12 и 8.7.5, и возможно, будет продолжено , поскольку выйдут более новые выпуски ). Однако, это не рассматривается "поддержанной" частью версии 8 sendmail. Точно так же как другой исходник, обеспеченный в архиве, Makefile, вероятно, будет нуждаться в некоторых поправках для вашего конкретного узла.
Говорят, что Irix 5.3, кажется, не имеет dbm или ndbm библиотеки, но компилирует makemap.c, Вы должны иметь DNDBM на строке "DBMDEF =" (некоторые необходимые вещи определены только в /usr/include/ndbm.h). Попытайтесь оставить только "-lndbm" от строки " LIBS = " в Makefile для makemap.
Если Вы планируете использовать makemap с db 1.85 на SGI машине, использующей версию Irix позже чем 4.x, см. Q2.16 для некоторых дополнительных шагов по получению и компилированию db 1.85 на вашей машине.