Ke mana email dikirim ke *@example.com pergi? [Tutup]


88

Jadi saya sudah lama memikirkan ini.

Ke mana email dikirim untuk *@example.compergi? Jika saya secara tidak sengaja mengirim informasi sensitif kepada *@example.comseseorang yang jahat (berpotensi di IANA) dapat mengambilnya suatu hari nanti?


2
Jika Anda menjalankan Postfix sebagai server SMTP, Anda dapat menggunakan discard ( postfix.org/discard.8.html ) untuk membuang email ke domain RFC 2606 (bukan bouncing).
HTTP500

4
Adakah yang bisa menjelaskan mengapa ini dimigrasi ke sini dan kemudian ditutup? Saya memulai pertanyaan tentang Stack Overflow karena saya pikir itu adalah masalah yang lebih umum, tapi saya rasa masuk akal kalau itu seharusnya ada di sini terkait dengan email dan jaringan. Tetapi jelas beberapa orang yang berpengalaman tidak setuju. Bagaimana dan di mana saya dapat membuka kembali pertanyaan ini?
bryan kennedy

Jika off topic di sini saya yakin itu akan baik-baik saja di webmaster pro.
DisgruntledGoat

Ini mungkin paling cocok untuk Pengguna Super .
MDMarra

1
Jika Anda mengunjungi example.com, dikatakan itu dicadangkan untuk keperluan ilustrasi & tautan ke iana.org/domains/reserved
pengguna

Jawaban:


48

Jika Anda mencoba mengirim email ke *@example.com

  1. SMTP Anda akan memeriksa domain yang ada.
  2. Server SMTP Anda akan mencari MXcatatan di example.com.
  3. Tidak ada: SMTP Anda akan kembali Adicatat. IP adalah 174.137.125.92 (pada hari ini)
  4. IANA telah mendaftarkan domain, tetapi belum menyiapkan server SMTP mendengarkan pada port 25 pada 174.137.125.92.
  5. Maka perilakunya tergantung pada SMTP Anda. Sebagian besar server akan mengirimi Anda peringatan, dan coba lagi nanti. Akhirnya (biasanya dalam 3 hari), SMTP akan membuang pesan dan mengirimi Anda pemberitahuan kegagalan.

Intinya : Itu tergantung pada konfigurasi Anda sendiri. Tetapi jika IANA menyiapkan server hari ini, mereka mungkin dapat menerima pesan yang Anda coba kirim 3 hari yang lalu.


58

Jika tidak ada data MX, server email akan mencoba mengirim ke data A.

Server example.com tidak mendengarkan pada port 25, sehingga server mail tidak akan membuat koneksi TCP dan bahkan tidak akan memulai pengiriman.


50

example.com tidak memiliki data MX, jadi server SMTP Anda pada domain pengirim harus memantulkan pesan jika dikonfigurasi seperti kebanyakan server SMTP.

EDIT: untuk kejelasan bagi mereka yang menemukan jawaban ini di masa mendatang, berikut adalah penjelasan tentang apa itu data MX: (dari http://en.wikipedia.org/wiki/Mx_record diambil 21 November 2011)

Catatan penukar surat (MX record) adalah jenis catatan sumber daya dalam Sistem Nama Domain yang menentukan server surat yang bertanggung jawab untuk menerima pesan email atas nama domain penerima dan nilai preferensi yang digunakan untuk memprioritaskan pengiriman surat jika banyak server surat tersedia . Himpunan catatan MX dari nama domain menentukan bagaimana email harus dialihkan dengan Protokol Transfer Surat Sederhana.

Jadi, pada dasarnya, example.com, example.net, dan example.org tidak memiliki server yang ditunjuk untuk menangani surat masuk, dan oleh karena itu setiap surat yang dikirim kepada mereka harus dikembalikan ke pengirim sebagai "tidak terkirim" (dapat bervariasi berdasarkan konfigurasi server SMTP , tetapi kembali ke pengirim sebagai "tidak terkirim" adalah perilaku yang sangat umum untuk situasi ini).

EDIT 2: Seseorang mengangkat perilaku didefinisikan RFC 5321 jatuh kembali menggunakan catatan A dalam kasus catatan MX yang hilang. Saya mencari RFC ini ( http://tools.ietf.org/html/rfc5321 ) dan tidak menemukan hal seperti itu, tetapi ada kemungkinan bahwa beberapa MTA (Mail Transfer Agent, seperti exim, postfix, sendmail, dan Microsoft Exchange Server, di antara yang lain) dapat mencoba mengirimkan email melalui SMTP ke alamat yang ditentukan dalam catatan A. Untuk anak cucu, inilah yang terjadi ketika Anda mencoba membuat koneksi SMTP ke alamat record A yang ditentukan untuk example.com (192.0.43.10 pada saat penulisan):

$ telnet 192.0.43.10 25
Trying 192.0.43.10...
telnet: Unable to connect to remote host: Connection timed out

EDIT 3: lihat balasan di bawah ini untuk klarifikasi tentang RFC yang relevan dan perilaku mundur.


16
Jawaban Anda salah - RFC 5321 tidak menentukan bahwa resolusi kembali ke Acatatan ketika tidak MXada catatan ("aturan MX implisit"); lihat bagian 5.1 . Jika daftar kosong MX dikembalikan, alamat diperlakukan seolah-olah dikaitkan dengan MX RR implisit, dengan preferensi 0, menunjuk ke host itu.
josh3736

1
Selain itu, SMTP selalu memiliki fallback untuk Amemerintah - itu tidak diperkenalkan dengan 5321.
josh3736

1
Dari RFC 974 (973 & 974 memperkenalkan catatan MX)It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX).
Chris S

2
@ josh3736 SMTP tidak pernah menentukan bahwa itu mundur dari catatan MD & MF ke RR. Bahkan, RFC 821 tidak menyebutkan bagaimana tepatnya menggunakan file HOSTS (DNS tidak ada pada saat itu) untuk mencari server jarak jauh. Namun Anda benar bahwa MX diharuskan untuk kembali ke catatan A, per RFC 974. Ini dikodifikasi karena sudah menjadi praktik umum, catatan MD dan MF menjadi terlalu rumit dan biasanya tidak digunakan.
Chris S

Terima kasih atas klarifikasi Anda - Saya belajar sedikit dari ini.
seanp2k

19

Internet Number Assigned Number Authority:

Domain Contoh

Seperti yang dijelaskan dalam RFC 2606 , kami mempertahankan sejumlah domain seperti EXAMPLE.COM dan EXAMPLE.ORG untuk tujuan dokumentasi. Domain ini dapat digunakan sebagai contoh ilustrasi dalam dokumen tanpa koordinasi sebelumnya dengan kami. Mereka tidak tersedia untuk pendaftaran.


15
Jawaban Anda tidak responsif terhadap pertanyaan itu.

7
@ George Kenapa tidak? IANA memiliki domain sehingga bahkan jika tidak ada MX pada hari ini, IANA dapat membuat satu di masa depan dan mulai menerima email misalnya. * Domain. Ini jawaban terbaik menurut saya.
eduardocereto
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.