voliuf.narod.ru

главная

друзья

помощь сайту

Администрирование почтовых серверов sendmail  

Бесплатные учебники по темам

Партнерская программа

1.Принципы организации систем электронной почты

2.Использование ОС Linux в качестве сервера электронной почты

3.Установка телекоммуникационного оборудования в ОС Linux

4.DNS и доменные имена

5.Протокол SMTP

6.Протокол POP3

7.Протокол IMAP

8.Протокол РРР

9.Протокол UUCP

10.Программа sendmail

11.Установка и конфигурирование sendmail

12.Установка и конфигурирование POP3 и IMAP

13.Подключение почтового сервера к провайдеру Internet

14.Администрирование почтового сервера

15.Конфигурирование клиентов ЛВС

16.Поддержка удаленных клиентов

17.Почтовые псевдонимы и преобразование адресов

18.Списки рассылки

19.Маршрутизация IP в ОС Linux

 

Администрирование почтовых серверов sendmail 
13.Подключение почтового сервера к провайдеру Internet
  

Провайдеры сети 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 представлена схема работы сети такой конфигурации.

 

 

Схема работы почтового сервера под управлением ОС Linux с Internet по выделенной линии

Рис. 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 во время начальной загрузки.

 

 


 

 

 

 


 

 

 

 

Окно конфигурации программы linuxconf

Рис. 13.2.  Окно конфигурации программы linuxconf

 

 

Коммутируемое РРР-соединение с использованием одного почтового ящика на почтовом сервере провайдера

Такая схема часто применяется в небольших компаниях, которые либо не могут себе позволить в силу определенных причин круглосуточный доступ к Internet, либо просто не нуждаются в нем. При работе по коммутируемому РРР-соединению локальный почтовый сервер через заданные интервалы времени (например, один раз утром, один раз вечером) вызывает сервер как при наличии исходящей почты, так и для проверки наличия входящих сообщений. Кроме того, провайдер конфигурирует свой почтовый сервер таким образом, чтобы вся почта, адресованная пользователям домена, поступала в один почтовый ящик. Затем с помощью программы fetchmail локальный почтовый сервер получает почту из ящика на сервере провайдера и распределяет ее соответствующим пользователям на своем почтовом сервере. На рис. 13.3 представлена схема работы такой системы.

 

 

Схема работы почтового сервера под управлением ОС Linux с использованием коммутируемого РРР-соединения и одного почтового ящика на сервере провайдера Internet

Рис. 13.3.  Схема работы почтового сервера под управлением ОС Linux с использованием коммутируемого РРР-соединения и одного почтового ящика на сервере провайдера Internet

 

 

Настройка РРР-соединения

Конфигурирование коммутируемого РРР-соединения имеет много общего с настройкой выделенного РРР-соединения. Единственное отличие в работе коммутируемого и выделенного соединения состоит в том, что РРР-соединение устанавливается только в том случае, когда локальному почтовому серверу необходима связь с сервером провайдера, и завершается после окончания сеанса связи с сервером провайдера. Для установки и завершения РРР-соединения в ОС Linux используется программа diald. С ее помощью можно запускать и останавливать работу программы pppd, описанной в предыдущем разделе.

 

Если в имеющейся у вас версии ОС Linux отсутствует бинарный файл программы diald, то его можно получить через Internet по адресу: http://diald.unix.ch. На момент написания книги текущей версией diald была версия diald-0.99. Для установки программы diald на вашем компьютере следует выполнить следующее.

 
  • Распаковать архив с исходными файлами:
    tar -zxvf diald-0.99.tar.gz
  • Перейти в созданный после распаковки diald-0.99 каталог:
    cd diald
  • Запустить программу GNU make с параметром depend:
    make depend
  • Запустить программу GNU make без параметров для компиляции:
    make
  • С правами пользователя root запустить программу GNU make с параметром install:
    make install
 

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

 

 

Схема работы почтового сервера под управлением ОС Linux с использованием коммутируемого 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.

 
Автор: Р. Блам  источник: http://www.INTUIT.ru 


 

13 центов(0,13$) за клик, выплаты через WebMoney каждый вторник +10% с рефералов

Мы выкупаем 100% трафа! $12 за 1000 хостов (РФ), и до $4 за 1000 хостов (зарубежный траф) + 10% с дохода Ваших рефералов!
 Выплаты через
WebMoney

~80-100$ за1000 хостов 2.5$ за 1 смс.
реф. процент - 10 %Выплаты происходят раз в неделю, в четверг на
WebMoney
 
 

 

____________________________

Посмотреть порно видео в онлайне »

_______________________________

 

   
   
Сайт управляется системой uCoz