क्या एक डोमेन से एक आईपी पते से एक ईमेल भेजने और प्राप्त करना संभव है?

आमतौर पर एक ईमेल में @ के दाईं ओर एक डोमेन नाम होता है, जिससे आप किसी संगठन या कंपनी की पहचान कर सकते हैं। यह डोमेन वास्तव में नाम सर्वर द्वारा हल किए गए एक आईपी पते के लिए "नाम" या "उपनाम" के अलावा कुछ भी नहीं है।

मुझे लगता है कि इसका उपयोग इंटरनेट ऑफ थिंग्स के लिए उदाहरण के लिए किया जा सकता है, क्योंकि POST और GET की तुलना में कई अधिक संभावनाएं हैं जैसे "कई से एक" या "एक से कई"।

उदाहरण के लिए user@xxx.xxx.xx.xxx के रूप में और IP पते से सीधे ईमेल भेजने और प्राप्त करने का एक तरीका है?

email smtp email-server

— पीटर मोर्टेंसन
स्रोत

एक तरफ: यदि आपको लगता है कि HTTP IoT के लिए बहुत अधिक प्रतिबंधात्मक है, तो MQTT या XMPP पर एक नज़र डालें।

— रोजर लिप्सकॉम्ब

एक डोमेन 'एक आईपी पते के लिए एक नाम' से अधिक है। एक डोमेन अपनी मेल सेवा (अपनी DNS प्रविष्टियों के माध्यम से) के बारे में बहुत अधिक जानकारी प्रकाशित कर सकता है, जिसमें कई मेल सर्वरों के लिए कई आईपी पते शामिल हो सकते हैं (जैसे लोड संतुलन या कम करने के उद्देश्य से)।

— jjmontes 14

ईमेल कई में से एक नहीं है, यह एक से एक है, और फिर सर्वर कई को संदेश फैला सकता है। आप एक सर्वर पर एक http पोस्ट कर सकते हैं, और फिर कई क्लाइंट ने उस सर्वर को बिल्कुल उसी मॉडल ईमेल उपयोगों में पढ़ा है।

— djsmiley2k - 15

किसी ऐसे व्यक्ति के रूप में, जिसे समय-समय पर नेटवर्क पुरातत्व करना पड़ता है, कृपया हार्ड-कोड IPs न करें। DNS अलग नहीं है, और DNS सर्वर जैसे dnsmasq होस्ट ओवरराइड की अनुमति देते समय हल्के होते हैं। इंटरनेट आईपी समय के साथ बदल जाएगा।

— 20

डोमेन आईपी पते के लिए एक उपनाम नहीं है। विशेष रूप से ईमेल में एमएक्स रिकॉर्ड होते हैं जहां डोमेन नाम एक प्राथमिकता या होस्टनाम (जिसमें ईमेल वितरित किया जाएगा) वाले एक या कई ट्यूपल्स पर मैप करता है। आप दो अलग-अलग अवधारणाओं को मिला रहे हैं: नामकरण (जो इसे भी भेजना है) और स्वीकार करना (जहां इसे भेजना है)।

— पैट्रिक मेवजेक

जवाबों:

ईमेल के लिए, एक आईपी पते के लिए एक डोमेन केवल एक उपनाम या मानव पढ़ने योग्य रूप नहीं है: मेल एक्सचेंजर MX रिकॉर्ड एक मेल प्राप्तकर्ता के डोमेन की ओर से ईमेल संदेशों को स्वीकार करने के लिए जिम्मेदार मेल सर्वर को निर्दिष्ट करने के लिए मौजूद है। डोमेन के लिए मेल स्वीकार करने वाले कई सर्वर हो सकते हैं, और वे आवश्यक रूप से उसी आईपी पर नहीं हैं Aजो डोमेन के लिए रिकॉर्ड में है। एक मेल सिस्टम में कई सर्वर हो सकते हैं: आने वाले सर्वर को आउटगोइंग सर्वर और मेल स्टोरेज सर्वर आदि से अलग किया जा सकता है। Aरिकॉर्ड का उपयोग केवल तब किया जाता है जब MXहोस्टनाम के लिए कोई रिकॉर्ड निर्दिष्ट नहीं होता है ।

हालाँकि, ईमेल पते के प्रारूप में कोई अन्य (अन्य) सीमा नहीं है कि आप ईमेल को सीधे <user@hostname.example.com>या यहां तक कि <user@[198.51.100.10]>(स्क्वायर ब्रैकेट के साथ आईपी) नहीं भेज सकते । अगर कोई मेलसर्वर था जो सादे होस्टनाम या यहां तक कि आईपी पते का उपयोग करके ईमेल स्वीकार करता है, तो यह करेगा। लेकिन आप जो सुझाव दे रहे हैं वह व्यवहार में विश्व स्तर पर काम नहीं करता है:

अधिकांश ईमेल सिस्टम में कई डोमेन होते हैं और उन सभी के लिए अलग से ईमेल को संभालने की आवश्यकता होती है। उपयोगकर्ता नाम स्वयं किसी भी वास्तविक मेलबॉक्स के लिए बाध्य नहीं <user@example.com>हो सकता है क्योंकि इससे भिन्न व्यक्ति हो सकता है<user@example.net>
जबकि यह दशकों पहले आम बात थी, स्पैम से लड़ने ने चीजों को और अधिक जटिल बना दिया है और ईमेल को स्वीकार करने की सख्त सीमाएं हैं।
25दुरुपयोग (स्पैम्बोट्स) के कारण उपभोक्ता ग्रेड इंटरनेट कनेक्शन पर एसएमटीपी पोर्ट का उपयोग बहुत सीमित है। IoT उपकरणों के लिए SMTP का वास्तव में इतना उपयोग नहीं है।

— एसा जोकिनेन
स्रोत

लेकिन अगर डोमेन (या एक आईपी) मेल के लिए कोई एमएक्स डीएनएस रिकॉर्ड नहीं है, तो ईमेल पते (होस्टनाम या आईपी पते) के डोमेन भाग को डिलीवर (या वितरित करने का प्रयास) किया जाता है। और प्राप्त सर्वर को उस होस्टनाम / आईपी पते के लिए मेल को संभालने के लिए कॉन्फ़िगर करना होगा।

— ivanivan

यह hostname के लिए मेल को हैंडल कर सकता है । दुनिया में हर सर्वर मेल को संभालता नहीं है। अधिकांश यूनिक्स / लिनक्स आधारित सर्वरों में आंतरिक मेल (क्रोन आदि से) को संभालने के लिए एसएमटीपी सर्वर होता है, लेकिन वे बिना अच्छी तरह से भी काम कर सकते हैं।

— Esa Jokinen

ईएसए - यदि आप अपने एमएक्स रिकॉर्ड को मेरे पोस्टफिक्स सर्वर पर इंगित करते हैं, तो एसएमटीपी कनेक्शन बनाया जाएगा लेकिन मेरे सर्वर को आपके डोमेन के लिए मेल को किसी भी तरह से आकार या रूप में कॉन्फ़िगर करने के लिए कॉन्फ़िगर नहीं किया गया है, इसलिए आपको एक उछाल मिलता है। लेकिन मेरे सर्वर कई विशिष्ट डोमेन और उपयोगकर्ताओं के लिए स्थापित हैं, सभी एक mysql सर्वर से आते हैं। यह सब 1 पर निर्भर करता है) क्या एक मेल सर्वर वास्तव में उस आईपी पर चल रहा है जिसे आप मेल भेज रहे हैं और 2) कहा जाता है कि मेल सर्वर को उस आईपी या सिर्फ एक विशिष्ट डोमेन / डोमेन या किसी भी डोमेन के लिए नियत मेल स्वीकार करने के लिए कॉन्फ़िगर किया गया है (केवल पते के उपयोगकर्ता भाग का मिलान)

— ivanivan

कई SMTP सर्वर (जैसे सेंडमेल) user@[aaa.bbb.ccc.ddd]ईमेल पते को संभालते हैं लेकिन

कुछ SMTP सर्वर इसे संभालते / पहचानते नहीं हैं
वे ऐसे प्रेषक पते को स्वीकार करने से इनकार कर सकते हैं या ऐसे पते पर भेजने में असमर्थ हो सकते हैं।
इस तरह के पते कुछ एंटी-स्पैम सॉफ़्टवेयर के साथ समस्या पैदा कर सकते हैं

RFC-5322: 3.4.1। Addr- विशेष विशिष्टता

विकिपीडिया: ईमेल पता - डोमेन भाग

... इसके अलावा, डोमेन एक आईपी एड्रेस शाब्दिक हो सकता है, जो चौकोर कोष्ठक से घिरा होता है [], जैसे कि jsmith @ [192.168.2.1] या jsmith @ [IPv6: 2001: db8 :: 1], हालाँकि यह शायद ही कभी देखा जाता है। ईमेल स्पैम । ...

— Anfi
स्रोत

ध्यान दें कि जैसे ईमेल पते user@[aaa.bbb.ccc.ddd]विनिर्देश के अनुसार सही हैं, और हैंडलिंग ठीक से परिभाषित है, इसलिए इसे संभालने वाले सर्वर तकनीकी रूप से "टूटे हुए" नहीं हैं

— फेरीबग

@ फेरीबग: सच है, अस्वीकार करने के बाद से तकनीकी रूप से भी संभाल रहा है।

— Esa Jokinen

ध्यान दें कि "ईमेल शायद एक मेजबान के बजाय विशिष्ट आईपी पते पर भेजा गया था" "शायद स्पैम" लाल झंडे की श्रेणी में बहुत अधिक रैंक करता है और बहुत सारे एवीएएस सॉफ़्टवेयर इसे चुपचाप त्यागने का फैसला कर सकते हैं।

— शादुर

यह काम करना चाहिए अगर सभी शामिल पार्टियां वास्तव में आधुनिक सॉफ़्टवेयर का उपयोग करती हैं।

जबकि एसएमटीपी टीसीपी पर अच्छी तरह से काम करता है, यह कम से कम अपने मूल रूप में है, टीसीपी / आईपी पर आधारित प्रोटोकॉल में ही नहीं। यदि आप मूल RFC 821 को देखते हैं, तो एक "टीसीपी परिवहन" को परिभाषित किया गया है .... एक परिशिष्ट में।

RFC 2821 (1989 से) संख्यात्मक पते "हतोत्साहित" का उपयोग करने पर विचार करता है।

यहां तक कि ऐनक के अधिक आधुनिक संस्करण उस दर्शन को RFC5321 से कुछ हद तक बनाए रखते हैं: "SMTP विशेष ट्रांसमिशन सबसिस्टम से स्वतंत्र है और इसके लिए केवल एक विश्वसनीय ऑर्डर किए गए डेटा स्ट्रीम चैनल की आवश्यकता होती है। जबकि यह दस्तावेज़ विशेष रूप से टीसीपी पर परिवहन पर चर्चा करता है, अन्य ट्रांसपोर्ट संभव है। । RFC 821 [1] में से कुछ का वर्णन।

हालाँकि, यह RFC - 2008 से, जो वास्तव में इसे बहुत नया बनाता है, "एड्रेस" को "अनुमति" के रूप में उपयोग करने की मंजूरी देता है ("इस बाधा को बायपास करने के लिए, पते के एक विशेष शाब्दिक रूप को डोमेन के विकल्प के रूप में अनुमति दी जाती है" नाम। ") धारा 4.1.3 में लेकिन फिर भी इसे 2.1.4 में" SHOULD NOT "के रूप में हतोत्साहित करता है।

SMTP, और इसके आस-पास बनाए गए अधिकांश सॉफ्टवेयर, होस्ट्स का उपयोग करते हैं , न कि आईपी पतों का , इसकी "मूल मुद्रा" के रूप में - यदि एक "पता शाब्दिक" एक "होस्ट" के रूप में उपयोग करने योग्य है, तो यह हो। और इसलिए (ज्यादातर आउटमोड्ड) नॉन-एसएमटीपी प्रोटोकॉल (जैसे यूयूसीपी मेल) का इस्तेमाल एसएमटीपी-आधारित सिस्टम के साथ पुराने के ईमेल इकोसिस्टम में किया गया था।

2008 के मानक के पूर्ण अनुपालन में होने वाली प्रत्येक शामिल प्रणाली पर भरोसा करना जितना लगता है उससे अधिक जोखिम भरा हो सकता है।

— rackandboneman
स्रोत

RFC 5321 # 2.1.4 पता शाब्दिकों का उपयोग करते हुए मंजूरी नहीं देता है: यह कहता है कि SHOULD NOT (और फिर गलत अनुभाग से लिंक करता है)। और RFC 2821 काफी पुराना नहीं है - यह 2001 था।

— Rup

मैं कहूंगा कि यह मेरे बीच की बात को साबित करता है :) .. .. उस "माइक्रो-मंजूरी" के बारे में एक स्पष्टीकरण एकीकृत, thx

— rackandboneman