Провайдеры сети Internet (Internet Service
Providers — ISP) обычно предлагают несколько
схем подключения почтового сервера под
управлением ОС Linux к Сети. Однако идеальной
схемы подключения пока, увы, не существует,
каждая схема подключения имеет определенные
преимущества и недостатки. Решение о применении
той или иной схемы подключения зависит, как
правило, от внешних факторов: ресурсов, политики
или потребностей компании. В этой лекции
рассматриваются различные параметры почтового
сервера под управлением ОС Linux, которые
администратор почтовой системы должен оговорить
с провайдером при подключении к сети Internet.
Подобная информация поможет также в принятии
решения о способе подключения конкретного офиса
к сети Internet. Во втором разделе лекции
представлены четыре примера подключения
почтового сервера к ISP. Эти примеры можно
использовать при подключении вашего почтового
сервера на базе ОС Linux к провайдеру Internet.
Подготовка к
подключению
Прежде чем закупать и устанавливать какое-либо
оборудование или программное обеспечение,
необходимо ответить на несколько вопросов. Чаще
всего это самая сложная часть в планировании и
подключении почтового сервера к сети Internet.
После того как ответы на основные вопросы,
касающиеся конфигурации и количества
программного и аппаратного обеспечения, будут
сформулированы, можно приступать к выбору схемы
подключения.
Перед установкой и конфигурированием почтового
сервера следует обсудить с провайдером Internet
три основных вопроса:
- хостинг
доменных имен;
- метод
доставки почты;
- параметры
соединения.
Каждый из этих вопросов относится к стандартному
перечню услуг, предоставляемых провайдером
Internet. Всегда имеется несколько возможных
решений, и они будут рассмотрены в последующих
разделах.
Хостинг
доменных имен
Одно из основных решений, которые предстоит
принять администратору почтовой системы, —
определение структуры адреса электронной почты
для сотрудников организации. В последнее время
выделение адресов электронной почты и Web-сайта
организации стало одной из горячих тем в сети
Internet. Часто компании готовы выложить
кругленькие суммы для перекупки доменного имени
у другой организации лишь по той причине, что
оно созвучно названию компании или ее
деятельности. Эти суммы намного превышают
обычные регистрационные взносы.
В
недалеком прошлом регистрацией доменных имен
занимался сетевой информационный центр (Network
Information Center — NIC).* Однако недавно
министерство торговли США и NIC разрешили
заниматься регистрацией доменных имен еще
нескольким компаниям. В настоящее время процесс
получения доменного имени упрощен насколько это
возможно. Можно зарегистрировать свое доменное
имя прямо через Internet. Для этого зайдите на
Web-сайт http://www.networksolutions.com (для
Европы: www.ripe.net) и далее следуйте
инструкциям, имеющимся на сайте. Там же вы
сможете проверить, зарегистрировано ли кем-либо
доменное имя, которое вы собираетесь
использовать. После того как вы оплатите
соответствующее доменное имя, необходимо решить
вопрос с его хостингом в сети Internet. Под
хостингом понимается хранение записи о доменном
имени на сервере DNS.
Локальный хостинг
доменных имен
При
наличии выделенного соединения с Internet (см.
далее раздел "Выделенные РРР-соединения") можно
использовать почтовый сервер под управлением ОС
Linux и для хранения DNS-записей о локальном
домене. В лекции 4, "DNS и доменные имена",
дается описание программы
named и файлов, необходимых для
организации работы DNS-сервера в ОС Linux.
Единственное требование для поддержки домена в
системе DNS — наличие не менее двух DNS-серверов.
Кроме того, эти серверы должны находиться в
разных сетях и питаться от различных
электросетей. Очевидно, что это требование можно
выполнить лишь при условии, что один из серверов
DNS находится вне здания организации. Хотя это
довольно дорого для небольших организаций, в
последнее время компании все же выполняют и это
условие.
Хостинг доменных имен
провайдером Internet
При
ведении переговоров с провайдером о подключении
к сети Internet можно рассмотреть возможность
хостинга доменных имен организации провайдером.
Практически все провайдеры Internet
предоставляют такую услугу в стандартном пакете
услуг на подключение.
За
небольшую плату провайдер может взять на себя
регистрацию доменного имени вашей организации в
InterNIC и ведение DNS-записей о вашем домене на
своих серверах имен. Это означает, что записи
типа NS для вашего
домена будут указывать на серверы DNS провайдера
Internet. Часто провайдер Internet для
организации вторичных DNS взаимодействует с
другими провайдерами. Тогда для вашего домена
могут существовать несколько записей
NS, которые
указывают на серверы DNS различных провайдеров.
Единственный недостаток хостинга доменных имен
на сервере провайдера заключается в том, что при
желании зарегистрировать доменное имя для
отдельного компьютера вашей сети необходимо
обращаться к провайдеру. Он, в свою очередь, по
вашей просьбе будет вносить изменения в базу
данных имен для каждого нового хоста в виде
записей A и
PTR.
Первичный
сервер DNS
Для решения
этой проблемы можно сконфигурировать сервер
с ОС Linux таким образом, чтобы он выступал
первичным (главным) DNS-сервером для вашего
домена, а провайдером поддерживался
вторичный (дополнительный) сервер DNS. При
такой схеме регистрация новых хостов в сети
производится на вашем сервере DNS без
участия провайдера.
Методы
доставки почты
Еще
один вопрос, который необходимо обсудить с
провайдером Internet при подключении почтового
сервера к Сети, — порядок получения почты из
Internet на почтовый сервер под управлением ОС
Linux. Существует три основных способа получения
электронной почты из сети Internet. В этом
разделе мы рассмотрим преимущества и недостатки
каждого из них.
Прямая доставка почты
Простейшим способом получения электронной почты
из сети Internet является прямая доставка
сообщений от узлов-отправителей на ваш почтовый
сервер под управлением ОС Linux. Такую схему
доставки почты можно реализовать только при
наличии выделенного соединения с Internet или
при подключении к сети, которая имеет выделенное
соединение с Internet.
На
почтовом сервере необходимо запустить программу,
реализующую функции сервера SMTP (например,
sendmail или
smail). При этом
для сервера SMTP должен быть сконфигурирован
правильный IP-адрес. Это позволит удаленным
узлам устанавливать SMTP-соединения с почтовым
сервером. Независимо от местонахождения базы
данных DNS с описанием вашего домена, в ней
должны содержаться записи
МХ, в которых однозначно указан IP-адрес
почтового сервера вашего домена. Все хосты в
сети Internet, доставляющие почту для вашего
домена, будут запрашивать систему DNS о почтовом
сервере для этого домена. Если в записи
МХ для домена
указан только IP-адрес почтового сервера, то
очевидно, что он должен обслуживать соединения
по протоколу SMTP, в противном случае почтовые
сообщения просто не будут доставлены по
назначению.
Вся
исходящая почта с помощью программы
sendmail и
протокола SMTP также будет доставляться прямо на
узел получателя. Преимущество такого способа
доставки почты состоит в том, что вся почта
доставляется в режиме реального времени.
Отсутствуют задержки, обусловленные интервалами
времени накопления почты на главном почтовом
узле. Недостатком же является то, что почтовый
сервер должен функционировать круглосуточно 7
дней в неделю. При этом любые простои сервера
могут привести не только к потерям почты, но и к
останову работы всей сети.
В
большинстве случаев невозможно обеспечить
круглосуточную работу в сети Internet 7 дней в
неделю. Поэтому были разработаны еще два
альтернативных способа получения электронной
почты из сети Internet.
Получение почты для
домена через один почтовый ящик на сервере
провайдера
Одно из полезных свойств узла провайдера
Internet состоит в том, что на нем имеются
хост-компьютеры, круглосуточно подключенные к
сети Internet 7 дней в неделю. Это
обстоятельство можно использовать для получения
почты на ваш домен. Для этого требуется лишь
изменить имя почтового сервера в записи
МХ в системе DNS
на сервер провайдера. Таким образом, вы
направите всю почту для вашего домена на
почтовый сервер провайдера. С этого момента
помещение почты для вашего домена в определенную
область, откуда ее будет забирать локальный
почтовый сервер, полностью возлагается на
провайдера.
Один из способов реализации такой схемы
получения почты заключается в пересылке всех
сообщений, адресованных пользователям вашего
домена, в определенный почтовый ящик на почтовом
сервере провайдера. Из лекции 11, "Установка и
конфигурирование sendmail", вы знаете, что
имеется возможность создания таблицы виртуальных
пользователей, с помощью которой можно
перенаправить всю почту для домена в один
почтовый ящик (см. листинг 11.4).
Для
получения почты из этого ящика на почтовом
сервере провайдера можно использовать протокол
POP3 с соответствующим идентификатором
пользователя. Затем с помощью этого
идентификатора локальный почтовый сервер может
получать всю почту, адресованную пользователям
домена. После того как почта получена из ящика
провайдера, ваш почтовый сервер под управлением
ОС Linux должен проанализировать адреса
получателей и обеспечить ее доставку
пользователям локального домена, которым она
адресована.
Хотя такой способ имеет право на существование,
он не всегда эффективен и рекомендуется не для
всех случаев. Программа распределения почты при
определении идентификатора пользователя
получателя сообщения может обрабатывать только
заголовки сообщений формата RFC 822. Иногда
программа распределения почты не может правильно
распознать получателя сообщения. Кроме того,
некоторые программы для распределения почты при
передаче сообщения получателю искажают заголовок
формата RFC 822, что делает возврат почты
практически невозможным. В рассмотренном ниже
способе доставки почты используется более
устойчивая схема получения сообщений электронной
почты.
Накопление почты для
домена у провайдера
В
основу третьего способа получения почты для
локального домена положен виртуальный почтовый
хостинг. Его смысл заключается в том, что база
данных DNS указывает в МХ-записи
на почтовый сервер провайдера, программа
sendmail на
котором сконфигурирована таким образом, что,
приняв почту, адресованную вашему домену, она
помещает ее в очередь почтовых сообщений. Обычно
очередь почтовых сообщений хранится в
определенном каталоге. Сообщения, адресованные в
ваш домен, находятся в очереди до тех пор, пока
локальный почтовый сервер не установит
соединение с почтовым сервером провайдера. Далее
сообщения из почтовой очереди с помощью одного
из известных протоколов поступают на ваш
почтовый сервер под управлением ОС Linux.
При
пересылке почты с использованием протоколов SMTP
или UUCP заголовки сообщений практически не
подвергаются изменениям, как это было в
предыдущей схеме. Таким образом, механизм
возврата сообщения работает практически
безотказно.
Имеется несколько способов получения почты,
помещенной в почтовую очередь на сервере
провайдера. Наиболее распространен метод
получения почты из очереди с помощью SMTP-команды
ETRN, посылаемой
локальным почтовым сервером под управлением ОС
Linux серверу провайдера. По этой команде
почтовый сервер провайдера должен установить
SMTP-соединение с локальным сервером электронной
почты и передать ему всю почту, адресованную в
ваш домен (см. лекцию 5, "Протокол SMTP").
Параметры
соединения
Третий вопрос в списке важнейших — способ
соединения почтового сервера под управлением ОС
Linux с провайдером Internet. Довольно часто
провайдерами предлагается несколько схем
соединения почтового сервера. Хотя каждый
провайдер предпочитает определенный способ
подключения почтовых серверов клиентов к сети
Internet, все они в конечном итоге обеспечивают
устойчивое соединение для доставки сообщений
электронной почты.
Часто требования к соединению с провайдером
определяют и способ доставки сообщений. Если,
например, кроме почтового сервера, еще
каким-либо устройствам в сети требуется
соединение с Internet, то очевидно, что для
почты не следует использовать протокол UUCP. С
другой стороны, многие компании используют
выделенные РРР-соединения исключительно для
работы с Web и FTP и отдельные UUCP-соединения
для работы с электронной почтой. При такой схеме
подключения почтовый трафик не снижает обработку
интерактивного трафика. И помните, что наличие
ресурсов и проводимая компанией политика в
области автоматизации и использования Internet
играет решающую роль в процессе принятия решения
о подключении к Internet. В этом разделе описаны
наиболее распространенные способы подключения
почтового сервера к Internet через узел
провайдера.
Выделенное
РРР-соединение
Лучше всего организовывать выделенное соединение
с сетью Internet. Хотя, к сожалению, такой тип
подключения и является самым дорогостоящим. В
настоящее время выделенное соединение почтового
сервера с сетью Internet организуется двумя
способами.
Первый способ, пожалуй, наиболее предпочтителен.
Он основан на использовании специального
внешнего устройства, с помощью которого и
организуется выделенный канал с узлом провайдера
Internet. Обычно в качестве таких устройств
выступают небольшие маршрутизаторы. Они
обеспечивают подключение сети компании к
провайдеру Internet либо по коммутируемой, либо
по выделенной линии. При этом почтовому серверу
под управлением ОС Linux требуется обеспечить
лишь стандартное сетевое соединение, остальную
работу по соединению с Internet выполнит
маршрутизатор.
Второй способ подключения предполагает
непосредственное участие в установлении
соединения с сетью Internet почтового сервера на
базе ОС Linux через выделенную линию. Как уже
отмечалось в лекции 8, "Протокол РРР", почтовый
сервер под управлением ОС Linux может с помощью
программы pppd
устанавливать соединение с сервером провайдера.
Подключив к почтовому серверу модем, можно
заставить его выполнять маршрутизацию IP-пакетов.
Таким образом, на базе одного компьютера под
управлением ОС Linux вы получаете почтовый
сервер и IP-маршрутизатор. При реализации такой
схемы желательно использовать ПК с мощным
процессором и большим объемом памяти.
Коммутируемое
РРР-соединение
Еще
один метод подключения почтового сервера на базе
ОС Linux к сети Internet заключается в
использовании коммутируемого РРР-соединения.
Такое соединение устанавливается только в те
моменты, когда почтовому серверу необходимо
принять или отправить почту, а все остальное
время линию можно использовать для других целей.
Таким образом, экономический выигрыш от
применения такого типа подключения очевиден,
поскольку не требуется круглосуточная загрузка
телефонной линии.
Для
установления РРР-соединения по запросу от
почтового сервера необходимо специальное
программное обеспечение. Как правило, в ОС Linux
для этой цели используется программа
diald, работа
которой подробно описана в лекции 8. Она может
использоваться совместно со стандартной
программой pppd
для обнаружения исходящего IP-трафика,
требующего наличия РРР-соединения.
Коммутируемое UUCP-соединение
И
последний метод подключения почтового сервера к
сети Internet — подключение с использованием
протокола "UNIX-to-UNIX CoPy" (UUCP), который
рассмотрен в глекции 9, "Протокол UUCP". Помните,
что провайдеры Internet не всегда поддерживают
протокол UUCP. Довольно часто провайдеры
Internet, у которых на узле нет администраторов
UNIX, вообще отказывают в подключении по
протоколу UUCP.
С
другой стороны, многие провайдеры, наоборот,
предлагают значительные скидки для клиентов,
подключающихся по UUCP, только для работы с
электронной почтой. Вам необходимо ознакомиться
с пакетами услуг, предлагаемых локальными
провайдерами Internet, чтобы узнать, имеется ли
возможность работы с ними по протоколу UUCP. В
США имеется несколько общенациональных
провайдеров Internet, которые предлагают сервис
UUCP по бесплатным номерам телефонов. Однако
следует проявить осторожность в отношении оплаты
таких подключений: некоторые провайдеры взимают
почасовую плату за пользование сервисом UUCP.
Если в вашей организации планируется пересылка
файлов больших объемов, то время работы в линии
может стоить вам больших затрат, чем ожидалось.
Главным преимуществом при работе с UUCP является
высокий уровень безопасности. Во время всего
сеанса работы по UUCP ваш почтовый сервер не
подключен к сети Internet напрямую. Это
обстоятельство затрудняет проникновение хакеров
в вашу сеть. И чем меньше у них возможностей
доступа к вашему серверу, тем лучше для вас.
Примеры
подключения почтового сервера
В
предыдущем разделе были рассмотрены основные
вопросы, которые должны учитываться
администратором почтовой системы при подключении
сервера электронной почты на базе ОС Linux к
сети Internet. В этом разделе мы рассмотрим
четыре типовых схемы подключения почтового
сервера к сети Internet:
-
выделенное РРР-соединение с непосредственной
доставкой почты из Internet;
-
коммутируемое РРР-соединение с
использованием одного почтового ящика на
почтовом сервере провайдера;
-
коммутируемое РРР-соединение с
использованием почтовой очереди на сервере
провайдера;
-
коммутируемое UUCP-соединение с
использованием почтовой очереди на сервере
провайдера.
К
каждой из этих схем прилагаются примеры файлов
конфигурации для ее реализации с помощью
определенных программ. Помните, что во всех
приведенных ниже примерах используются фиктивные
IP-адреса и имена доменов. Вам следует
использовать свои зарегистрированные имена
доменов и IP-адреса.
Выделенное
РРР-соединение с непосредственной доставкой
почты из Internet
На
сегодняшний день на почтовом сервере под
управлением ОС Linux проще всего реализовать
схему выделенного соединения с Internet. Как уже
отмечалось ранее, существует два метода
получения выделенного соединения с сетью
Internet. Предположим, что в вашей локальной
сети нет специального маршрутизатора, с помощью
которого обеспечивается выход в Internet. В
таком случае работу РРР-соединения должен
обеспечить почтовый сервер под управлением ОС
Linux. На рис. 13.1 представлена схема работы
сети такой конфигурации.
Рис. 13.1. Схема работы почтового
сервера под управлением ОС Linux с Internet по
выделенной линии
При
использовании такой схемы нужно сконфигурировать
РРР-соединение таким образом, чтобы связь
восстанавливалась сразу при включении питания
аппаратуры. Программа sendmail должна обеспечить
доставку почты удаленным узлам в сети Internet
напрямую, для чего ее необходимо соответствующим
образом сконфигурировать. Несмотря на то что
имеется постоянное РРР-соединение с провайдером,
при использовании такой схемы подключения он
должен обеспечить работу системы доменных имен
по обслуживанию вашего домена. В этом случае
отпадает необходимость выполнения этих функций
вашим почтовым сервером. Ниже дается описание
файлов конфигурации, с помощью которых
реализуется такая схема подключения.
Настройка
РРР-соединения
Как
уже говорилось в лекции 8, для установки
РРР-соединения с узлом провайдера Internet
применяется программа
pppd. Для ее работы необходим сценарий
chat, в котором
программе даются инструкции о подключении к
удаленному серверу с помощью модема. В листинге
13.1 представлен пример сценария
chat, который вы
можете использовать для организации соединения с
сервером провайдера Internet.
1 ""
2 ATDT5551234
3 CONNECT
4 ""
5 "ogin:"
6 rich
7 "word:"
8 guitar
9 "rich]$"
10 "exec /usr/sbin/pppd silent modem crtscts
proxyarp
10.0.0.100:10.0.0.2"
Листинг 13.1.
Пример сценария isp.chat для pppd
В
строке 2 листинга 13.1 замените номер телефона
на номер, предоставленный вашим провайдером для
дозвона к его серверу. Следует также заменить
строки 6 и 8 с именем пользователя и паролем,
необходимыми для получения доступа к серверу
провайдера. В строке 9 замените фрагмент
командной строки на фрагмент, выдаваемый
сервером провайдера. В строке 10 задается
команда на запуск pppd
на сервере провайдера. Скорее всего, на сервере
вашего провайдера для запуска этой программы
используется несколько иная строка. Выясните у
провайдера ее содержимое. Сохраните полученный
сценарий в каталог, куда имеет доступ только
пользователь root
(помните: в этом файле в явном виде хранится имя
пользователя и пароль доступа на сервер
провайдера).
После создания сценария
chat вы можете запустить программу
pppd для
подключения локального почтового сервера к
серверу провайдера:
pppd ttyS1 38400
connect '/usr/sbin/chat -v -f /root/isp.chat'
modem crtscts defaultroute
Замените имя устройства
ttyS1 в соответствии с последовательным
портом, к которому подключен модем. Замените
также имя файла isp.chat
и каталог, в котором он находится, на имеющиеся
в вашей системе. После запуска приведенной выше
команды должно быть установлено РРР-соединение.
Команду на запуск pppd
можно сохранить в виде файла сценария. Это
облегчит ее повторный запуск при разрывах
соединения.
Для
того чтобы почтовый сервер на базе ОС Linux
правильно преобразовывал доменные имена,
необходимо в качестве переменной
nameserver в
/etc/resolv.conf
указать имя сервера DNS провайдера Internet. В
файле /etc/resolv.conf
можно объявлять три переменных
nameserver. Строка,
где определяется сервер имен, выглядит следующим
образом:
nameserver
192.168.10.6
Адрес IP, указанный с переменной
nameserver,
является адресом сервера имен провайдера. Это
позволяет программе sendmail правильно
интерпретировать доменные имена в адресной части
почтовых сообщений и получать соответствующие
МХ-хосты (почтовые
серверы) для этих доменов.
Настройка sendmail
Настройка файла конфигурации sendmail для работы
по этой схеме чрезвычайно проста. В нем лишь
необходимо задать следующее:
- вся
исходящая почта должна посылаться с
использованием только доменного имени, без
включения в поле адреса имени хоста, с
которого она была отправлена;
- вся
исходящая почта доставляется получателю
напрямую;
- для
доставки почты локальным пользователям
используется программа
procmail;
- локальным
пользователям разрешается пересылка почты
непосредственно в Internet.
Файл макросов sendmail должен приобрести
следующий вид (листинг 13.2).
1 divert(-1)
2 divert(0)dnl
3 includel('/usr/lib/sendmail-cf/m4/cf.m4')dnl
4 OSTYPE('linux')dnl
5
6 FEATURE('allmasquerade')dnl
7 FEATURE('masquerade_envelope')dnl
8 FEATURE('local_procmail', '/usr/bin/procmail')dnl
9 FEATURE('access_db', ' /etc/mail/access.db')dnl
10 FEATURE('nocanonify')dnl
11
12 MAILER('smtp')dnl
13 MAILER('procmail')dnl
14
15 MASQUERADE_AS('smallorg.org')dnl
Листинг 13.2.
Пример файла макросов direct.mc
В
строках 6, 7 и 15 листинга 13.2 описана
настройка подстановки адресов (маскарадинг). С
помощью этой настройки в адресах всей исходящей
почты может использоваться другой адрес или
доменное имя (в нашем случае это доменное имя
smallorg.org).
Настройка позволяет создавать пользователям
адреса электронной почты с простым и понятным
доменным именем, таким например, как,
prez@smallorg.org.
В строке 8 задается программа для локальной
доставки почты пользователям на самом сервере. В
нашем случае в этой роли выступает программа
procmail. В строке
9 определяется файл
access_db, содержащий хешированную базу
данных, где указаны хосты, которым разрешено
отправлять почту через данный почтовый сервер.
При создании нового файла конфигурации для
sendmail можно воспользоваться макропроцессором
m4:
m4 direct.m4 >
sendmail.cf
После создания нового файла конфигурации
существующий файл
sendmail.cf из каталога
/etc нужно
заменить вновь созданным.
Чтобы обеспечить передачу почты клиентам
локальной сети через почтовый сервер на базе ОС
Linux, необходимо создать базу данных управления
доступом, где адресам локальной сети разрешается
использовать свойство
RELAY (см. лекцию 15, "Конфигурирование
клиентов ЛВС"). В листинге 13.3 представлена
текстовая версия подобной записи в базе данных
управления доступом.
192.168.1 RELAY
Листинг 13.3.
Пример базы данных управления доступом
/etc/mail/access
Из
листинга 13.3 видно, что IP-адреса локальной
сети все находятся в сети с адресом
192.168.1.0. (Запись
в базе данных приведена в качестве примера.) На
самом деле вам нужно изменить IP-адреса на
выданные провайдером или другой организацией по
управлению сетью. Для создания новой базы данных
из текстового файла воспользуйтесь утилитой
makemap:
makemap hash
/etc/mail/access.db
< /etc/mail/access
После создания нового файла конфигурации
sendmail и нового файла базы данных управления
доступом необходимо перезапустить программу
sendmail, чтобы внесенные в файлы изменения были
приняты. В команде на запуск программы sendmail
следует указать параметр
-q, которым устанавливается интервал
времени для проверки очереди почтовых сообщений
на наличие новых сообщений:
/usr/sbin/sendmail -bd
-q30m
Вышеприведенной командой в фоновом режиме
запускается демон-процесс sendmail и
устанавливается интервал проверки почтовой
очереди каждые 30 минут.
Автоматизация обработки
почты
Запуск программы sendmail можно описывать в
сценариях начальной загрузки ОС Linux. В
большинство версий ОС Linux входит уже готовый
сценарий запуска для sendmail. В случае его
отсутствия с помощью программы
linuxconf можно
добавить запуск sendmail в сценарии начальной
загрузки системы. На рис. 13.2 представлено окно
конфигурации, где разрешается запуск sendmail во
время начальной загрузки.
Рис. 13.2. Окно конфигурации программы
linuxconf
Коммутируемое
РРР-соединение с использованием одного почтового
ящика на почтовом сервере провайдера
Такая схема часто применяется в небольших
компаниях, которые либо не могут себе позволить
в силу определенных причин круглосуточный доступ
к Internet, либо просто не нуждаются в нем. При
работе по коммутируемому РРР-соединению
локальный почтовый сервер через заданные
интервалы времени (например, один раз утром,
один раз вечером) вызывает сервер как при
наличии исходящей почты, так и для проверки
наличия входящих сообщений. Кроме того,
провайдер конфигурирует свой почтовый сервер
таким образом, чтобы вся почта, адресованная
пользователям домена, поступала в один почтовый
ящик. Затем с помощью программы
fetchmail
локальный почтовый сервер получает почту из
ящика на сервере провайдера и распределяет ее
соответствующим пользователям на своем почтовом
сервере. На рис. 13.3 представлена схема работы
такой системы.
Рис. 13.3. Схема работы почтового
сервера под управлением ОС Linux с
использованием коммутируемого РРР-соединения и
одного почтового ящика на сервере провайдера
Internet
Настройка
РРР-соединения
Конфигурирование коммутируемого РРР-соединения
имеет много общего с настройкой выделенного
РРР-соединения. Единственное отличие в работе
коммутируемого и выделенного соединения состоит
в том, что РРР-соединение устанавливается только
в том случае, когда локальному почтовому серверу
необходима связь с сервером провайдера, и
завершается после окончания сеанса связи с
сервером провайдера. Для установки и завершения
РРР-соединения в ОС Linux используется программа
diald. С ее
помощью можно запускать и останавливать работу
программы pppd,
описанной в предыдущем разделе.
Если в имеющейся у вас версии ОС Linux
отсутствует бинарный файл программы
diald, то его
можно получить через Internet по адресу:
http://diald.unix.ch.
На момент написания книги текущей версией
diald была версия
diald-0.99. Для
установки программы diald
на вашем компьютере следует выполнить следующее.
После установки программы необходимо создать для
нее файл конфигурации. Этот файл обычно
находится в /etc/diald.conf.
В листинге 13.4 приведен пример файла
конфигурации для diald.
1 ###
2 # /etc/diald.conf - diald configuration
3 #
4 # see /usr/lib/diald for sample config
files
5 #
6 mode ppp
7 connect '/usr/sbin/chat -f /root/isp.chat
-t 35000'
8 connect-timeout 180
9 device /dev/ttyS1
10 speed 115200
11 modem
12 lock
13 crtscts
14 local 192.168.1.1
15 remote 192.168.1.2
16 dynamic
17 defaultroute
18 include /usr/lib/diald/standard.filter
19 fifo /etc/diald/diald.ctl
Листинг 13.4.
Пример файла /etc/diald.conf
В
строке 7 листинга 13.4 определяется
местонахождение сценария, который был создан для
установки РРР-соединения в рассмотренной выше
схеме подключения. Сама программа
diald не
занимается организацией РРР-соединения, в ее
функции входит лишь запуск программы pppd при
наличии данных, адресованных во внешнюю сеть. В
строке 9 описывается порт на Linux-сервере, к
которому подключен модем —
/dev/ttyS1 (в
операционной системе DOS это порт СОМ2). О
нумерации портов более подробно читайте в лекции
3, "Установка телекоммуникационного оборудования
в ОС Linux". В строках 14 и 15 локальному
почтовому серверу и серверу провайдера,
участвующим в РРР-соединении, назначаются
временные IP-адреса. В строке 18 определяется
стандартный фильтр diald,
который устанавливает правила и время установки
и завершения РРР-соединения.
Помните, что запустить
diald может только пользователь с правами
root. После
запуска программа diald
автоматически переводится в фоновый режим и
следит за IP-трафиком сети, инициируя при
необходимости РРР-соединение с сервером
провайдера Internet. Через 30 секунд после
завершения передачи IP-трафика программа
diald
автоматически завершает РРР-соединение.
Комбинация программ diald
и pppd позволяет
серверу электронной почты под управлением ОС
Linux получать соединение с провайдером Internet
при наличии исходящей почты. К ней относятся и
сообщения от пользователей локальной сети,
которые пересылаются через локальный почтовый
сервер в сеть Internet.
Конфигурация sendmail
Как и в предыдущем случае, для реализации новой
схемы необходимо создать новый файл конфигурации
sendmail. На этот раз почтовый сервер под
управлением ОС Linux не может отправлять и
принимать сообщения непосредственно от удаленных
хостов в сети Internet. При использовании такой
схемы доставка сообщений между локальным
почтовым сервером и другими узлами в сети
осуществляется через интеллектуальный хост. Все
исходящие почтовые сообщения помещаются в
очередь на сервере электронной почты и находятся
там до того момента, пока sendmail не установит
соединение с интеллектуальным хостом и не начнет
с ним сеанс работы. Все входящие сообщения
хранятся в очереди почтовых сообщений на сервере
провайдера и также ожидают установления
соединения с соответствующим почтовым сервером.
Локальный почтовый сервер подключается к серверу
провайдера и с помощью программы
fetchmail получает
адресованные его домену сообщения.
Таким интеллектуальным
хостом обычно является почтовый сервер
провайдера, обеспечивающий пересылку сообщений
между сетью Internet и вашим почтовым сервером
на базе ОС Linux. В листинге 13.5 представлен
файл конфигурации sendmail для работы по
коммутируемому соединению.
1 divert(-1)
2 divert(0)dnl
3 include('/usr/lib/sendmail-cf/m4/cf.m4')dnl
4 OSTYPE('linux')dnl
5
6 FEATURE('allmasquerade')dnl
7 FEATURE('masquerade_envelope')dnl
8 FEATURE('local_procmail', '/usr/bin/procmail')dnl
9 FEATURE('access_db', '/etc/mail/access.db')dnl
10 FEATURE('nocanonify')dnl
11
12 MAILER('smtp')dnl
13 MAILER('procmail')dnl
14
15 MASQUERADE_AS('smallorg.org')dnl
16 define('SMART_HOST', 'smtp:mail.isp.net')dnl
Листинг 13.5.
Пример файла макросов dialup.mc
Как и в предыдущем случае, в листинге 13.5 для
почтового сервера определяется доменное имя,
которое будет подставляться в адреса всех
сообщений. Определяется также программа для
локальной доставки почты на самом почтовом
сервере. Эти функции будет выполнять программа
procmail.
Единственное отличие наблюдается в строке 16,
где в качестве SMART_HOST
определяется почтовый сервер провайдера
Internet. Вам необходимо лишь изменить имя хоста
mail.isp.net на
имя реального почтового сервера вашего
провайдера. Сохраните полученный файл макросов и
с помощью макропроцессора
m4 сгенерируйте новый файл
sendmail.cf (как
показано в предыдущем примере).
После этого клиенты локальной сети смогут
использовать локальный почтовый сервер для
пересылки почтовых сообщений. Вам понадобится
лишь создать файл access
базы данных управления доступом и с помощью
утилиты makemap
создать хешированную базу данных, которая
хранится в файле
access.db.
Далее необходимо запустить программу sendmail в
фоновом режиме. Для этого сценарий запуска
sendmail можно добавить в сценарии запуска
init для
соответствующего уровня запуска ОС Linux. В
качестве альтернативы можно использовать
графическую программу
linuxconf, окно которой представлено на
рис. 13.2.
Конфигурация fetchmail
Программа fetchmail
является универсальным инструментом для
получения почтовых сообщений от удаленных
серверов электронной почты. При работе по
рассматриваемой схеме программа
fetchmail должна
быть сконфигурирована для получения сообщений из
одного почтового ящика на сервере провайдера с
использованием протокола POP3.
Получив сообщения от почтового сервера
провайдера, программа
fetchmail должна проанализировать
заголовки формата RFC822 и определить, кому из
локальных пользователей адресовано то или иное
сообщение. Эти настройки могут быть заданы в
файле конфигурации
fetchmail.
Для каждого пользователя на локальном почтовом
сервере под управлением ОС Linux заводится
отдельный файл конфигурации
fetchmail. Этот
файл хранится в рабочем каталоге пользователя
$HOME под именем
.fetchmail.rc.
Пользователь root
пользуется файлом конфигурации
fetchmail,
определенным для подключения к почтовому серверу
провайдера по протоколу POP3 с использованием
имени пользователя и пароля, заданных
провайдером. Кроме того, каждый пользователь,
которому разрешено принимать почту из Internet,
должен быть описан в файле
.fetchmail.rc
пользователя root.
Почта, полученная для описанных в этом файле
локальных пользователей, передается в их ящики.
Вся остальная почта, полученная с помощью
программы fetchmail,
хранится в почтовом ящике пользователя,
запустившего fetchmail
(в нашем случае пользователя
root). В листинге
13.6 приведен пример файла
.fetchmail.rc,
который может применяться при работе по
описываемой схеме.
1 poll mail.isp.net
with proto POP3
2 localdomains smallorg.org
3 no envelope
4 no dns
5 user "rich" with password "guitar" is
6 rich
7 barbara
8 katie
9 jessica
10 haley
11 riley
12 chris
13 matthew
14 here
Листинг 13.6.
Пример файла конфигурации
$HOME/.fetchmail.rc
В
строке 1 листинга 13.6 определяется почтовый
сервер провайдера, к которому для получения
почты подключается программа
fetchmail. В этой
строке также указывается, что получение почты с
сервера провайдера будет осуществляться с
помощью протокола POP3. В строках 2–4
определяются параметры соединения. Так, в строке
2 указывается, какое доменное имя будет
использовано программой
fetchmail в качестве локального доменного
имени при анализе заголовков сообщений. То есть
адрес prez@smallorg.org
почтовый сервер распознает как пользователя на
локальном почтовом сервере с именем
prez. Строкой 3
программе fetchmail
указывается не использовать при анализе адреса
получателя поле заголовка
X-Envelope-To:. Это поле обычно
добавляется почтовыми транспортными агентами МТА
при прохождении сообщением почтовых узлов. Дело
в том, что эти поля могут стать причиной
некорректной работы
fetchmail, поэтому желательно их
игнорировать. В строке 4 указывается, что нет
необходимости в проверке подлинности узла
отправителя с помощью системы DNS. В строке 5
задаются имя пользователя и пароль, с которыми
осуществляется подключение
fetchmail к
почтовому ящику на сервере провайдера. Эти
данные должен предоставить ваш провайдер сети
Internet.
В
строках 6–13 задаются все пользователи
локального почтового сервера под управлением ОС
Linux, которые могут принимать электронную
почту. Работа программы заключается в просмотре
и анализе полей заголовков формата RFC 822 на
предмет соответствия именам пользователей,
приведенных в списке. Если в адресной части
сообщения найдено совпадение с именем
пользователя, то программа
fetchmail
пересылает сообщение пользователю локального
почтового сервера. В противном случае, если ни
один из пользователей в адресе не соответствует
приведенным в списке,
fetchmail пересылает сообщение в почтовый
ящик пользователя, от имени которого она была
запущена (в нашем случае это пользователь
root). В
обязанности администратора почтовой системы
входит обновление списка пользователей
локального почтового сервера. В строке 14
указано, что все приведенные имена пользователей
находятся на том же хост-компьютере, где
запущена программа
fetchmail.
После создания файла
.fetchmail.rc и сохранения его в рабочем
каталоге пользователя, от имени которого будет
запускаться fetchmail
(в нашем случае это пользователь
root), можно
непосредственно приступить к работе с
fetchmail. Теперь,
если вы зададите в командной строке
fetchmail,
программа diald
автоматически откроет РРР-соединение, а
fetchmail
автоматически подключится к почтовому серверу
провайдера для получения сообщений из почтового
ящика, выделенного для вашего домена. Если все
эти этапы пройдут успешно, то следующим
действием будет получение почты.
Автоматизация получения
почты
После конфигурирования программного обеспечения
почтового сервера на базе ОС Linux следует
автоматизировать процесс проверки и получения
почты. Для этого необходимо лишь задать
интервалы времени, через которые будет
запускаться программа
fetchmail. При этом одним из условий
является наличие уже запущенной в фоновом режиме
программы sendmail.
Запуск fetchmail
через определенные интервалы времени можно
обеспечить с помощью утилиты ОС Linux
cron. Эта утилита
считывает таблицу, в которой содержатся строки с
инструкциями о запуске определенной программы в
определенное время. Каждый пользователь в ОС
Linux имеет свою таблицу
cron. В нашем примере программа
fetchmail
запускается пользователем
root, поэтому следует модифицировать
cron-таблицу пользователя
root. Изменить содержимое cron-таблицы
можно с помощью утилиты
crontab. Если вы как пользователь
root зададите
команду crontab -l,
то увидите содержимое cron-таблицы. Чтобы внести
изменения в нее, воспользуйтесь командой
crontab -e. С
помощью этой команды вы перейдете в режим
редактирования в стандартном для ОС Linux
редакторе vi.
Чтобы задать программе
fetchmail интервал запуска 15 минут,
необходимо добавить в таблицу строку,
представленную в листинге 13.7.
0,15,30,45 * * * *
/usr/bin/fetchmail
Листинг 13.7.
Пример записи в cron-таблице для запуска
fetchmail
Этой строкой определяется, что круглый год
ежемесячно семь дней в неделю в 0, 15, 30 и 45
минут каждого часа будет запускаться программа
fetchmail. Вы
можете изменить этот интервал в соответствии со
своими потребностями. Избегайте частой проверки
почтового ящика на сервере провайдера, поскольку
может возникнуть ситуация, когда программой
diald еще не будет
завершено РРР-соединение с сервером провайдера,
как уже будет инициироваться новое.
Коммутируемое
РРР-соединение с использованием почтовой очереди
на сервере провайдера
В
третей схеме подключения почтового сервера также
используется коммутируемое РРР-соединение, по
которому осуществляется обмен почтовыми
сообщениями между локальным почтовым сервером и
сервером провайдера. Отличие этой схемы от
предыдущих заключается в том, что почта для
вашего домена помещается не в отдельный почтовый
ящик на сервере провайдера, а в очередь почтовых
сообщений на этом сервере. Дальнейшая доставка
почты на ваш почтовый сервер полностью зависит
от конфигурации программы sendmail на его
сервере электронной почты.
Итак, после того как ваш почтовый сервер
установил РРР-соединение с сервером электронной
почты провайдера, он должен еще установить SMTP-соединение,
что позволит ему запросить с помощью команды
ETRN почту из
очереди почтовых сообщений. Как уже было сказано
в лекции 5, в ответ на команду
ETRN почтовый
сервер провайдера должен создать еще одно SMTP-соединение
с локальным почтовым сервером домена и передать
по нему все сообщения из своей очереди, которые
адресованы в этот домен. В таком случае в
заголовки сообщений не вносятся никакие
изменения. Работа почтового сервера по такой
схеме представлена на рис. 13.4.
Рис. 13.4. Схема работы почтового
сервера с использованием коммутируемого
РРР-соединения и почтовой очереди на сервере
провайдера
Настройка
РРР-соединения
Работа РРР-соединения в данной схеме полностью
совпадает с предыдущей схемой. Для организации
коммутируемых соединений по протоколу РРР
необходимо установить программы
diald и
pppd, а также
настроить файл diald.conf
в соответствии с примером, приведенным в
листинге 13.4. Как и в предыдущей схеме,
программа diald
работает в фоновом режиме и отслеживает весь
IP-трафик в сети. При наличии исходящих
сообщений с ее помощью может быть инициирована
установка РРР-соединения. По завершении сеанса
работы программа ожидает 30 секунд, после чего
разрывает РРР-соединение. При использовании
такой схемы подключения почтового сервера к
провайдеру Internet, возможно, понадобится
увеличить интервал времени ожидания при
установлении соединения. Это необходимо для
того, чтобы почтовый сервер провайдера получил
достаточно времени для организации обратного
SMTP-соединения с локальным почтовым сервером.
Для увеличения интервала ожидания отредактируйте
файл
/usr/lib/standard.filter, который
прилагается к программе
diald. Последняя строка в этом файле
должна выглядеть примерно так:
accept any 30 any
Здесь задается интервал ожидания 30 секунд.
Увеличьте его, заменив числовое значение
интервала 30 на
величину интервала, согласованную с провайдером
сети Internet, и сохраните полученный файл.
Конфигурация sendmail
Поскольку РРР-соединение не поддерживается в
программе sendmail постоянно, необходимо
предусмотреть работу с интеллектуальным хостом,
как и в предыдущем случае. Поэтому
сконфигурируйте sendmail так, чтобы пользователи
вашей сети могли пересылать свои сообщения через
локальный почтовый сервер на базе ОС Linux. Для
работы по рассматриваемой нами схеме можно без
изменений использовать файл конфигурации
sendmail, полученный для предыдущей схемы
подключения. Этот файл будет таким же, как и
приведенный в листинге 13.5
dialup.mc.
Необходимо, кроме того, создать базу данных,
аналогичную представленной в листинге 13.3, с
помощью которой удаленные клиенты сети,
используя протокол SMTP, смогут пересылать почту
через ваш сервер электронной почты.
Конфигурация fetchmail
В
этой схеме используется несколько иной способ
получения почты с почтового сервера провайдера:
программа fetchmail
получает сообщения из общей почтовой очереди на
сервере электронной почты провайдера.
С
этой целью в fetchmail
используется команда ETRN,
описанная в лекции 5. Таким образом, сама
программа fetchmail
не получает никаких сообщений с сервера
электронной почты, она лишь указывает почтовому
серверу провайдера инициировать новое SMTP-соединение
в обратном направлении и завершает свою работу.
В листинге 13.8 представлен пример файла
.fetchmailrc,
который используется для вызова почтового
сервера провайдера с помощью команды
ETRN.
1 poll mail.isp.net
with proto ETRN
2 localdomains smallorg.org
3 no dns
4 no envelope
Листинг 13.8.
Пример файла .fetchmailrc для вызова
почтового сервера
В
строке 1 листинга 13.8 указан удаленный сервер,
к которому необходимо подключаться. При этом
программа fetchmail
должна выдать команду
ETRN, чтобы началась передача почты от
почтового сервера провайдера на локальный
почтовый сервер. В строке 2 указано
альтернативное имя домена, на который почтовый
сервер под управлением ОС Linux будет принимать
почту. Следует заменить это имя на
зарегистрированное вашей организацией доменное
имя. В строках 3 и 4 указывается, что в
fetchmail не
используется проверка подлинности доменных имен
с помощью DNS, а также игнорируются поля
X-Recieve-To: в
заголовках формата RFC 822.
Автоматизация получения
почты
Как и в предыдущей схеме, необходимо обеспечить
запуск fetchmail
через равные интервалы времени для проверки
наличия почты на сервере провайдера. Проще всего
воспользоваться стандартной для ОС Linux
утилитой cron. Для
задания времени и частоты запуска
fetchmail создайте
cron-таблицу для пользователя
root, аналогичную
приведенной в листинге 13.7. Каждый раз при
запуске программы
fetchmail программа
diald будет
инициировать установку РРР-соединения с сервером
электронной почты провайдера.
Коммутируемое
UUCP-соединение с использованием почтовой
очереди на сервере провайдера
В
последней схеме, которую мы рассмотрим, в
качестве протокола для установки соединения с
почтовым сервером провайдера используется
протокол UUCP. Работа по этой схеме предполагает
накопление исходящих сообщений в очереди UUCP на
почтовом сервере под управлением ОС Linux и
дальнейшую их передачу при установлении UUCP-соединения.
Точно так же вся почта, адресованная на ваш
почтовый сервер, накапливается в очереди на
сервере провайдера и передается при наличии
UUCP-соединения на ваш почтовый сервер. На рис.
13.5 представлена схема обмена почтой при работе
по UUCP-соединению.
Рис. 13.5. Схема работы почтового
сервера под управлением ОС Linux с
использованием коммутируемого UUCP-соединения и
почтовой очереди на сервере провайдера
Настройка UUCP-соединения
Очевидно, что для подключения вашего почтового
сервера на базе ОС Linux к серверу провайдера
Internet по протоколу UUCP на нем должно быть
установлено программное обеспечение для работы с
UUCP. Стандартным пакетом для работы с UUCP на
платформе Linux является программный пакет
Taylor UUCP. В большинство дистрибутивов ОС
Linux он входит в виде бинарного пакета, который
легко установить на своем сервере. В Mandrake
Linux 6.0 этот пакет представлен в виде файла
uucp-1.06.1-10mdk.i586.rpm. Для его
установки можно использовать стандартную
программу rpm.
Если же в имеющейся у вас версии Linux
отсутствуют программные пакеты для работы с
UUCP, можно получить исходный код таких программ
на сервере
sunsite.unc.edu в каталоге
/pub/linux/systems/network/uucp.
В настоящее время доступен файл
uucp-1.05.tar.gz,
где содержится программное обеспечение для
работы с UUCP. В лекции 9, "Протокол UUCP", вы
найдете подробные инструкции о том, как
скомпилировать исходный код и установить этот
пакет на своем сервере.
После того как вы установите программный пакет
Taylor UUCP, его необходимо сконфигурировать для
работы с сервером UUCP провайдера. Все настройки
в пакете Taylor UUCP осуществляются в четырех
файлах конфигурации. Обычно эти файлы находятся
в каталоге /etc/uucp.
Первый их них — файл
config — определяет имя узла для
локального почтового сервера на базе ОС Linux. В
листинге 13.9 приведен пример этого файла
конфигурации.
nodename smallorg
Листинг 13.9.
Пример файла config для Taylor UUCP
Следующий файл, необходимый для работы UUCP, —
файл sys. В файле
sys описываются
все удаленные UUCP-узлы, с которыми ваш почтовый
сервер может устанавливать UUCP-соединение. В
нашем случае достаточно указать сервер UUCP
провайдера. В листинге 13.10 приведен пример
файла sys.
1 system ispmail
2 time Any
3 phone 555-1234
4 port modem
5 speed 38400
6 chat ogin: rich word: guitar
Листинг 13.10.
Пример файла sys для Taylor UUCP
В
строке 1 листинга 13.10 описывается удаленный
узел UUCP, с которым ваш почтовый сервер буде
поддерживать связь. Вы должны заменить это имя
на имя сервера UUCP вашего провайдера. В строке
2 задается время суток, когда разрешена
установка соединения. Так, например, в нашем
случае нет ограничений по времени, т.е. серверы
могут соединяться в любое время. В строке 3
указывается номер телефона, по которому вы
будете вызывать сервер провайдера. Этот номер
также нужно заменить на тот, что укажет
провайдер. В строке 4 указывается ссылка на файл
port, который
используется при установлении соединения. В
строке 5 определяется скорость обмена данными.
Строка 6 определяет последовательность
chat при
регистрации на сервере UUCP провайдера. Эти
данные также следует получить у своего
провайдера.
На
третий файл конфигурации имеется ссылка в файле
sys. Как вы уже
догадались, это файл port.
В этом файле описываются параметры портов и
модемов, которые могут применяться в пакете
Taylor UUCP для установки UUCP-соединения. В
листинге 13.11 приведен пример файла
port.
1 port modem
2 type modem
3 device /dev/ttyS1
4 speed 38400
5 dialer normal
Листинг 13.11.
Пример файла port для Taylor UUCP
В
строке 1 листинга 13.11 определяется имя порта,
на который имеется ссылка в файле
sys. В строке 2
определяется тип порта, используемого при
установке UUCP-соединения. В нашем случае при
подключении к удаленному серверу UUCP
используется модем. В строке 3 определяется имя
устройства, к которому подключен модем. В нашем
случае модем подключен к устройству
ttyS1, что
означает второй последовательный порт на
сервере. В строке 4 указывается скорость обмена
данными с модемом, а в строке 5 —режим дозвона
из файла dial,
который используется для связи с модемом.
И
последний файл конфигурации UUCP —
dial. Файл
dial используется
в сценарии для обмена данными с модемом и при
установлении соединения с удаленным сервером
UUCP. В листинге 13.12 приведен пример этого
файла.
1 dialer normal
2 chat "" ATZ OK ATDT\T CONNECT
Листинг 13.12.
Пример файла dial для Taylor UUCP
В
строке 1 листинга 13.12 описывается режим
дозвона, указанный в файле
port. В строке 2
представлен сценарий chat
для соединения с удаленным сервером UUCP.
Переменная \T
используется для вставки номера телефона,
указанного в файле sys.
После создания файлов конфигурации для Taylor
UUCP необходимо установить UUCP-соединение с
сервером UUCP провайдера. Для этого
воспользуйтесь командой:
/usr/sbin/uucico -s
ispmail,
где ispmail — имя
узла UUCP провайдера. После ввода этой команды
модем дозванивается на сервер UUCP провайдера и
устанавливает с ним соединение по протоколу
UUCP. Если сообщений для передачи нет, то
соединение должно быть сразу же разорвано. Все
сеансы работы UUCP должны заноситься в файл
отчета log,
соответствующий вашему дистрибутиву ОС Linux. В
Mandrake Linux файл отчета о работе UUCP
находится в /var/log/uucp/Log.
Конфигурация sendmail
Конфигурация программы sendmail для работы по
рассматриваемой схеме почти не отличается от
двух предыдущих. Поскольку при работе с UUCP
локальный почтовый сервер не получает прямого
соединения с сетью Internet, то для доставки
исходящих сообщений необходимо использовать
интеллектуальный хост. Единственное отличие этой
схемы подключения от предыдущих заключается в
том, что почтовый сервер должен соединяться с
интеллектуальным хостом по протоколу UUCP.
Обратите внимание, что и в данном случае
программа sendmail должна обеспечить отправку
сообщений от пользователей локальной сети. В
листинге 13.13 представлен пример файла макросов,
из которого можно получить полнофункциональный
файл sendmail.cf.
1 divert(-1)
2 divert(0)dnl
3 include('/usr/lib/sendmail-cf/m4/cf.m4')dnl
4 OSTYPE('linux')dnl
5
6 FEATURE('allmasquerade')dnl
7 FEATURE('masquerade_envelope')dnl
8 FEATURE('local_procmail', '/usr/bin/procmail')dnl
9 FEATURE('access_db', '/etc/mail/access.db')dnl
10 FEATURE('nocanonify')dnl
11
12 MAILER('smtp')dnl
13 MAILER('procmail')dnl
14 MAILER('uucp')dnl
15
16 MASQUERADE_AS('smallorg.org')dnl
17 define('SMART_HOST', 'uucp-dom:ispmail')dnl
Листинг 13.13.
Пример файла макросов для работы по UUCP
Как видите, строки 1–13 листинга 13.13 полностью
совпадают со строками файлов макросов для двух
предыдущих схем подключения. В строке 14
sendmail указывается, что при выполнении своих
функций она должна использовать протокол UUCP. В
строке 17 определяется интеллектуальный хост
ispmail,
подключение к которому осуществляется с помощью
протокола uucp-dom.
Это специальный формат протокола UUCP,
используемый программой sendmail для передачи
почты по протоколу UUCP с сохранением SMTP-заголовков
сообщений.
После этого, как и в предыдущих случаях,
программу sendmail следует запустить в фоновом
режиме. Для того чтобы программа sendmail
запускалась при загрузке системы, воспользуйтесь
программой linuxconf,
окно которой приведено на рис. 13.2.
Автоматизация получения
почты
Автоматизация процесса получения почты
заключается в том, что UUCP-соединение
необходимо устанавливать через определенные
интервалы времени в течение суток. Как и прежде,
для этой цели используется утилита
cron, с помощью
которой запускается сценарий установки UUCP-соединения
с сервером UUCP провайдера Internet. Для задания
сценариев, выполняемых утилитой
cron, используйте
программу crontab.
В
таблице cron для
запуска через определенные интервалы времени
следует задать два сценария. Во-первых, в ней
нужно задать программу
uucico. Эта программа используется для
вызова удаленного узла UUCP. Укажите программе
вызывать удаленный хост UUCP несколько раз в
сутки. Можно даже вручную создать файл запроса в
очереди UUCP на вашем сервере, что вынудит
uucico вызвать
сервер UUCP провайдера. Этот файл можно создать
непосредственно перед запуском программы
uucico. Завершив
работу, программа uucico
удаляет файл из очереди. В листинге 13.14
представлены файлы сценариев, согласно которым
осуществляется вызов сервера UUCP провайдера.
14,29,44,59 * * * * /usr/sbin/touch/var/spool/uucp/ispmail/C./C.ispmailA0000
0,15,30,45, * * * * /usr/sbin/uucico -s
ispmail
Листинг 13.14.
Пример файла cron для работы по UUCP
Первая строка указывает на файл вызова
удаленного хоста UUCP
ispmail. Вы можете заменить имя узла UUCP
на имя сервера UUCP провайдера, чтобы получить
файл вызова для вашей почтовой системы на базе
ОС Linux. При запуске
uucico в качестве параметра также следует
указать имя узла UUCP, т.е. сервер UUCP
провайдера.
При такой настройке почтовый сервер на базе ОС
Linux будет вызывать сервер UUCP провайдера
каждые 15 минут в течение суток. Если вы платите
провайдеру за работу по UUCP, то, возможно, вам
придется сделать несколько записей в
cron-таблице: одну с частыми интервалами в
бизнес-время (с 9 до 18) и вторую с менее
частыми интервалами вызова (в нерабочее время).
При использовании такой схемы почта собирается и
при наличии UUCP-соединения передается одним
пакетом. Почта, принимаемая от пользователей
локальной сети по протоколу SMTP, также
собирается и передается затем пакетами на
интеллектуальный хост. Почта, принимаемая для
вашего домена из сети Internet, хранится в UUCP-очереди
на почтовом сервере провайдера и передается на
ваш локальный сервер электронной почты при
наличии UUCP-соединения.
Резюме
В
этой лекции нами рассмотрены вопросы, которые
администратор почтовой системы должен решить
перед установкой почтового сервера. Существует
несколько путей реализации хостинга доменных
имен, хостинга почты и подключения к провайдеру
Internet. Здесь также рассмотрены четыре
основные схемы обмена почтой через сервер
электронной почты провайдера между локальным
почтовым сервером на базе ОС Linux и сетью
Internet. Для получения и отправки почты в
режиме реального времени желательно использовать
выделенное соединение с сетью Internet. Работа
по коммутируемым линиям также может обеспечить
быструю доставку электронной почты, но прием
сообщений происходит с некоторой задержкой,
поскольку сообщения помещаются в очередь на
сервере провайдера и поступают на локальный
почтовый сервер лишь через определенные
промежутки времени. Однако такая схема
подключения обходится намного дешевле, чем
выделенное соединение. Еще одна схема
подключения почтового сервера к сети Internet
основана на применении протокола UUCP в качестве
транспортного протокола для электронной почты.
Для передачи между узлами сети по протоколу UUCP
входящие и исходящие сообщения собираются в
пакеты. Часто для небольших организаций
поддержка UUCP-соединения — оптимальный вариант
для работы с большими объемами почты из сети
Internet. Иногда работа по протоколу UUCP
оказывается самым дешевым способом подключения к
сети Internet.
|