Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Походу у сбербанка еще и dkim нет))
Знаю, что шансов мало (я их и сам когда-то просил включить HSTS на online.sberbank.ru, о чём получил классический ответ ни о чём), но вы всё-таки попробовали бы написать им в саппорт.
Ух ты, это вы ловко нашли! За статью спасибо, ошибка действительно достойна огласке.
Интересно, если указать тупо ip-адреса, запись работать будет?
Ребят, ну Сбербанк же. Понять, простить и отпустить.
Любая пересылка будет сводить ценность SPF-записи к нулю.
А касательно сбербанка — вся действительно ценная переписка с ними идёт через клиент-банк. В том числе — и для физлиц.
А касательно сбербанка — вся действительно ценная переписка с ними идёт через клиент-банк. В том числе — и для физлиц.
SRS отлично работает, поэтому первое утверждение неверно.
А вот по поводу действительно ценной переписки — не забывайте, что фишинг никто не отменял. Банку жить без -all нельзя.
А вот по поводу действительно ценной переписки — не забывайте, что фишинг никто не отменял. Банку жить без -all нельзя.
Посмотрел топ10 банков, жесткий -all прописан только у 4, включая Сбер.
У остальных или ~all или вовсе не прописана SPF.
Как же они так? И есть ли вообще какая-то реакция на письма, попадающие в эту «извинительную приписку», там, пропустить, но накинуть немного спам-очков? Если этот механизм такой хороший, зачем бояться прописывать "-all"? Что-то тут не чисто.
У остальных или ~all или вовсе не прописана SPF.
Как же они так? И есть ли вообще какая-то реакция на письма, попадающие в эту «извинительную приписку», там, пропустить, но накинуть немного спам-очков? Если этот механизм такой хороший, зачем бояться прописывать "-all"? Что-то тут не чисто.
Да в этом и проблема, что накидывание спам-очков крайне осложнено. Из моего опыта достаточного количества почты в сутки, с Softfail ее достаточно много, порядка 40%. Всем накидывать не будешь.
SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.
Как результат, имеем что имеем.
SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.
Как результат, имеем что имеем.
И да, спасибо, добавил в статью ссылку.
Сбербанк для рассылок пользуется сторонними сервисами. Меня спамят от sendsay.ru
Сложно сказать, какая SPF запись была на момент ноября 15 года на sberbank.ru, но проверку spamassassin`а прошла:
Сложно сказать, какая 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
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
Теперь не смогут отправлять отправлять через sendsay, если не добавят запись в SPF. вообще имея большую аудиторию клиентов, не хорошо использовать сторонние сервисы для рассылок!
Ну в комментарии приведен кусочек рассылки, которая не шла через sendsay.
А вообще, для сторонних сервисов внесут исключения, нет проблем.
А вообще, для сторонних сервисов внесут исключения, нет проблем.
Да, надо было сразу пояснить про рассылку. Она, естественно, имеет другой источник и сбербанковская 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»
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;
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;
> Это вызывает ошибку Permerror, и тогда у большинства почтовых систем запись даже не проверяется, а письмо просто пропускается.
Это не так.
Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Во-вторых, механизмы в записи проверяются слева направо. Это означает, что в случае валидной почты от Сбера письмо пройдет успешную проверку по механизму «mx».
В-третьих, если почта пришла с невалидного хоста, то действительно дальше пойдут пустые запросы, однако стандарт рекомендует возвращать permerror после пары таких, а не обязывает. Учитывая, что этот RFC относительно свежий и абсолютное большинство имплементаций почтовых серверов разрабатывались и внедрялись до его публикации — утверждение «у большинства почтовых систем… письмо просто пропускается» нуждается, как минимум, в дополнительном обосновании.
Это не так.
Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Во-вторых, механизмы в записи проверяются слева направо. Это означает, что в случае валидной почты от Сбера письмо пройдет успешную проверку по механизму «mx».
В-третьих, если почта пришла с невалидного хоста, то действительно дальше пойдут пустые запросы, однако стандарт рекомендует возвращать permerror после пары таких, а не обязывает. Учитывая, что этот RFC относительно свежий и абсолютное большинство имплементаций почтовых серверов разрабатывались и внедрялись до его публикации — утверждение «у большинства почтовых систем… письмо просто пропускается» нуждается, как минимум, в дополнительном обосновании.
Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Результатом проверки такой записи является 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, что означает «жестить и никаких гвоздей».
> Результатом проверки такой записи является 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 сам по себе совершенно не приводит к тому, что все внезапно бросились переписывать свои парсеры.
Ещё раз — это не так. Для валидного письма будет 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 сам по себе совершенно не приводит к тому, что все внезапно бросились переписывать свои парсеры.
Я же говорю еще раз, проверка SPF — это обычно дело внешней сущности. Которая может (и нужет) обновляться.
Про «большинство» не вижу смысла спорить, поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
Про «большинство» не вижу смысла спорить, поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
> поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
Разница в том, что вы позволяете себе делать утверждения насчет этого большинства, на самом деле вообще ничего о нем не зная. Спорить в этом случае действительно смысла нет — надо либо проверять то, что утверждаете, либо не выдавать придуманное за действительное. Технически верной фразой было бы что-то типа «SPF-запись Сбера корректно проходит проверку в случае валидного письма, но поддельное письмо, в соответствии с текущим стандартом и в зависимости от имплементации стандарта конкретным почтовым сервисом, может давать результат проверки permerror и пропускаться как валидное».
Разница в том, что вы позволяете себе делать утверждения насчет этого большинства, на самом деле вообще ничего о нем не зная. Спорить в этом случае действительно смысла нет — надо либо проверять то, что утверждаете, либо не выдавать придуманное за действительное. Технически верной фразой было бы что-то типа «SPF-запись Сбера корректно проходит проверку в случае валидного письма, но поддельное письмо, в соответствии с текущим стандартом и в зависимости от имплементации стандарта конкретным почтовым сервисом, может давать результат проверки permerror и пропускаться как валидное».
Сбербанк-АСТ видимо поправили
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"
Да, и правда поправили. Немного избыточно, правда.
Тогда mail4 можно было бы не добавлять в список.
Но -all радует. Это хорошо.
> host -t mx sberbank-ast.ru
sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.
Тогда mail4 можно было бы не добавлять в список.
Но -all радует. Это хорошо.
Честно говоря так и не понял вашей радости от "-all"… Объективная польза от SPF близка к гомеопатической. Прописывать ее конечно нужно, а вот выставлять "-all" я бы не советовал…
Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?
Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?
Для случаев пересылки есть SRS, который вполне себе хорошо работает. Если пересылающий не умеет им пользоваться, то ССЗБ.
Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.
Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.
Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.
Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.
Спасибо за быстрый ответ. Отвечу по пунктам:
SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…
SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…
200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:
Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)
SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…
SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…
200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:
Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)
Спасибо за развернутый ответ.
Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.
Во вторую очередь это можно считать борьбой со спамом, но с рядом оговорок.
Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).
В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.
А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.
А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.
Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.
Во вторую очередь это можно считать борьбой со спамом, но с рядом оговорок.
Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).
В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.
А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.
А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.
Мой опыт/ощущение «фишинга» — если в вкратце — техника тут бессильна: пользователи заполняют формуляры и кликают на ссылки в письмах которые, мне кажется, даже в пятном угаре нельзя принять за настоящие. Недавно то-ли на семинаре то ли в частной обсуждении слышал любопытную гипотезу:
Фишеры специально оставляют массу «аномалий/ошибок» в своих письмах/формулярах — это психологический прием позволяет отсечь «слишком умных» — их трудно «разводить», они могут поднять тревогу, и.т.д.
SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?
Фишеры специально оставляют массу «аномалий/ошибок» в своих письмах/формулярах — это психологический прием позволяет отсечь «слишком умных» — их трудно «разводить», они могут поднять тревогу, и.т.д.
SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?
Про фишинг соглашусь, но мое мнение, что зловредам нужно максимально усложнить жизнь. SPF тут помогает.
Про SpamCop: мы с ними общаемся напрямую, на адрес noc пишут. А про DNS — посмотрите тут последние три вопроса-ответа. Очень забавляет :)
Про SpamCop: мы с ними общаемся напрямую, на адрес noc пишут. А про DNS — посмотрите тут последние три вопроса-ответа. Очень забавляет :)
Помню их FAQ, читал. Но они про DSN то и пишут — может быть «злом» но тем не менее это часть стандарта. Лет 5-10 было у меня пару запросов на эту тему (может и от них уж не помню сейчас). Ответил кратко «DSN is mandatory part of RFC.» и развернуто «если проблема столь острая можете делать по простому: дискардить любые входящие ДСНы (глупость), или можете делать по интеллектуальному: дискардить входящие ДСНы для которых нет соответствующих исходящих писем». Если проблема может быть решена на стороне клиента то там она и должна решаться…
Пишут в правилах Хабра, что «Хабр — не жалобная книга», но де-факто Хабр — вообще единственная стабильно работающая жалобная книга рунета. Описанную здесь ошибку пофиксят с вероятностью около 100%.
Ну так и почему у Сбербанка некорректная SPF-запись для домена? Вы рассказали в чем заключается некорректность, но на вопрос «почему» так и не ответили.
Вы задали прекрасный вопрос. Признаюсь, я ожидал его раньше :)
У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.
1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.
2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.
1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.
2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
-all для SPF выявляет интересную багофичу у mail.ru — при переадресации почты с mail.ru «куда-нибудь», они оставляют адрес отправителя исходным, а сервер получателя видит соединение с почтового сервера mail.ru и -all в SPF, где этот сервер не обозначен. В итоге ящик-получатель после такой переадресации просто не получает письмо и режет его как спам.
Зато у них антиспам на Tarantool, что им до какого-то SPF :)
дак может и это увидят и пофиксят…
Это общеизвестная проблема SPF. Чинится она внедрением SRS. Однако он на данный момент не имеет статус стандарта, а является только черновиком. Его реализация может испортить репутацию домена, поэтому многие (в том числе gmail: https://support.google.com/mail/answer/175365?hl=en) не рекомендуют его использовать в последнее время. Для верификации писем рекомендуется использовать DMARC, использование только SPF очень часто приводит к False Positive.
Тем не менее, спасибо за репорт. В одном из следующих релизов мы проведем тестирование SRS.
Тем не менее, спасибо за репорт. В одном из следующих релизов мы проведем тестирование SRS.
Я думаю жопа у кого-то сейчас красная, так опозориться на всю страну. Может другие домены тоже проверить? :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему у Сбербанка некорректная SPF-запись для домена?