Bagaimana email ini menumbangkan cek SPF?


13

Saya menjalankan server surat yang tampaknya menangani email dengan benar dengan set SPF - namun saya sudah mulai menerima email palsu yang mengaku berasal dari bank - dengan alamat Dari ditetapkan sebagai bank - tetapi yang jelas bukan berasal dari bank.

Header email yang relevan adalah sebagai berikut:

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

Kuncinya di sini adalah bahwa kiwibank.co.nz adalah bank yang sah dan bereputasi di mana saya berasal, dan memiliki catatan SPF yang berbunyi:

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"

Jadi, setelah beberapa pembacaan - tampaknya Envolope-From benar, tetapi "From" telah dipalsukan. Apakah ada cara saya dapat memperbaiki / mengurangi ini tanpa melanggar email "umum"? Saya perhatikan bahwa saya menggunakan Postfix, Spamassassin, dan policyd (postfix-policyd-spf-perl) - dan jika sangat mudah untuk mem-bypass, apa gunanya SPF?

Jawaban:


13

Dalam hal ini mereka mungkin mengatakan kepada server Anda sesuatu seperti ini:

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...
.

Percakapan SMTP (alias "amplop") dapat memiliki header Dari / Ke yang berbeda dari header email. SPF tidak memeriksa tajuk, namun tajuk yang selalu ditampilkan kepada pengguna akhir! Ya, SMTP itu rusak. Ya, SPF itu rusak.

Anda akan lebih baik dilayani dengan memeriksa DMARC daripada hanya memeriksa SPF. DMARC secara default memeriksa SPF tetapi juga memeriksa perataan header Dari dengan SMTP MAIL FROM (domain harus cocok - domain mengabaikan bagian nama pengguna). Sebagai bonus Anda juga bisa mendapatkan dukungan DKIM, yang merupakan tambahan yang sangat berguna untuk SPF.

DMARC akan bergantung pada catatan DNS TXT yang ditetapkan di _dmarc.kiwibank.co.nz. tetapi saat ini tidak ada. Menurut ketentuan Internet terkini, itu artinya pemilik kiwibank.co.nz. sama sekali tidak peduli tentang dilindungi terhadap tipuan seperti itu. Tetapi Anda bisa menerapkan beberapa implementasi DMARC untuk semua email yang masuk.


SPF tidak rusak. Email itu sendiri rusak di sini. Envelope to! = Header to memiliki alasan yang bagus. Amplop lintas-domain dari! = Tajuk dari tidak memiliki alasan yang bagus.
joshudson

1
@ Joshshson ya itu. Misalnya, jika saya mengatur .forwardfile (atau penerusan email lainnya) untuk meneruskan dari salah satu akun saya ke yang lain, masuk akal untuk mempertahankan dari siapa pesan itu berasal (Dari tajuk), dan untuk menampilkannya dari siapa dari dalam klien email, dll. Tetapi bouncing yang dihasilkan oleh penerusan itu (pengirim amplop) harus pergi kepada saya, bukan orang yang awalnya mengirim pesan. Hal yang sama berlaku untuk milis.
derobert

1
@derobert Mailing list adalah sesuatu yang tidak biasa. Klien surat tidak memperingatkan pengguna tentang palsu - ini masalah besar, dan tidak ada .forwardpenggunaan yang dapat membenarkannya.
kubanczyk

Ini luar biasa.
g33kz0r

2

Jadi, setelah beberapa pembacaan - tampaknya Envolope-From benar, tetapi "From" telah dipalsukan. Apakah ada cara saya dapat memperbaiki / mengurangi ini tanpa melanggar email "umum"?

Memverifikasi Fromtajuk akan memecah daftar mailing:

  1. foo @ yourbank mengirim email ke bar @ daftar gambar kucing.

  2. Milis akan menerima surat,

    • ganti Envelope-Fromdengan sesuatu yang mirip dengan cat-picture-sharing-list-bounce @ bar,
    • mungkin memodifikasi header Balas-Ke dan
    • kirim ulang surat ke semua penerima (mis. Anda).

Sekarang server surat Anda menerima surat

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

dikirim dari server email bar.

Saya perhatikan bahwa saya menggunakan Postfix, Spamassassin, dan policyd (postfix-policyd-spf-perl) - dan jika sangat mudah untuk mem-bypass, apa gunanya SPF?

  1. Banyak pengirim spam yang tidak mau repot-repot mengirim Envelope-From yang benar.
  2. Bank Anda tidak akan mendapatkan (sebagian besar) penghambur balik untuk email spam ini, karena NDR dikirim (atau: harus) dikirim ke alamat Envelope-From.
  3. Penilaian berdasarkan Envelope-From menjadi lebih dapat diandalkan. Jika Anda (atau penyedia skoring yang Anda percayai) menetapkan semua email dengan Envelope-From = ... @ yourbank skor spam yang sangat negatif, spammer tidak dapat menyalahgunakannya.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.