Apakah penulisan ulang SRS mutlak diperlukan untuk server mail penerusan?

Saya mengoperasikan server email Postfix untuk domain saya, katakanlah mydomain.com. Sebagian besar bertindak sebagai server email penerusan: pengguna menerima alamat email @ mydomain.com, tetapi biasanya memilih untuk meneruskan alamat mereka ke kotak masuk eksternal (Gmail, Yahoo, dll). Ada beberapa ribu alamat yang diteruskan, sehingga server menangani volume lalu lintas surat yang cukup signifikan.

Di masa lalu, server tidak menggunakan penulisan ulang SRS. Ini tentu saja berarti bahwa surat yang diteruskan akan gagal dalam pemeriksaan SPF, karena alamat ip saya secara teknis tidak berwenang untuk mengirim email atas nama domain pengirim asli. Namun, dari apa yang saya lihat tampaknya tidak menyebabkan masalah signifikan. Umumnya tidak ada keluhan dari pengguna seperti Gmail, Yahoo, dll. Tampaknya cukup pintar untuk mengabaikan kegagalan SPF dan tetap mengirimkan pesan.

Dengan pemikiran ini, apakah benar-benar perlu untuk mengaktifkan penulisan ulang SRS? Saya sedang mempertimbangkan untuk mengaktifkannya, tetapi kekhawatiran utama saya adalah bahwa domain saya akan masuk daftar hitam karena mengirim spam ketika spam mau tidak mau akan terampas. Tidakkah penulisan ulang membuatnya seolah-olah saya adalah pencetus spam? (Setidaknya, ini adalah pemahaman saya dari membaca Praktik Terbaik Gmail untuk Penerusan Pengirim Surat ).

Memang, saya sudah mengambil beberapa tindakan pencegahan yang disarankan seperti menggunakan SpamAssassin untuk menambahkan "SPAM" ke baris subjek dugaan spam sebelum meneruskan, tidak meneruskan keyakinan tinggi (skor 15+), dan menggunakan daftar pemblokiran spamhaus, tetapi langkah-langkah ini tidak muncul Sempurna dan spam masih bisa lolos tanpa tanda.

Apakah mengaktifkan penulisan ulang SRS sepadan, jika hal itu meningkatkan risiko salah ditandai sebagai spammer? Atau apakah lebih aman membiarkannya begitu saja dan mengabaikan kegagalan SPF?

postfix spam spamassassin

— tlng05
sumber

Saya tahu dari pengalaman bahwa beberapa ISP di Inggris akan menolak email masuk yang mengaku berasal dari pelanggan mereka sendiri, tetapi itu belum dikirim dari mailer mereka sendiri. Hal yang sama juga berlaku untuk Gmail, Yahoo, dan AOL. Situasi seperti itu hanya dapat diatasi dengan menulis ulang alamat pengirim.

— roaima

Jawaban:

Menurut saya, pertanyaan Anda adalah " berapa banyak server surat di luar sana yang memeriksa catatan SPF pada email yang masuk? ". Jika sebagian besar dari mereka, SRS adalah persyaratan mutlak untuk server penerusan; jika tidak ada dari mereka, Anda tidak perlu SRS.

Sayangnya, saya tidak dapat segera menempatkan pekerjaan akademis saya pada ini. Tetapi karena saya memeriksa SPF pada email yang masuk, saya dapat mengatakan dengan pasti bahwa beberapa server email melakukan pengecekan. Klien mana pun yang memiliki server Anda meneruskan ke akun di server saya akan kehilangan email yang dikirim dari pengirim yang mengiklankan SPF yang berakhir (seperti seharusnya) -all, kecuali Anda menggunakan SRS. Jadi saya dapat mengatakan dengan pasti bahwa tanpa SRS, beberapa email pelanggan Anda tidak akan dikirimkan .

Saya minta maaf kepada Marc bahwa saya tidak bisa membaca bahasa Jerman, jadi saya tidak bisa mengatakan apakah PDF yang ia kutip menunjukkan argumen yang meyakinkan, tetapi saya dapat menegaskan kembali bahwa tanpa SRS, sebagian kecil dari email pelanggan Anda tidak akan dikirimkan. Saya tidak bisa mengatakan apa fraksi itu, tetapi bukan nol - dan mengingat, saya pikir Anda tidak punya alternatif selain menjalankan SRS.

Saya setuju bahwa server Anda tidak akan membantu dirinya sendiri dengan meneruskan SPAM, tetapi menurut pengalaman saya sebagian besar kerusakan reputasi dilakukan pada alamat IP-nya, bukan dari-domain amplop; ini akan dilakukan terlepas dari penggunaan SRS.

Jawaban yang lebih dalam untuk pertanyaan Anda adalah bahwa, antara SPF dan tindak lanjutnya (yang dipertimbangkan dengan buruk dan melanggar internet) DMARC, bagi saya tampaknya layanan penerusan surat sudah cukup. Saya sudah meminta semua kecuali satu pengguna saya untuk mendapatkan pengiriman akhir di server saya, dan bahwa satu pengguna harus mengubah atau pergi pada 2016. Saat ini, banyak sistem webmail akan memungkinkan integrasi lebih dari beberapa kotak surat dengan mengumpulkan surat luar server menggunakan IMAP atau POP, dan banyak klien surat memungkinkan beberapa akun IMAP atau POP hadir sebagai satu INBOX terintegrasi, jadi penerusan bukanlah keuntungan bagi pembacaan terpusat seperti dulu.

Singkatnya, saya katakan Anda membutuhkan SRS dalam jangka pendek, dan model bisnis baru dalam jangka panjang.

— MadHatter
sumber

Masalahnya adalah bahwa SRS adalah solusi untuk memperbaiki masalah penerusan SPF. Penulisan ulang SRS misalnya pengguna @ A ke A = pengguna @ B dan catatan SPF B yang bertanggung jawab. Masalah: B masih bisa memalsukan alamat! Jadi karena itu ada yang menambahkan crypt-hashes dan stempel waktu ke alamat yang ditulis ulang. Agar ini dapat bekerja dalam skala besar, perlu adopsi global yang tidak ada di sana. Ini juga hanya berfungsi jika sesuatu diteruskan sekali, tetapi tidak lebih. Juga jawaban adalah masalah. Juga perlu diingat, bahwa SPF adalah teknik untuk melindungi domain penyalahgunaan Anda sendiri, tidak lebih.

— Marc Stürmer

@ MarcStürmer " SRS adalah solusi untuk memperbaiki masalah penerusan SPF ": ya, itulah tepatnya. SPF dikenal untuk memecah penerusan sederhana; jika Anda tidak berpikir SRS adalah harga yang pantas dibayar, jangan mengiklankan catatan SPF. " Masalah: B masih dapat memalsukan alamat ": tidak ke domain A, atau domain lain yang dilindungi oleh catatan SPF yang layak, atau surat akan ditolak berdasarkan SPF; tetapi selain itu, ya, itu bisa, dan saya tidak melihatnya sebagai masalah. " SPF adalah teknik untuk melindungi domain penyalahgunaan Anda sendiri, tidak lebih ": Saya setuju.

— MadHatter

@ MarcStürmer: "Ini juga hanya berfungsi jika sesuatu diteruskan sekali, tetapi tidak lebih." salah. SRS bekerja dengan sangat baik pada beberapa server penerusan. Ia menderita hanya jika ada server yang tidak memberi tag di baris. Tetapi ini adalah masalah yang sama dibandingkan dengan server non-penandaan pada umumnya, baik itu hop maju pertama atau lambat. Di dunia SPF, Anda tidak perlu SRS, Anda hanya perlu mengambil alih tanggung jawab surat yang diteruskan dan memastikan Anda dapat mengirim kemungkinan bouncing kembali. SRS hanyalah salah satu teknik yang melakukan ini, google misalnya menggunakan sesuatu yang berbeda.

— Adrian Zaugg

Masalahnya adalah, menggunakan SRS merusak pemeriksaan penyelarasan DMARC (yaitu pengirim amplop! = From:-Kepala) dan akan membuat Gmail menolak pesan jika domain di From:header memiliki p=rejectkebijakan DMARC mereka. Jika Anda menulis ulang From:juga, surat akan diperiksa sesuai dengan aturan domain Anda sendiri. Tetapi cek DKIM akan gagal dan pengirim yang diperlihatkan di klien email rusak.

— mbirth

@mbirth afaik, Anda benar. Tapi saya pribadi menganggap DMARC sebagai bencana total, paling tidak karena secara sepihak memecah milis, dan (dalam kapasitas saya sebagai admin daftar komunitas besar) hanya menyarankan orang-orang untuk tidak menggunakan ISP apa pun yang menerbitkan p=rejectkebijakan. Jika SRS merusak DMARC, yah, itu hanya sulit pada DMARC.

— MadHatter

SRS tampaknya merupakan ide yang bagus di atas kertas, tetapi dalam praktiknya tidak berjalan baik menurut orang-orang dari Heinlein Support (mereka menjalankan layanan surat berukuran sedang dengan lebih dari 100.000 akun.)

Detail dalam pembicaraan mereka, meskipun dalam bahasa Jerman, mengapa: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Alasan utama adalah bahwa SRS adalah tambalan kecil untuk masalah serius dalam mengimplementasikan SPF dalam kenyataan, karena SPF tidak mencakup beberapa kasus penggunaan email yang sangat baik. Untuk SRS masuk akal meskipun perlu digunakan pada basis besar server, yang tidak mungkin terjadi. Jadi sebelum ditempatkan pada basis server yang besar, itu tidak masuk akal sama sekali.

Masalah dengan penyedia surat besar adalah bahwa mereka saat ini memang memiliki basis pengguna yang sangat besar dan mereka menerapkan teknik lebih banyak dan lebih (penerus DMARC sudah dalam pipa), yang membuatnya semakin sulit untuk normal pengaturan server surat untuk mengirim surat kepada mereka dengan cara yang andal.

Jika Anda ingin mendapatkan email Anda lebih baik dikirim ke penyedia surat besar seperti Gmail, Hotmail dan sebagainya Anda harus menerapkan setidaknya DKIM dan DMARC, tetapi juga mengaturnya ke soft gagal terbaik dan mungkin menerapkan beberapa mekanisme pembatasan tarif pada pengiriman surat akan bekerja keajaiban untuk Anda.

Masalah dengan penyedia besar ini adalah alasan mengapa ada layanan saat ini seperti Mailchimp, Mandrill atau Returnpath. Penyedia itu membayar uang ke Google & Co. untuk kualitas pengiriman yang lebih baik.

— Marc Stürmer
sumber

Masalahnya di sini adalah SPF bukan SRS. Selama beberapa ISP menggunakan SPF, Anda perlu mengimplementasikan SRS (atau yang serupa) untuk membuat penerusan bekerja dengan mereka semua. Masalah dengan greylisting berbeda, Anda harus "membongkar" alamat pengirim yang ditandai SRS untuk greylisting (juga mail yang ditandai oleh BATV).

— Adrian Zaugg

Saya setuju dengan setiap kata @MadHatter, TETAPI fakta penting tentang Google!

Jika Anda memberikan layanan penerusan ke gmail, ada kemungkinan besar Anda juga menyediakan akses SMTP sehingga pengguna gmail Anda dapat mengirim email dari gmail atas nama alamat yang disimpan oleh Anda.

Dalam hal itu - gmail tahu Anda adalah pengirim untuk email ini dan tidak menandai ke depan Anda sebagai spam meskipun gagal memeriksa SPF.

Anda dapat mengirim email klien Anda dari bill@microsoft.com. Pesan akan masuk ke kotak masuk mereka tanpa peringatan apa pun! (Microsoft memang memiliki -all dalam catatan spf)

Diperiksa dan diverifikasi. Contoh terlampir.

pesan ini masuk ke kotak masuk.

— kamu
sumber