Этот блог посвящен MS Exchange, Outlook и проблемам, связанным с электронной почтой

Война между DNSBL/Greylisting и Callback verification продолжается

Как-то я уже писал про эту проблему, но сегодня история получила продолжение. Сотрудник нашей компании отправил сообщение на один из серверов и получил сообщение об ошибке. Оно представлено ниже.


From: System Administrator
Sent: Wednesday, December 10, 2008 3:11 PM
To: Berkova, Elena

Subject: Undeliverable: RE:

Your message did not reach some or all of the intended recipients.

      Subject:            RE:

      Sent:  10/12/2008 12:10

The following recipient(s) could not be reached:

      iff@onedomain.com on 10/12/2008 15:11

            You do not have permission to send to this recipient.  For assistance, contact your system administrator.

            <myserver.mydomain.ru.ru #5.7.1 smtp;550 5.7.1 <iff@onedomain.com>… Rejecting due to security policy — Unable to validate Sender address <elena.berkova@mydomain.ru>, Please see: http://www.server.ru/policy.html#invalidsender>

 

         Поскольку это мой пользователь и мне нужно “ехать” (помните доклад на Платформе? :-) ), то нужно было произвести анализ ситуации и понять что делать. Сразу видно, что сервер получателя пытается проверить адрес отправителя и не может это сделать. Скорее всего используется метод Callback verification, cсылка указанная в сообщении конечно же не работала.

       Проблема заключалась в том, что на моем сервере используется два врага этого метода – DNSBL и Greylisting. В обоих случаях соединение получающего сервера отбивается во время проверки отправителя на моем сервере. Что делать? Решения два:

  1. Звонить админу и говорить, что его сервер работает не правильно(вопрос очень спорный :-) ) или просить выключить эту проверку для нашего сервера/домена
  2. Взять ситуацию в свои руки, мне же надо “ехать” и добавить сервер получателя в мой белый список, чтобы мои фильтры не применялись к этому серверу, когда он пытается выполнить проверку

         Второе решение более простое. Поскольку я знаю, как работают мои фильтры, то добавить исключение для IP получателя было просто и почта заработала.

Выводы:

  • из-за побочных эффектов технологий и их настроек опять пострадали пользователи
  • не понятно кто прав. Тот админ или я, у каждого своя правда
  • у технологий борьбы со спамом есть не только плюсы, а еще и минусы
  • я довольно быстро нашел решение, т.к. знал работу фильтров и знал куда добавить IP адрес. А Вы точно знаете как работает ваша почтовая система и фильтры?
  • хорошо, что сталкивался с подобной проблемой раньше, разобрался с механизмом работы  и записал это в блог

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

Похожие посты:

clock 11 Декабрь 2008, 10:24 comment Комментариев: 64



Комментариев: 64 к “Война между DNSBL/Greylisting и Callback verification продолжается”

  1. cognize@:
    11 Декабрь 11, 2008 г. в 10:37

    Хуже спама может быть только борьба со спамом.

    На мой взгляд greylisting не эффективен в организациях, для которых электронная почта — основной рабочий инструмент. Имхо — это система для малюсеньких организаций.

    Скажите как сработает фильтр Вашей системы, если:

    1)будет письмо для двух адресатов, в котором есть «скрытая копия»
    2)Один из получателей в данном письме не должен попадать под фильтры

    или отправитель из Вашего же домена ?


  2. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 10:40

    О каком фильтре идет речь?


  3. cognize@:
    11 Декабрь 11, 2008 г. в 10:42

    Вы же не хотите сказать что используете только DNSBL/Greylisting ?

    Мне интересно как Ваша система борьбы со спамом обработает письма с данными условиями.


  4. Павел:
    11 Декабрь 11, 2008 г. в 11:07

    cognize, у меня в месяц около 2,6 млн. попыток влить почту. Каков на ваш взгляд размер нашей организации? Статистика показывает высокую эффективность грейлистинга! Вот мои цифры:

    HELO Blacklist
    37,21

    Recipient Validation
    28,11

    Greylisting
    14,68

    DNS Blacklists
    13,75

    SPF Test
    2,69

    External Agents
    0,47

    Recipient Blacklist
    0,23

    IP Blacklist
    0,22

    SURBLs
    0,21

    Sender Blacklist
    0,15

    Reverse DNS
    0,15

    Keyword Filtering
    0,07

    Приведите свою статистику, сравним.


  5. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 11:14

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

    Хорошо, что Вы привели статистику. Я этим не заморачивался, надо будет скриптов понаписать для анализа.


  6. cognize@:
    11 Декабрь 11, 2008 г. в 11:26

    Павел, у меня нет цифр — есть факты. Люди практически не получают спама. А технология серых списков не эффективна (имхо/на мой взгляд — заметили акцент ?) Как часто люди остаются без нужной корреспонденции ? В выходные/ночью/праздники будете делать исключения фильтров? Это был вопрос а не показуха вида «у кого Exchange больше». У вас не ORF случаем установлен ?

    И раз ввязались в дискуссию — приведите ответ на поставленый вопрос с условиями.

    Как фильтры реагируют на blind carbon copy ?


  7. MrGonzales:
    11 Декабрь 11, 2008 г. в 11:58

    Павел, помоему это очередной (cognize) спамер пытается выведать секреты, не говорите ему ничего :)


  8. Михаил:
    11 Декабрь 11, 2008 г. в 12:27

    Павел, подскажите, где в exch07 настраивается фильтр HELO Blacklist
    или его нужно создавать самому?

    подскажите, как это сделать.


  9. Rept-Tile:
    11 Декабрь 11, 2008 г. в 12:40

    А у меня такой вопрос по поводу самого Callback.
    У меня SMTP Outbound gateway и MX — это две разные, слабо связанные между собой системы. И первый отшибает все соединения извне по 25-му порту.
    Какие мысли по этому поводу? Были где-нибудь уже дискуссии? (Сорри, новенький я на этом ресурсе, а со временем жесткая напряженка.


  10. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 12:48

    «Люди практически не получают спама.» это Вы про свою систему? Очень хорошо, расскажите, как такого можно добиться.
    Про взгляд конечно заметил и это вполне нормально, мы все строим системы и у каждого просто обязано быть свое мнение.

    Из моего опыта спама становится значительно меньше после DNSBL и Greylisting, но есть побочные эффекты.
    «выходные/ночью/праздники» — вот это как раз и называется требования к почтовой системе. Иногда сталкиваюсь с тем, что некоторые почтовые системы завалились и никто их не поднимает и не знает об этом. Это совсем другие требования.

    Blind Carbon copy — это уровень доменов. DNSBL — уровень соединения. Соответственно, если фильтрация произойдет на уровне соединения, то до уровня доменов просто не дойдет.

    Если сервер находится в DNSBL, то я могу оперировать списком белых IP, но не  получателей/отправителей доменов.

    В случае Greylisting. Тут работа уже идет на уровне доменов, анализируется три параметра — IP, отправитель, получатель. В моей реализации Greylisting под Linux можно оперировать доменами.

    Что касается bcc. В моей системе почта попадает из Интернет на Linux, а процесс бифуркация происходит после, при попадания письма на Exchange

    Моя антиспам система  не умеет выкусывать заблокированных получателей из письма или наоборот, доставлять «спам» письма избранным пользователям. Хотя еще поиграюсь, возможно это можно настроить.


  11. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 12:49

    Rept-Tile, Вы вопрос задайте по нормальному :-)


  12. cognize@:
    11 Декабрь 11, 2008 г. в 13:03

    Pavel — ответа так и не услышал и наверное удивлю если скажу не один Вы используете MailGate. Можно мне придраться к словам ? -) Почта падает не на Linux а на MTA ) Скорее всего используете postfix — угадал ? -) И даже догадываюсь какой graylisting.

    «Blind Carbon copy — это уровень доменов. DNSBL — уровень соединения. Соответственно, если фильтрация произойдет на уровне соединения, то до уровня доменов просто не дойдет.»  Не ошибаетесь ? А если дойдёт до соединения ?

    «Что касается bcc. В моей системе почта попадает из Интернет на Linux, а процесс бифуркация происходит после, при попадания письма на Exchange» Какие различия между bcc и Blind Carbon copy ? Не придираюсь, мне интерсно Ваше понимание. И не совсем понял есть ли антиспам фильтры (помимо helo_access и check_rbl)

    «Моя антиспам система  не умеет выкусывать заблокированных получателей из письма или наоборот, доставлять “спам” письма избранным пользователям. Хотя еще поиграюсь, возможно это можно настроить.» Тогда вообще не понятно что это за система такая. Эксперимент с задаными условиями опробовали ? Что получилось ? А почему ? -)

    Ссылаясь на Ваш пост о предстоящем походе на платформу и поправок касающихся «крутых выскачек» отмечу — мои вопросы заданы ради спортивного интереса -)


  13. Rept-Tile:
    11 Декабрь 11, 2008 г. в 13:26

    Pavel Nagaev, виноват. Перманентная запарка, посему и слог хромает. :)
    Обсуждался ли уже вопрос насчет Sender callback verification в том случае, когда у отправителя используются разные хосты для приема и отправки почты? В этом случае проверка отправителя со стороны сервера, использующего Callback, заранее обречена на неудачу.
    Не нашлось ли наработанных методов борьбы с такой ситуацией (кроме звонка админу-коллбэкщику)?


  14. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 13:53

    to Rept-Tile: все зависит от реализации механизма Callback. Для его выполнения серверу необходимо установить SMTP сессию с сервером отправителям и логично искать этот сервер по MX. У меня такая же, как у Вас система и проверка осуществлялась на сервере с первым MX.

    to cognize@:
    Вы не один из тех, кто поднял руку, что поборол спам? Если да, то расскажите cекрет успеха, я тоже так хочу.
    К словам если хотите — придирайтесь, конечно на MTA и конечно postfix.

    «Не ошибаетесь ? А если дойдёт до соединения?» Не понял что имели ввиду. Мне не хочется гадать, напишите свою версию алгоритма работы.

    По моему это одно и то же «bcc и Blind Carbon copy» если нет, то напишите, что Вы имеете ввиду.

    Еще есть контент фильтр.
    Эксперимент проделал.  Результаты написал выше — «не умеет».


  15. Rept-Tile:
    11 Декабрь 11, 2008 г. в 14:28

    Pavel Nagaev,
    > установить SMTP сессию с сервером отправителям и логично искать этот сервер по MX
    Каким образом, можно поподробнее? У принимающего SMTP-сессию из достоверной информации есть IP передающего (т.к. имя хоста в HELO легко подделать спамерам, и для реализации Callback вряд ли разумно использовать этот аргумент).

    Так какова будет цепочка, чтобы выяснить IP другого сервера - MX, готового принять Callback-письмо?


  16. Павел:
    11 Декабрь 11, 2008 г. в 14:42

    cognize, отвечаю на ваш вопрос заданный в первом коментарии. Получатель, для которого greylisting запрещен, получит сообщение в первую попытку отправки сообщения, остальные получатели — во вторую.


  17. cognize@:
    11 Декабрь 11, 2008 г. в 14:45

    Pavel.

    «Вы не один из тех, кто поднял руку, что поборол спам? Если да, то расскажите cекрет успеха, я тоже так хочу.» Не говорю «совсем не получают» — есть же оговорка «практически».

    «“Не ошибаетесь ? А если дойдёт до соединения?” Не понял что имели ввиду. Мне не хочется гадать, напишите свою версию алгоритма работы.» Имелось ввиду что будет если RBL пропустит письмо.

    «По моему это одно и то же “bcc и Blind Carbon copy” если нет, то напишите, что Вы имеете ввиду.» Конечно одно и тоже.Хотелось узнать понимаем ли мы друг друга.

    «Еще есть контент фильтр.
    Эксперимент проделал.  Результаты написал выше — “не умеет”.» У Postfix к сожалению нет деректив для фильтров по полю bcc. Контент фильтр наверняка spamassassin или dspam — так же бессильны.

    В Вашей организации внешними пользователями используется доступ к smtp для отправки ? Это касаемого второго вопроса о отправителе Вашего же домена.


  18. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 14:46

    неправильно. Механизм Callback работает на основании домена из адреса отправителя и IP тут не причем. Механизм может запускаться и после RCPT TO, но не важно.

    После того, как получен  адрес отправителя принимающий сервер должен найти сервер отправителя и сымитировать отправку на сервере отправителя. Если она прошла, то значит отправитель валидный.

    Механизмы DNSBL, если ваш сервер в блек листах или Greylist не дадут код 250 после ввода mail to на отправляющем сервере.

    Поиск отправляющего будет искаться по MX для домена


  19. cognize@:
    11 Декабрь 11, 2008 г. в 14:48

    Павел — а если greylisting включен то что тогда ? Вы не поняли вопроса — greylisting тут не причём.


  20. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 14:57

    мои пользователи используют SMTP, для этого есть специальный SMTP сервер, который принимает шифрованные и авторизованные коннекты, поэтому из Интернета у меня запрещено принимать почту из моего домена. Вся почта генериться внутри моей системы и может только уходить наружу.


  21. cognize@:
    11 Декабрь 11, 2008 г. в 14:59

    Pavel.

    Тогда переходим ко второму вопросу:

    Скажите как сработает фильтр Вашей системы, если отправитель с адресом Вашего же домена ?


  22. Rept-Tile:
    11 Декабрь 11, 2008 г. в 15:01

    Pavel Nagaev,
    > Механизм Callback работает на основании домена из адреса отправителя и IP тут не причем

    Гм. Тогда получается, что например у Exim — какой-то неправильный Callback. Потому что он лезет тупо по IP передающего и пытается что-то сунуть на 25-й порт моему исходящему.

    ОК, спасибо за разъяснения. Хотя это лишь самый простой вопрос. Далее перед механизмом Callback должны встать те же проблемы, которые уже много лет стоят перед SPF. Например, хостинг списков рассылки во внешнем домене, форвардинг без замены Return-Path.. И прочие сладости.


  23. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 15:15

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


  24. cognize@:
    11 Декабрь 11, 2008 г. в 15:21

    Pavel.

    Видимо плохо почтавил вопрос.

    Подробней командами для наглядности (аля от внешнего отправителя)

    telnet mail.com 25
    helo mail.com
    mail from: test@mail.com
    rcpt to: test@mail.com

    Что будет ?

    И в догонку — как боретесь с undisclosed-recipients ?


  25. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 15:26

    mail from:me@mydomain.ru
    250 Ok
    rcpt to:me@mydomain.ru
    554 me@mydomain.ru Sender address rejected: Access from this sender disabled by administrator!

    Обработка mail from происходит после rcpt to и Вы видите, что письмо реджектится с 554

    По поводу undisclosed-recipients- никак не борюсь, т.к. не до конца понимаю что это такое. Расскажите, плиз.


  26. Павел:
    11 Декабрь 11, 2008 г. в 15:32

    cognize, сформулируйте свой вопрос более четко, т.к. в своем первом коментарии вы упоминаете greylisting, а теперь, оказывается, что вы имели в виду что-то другое.


  27. cognize@:
    11 Декабрь 11, 2008 г. в 15:33

    Sender address rejected: Access from this sender disabled by administrator! Это для всех адресов Вашего домена ?

    «По поводу undisclosed-recipients- никак не борюсь, т.к. не до конца понимаю что это такое. Расскажите, плиз.» Как понятно из названия undisclosed-recipients — это «на закрытые получатели» :)

    Почтовые клиенты обязаны их закрывать -

    rcpt to:me@mydomain.ru; — двоеточием с запятой.

    Многие почтовые роботы не соблюдают это — поэтому можно оградить себя от некого кол-ва спама данного рода.


  28. cognize@:
    11 Декабрь 11, 2008 г. в 15:35

    Павел.

    Читайте внимательней:

    Скажите как сработает фильтр Вашей системы, если:
    1)будет письмо для двух адресатов, в котором есть “скрытая копия”
    2)Один из получателей в данном письме не должен попадать под фильтры
    Упор делается на недостаток многих систем борьбы со спамом.


  29. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 14:55

    Если включен грейлистинг, то callback не пройдет, т.к.
    => RCPT TO: <n@sender.ru>
    <= 451 : Recipient address rejected: Greylisted, see http://fff.fff.ru/greylist.htm

    Проверяющий сервер вместо 250 получит 451. Это не значит, что пользователя нет, но и не 250, поэтому проверка не пройдет.
    Возможно, что современные системы Callback знают про грейлистинг и подобный ответ может приравниваться к 250, но это предположения


  30. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 16:02

    Sender address rejected: Access from this sender disabled by administrator! Это для всех адресов Вашего домена ?

    Для всех. Что не так?


  31. Pavel Nagaev:
    11 Декабрь 11, 2008 г. в 16:03

    Павел: и Pavel Nagaev  — разные люди


  32. cognize@:
    11 Декабрь 11, 2008 г. в 16:08

    Pavel.

    «Павел: и Pavel Nagaev  — разные люди» — это понятно, поэтому и обращаюсь

    Павел
    Pavel

    -)

    «Для всех. Что не так?» — всё так. просто уточнил.


  33. Павел:
    11 Декабрь 11, 2008 г. в 16:12

    cognize, ответ такой же, см. пункт 16. Нет разницы где указан получатель: в To, Cc, Bcc. Эти поля используются только для (не)отображения адресов в почтовом клиенте.


  34. cognize@:
    11 Декабрь 11, 2008 г. в 16:30

    Павел.

    Давайте рассмотрим схему подробней:

    Отправляется одно письмо для двух получателей.

    Первый получатель (стоит в поле TO) исключён из действия фильтров (фильтры для него выключены)

    Второй получатель (стоит в поле bcc) получает почту только после прохождения письма через спам фильтры (фильтры для него включены)

    Кто в таком случае получит письмо и почему ?


  35. Павел:
    11 Декабрь 11, 2008 г. в 16:54

    Оба получателя получат письма (конечно, если сообщение для второго не будет заблокировано). Message-ID и дата/время отправления будут у них одинаковые, дата/время получения может быть разное. Что вас смущает?

    Черт, уже надоело арифметикой заниматься…


  36. cognize@:
    11 Декабрь 11, 2008 г. в 17:28

    Павел, не нервничайте -)

    Давайте без теории — Вы проверили данную схему в работе ? А если для второго адресата сработает фильтр ? И с чего вдруг дата/время получения будет разная ?

    Арифметикой никто не просит заниматься — дискуссию вести не обязательно.


  37. Павел:
    11 Декабрь 11, 2008 г. в 17:50

    cognize, да, проверял. Если для второго сработает фильтр, то первый получит, а второй нет. Время получения может отличаться из-за работы greylisting’a.

    Не коментарии, а форум получился…


  38. a_tyan:
    11 Декабрь 11, 2008 г. в 18:24

    System,Uptime,228d 07:08:09,0d 01:48:12
    System,Spam ratio,98%,85%
    Before Arrival,Tested,13645364,719
    Before Arrival,Allowed,1510967,76
    Before Arrival,Ignored,1036905,479
    Before Arrival,Blacklisted,11097492,164
    Before Arrival,Spam ratio,88%,68%
    Before Arrival,IP whitelist,Tests: 12806852 / Hits: 26052,Tests: 723 / Hits: 306
    Before Arrival,Sender whitelist,Tests: 11304589 / Hits: 62613,Tests: 304 / Hits: 67
    Before Arrival,Auto sender whitelist,Tests: 10981687 / Hits: 53704,Tests: 234 / Hits: 102
    Before Arrival,Recipient whitelist,Tests: 11241976 / Hits: 56014,Tests: 237 / Hits: 3
    Before Arrival,DNS whitelist,Tests: 11132258 / Hits: 5,Tests: 132 / Hits: 0
    Before Arrival,HELO blacklist,Tests: 732544 / Hits: 4,Tests: 132 / Hits: 0
    Before Arrival,SPF test,(disabled),(disabled)
    Before Arrival,IP blacklist,Tests: 732540 / Hits: 47,Tests: 132 / Hits: 0
    Before Arrival,Sender blacklist,Tests: 732493 / Hits: 5,Tests: 132 / Hits: 0
    Before Arrival,Recipient blacklist,Tests: 2256312 / Hits: 0,Tests: 417 / Hits: 0
    Before Arrival,Recipient validation,Tests: 2256312 / Hits: 1476211,Tests: 417 / Hits: 113
    Before Arrival,Reverse DNS,Tests: 719303 / Hits: 873,Tests: 87 / Hits: 0
    Before Arrival,Greylisting,Tests: 9300686 / Hits: 9217339,Tests: 63 / Hits: 32
    Before Arrival,DNSBL: AHBL,Tests: 731586 / Hits: 0,Tests: 132 / Hits: 0
    Before Arrival,DNSBL: CBL,Tests: 731583 / Hits: 392018,Tests: 132 / Hits: 24
    Before Arrival,DNSBL: SPAMCOP,Tests: 339565 / Hits: 9803,Tests: 108 / Hits: 0
    Before Arrival,DNSBL: SPAMHAUS-SBLXBL,Tests: 137568 / Hits: 1197,Tests: 108 / Hits: 0

    Это статистика ORF, который стоит на нашем почтовом серваке. Если грейлистинг выключить, спама повалит немеренно, только он спасает. Единственный недостаток грейлистинга — это задержка доставки. Грейлистинг к Callback verification никакого отношения не имеет, во всяком случае в ORF никаких проблем не наблюдается.


  39. kpmedia:
    11 Декабрь 11, 2008 г. в 18:31

    Расскажу про себя. Практика показала неэффективность применения BL и использования sender verify. Их применение при больших объемах почты приводит к ложным положительным срабатываниям.

    Введение грейлистинга себя показало гораздо лучше.


  40. MrGonzales:
    11 Декабрь 11, 2008 г. в 18:39

    поделюсь и я статистикой.
    1 Сервер:

    System    Uptime    84d 01:57:59    9d 02:14:20
    System    DNS lookups    23121897    1629605
    System    DNS timeouts    75516    3118
    System    Spam ratio    100%    100%
    Before Arrival    Tested    10567767    789823
    Before Arrival    Allowed    39735    3877
    Before Arrival    Ignored    125380    16525
    Before Arrival    Blacklisted    10402652    769421
    Before Arrival    Spam ratio    100%    99%
    Before Arrival    IP whitelist    Tests: 10499958 / Hits: 13837    Tests: 780832 / Hits: 1707
    Before Arrival    Sender whitelist    Tests: 4479626 / Hits: 19438    Tests: 303913 / Hits: 2826
    Before Arrival    Auto sender whitelist    Tests: 4460188 / Hits: 24189    Tests: 301087 / Hits: 2973
    Before Arrival    Recipient whitelist    Tests: 4460188 / Hits: 0    Tests: 301087 / Hits: 0
    Before Arrival    DNS whitelist    Tests: 4435814 / Hits: 97    Tests: 298114 / Hits: 18
    Before Arrival    HELO blacklist    (disabled)    (disabled)
    Before Arrival    SPF test    Tests: 4435880 / Hits: 147124    Tests: 298093 / Hits: 13438
    Before Arrival    IP blacklist    (disabled)    (disabled)
    Before Arrival    Sender blacklist    (disabled)    (disabled)
    Before Arrival    Recipient blacklist    (disabled)    (disabled)
    Before Arrival    Recipient validation    Tests: 10486121 / Hits: 6006495    Tests: 779125 / Hits: 475212
    Before Arrival    Reverse DNS    Tests: 4288778 / Hits: 1939432    Tests: 284658 / Hits: 116467
    Before Arrival    Greylisting    Tests: 208503 / Hits: 168807    Tests: 14258 / Hits: 10381
    Before Arrival    DNSBL: SORBS-ALL    Tests: 256774 / Hits: 48067    Tests: 14962 / Hits: 704
    Before Arrival    DNSBL: SPAMCOP    Tests: 266994 / Hits: 10291    Tests: 15483 / Hits: 521
    Before Arrival    DNSBL: SPAMHAUS-ZEN    Tests: 1902163 / Hits: 1771140    Tests: 168191 / Hits: 152708
    On Arrival    Tested    126141    15503
    On Arrival    Allowed    30993    3364
    On Arrival    Ignored    88390    11662
    On Arrival    Blacklisted    6758    477
    On Arrival    Spam ratio    18%    12%
    On Arrival    IP whitelist    Tests: 40818 / Hits: 3067    Tests: 4701 / Hits: 860
    On Arrival    Sender whitelist    Tests: 78778 / Hits: 19549    Tests: 9094 / Hits: 1972
    On Arrival    Auto sender whitelist    Tests: 24629 / Hits: 24628    Tests: 3123 / Hits: 3123
    On Arrival    Recipient whitelist    Tests: 0 / Hits: 0    Tests: 0 / Hits: 0
    On Arrival    DNS whitelist    (disabled)    (disabled)
    On Arrival    HELO blacklist    (disabled)    (disabled)
    On Arrival    SPF test    (disabled)    (disabled)
    On Arrival    IP blacklist    (disabled)    (disabled)
    On Arrival    Sender blacklist    (disabled)    (disabled)
    On Arrival    Recipient blacklist    (disabled)    (disabled)
    On Arrival    Recipient validation    (disabled)    (disabled)
    On Arrival    Reverse DNS    (disabled)    (disabled)
    On Arrival    Keyword whitelist    Tests: 37751 / Hits: 0    Tests: 3841 / Hits: 0
    On Arrival    Keyword blacklist    Tests: 37751 / Hits: 361    Tests: 3841 / Hits: 63
    On Arrival    Attachment blacklist    (disabled)    (disabled)
    On Arrival    Charset blacklist    (disabled)    (disabled)
    On Arrival    User-defined URL domain blacklist    Tests: 39688 / Hits: 0    Tests: 3941 / Hits: 0
    On Arrival    SURBL: MULTI-SURBL    Tests: 26332 / Hits: 3242    Tests: 2571 / Hits: 228
    On Arrival    SURBL: UB-BLACK    Tests: 23090 / Hits: 3155    Tests: 2343 / Hits: 186


  41. MrGonzales:
    11 Декабрь 11, 2008 г. в 18:40

    2 сервер.
    System    Uptime    92d 11:18:39 15d 04:55:27
    System    DNS lookups    5788490    530111
    System    DNS timeouts    14832    1025
    System    Spam ratio    100%    100%
    Before Arrival    Tested    7462781 724466
    Before Arrival    Allowed    14311    1243
    Before Arrival    Ignored    24608    4067
    Before Arrival    Blacklisted    7423862    719156
    Before Arrival    Spam ratio    100%    100%
    Before Arrival    IP whitelist    Tests: 7462786 / Hits: 1218    Tests: 724475 / Hits: 298
    Before Arrival    Sender whitelist    Tests: 1095082 / Hits: 3384    Tests: 101144 / Hits: 1131
    Before Arrival    Auto sender whitelist    Tests: 1089384 / Hits: 19895    Tests: 100013 / Hits: 2636
    Before Arrival    Recipient whitelist    Tests: 1091698 / Hits: 0    Tests: 100013 / Hits: 0
    Before Arrival    DNS whitelist    Tests: 1044901 / Hits: 107    Tests: 97377 / Hits: 2
    Before Arrival    HELO blacklist    (disabled)    (disabled)
    Before Arrival    SPF test    Tests: 1067750 / Hits: 36430    Tests: 97374 / Hits: 3564
    Before Arrival    IP blacklist    Tests: 542 / Hits: 0    (disabled)
    Before Arrival    Sender blacklist    Tests: 6264 / Hits: 0    (disabled)
    Before Arrival    Recipient blacklist    Tests: 47200 / Hits: 0    (disabled)
    Before Arrival    Recipient validation    Tests: 7457258 / Hits: 6366486    Tests: 724177 / Hits: 623033
    Before Arrival    Reverse DNS    Tests: 1031291 / Hits: 486605    Tests: 93811 / Hits: 38599
    Before Arrival    Greylisting    Tests: 78431 / Hits: 69370    Tests: 4185 / Hits: 2942
    Before Arrival    DNSBL: SORBS-ALL    Tests: 352169 / Hits: 128847    Tests: 4524 / Hits: 339
    Before Arrival    DNSBL: SPAMCOP    Tests: 226635 / Hits: 64975    Tests: 4684 / Hits: 160
    Before Arrival    DNSBL: SPAMHAUS-ZEN    Tests: 206682 / Hits: 190102    Tests: 55212 / Hits: 50528
    On Arrival    Tested    28505    3495
    On Arrival    Allowed    8461    925
    On Arrival    Ignored    16222    2494
    On Arrival    Blacklisted    3822    76
    On Arrival    Spam ratio    31%    8%
    On Arrival    IP whitelist    Tests: 21440 / Hits: 585    Tests: 4496 / Hits: 253
    On Arrival    Sender whitelist    Tests: 27975 / Hits: 1056    Tests: 3242 / Hits: 376
    On Arrival    Auto sender whitelist    Tests: 20447 / Hits: 20447    Tests: 2628 / Hits: 2628
    On Arrival    Recipient whitelist    Tests: 0 / Hits: 0    Tests: 0 / Hits: 0
    On Arrival    DNS whitelist    (disabled)    (disabled)
    On Arrival    HELO blacklist    Tests: 3099 / Hits: 0    (disabled)
    On Arrival    SPF test    Tests: 1207 / Hits: 30    (disabled)
    On Arrival    IP blacklist    Tests: 3074 / Hits: 0    (disabled)
    On Arrival    Sender blacklist    Tests: 3074 / Hits: 0    (disabled)
    On Arrival    Recipient blacklist    Tests: 3796 / Hits: 0    (disabled)
    On Arrival    Recipient validation    Tests: 242 / Hits: 225    (disabled)
    On Arrival    Reverse DNS    Tests: 3040 / Hits: 1130    (disabled)
    On Arrival    Keyword whitelist    Tests: 12110 / Hits: 0    Tests: 1001 / Hits: 0
    On Arrival    Keyword blacklist    Tests: 12110 / Hits: 57    Tests: 1001 / Hits: 56
    On Arrival    Attachment blacklist    Tests: 8689 / Hits: 0    Tests: 2722 / Hits: 0
    On Arrival    Charset blacklist    Tests: 0 / Hits: 0    Tests: 0 / Hits: 0
    On Arrival    User-defined URL domain blacklist    Tests: 13845 / Hits: 0    Tests: 2048 / Hits: 0
    On Arrival    SURBL: MULTI-SURBL    Tests: 7682 / Hits: 613    Tests: 1091 / Hits: 14
    On Arrival    SURBL: UB-BLACK    Tests: 7288 / Hits: 371    Tests: 1077 / Hits: 6


  42. cognize@:
    12 Декабрь 12, 2008 г. в 12:25

    Доброе утро Pavel&Павел.

    Предлагаю продолжить вчерашнюю игру -)

    Итак. Усложним вторую задачу.

    1) Ваш домен (mail.com) запрещает приём писем от внешних получателей с адресом Вашего домена (user@mail.com)
    2)Проверка telnet на 25 порт Вашего внешнего сервера  с внешнего ip адреса имеет вид:
    telnet mail.com 25
    helo mail.com
    250 mail.com
    mail from:user@mail.com
    250 Ok
    rcpt to:user@mail.com
    554 <user@mail.com>: Sender address rejected: Access denied

    Но пользователи иногда жалуются что получают спам от самих себя же.

    (в полях сообщения From и To указан адрес user@mail.com)

    Вопрос:

    Как такое возможно ? И как с этим бороться.

    -)

    Сразу оговорюсь — проблему/решение знаю и могу привести ссылки.


  43. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 12:31

    Мне нужно посмотреть на само письмо, но мне кажется ответ кроется в P1 и P2? Так? Это когда адрес отправителя прописывается внутри письма и Outlook при наличии его отобразит именно его первым, а если он не указан, то возьмет из Internet Header.


  44. cognize@:
    12 Декабрь 12, 2008 г. в 12:33

    п1 и п2 — условия, которые только для подсказки.

    Internet Header содержит идентичные from и to (хотя это  запрещено)


  45. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 12:40

    Мой ответ не правильный? P1 и P2 — это не пункты из вашего вопроса.
    P1 — это отправитель из MAIL FROM:
    P2 — это отправитель в message header(не Internet header)

    http://blogs.msdn.com/tzink/archive/2008/03/23/the-concept-of-safe-senders.aspx

    Таким образом mail from(P1) может быть любым, а но в письме пользователь увидет P2, который может быть именем пользователя

    Другое в голову пока не приходит
    увидеть


  46. kpmedia:
    12 Декабрь 12, 2008 г. в 12:53

    Мы были закрыты от возможности получать письма «снаружи» от адресов с «нашими» доменами. Но, есть сервисы blackberry, есть отправка почты с гугля и т.д., где пользователи хотят иметь возможность проставлять from от внутренней почты. Пришлось отказаться.


  47. cognize@:
    12 Декабрь 12, 2008 г. в 14:02

    Pavel.

    Ваш ответ не правильный. Есть ещё идеи ?


  48. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 14:08

    Мой ответ правильный и на ваш вопрос он подходит тоже. Просто у Вас другое решение.

    Пользователи получают спам через внутренние серверы, спам от внутренних пользователей? У меня правда SMTP для внутренней сети закрыт.
    NDR не подходят.
    Честно говоря у меня идей нет и мне очень интересно какой же будет ответ.


  49. cognize@:
    12 Декабрь 12, 2008 г. в 14:13

    Pavel.

    Если рассматривать ситуацию, то ответ не тот.

    Спам от внешних пользователей.

    Почему NDR не подходят ? Это близко к ответу.


  50. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 15:19

    MAIL FROM:<> ? Но как же тогда имя пользователя подставляется? P2?


  51. cognize@:
    12 Декабрь 12, 2008 г. в 15:25

    Pavel.

    Вот заголовок сообщения:

    Received: from mail.com (10.0.1.1) by mail.com
    (192.168.0.244) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008
    14:11:49 +0300
    Received: by mail.mail.com ( MAILER, from userid 1004)    id
    1DA2A4ACFE; Fri, 12 Dec 2008 13:15:35 +0200 (EET)
    X-Spam-Checker-Version: SpamAssassin  (2008-06-10) on mail.com
    X-Spam-Level:
    X-Spam-Status: No, score=-82.0 required=1.5 tests=BAYES_50,HTML_FONT_LOW_CONTRAST,HTML_IMAGE_ONLY_08,HTML_MESSAGE,HTML_SHORT_LINK_IMG_1,MIME_HTML_ONLY,MISSING_OUR_TO_CC,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,URIBL_AB_SURBL,URIBL_BLACK,URIBL_JP_SURBL,URIBL_RHS_DOB,URIBL_SC_SURBL,USER_IN_ALL_SPAM_TO autolearn=no
    Received: from acgk13.neoplus.adsl.tpnet.pl (acgk13.neoplus.adsl.tpnet.pl
    [83.9.238.13])    by mail.mail.com (MAILER) with SMTP id
    9490D4ACB9    for <user@mail.com>; Fri, 12 Dec 2008 13:15:25 +0200 (EET)
    To: <user@mail.com>
    Subject: Your order
    From: <user@mail.com>
    MIME-Version: 1.0
    Importance: High
    Content-Type: text/html
    Message-ID: <20081212111525.9490D4ACB9@mail.mail.com>
    Date: Fri, 12 Dec 2008 13:15:25 +0200
    Return-Path: lorraine@afc-ais.com


  52. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 16:54

    ну вот, отправили от P1= lorraine@afc-ais.com,  а в P2 = user@mail.com, поэтому фильтр не обрабатывал, т.к.  lorraine@afc-ais.com и оно не совпало с вашим доменом. Хм, а как же быть тогда….. надо подумать. Получается это должен конетент фильтр смотреть именно адрес отправителя и маркировать спам или транспортный агент.

    Памятка для меня самого:
    Я отправил письмо от имени pan@asdfsadf.com
    P2 написал «Pavel Nagaev»<pan@exchangerus.ru>

    В Internet Header написано вот как.
    from: «Pavel Nagaev»<pan@exchangerus.ru>
    Bcc:
    Return-Path: pan@asdfsadf.com

    Т.к. P1 становится Return-Path:, а P2 перемещается в From:

    Еще наковырял, что mail from:<>  нужно запретить. Если это будет полноценный NDR, то в качестве отправителя будет postmaster отправляющей системы.


  53. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 16:54

    Кстати, тема хорошо развилась, надо будет все в кучу собрать и пост написать


  54. cognize@:
    12 Декабрь 12, 2008 г. в 17:10

    Pavel.

    Это не content filter.

    И в условиях было что не postmaster, а %username%

    Это Reverse NDR attacks. -)

    Для Postfix http://www.postfix.org/BACKSCATTER_README.html

    Для Exchange http://support.microsoft.com/kb/886208

    Если интересно, то можно продолжить игру с вопросами по обработки фильтров Postfix.


  55. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 17:15

    Читать то, что мы тут понаписали, конечно полная жесть. Но давайте продолжим, это заставляет мозги больше работать. Вчера у меня было закипание и вечером пришлось долго смотреть на звезды :-)

    Вы кстати чем занимаетесь? Postfix?


  56. cognize@:
    12 Декабрь 12, 2008 г. в 17:43

    Pavel.

    И Postfix и Exchange и ещё много чем -)

    По поводу мозговых разминок согласен — другим наверняка было интересно почитать.

    Задача №3 (ведь этот сайт не только о Exchange, но и о электронной почте)

    В main.cf Postfix существуют следующие директивы

    body_checks = regexp:/etc/postfix/body_checks

    smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access,
    …

    Заданные параметры для данных фалов:

    /etc/postfix/access
    user@domainltd.com OK

    /etc/postfix/body_checks
    /chat.ru/       REJECT

    Внешний пользователь (user@domainltd.com) отправляет письмо в теле которого есть chat.ru на Ваш Postfix.

    Что произойдёт и почему ? -)


  57. Pavel Nagaev:
    12 Декабрь 12, 2008 г. в 18:00

    Вау, это вопрос на знание postfix и регулярных выражений, к сожалению я ни в том ни в том не силен.

    1. Сначала пойдет проверка отправителя. Тут нужно знать логику работы postfix, вполне возможно, что после этой проверки остальные фильтры могут и не проверяться. Типа белый список пройден.
    2. Если же дойдет до второй проверки, то /chat.ru/   было бы лучше сделать  /chat\.ru/, хотя точка — это любой символ, поэтому может и прокатит.
    Соответственно если будет вхождение, то произойдет на уровне SMTP после команды DATA.

    Но еще раз повторяю, я эти системы почти не знаю.


  58. cognize@:
    12 Декабрь 12, 2008 г. в 18:10

    Pavel.

    Директивы header, body, mime cheks не предусматривают исключений по определённым отправителям/доменам/ip адресам, поэтому письмо будет отброшено. Хотя есть дополнителья опция filter: — она перенаправляет на самописный скрипт попавшие под критерий письма — но это отдельная тема -)


  59. Beigood:
    16 Декабрь 16, 2008 г. в 10:53

    Ну, гуру, вы даете!

    Читать это — в самом деле — жесть!!!

    Хотелось бы увидеть обобщение и выводы какие-нибудь по данной теме ;)


  60. Pavel Nagaev:
    16 Декабрь 16, 2008 г. в 17:18

    ээээ, выводов тут быть не может :-)


  61. vinni:
    17 Декабрь 17, 2008 г. в 05:29

    ИМХО, то, на что Вы (Pavel Nagaev) «напоролись» — косяк разработчиков продукта. На мой взгляд, ответы от GreyListing, SPF и т.п. надо «объявлять» после команды DATA. При таком раскладе «тот» сервер спокойно сделает CBV, скажет RSET и «уйдёт довольным».


  62. Pavel Nagaev:
    17 Декабрь 17, 2008 г. в 09:54

    Я бы не стал так утверждать, что это «косяк разработчиков продукта». Уверен, что все эти варианты рассматривались и по этому поводу в Микрософт собирали не один митинг. Из моего опыта общения с Микрософт о «неверной», с моей точки зрения, логики работы программ, мне дали понять, чтоне все так просто. Они всегда смотрят на то, как это поведение скажется в распределенных сетях на большом количестве сообщений. Возможно у них были свои доводы оставить алгоритм работы именно таким.
    Но это все мои предположения.


  63. vinni:
    17 Декабрь 17, 2008 г. в 12:53

    Да это не только у MS. Например, в том же MDaemon’e аналогичные вещи тоже меняются (справедливости ради) в лучшую сторону, но черепашьими темпами. Те «косяки», которые мне приходилось «латать» в 8-ой версии, в 10 вылечены всего процентов на 80. То есть они движутся в _ту_ сторону, но не сразу по всем параметрам, а только по наиболее проблемным позициям (например, таки перенесли проверку PTR Lookup на стадию после возможной авторизации клиента и т.п.)


  64. продажа форвардеров « Эхо блогосферы:
    1 Август 1, 2010 г. в 17:33

    [...] Pavel Nagaev пишет: Организации, которые делают деньги на продаже почтовых услуг, не могут позволить себе использование greylisting, т.к. вышеупомянутые проблемы могут отпугнуть клиентов. Поэтому им вообще лучше почту не трогать и возложить борьбу со спамом на …. Хотя это лишь самый простой вопрос. Далее перед механизмом Callback должны встать те же проблемы, которые уже много лет стоят перед SPF. Например, хостинг списков рассылки во внешнем домене, форвардинг без замены Return-Path. … [...]