จะสามารถส่งและรับอีเมลจากที่อยู่ IP แทนจากโดเมนได้หรือไม่

โดยปกติแล้วอีเมลจะมีชื่อโดเมนทางด้านขวาของ @ เพื่อให้คุณสามารถระบุองค์กรหรือ บริษัท อันที่จริงโดเมนนี้ไม่มีอะไรอื่นนอกจาก "ชื่อ" หรือ "นามแฝง" สำหรับที่อยู่ IP ที่แก้ไขโดยเซิร์ฟเวอร์ชื่อ

ฉันคิดว่านี่สามารถใช้เป็นตัวอย่างสำหรับอินเทอร์เน็ตของสิ่งต่าง ๆ ได้เนื่องจากมีความเป็นไปได้มากกว่าเมื่อเปรียบเทียบกับ POST และ GET เช่น "หลายต่อหนึ่ง" หรือ "หนึ่งต่อหลาย"

มีวิธีการส่งและรับอีเมลโดยตรงและจากที่อยู่ IP เช่น user@xxx.xxx.xx.xxx หรือไม่

email smtp email-server

— ปีเตอร์มอร์เทนเซ่น
แหล่งที่มา

นอกเหนือจาก: ถ้าคุณคิดว่า HTTP นั้น จำกัด IoT เกินไปให้ดูที่ MQTT หรือ XMPP

— Roger Lipscombe

โดเมนเป็นมากกว่า 'ชื่อสำหรับที่อยู่ IP' โดเมนสามารถเผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับบริการอีเมลของตน (ผ่านรายการ DNS) ซึ่งอาจมีที่อยู่ IP หลายแห่งสำหรับเซิร์ฟเวอร์อีเมลหลายแห่ง (เช่นเพื่อการทำโหลดบาลานซ์หรือเพื่อวัตถุประสงค์ในการย้อนกลับ)

— jjmontes

อีเมลไม่ได้เป็นรายบุคคล แต่เป็นแบบหนึ่งต่อหนึ่งและจากนั้นเซิร์ฟเวอร์อาจกระจายข้อความไปยังหลาย ๆ คน คุณสามารถโพสต์ http ไปยังเซิร์ฟเวอร์จากนั้นให้ไคลเอนต์จำนวนมากอ่านเซิร์ฟเวอร์นั้นในอีเมลรุ่นเดียวกันที่แน่นอนใช้

— djsmiley2k - CoW

ในฐานะที่เป็นคนที่ต้องทำโบราณคดีเครือข่ายเป็นระยะโปรดอย่าใช้รหัส IP อย่างหนัก DNS ไม่ใช่ difficulr และเซิร์ฟเวอร์ DNS เช่นdnsmasqมีน้ำหนักเบาในขณะที่อนุญาตการแทนที่โฮสต์ IP ของอินเทอร์เน็ตจะเปลี่ยนแปลงตลอดเวลา

— Criggie

โดเมนไม่ใช่ชื่อแทนสำหรับที่อยู่ IP อีเมลเฉพาะมีระเบียน MX ที่ชื่อโดเมนจะจับคู่กับสิ่งอันดับหนึ่งหรือหลายรายการที่มีทั้งลำดับความสำคัญและชื่อโฮสต์ (ซึ่งจะส่งอีเมล) คุณกำลังผสมแนวคิดที่แตกต่างกันสองประการ: การตั้งชื่อ (ใครที่จะส่งด้วย) และที่อยู่ (ที่ที่จะส่ง)

— Patrick Mevzek

คำตอบ:

สำหรับอีเมลโดเมนไม่ได้เป็นเพียงนามแฝงหรือรูปแบบที่มนุษย์สามารถอ่านได้สำหรับที่อยู่ IP: มีระเบียนตัวแลกเปลี่ยนอีเมล MXเพื่อระบุเซิร์ฟเวอร์อีเมลที่รับผิดชอบในการยอมรับข้อความอีเมลในนามของโดเมนผู้รับ อาจมีเซิร์ฟเวอร์หลายตัวที่รับจดหมายสำหรับโดเมนและไม่จำเป็นต้องอยู่บน IP เดียวกันกับที่อยู่ในAระเบียนของโดเมน ระบบเมลสามารถมีเซิร์ฟเวอร์ได้หลายเซิร์ฟเวอร์: เซิร์ฟเวอร์ขาเข้าอาจแยกออกจากเซิร์ฟเวอร์ขาออกและเซิร์ฟเวอร์ที่เก็บเมล ฯลฯAบันทึกจะใช้เฉพาะเมื่อไม่มีการMXระบุเรคคอร์ดสำหรับชื่อโฮสต์

อย่างไรก็ตามไม่มีข้อ จำกัด (อื่น ๆ ) ในรูปแบบที่อยู่อีเมลที่คุณไม่สามารถส่งอีเมลโดยตรง<user@hostname.example.com>หรือแม้กระทั่ง<user@[198.51.100.10]>(IP ที่มีเครื่องหมายวงเล็บเหลี่ยม) หากมีเซิร์ฟเวอร์อีเมลที่รับอีเมลโดยใช้ชื่อโฮสต์ธรรมดาหรือแม้กระทั่งที่อยู่ IP ก็จะทำเช่นนั้น แต่สิ่งที่คุณกำลังแนะนำไม่สามารถใช้ได้ทั่วโลกในทางปฏิบัติ:

ระบบอีเมลส่วนใหญ่มีหลายโดเมนและจำเป็นต้องจัดการอีเมลแยกต่างหากสำหรับพวกเขาทั้งหมด ชื่อผู้ใช้อาจไม่ได้ถูกผูกไว้กับกล่องจดหมายจริงใด ๆ เนื่องจาก<user@example.com>อาจเป็นบุคคลที่แตกต่างจาก<user@example.net>
ขณะนี้เป็นเรื่องปกติเมื่อสองสามทศวรรษที่ผ่านมาการต่อสู้กับสแปมทำให้สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นและการรับอีเมลมีข้อ จำกัด ที่เข้มงวด
การใช้พอร์ต SMTP 25มีข้อ จำกัด มากในการเชื่อมต่ออินเทอร์เน็ตระดับผู้บริโภคเนื่องจากการใช้งานในทางที่ผิด (สแปมบอท) การใช้งาน SMTP สำหรับอุปกรณ์ IoT นั้นมีไม่มากนัก

— Esa Jokinen
แหล่งที่มา

แต่ถ้าไม่มีเรคคอร์ด MX dns สำหรับโดเมน (หรือ IP) ส่งเมล (หรือพยายามส่งไป) ส่วนโดเมนของที่อยู่อีเมล (ชื่อโฮสต์หรือที่อยู่ IP) และเซิร์ฟเวอร์การรับจะต้องถูกกำหนดค่าให้จัดการเมลสำหรับชื่อโฮสต์ / ที่อยู่ IP นั้น

— ivanivan

มันสามารถจัดการจดหมายสำหรับชื่อโฮสต์ ไม่ใช่เซิร์ฟเวอร์ทุกตัวในโลกที่รองรับเมลได้ทั้งหมด เซิร์ฟเวอร์ที่ใช้ Unix / Linux ส่วนใหญ่มีเซิร์ฟเวอร์ SMTP เพื่อจัดการกับจดหมายภายใน (จาก cron เป็นต้น) แต่สามารถทำงานได้ดีหากไม่มีเช่นกัน

— Esa Jokinen

Esa - ถ้าคุณชี้ระเบียน MX ของคุณไปยังเซิร์ฟเวอร์ postfix ของฉันการเชื่อมต่อ SMTP จะถูกสร้างขึ้น แต่เซิร์ฟเวอร์ของฉันไม่ได้กำหนดค่าให้จัดการอีเมลสำหรับโดเมนของคุณในรูปแบบหรือรูปแบบใด ๆ เพื่อให้คุณได้รับการตีกลับ แต่เซิร์ฟเวอร์ของฉันได้รับการตั้งค่าสำหรับโดเมนและผู้ใช้หลายโดเมนโดยเฉพาะทั้งหมดมาจากเซิร์ฟเวอร์ mysql ทุกอย่างขึ้นอยู่กับ 1) เซิร์ฟเวอร์อีเมลทำงานจริงที่ IP ที่คุณส่งอีเมลไปและ 2) มีการกล่าวว่าเซิร์ฟเวอร์อีเมลกำหนดค่าให้รับจดหมายที่กำหนดไว้สำหรับ IP นั้นหรือเฉพาะโดเมน / โดเมนหรือโดเมนใด ๆ เลย (เท่านั้น) จับคู่ส่วนผู้ใช้ของที่อยู่)

— ivanivan

เซิร์ฟเวอร์ SMTP หลายแห่ง (เช่น sendmail) จัดการuser@[aaa.bbb.ccc.ddd]ที่อยู่อีเมลแต่

เซิร์ฟเวอร์ SMTP บางตัวไม่จัดการ / รับรู้
พวกเขาอาจปฏิเสธที่จะยอมรับที่อยู่ผู้ส่งหรือไม่สามารถส่งไปยังที่อยู่ดังกล่าวได้
ที่อยู่ดังกล่าวอาจทำให้เกิดปัญหากับซอฟต์แวร์ป้องกันสแปม

RFC-5322: 3.4.1 ข้อมูลจำเพาะของ Addr-Spec

Wikipedia: ที่อยู่อีเมล - ส่วนของโดเมน

…นอกจากนี้โดเมนอาจเป็นตัวอักษรที่อยู่ IP ที่ล้อมรอบด้วยเครื่องหมายวงเล็บสี่เหลี่ยม [] เช่น jsmith @ [192.168.2.1] หรือ jsmith @ [IPv6: 2001: db8 :: 1] แม้ว่าจะไม่ค่อยเห็นยกเว้น อีเมลขยะ ...

— Anfi
แหล่งที่มา

โปรดสังเกตว่าที่อยู่อีเมลที่ชอบuser@[aaa.bbb.ccc.ddd]นั้นถูกต้องตามข้อกำหนดและการจัดการถูกกำหนดไว้อย่างเหมาะสมดังนั้นเซิร์ฟเวอร์ที่ไม่จัดการมันจะ "ขาด" ทางเทคนิค

— Ferrybig

@Ferrybig: จริงเนื่องจากการปฏิเสธนั้นเป็นเทคนิคการจัดการเช่นกัน

— Esa Jokinen

โปรดทราบว่า "อีเมลถูกส่งไปยังที่อยู่ IP ที่เฉพาะเจาะจงมากกว่าโฮสต์" ค่อนข้างสูงในหมวดหมู่ของธงสีแดง "อาจเป็นสแปม" และซอฟต์แวร์ AVAS จำนวนมากอาจตัดสินใจที่จะทิ้งมันไปอย่างเงียบ ๆ

— Shadur

ควรใช้งานได้หากทุกฝ่ายที่เกี่ยวข้องใช้ซอฟต์แวร์ที่ทันสมัยจริงๆ

ในขณะที่ SMTP ทำงานได้ดีกับ TCP แต่อย่างน้อยก็ในรูปแบบดั้งเดิมไม่ใช่โปรโตคอลที่อิงกับ TCP / IP หากคุณดู RFC 821 ดั้งเดิมจะมีการกำหนด "การขนส่ง TCP" ไว้ในภาคผนวก

RFC 2821 (จาก 1989) พิจารณาการใช้ที่อยู่ตัวเลข "หมดกำลังใจ"

แม้แต่รุ่นที่ทันสมัยกว่าของรายละเอียดยืนยันว่าปรัชญาในระดับหนึ่งจาก RFC5321: "SMTP เป็นอิสระจากระบบย่อยการส่งโดยเฉพาะและต้องการช่องสัญญาณกระแสข้อมูลที่เชื่อถือได้สั่งเท่านั้นในขณะที่เอกสารนี้กล่าวถึงการขนส่งผ่าน TCP โดยเฉพาะ ภาคผนวกของ RFC 821 [1] อธิบายบางอย่าง "

อย่างไรก็ตาม RFC นี้ - จากปี 2008 ซึ่งจริง ๆ แล้วมันใหม่มากห้ามการใช้ "ตัวอักษรที่อยู่" เป็น "อนุญาต" ("เพื่อหลีกเลี่ยงอุปสรรคนี้อนุญาตให้ใช้รูปแบบตัวอักษรพิเศษของที่อยู่เป็นทางเลือกให้กับโดเมน ชื่อ. ") ในส่วน 4.1.3 แต่ยังคงทำให้เป็น" ไม่ควร "ใน 2.1.4

SMTP และซอฟต์แวร์ส่วนมากที่อยู่รอบ ๆ นั้นใช้โฮสต์ไม่ใช่ที่อยู่ ipเป็น "สกุลเงินท้องถิ่น" - หาก "ที่อยู่ตามตัวอักษร" นั้นสามารถใช้งานได้ในฐานะ "โฮสต์" ดังนั้นไม่ว่าจะเป็น และโปรโตคอลที่ไม่ใช่ของ SMTP (ส่วนใหญ่ล้าสมัย) (เช่นอีเมล UUCP) ที่ใช้ในระบบนิเวศอีเมลของเก่าพร้อมกับระบบที่ใช้ SMTP

การใช้ระบบที่เกี่ยวข้องทุกระบบให้สอดคล้องกับมาตรฐาน 2008 อาจมีความเสี่ยงมากกว่าที่คิดไว้

— rackandboneman
แหล่งที่มา

RFC 5321 # 2.1.4ไม่อนุญาตให้ใช้ตัวอักษรที่อยู่: มันบอกว่าไม่ควร (และเชื่อมโยงไปยังส่วนที่ไม่ถูกต้อง) และ RFC 2821 ไม่ได้ค่อนข้างเก่า - มันเป็นปี 2001

— โฟโต้

ฉันจะบอกว่านี่เป็นข้อพิสูจน์ของฉันระหว่างเส้นจุด :) .. รวมคำอธิบายเกี่ยวกับ "micro-sanction", ขอบคุณ

— rackandboneman