1.У меня демо-версия на 500 адресов
Означает ли это, что в этоv случае вот опция ProtectedDomains не требует заполнения?
# ProtectedDomains = {strings_and_files}
# List of protected domains. Domains are divided by a comma.
# ProtectedDomains =
То есть будут проверяться только 500 адресов в любом направлении (to/from)
и с любой доменной частью?
A 501 пользователю будет добавлен в заголовок сообщения статус SKIP?
2. Для каких целей служит эта опция?
# ProtectedNetworks = {strings_and_files}
# List of protected networks. Networks are divided by a comma.
ProtectedNetworks = 127.0.0.0/8
Предложения.
1. Поскольку у вас предусмотрена возможность блокировки сообщений от <>,
не стоит ли добавить предупреждение о том, что так и в rfc-ignorant угодить недолго. Просто для того, чтобы люди осознавали, что они делают. И потом не бегали по форумам и не спрашивали, почему они в черные списки попали.
2. Аналогично и относительно
;MissingHeader { field list }
; Describes list of header fields, absence of which in the message
; will filter this message.
;MissingHeader "To", "From"
Bcc ведь еще никто не отменял, но о нем не всегда вспоминают, когда блокируют пустые To:
3. Не сочтите меня занудой, но
Monitor has tried to restart "drweb-milter" at 16:00:13
Further attempts to restart the module were made at: 16:00:43, 16:01:13
неплохо бы будущее время поставить вместо were made :)
Вопросы по VadeRetro (II)
Автор
Medlar
, апр 22 2008 13:42
5 ответов в этой теме
#1
Отправлено 22 Апрель 2008 - 13:42
#2
Отправлено 22 Апрель 2008 - 14:18
1. Они никак не связаны: сейчас ProtectedDomains используется только в smtp-proxy и в плагине flytrap. Т.е. в вашем случае можно его не заполнять.
Так как у Вас демо-версия на 500 адресов, то никаких ограничений нет.
2. ProtectedNetworks - аналогично ProtectedDomains.
Предложения.
1. возможно.. но вообще администратор должен понимать что делает.
2. аналогично предыдущему :)
3. да - поправим
Так как у Вас демо-версия на 500 адресов, то никаких ограничений нет.
2. ProtectedNetworks - аналогично ProtectedDomains.
Предложения.
1. возможно.. но вообще администратор должен понимать что делает.
2. аналогично предыдущему :)
3. да - поправим
#3
Отправлено 23 Апрель 2008 - 11:09
Cписок ip-адресов, сообщения с которых вообще не должны проверяться, не предусмотрен?
Т.е. настоящий whitelist, но только для ip.
Под "настоящим" я подразумеваю отказ от проверки письма,
а не проверку с последующим вычитанием определенного значения.
Т.е. настоящий whitelist, но только для ip.
Под "настоящим" я подразумеваю отказ от проверки письма,
а не проверку с последующим вычитанием определенного значения.
#4
Отправлено 23 Апрель 2008 - 11:13
в текущей версии - нет.
в следующей будет реализовано через Rules. Т.е. в таком духе:
client-ip:127.0.0.1 cont scan=all:-vaderetro
в следующей будет реализовано через Rules. Т.е. в таком духе:
client-ip:127.0.0.1 cont scan=all:-vaderetro
#5
Отправлено 29 Апрель 2008 - 12:46
Еще 4 вопроса
1. Есть плагин headersfilter. Насколько я понимаю, он проверят только заголовки.
А не планируете ли вы возможность добавления в конфиг VadeRetro своей проверки на определенный шаблон в _теле_ письма?
2. Вы сказали, что персональный вес для reject'a(discrad'a) спам-письмам, обозначения веса письма в теме и возможность указания списка непроверяемых адресов/сетей будет в след. версиях.
Хотя бы приблизительно, когда след.версия выйдет: во второй половине 2008, в 2009 ?
Мне это важно знать, потому что в середине июля истекает срок действия лицензии для антиспама, к-м я сейчас пользуюсь, и нужно принять решение, а времени остается мало.
3. При default-уровне логирования для milter (9) в лог пишется информация о вставке определенных строк из заголовка + строк VadeRetro, а потом об удалении части тех же строк . Для меня эта инфа (удаление-добавление, за исключением строк VadeRetro и изменения темы)
лишняя, поэтому я использую уровень 8.
И все бы ничего, но теперь нет строки об изменении темы письма. Когда вы добавите в тему вес письма, эта строка мне будет очень нужна для статистики,
значит, придется вернуться к логированию уровня 9.
Какой смысл в этой инфе, может, стоит от нее отказаться?
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter insert (5): header: Date: Tue, 29 Apr 2008 07:25:26 +0000
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter insert (6): header: MIME-Version: 1.0
...
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter delete: header Date: Tue, 29 Apr 2008 07:25:26 +0000
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter delete: header MIME-Version: 1.0
А изменение темы письма показывать одной строкой "Milter change",
а не двумя (insert,delete).
Чтобы вы не подумали, что я придираюсь не по делу, хочу сказать, что я из тех админов, которые внимателньо читают логи (под чтением я подразумеваю не только и не столько буквальное чтение), и обилие лишней информации напрягает и кроме того увеливает логи.
4. Может, я хочу совсем запредельного, но как вы смотрите на возможность (пусть не в след. версии, а через версию) условного rejecta?
У нас кроме основного почтовика еще 2 mx-a. По причинам ограниченности в финансах, антиспам покупается только на основной почтовик. А это значит, что невозможно будет пользоваться reject'ом spam-письма:
если спам-письмо пришло с моего mx-a, mx получит reject и будет пытаться доставить извещение о невозможности доставки письма отправителю, а отправитель часто поддельный, и т.д. и т.п. Лишняя никчемная работа.
Условный reject позволил бы делать reject всем сообщениям, которые набрали
соотвествующий вес, если они пришли не с mx-ов,
и делать тихий discard, если спам-письмо пришло с mx-a (указан в конфиге).
Кроме того, многие имеют вторые-третьи mx-ы по договоренности с другими админами на сторонних почтовых серверах, и не обязательно на них должен быть установлен какой-либо антиспам. Как бы тоже не очень хорошо по отношению к этим почтовым серверам нагружать их лишней работой по доставке уведомлений о reject'e
А штука удобная - reject, а приходиться от нее отказываться ...
1. Есть плагин headersfilter. Насколько я понимаю, он проверят только заголовки.
А не планируете ли вы возможность добавления в конфиг VadeRetro своей проверки на определенный шаблон в _теле_ письма?
2. Вы сказали, что персональный вес для reject'a(discrad'a) спам-письмам, обозначения веса письма в теме и возможность указания списка непроверяемых адресов/сетей будет в след. версиях.
Хотя бы приблизительно, когда след.версия выйдет: во второй половине 2008, в 2009 ?
Мне это важно знать, потому что в середине июля истекает срок действия лицензии для антиспама, к-м я сейчас пользуюсь, и нужно принять решение, а времени остается мало.
3. При default-уровне логирования для milter (9) в лог пишется информация о вставке определенных строк из заголовка + строк VadeRetro, а потом об удалении части тех же строк . Для меня эта инфа (удаление-добавление, за исключением строк VadeRetro и изменения темы)
лишняя, поэтому я использую уровень 8.
И все бы ничего, но теперь нет строки об изменении темы письма. Когда вы добавите в тему вес письма, эта строка мне будет очень нужна для статистики,
значит, придется вернуться к логированию уровня 9.
Какой смысл в этой инфе, может, стоит от нее отказаться?
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter insert (5): header: Date: Tue, 29 Apr 2008 07:25:26 +0000
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter insert (6): header: MIME-Version: 1.0
...
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter delete: header Date: Tue, 29 Apr 2008 07:25:26 +0000
Apr 29 15:17:59 apache sendmail[24375]: m3T9HpaA024375: Milter delete: header MIME-Version: 1.0
А изменение темы письма показывать одной строкой "Milter change",
а не двумя (insert,delete).
Чтобы вы не подумали, что я придираюсь не по делу, хочу сказать, что я из тех админов, которые внимателньо читают логи (под чтением я подразумеваю не только и не столько буквальное чтение), и обилие лишней информации напрягает и кроме того увеливает логи.
4. Может, я хочу совсем запредельного, но как вы смотрите на возможность (пусть не в след. версии, а через версию) условного rejecta?
У нас кроме основного почтовика еще 2 mx-a. По причинам ограниченности в финансах, антиспам покупается только на основной почтовик. А это значит, что невозможно будет пользоваться reject'ом spam-письма:
если спам-письмо пришло с моего mx-a, mx получит reject и будет пытаться доставить извещение о невозможности доставки письма отправителю, а отправитель часто поддельный, и т.д. и т.п. Лишняя никчемная работа.
Условный reject позволил бы делать reject всем сообщениям, которые набрали
соотвествующий вес, если они пришли не с mx-ов,
и делать тихий discard, если спам-письмо пришло с mx-a (указан в конфиге).
Кроме того, многие имеют вторые-третьи mx-ы по договоренности с другими админами на сторонних почтовых серверах, и не обязательно на них должен быть установлен какой-либо антиспам. Как бы тоже не очень хорошо по отношению к этим почтовым серверам нагружать их лишней работой по доставке уведомлений о reject'e
А штука удобная - reject, а приходиться от нее отказываться ...
#6
Отправлено 29 Апрель 2008 - 14:36
1. Нет - в плагин VadeRetro мы не планируем данной функциональности. Возможно с данной функциональностью будет отдельный плагин.
2. 2008 год. я надеюсь..
3. нет-нет мы не отвечаем за milter-лог - за этот лог отвечает исключительно sendmail. мы расчитываем что пользователи будут смотреть на INFO лог плагина vaderetro - там вроде должна быть вся необходимая информация.
4. На сколько я понял это можно будет сделать в следующей версии через правила. Например так:
[Rules]
client-ip:mx-ip cont VadeRetro/Action = discard
NOT client-ip:mx-ip cont VadeRetro/Action = reject
2. 2008 год. я надеюсь..
3. нет-нет мы не отвечаем за milter-лог - за этот лог отвечает исключительно sendmail. мы расчитываем что пользователи будут смотреть на INFO лог плагина vaderetro - там вроде должна быть вся необходимая информация.
4. На сколько я понял это можно будет сделать в следующей версии через правила. Например так:
[Rules]
client-ip:mx-ip cont VadeRetro/Action = discard
NOT client-ip:mx-ip cont VadeRetro/Action = reject
Читают тему: 0
0 пользователей, 0 гостей, 0 скрытых