Sergey Korolew wrote:
> VU> один _ARG_ использовать и при проверке домена из envelope from и при
> VU> проверке домена из header from? или для одной проверки использовать
> VU> _ARG_, а для другой - _ARG2_?
>> Имхо логично будет примерно так:
> define(`confRESTR_IN_MAIL_ENV_FROM', `You can not send mail with this
> envelope From')dnl
> define(`confRESTR_IN_MAIL_HDR_FROM', `You can not send mail with this
> header From')dnl
>> Ну а глобальный использовать если соотв. переменная определена,
> но длина у нее нулевая.
> HACK(restrict_incoming_mail, `Permission denied')dnl
вообще-то методика передачи параметров, исползованная в
restrict_incoming_mail.m4, давно уже устарела. и этот хак - это
оформленный в виде отдельного файла мой ответ на чей-то вопрос в
fido7.ru.* или рассылке UAFUG'а
в соответствии с используемой сейчас схемой передачи параметров:
параметры confRESTR_IN_MAIL_ENV_FROM и confRESTR_IN_MAIL_HDR_FROM
объединяются в confRESTR_IN_MAIL, который может иметь значения ENV_FROM
и/или HDR_FROM. можно указать оба параметра, разделив их пробелом.
параметры confRESTR_IN_MAIL_ACCESS и confRESTR_IN_MAIL_ACCESS_PTR
объединяются в confRESTR_IN_MAIL_LOCAL со значениями A и PTR. точно
также можно указать оба значения через пробел.
вот в эту схему теперь и надо вклинить передачу юзерских сообщений об
ошибках.
я вижу два варианта:
1. создание переменных confRESTR_IN_MAIL_ENV_FROM_MSG и
confRESTR_IN_MAIL_HDR_FROM_MSG с присвоением юзером им необходимых
значений. дефолтовое будет указано прямо в хаке.
2. передача хаку двух параметров. первый будет сообщением, используемым
при проверке домена из envelope from, второй - сообщением, используемым
при проверке домена из header from
второй вариант кажется более приемлемым. уж очень имена переменных
получились длинными :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ UIN: 77186900, 32418694 nic-handle: CRV2-RIPE, CRV-UANIC