Ни кто не настраивал milter-sender ?

[Oleg_]

Что-то не хочет работать.
maillog :
....
Jun 28 14:01:06 boss milter-sender[4560]: process uid=502 gid=506
Jun 28 14:01:33 boss sendmail[4602]: alias database /etc/mail/aliases rebuilt by root
Jun 28 14:01:33 boss sendmail[4602]: /etc/mail/aliases: 11 aliases, longest 19 bytes, 240 bytes total
Jun 28 14:01:35 boss sendmail[4616]: starting daemon (8.12.10): SMTP+queueing@00:05:00
Jun 28 14:03:21 boss milter-sender[4560]: milter-sender/0.57.774 Copyright 2002, 2004 by Anthony Howe. All rights reserved.
Jun 28 14:03:21 boss milter-sender[4560]: LibSnert/1.34.548 Copyright 1996, 2004 by Anthony Howe. All rights reserved.
Jun 28 14:03:21 boss milter-sender[4560]: Sleepycat Software: Berkeley DB 3.2.9: (February 2, 2001)
...

Т.е. он запустился.
socket тоже создается.
При прохождении писем должна добавляться строка в заголовок, но ее нет (хотя в /etc/mail/milter-sender.cf включено).
??

[setar]

а логи подключения к милтеру есть?
аналогичные этому :

Код: Выделить всё

Jun 21 04:02:31 gw spamd[18803]: connection from localhost [127.0.0.1] at port 3
4708

[Oleg_]

а логи подключения к милтеру есть?
аналогичные этому :

Код: Выделить всё

Jun 21 04:02:31 gw spamd[18803]: connection from localhost [127.0.0.1] at port 3
4708

В логах при подключении к miltery только clamav, milter-sender'a нет.

[setar]

я к сожалению с этим милтером не работал,
посмотрите что сказано в его конфигах по логам.

И вопрос, который может быть покажется вам смешным, но лучше я его проговорю.
У вас строка подключения к милтеру из конфига сендмайла имеется, все ли параметры там верны?

дело в том что в логах фиксируется запуск милтера по любому, даже если он не связан с мылером.

[Oleg_]

я к сожалению с этим милтером не работал,
посмотрите что сказано в его конфигах по логам.

И вопрос, который может быть покажется вам смешным, но лучше я его проговорю.
У вас строка подключения к милтеру из конфига сендмайла имеется, все ли параметры там верны?

дело в том что в логах фиксируется запуск милтера по любому, даже если он не связан с мылером.

Появились записи в логах :
Jun 29 07:56:53 boss sendmail[9739]: i5T2uh94009739: Milter (milter-sender): timeout before data read
Jun 29 07:56:53 boss sendmail[9739]: i5T2uh94009739: Milter (milter-sender): to error state
Jun 29 07:56:53 boss sendmail[9739]: i5T2uh94009739: Milter: from=<dongming@yalbi.com>, reject=451 4.7.1 Please try again late
Jun 29 07:56:53 boss sendmail[9739]: i5T2uh94009739: from=<dongming@yalbi.com>, size=0, class=0, nrcpts=0, proto=SMTP, daemon=...

Соответственно вся внешняя почта не пришла.
Локальная почта при этом ходит .

Будем разбираться.

[Oleg_]

Ура !

Разобрался откуда такая запись (после включения debug'а milter-sender и доки на него ) :
.. i5T2uh94009739: Milter (milter-sender): timeout before data read

milter-sender пытается установить соединение по SMTP с доменом отправителя и не может (timeout) , т.к. на файерволе закрыты соединения с серверами, отличными от почты провайдера.

[setar]

поздравляю, теперь пожалуй можно узнать впечатление
от применения этого милтера?
зачем он потребовался и каие задачи решил ?

[Oleg_]

поздравляю, теперь пожалуй можно узнать впечатление
от применения этого милтера?
зачем он потребовался и каие задачи решил ?

Пока ничего не решил, т.к. надо настраивать файервол, следовательно появиться доп. платный трафик . Эта штука используется с сендмайлом и режет спам, когда идет письмо с несуществующим именем отправителя - н-р,some@publicist.com - явно на publicist.com нет такого пользователя и milter-sender обрубит письмо на этапе проверки пользователя ( делается запрос на проверку пользователя к домену отправителя -- тута и появится трафик ).

[Stranger03]

поздравляю, теперь пожалуй можно узнать впечатление
от применения этого милтера?
зачем он потребовался и каие задачи решил ?

Я его пробовал, но работа его совсем не удовлетворила. Там идея такая, что должен проверяться адрес отправителя. То есть внешний хост инициирует соединение, представляет адрес типа from<...>, твой хост его подвешивает и начинает проверять, а существует ли такой юзер на сервере, который есть в MX.
Но, во первых MX отправителя и получателя могут быть разные.
Во вторых 90% серверов или даже больше тебе всегда ответят ОК, потому что там не реализованы функции проверок пользователя. Вот и получается, что ну 5, ну 10 процентов можно проверить. И то, вероятность ошибки очень велика. Потому я от него отказался.

Байес - ключ к успеху,

[corvax]

поздравляю, теперь пожалуй можно узнать впечатление
от применения этого милтера?
зачем он потребовался и каие задачи решил ?

Я его пробовал, но работа его совсем не удовлетворила. Там идея такая, что должен проверяться адрес отправителя. То есть внешний хост инициирует соединение, представляет адрес типа from<...>, твой хост его подвешивает и начинает проверять, а существует ли такой юзер на сервере, который есть в MX.
Но, во первых MX отправителя и получателя могут быть разные.

ну и что? знать, существует ли определенный пользователь в определенном домене должен best MX домена отправителя. совершенно не играет роли, разные ли MX отправителя и получателя. кстати, я эту фразу не очень хорошо понял

Во вторых 90% серверов или даже больше тебе всегда ответят ОК, потому что там не реализованы функции проверок пользователя.

не совсем так. функции эти реализованы в любом случае, без них невозможна была бы доставка. но есть одно "но". некоторые MTA проверяют существование пользователя лишь при совершении процесса доставка, т. е. когда письмо уже принято и находится в очереди. либо существуют ситуации, когда best MX получателя доставляет всю почту домена в один mailbox, откуда позже клиент забирает почту по pop3. в этом случае best MX получателя может вообще не знать, какие пользователи есть в данном домене

Вот и получается, что ну 5, ну 10 процентов можно проверить. И то, вероятность ошибки очень велика.

вероятность ошибки не велика, если только best MX домена отправителя не отвергает почту с пустым envelope from. а если отвергает, то такому домену два пути - или reject или white list

или под ошибкой подразумевается
250 Recipient Ok
в ответ на попытку проверить любого, даже несуществующего пользователя? так это не ошибка

Потому я от него отказался.

зря

Байес - ключ к успеху,

встречная проверка отправителя и статистические фильтры дополняют друг друга, а не взаимоисключают

[Stranger03]

ну и что? знать, существует ли определенный пользователь в определенном домене должен best MX домена отправителя. совершенно не играет роли, разные ли MX отправителя и получателя. кстати, я эту фразу не очень хорошо понял

Честно говоря я тоже . Имелось ввиду, когда MX отправителя (сервера, на который будет подан запрос на проверку) является лишь пересыльщиком (RELAY). Единственное, что там может быть реализовано для контроля пользователей - virtualusers. А реальных пользователей там нет вообще. Такой сервер тебе ответит ОК на начальном этапе.

Да и потом, BEST MX - столько же мало, насколько много LAMER MX. Я тут попробовал поставить проверку обратной зоны на почтовике. То, что касается "may by forged". Это ужас, примерно половина наших клиентов получила отлуп. Только потому, что их балбес админ забыл корректно прописать PTR отправителя. Так что вот. А ты говоришь BEST MX?

невозможна была бы доставка. но есть одно "но". некоторые MTA проверяют существование пользователя лишь при совершении процесса доставка, т. е. когда письмо уже принято и находится в очереди. либо существуют ситуации, когда best MX получателя доставляет всю почту домена в один mailbox, откуда позже клиент забирает почту по pop3. в этом случае best MX получателя может вообще не знать, какие пользователи есть в данном домене

Именно. Хотя вариантов очень много. А для корректной работы "проверки пользователя" необходимо, чтобы все сервера следовали одному стандарту. А так получается, у меня настроено так, у тебя эдак... Вообщем, бардак,

вероятность ошибки не велика, если только best MX домена отправителя не отвергает почту с пустым envelope from. а если отвергает, то такому домену два пути - или reject или white list

или под ошибкой подразумевается
250 Recipient Ok
в ответ на попытку проверить любого, даже несуществующего пользователя? так это не ошибка

Я не про ошибку говорил, я говорил, что такая проверка отсеет ну отсилы 5% почты. А создаст трафика еще на 15%. Оно нам надо? Мне нет.

встречная проверка отправителя и статистические фильтры дополняют друг друга, а не взаимоисключают

Дополняют, . Только вот больше трафика лишнего создают, чем приносят пользы.

[corvax]

ну и что? знать, существует ли определенный пользователь в определенном домене должен best MX домена отправителя. совершенно не играет роли, разные ли MX отправителя и получателя. кстати, я эту фразу не очень хорошо понял

Честно говоря я тоже . Имелось ввиду, когда MX отправителя (сервера, на который будет подан запрос на проверку) является лишь пересыльщиком (RELAY).

и что?

Единственное, что там может быть реализовано для контроля пользователей - virtualusers. А реальных пользователей там нет вообще. Такой сервер тебе ответит ОК на начальном этапе.

да

Да и потом, BEST MX - столько же мало, насколько много LAMER MX.

вообще-то под best MX я подразумеваю MX запись домена с наивысшим приоритетом. при чем тут LAMER MX?

Я тут попробовал поставить проверку обратной зоны на почтовике. То, что касается "may by forged". Это ужас, примерно половина наших клиентов получила отлуп. Только потому, что их балбес админ забыл корректно прописать PTR отправителя. Так что вот. А ты говоришь BEST MX?

до сих пор не могу понять, какое отношение имеет "best MX" к проверке несоответствия записей хоста рилея в прямой и реверсной зонах DNS

невозможна была бы доставка. но есть одно "но". некоторые MTA проверяют существование пользователя лишь при совершении процесса доставка, т. е. когда письмо уже принято и находится в очереди. либо существуют ситуации, когда best MX получателя доставляет всю почту домена в один mailbox, откуда позже клиент забирает почту по pop3. в этом случае best MX получателя может вообще не знать, какие пользователи есть в данном домене

Именно. Хотя вариантов очень много. А для корректной работы "проверки пользователя" необходимо, чтобы все сервера следовали одному стандарту.

какому стандрарту? нигде в RFC/STD не упоминается, что принимающий MTA обязан именно на этапе RCPT TO определить, является ли получатель валидным юзером.

А так получается, у меня настроено так, у тебя эдак... Вообщем, бардак,

вероятность ошибки не велика, если только best MX домена отправителя не отвергает почту с пустым envelope from. а если отвергает, то такому домену два пути - или reject или white list

или под ошибкой подразумевается
250 Recipient Ok
в ответ на попытку проверить любого, даже несуществующего пользователя? так это не ошибка

Я не про ошибку говорил, я говорил, что такая проверка отсеет ну отсилы 5% почты.

это ваше личное заблуждение

А создаст трафика еще на 15%. Оно нам надо? Мне нет.

я вас и не призываю использовать встречную поверку. я лишь говорю о том, что статистика - вещь упрямая. а вот как были вычислены 15% трафика? даже по грубым прикидкам не получается такой монстрообразной величины

встречная проверка отправителя и статистические фильтры дополняют друг друга, а не взаимоисключают

Дополняют, . Только вот больше трафика лишнего создают, чем приносят пользы.

не забывайте добавлять IMHO. ибо пока кроме показателей 5% vs 15%, взятых явно с потолка, ничего против встречной проверки предъявлено не было

[Stranger03]

Имелось ввиду, когда MX отправителя (сервера, на который будет подан запрос на проверку) является лишь пересыльщиком (RELAY).

и что?

А то, что проверка пользователя отправителя в данном случае сводится на нет.

вообще-то под best MX я подразумеваю MX запись домена с наивысшим приоритетом. при чем тут LAMER MX?

А, ну если с этой точки зрения. Я имел ввиду сервера некорректно настроенные. Только и всего. А таких большинство

до сих пор не могу понять, какое отношение имеет "best MX" к проверке несоответствия записей хоста рилея в прямой и реверсной зонах DNS

Нет, не имеют. Это был лишь пример попытки ввести очередную проверку, но попытка была неудачная. Только и всего.

какому стандрарту? нигде в RFC/STD не упоминается, что принимающий MTA обязан именно на этапе RCPT TO определить, является ли получатель валидным юзером.

Согласен, стандарта нет. Но почему бы его не принять, ???

это ваше личное заблуждение

Хмм, а примеры можно? Его реальной эффективности?? В студию. С год назад, когдя я его реально испытывал у себя, он показал скорей отрицательный результат. И не пытай меня статистикой, нету. Тогда, насколько я помню, недельный анализ логов показал почти нулевую эффективность. Если у тебя есть, пардон, у вас есть другие результаты - напишите. Я сниму шляпу, признаю, что бы не прав. Пока мое IMHO - до принятия стандарта или повсеместного введения этой фичи на серверах он практически бесполезен. IMHO - так лучше, ???

не забывайте добавлять IMHO. ибо пока кроме показателей 5% vs 15%, взятых явно с потолка, ничего против встречной проверки предъявлено не было

Ну пусть везде будет IMHO. Если анализировать лог скажем за неделю, то списки DNSBL дадут 10-15 процентов, что есть хорошо. Остальное отсеет spamassisn с его bayes. А ваши проверки пользователей встретятся пару раз. Это так круто, чтобы создавать тут кучу флейма???

Вопрос, вы сами то его используете? Можете привести результаты? Нет, ну тогда спор бесполезен...

[corvax]

Имелось ввиду, когда MX отправителя (сервера, на который будет подан запрос на проверку) является лишь пересыльщиком (RELAY).

и что?

А то, что проверка пользователя отправителя в данном случае сводится на нет.

а никто не обещал, что встречная проверка адреса отправителя - это панацея от спама.

вообще-то под best MX я подразумеваю MX запись домена с наивысшим приоритетом. при чем тут LAMER MX?

А, ну если с этой точки зрения. Я имел ввиду сервера некорректно настроенные. Только и всего. А таких большинство

а я имел ввиду термин из op.me:

5.9. K -- Key File Declaration
[...]
bestmx Returns the best MX record for a host name
given as the key. The current machine is
always preferred -- that is, if the current
machine is one of the hosts listed as a low-
est-preference MX record, then it will be
guaranteed to be returned. This can be used
to find out if this machine is the target
for an MX record, and mail can be accepted
on that basis. If the -z flag is given,
then all MX names are returned, separated by
the given delimiter.

до сих пор не могу понять, какое отношение имеет "best MX" к проверке несоответствия записей хоста рилея в прямой и реверсной зонах DNS

Нет, не имеют. Это был лишь пример попытки ввести очередную проверку, но попытка была неудачная. Только и всего.

на самом деле достаточно часто пишут о том, что фильтровать по наличию/корректности реверса не имеет смысла - уровень false positive ужасно велик

какому стандрарту? нигде в RFC/STD не упоминается, что принимающий MTA обязан именно на этапе RCPT TO определить, является ли получатель валидным юзером.

Согласен, стандарта нет. Но почему бы его не принять, ???

потому, что не все смогут выполнить условия такого стандарта

это ваше личное заблуждение

Хмм, а примеры можно? Его реальной эффективности?? В студию. С год назад, когдя я его реально испытывал у себя, он показал скорей отрицательный результат. И не пытай меня статистикой, нету. Тогда, насколько я помню, недельный анализ логов показал почти нулевую эффективность. Если у тебя есть, пардон, у вас есть другие результаты - напишите. Я сниму шляпу, признаю, что бы не прав. Пока мое IMHO - до принятия стандарта или повсеместного введения этой фичи на серверах он практически бесполезен. IMHO - так лучше, ???

из последних 390 попыток проверки адреса отправителя (это и спам и неспам) 334 закончились успешно. остальное - в печь.

правда, часть как положительных, так и отрицательных результатов проверки взята из кеша. статистику попадания в кеш я не веду. но, в принципе, из логов чекера можно извлечь список уникальных адресов и сравнить со общим списком проверенных адресов

false positive за все время эксплуатации (чуть больше года) можно пересчитать на пальцах одной руки.

не забывайте добавлять IMHO. ибо пока кроме показателей 5% vs 15%, взятых явно с потолка, ничего против встречной проверки предъявлено не было

Ну пусть везде будет IMHO. Если анализировать лог скажем за неделю, то списки DNSBL дадут 10-15 процентов, что есть хорошо. Остальное отсеет spamassisn с его bayes. А ваши проверки пользователей встретятся пару раз. Это так круто, чтобы создавать тут кучу флейма???

нет. кстати, эффективность встречной проверки серьезно упала после введения проверок HELO. просто проверка HELO (как более дешевая с точки зрения ресурсов) проводится раньше проверки отправителя

Вопрос, вы сами то его используете? Можете привести результаты? Нет, ну тогда спор бесполезен...

я использую механизм встречной проверки отправителя. но не milter-sender, а свой milter. какие результаты, кроме соотношения удачных/неуданых проверок нужны?

[setar]

to corvax
У вас удивительный характер склонный к спорам, я даже предпологаю что по знаку зодиака Вы телец.
Впрочем такая черта это не плохо, в спорах рождается истина, главное не углубляться в спор ради спора

я использую механизм встречной проверки отправителя. но не milter-sender, а свой milter. какие результаты, кроме соотношения удачных/неуданых проверок нужны?

А вот это уже очень интересно. Не поделитесь с общественностью ?