Dmitry A.Deineka wrote:
> Добрый день!
добрый
> Во-первых, спасибо за Паровоз :-)
велкам
> Во-вторых, несколько замечаний, вопросов и feature requests.
> 1) В данный момент у нас схема такая:
> Пара серверов, обслуживающих входящую почту (mx1, mx2) с одинаковым
> весом и почтовый сторадж, который не имеет записи MX, но, фактически,
> обслуживает виртуальные хосты, uucp :-) и прочее. Почему так получилось
> - я уже не помню, но схема такая есть. И вот, посмотрев на то, что в
> exim есть verify recipient с callout, поставил я на одном из mx-ов exim
> 4.60. Конфиг банально прост (выдержки):
>> domainlist relay_to_domains = @mx_any/ignore=127.0.0.1
> require verify = recipient/callout=10s,defer_ok
>> smarthost:
> driver = manualroute
> transport = remote_smtp
> domains = ! +local_domains
> route_list=* huge-mail-storage.domain
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
> no_more
>> Все заработало. Начал смотреть на паровоз. В нем же сделано, несомненно,
> все правильно, но:
> define(`confSECONDARY_RELAY', `YES')dnl
> define(`confRELAY_BASED_ON_MX', `YES')dnl # или ANY
>> требует наличия MX с более высоким приоритетом. А в моей схеме этого нет
> !
ну так сделайте (ниже опишу, что именно я имею ввиду)
> Поэтому и пришлось как quick hack добавить таки в mx-ы большой
> почтовый хаб, но на нем закрыть входящие snmp с мира ipfw.
> Поэтому, или я что-то не дочитал, или просьба - сделать более гибкой
> схему с RELAY_BASED_ON_MX для того, чтобы можно было делать такие
> извращения :-)
есть два пути:
1. простой. если у вас bind, сделайте отдельный view, в котором будет в
качестве best MX фигурировать хост с ваших почтовым стораджем
2. чуть более сложный. надо в паровозе реализовать аналог mailertable,
но только для callout'ов. или в существующую mailertable адаптировать
для этого
пока я рекомендую перейти с вашей подпорки на ту, которая описана в
пункте 1. а я чуть позже реализую mailertable для callout'ов. тем более,
что nvi уже давненько когда-то просил нечто подобное
> 2) spamd. Во-первых, как я понял, для того, чтобы заголовки писем
> дополнялись информацией от SA, нужно, чтобы был включен
> define(`confSYSTEM_FILTER', `CONFDIR/system_filter') ? (По крайней мере,
> без этого у меня не работало). Нужно бы в документации отразить, я думаю.
согласен. просто у нас столько завязано на системный фильтр, что без
него вообще нет ни единого хоста с паровозом.
я в conf.default обязательно упомяну о необходимости включать
использование системного фильтра при использовании spamassassin.
хотя... можно автоматически включать использование системного фильтра
при использовании spamassassin. надо только чтобы конфиги собирали после
этого не командой gmake configure, а gmake all
> И было бы неплохо иметь не hardcoded адрес spamd
> (features/spamassassin.m4, строка 89), а иметь возможность его менять.
с этим совсем просто
можно уже сейчас синхронизировать паровоз, в site/conf внести строку:
define(`confSPAMASSASSIN_SPAMD_ADDRESS', `127.0.0.1 783')
и пересобирать конфиг.
> Если я что-то недопонял в паровозе, что задаю такие вопросы - ткните
> носом, куда смотреть :-)
да вроде все по делу. и сформулировано внятно и вопросы по существу
--
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