Як цей електронний лист підриває перевірки SPF?


13

Я запускаю поштовий сервер, який, як видається, правильно обробляє електронні листи з набором SPF - однак я почав отримувати підроблені електронні листи, що вважаються від банку - з адресою From, встановленою як банк, але які точно не походять від банку.

Відповідні заголовки електронного листа:

Delivered-To: me@mydomain.name
Received: from mail.mydomain.org (localhost [127.0.0.1])
    by mail.mydomain.org (Postfix) with ESMTP id AD4BB80D87
    for <user@mydomain.com>; Thu, 13 Oct 2016 20:04:01 +1300 (NZDT)
Received-SPF: none (www.tchile.com: No applicable sender policy available) receiver=mydomain.org; identity=mailfrom; envelope-from="apache@www.tchile.com"; helo=www.tchile.com; client-ip=200.6.122.202
Received: from www.tchile.com (www.tchile.com [200.6.122.202])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by mail.mydomain.org (Postfix) with ESMTPS id 40F6080B9F
    for <user@mydomain.com>; Thu, 13 Oct 2016 20:03:57 +1300 (NZDT)
Received: from www.tchile.com (localhost.localdomain [127.0.0.1])
    by www.tchile.com (8.13.1/8.13.1) with ESMTP id u9D73sOG017283
    for <user@mydomain.com>; Thu, 13 Oct 2016 04:03:55 -0300
Received: (from apache@localhost)
    by www.tchile.com (8.13.1/8.13.1/Submit) id u9D73smu017280;
    Thu, 13 Oct 2016 04:03:54 -0300
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3
X-Virus-Scanned: ClamAV using ClamSMTP

Ключовим тут є те, що kiwibank.co.nz є законним, авторитетним банком, з якого я родом, і має запис SPF, який говорить:

kiwibank.co.nz.     13594   IN  TXT "v=spf1 include:_spf.jadeworld.com ip4:202.174.115.25 ip4:202.126.81.240 ip4:202.12.250.165 ip4:202.12.254.165 ip4:66.231.88.80 include:spf.smtp2go.com include:spf.protection.outlook.com -all"

Отже, після деякого читання - виявляється, що «Енволопа-Від» правильна, але «З» підроблена. Чи є спосіб я виправити / пом’якшити це, не порушуючи "загальну" електронну пошту? Зауважу, що я використовую Postfix, Spamassassin та policyd (postfix-policyd-spf-perl) - і якщо його дійсно так просто обійти, у чому сенс SPF?

Відповіді:


13

У цьому випадку вони, ймовірно, сказали вашому серверу щось подібне:

EHLO www.tchile.com
MAIL FROM: apache@www.tchile.com 
RCPT TO: user@mydomain.com
DATA
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3
X-Virus-Scanned: ClamAV using ClamSMTP

The contents of mail...
.

SMTP-розмова (яка називається "конверт") може мати різні заголовки від / до, ніж електронні адреси. SPF не перевіряє заголовок, однак це завжди заголовок, який фактично відображається кінцевому користувачеві! Так, SMTP - це те, що зламано. Так, SPF - це те, що зламано.

Вам найкраще буде перевірити DMARC, а не перевірити SPF. DMARC за замовчуванням перевіряє SPF, але він також перевіряє вирівнювання заголовка From з SMTP MAIL FROM (домени повинні відповідати - він ігнорує частину імені користувача). Як бонус ви також можете отримати підтримку DKIM, що є дуже корисним доповненням до SPF.

DMARC залежатиме від запису DNS TXT, встановленого на _dmarc.kiwibank.co.nz. але в даний час його немає. Відповідно до поточного стану Інтернет-правил, що означає власника kiwibank.co.nz. зовсім не хвилює захист від таких підробників. Але ви можете в деяких реалізаціях застосувати DMARC для всіх вхідних електронних листів.


SPF не порушено. Тут розірвана сама пошта. Конверт до! = Заголовка, щоб мати вагомі причини. Конверт між доменами з! = Заголовка від не має вагомих причин.
Джошудсон

1
@joshudson так, це так. Наприклад, якщо я налаштував .forwardфайл (або інше переадресація електронної пошти) для пересилання з одного з моїх облікових записів в інший, має сенс зберегти, від кого це повідомлення (із заголовка), і відобразити його як у кого це повідомлення клієнт електронної пошти і т. д. Але будь-які відмови від цього переадресації (відправника конверту) повинні мати мене, а не людину, яка спочатку надіслала повідомлення. Те саме стосується списків розсилки.
дероберт

1
@derobert Списки розсилки - це бахрома. Поштові клієнти не попереджають користувачів про очевидну підробку - це величезна проблема, і жодне .forwardвикористання не може її виправдати.
kubanczyk

Це просто неймовірно.
g33kz0r

2

Отже, після деякого читання - виявляється, що «Енволопа-Від» правильна, але «З» підроблена. Чи є спосіб я виправити / пом’якшити це, не порушуючи "загальну" електронну пошту?

Перевірка Fromзаголовка буде розбити списки розсилки:

  1. foo @ yourbank надсилає листа до кота-спільного перегляду картинок @ bar.

  2. Список розсилки буде приймати пошту,

    • замініть Envelope-Fromщось, що схоже на кішку-картинку-спільний-список-відмов @ бар,
    • можливо змінити заголовок відповіді та
    • повторно надіслати пошту всім одержувачам (наприклад, вам).

Тепер ваш поштовий сервер отримує пошту з

Envelope-From: cat-picture-sharing-list-bounce@bar
From: foo@yourBank

надсилається з поштових серверів бару.

Зауважу, що я використовую Postfix, Spamassassin та policyd (postfix-policyd-spf-perl) - і якщо його дійсно так просто обійти, у чому сенс SPF?

  1. Багато спамерів не намагаються надсилати «правильний» конверт.
  2. Ваш банк не отримає (більшість) зворотного розсилки для цієї спам-пошти, оскільки НДР надсилаються (або: повинні бути) на адресу Конверт-Від.
  3. Оцінка за результатами Envelope-From стає більш надійною. Якщо ви (або якийсь постачальник рахунків, якому ви довіряєте), призначите всі листи за допомогою Envelope-From = ... @ yourbank вкрай негативний показник спаму, спамери не можуть це зловживати.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.