Vladimir A. Butenko wrote:
> >Да, теперь вижу. Раз задокументировано - значит и правда фича :)
> >
> >Note: this option checks for the "fixed" Client IP Addresses only - it
> >does not pay attention to the "temp-client" addresses added with the
> >Process as a Client Address feature.
> >
> >А в чем принципиальное значение этой фичи?
>
> Force AUTH делается не для релеинга, а для того, чтобы кто ни попадя не мог
> от моего имени отправить письмо - хотя бы внутри того же сервера. И тогда
> Client IP Addresses используются как исключения или этого правила (если
> обсуждаемая опция стоит для "clients"). И поэтому будет совсем нехорошо,
У меня она стояла для non-clients (пока не пришлось сегодня поставить nobody). Именно для того, чтобы всякие левые люди не писали от имени пользователей наших доменов. Но вопрос в том, что прошедшие "POP before SMTP" никак не могут считаться левыми! Почему забрать почту аккаунта user@domain.com мы ему доверили, а отправить с таким envelope from низзя?
> если кто-то из совсем левой сети, но имеющий пароль (студент из дому - это
> опция для университетов актуальна) сможет залогиниться под своим именем, а
> потом под это дело - обходить Force AUTH как ему вздумается.
Всё равно неясно, почему обычному клиенту можно сделать исключение, а временному нельзя.
>
> Вашу проблему можно было бы решить путем запрета Secure SASL на уровне
> домена. Тогда можно было бы создать фиктивный домен, форвадрящий всё на
> домен реальный, но со своим IP. При соединении именно к этому IP
> срабатывали бы сеттинги именно этого домена, и Secure SASL бы не
> показывался. Это сейчас работает с SSL опциями (STARTTLS), но не с SASL.
Этот домен и так на отдельном IP, я бы и рад запретить там SASL, но как?
-- Victor Sudakov, VAS4-RIPE, VAS47-RIPNПолучено Thu Jul 14 11:22:56 2005
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:13:58 MSK