Всё о о Microsoft Exchange Server и электронной почте.

Война между 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. все это ерунда, технологии – это всего лишь инструмент для зарабатывания денег, не этим должен жить человек, не для этого его создавала природа.

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

  • cognize@

    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

  • http://www.exchangerus.ru Pavel Nagaev

    ну вот, отправили от 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 отправляющей системы.

  • http://www.exchangerus.ru Pavel Nagaev

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

  • cognize@

    Pavel.

    Это не content filter.

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

    Это Reverse NDR attacks. -)

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

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

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

  • http://www.exchangerus.ru Pavel Nagaev

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

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

  • cognize@

    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.

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

  • http://www.exchangerus.ru Pavel Nagaev

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

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

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

  • cognize@

    Pavel.

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

  • Beigood

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

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

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

  • http://www.exchangerus.ru Pavel Nagaev

    ээээ, выводов тут быть не может 🙂

  • vinni

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

  • http://www.exchangerus.ru Pavel Nagaev

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

  • vinni

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

  • продажа форвардеров « Эхо блогосферы

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

  • Прохожий

    > Еще наковырял, что mail from: нужно запретить.

    За это сразу следует бить линейкой по пальцам, канделябром и т.п. Читайте RFC 5321 (в 821 и 2821 это тоже было)

    6.1. Reliable Delivery and Replies by Email

    If there is a delivery failure after acceptance of a message, the
    receiver-SMTP MUST formulate and mail a notification message. This
    notification MUST be sent using a null («») reverse-path in the
    envelope.

    Развели недоучек… Извините, наболело.

    Что касается грейлистинга, он не будет мешать каллбэку, если его применять не после MAIL FROM, а после DATA. Как и в каком MTA это сделать, вопрос отдельный, я знаю, как это сделать в Sendmail посредством Milter.