Почему у Сбербанка некорректная SPF-запись для домена?

    Кратко: у основного домена Сбербанка (sberbank.ru) некорректная SPF-запись. Это приводит к тому, что у злоумышленников есть возможность делать фальшивые рассылки электронной почты от имени Сбербанка. Сама запись настроена хорошо, годно, но с ошибкой, сводящей к нулю все усилия.

    > host -t txt sberbank.ru
    sberbank.ru descriptive text "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"
    

    Счастливый финал: в течение дня запись исправили, теперь она соответствует RFC.

    > host -t txt sberbank.ru
    sberbank.ru descriptive text "v=spf1 mx -all"
    

    Ну, а для тех кто осилит прочитать — добро пожаловать под кат.

    Зачем нужен SPF?


    SPF помогает бороться с подделкой адресов отправителя. Не путайте SPF c DMARC, SPF позволяет только установить, мог ли данный IP-адрес отправлять почту от имени вот того домена (с поддержкой целого ряда исключений и реверансов).

    Существует мнение, что SPF не нужен и вреден, однако как показывает практика, SPF на сегодня есть основной механизм в DMARC и пока на горизонте ничего подобного нет.

    Как это работает?


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

    И что, реально работает?


    Ну, в целом, не совсем. Изначально в SPF был предусмотрен тип записи, который позволяет делать Softfail. Это как бы косяк, но простительный. То есть, я говорю, что почта от моего домена может идти с вот этих адресов, тогда она точно нормальная. И если с каких-то других, то это ничего, простительно.

    Вот эта извинительная приписка вообще на сегодня практически сводит к нулю толк от SPF, поскольку спамеры часто в эту извинительную приписку попадают.

    В чем Сбербанк молодец?


    А в том, что у них запись содержит -all, это как раз недопущение извинительного Softfail. То есть, ребята из Сбера как бы говорят нам, что почта от них может идти только с заданных адресов и никак иначе. Молодцы, это здорово.

    А в чем же Сбербанк ошибся?


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

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

    Да где же ошибка?


    RFC 7208 вводит некоторые ограничения на количество DNS-запросов, которые должен сделать почтовый сервер, чтобы получить нужные данные в SPF. Оно же самое RFC ограничивает количество запросов с пустым результатом или ошибкой.

    Разбираем запись:

    "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"

    0. v=spf1

    Версия SPF-записи, т.е. синтаксис

    1. mx

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

    > host -t mx sberbank.ru
    sberbank.ru mail is handled by 50 shark11.sberbank.ru.
    sberbank.ru mail is handled by 50 shark14.sberbank.ru.
    sberbank.ru mail is handled by 50 email1.sberbank.ru.
    sberbank.ru mail is handled by 50 shark12.sberbank.ru.
    sberbank.ru mail is handled by 50 shark13.sberbank.ru.

    Хорошо, видим эти пять серверов.

    2. mx:shark11.sberbank.ru

    Почту от домена sberbank.ru могут отправлять те серверы, что перечислены, как MX для домена shark11.sberbank.ru

    СТОП! Ещё раз.

    Почту от домена sberbank.ru могут отправлять те серверы, что перечислены, как MX для домена shark11.sberbank.ru

    > host -t mx shark11.sberbank.ru
    shark11.sberbank.ru has no MX record

    И вот этот результат засчитывается, как пустой. А по RFC, после первых двух таких ошибок надо прекратить анализировать SPF-запись и посчитать ее ошибочной. Что и происходит.

    Короче говоря, ребята немного перестарались.

    Как надо было сделать?


    "v=spf1 mx -all"


    А может коллеги сделали лучше?


    На самом деле, сам Сбербанк редко шлет письма, вернее, в нашей почтовой системе их, например, не так много. Гораздо больше их приходит от площадки «Сбербанк АСТ», давайте посмотрим туда.

    > host -t txt sberbank-ast.ru
    sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru ~all"

    А тут, увы, Softfail. Что сводит к нулю ценность SPF-записи.

    UPDATE
    Коллеги из «Сбербанк АСТ» отреагировали быстро. Теперь вот так:

    > host -t txt sberbank-ast.ru
    "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all"

    По сути, конечно, несколько избыточно, поскольку есть указание mx и

    > host -t mx sberbank-ast.ru
    sberbank-ast.ru descriptive text sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.

    Но переключение с ~all на -all достойно всяческой похвалы.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 43

      0
      Походу у сбербанка еще и dkim нет))
        0
        Знаю, что шансов мало (я их и сам когда-то просил включить HSTS на online.sberbank.ru, о чём получил классический ответ ни о чём), но вы всё-таки попробовали бы написать им в саппорт.
          +3
          Да, разумеется, отписано.
          0

          Ух ты, это вы ловко нашли! За статью спасибо, ошибка действительно достойна огласке.
          Интересно, если указать тупо ip-адреса, запись работать будет?

            +2
            Если тупо — нет.
            Надо делать согласно RFC.
            0
            Ребят, ну Сбербанк же. Понять, простить и отпустить.
              0
              Любая пересылка будет сводить ценность SPF-записи к нулю.
              А касательно сбербанка — вся действительно ценная переписка с ними идёт через клиент-банк. В том числе — и для физлиц.

                0
                SRS отлично работает, поэтому первое утверждение неверно.

                А вот по поводу действительно ценной переписки — не забывайте, что фишинг никто не отменял. Банку жить без -all нельзя.
                  0
                  Посмотрел топ10 банков, жесткий -all прописан только у 4, включая Сбер.
                  У остальных или ~all или вовсе не прописана SPF.

                  Как же они так? И есть ли вообще какая-то реакция на письма, попадающие в эту «извинительную приписку», там, пропустить, но накинуть немного спам-очков? Если этот механизм такой хороший, зачем бояться прописывать "-all"? Что-то тут не чисто.
                    0
                    Да в этом и проблема, что накидывание спам-очков крайне осложнено. Из моего опыта достаточного количества почты в сутки, с Softfail ее достаточно много, порядка 40%. Всем накидывать не будешь.

                    SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.

                    Как результат, имеем что имеем.
                      0
                      А откуда так много нормальной-ненормальной почты, из-за пересылок? Т.е spf де-факто не работает (хотя задумка хорошая)?
                      Вон и гмейла даже: «v=spf1 include:_spf.google.com ~all»
                        0
                        Специально посмотрел, правда, без глубокого анализа. Практически один спам у меня идет в Softfail.

                        Вернее, я допускаю, что там есть легитимная пересылаемая почта. Но крайне мало.
                  0
                  И да, спасибо, добавил в статью ссылку.
                  0
                  Сбербанк для рассылок пользуется сторонними сервисами. Меня спамят от sendsay.ru

                  Сложно сказать, какая SPF запись была на момент ноября 15 года на sberbank.ru, но проверку spamassassin`а прошла:
                  Заголовки письма от sberbank.ru
                  Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=194.186.207.32; helo=shark13.sberbank.ru; envelope-from=sberbank@modified.mail; receiver=my@modified.mail
                  Received: from Shark13.sberbank.ru (shark13.sberbank.ru [194.186.207.32])
                  by mail.modified.domain (Postfix) with ESMTPS id 3C7451E058D
                  for <my@modified.mail>; Mon, 16 Nov 2015 15:40:00 +0300 (MSK)
                  Received: from SPRING11.sigma.sbrf.ru (10.21.7.66) by Shark13.sberbank.ru
                  (10.21.6.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Nov 2015
                  15:36:35 +0300
                  Received: from Ocean16.sigma.sbrf.ru ([fe80::1480:e5a9:4888:1b2f]) by
                  spring11.sigma.sbrf.ru ([::1]) with mapi id 14.03.0248.002; Mon, 16 Nov 2015
                  15:34:43 +0300
                  From: <sberbank@modified.mail>
                  To: <my@modified.mail>
                  Date: Mon, 16 Nov 2015 12:34:42 +0000
                  Message-ID: <Ocean16.sigma.sbrf.ru>
                  Accept-Language: ru-RU, en-US
                  Content-Language: ru-RU
                  X-MS-Has-Attach:
                  X-MS-TNEF-Correlator:
                  x-originating-ip: [10.21.6.242]
                  x-kse-antivirus-interceptor-info: scan successful
                  x-kse-antivirus-info: Clean
                  Content-Type: text/plain; charset=«windows-1251»
                  Content-Transfer-Encoding: quoted-printable
                  MIME-Version: 1.0
                  X-KSE-AntiSpam-Interceptor-Info: internally-submitted e-mail

                    0
                    Теперь не смогут отправлять отправлять через sendsay, если не добавят запись в SPF. вообще имея большую аудиторию клиентов, не хорошо использовать сторонние сервисы для рассылок!
                      0
                      Ну в комментарии приведен кусочек рассылки, которая не шла через sendsay.

                      А вообще, для сторонних сервисов внесут исключения, нет проблем.
                        0
                        Да, надо было сразу пояснить про рассылку. Она, естественно, имеет другой источник и сбербанковская SPF не используется. Письмо приходит с «левого» домена. Для того чтобы представиться правильно подставляется поле From: <vip@sberbank.ru>. SPF проверяется у gluck@mail.sendsay.ru и он естественно проходит проверку. Стандартный почтовый финт. Письмо даже под пристальным просмотром в почтовом клиенте не выдаст отправителя. Везде красуется только сбербанк.

                        SPF запись mail.sendsay.ru
                        host -t txt mail.sendsay.ru
                        mail.sendsay.ru descriptive text "v=spf1 include:spf.sendsay.ru -all"

                        host -t txt spf.sendsay.ru
                        spf.sendsay.ru descriptive text "v=spf1 +ip4:81.9.34.128/25 +ip4:81.222.129.0/24 +ip4:81.222.217.0/24 +ip4:81.222.133.0/24 +ip4:81.9.46.0/24 +ip4:185.138.180.0/22 +ip4:185.76.232.0/22 +ip6:2a07:b40::/29 +ip6:2a05:5dc0::/29 ?all"



                        Заголовки письма от sendsay
                        Return-Path: <gluck@mail.sendsay.ru>
                        Delivered-To: my@modified.mail
                        Received: by mail.mymodified.domain (Postfix, from userid 5000)
                        id 953391E0C46; Fri, 6 May 2016 16:25:33 +0300 (MSK)
                        X-Spam-Checker-Version: SpamAssassin 3.3.1 on mail.mymodified.domain
                        X-Spam-Level: **
                        X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_60,HTML_MESSAGE,
                        MIME_HTML_ONLY,SPF_PASS,T_DKIM_INVALID autolearn=no version=3.3.1
                        Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=81.222.129.23; helo=gato23.subscribe.ru; envelope-from=gluck@mail.sendsay.ru; receiver=my@modified.mail
                        Received: from gato23.subscribe.ru (gato23.subscribe.ru [81.222.129.23])
                        by mail.mymodified.domain (Postfix) with ESMTPS id 93E8A1E058D
                        for <my@modified.domain>; Fri, 6 May 2016 16:25:31 +0300 (MSK)
                        Received: id AE94ED3048A-1462541096
                        X-rpcampaign: sberbankimport2016050417203320160506162217
                        DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.sendsay.ru; s=sendsay.201502;
                        t=1462541096; bh=2M2ZxWnNlr3C6M3dajHUsSMlNsxmEYYNHW5ImW/0RXE=;
                        h=X-Felis-Queue-Id:Precedence:List-Id:List-Issue:List-Unsubscribe:
                        List-Subscribe:List-Archive:List-Post:X-Felis-L:Date:Message-Id:
                        From:To:Subject:X-Mailru-Msgtype:MIME-Version:Content-Type;
                        b=fLWfzPX32i0Ygnk6ZTLFqhH6szzpFzbp1RZ5zFnVNJPrZYuB9K+FNFgjzKwYHXa9+
                        AvF/hyu3pHH2nO+S5qPoFwiqbh4V2YxJMfxiKLS12zSLWBbtIHp7CkNcL/T+ZrO02j
                        TMf2zrY12VUuynT+ysMD0U5oAsc8gHBKc0N7hr/A=
                        List-Subscribe: NO
                        List-Archive: NO
                        List-Post: NO
                        Date: Fri, 6 May 2016 16:24:56 +0300
                        From: =?utf-8?Q?=D0=A1=D0=91=D0=95=D0=A0=D0=91=D0=90=D0=9D=D0=9A=20?=
                        =?utf-8?Q?=D0=A0=D0=9E=D0=A1=D0=A1=D0=98=D0=98?= <vip@sberbank.ru>
                        To: <my@modified.mail>
                        Subject: modified subject
                        X-Mailru-Msgtype: sendsay.sberbank
                        MIME-Version: 1.0
                        Content-Type: text/html;
                        charset=«utf-8»


                        SPF запись spasibosb.ru
                        host -t txt spasibosb.ru
                        spasibosb.ru descriptive text "v=spf1 a:mail.spasibosb.ru a:mail.cplsb.ru a:mail2.spasibosb.ru a:bounce.sbspasibo.ru ip4:91.224.14.146 ip4:91.224.14.200 ip4:95.213.151.27 include:sbspasibo.ru include:bounce.sbspasibo.ru -all"


                        Заголовки письма от spasibosb.ru
                        Return-Path: <modified@bounce.sbspasibo.ru>
                        Delivered-To: my@modified.mail
                        Received: by mail.mymodified.domain(Postfix)
                        id BE0121E0C82; Tue, 16 Aug 2016 15:40:29 +0300 (MSK)
                        X-Spam-Checker-Version: SpamAssassin 3.3.1 on mail.mymodified.domain
                        X-Spam-Level:
                        X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,HTML_MESSAGE,
                        RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=ham
                        version=3.3.1
                        Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=91.224.14.146; helo=mail.sbspasibo.ru; envelope-from=modified@bounce.sbspasibo.ru; receiver=my@modified.mail
                        Received: from mail.sbspasibo.ru (mail.sbspasibo.ru [91.224.14.146])
                        by mail.mymodified.domain(Postfix) with ESMTPS id 92AC81E0BDB
                        for <my@modified.mail>; Tue, 16 Aug 2016 15:40:23 +0300 (MSK)
                        DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spasibosb.ru; s=mail;
                        h=Content-Type:MIME-Version:Date:Subject:To:From:Message-ID; bh=aGfLJMVn2kKxAKHClN1oq2a4vKIcmp0ESRFwfj6gs3o=;
                        b=ovEiBzv7qrG7Kb+a1jbe7XtXMLXKCm1u0o6ngORTVZoVqndPDT0z/sTUnD4PeKwtUlYj/IBlcjNNpr9nDwUJ5o8Ad338Xhrmdt6ZPkhtr4DdDZ7c8ojxUMDEmIx3x6V/JKMGoIStWE3IgQ/S7MW4Tka1q4V+V6yGd7BNoTkxtrcG2gtIynd6AukZKfCW7u1MRZbawZ8QGYsMj7Qbg0ZJfuALL0pxhtc3XbfdXlpEzfw1E+ckUyyYpwk7YwSG9IMpeksKV0jywIuTAp51JDtl04znUSaG9TjMvzHNRuT+FjktbYhTcP8gULn5RsasoZVXJMW9Qd1YANX5f4Kbhwjkjw==;
                        From: "=?utf-8?B?0KHQv9Cw0YHQuNCx0L4g0L7RgiDQodCx0LXRgNCx0LDQvdC60LAh?=" <digest@spasibosb.ru>
                        To: <my@modified.mail>
                        Subject: =?utf-8?B?0JTQviAyMCUg0KHQn9CQ0KHQmNCR0J4g0LfQsCDQv9C+0LrRg9C/0Lo=?=
                        =?utf-8?B?0Lgg0Log0YjQutC+0LvQtQ==?=
                        Date: Tue, 16 Aug 2016 15:43:34 +0300
                        MIME-Version: 1.0
                        Content-Type: multipart/alternative;


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

                      Это не так.

                      Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
                      Во-вторых, механизмы в записи проверяются слева направо. Это означает, что в случае валидной почты от Сбера письмо пройдет успешную проверку по механизму «mx».
                      В-третьих, если почта пришла с невалидного хоста, то действительно дальше пойдут пустые запросы, однако стандарт рекомендует возвращать permerror после пары таких, а не обязывает. Учитывая, что этот RFC относительно свежий и абсолютное большинство имплементаций почтовых серверов разрабатывались и внедрялись до его публикации — утверждение «у большинства почтовых систем… письмо просто пропускается» нуждается, как минимум, в дополнительном обосновании.
                        0
                        Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).


                        Результатом проверки такой записи является Permerror. Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04 и посмотрим туда.

                        # A permanent error has occured (eg. badly formatted SPF record)
                        PermError_reject = False

                        Т.е. никакого Reject не будет, письмо пойдет дальше. Кроме того, обычно работа с SPF не есть работа почтового сервера. В подавляющем большинстве случаев это делается некой внешней утилитой (неважно, как вызываемой), которая вполне себе может поддерживать RFC 7208 от 2014 года.

                        SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.

                        Вообще, если посмотрите, то политика в отношении SPF-проблем крайне мягкая, это если брать конфиги по-умолчанию. У Сбера же применяется -all, что означает «жестить и никаких гвоздей».
                          +1
                          > Результатом проверки такой записи является Permerror.

                          Ещё раз — это не так. Для валидного письма будет pass. Для невалидного — permerror, но только в том случае, если принимающая сторона зачем-то имплементирует рекомендации свеженького RFC, не оглядываясь на окружающий мир, который много лет до его появления жил по другим правилам.

                          > Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04

                          Зачем? Какой процент почтовых серверов в мире работает на дефолтном конфиге Ubuntu 16.04? Плюс речь совершенно не о том, как реагировать на permerror, а о том, будет ли этот permerror вообще, или парсер всё-таки сделает больше двух запросов и вернет fail.

                          > SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.

                          Вы можете видеть или не видеть, но «большинство» почтовых систем, поведение которых вы пытаетесь предсказать, разработано и сконфигурировано не вами.

                          SHOULD — This word, or the adjective «RECOMMENDED», mean that there may exist valid reasons in particular circumstances to ignore a particular item

                          Возможно, «много лет рекомендации RFC были иными» — для вас не valid reason, но вот за других я бы говорить не взялся. Не говоря уж о том, что выход нового RFC сам по себе совершенно не приводит к тому, что все внезапно бросились переписывать свои парсеры.
                            0
                            Я же говорю еще раз, проверка SPF — это обычно дело внешней сущности. Которая может (и нужет) обновляться.

                            Про «большинство» не вижу смысла спорить, поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
                              +2
                              > поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».

                              Разница в том, что вы позволяете себе делать утверждения насчет этого большинства, на самом деле вообще ничего о нем не зная. Спорить в этом случае действительно смысла нет — надо либо проверять то, что утверждаете, либо не выдавать придуманное за действительное. Технически верной фразой было бы что-то типа «SPF-запись Сбера корректно проходит проверку в случае валидного письма, но поддельное письмо, в соответствии с текущим стандартом и в зависимости от имплементации стандарта конкретным почтовым сервисом, может давать результат проверки permerror и пропускаться как валидное».
                        0
                        Сбербанк-АСТ видимо поправили
                         host -t txt sberbank-ast.ru 
                        sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all"
                        
                          0
                          Да, и правда поправили. Немного избыточно, правда.

                          > host -t mx sberbank-ast.ru
                          sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.

                          Тогда mail4 можно было бы не добавлять в список.

                          Но -all радует. Это хорошо.
                            +1
                            Честно говоря так и не понял вашей радости от "-all"… Объективная польза от SPF близка к гомеопатической. Прописывать ее конечно нужно, а вот выставлять "-all" я бы не советовал…
                            Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?
                              0
                              Для случаев пересылки есть SRS, который вполне себе хорошо работает. Если пересылающий не умеет им пользоваться, то ССЗБ.

                              Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.

                              Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.
                                0
                                Спасибо за быстрый ответ. Отвечу по пунктам:

                                SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…

                                SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…

                                200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:

                                Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)
                                  0
                                  Спасибо за развернутый ответ.

                                  Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.

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

                                  Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).

                                  В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.

                                  А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.

                                  А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.
                                    0
                                    Мой опыт/ощущение «фишинга» — если в вкратце — техника тут бессильна: пользователи заполняют формуляры и кликают на ссылки в письмах которые, мне кажется, даже в пятном угаре нельзя принять за настоящие. Недавно то-ли на семинаре то ли в частной обсуждении слышал любопытную гипотезу:

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

                                    SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?

                                      0
                                      Про фишинг соглашусь, но мое мнение, что зловредам нужно максимально усложнить жизнь. SPF тут помогает.

                                      Про SpamCop: мы с ними общаемся напрямую, на адрес noc пишут. А про DNS — посмотрите тут последние три вопроса-ответа. Очень забавляет :)
                                        0
                                        Помню их FAQ, читал. Но они про DSN то и пишут — может быть «злом» но тем не менее это часть стандарта. Лет 5-10 было у меня пару запросов на эту тему (может и от них уж не помню сейчас). Ответил кратко «DSN is mandatory part of RFC.» и развернуто «если проблема столь острая можете делать по простому: дискардить любые входящие ДСНы (глупость), или можете делать по интеллектуальному: дискардить входящие ДСНы для которых нет соответствующих исходящих писем». Если проблема может быть решена на стороне клиента то там она и должна решаться…
                                        0
                                        Про фишинг, с матаном и всем таким.
                            +9
                            Пишут в правилах Хабра, что «Хабр — не жалобная книга», но де-факто Хабр — вообще единственная стабильно работающая жалобная книга рунета. Описанную здесь ошибку пофиксят с вероятностью около 100%.
                              0
                              Вы совершенно правы, в течение дня изменения внесли. Хотя на мое письмо так и не ответили. Шапку поста обновил.
                              +1
                              Ну так и почему у Сбербанка некорректная SPF-запись для домена? Вы рассказали в чем заключается некорректность, но на вопрос «почему» так и не ответили.
                                0
                                Вы задали прекрасный вопрос. Признаюсь, я ожидал его раньше :)

                                У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.

                                1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.

                                2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
                                +2
                                -all для SPF выявляет интересную багофичу у mail.ru — при переадресации почты с mail.ru «куда-нибудь», они оставляют адрес отправителя исходным, а сервер получателя видит соединение с почтового сервера mail.ru и -all в SPF, где этот сервер не обозначен. В итоге ящик-получатель после такой переадресации просто не получает письмо и режет его как спам.
                                  +2
                                  Зато у них антиспам на Tarantool, что им до какого-то SPF :)
                                    0
                                    дак может и это увидят и пофиксят…
                                      0
                                      Это общеизвестная проблема SPF. Чинится она внедрением SRS. Однако он на данный момент не имеет статус стандарта, а является только черновиком. Его реализация может испортить репутацию домена, поэтому многие (в том числе gmail: https://support.google.com/mail/answer/175365?hl=en) не рекомендуют его использовать в последнее время. Для верификации писем рекомендуется использовать DMARC, использование только SPF очень часто приводит к False Positive.
                                      Тем не менее, спасибо за репорт. В одном из следующих релизов мы проведем тестирование SRS.
                                      0
                                      Я думаю жопа у кого-то сейчас красная, так опозориться на всю страну. Может другие домены тоже проверить? :)
                                      • UFO just landed and posted this here

                                        Only users with full accounts can post comments. Log in, please.