Запуск новой почтовой программы



Как только вы все настроили, потребуется или уничтожить процесс sendmail, который уже не нужен и запустить новую почтовую программу, или просто перегрузить систему. Перезагрузка также даст вам возможность проверить, правильно ли настроена система для автоматического запуска MTA при загрузке.

Поиск и устранение неисправностей

1. Почему я должен использовать FQDN для хостов вне моей подсети?

Вы, видимо, обнаружили, что хост, к которому вы обратились, оказался на самом деле в другом домене; например, если вы находитесь в домене foo.bar.edu и хотите обратиться к хосту mumble в домене bar.edu, то должны указать его полное доменное имя, mumble.bar.edu, а не просто mumble.

Традиционно, программа разрешения имен BSD BIND позволяла это делать. Однако, текущая версия BIND, поставляемая с FreeBSD, больше не добавляет имена доменов, отличающихся от того, в котором вы находитесь, для не полностью указанных имен хостов. То есть, имя mumble будет опознан как mumble.foo.bar.edu или будет искаться в корневом домене.

Это отличается от предыдущего поведения, при котором поиск продолжался в доменах mumble.bar.edu и mumble.edu. Если вам интересны причины объявления такого поведения плохой практикой и даже ошибкой в безопасности, обратитесь к RFC 1535.

Хорошим решением будет поместить строку

search foo.bar.edu bar.edu

 вместо ранее используемой:

domain foo.bar.edu

 в файл /etc/resolv.conf. Однако удостоверьтесь, что порядок поиска не нарушает ''границ полномочий между локальным и внешним администрированием'', в терминологии RFC 1535.

2. sendmail выдает ошибку mail loops back to myself

В FAQ по sendmail дан следующий ответ:

Я получаю такие сообщения об ошибке:

 

553 MX list for domain.net points back to relay.domain.net

554 <user@domain.net>... Local configuration error

 

Как можно решить эту проблему?

 

Согласно записям MX, почта для домена domain.net перенаправляется на хост

relay.domain.net, однако последний не распознается как

domain.net. Добавьте domain.net в файл

/etc/mail/local-host-names

[известный как /etc/sendmail.cw до версии 8.10]

(если вы используете

FETURE(use_cw_file)) или добавьте ''Cw domain.net'' в файл

/etc/mail/sendmail.cf.

FAQ по sendmail можно найти на http://www.sendmail.org/faq/ и рекомендуется прочесть его при желании произвести некоторые ''усовершенствования'' настроек почтовой системы.

3. Как организовать работу почтового сервера при коммутируемом соединении с Интернет?

Вы хотите подключить к интернет компьютер с FreeBSD, работающий в локальной сети. Компьютер с FreeBSD будет почтовым шлюзом для локальной сети. PPP соединение не выделенное.

Существует как минимум два пути, чтобы сделать это. Один способ это использование UUCP.

Другой способ это использование постоянно работающего интернет сервера для обеспечения вторичного MX сервиса вашего домена. Например, домен вашей компании example.com, и провайдер интернет настроил example.net для обеспечения вторичного MX сервиса:

example.com.     MX   10 example.com.

                 MX   20 example.net.

Только один хост должен быть указан в качестве последнего получателя (добавьте запись Cw example.com в файл /etc/mail/sendmail.cf на машине example.com).

Когда программа sendmail (со стороны отправителя) ''захочет'' доставить почту, она попытается соединиться с вашим хостом (example.com) через модемное подключение. Скорее всего, ей это не удастся (вы, вероятнее всего, не будете подключены к интернет). Программа sendmail автоматически перейдет ко вторичному MX серверу, т.е. вашему провайдеру (example.net). Вторичный MX сервер будет периодически пытаться соединиться с вашим хостом и доставить почту на основной сервер MX (example.com).

Вы можете воспользоваться следующим сценарием, чтобы забирать почту каждый раз, когда вы входите в систему:

#!/bin/sh

# Put me in /usr/local/bin/pppmyisp

( sleep 60 ; /usr/sbin/sendmail -q ) &

/usr/sbin/ppp -direct pppmyisp

Если же вы хотите написать отдельный пользовательский скрипт, лучше воспользоваться командой sendmail -qRexample.com вместо вышеприведенного сценария, так как в этом случае вся почта в очереди для хоста example.com будет обработана немедленно.

Рассмотрим эту ситуацию подробнее:

Вот пример сообщения из freebsd-isp (http://lists.FreeBSD.org/mailman/listinfo/freebsd-isp).

> Мы предоставляем вторичный MX для наших клиентов. Вы соединяетесь

> с нашим сервером несколько раз в день, чтобы забрать почту для вашего

> первичного (главного) MX (мы не соединяемся с ним каждый раз, когда

> приходит новая почта для его доменов). Далее, sendmail отправляет

> почту, находящуюся в очереди каждые 30 минут, и клиент должен быть

> подключен к Интернет в течении 30 минут, чтобы удостовериться, что

> вся почта ''ушла'' на основной MX-сервер.

>

> Может быть, есть какая-либо команда, которая заставит sendmail

> немедленно отправить все почту, находящуюся в очереди? Естественно,

> пользователи не обладают какими-либо повышенными привилегиями на

> нашем сервере.

 

В разделе ''privacy flags'' файла

sendmail.cf, определяется опция

Opgoaway,restrictqrun

 

Уберите restrictqrun, чтобы разрешить рядовым

пользователям инициировать работу с очередью. Вам также может понадобиться

изменить порядок MX-серверов. Так, если вы предоставляете первый (основной)

MX-сервер для ваши пользователей, мы указываем:

 

# If we are the best MX for a host, try directly instead of generating

# local config error.

OwTrue

 

Таким образом, удаленный хост будет доставлять почту непосредственно к вам,

не пытаясь установить соединение с клиентом. Затем уже вы, в свою очередь,

отсылаете ее клиенту. Удостоверьтесь, что в DNS есть записи про

''customer.com'' и ''hostname.customer.com''. Просто

добавьте запись A в DNS для ''customer.com''.

4. Почему я продолжаю получать ошибки Relaying Denied при отправки почты через другие хосты?

В установке FreeBSD по умолчанию, sendmail настроен для отправки почты только от хоста, на котором он работает. Например, если доступен POP сервер, пользователи смогут проверять почту из школы, с работы или других удаленных точек, но не смогут отправлять письма. Обычно, через некоторое время после попытки будет отправлено письмо от MAILER-DAEMON с сообщением об ошибке 5.7 Relaying Denied.

Есть несколько путей разрешения этой ситуации. Самый прямой путь это использование адреса вашего провайдера в файле relay-domains, расположенном в /etc/mail/relay-domains. Быстрый способ сделать это:

# echo "your.isp.example.com" > /etc/mail/relay-domains

После создания или редактирования этого файла вы должны перезапустить sendmail. Это отлично работает, если вы администратор сервера и не хотите отправлять почту локально, или хотите воспользоваться почтовым клиентом/системой на другом компьютере или даже через другого провайдера. Это также очень полезно, если у вас настроены одна или две почтовые записи. Если необходимо добавить несколько адресов, вы можете просто открыть этот файл в текстовом редакторе и добавить домены, по одному на строку:

your.isp.example.com

other.isp.example.net

users-isp.example.org

www.example.org

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

Расширенное руководство

В следующем разделе рассматриваются более сложные темы, такие как настройка почты и включение почтовой системы для всего домена.

Базовая конфигурация

Изначально, вы можете отправлять почту ''во внешний мир'' если правильно составлен файл /etc/resolv.conf или запущен свой сервер имен. Если вы хотите, чтобы почта, предназначенная для хоста в вашем домене, доставлялась MTA (например, sendmail) на вашем хосте FreeBSD, есть два пути:

• Запустите свой собственный сервер DNS, тем самым организовав собственный домен, например, FreeBSD.org

• Получайте почту для вашего хоста непосредственно. Это работает при доставке почты непосредственно на DNS имя вашей машины. Например, example.FreeBSD.org.

Независимо от выбранного из предложенных выше вариантов, для доставки почты непосредственно на ваш хост у него должен быть постоянный IP адрес (а не динамический, как у большинства PPP соединений). Если вы находитесь за брандмауэром, то последний должен пропускать SMTP-пакеты. Если вы хотите, чтобы почта приходила непосредственно на ваш хост, необходимо убедиться в одном из двух:

• Убедитесь, что запись (с наименьшим номером) MX в DNS соответствует IP адресу вашего хоста.

• Убедитесь, что в DNS для вашего хоста вообще отсутствует MX-запись.

Выполнение любого из перечисленных условий обеспечит доставку почты для вашего хоста.

Попробуйте это:

# hostname

example.FreeBSD.org

# host example.FreeBSD.org

example.FreeBSD.org has address 204.216.27.XX

Если вы это видите, то можно без проблем посылать почту на <yourlogin@example.FreeBSD.org> (предполагается, что sendmail на example.FreeBSD.org работает правильно).

Однако, если вы видите это:

# host example.FreeBSD.org

example.FreeBSD.org has address 204.216.27.XX

example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org

то вся почта, посланная на example.FreeBSD.org будет собираться на hub (для того же пользователя), вместо того, чтобы быть отосланной непосредственно на ваш хост.

Эта информация обрабатывается вашим DNS сервером. Соответствующая запись DNS, указывающая, через какой хост будет проходить ваша почта, называется MX (Mail eXchanger). Если для хоста отсутствует такая запись, почта будет приходить прямо на этот хост.

Допустим, что запись MX для хоста freefall.FreeBSD.org в какой-то момент выглядела так:

freefall         MX 30 mail.crl.net

freefall           MX 40 agora.rdrop.com

freefall           MX 10 freefall.FreeBSD.org

freefall           MX 20 who.cdrom.com

Вы видите, что для хоста freefall существуют несколько MX-записей. Запись с наименьшим номером соответствует хосту, получающему почту непосредственно, если он доступен; если он недоступен по каким-то причинам, другие сервера (иногда называемые (''резервными MX'') временно получают почту, и хранят ее пока не станут доступны хосты с меньшими номерами, в конечном итоге отправляя почту на эти хосты.

Чтобы альтернативные MX-хосты использовались наиболее эффективно, они должны быть независимо подключены к Интернет. Ваш провайдер (или дружественный сайт) скорее всего без проблем сможет оказать подобные услуги.

Почта для вашего домена

Для настройки ''почтового хоста'' (почтовый сервер) вам потребуется, чтобы почта, направляемая различным рабочим станциям, пересылалась этому хосту. Обычно вам необходима доставка всей почты для любого хоста вашего домена (в данном случае *.FreeBSD.org) на почтовый сервер, чтобы пользователи могли получать свою почту на с этого сервера.

Чтобы облегчить себе (и другим) жизнь, создайте на обеих машинах учетные записи с одинаковыми именами пользователей, например, с помощью команды adduser(8).

Сервер, который вы будете использовать в качестве почтового, должен быть объявлен таковым для каждой машины в домене. Вот фрагмент примерной конфигурации:

example.FreeBSD.org   A  204.216.27.XX      ; Рабочая станция

                   MX 10 hub.FreeBSD.org ; Почтовый шлюз

Таким образом, вся корреспонденция, адресованная рабочей станции, будет обрабатываться вашим почтовым сервером, независимо от того, что указано в A-записи.

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

Если вы хотите поддерживать несколько виртуальных почтовых серверов, может пригодиться следующая информация. Допустим, что ваш клиент зарезервировал домен, например, customer1.org, и вам требуется, чтобы почта, предназначенная для customer1.org приходила на ваш хост, например, mail.myhost.com. В таком случае, DNS должен выглядеть так:

customer1.org      MX 10 mail.myhost.com

Заметьте, что если вам требуется только получать почту для домена, соответствующая A-запись не нужна.

Замечание: Помните, что если вы попытаетесь каким-либо образом обратиться к хосту customer1.org, у вас вряд ли что-либо получится, если нет A-записи для этого хоста.

Последнее, что вы должны сделать – это сказать программе sendmail, для каких доменов и/или хостов она должна принимать почту. Это можно сделать несколькими способами:

• Добавьте названия этих хостов в файл /etc/mail/local-host-names, если вы используете FEATURE(use_cw_file). Если у вас sendmail версии ниже 8.10, необходимо отредактировать файл /etc/sendmail.cw.

• Добавьте строку Cwyour.host.com в файл /etc/sendmail.cf или /etc/mail/sendmail.cf (если у вас sendmail версии 8.10 или более поздней).

SMTP через UUCP

Настройка поставляемого с FreeBSD sendmail предназначена для сайтов, подключенных к интернет непосредственно. Сайты, осуществляющие обмен почтой через UUCP, должны использовать другой файл настройки sendmail.

Редактирование /etc/mail/sendmail.cf вручную это сложная задача. sendmail версии 8 генерирует файлы настройки через препроцессор m4(1), реально настройка выполняется на более высоком уровне абстракции. Файлы настройки m4(1) можно найти в /usr/share/sendmail/cf. Файл README в каталоге cf содержит введение в основы настройки m4(1).

Лучшим способом настройки поддержки передачи по UUCP является использование возможности mailertable. При этом создается база данных, которая помогает sendmail решать вопросы маршрутизации.

Во-первых, создайте файл .mc. В каталоге /usr/share/sendmail/cf/cf находятся несколько примеров. Возьмем для примера имя файла foo.mc. Все, что потребуется для преобразования его в sendmail.cf, это:

# cd /etc/mail

# make foo.cf

# cp foo.cf /etc/mail/sendmail.cf

Типичный .mc файл может выглядеть примерно так:

VERSIONID(`Your version number') OSTYPE(bsd4.4)

 

FEATURE(accept_unresolvable_domains)

FEATURE(nocanonify)

FEATURE(mailertable, `hash -o /etc/mail/mailertable')

 

define(`UUCP_RELAY', your.uucp.relay)

define(`UUCP_MAX_SIZE', 200000)

define(`confDONT_PROBE_INTERFACES')

 

MAILER(local)

MAILER(smtp)

MAILER(uucp)

 

Cw your.alias.host.name

Cw youruucpnodename.UUCP

Строки, содержащие accept_unresolvable_domains, nocanonify, и confDONT_PROBE_INTERFACES, предотвратят использование DNS для доставки почты. Пункт UUCP_RELAY необходим для поддержки доставки по UUCP. Просто поместите сюда имя хоста в интернет, способного работать с .UUCP адресами псевдо-доменов; скорее всего, вы введете сюда основной сервер пересылки почты провайдера.

Как только вы сделаете это, потребуется файл /etc/mail/mailertable. Если вы используете для всей почты только одно внешнее соединение, подойдет следующий файл:

#

# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable

.                        uucp-dom:your.uucp.relay

Более сложный пример может выглядеть так:

#

# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable

#

horus.interface-business.de uucp-dom:horus

.interface-business.de   uucp-dom:if-bus

interface-business.de    uucp-dom:if-bus

.heep.sax.de             smtp8:%1

horus.UUCP               uucp-dom:horus

if-bus.UUCP              uucp-dom:if-bus

.                        uucp-dom:

В первых трех строках обрабатываются специальные случаи, когда почта для домена должна отправляться не на маршрут по умолчанию, а на ближайшее соединение UUCP для сокращения пути доставки. Следующая строка обрабатывает почту, которая может быть доставлена по SMTP для локального Ethernet домена. Наконец, определены маршруты UUCP в нотации псевдо-доменов .UUCP, для включения перезаписи правил по умолчанию правилом uucp-neighbor !recipient. Последняя строка всегда содержит одиночную точку, означающую ''все остальное'', с отправкой через UUCP, являющимся универсальным почтовым шлюзом. Все имена узлов после ключевого слова uucp-dom: должны представлять существующие маршруты UUCP, проверить их можно с помощью команды uuname.

Напоминаем, что этот файл должен быть преобразован в базу данных DBM перед использованием. Командную строку для этой задачи лучше всего поместить в качестве комментария в верхней части файла mailertable. Всегда выполняйте эту команду после правки файла mailertable.

И наконец: если вы не уверены, что некоторые отдельные почтовые маршруты будут работать, запомните параметр sendmail -bt. С этим параметром sendmail запускается в режиме тестирования адреса; просто введите 3,0 и адрес, который вы хотите протестировать. В последней строке появится сообщение об используемом внутреннем почтовом агенте, хосте назначения, с которым вызывается этот агент, и (возможно транслированный) адрес. Выход из этого режима происходит при нажатии Ctrl+D.

% sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

> 3,0 foo@example.com

canonify      input: foo @ example . com

...

parse       returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . >

> ^D


Дата добавления: 2018-10-26; просмотров: 177; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!