Введение в синтаксис sendmail.cf

[Карта] [Начало] [Sendmail-ссылки] [Синтаксис] [Типовые задачки] [Задачки по маршрутизации] [Задачки по макарадингу] [SendmailACL] [Spamooborona] [VadeRetro] [Regex] [Тонкости] [Недок.особен.] [Несущ.юзеры] [Прячемся!] [RFC1893.Цитаты] [ТП.Эмоции] [Антиспам&Разум]

Ввведение в синтаксис sendmail.cf.

Прежде чем вы начнете это читать, я должна вас предупредить: я не sendmail-гуру, многие вещи понимаю интуитивно, объясняю так, как понимаю сама, возможно, и неверно. В общем, я предупредила. Да, специально для тех, кто упрекает меня в том, что я пишу "вроде по-русски, но явно не для русских", сообщаю: этот язык для меня не родной, поэтому пишу так, как умею, и лучше (понятнее) не могу.

А теперь то, с чего и нужно было начинать sendmail-раздел.
Скажу сразу, в Сети нет материалов, подробно объясняющих синтаксис sendmail.cf.
Начать можно с этого:

Пособие по установке и конфигурированию Sendmail (V.8.11) Перевод Плотникова А.С.

O'Reilly - Sendmail, 3rd Edition.

Все известные мне ссылки на этот труд: O'Reilly - Sendmail, 3rd Edition.

Полезно будет посмотреть здесь:

Сергей Вакуленко. Пример sendmail.cf на русском

Sendmail

Linux Network Administrators Guide.Глава 18. Sendmail. Интерпретация и написание правил переписки

Фильтры regex в sendmail - это не описание синтаксиса, но автор не поленился: описал практически каждую строку фильтра.

Владимир Петров Конфигурационный файл sendmail

08.05.2008. Почему я не увидела этого раньше? Здесь же все разжевано!! Мою лавочку можно закрывать ... Sendmail 8.8.7

То же самое

Если доведется быть в книжном магазине, поищите книгу Мохамеда Дж. Кабира "RH Linux Server". Нашли? Теперь открывайте стр. 215-237 и читайте. Покупать не нужно :)

Linux mail, sendmail, uucp. How to configure it fast, some samples, books

Лекция: Программа sendmail

То же самое. Лекция: Программа sendmail

Огромное количество всевозможных правил имеется на sendmail-овской конфе, некоторые из них даже с объяснениями.
Кроме того не помешает распечатать 5 главу "Полное описание файла конфигурации" ( [1] - перевод устаревшей версии, [2] - ссылки на текущую версию) документа "Sendmail Installation and Operation Guide" (/usr/src/sendmail/doc/op/op.me) и документ /usr/src/sendmail/cf/README. Когда я работаю с конфигом sendmail'a, эти документы у меня всегда перед глазами.

Ну и еще один мощный инструмент познания - syslog. Если вы не понимаете, как работает набор правил, то ставьте после каждого правила перезаписи вывод в лог, так вам станет понятно, что подавалось на вход, и что получилось на выходе. Лично я без syslog - как без рук. С тех пор как на sendmail-конфе увидела, как это делается, понимать правила стало гораздо легче. Почему я не использую для этого тестовый режим - sendmail -bt? Потому что некоторые вещи так не увидишь.

18.11.2008. ==Я очень и очень советую пользоваться родной документацией.
Чтобы не приходилось читать вот такие ляпы (кстати, ляпы и у меня бывают, спасибо, в частности, Владимиру Васильеву, который много чего подправил):
- "В большинстве дистрибутивов кроме самого почтового сервера, слушающего запросы на 25 порту, запускается дополнительный процесс sendmail — MSA (Агент подачи почты). Он предназначен для предварительной проверки и изменений в заголовках письма. По умолчанию он слушает запросы на 587 порту и, естественно, никакой аутентификации не поддерживает. " (Помилуйте, он в значительной мере и предназначен для использования локальными клиентами посредством smtp-авторизации!)
- Про cyrus-sasl:
"У этого способа есть один неприятный момент — Вам придется заносить всех пользователей, которые должны получать почту (при чем здесь "получать" (pop3/imap)? посылать (smtp)! ), в специальную базу данных. (Поправьте меня, я так и не понял как в Slackware заставить брать информацию о пользователях из /etc/passwd) "
(В Sendmail.conf: pwcheck_method: saslauthd, в /etc/sysconfig/saslauthd: SASLAUTHD_AUTHMECH=shadow)
Я ни в коей мере не хочу обидеть автора, тем более, что он преподаватель с большим стажем, но так и хочется повторить слова главной героини (ее сыграла безвременно ушедшая Ирина Метлицкая (лейкоз, 36 лет)) фильма "Черная вуаль":
"Господа! Читайте Достоевского. Там все написано."
Наткнулась на эту страницу случайно, править некогда, и пример этот приведен исключительно для того, чтобы намекнуть: использование вторичной документации по sendmail (в том числе и моего раздела) имеет смысл только в том случае, если вы уже ознакомились с родной документацией: README & op.me. Читайте первоисточники. Ведь "там все написано." ===

Итак, Sendmail.cf в стандартном виде состоит из множества наборов правил перезаписи, расположенных в определенном порядке.
На вход в эти правила подаются заранее определенные разаработчиками значения. Например,
в check_relay - ip-адрес и доменный адрес почтовика, установившего с вами соединение, в виде somehost.somedom.ru $| 1.2.3.4 в случае, если хост имеет доменное имя и в виде 1.2.3.4 $| 1.2.3.4- в противном случае;
в check_mail - адрес отправителя в виде < user@domain.ru >;
в check_rcpt - адрес получателя < user@domain.ru > и т.д.

Перечисленные выше наборы правил не рекомендуется редактировать напрямую, для этого в них предусмотрен вызов локальных наборов правил Local_check_relay, Local_check_mail, Local_check_rcpt, обычно пустых. Вот эти наборы и следует заполнять, если вам нужно поработать с адресом релея, адресами отправители или получателя.
Sendmail.cf составлен так, что локальный набор правил вызывается из основного, поэтому сначала исполняется локальный набор правил, например, Local_check_relay, и только потом основной набор, check_relay.
Когда вы пишете свои наборы правил, вы можете задать на входе какие угодно значения из внутренних макросов sendmail для дальнейшей обработки.

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

Любое правило состоит из левой(LHS, правило левой руки) и правой (RHS, правило правой руки) частей, разделенных знаком табуляции.
Соотносятся между собой левая и правая часть так же, как и условие и действие в классическом операторе условия IF:
если левая часть верна (возвращает значение TRUE), тогда исполняется правая часть.
Если левая часть возвращает FALSE, то происходит переход к следующей строке, т.е. следующему правилу.

Можно сказать, что все рулсеты sendmail.cf состоят только из операторов условия. Но на самом деле, все не так страшно :)
Простой оператор присваивания на языке sendmail.cf является прямым следствием (вытекает из) условного оператора:
условием является событие, которое произойдет при любых обстоятельствах.
Поясню на примере: присвоим макросу Test значение 1:
R$*                $: <$(storage {Test} $@ 1 $)>
Если рассматривать эту строку как условный оператор, то можно трактовать ее так: если на вход подано что угодно или не подано ничего вообще ($*), то следует исполнить команду storage, присвоив макросу Test значение 1.
Как видим, условие "если на вход подано что угодно или не подано ничего вообще" исполняется в любом случае, вне зависимости от того, подается ли на вход хоть какое-то значение, и, если подается, каково оно. То есть, это формальное условие или безусловное событие, событие, которое произойдет "при любой погоде". Поэтому это правило есть простое присвоение значения 1 макросу Test.
Кстати, если макросу Test нужно присвоить значение, которое было подано на вход, то нужно написать следующее:
R$*                $: <$(storage {Test} $@ $1 $)>
Ну, и если придраться к самой себе, то следует сказать, что storage - это не команда, а имя спец. преобразования.
Это имя (storage) дала я, а относится оно ко встроенному в sendmail типу преобразования macro, который "устанавливает или очищает значение макроса". И чтобы все было правильно, предварительно следует объявить вот такой строкой то, что мы будем использовать это спец. преобразование:
Kstorage macro

С этой же точки зрения можно взглянуть на "операторы выхода". Завершить работу рулсета раньше времени, т.е. не доходя до последнего правила, можно двумя способами:
R$*             $@ OK
Это правило завершает работу набора правил, возвращая в точку вызова значение OK (вместо OK может быть другое значение, например, $1 - то, что было подано на вход в это правило).
А вот следующее правило сообщит не только о необходимости завершения работы рулсета, но и о том, что адрес полностью разрешен, и , следовательно, необходимо вызвать определенный mailer. В sendmail.cf предусмотрен особый mailer error, который предназначен (но только в наборах правил 0, 5 и check_*) для генерации сообщений об ошибках.
R$*              $#error $@ 5.7.1 $:"554 Sorry, forged sender address."
Его отличие от первого оператора выхода в том, что , несмотря на то, что оставшиеся наборы правил все равно будут исполнены, письмо доставлено не будет, а релей отправителя на этапе smtp-диалога получит следующий отказ: "Sorry, forged sender address." Который и вернет отправителю.

10.06.2008. Небольшая тонкость (спасибо Владимиру Васильеву):
"...If the Local_check_relay rule set returns a #error or #discard delivery agent, the con- nection is rejected. If it returns a $#OK, the connection is accepted and subsequent check_relay rule set rules are skipped:
SLocal_check_relay
R $*               $# OK skip check_relay rule set rules
But if it returns a $@OK, further check_relay rule set rules are allowed which might themselves reject the connection:
SLocal_check_relay
R $*               $@ OK allow check_relay rule set rules..." ("Sendmail" Bryan Costales with Eric Allman)
Насколько я понимаю эта тонкость может использоваться в любом "поднаборе" правил, который вызывается из основного набора.
Посмотрим на рулсет check_relay
Scheck_relay
R$*               $: $1 $| $>"Local_check_relay" $1
R$* $| $* $| $#$*               $#$3
R$* $| $* $| $*               $@ $>"Basic_check_relay" $1 $| $2
Здесь видно, что, если из рулсета Local_check_relay возвращается любое значение, начинающееся на $#, то sendmail.cf должен или вернуть это значение(если это не команда) в точку вызова check_relay или исполнить команду, следующую за знаком #. А в рулсетах check_ этими командами могут быть только error, discard. Другими словами, если из созданного вами локального набора Local_check_relay возвращается значение #OK, то есть в Local_check_relay есть строка
R$*              $#OK
,то вот эта строка из основного набора
R$* $| $* $| $#$*               $#$3
позволяет сразу завершить работу набора check_relay, вернув в точку вызова значение OK.

Примеры.
В любом заголовке письма вы увидите подзаголовок (и не один) Received:
Received: from [194.67.45.248] (port=4964 helo=puma.mail.ru)
               by mx21.mail.ru with esmtp
               id 1I0zNV-0002nl-00
               for something@mail.ru; Wed, 20 Jun 2007 16:33:41 +0400

Проверить все Received: можно набором правил, мы назовем его CheckReceived.
Указываем, что подзаголовок Received: должен быть отправлен на проверку в набор правил CheckReceived.
HReceived:                $>+CheckReceived (про + объясню потом)
А вот и сам набор правил:
SCheckReceived
Если в подзаголовке Received присутствует домен outblaze.com, то блокируем такую почту.
R$+ outblaze.com $+               $#error $: "554 Sorry, you cannot send the letter."
$+ означает, что и слева и справа от шаблона outblaze.com _должен_ быть по крайней мере один произвольный символ.
$# приводит к немедленному завершению набора работы набора правил,
error означает, что будет сгенерирована ошибка, а в отлупе будет содержаться указанный нами текст.

Таким же образом вы можете проверить:

Tему письма HSubject: $>Check_Subject
SCheck_Subject
Блокируем любую тему, в которой содержится слово VIAGRA
R$* VIAGRA $* $#error $: "554 Sorry, you cannot send the letter."
$* означает, что и слева и справа от шаблона VIAGRA _могут_ быть произвольные символы.

Внутренний адрес получателя HTo: $>Check_To
SCheck_To
Блокируем письмо, если внутренним получателем указан адрес spamlist@mydomain.ru
Rspamlist@mydomain.ru $#error $: "554 Sorry, you cannot send the letter."
Внутренний получатель часто используется спамерами для заморачивания получателей письма, когда в этом поле указывается получатель, отличный от конвертного, а бедный настоящий получатель, завидев вас на горизонте, бросается к вам с возгласом "Мне приходят чужие письма!!!"

А что такое "внутренний получатель"?
Есть получатель конвертный(envelope reipient), он указывается отправителем в команде "RCPT TO:", и именно он прописывается в логе, а есть получатель внутренний, или, как его называет зарубежная sendmail-община, header recipient - это получатель, указанный после команды "DATA" в строке "To:". Это необязательный параметр и он может не совпадать с реальным адресом получателя.
Если он не указан отправителем, то в поле To: вы увидите либо свой адрес, либо какой-либо другой адрес, если отправитель указал ваш адрес в поле Bcc:
Но, если внутренний получатель указан отправителем, то именно его вы и увидите в поле "To:" при получении письма.
То же самое касается и адреса отправителя: есть конвертный(реальный) отправитель (этап "MAIL FROM:") и отправитель из подзаголовка From:
Пример. Есть 2 конкурирующие фирмы: "Елки-Палки" & "Палки-Елки". Вы - админ "Елок-Палок". В один прекрасный день некий злоумышленник проделывает следующее:

telnet mail.elki-palki.ru 25
MAIL FROM:somebody@somewhere.ru
RCPT TO:boss@elki-palki.ru
DATA
From:postmaster@elki-palki.ru
To: boss@palki-elki.ru
Subject: Продам секреты фирмы "Елки-Палки". Дорого.
.
Что теперь? А теперь ждите разборок.
Ваш шеф получил письмо (с весьма занимательной темой), адресованное якобы вами якобы шефу фирмы-конкурента.

Еще один показательный пример, теперь уже "литературный":
telnet yourdomain.ru 25
helo pushkinhost.yourdomain.ru
mail from: pushkin@yourdomain.ru
rcpt to: dantes@yourdomain.ru
DATA
From: martynov@yourdomain.ru
To: lermontov@yourdomain.ru
Subject:Challenging to a duel
.

Внутренний адрес отправителя
HFrom: $>Check_From
SCheck_From
Блокируем письмо, если внутренним получателем указан адрес spamlist@mydomain.ru
Rreklama@domain.ru $#error $: "554 Sorry, you cannot send the letter."

Список можно продолжить, например, я еще проверяю:

HCc: $>CheckTo

HMessage-ID: $>CheckMessageID
SCheckMessageID

H*: $>+CheckHeader
SCheckHeader

HX-MIMEOLE: $>+CheckMIMEOLE
SCheckMIMEOLE

Ну и венчает все это великолепие заключительная проверка check_eoh (это последний набор правил(end of headers), в нем рекомендуетcя делать проверку разных макросов, значения которых были определены в предыдущих наборах)
Краткое описание наборов правил можно посмотреть в разделе "5.1.4. Ловушки Наборов Правил" документа /usr/something/sendmail/doc/op.me из sendmail-дистрибутива.

Теперь, давайте для примера попробуем добавить вывод в лог в наборе правил Local_check_relay:
LOCAL_CONFIG
LOCAL_RULESETS
SLocal_check_relay
R$*                $: $(syslog syslog:check_relay: $1 $) $1

$* - рассматриваем все, что подано на вход;
$: означает, что следует перейти к следующему правилу после исполнения того, что указано после $: (в нашем случае это вывод в лог);
syslog:check_relay: - вывод в лог для удобства будет предваряться этой меткой (вдруг вы выводите в лог много чего, тогда данная метка позволит вам эффективно фильтровать инфу именно из этого набора правил).
$1 - распечатем в логе все, что было подано на вход.
Syslog, после того как отработает, на выходе не оставляет ничего, а ведь входные данные нам могут понадобиться в Local_check_relay дальше (но не в этом примере, здесь мы просто распечатали значение и на этом набор правил Local_check_relay завершил свою работу). Для того, чтобы данные не терялись добавляем еще один $1 .
Пересобираем конфиг, перезагружаем sendmail, смотрим лог:

Jun 20 17:36:01 apache sendmail[11674]: l5KBa1J0011674: syslog:check_relay:74-132-86-89.dhcp.insightbb.com\23374.132.86.89
Jun 20 17:36:01 apache sendmail[11674]: ruleset=check_relay, arg1=74-132-86-89.dhcp.insightbb.com, arg2=127.0.0.2, relay=74-132-86-89.dhcp.insightbb.com [74.132.86.89], reject=554 5.3.0 Spam blocked see:http://spamcop.net/bl.shtml? 74.132.86.89
Вторая запись попала в мой лог потому, что я использую FEATURE(`dnsbl',`bl.spamcop.net', `Spam blocked see: http://spamcop.net/bl.shtml?$&{client_addr}'), который обрабатывается в основном наборе check_relay. В данном случае оказалось, что ip-адрес релея попал в черный список на spamcop.net
Как вы уже догадались, \233 - это $|. Откуда он берется, и для чего он нужен?
Как я уже говорила, на вход в check_relay подается два значения, разделенные символами $|.
$| используется в качестве разделителя , я так понимаю, для удобства чтения крнфига.
В качестве выделителя используются угловые скобки. В этом случае при чтении конфига удобно визуально отделять одно значение от другого, кроме того, если оно оказывается пустым, то <> наглядно это продемонстрирует.

А теперь поговорим о лексемах левосторонней части правила (LHS).
Здесь я позволю себе небольшое отступление.
Где-то в 2001-2002 гг. мой почтовик стал заваливать спам, в обратном адресе которого фигурировали 2 и больше нижних подчеркивания, что-то вроде s_e_m_i_n_a_r@yandex.ru. Адреса были самые разные, но одно оставалось неизменным - нижние подчеркивания. Из-за недопонимания синтаксиса очень много времени у меня ушло на отладку таких неправильных правил :
SLocal_check_mail
R$*_$+_$*@$*                $#error $: "554 Sorry, you cannot send the letter."

Моя ошибка была в том, что я не приняла во внимание, что sendmail.cf работает с лексемами (в оригинале - tokens). В двух словах я бы определила лексему как набор символов между разделителями sendmail.cf.
"...
OperatorChars=charlist
[$o macro] The list of characters that are considered to be operators,that is, characters that delimit tokens.
All operator characters are tokens by themselves; sequences of non-operator characters are also tokens.
White space characters separate tokens but are not tokens themselves --
for example, AAA.BBB has three tokens, but AAA BBB has two.
If not set, OperatorChars defaults to .:@[]; additionally, the characters ()<>,; are always operators.
Note that OperatorChars must be set in the configuration file before any rulesets..."

Разделители перечислены в строке в sendmail.cf:
# delimiter (operator) characters (old $o macro)
O OperatorChars=.:%@!^/[]+

И как вы видите, нижнего подчеркивания в этом списке нет
И в отношении адреса отправителя, который поступает в check_mail в виде <user@domain.ru> лексемами будут user, domain, ru.
То есть, если разложить адрес отправителя на лексемы, мы получим
разделитель_левая_угловая_скобка лексема(имя почтового ящика) разделитель_амперсанд лексема(почтовый домен) разделитель_точка лексема(домен 1-го уровня) разделитель_правая_угловая_скобка
Так как _ не является разделителем, то простым способом такую почту заблокировать невозможно.
А вот простые случаи нам по плечу:
SLocal_check_mail
R< reklama@$+ >                $#error $: "554 Sorry, you cannot send the letter."
- так мы заблокировали почту с любого домена с именем почтового ящика reklama.
А что все-таки делать с адресами, содержащими нижние подчеркивания?
В этом случае необходимо использовать специальное преобразование с классом regex.
Подробно о нем я давно рассказала здесь.

А наша задачка решается так:
LOCAL_CONFIG
#Определяем спец. преобразование SPAM, которое будет отлавливать трех и более кратные повторения
#символа _ в сочетании с произвольным количеством любых символов.
#Если подобный набор символов будет обнаружен, то все, что подано на вход, будет заменено на @MATCH.
KSPAM regex -aMATCH (_.+){3,}
LOCAL_RULESETS
SLocal_check_mail
#На вход в этот набор правил по умолчанию подается адрес отправителя в виде <user@domain.net>.
#Нас интересует правая часть адреса ($1) поэтому мы сразу разбиваем адрес отправителя
#на лексемы для дальнейшего разбора.
#Берем имя почтового ящика, отправляем его в спеЦ. преобр. SPAM
R<$+@$+>             $: $(SPAM $1 $)
#Если в имени ящика содержатся "криминальные элементы", то предыдущее правило вернет нам слово @MATCH,
#и тогда данный отправитель будет отвегнут.
R@MATCH             $#error $: 554 Spam.
#А если ничего криминального не произошло, то Local_check_mail завершен успешно, мы возвращаемся в
#основной check_mail, и начинаем разбор адреса отправителя уже собственными правилами sendmail.cf.
#При этом не имеет значение, что именно вернется в основной набор правил:
#этот набор продолжит работу с исходным материалом <user@domain.net>,
#предварительно сохраненным перед вызовом Local_check_rcpt.

Каждый набор правил можно протестировать частным порядком, то есть исполнив такую команду:
echo "Local_check_mail s_e_m_i_n_a_r@yandex.ru"|/usr/sbin/sendmail -bt
Я не буду сейчас приводить выод этой команды - некогда. Но вы и сами догадаетесь по результату, сработало ваше правило или нет.
Вы можете посмотреть здесь различные ключи для команды sendmail -bt.
Но, если вам нужно оттестировать Local_check_relay, то для подачи разделителя $| нужно будет пойти на хитрость:
Добавить в конфиг (после любого набора, например, (Local_)?check_(relay|mail|rcpt)|CheckFrom|CheckReceived|etc ) 2 строчки:
SStart
R$* $$| $*               $: $1 $| $2        fake for -bt mode, remove for real version
а затем в командной строке набрать
echo "Start,check_relay a.b.c.d $| 1.2.3.4"|/usr/sbin/sendmail -bt
Как видите, разработчики указали особо, что рулсет SStart нужно будет удалить из конфига после тестирования.
А можно добавить эти строки в тестовый конфиг, назвав его, скажем, test.cf, и запустить тогда sendmail уже так:
echo "Start,check_relay a.b.c.d $| 1.2.3.4"|/usr/sbin/sendmail -bt -C/etc/mail/test/test.cf

Кое-какие примеры тестирования есть здесь.

11.11.2008.Когда начинают действовать правила перезаписи?

Из ответа Per Hedeland на вопрос "when exactly do the rewrite rules come into play?"
С точки зрения sendmail любое письмо является и входящим, и исходящим (т.е. сначала оно поступает к sendmail, а затем исходит от него.)
То, что вы понимаете под "входящей" и "исходящей" почтой, ВОЗМОЖНО имеет отношение к тому, какой мэйлер ("local" or "smtp") будет выбран для доставки, НО такие вещи на самом деле не затрагивают логику sendmail.
Sendmail - это почтовый роутер, находящийся между мэйлерами, которые имеют множество механизмов доставки, которые в принципе не имеют отношения к обработке сообщений.
К понятиям "входящий" и "исходящий" электронные адреса имеют отношение еще меньше.
Рулсет 3 - это предобработка адресов.
Постобработка адресов происходит прямо перед тем, как sendmail передает сообщение дальше выбранному агенту доставки.

when exactly do the rewrite rules come into play?
Это, действительно, очень трудный вопрос. Neil однажды дал полное и ясное объяснение в очень компактном виде. Я не думаю, что могу сделать это лучше. Но вам не нужно беспокоиться об этом, если вы будете следовать функционалу, предоставляемому m4-файлами и конфигом sendmail.mc

Так sendmail сначала получает письмо и затем применяет правила перезаписи вне зависимости от того, идет ли это письмо с локального хоста (?) или релеится дальше или получается (в процессе получения)?
В самом упрощенном смысле - да. Но есть множество "если" и "но". Большая часть обрабоки письма происходит в рулсетах, имеющих отношение к мэйлерам (указанных с параметре S= в определении мэйлера), они могут быть разными для разных мэйлеров и обычно таковыми и являются, например "local & "smtp". И некоторые рулсеты (большинство из check_xxx) относятся к разным этапам SMTP-сессии и вызываются только, когда сообщение принимается по SMTP. И рулсет "5" (localaddr) вызывается только теми мэйлерами, которые имеют флаг "5", а это обычно только локальные мэйлеры. И обработка конвертных адресов и большинства SMTP check_xxx рулсетов происходит перед тем, как письмо будет получено.
sendmail.cf - это не просто конфиг, это очень сложная прогрмма
Эксперименты с конфигом с целью изучения sendmail - это хорошо, но до тех пор, пока вы не начнете четко и детально осознавать (а это может занять несколько лет), что же делает sendmail.cf, и как он взаимодействует с бинарником sendmail , строго следуйте m4-методу.

A good tool for playing is -bt mode with input of '< ruleset > < address >'. You actually almost always want to send an address through rulset 3 first, because that's what sendmail does, so you'll input something like '3,0 user@domain' to see how the address is first transformed into "canonical form" by ruleset 3, and then passed through ruleset 0 to make a delivery decision.

This still only gives you fragments of the whole picture though - to find out more about your original question, which rulesets are called in which order etc, you can feed a complete message to sendmail with debug options, in particular -d21.x where x is an integer that you can increase to see more detail (start with 2 or so). You'll also want to note that envelope and header addresses are handled differently - you can feed in the envelope sender address with the -f option, and envelope recipient address by simply giving it as an argument to sendmail. The header addresses are in the header of course, i.e. From:/To: etc.
Цитирование гуру окончено.

Обратная связь
Страница создана 28 апреля 2007г. Последнее обновление - 08 декабря 2008г.