क्या हस्ताक्षर के दाईं ओर का हिस्सा वैध वेबसाइट का पता होना चाहिए?


11

क्या ईमेल पते में साइन इन के दाईं ओर का हिस्सा एक वैध वेबसाइट url होना चाहिए? मैंने सिर्फ दो ईमेल पते देखे हैं जहाँ दाहिना भाग वेबसाइट का पता नहीं लगता है। वास्तव में, यह तब नहीं खुला जब मैंने वेब ब्राउज़र के माध्यम से ऐसा करने की कोशिश की।


12
नोट: WWW होने से पहले इंटरनेट पर (आज के समान प्रोटोकॉल का उपयोग करके) ईमेल था।
कार्स्टन एस

जवाबों:


14

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

उदाहरण के लिए, यदि मेरे पास एक डोमेन नियंत्रक है जो MyDomain.local को होस्ट करता है, और मेरे पास इस डोमेन के अंदर एक एक्सचेंज सर्वर है, तो मैं LPChip@MyDomain.local हो सकता है

यदि मैं एक वेबसर्वर की मेजबानी नहीं करता और वेबसाइटों को बनाने वाली हर चीज को निष्क्रिय कर देता, तो http: //MyDomain.local काम नहीं करता।

उसके ऊपर, यह देखते हुए कि यह केवल एक आंतरिक पता है, यह बाहर से भी काम नहीं करेगा।

अगर हम बाहरी ईमेल पतों के बारे में बात करते हैं, तो निम्नलिखित मामले हैं:

ईमेल पते के 2 भाग हैं: उपयोगकर्ता और डोमेन + वैकल्पिक रूप से उप डोमेन।

यदि हम उदाहरण के लिए लेते हैं: LPChip@email.example.com, तो LPChip उपयोगकर्ता है, ईमेल उप डोमेन है और example.com डोमेन है।

डोमेन में एमएक्स रिकॉर्ड होते हैं जो बताते हैं कि ईमेल कहां स्थित है। यह इस मार्ग का उपयोग एसएमटीपी प्रोटोकॉल द्वारा ईमेल वितरित करने के लिए किया जाता है।

अब इसका एक वेबसाइट url में @ होना भी संभव है, जिसका आमतौर पर उपयोगकर्ता नाम @ वेबसाइट होता है, लेकिन इसका उपयोग वेबसाइट के uri में @ char के रूप में भी किया जा सकता है।

उदाहरण के लिए, निम्नलिखित वेबसाइट का पता मान्य है: https://example.net/owa/username@example.com

यहाँ का uri /owa/username@example.com है और इसमें @ शामिल है।

एक और उदाहरण यह है:

एफ़टीपी: //username@ftp.example.com


1
तो, एसएमटीपी को संगठनों के बाहर ईमेल देने के लिए एक वैध डोमेन नाम की आवश्यकता होती है?
कोडजॉम्बिन

2
हां, जब तक कि यह आईपी पता नहीं जानता (जो कि वैसे भी डोमेन देता है)। इसके अलावा, ध्यान दें कि वेबसाइट को इसका समर्थन करना चाहिए। आप उपयोगकर्ता नाम: पासवर्ड @ डोमेन भी कर सकते हैं, लेकिन यह बहुत असुरक्षित है।
LPChip

1
हालांकि यह बहुत अधिक सर्वव्यापी है कि @ के बाद का हिस्सा एक डोमेन नाम है और इन दिनों एक डोमेन नाम कहा जाता है, यह एक स्ट्रिंग डालने के लिए भी मान्य है जो अन्यथा एक होस्ट नाम है और @ के बाद होस्ट नाम माना जा सकता है। इसमें काम करने के लिए MX रिकॉर्ड होना चाहिए। यदि आपके पास email.domain.com नामक एक होस्ट है और आप email.domain.com के लिए MX रिकॉर्ड बनाते हैं, तो आप user@email.domain.com पर मेल को संबोधित कर सकते हैं और "email.domain.com" को कॉल करना तर्कसंगत है। एक "होस्टनाम", "डोमेन नाम", या "उप डोमेन नाम" या तो भाग।
टोड विलकॉक्स

1
@ जैसनस्टैक आमतौर पर आप नहीं कर सकते। अधिकांश वेबसाइटें बेसिक ऑथेंट का उपयोग नहीं करती हैं। और आप GMail के साथ भी कैसे करेंगे, यह देखते हुए कि आपका "उपयोगकर्ता नाम" एक ईमेल पता है, जिसमें एक @है? :)
हॉब्स

2
@ToddWilcox वास्तव में - यह है कि कैसे इंटरनेट मेल uucp होस्ट्स के लिए रूट किया गया (कुछ मुझे दिन में वापस अनुभव था)। प्रत्येक DNS रिकॉर्ड में एक संबद्ध IP पता नहीं होता है (लेकिन यदि इसमें MX प्रविष्टि, ऑफ-इंटरनेट मेल रूटिंग काम कर सकती है) और प्रत्येक IP पते पर किसी वेब साइट की मेजबानी नहीं होती है। मुझे लगता है कि ओपी "मान्य डोमेन नाम" और "मान्य वेबसाइट पते" के बीच अंतर के बारे में भ्रमित हो सकता है।
जेमी हन्रहान

13

नहीं, वेबसाइट और ईमेल पते में मूल रूप से कुछ भी नहीं है।

Info@microsoft.com के दाहिने हिस्से का अर्थ है कि आप microsoft.com नामक डोमेन पर ईमेल भेजते हैं। ईमेल भेजने के लिए उपयोग किया जाने वाला प्रोटोकॉल SMTP है।

लेकिन url http://www.microsoft.com/ का अर्थ है कि आप www नामक सर्वर पर होस्ट की गई जानकारी चाहते हैं। प्रोटोकॉल का उपयोग HTTP है।

यह आवश्यक नहीं है कि ये दोनों भाग दोनों प्रोटोकॉल के लिए मौजूद हों। और इसके विपरीत भी मान्य है। उदाहरण के लिए, आपके पास http://support.dell.com/ जैसी कोई समर्थन वेबसाइट हो सकती है और जिसका कोई ईमेल पता नहीं है @ support.dell.com।


1
यह एक बेहतर उदाहरण होगा यदि आप microsoft.com का उपयोग करते हैं तो कम से कम डोमेन उसी का है।
लाइट ऑक्ट्स ऑर्बिट

10

user@example.org एक कामकाजी ईमेल पता है, यदि MX उदाहरण example.org के लिए काम करने वाले मेल सर्वर की ओर इशारा करता है, जो उस ईमेल पते के लिए मेल स्वीकार करता है (यानी पोर्ट 25 को सुनना और SMTP अनुरोधों को संभालना)।

http://example.org/ एक कामकाजी URL है यदि उदाहरण के लिए A रिकॉर्ड एक वेब सर्वर चलाने वाले होस्ट को इंगित करता है (यानी पोर्ट 80 पर सुन रहा है और HTTP अनुरोधों को संभाल रहा है)। यदि example.org पर कोई वेब सर्वर नहीं है, तो अधिकांश ब्राउज़र http://www.example.org/ को आज़माने के लिए मानक अनुशंसा का पालन करते हैं ।

यदि आप अधिक विवरण चाहते हैं, तो टीसीपी के लिए संबंधित इंटरनेट आरएफसी, जैसे कि पोर्ट बताते हैं, को देखें।

ये दो अलग-अलग सेवाएं हैं जो पूरी तरह से अलग हैं। एक सर्वर एक या दोनों चल रहा हो सकता है।

जैसा कि टेरोसॉरोस बताते हैं, "वैध" का एक तकनीकी अर्थ है न कि वाक्य-रचना-त्रुटि, जरूरी नहीं कि "काम करना"। उस उत्तर को और देखें


DNS के लिहाज से ईमेल खास है। एमएक्स रिकॉर्ड किसी भी मेल सर्वर को एक डोमेन नाम के लिए मेल-एक्सचेंज के रूप में सूचीबद्ध कर सकते हैं। अन्य सभी सेवाएँ (ssh, ftp, http, https, इत्यादि) एक अप्रत्यक्ष रूप से एक अतिरिक्त परत के लिए पहले "example.org के लिए एफ़टीपी सर्वर क्या है" रिकॉर्ड की जाँच करने के बजाय सीधे (आईपी एड्रेस) रिकॉर्ड का उपयोग करती हैं। यह इस सवाल के लिए अप्रासंगिक है, हालांकि। सभी इंटरनेट सेवाएं ऑर्थोगोनल हैं, और किसी भी डोमेन नाम के लिए मौजूद नहीं हो सकती हैं या नहीं।

(राउटर / फ़ायरवॉल द्वारा पोर्ट-आधारित रूटिंग http और ftp ट्रैफ़िक को विभाजित कर सकती है (उदाहरण के लिए) एक ही आईपी के लिए अलग-अलग सर्वरों के लिए अगर बड़ी साइटों के लिए ज़रूरी हो, तो अन्य सेवाएँ स्वयं अप्रत्यक्ष न होने से गायब हैं। ईमेल की तरह रिकॉर्ड करता है।)


2
यह अब तक का सबसे अच्छा जवाब है।
केवॉन

1
@ शेवन: धन्यवाद :)। दो अन्य उत्तर वास्तव में बिंदु, IMO के दिल को नहीं मिले, और कुछ भ्रामक लग रहे थे।
पीटर कॉर्ड्स

1
वहाँ रहे हैं सेवाओं है कि का उपयोग करता है SRVप्रमुख उदाहरण एसआईपी और XMPP कर रहे हैं - रिकॉर्ड अविवेक के एक समान प्रकार प्रदान करते हैं। अगर हम खरोंच से इंटरनेट का पुनर्निर्माण कर रहे थे तो हम हर चीज के लिए ऐसा करना चाहते हैं।
zwol

3

ओपी (और शायद कुछ टिप्पणीकार / उत्तर) शब्दावली में भ्रमित हो सकते हैं।

एक मान्य वेबसाइट url ( बहुत अधिक पांडित्य होने की कोशिश करते हुए ) दो अलग-अलग चीजों में से एक हो सकती है:

  1. एक मान्य प्रारूप URL (आधुनिक लेक्सिकॉन में यूआरआई), जैसे कि abc://azertyfoo.baz:303/- हालांकि यह एक वेब पता नहीं है ।
  2. एक ऐसा URL जो वाक्य-रचना दोनों के रूप में मान्य है (ऊपर के रूप में), लेकिन एक ज्ञात योजना (थोड़ा पहले ://) भी निर्दिष्ट करता है , और पूरी तरह से योग्य डोमेन नाम (FQDN) को हल करने वाला एक मान्य नाम देता है। उदाहरण के लिए: http://superuser.com:80/एक मान्य वेबसाइट URL (इन शर्तों के तहत) है।

बहुत से अन्य उत्तरों ने वेब (यानी ए रिकॉर्ड) बनाम ईमेल (एमएक्स रिकॉर्ड) के संबंध में डीएनएस रिकॉर्ड में अंतर को संबोधित किया है।


मुझे संदेह है कि जहां लोग शायद भ्रमित हो रहे हैं वे ईमेल पते के होस्ट हिस्से के साथ हो सकते हैं ।

एक ईमेल पते में एक मेजबान निम्नलिखित में से कोई भी हो सकता है:

  • FQDN, MX रिकॉर्ड के साथ ठीक से कॉन्फ़िगर किया गया है।
  • एक अन्यथा resolvable डोमेन नाम जो पूरी तरह से योग्य नहीं हो सकता है (जैसा कि कई कॉर्पोरेट वातावरण में उपयोग किया जाता है)। उदाहरण के लिए MyMail.local- स्पष्ट रूप .localसे एक मान्य शीर्ष-स्तरीय-डोमेन (TLD) नहीं है, हालाँकि यह डोमेन नाम अभी भी मान्य है और कॉर्पोरेट वातावरण में हल हो सकता है।
  • एक होस्टनाम, जैसे localhost(अपाचे के कई संस्करणों में त्रुटि पृष्ठों पर डिफ़ॉल्ट पता webmaster@localhost, उदाहरण के लिए)। स्थानीय मशीन से परे कोई भी कभी भी उस इनबॉक्स पर मेल नहीं भेज सकेगा, हालांकि, उस मशीन पर (यह मानते हुए कि यह सेंडमेल या इसी तरह चल रहा है), पता मान्य है
  • एक आईपी पता, 127.0.0.1- फिर से यह एक विशेष वातावरण में मान्य है। हालाँकि, मुझे संदेह है कि कई (या कोई?) मेलस्वर्स उस होस्ट को मेल भेजेंगे यदि आपने ओपन इंटरनेट पर यह प्रयास किया है।

यदि कोई उचित योजना और पथ में संलग्न है, तो इनमें से कोई भी मान्य होस्ट एक मान्य वेबसाइट url भी हो सकता है : http://[उपरोक्त में से कोई भी]/


अच्छा बिंदु, ओपी शब्द "वैध" का उपयोग करने के बजाय "काम" कहने के लिए मेरे उत्तर को अपडेट किया, जिसका एक अलग तकनीकी अर्थ है।
पीटर कॉर्ड्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.