Laman » bagaimana untuk » Mengapa Server SMTP Perantaraan Perlu Hantar Surat?

    Mengapa Server SMTP Perantaraan Perlu Hantar Surat?

    Sebagai seorang individu belajar lebih lanjut mengenai bagaimana pelanggan mel, pelayan SMTP, dan keseluruhan sistem e-mel berfungsi, mereka mungkin ingin tahu mengapa pelayan SMTP pertengahan juga diperlukan. Dengan itu, pos Q & A SuperUser hari ini mempunyai jawapan kepada soalan pembaca yang ingin tahu.

    Sesi Soalan & Jawapan hari ini datang kepada kami dengan ihsan SuperUser-bahagian pembahagian Stack Exchange, kumpulan yang diketuai oleh komuniti laman web Q & A.

    Photo courtesy of David Schroeder (Flickr).

    Soalan

    Pembaca Superuser Tobia ingin tahu mengapa pelayan SMTP pertengahan diperlukan untuk menghantar mel:

    Mengapa saya memerlukan pelayan SMTP pertengahan untuk menghantar mel? Kenapa klien mel saya (Outlook atau Thunderbird) tidak dapat menghantar mesej terus ke domain SMTP penerima?

    Sebagai contoh, jika saya perlu menghantar mel ke [email protected] dengan akaun Gmail saya, saya hantar kepada smtp.gmail.com pelayan; maka pelayan ini menghantar mesej saya ke pelayan MX example.com.

    Mengapa pelayan SMTP pertengahan diperlukan untuk menghantar mel?

    Jawapan

    Penyumbang SuperUser davidgo mempunyai jawapan untuk kami:

    Secara teknikalnya mungkin untuk menghantar mel terus ke pelayan SMTP penerima dari komputer anda.

    Melihatnya secara bersejarah, jika pelayan SMTP jauh turun, anda mahu sistem mengendalikannya secara automatik dan terus mencuba, oleh itu anda mempunyai pelayan SMTP. Begitu juga, pada zaman dahulu, tidak semua pelayan mel disambungkan sepanjang masa (pautan jarak jauh mahal), jadi mel akan dihantui dan dihantar apabila pautan ditubuhkan.

    Bergerak ke tempat perkhidmatan Internet murah, masih berguna untuk mempunyai mekanisme untuk memajukan menghantar mel jika pelayan tidak tersedia. Ia tidak sesuai untuk kefungsian ini untuk ditulis ke dalam MUA (e-mel pengguna / e-mel pengguna akhir program). Fungsi ini dimuatkan ke pelayan MTA (pelayan Mel / SMTP).

    Tetapi ia semakin buruk-spammer. Kebanyakan mel (lebih daripada 80 peratus) adalah spam. Penyedia mel melakukan apa sahaja yang mereka boleh untuk mengurangkan masalah ini dan sebilangan besar teknik membuat andaian mengenai cara penghantaran surat dihantar. Berikut adalah pertimbangan penting:

    1. Penyenaraian Grey: Sesetengah pembekal secara automatik akan menjatuhkan sambungan mel jika penghantar dan penerima tidak disampaikan sebelum dan mengharapkan mereka mencuba untuk kali kedua. Pemain spam sering tidak mencuba sementara pelayan SMTP selalu sepatutnya. Ini mengurangkan jumlah spam sebanyak kira-kira 80 peratus, tetapi ia sepatutnya dilakukan sekalipun.

    2. Reputasi: Lebih jauh lagi seseorang yang menghantar mel melalui pelayan SMTP yang terkenal, dikenali sebagai legit berbanding dengan server penerbangan malam. Untuk mendapatkan reputasi, penyedia melakukan beberapa perkara:

    • Sekat alamat dinamik / pelanggan (bukan 100 peratus, tetapi potongan besar internet telah dipetakan).
    • Semak untuk melihat sama ada DNS terbalik sepadan dengan DNS hadapan. Tidak terlalu sukar untuk dilakukan, tetapi ia menunjukkan beberapa tahap kebertanggungjawaban dan pengetahuan amalan terbaik (sesuatu yang banyak blok alamat pelanggan tidak mempunyai).
    • Semak reputasi. Apabila berkomunikasi dengan pelayan SMTP yang lain, banyak penyedia menjejaki jumlah spam dan jumlah mel yang dihantar. Mereka boleh mengurangkan jumlah spam dengan mengehadkan sambungan dan mengawasi parameter ini. Terdapat banyak cara ini dilakukan, tidak semuanya jelas, tetapi memerlukan pengirim yang diketahui.
    • SPF dan DKIM. Mekanisme ini mengikat sumber DNS ke nama domain untuk membuat surat melekat lebih keras dan akan sulit, tetapi tidak semestinya mustahil untuk digunakan jika program mel (MUA) bertanggung jawab untuk mel keluar.

    Mungkin ada kebimbangan kecil lain, tetapi ini akan menjadi yang utama.


    Mempunyai sesuatu untuk menambah penjelasannya? Bunyi dalam komen. Ingin membaca lebih banyak jawapan dari pengguna Stack Exchange yang berteknologi tinggi? Lihat thread perbincangan penuh di sini.