Belajar dan Menguji DMARC

 (learndmarc.com)
2 poin oleh GN⁺ 2023-10-02 | 1 komentar | Bagikan ke WhatsApp
  • LearnDMARC memungkinkan pengguna mempelajari dan menguji inti autentikasi email, yaitu SPF, DKIM, DMARC dalam satu layar, dan penjelasan visual keseluruhan dapat dilihat di desktop
  • Layar hasil terlebih dahulu menampilkan informasi koneksi seperti Source IP address, Hostname, dan Sender sehingga titik awal penilaian autentikasi dapat diperiksa
  • SPF dan DKIM masing-masing menampilkan domain target autentikasi dan hasilnya, serta sekaligus memperlihatkan apakah Alignment untuk penilaian DMARC terpenuhi
  • Bagian DMARC menggabungkan RFC5322.From domain, Policy(p=), hasil SPF, dan DKIM untuk menghubungkannya ke hasil akhir DMARC Result
  • Pada bagian akhir, keseluruhan penilaian dapat dilihat melalui Final verdict, dan tersedia juga anonimisasi hasil serta tautan pembelajaran DMARC

Tujuan LearnDMARC

  • Ini adalah halaman untuk mempelajari dan menguji SPF, DKIM, DMARC
  • Penjelasan visual menyeluruh tentang cara kerja DMARC hanya dapat dilihat jika situs dibuka di desktop

Item yang dapat diperiksa di layar hasil

  • Connection parameters

    • Source IP address
    • Hostname
    • Sender

  • SPF

    • Domain
    • Identity
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DMARC

    • RFC5322.From domain
    • Policy(p=)
    • SPF
    • DKIM
    • DMARC Result

Penilaian akhir dan fitur pendukung

  • Layar hasil menampilkan keseluruhan penilaian melalui Final verdict
  • Hasil dapat dianonimkan dengan Anonymize results
  • Tautan Learn more about DMARC disediakan

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-02
Komentar Hacker News

  • Ini cara yang bagus untuk mendorong layanan email inti yang diperlukan untuk mengurangi spam. Saya selalu berharap SPF, DKIM, dan DMARC saja sudah cukup menjadi motivasi bagi perusahaan-perusahaan tempat saya bekerja, tetapi reputasi saja sering kali tidak cukup untuk menjadikan investasi ini prioritas
    Untungnya, bagi perusahaan yang ingin berkomunikasi dengan pelanggan secara tepercaya, ada standar yang mungkin disukai pemasar: Brand Indicators for Message Identification(BIMI). Sekarang mereka tidak hanya mendapat keamanan, tetapi juga logo yang cantik: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    Di beberapa perusahaan, saya pernah memakai BIMI dengan alasan “pengalaman pelanggan” untuk membuat mereka menerapkan DMARC dengan benar, yaitu P=Reject

    • DMARC juga masih punya masalah. Materi dari beberapa tahun lalu: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      SPF maupun DKIM tidak sepenuhnya menyelesaikan pencegahan spoofing email. SPF mengautentikasi identifier HELO/MAIL FROM dan DKIM mengautentikasi field d= pada header DKIM-Signature, tetapi keduanya tidak mengautentikasi header From yang ditampilkan kepada pengguna akhir. Jadi meski verifikasi SPF dan DKIM lolos, alamat From tetap masih bisa dipalsukan
      Tidak adanya DMARC+ pada domain email jelas masalah, tetapi DMARC+ saja juga tidak menyelesaikan masalah “apakah ini pengirim yang sebenarnya”
    • Dari sisi penyerang, saya penasaran apa yang mencegah mereka membuat domain phishing yang memakai logo yang sama lalu menyiapkan BIMI
    • Bukankah BIMI biayanya sekitar 1000 dolar per tahun?

  • Materi terkait: melihat secara interaktif bagaimana DMARC, SPF, dan DKIM bekerja - https://news.ycombinator.com/item?id=29869266 - Januari 2022, 108 komentar

  • Saya penasaran apakah ada cara open source atau setidaknya gratis untuk memproses laporan DMARC
    Saya punya beberapa domain email dengan SPF, DKIM, dan DMARC aktif, dan semuanya berfungsi, tetapi ada dua hal menjengkelkan soal DMARC
    (1) Beberapa situs mengirim laporan DMARC seperti “Anda mengirim 3 pesan, semuanya normal, dan semua pemeriksaan lulus”
    (2) Sesekali ada upaya mengirim spam memakai domain saya melalui server lain, lalu saya menerima laporan “seseorang mencoba spam dengan memasukkan domain Anda di HELO/FROM, tetapi pemeriksaan gagal dan diblokir”
    Keduanya tidak berguna bagi saya. Saya tidak ingin tahu bahwa pengguna saya mengirim email ke @gmail.com atau @mail.ru, dan pada kasus kedua pun IP itu bukan IP server saya sehingga tidak ada yang bisa saya lakukan
    Membuka dan memeriksa XML secara manual terlalu merepotkan, jadi filter atau dasbor akan sangat berguna

  • Penjelasan “agar DMARC lolos, pemeriksaan DKIM dan/atau SPF harus lolos dan domain harus selaras” setahu saya salah
    Bukan “and/or”, melainkan or. Cukup salah satu dari DKIM atau SPF yang lolos, dan tidak ada cara untuk mewajibkan keduanya

    • Terkait hal ini, baru-baru ini ada masalah pada kemitraan Cloudflare dan MailChannels, dan spoofing email menjadi mungkin
      Masalah dasarnya adalah MailChannels tidak mewajibkan autentikasi. Cloudflare Workers bisa memanggil endpoint API MailChannels untuk mengirim email, dan MailChannels meminta penambahan record include: ke kebijakan SPF. Akibatnya MailChannels menjadi pengirim yang valid untuk semua domain, sehingga siapa pun bisa menyamar sebagai siapa pun
      Dari 2 juta domain yang di-host, hanya sekitar 400 yang mengatur DKIM, tetapi sekalipun ada DKIM, DMARC tetap lolos hanya dengan SPF yang lolos
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • Sepertinya Anda salah menafsirkan sintaksnya. Saya melihat and/or di sini berarti OR inklusif. “and” tidak selalu berarti itu opsi yang bisa dipilih
    • Entah kenapa kena downvote, tetapi pernyataan bahwa hanya or yang benar itu akurat
    • Jika memakai literal alamat IP tanpa membayar biaya domain, Anda bisa mendapatkan SPF secara gratis
      Cukup punya alamat email dengan literal alamat IP di field From:/Reply-To:, maka Anda mendapat “SPF”, dan memperoleh skor yang jauh lebih baik untuk menghindari greylisting pada transaksi pertama. Lebih bagus lagi jika tidak ada URL di isi pesan
      Tapi ini pengetahuan umum

  • Saya sangat suka pendekatan yang membuat kita mengikuti prosesnya secara iteratif. Beberapa tahun lalu, ketika di perusahaan sebelumnya kami hendak pindah ke pengiriman email self-hosted dengan langkah-langkah keamanan yang benar, hal seperti ini pasti sangat membantu

  • Saat mengirim email lewat layanan “Hide My Email” milik Apple, muncul error: https://support.apple.com/en-us/HT210425
    Unhandled Promise Rejection:
    TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
    dist.min.js:3:32767
    Terjadi setelah antarmuka mulai menampilkan “Here are the message headers and message body:” dan DKIM-Signature: d=icloud.com s=1a1hai
    Karena sudah lebih dari setahun sejak situs web ini diperkenalkan di Hacker News, sepertinya kode JavaScript-nya sudah tua dan tidak lagi berfungsi. Bisa jadi sejak awal memang tidak mendukung Safari, atau keduanya. Meski begitu, saya banyak belajar dari bagian pertama dan kedua pengujian DMARC, dan bisa mendapat gambaran tentang apa yang akan terjadi di tahap berikutnya
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • Saat menguji email palsu, error yang sama juga muncul di Chrome
      telnet learndmarc.com 25
      Trying 87.239.13.42...
      Connected to learndmarc.com.
      Escape character is '^]'.
      220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
      HELO there
      250 allspark.uriports.com Hello []
      MAIL From: me@example.com
      250 OK
      RCPT To: ld-49101f55f6@learndmarc.com
      250 Accepted
      DATA
      354 Enter message, ending with "." on a line by itself
      .
      250 OK id=1qn4QF-00CUhd-5j
      Lucu saat mengetik, rasanya seperti “tidak perlu sampai menulis surat cinta”. Mungkin tidak, tetapi sepertinya di bagian data perlu mengulang header From: dan To:
      Masih lucu kalau membayangkan berapa banyak email yang selama bertahun-tahun dikirim dengan HELO there alih-alih hostname. Saya juga penasaran berapa proporsi trafik internet yang berupa Enter message, ending with . on a line by itself
    • Ini rusak karena email dikirim tanpa field from. Programmer-nya hanya tidak terpikir untuk menguji kasus pengguna buruk melakukan hal buruk; tidak ada konspirasi khusus
    • DMARC bergantung pada alamat RFC5322.From, jadi kalau alamat ini hilang akan muncul error. Untuk menghindari error seperti ini, sekarang email yang tidak memiliki alamat tersebut diabaikan

  • Sungguh mengejutkan bahwa teknologi yang sekitar 30 tahun lalu sesuai dengan niat baik dan idealisme masih dipaksa berjalan di abad ke-21 dengan bergantung pada tumpukan lapisan kompatibilitas dan hack
    Di sisi VOIP/telekomunikasi juga sama
    Microsoft juga baru-baru ini mengalami masalah deliverability email, dan di sebagian besar tenant O365 kami muncul notifikasi untuk memeriksa SPF, DKIM, dan DMARC. Kami sudah mengaturnya dengan benar, tetapi beberapa tenant mengalami masalah saat mengirim email ke penyedia email kecil (setingkat ISP). Penyebabnya, karena spam keluar dari alamat IP atau server email yang sama, penyedia kecil itu memblokir seluruh IP dan rentang IP

  • Fakta menarik: sns.amazonaws.com masih belum punya record DMARC. Jika tidak memakai domain kustom, pesan AWS SNS berasal dari sini, dan semua notifikasi CloudWatch juga datang dari no-reply@sns.amazonaws.com

  • Email memang seharusnya bekerja seperti ini, tetapi di dunia nyata ada allowlist

    • Dan ada juga blocklist. Ada blocklist yang predatoris, dan ada blocklist yang nyaris seperti pemerasan terorganisasi
    • Tidak jelas allowlist untuk apa. Tidak umum untuk terlebih dahulu menetapkan allowlist domain yang boleh mengirim ke domain saya. Kalau begitu, tujuan email jadi runtuh

  • Dalam failover DNS pun jangan lupa mengatur pemeriksaan semacam ini dengan benar
    Saya pernah melihat perusahaan tertipu karena memakai pengaturan default Exchange Online
    Ketika penyerang sebentar membuat DNS menjadi “tidak tersedia”, semua email phishing lolos. Sebab server MS merespons dengan DNS temp error dan meloloskan semua email sebagai bukan spam
    Detailnya adalah received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout), dan DKIM diperiksa terhadap domain server SMTP pengirim, yang dalam kasus ini adalah server penyerang yang dipakai untuk phishing
    Setelah itu saya menghabiskan waktu yang menyenangkan bersama dukungan IT/keamanan MS, tetapi orang-orang di sana bahkan tidak memahami cara kerja email. Pengalaman yang sangat lucu sekaligus menyedihkan, dan semoga outsourcing cocok untuk mereka