3. СПЕЦИФИЧЕСКИЕ ПРОБЛЕМЫ ВЕРСИИ 8 SENDMAIL

Q3.1 - Как я могу заставить все мои адреса  казаться исходящими из одного хоста?

На этот вопрос отвечают подробно  на странице конфигурации Masquerading and Relaying

Q3.2 - Как мне перезаписать мое поле From:чтобы строка читалась ``First_Last@My.Domain''' или ``Different_Name@My.Domain''?

Дата: 23 сентября, 1997
Модифицирован: 8 ноября, 1999

Используйте generics таблицу, как описано в шагах 6 и 7 на  странице  Virtual Hosting.

Q3.3 - А что относительно полностью-квалифицированных адресов, типа тех что от Pine или FEATURE(always_add_domain)?

Дата: 19 июля, 1996
Модифицирован: 8 ноября, 1999
Модифицирован: 25 января, 2000

Этот вопрос обычно звучал так " Как я могу заставить пользовательскую базу данных  работать с Pine  или с FEATURE(always_add_domain)? ".  Но пользовательская база данных - больше не рекомендуемое  решение для этой проблемы, таким образом этот  вопрос, соответственно, был решен.

Надлежащим решением является использование generics таблицы, как описано ступенчато 6 и 7 на  странице Virtual Hosting. Важное  замечание состоит в том, что часть host/domain полностью-квалифицированного доменного имени (FQDN)  должна быть определена через GENERICS_DOMAIN() или GENERICS_DOMAIN_FILE().

Q3.4 - Тогда для чего же была предназначена user database feature ?

Дата: 12 мая, 1997

Намерение состояло в том, чтобы иметь всю информацию о  конкретном пользователе (где под именем пользователя имеется ввиду  уникальное имя входа в систему (логин), а не имя и фамилия, которые, вообще говоря, не являются уникальными) в одном месте. Это решение должно было включать телефонные номера, адреса, и т.д. Особенность "maildrop"(что-то типа "почтовое преимущество"- прим.перев.) в  том,  что Berkeley не использует централизованный сервер почты (имеется ряд причин для этого, которые являются главным образом историческими), поэтому мы должны знать, где каждый пользователь получает его или ее доставленную почту, т.е. где находится его почтовая очередь.

UC Berkeley - находится (находился) в процессе установке своего окружения, таким образом, почта посланная просто на неквалифицированное имя "name", идет к этому человеку преимущественно через maildrop; почта посланная на "name@host" идет на тот хост. Цель "FEATURE(notsticky)" - заставить и для адреса вида "name@host" искать в базе данных пользователя для дальнейшей доставки к maildrop.

Q3.5 - Почему такая неприязнь относительно использования имен и фамилий для адресов электронной почты?

Дата: 12 мая, 1997

Поскольку имена и фамилия не уникальны. Например, компьютерное сообщество знает имеет двух  Peter Deutsches. В одно время Bell Labs имели двух Stephen R. Bournes с кабинетами, располагающимися через несколько дверей. Вы можете создавать альтернативные адреса (например, Stephen_R_Bourne_2), но это вдвойне хуже - который из них должен осквернять свое имя  таким образом? И Вы можете держать пари, что один из них получит большинство электронной почты другого.

Так называемые "имена и фамилия" - только попытка создать более длинные версии уникальных названий. Это довольно сильно убаюкивает людей в ощущение защиты, Я предпочел бы, что  было бы чище, если бы эти ники были бы произвольны. Люди должны использовать хорошх почтовые клиентов, которые имеют отображения алиасов  так, чтобы люди могли прикреплять произвольные названия для своего персонального использования  с теми, с кем  они переписываются (таких как файл алиасов MH).

Проблема вдвойне  хуже вне Америки, где не - ASCII символы (например, символы с умлаутами или Норвежским Ш) используются в именах. С тех пор как не - ASCII символы не могут использоваться в конверте SMTP или заголовках электронной почты, имена и фамилия все равно будут искарежены, так или иначе.

Даже хуже - нечеткое соответствие в электронной почте может сделать хороший адрес плохим. Например, Эрик Аллман в настоящее время (как мы знаем, к лучшему) единственный  "Allman" в Berkeley, так что почта, посланная <Allman@Berkeley.EDU> должна приниматься для него. Но если бы другой Allman когда-либо появился, этот адрес мог бы внезапно стать неоднозначным. Он был единственным Allman в Berkeley в течение более чем пятнадцати лет, чтобы внезапно заиметь на этот " хороший адрес " срыв почты, только потому что это неоднозначно. Это было бы отвратительно и неправильно.

Сервисы директорий должны быть настолько нечетки насколько возможно (в пределах здравого смысла, конечно). Почтовые сервисы должны быть уникальны.

Q3.6 - был негативно оценен.

Q3.7 - Как я могу управлять несколькими (виртуальными) доменами?

На этот вопрос отвечают подробно на странице Virtual Hosting.

Q3.8 - имеются четыре UUCP мэйлера, перечисленные в конфигурационном файле. Который из них я должен использовать?

На этот вопрос отвечают с подробностями  конфигурирования на странице Using UUCP Mailers 

Q3.9 - Как я могу установить сообщения "undefined symbol inet_aton" и "undefined symbol _strerror" ?

Этот вопрос детально разобран  в пределах страницы Compiling Sendmail.

Q3.10 - Как я могу решить ошибки "collect: I/O error on connection" или "reply: read error from host.name"?

Дата: 8 апреля, 1997
Модифицирован: 9 мая, 2000

Если Вы получаете такие сообщения  иногда и случайно, они, вероятно, из-за временной сетевой проблемы, или отдаленной аварии хоста или же резкого завершение подключения. Если Вы получаете их много  от одного конкретного хоста, имеется, вероятно, некоторая несовместимость между 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 для подробностей.

Q3.11 - Почему мои пользователи не могут передавать их собственную почту программе?

Дата: 9 июля, 1996
Модифицирован: 19 ноября, 1999

Я только что обновил к версии 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.

Q3.12 - Почему соединения на порт SMTP забирают так много времени?

Дата: 24 ноября, 1996
Модифицирован: 29 августа, 2001

Я только что обновил к версии 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 для вашего частного адресного пространства-прим.перев.).

Q3.13 - Почему, я получаю ошибку "unknown mailer error 5 -- mail: options MUST PRECEDE recipients"?

Дата: март 23, 1996

Я только что обновил  к версии 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.

Q3.14 - Почему  версия 8 sendmail делает панику в моем SunOS почтовом ящике?

Дата: март 24, 1996
Модифицирован: 4 ноября, 1997

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).

Q3.15 - Почему Unix строка From оказывается загадочым образом испорчена когда я посылаю на алиас?

Дата: 3 декабря, 1997

``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".

Q3.16 - Почему MASQUERADE_AS (или the user database)  не работают для адресов конверта так же, как для адресов заголовка?

Дата: 24 ноября, 1996

Верьте этому или нет, но это сделано намеренно. Интерпретация стандартов версией 8 sendmail группой разработчиков была таковой, что это была бы неуместная перезапись, и  если бы перезапись заголовка оказалась некорректной, по крайней мере конверт содержал бы правильный обратный адрес.

Если вы используете версию 8.7.y sendmail (или более позднюю), Вы можете использовать FEATURE(masquerade_envelope) В вашем sendmail.mc файле, чтобы изменить это поведение. Это обсуждено в больших деталях на странице конфигурации  Masquerading and Relaying.

Q3.17 - Как я могу использовать версию 8 sendmail и поддерживать   протокол MAIL11V3?

Дата: март 23, 1996

Получите нововведение  протокола mail11  Китом Муром с ftp://gatekeeper.dec.com/pub/DEC/gwtools/ (с дополнениями от Пола Викси).

Q3.18 - Почему сообщения исчезают из моей почтовой очереди непосланными?

Дата: март 23, 1996

Когда я смотрю в директорию  очереди, я  вижу, что qf* файл был переименован к Qf *, и sendmail не видит его. Что является неправильным?

Если Вы посмотрите  поближе, Вы найдете, что Qf файл принадлежит пользователям, отличным  от root. С тех пор как sendmail выполняется как root, он отказывается доверять  в не принадлежащих root директориях qf-файлам, потому переименовывает их в Qf, выбрасывает из очереди и облегчает для Вас их поиск. Обычно, причина этого двояка: во-первых, Вы имеете  каталог очереди перезаписываемым для всего мира (что является, вероятно, ошибкой - это открывает другие проблемы безопасности), во-вторых,  кто - то вызывает sendmail с " опасным " флагом, обычно флагом -o, который устанавливает опцию, которая может ставить под угрозу защиту. Когда sendmail видит это, он активизирует разрешения setuid root.

Обычное решение- не использовать проблематичные флаги. Если Вы должны использовать их, Вы должны создать специальный каталог очереди и обрабатывать его тем же самым uid'ом, который выполнял работу в первом случае.

Q3.19 - Когда  sendmail начнет поддерживать RFC 2047 кодирование заголовка MIME?

Дата: март 23, 1996
Модифицирован: 5 сентября, 1999

Это  рассматривается скорее как проблема MUA,  чем проблема MTA.

Рассказывает Эрик Аллман:

Во-первых,  информация о необходимости выполнения кодирования (то есть 8- > 7 бит) является неизвестной для  MTA. В особенности, набор символов, использующийся для кодирования названия в заголовках  НЕ обязательно тот же самый, какой используется для кодирования тела (которое уже закодировано в MIME в параметре набора символов Content-Type: header). Кроме того, это совершенно разумно для, скажем, шведа,  живущего и работающего в Корее, или русского, живущего и работающего в  Германии, и желающих, чтобы их имена были закодированы в их родном наборе символов; может быть даже то, что отправитель японец, получатель русский, и тело закодировано в ISO 8859-1. Если все, что я имею - 8-разрядные символы, я не могу выбирать набор символов должным образом.

Точно так же при выполнении 7- > 8 битного преобразования  я не хочу отбрасывать эту информацию, поскольку она необходима для правильного представления конечному пользователю.

Q3.20 - Почему я не могу послать почту в некоторые места, но вместо этого всегда получаю ошибку "reply: read error from name.of.remote.host"?

Дата: 17 января, 1997

Это обычно вызывается багом в сервере почты отдаленного хоста, или 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, если, конечно, Вы хотите такую особенность.

Q3.21 - Почему не работает "FEATURE(xxx)"?

Дата: 17 января, 1996

При создании m4 Master Config (".mc") файла  для версии 8 sendmail, много макрокоманд FEATURE() просто заменяют определение внутренних переменных, которые вызываются в определениях MAILER(). 

Чтобы удостовериться, что все работает как хочется, Вы должны проверить, что макрокоманды OSTYPE ()  помещены в самое начало файла, затем идут макрокоманды FEATURE() и HACK(),затем локальные определения, и в самом конце определения MAILER(). См. конфигурационную страницу Introduction and Example для более подробного объяснения.

Q3.22 - Как мне  сконфигурировать sendmail, чтобы не использовать DNS?

Дата: март 24, 1997
Модифицирован: 6 апреля, 2000

В случаях, когда Вы находитесь позади 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
 (или любом аналогичном). 


  
 
 Q3.23 - Как мне получить всю мою почтовую очередь,
 доставленную в мой Unix-почтовый ящик, от моего
 провайдера?
 
Дата: 6 июня, 1997 

 Модифицирован: 8 октября, 1998

 В 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,
 чтобы выяснить точную версию этого. 


  
 
 Q3.24 - Почему я получаю сообщение об
 ошибке "unable to write /etc/mail/sendmail.pid"
 на Solaris 2.x ?
 
Дата: 6 августа, 1997

 Sendmail проверяет имеется ли  доступ на
 запись в директорию, в которой требуется создать файл без
 использования специальных привилегий 'root'. Чтобы
 sendmail работал надлежащым образом,
 директориии /etc, /etc/mail, и/или /var/run должны принадлежать
 root и быть перезаписываемыми своим владельцем. 


  
 
 Q3.25 - Почему я  не могу компилировать sendmail с Berkeley DB 2. X?
 
Дата: 12 августа, 1997 

 Модифицирован: 20 мая, 1998 


 Sendmail 8.8 поддерживает только Berkeley DB 1.85. Это не будет работать с более новыми
 версиями Berkeley DB , даже в режиме совместимости
Однако,
 Sendmail 8.9 включает поддержку для Berkeley DB 2. X,
 начиная с версии 2.3.16. 


  

 Q3.26 - На какие операционные системы
перенесен Berkeley sendmail ?
 
Дата: 18 декабря, 1997 

 Модифицирован: 9 сентября, 1999 


 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. 


  
 
 Q3.27 - Как мне предотвратить  ошибки Relaying
 Denied  для моих клиентов?
 
Дата: 12 апреля, 1998 

 Последняя модификация: 19 июня, 2000

 Вы должны добавить полностью-квалифицированное имя хоста и-или АДРЕС 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. 


  
 
 Q3.28 - Почему virtual hosting не работает даже после того, как я
 добавляю строку Kvirtuser к sendmail.cf?
 
Дата: 12 апреля, 1998
Одно только добавление
 соответствующей строки Kvirtuser к sendmail.cf не
 достаточно, чтобы активизировать свойство
 virtual user table, ключевой компонент для виртуального
 хостинга. Вы должны использовать метод m4 FEATURE(virtusertable);
 более подробные инструкции перечислены на
 нашей странице Virtual
 Hosting with Sendmail. 


  
 
 Q3.29 - Как я могу добавить  заголовок, определяющий
 фактического получателя (при наличии многократных пользователей в виртуальном домене) на одиночный почтовый ящик?
 
Дата: 2 июля, 1998 

 Модифицирован: 17 мая, 2001
Сваливание
 многочисленной пользовательской почты в одиночный почтовый ящик
 явлеется не очень хорошим методом  распределения почты
 пользователей, но если Вы вынуждены делать это,
 следующее решение должно позволить
 приложению, подобному fetchmail отделять сообщения 
 для индивидуальных пользователей. 

    
 

  1.  Используйте FEATURE(local_procmail) в вашем .mc файле,
  таким образом procmail (который Вы должны установить отдельно)
  будет доставлять почту в почтовый ящик. 

  2.  Используйте FEATURE(virtusertable), чтобы создать
  virtual user table вступление для домена следующим образом: 
 @domain.com 	 domuser+%1 
Где domuser - имя пользователя почтового ящика, который Вы будете использовать. Заметьте, что "domuser"
  должно быть фактическое имя пользователя,
  НЕ алиас. 

    
 Может быть необходимо приобщить
 "@localhost" следующим образом 
 @domain.com 	 domuser+%1@localhost 

  3.  Поместите это в соответствующую 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
  найти это или нет. 




  
 
 Q3.30 - Что я должен делать, когда Build
 терпит неудачу потому что  groff не был найден?
 
Дата: 24 сентября, 1998

 Вы можете получить groff от ftp://ftp.gnu.org/pub/gnu/. Но это - не
 большое решение, потому что: 

    
 

  1.  Вы уже успешно сформировали бинарный код
  sendmail, чтобы удалиться от  этого. 

  2.  Вы можете использовать предварительно отформатированные страницы
  руководства в любом случае: 
 % cp *.0 obj* 





  
 
 Q3.31 - Что значит "class hash not available"?
 
Дата: 24 сентября, 1998

 Вы сформировали sendmail и/или makemap без NEWDB, указанного в вашей DBMDEF конфигурации, но Вы определили
 класс hash в sendmail.cf или в makemap команде.Класс hash
 требует поддержки NEWDB, для которой
 Вам необходима Berkeley database. Пожалуйста,
 перейдите к разделу Database
 Definitions нашей страницы Compiling
 Sendmail. 


  

 Q3.32 - Как я конфигурирую majordomo с sendmail 8.9 без того, чтобы ослабить опцию DontBlameSendmail?
 
Дата: 26 января, 1999

 Мы имели некоторые запросы относительно этого, поскольку 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 командами: 

    
 

  1.  Поместите majordomo.aliases файл в /etc, не в
  установочный каталог (/usr/local/lib/majordomo) установки majordomo. 

  2.  Сделайте права на /usr/local/lib/majordomo 0751, не 0775. 

  3.  Сделайте права на /usr/local/lib/majordomo/Log 0664, владелец
  majordom, группа majordom. 

  4.  /usr/local/lib/majordomo/lists в режим 0755, владелец majordom, группа majordom. 

  5.  Права / владельцы для списков должны быть
  такими, как показано выше. Эти права /собственность позволяют majordom продолжать управлять списками. 




  

 Q3.33 - Как мне сконфигурировать мою систему
в общем с sendmail 8.9?
 
Дата: 24 мая, 1999

 Следующее взято непосредственно из раздела
 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"
 для каждого каталога в пути файла. 


  
 
 Q3.34 - Что значит "foo not available for
sendmail programs"?
 
Дата: 24 сентября, 1999

 Это значит, что Вы используете 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 для подробностей относительно этого. 


  
 
 Q3.35 - Как я могу добавить нижний колонтитул / сигнатуру ко
 всей (исходящей) почте?
 
Дата: 9 октября, 2000 

 Модифицирован: 1 августа, 2001

 Это весьма усложнено. На первый взгляд это могло бы быть просто: только "cat" некоторый текст (взятый
 из  файла или чего-нибудь) в конец сообщений
 электроннай почты, передающихся через sendmail. Однако, имеется большая проблема: что относительно
 структурированых сообщений
 электронной почты, то есть, сообщений MIME? Они могут быть произвольно
 cкомплектованы и только "cat" нижнего колонтитула к концу тела
 сообщения может нарушить структуру MIME. (MIME
 понимающий MUA не будет только показывать
 такой нижний колонтитул, так что это довольно бесполезно в любом случае.) Но
 подписанные сообщения  (подумайте: PGP)
 будут нарушаться. Следовательно, не имеется никакого простого
 решения  этой проблемы!

 Если Вы знаете достаточно относительно MIME и некоторого программирования C, то смотрите на sendmail 8.11 и libmilter/README. Это
 сегодня предлагает некоторые функциональные возможности, чтобы достичь этой цели. Однако, это неподдерживаемо sendmail.org! Пожалуйста не
 спрашивайте у нас вопросы относительно libmilter. (тем
 не менее, мы можем наладить баги!) 


  
 
 Q3.36 - Что значит "Cannot open hash database ... Invalid
 argument" ?
 
Дата: 3 января, 2001 

 Модифицирован: 8 февраля, 2001

 Это - ошибка, возвращаемая  библиотекой 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
    

  

  

 



  
 
 Q3.37 - Что значит "parse error before `NDBM'"?
 
Дата: 21 апреля, 2001

 Эта ошибка в общем случае сопровождается сообщением, указывающим,
 в котором файле это произошло  и какой номер строки
 этого файла вызвал эту ошибку , обычно
 следующим образом: 
 ERROR NDBM or NEWDB must be defined. 
 Предполагается, что Вы  читаете эту строку, и делаете
 что-нибудь в связи с этим.

 Обычно на Linux и различных версиях BSD используется
 NEWDB, в то время как в коммерческих
 реализациях Unix  (Solaris, HP-UX и возможных
 других) используется NDBM. Возможно, Вам не
 удалось устанавить требуемые библиотеки, когда Вы
 устанавливали вашу систему.

 Пожалуйста, смотрите 3.31 и раздел
 Database
 Definitions нашей страницы Compiling
 Sendmail для допольнительных подробностей.


 


Оглавление Sendmail FAQ