Здравствйте. Установлены FreeBSD 8.2, sendmail 8.14.5 из портов. Sendmail собран с SASLv2 и STARTTLS. Для аутентификации использовал настройку:
TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
define(`confAUTH_OPTIONS', `A p y')dnl
Соответсвенно plain и login разрешены только после шифрования. Хотим организовать рассылку почты из 1С. Она, как мне обьяснили наши 1С-овцы не поддерживает работу с сертификатами. Есть ли возможность для локальной подсети испоьзовать аутентификацию без шифрования, для остальных шифровать.
> Здравствйте. Установлены FreeBSD 8.2, sendmail 8.14.5 из портов. Sendmail собран с SASLv2
> и STARTTLS. Для аутентификации использовал настройку:
> TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
> define(`confAUTH_MECHANISMS', `LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
> define(`confAUTH_OPTIONS', `A p y')dnl
> Соответсвенно plain и login разрешены только после шифрования. Хотим организовать рассылку
> почты из 1С. Она, как мне обьяснили наши 1С-овцы не поддерживает
> работу с сертификатами. Есть ли возможность для локальной подсети испоьзовать аутентификацию
> без шифрования, для остальных шифровать.в <tra-ta-ta>.mc
FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access')
в /etc/mail/access
<IP> RELAY
И будет с этого IP-а вообще без авторизации принимать.
> в <tra-ta-ta>.mc
> FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access')
> в /etc/mail/access
> <IP>
> RELAY
> И будет с этого IP-а вообще без авторизации принимать.Мне не надо без авторизации. Мне надо:
для локальной подсети испоьзовать аутентификацию
без шифрования, для остальных шифровать.
>> в <tra-ta-ta>.mc
>> FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access')
>> в /etc/mail/access
>> <IP>
>> RELAY
>> И будет с этого IP-а вообще без авторизации принимать.
> Мне не надо без авторизации. Мне надо:
> для локальной подсети испоьзовать аутентификацию
> без шифрования, для остальных шифровать.Запустить 2 сендмейла, на один (без шифрования) разрешить коннектиться исключительно из локалки, на второй - всем.
А вообще не совсем понятно накой авторизация без шифрования?? почему бы не разрешить нужным серверам подключение напрямую?
> Запустить 2 сендмейла, на один (без шифрования) разрешить коннектиться исключительно из
> локалки, на второй - всем.
> А вообще не совсем понятно накой авторизация без шифрования?? почему бы не
> разрешить нужным серверам подключение напрямую?Авторизация без шифрования нужна, чтобы коллега из соседней комнаты не "послал" директора от моего имени.
> Авторизация без шифрования нужна, чтобы коллега из соседней комнаты не "послал" директора
> от моего имени.Ну, почтовики обычно пишут хидеры. :) Из них будет видно - кто, кого и куда послал. Да и логи ведут вообще-то.
> Ну, почтовики обычно пишут хидеры. :) Из них будет видно -
> кто, кого и куда послал. Да и логи ведут вообще-то.Согласен, вычислить можно. Но мне, извините, нужно:
для локальной подсети использовать аутентификацию
без шифрования, для остальных шифровать.
>> Авторизация без шифрования нужна, чтобы коллега из соседней комнаты не "послал" директора
>> от моего имени.
> Ну, почтовики обычно пишут хидеры. :) Из них будет видно -
> кто, кого и куда послал. Да и логи ведут вообще-то.Гы, если коллега додумается до такого, то как отснифить пароль в сети - мозгов не больше нужно...
Ну и ничто не мешает коллеге от вашего имени заодно и авторизоваться :)
Или на smtp авторизоваться своим логином, а в поле from указать ваш емыл.
В любом варианте в заголовке обязан остаться ip узла, с которого сей емыл был отправлен.Но мы уклонились от темы.
Я бы 2 сендмыла поднял.
> Гы, если коллега додумается до такого, то как отснифить пароль в сети
> - мозгов не больше нужно...
> Ну и ничто не мешает коллеге от вашего имени заодно и авторизоваться
> :)
> Или на smtp авторизоваться своим логином, а в поле from указать ваш
> емыл.
> В любом варианте в заголовке обязан остаться ip узла, с которого сей
> емыл был отправлен.После того как директор прочитает и втавит мне по самые помидоры, мне ходить и разбираться кто виноват будет уже не столь важно.:)
> Но мы уклонились от темы.
> Я бы 2 сендмыла поднял.Про sendmail я тоже думал, я в сторону правил хотел вопрос увести.
>[оверквотинг удален]
>> :)
>> Или на smtp авторизоваться своим логином, а в поле from указать ваш
>> емыл.
>> В любом варианте в заголовке обязан остаться ip узла, с которого сей
>> емыл был отправлен.
> После того как директор прочитает и втавит мне по самые помидоры, мне
> ходить и разбираться кто виноват будет уже не столь важно.:)
>> Но мы уклонились от темы.
>> Я бы 2 сендмыла поднял.
> Про sendmail я тоже думал, я в сторону правил хотел вопрос увести.http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
>[оверквотинг удален]
>>> Или на smtp авторизоваться своим логином, а в поле from указать ваш
>>> емыл.
>>> В любом варианте в заголовке обязан остаться ip узла, с которого сей
>>> емыл был отправлен.
>> После того как директор прочитает и втавит мне по самые помидоры, мне
>> ходить и разбираться кто виноват будет уже не столь важно.:)
>>> Но мы уклонились от темы.
>>> Я бы 2 сендмыла поднял.
>> Про sendmail я тоже думал, я в сторону правил хотел вопрос увести.
> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.htmlТакое подходит или нет?
>> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
> Такое подходит или нет?Я так понял, что тут проверка по разрешенным механизмам аутентификации, а мне надо чтобы проверялось на принадлежность к локальной подсети.
>>> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
>> Такое подходит или нет?
> Я так понял, что тут проверка по разрешенным механизмам аутентификации, а мне
> надо чтобы проверялось на принадлежность к локальной подсети.Нет, это какраз возможность создать правило, отличное от дефолтового по набору признаков. (насколько я понял)
>>>> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
>>> Такое подходит или нет?
>> Я так понял, что тут проверка по разрешенным механизмам аутентификации, а мне
>> надо чтобы проверялось на принадлежность к локальной подсети.
> Нет, это какраз возможность создать правило, отличное от дефолтового по набору признаков.authinfo: It should not be needed for most installations. Provide a separate map for client side authentication information. See SMTP AUTHentication for details. By default, the authinfo database specification is: hash /etc/mail/authinfo
>>>>> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
>>>> Такое подходит или нет?
>>> Я так понял, что тут проверка по разрешенным механизмам аутентификации, а мне
>>> надо чтобы проверялось на принадлежность к локальной подсети.
>> Нет, это какраз возможность создать правило, отличное от дефолтового по набору признаков.
> authinfo: It should not be needed for most installations. Provide a
> separate map for client side authentication information. See SMTP AUTHentication for
> details. By default, the authinfo database specification is: hash /etc/mail/authinfoУпс, извиняюсь - это когда сендмыл клиентом является, а у вас он в роли сервера выступает.
>>>>>> http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
>>>>> Такое подходит или нет?
>>>> Я так понял, что тут проверка по разрешенным механизмам аутентификации, а мне
>>>> надо чтобы проверялось на принадлежность к локальной подсети.
>>> Нет, это какраз возможность создать правило, отличное от дефолтового по набору признаков.
>> authinfo: It should not be needed for most installations. Provide a
>> separate map for client side authentication information. See SMTP AUTHentication for
>> details. By default, the authinfo database specification is: hash /etc/mail/authinfo
> Упс, извиняюсь - это когда сендмыл клиентом является, а у вас он
> в роли сервера выступает.А вот первая ссылка - какраз дает то, что нужно.
http://www.sendmail.com/sm/open_source/docs/m4/smtp_auth.html
Надо только проавильно написать регекспы, но я в них не силен.
SLocal_check_rcpt
R$* $: $&{auth_type} $| $&{auth_authen}
RDIGEST-MD5 $| $+@$=w $# OKto allow relaying for users that authenticated using DIGEST-MD5 and have an identity in the local domains.
вам же надо сюда вместо RDIGEST-MD5 вставить RPLAIN и добавить описалово сети, после чего для всех остальных - с tls-ом...
> Надо только проавильно написать регекспы, но я в них не силен.Это не регэкспы, а страшный и суровый язык лексем сендмыла. :)
Если кому интересно решил я эту проблемку.
В access добавил
Srv_Features:192.168.0 C S
> Если кому интересно решил я эту проблемку.
> В access добавил
> Srv_Features:192.168.0 C SМожет оформите теперь конечный результат в более-менее удобочитаемом варианте?
Изначальная постановка задачи
решение
результат
конечный вид конфига
выводы??
> Если кому интересно решил я эту проблемку.
> В access добавил
> Srv_Features:192.168.0 C SКстати из каких дебрей были вынуты эти "C S" ??
Очень любопытно.
>> Если кому интересно решил я эту проблемку.
>> В access добавил
>> Srv_Features:192.168.0 C S
> Кстати из каких дебрей были вынуты эти "C S" ??
> Очень любопытно./usr/local/share/doc/sendmail/op.txt
> Здравствйте. Установлены FreeBSD 8.2, sendmail 8.14.5 из портов. Sendmail собран с SASLv2
> и STARTTLS. Для аутентификации использовал настройку:
> TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
> define(`confAUTH_MECHANISMS', `LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5')dnl
> define(`confAUTH_OPTIONS', `A p y')dnl
> Соответсвенно plain и login разрешены только после шифрования. Хотим организовать рассылку
> почты из 1С. Она, как мне обьяснили наши 1С-овцы не поддерживает
> работу с сертификатами. Есть ли возможность для локальной подсети испоьзовать аутентификацию
> без шифрования, для остальных шифровать.а вы полностью представляете себе работу smtp-auth и различие:
- login
- plain
- gssapi
- digest-md5
- cram-md5
?Если нет, то для начала реализуйте smtp-auth в понятном вам виде, затем
при наличии проблем - будете думать.ps. Поднимите VirtualBox в нем FreeBSD + sendmail + smtp-auth и все станет понятно.
>[оверквотинг удален]
> - login
> - plain
> - gssapi
> - digest-md5
> - cram-md5
> ?
> Если нет, то для начала реализуйте smtp-auth в понятном вам виде, затем
> при наличии проблем - будете думать.
> ps. Поднимите VirtualBox в нем FreeBSD + sendmail + smtp-auth и все
> станет понятно.VirtualBox поднимать не вижу смысла, это всё у меня уже установлено в реале. Для outlook и 1С различий в механизме аутентификации нет, так как они поддреживают только login (по крайней мере outlook).
>[оверквотинг удален]
>> - digest-md5
>> - cram-md5
>> ?
>> Если нет, то для начала реализуйте smtp-auth в понятном вам виде, затем
>> при наличии проблем - будете думать.
>> ps. Поднимите VirtualBox в нем FreeBSD + sendmail + smtp-auth и все
>> станет понятно.
> VirtualBox поднимать не вижу смысла, это всё у меня уже установлено в
> реале. Для outlook и 1С различий в механизме аутентификации нет, так
> как они поддреживают только login (по крайней мере outlook).ну так оставьте часть сетки без SSL, если не знаете как, поднимите второй
sendmail/postfix/exim... в jail'е или на другой машине и через него гоните подсеть,
второй sendmail с первым можете связать по ssl + smtp-auth.
Два sendmail'а на одной машине можно, но не советую, лучше на разных или в jail,
причем на вспомогательном можете разрешить ТОЛЬКО нужную подсеть и только изнутри,
а его связать с основным.Ну или замените sendmail на postfix или exim.
> ну так оставьте часть сетки без SSL, если не знаете как,Так по этому и спросил, что не знаю.
>> ну так оставьте часть сетки без SSL, если не знаете как,
> Так по этому и спросил, что не знаю.понято, если память не изменяет, by default sendmail with tls/ssl + smtp-auth для
локальной сети если она указана в релеинге не требует auth и ssl.
> понято, если память не изменяет, by default sendmail with tls/ssl + smtp-auth
> для
> локальной сети если она указана в релеинге не требует auth и ssl.Да, это я знаю. Мне надо чтобы требовала но без ssl, а для внешней с ssl.
Я так понимаю, что без поднятия второго почтовика проблему не решить.
> Я так понимаю, что без поднятия второго почтовика проблему не решить.Пути указаны выше:
1. сендмыльными лексемами.
2. 2 сендмыла.
3. изменить начальныю задачу в сторону упрощения:
3.1 без авторизации для локальной подсети
3.2 pop перед smtp
4. заменить сендмыл на что-то, в чем это реализовывается проще.
>> Я так понимаю, что без поднятия второго почтовика проблему не решить.
> Пути указаны выше:
> 1. сендмыльными лексемами.
> 2. 2 сендмыла.
> 3. изменить начальныю задачу в сторону упрощения:
> 3.1 без авторизации для локальной подсети
> 3.2 pop перед smtp
> 4. заменить сендмыл на что-то, в чем это реализовывается проще.1 вариант самый оптимальный, только я в этих лексемах пока не туту
4 я бы на постификсе сделал, да только в нем тоже таких настроек не нашел.
>[оверквотинг удален]
>> Пути указаны выше:
>> 1. сендмыльными лексемами.
>> 2. 2 сендмыла.
>> 3. изменить начальныю задачу в сторону упрощения:
>> 3.1 без авторизации для локальной подсети
>> 3.2 pop перед smtp
>> 4. заменить сендмыл на что-то, в чем это реализовывается проще.
> 1 вариант самый оптимальный, только я в этих лексемах пока не туту
> 4 я бы на постификсе сделал, да только в нем тоже таких
> настроек не нашел.Есть еще один вариант:
Настраиваете сендмыл без требования шифрования, а наружу выставляете stunnel.
> Я так понимаю, что без поднятия второго почтовика проблему не решить.Насколько срочно это задание?
>> Я так понимаю, что без поднятия второго почтовика проблему не решить.
> Насколько срочно это задание?Пару недель время есть.
> Пару недель время есть.Это радует. У вас в данный момент шифрование на почтовике используется?
>> Пару недель время есть.
> Это радует. У вас в данный момент шифрование на почтовике используется?Да
Итак, у нас в активе:
- мой собственный более-менее опыт написания рулсетов к sendmail.cf;
- желание вам помочь.
В пассиве:
- в последнее время я отошла от активного написания рулсетов,значит, частично навыки утрачены;
- отсутствие опыта работы с шифрованием на почтовике, и, как следствие, tls_рулсетами;
- 10-12 часовая загруженность на работе;
- в среду у меня суд и я к нему активно готовлюсь (сорри за интимные подробности моего бытия).ВЫВОД: задачка мне интересна, но времени и сил не то чтобы нет, они уже в минусе, но ... задачка мне интересна! Попробуем уложиться в тот срок (но я буду постоянно пропадать!), что вы указали, время пошло, от вас требуется максимальная внимательность.
1. Мне нужен ваш конфиг.
2. Где у вас прописана локальная сеть? /et/mail/relay-domains or /etc/mail/access - покажите оба файла.
3. МНе нужно, чтобы вы добавили вот этот рулсет в sendmail.cf и показали результат:
Scheck_eoh
R$* [TAB] $: $(syslog syslog:check_eoh:0: $&{verify} $) $1egrep check_eoh /var/log/maillog
ИНф. по пп.1,2,3 пришлите постмастеру домена anrb.ru.
P.S. Я на этой ветке появляться не буду, но вы следите дальше за сообщениями:
возможно сюда заглянет супергуру по sendmail - тогда ваша задачка будет решена с полпинка.
Честно говоря, я увидела вашу тему сразу, но не подключалась, выжидая в надежде, что он ответит вам раньше меня. И я тоже научусь чему-то новому.
>>> Я так понимаю, что без поднятия второго почтовика проблему не решить.
>> Насколько срочно это задание?
> Пару недель время есть.О!
Disabling STARTTLS And Setting SMTP Server FeaturesBy default STARTTLS is used whenever possible. However, there are some broken MTAs that don't properly implement STARTTLS. To be able to send to (or receive from) those MTAs, the ruleset try_tls (srv_features) can be used that work together with the access map. Entries for the access map must be tagged with Try_TLS (Srv_Features) and refer to the hostname or IP address of the connecting system. A default case can be specified by using just the tag. For example, the following entries in the access map:
Try_TLS:broken.server NO
Srv_Features:my.domain v
Srv_Features: Vwill turn off STARTTLS when sending to broken.server (or any host in that domain), and request a client certificate during the TLS handshake only for hosts in my.domain. The valid entries on the RHS for Srv_Features are listed in the "Sendmail Installation and Operations Guide".
> Try_TLS:broken.server NOВыглядит красиво, тока не работает для клиентов.
Я так понимаю это относиться только к серверам(MTA).