সাইন এর ডান দিকের অংশটি কি বৈধ ওয়েবসাইট ঠিকানা হতে হবে?


11

সাইন ইন ইমেল ঠিকানাগুলিতে ডানদিকে অংশটি কোনও বৈধ ওয়েবসাইট ইউআরএল হতে হবে? আমি সবেমাত্র দুটি ইমেল ঠিকানা দেখেছি যেখানে ডান অংশটি কোনও ওয়েবসাইট ঠিকানা বলে মনে হচ্ছে না। আসলে, যখন আমি কোনও ওয়েব ব্রাউজারের মাধ্যমে এটি করার চেষ্টা করি তখন এটি খুলেনি।


12
দ্রষ্টব্য: ডাব্লুডাব্লুডাব্লু হওয়ার আগে ইন্টারনেটে ইমেল ছিল (আজকের মতো একই প্রোটোকল ব্যবহার করে)।
কার্স্টেন এস

উত্তর:


14

না এটি একই হতে হবে না। ইমেল ওয়েবসাইটগুলির চেয়ে পৃথক প্রোটোকল ব্যবহার করে এবং সর্বদা অভ্যন্তরীণ ইমেলগুলির জন্য (অভ্যন্তরীণ সংস্থাগুলি) অ-বিদ্যমান ডোমেন থাকার বিকল্প রয়েছে there's

উদাহরণস্বরূপ, যদি আমার কাছে কোনও ডোমেন নিয়ামক থাকে যা মাইডোমাইন.লোকালকে হোস্ট করে এবং এই ডোমেনের ভিতরে আমার একটি এক্সচেঞ্জ সার্ভার রয়েছে তবে আমার কাছে এলপিসিপ@মাইডোমাইন.লোকাল থাকতে পারে

যদি আমি কোনও ওয়েবসভারটি হোস্ট না করি এবং ওয়েবসাইট তৈরি করে এমন সমস্ত কিছু অক্ষম করি, তবে http: //MyDomain.local কাজ করবে না।

সর্বোপরি, কেবলমাত্র এটি একটি অভ্যন্তরীণ ঠিকানা, এটি বাইরে থেকেও কাজ করবে না।

যদি আমরা বাহ্যিক ইমেল ঠিকানাগুলি সম্পর্কে কথা বলি, তবে নিম্নলিখিত বিষয়গুলি:

ইমেল ঠিকানার 2 অংশ রয়েছে: ব্যবহারকারী এবং ডোমেন + বিকল্পভাবে সাবডোমেনগুলি।

যদি আমরা উদাহরণস্বরূপ নিই: LPChip@email.example.com, তবে এলপিসিপ ব্যবহারকারী, ইমেল সাবডোমেন এবং উদাহরণ.কম ডোমেন।

ডোমেনটির এমএক্স রেকর্ড রয়েছে যা ইমেলটি কোথায় রয়েছে তা জানিয়ে দেয়। এটিই এই রুটটি এসএমটিপি প্রোটোকল দ্বারা ইমেল সরবরাহ করতে ব্যবহৃত হয়।

এখন কোনও ওয়েবসাইটের ইউআরএলটিতে একটি @ থাকাও সম্ভব যা সাধারণত ব্যবহারকারী নাম @ ওয়েবসাইট মানে তবে ওয়েবসাইটের ইউরিতে @ চর হিসাবেও ব্যবহার করা যেতে পারে।

উদাহরণস্বরূপ, নিম্নলিখিত ওয়েবসাইটের ঠিকানা বৈধ: https://example.net/owa/username@example.com

ইউরি এখানে /owa/username@example.com এবং এতে একটি @ রয়েছে।

আর একটি উদাহরণ হ'ল:

FTP: //username@ftp.example.com


1
সুতরাং, এসএমটিপি বাইরে প্রতিষ্ঠানের ইমেল বিতরণ করার জন্য একটি বৈধ ডোমেন নাম প্রয়োজন?
কোডজম্বি 10

2
হ্যাঁ যদি না এটি আইপি ঠিকানা না জেনে থাকে (ডোমেন যাইহোক এটি দেয়)। এছাড়াও, নোট করুন যে ওয়েবসাইটটি অবশ্যই এটি সমর্থন করে। এমনকি আপনি ব্যবহারকারীর নাম: পাসওয়ার্ড @ ডোমেনও করতে পারেন, তবে এটি অত্যন্ত সুরক্ষিত।
LPChip 10

1
যদিও এটি এখন বেশ সর্বব্যাপী যে @ এর পরে যে অংশটি একটি ডোমেন নাম এবং আজকাল একটি ডোমেন নাম বলা হয়, এটি একটি স্ট্রিং যুক্তিযুক্ত যা অন্যথায় একটি হোস্ট নাম এবং এটি @ এর পরে একটি হোস্টের নাম হিসাবে বিবেচিত হতে পারে। এটি কাজ করার জন্য অবশ্যই একটি এমএক্স রেকর্ড থাকতে হবে। আপনার যদি ইমেল.ডোমেন.কম নামে একটি হোস্ট থাকে এবং আপনি ইমেল.ডোমেন.কমের জন্য একটি এমএক্স রেকর্ড তৈরি করেন, আপনি মেইলটিকে ইউজার@email.domain.com এ সম্বোধন করতে পারেন এবং "ইমেল.ডোমেন.কম" কল করা যৌক্তিক একটি "হোস্টনাম", "ডোমেন নাম", বা "সাবডোমেন নাম" অংশ করুন।
টড উইলকক্স 20

1
@ জেসনস্ট্যাক সাধারণত আপনি পারবেন না। বেশিরভাগ ওয়েবসাইটগুলি বেসিক অথ ব্যবহার করে না। এবং আপনার "ব্যবহারকারীর নাম" একটি ইমেল ঠিকানা আছে যা বিবেচনা @করে তাতে কীভাবে আপনি এটি করতে পারেন? :)
hobbs

2
@ টডউইলকক্স ঠিকঠাকভাবে - এভাবেই ইন্টারনেট মেইলটি ইউপ্প হোস্টগুলিতে রূপান্তরিত হয়েছিল (এমন কিছু কিছু যা আমার সাথে দিনের সাথে কিছুটা অভিজ্ঞতা ছিল)। প্রতিটি ডিএনএস রেকর্ডে কোনও সম্পর্কিত আইপি ঠিকানা থাকে না (তবে এতে যদি কোনও এমএক্স এন্ট্রি অন্তর্ভুক্ত থাকে তবে অফ-ইন্টারনেট মেল রাউটিং কাজ করতে পারে) এবং প্রতিটি আইপি ঠিকানা কোনও ওয়েবসাইট হোস্ট করতে হয় না। আমি মনে করি ওপি "বৈধ ডোমেন নাম" এবং "বৈধ ওয়েবসাইট ঠিকানা" এর মধ্যে পার্থক্য সম্পর্কে বিভ্রান্ত হতে পারে।
জেমি হানরাহান

13

না, ওয়েবসাইট এবং ইমেল ঠিকানার মূলত তেমন কিছু নেই।

তথ্য @ মাইক্রোসফট.কম এর ডান অংশটির অর্থ হ'ল আপনি মাইক্রোসফট.কম নামে একটি ডোমেইনে ইমেল প্রেরণ করেছেন। ইমেল প্রেরণের জন্য ব্যবহৃত প্রোটোকলটি এসএমটিপি।

তবে ইউআরএল http://www.microsoft.com/ এর অর্থ আপনি www নামে একটি সার্ভারে হোস্ট করা তথ্য চান। ব্যবহৃত প্রোটোকল হ'ল এইচটিটিপি।

উভয় প্রোটোকলের জন্য এই দুটি অংশ উপস্থিত থাকার প্রয়োজন নেই। এবং বিপরীতটিও বৈধ। উদাহরণস্বরূপ, আপনার কাছে http://support.dell.com/ এর মতো একটি সমর্থন ওয়েবসাইট থাকতে পারে এবং @ সমর্থন.dell.com কোনও ইমেল ঠিকানা নেই।


1
এটি যদি আপনি মাইক্রোসফট.কম ব্যবহার করেন তবে কমপক্ষে ডোমেনটি একই রকম হয় better
অরবিটে হালকাতা রেস

10

ইউজার@example.org যদি একটি কার্যকারী ইমেল ঠিকানা হয় উদাহরণস্বরূপ এমএক্স রেকর্ডটি কোনও कार्यरत মেল সার্ভারের দিকে ইঙ্গিত করে যা সেই ইমেল ঠিকানাটির জন্য মেইল ​​গ্রহণ করে (যেমন পোর্ট 25 শুনে এবং এসএমটিপি অনুরোধ পরিচালনা করে)।

http://example.org/ একটি কার্যকারী ইউআরএল যদি উদাহরণ.org এর একটি রেকর্ড কোনও ওয়েব সার্ভার চালিত হোস্টকে নির্দেশ করে (যেমন পোর্ট ৮০ শুনে এবং এইচটিটিপি অনুরোধ পরিচালনা করে)। উদাহরণ.আরজে কোনও ওয়েব সার্ভার না থাকলে, বেশিরভাগ ব্রাউজারগুলি http://www.example.org/ এ চেষ্টা করার জন্য স্ট্যান্ডার্ড প্রস্তাবনা অনুসরণ করে ।

প্রাসঙ্গিক ইন্টারনেট আরএফসি দেখুন, যেমন টিসিপি-র জন্য যেখানে এটি বন্দরগুলি ব্যাখ্যা করে, যদি আপনি আরও বিশদ চান want

এটি দুটি পৃথক পরিষেবা যা সম্পূর্ণ পৃথক। একটি সার্ভার একটি বা উভয় চলমান হতে পারে।

টেরোসোরাস যেমন উল্লেখ করেছেন, "বৈধ" এর নন-এ-সিনট্যাক্স-ত্রুটির প্রযুক্তিগত অর্থ রয়েছে, অগত্যা "কাজ করা" নয়। আরও উত্তর দেখুন।


ডিএনএসের ক্ষেত্রে ইমেল বিশেষ। এমএক্স রেকর্ডগুলি কোনও ডোমেইন নামের জন্য মেল-এক্সচেঞ্জ হিসাবে যে কোনও মেল সার্ভারকে তালিকাভুক্ত করতে পারে। অন্যান্য সমস্ত পরিষেবাদি (এসএসএস, এফটিপি, এইচটিপি, https, ইত্যাদি) প্রথমে ইন্ডিয়ারেশনের অতিরিক্ত স্তরের জন্য "উদাহরণস্বরূপের জন্য এফটিপি সার্ভার কী" রেকর্ড করার চেয়ে সরাসরি এ (আইপি ঠিকানা) রেকর্ড ব্যবহার করে। যদিও এই প্রশ্নের জন্য এটি অপ্রাসঙ্গিক। সমস্ত ইন্টারনেট পরিষেবাদি অরথোগোনাল, এবং কোনও প্রদত্ত ডোমেন নামের জন্য উপস্থিত থাকতে পারে বা নাও থাকতে পারে।

(একটি রাউটার / ফায়ারওয়াল দ্বারা পোর্ট ভিত্তিক রাউটিং বড় সাইটের জন্য প্রয়োজনে একক আইপি-র জন্য বিভিন্ন সার্ভারে HTTP এবং ftp ট্র্যাফিককে বিভক্ত করতে পারে (উদাহরণস্বরূপ), যাতে অন্যান্য পরিষেবাদি তাদের নিজস্ব দিকনির্দেশনা না পেয়ে নিখোঁজ হয় না ইমেলের মত রেকর্ড।)


2
এটি এখন পর্যন্ত সেরা উত্তর।
কেভন

1
কেভন: ধন্যবাদ :) অন্য দুটি উত্তর সত্যিই পয়েন্ট, আইএমওর কাছে পৌঁছায়নি এবং কিছুটা বিভ্রান্ত দেখছিলেন।
পিটার কর্ডস

1
সেখানে হয় যে পরিষেবাগুলি ব্যবহারের SRVবিশিষ্ট উদাহরণ SIP র এবং পাওয়া XMPP রয়েছে - রেকর্ড অপ্রত্যক্ষ্যতার একটি অনুরূপ সাজানোর প্রদান। আমরা যদি স্ক্র্যাচ থেকে ইন্টারনেট পুনর্নির্মাণ করতাম তবে আমরা সবকিছুর জন্য এটি করতে চাই।
zwol

3

ওপি (এবং সম্ভবত কিছু মন্তব্যকারী / উত্তর) শব্দভাণ্ডারে বিভ্রান্ত হতে পারে।

একটি বৈধ ওয়েবসাইট ইউআরএল ( খুব বেশি পেডেন্টিক না হওয়ার চেষ্টা করার সময় ) দুটি ভিন্ন জিনিসের মধ্যে একটি হতে পারে:

  1. একটি বৈধ বিন্যাসের ইউআরএল (আধুনিক অভিধানে ইউআরআই) যেমন abc://azertyfoo.baz:303/- এটি তবে কোনও ওয়েব ঠিকানা নয়।
  2. একটি ইউআরএল যা উভয় সিনট্যাক্টিক্যালি বৈধ (উপরে হিসাবে), কিন্তু একটি জ্ঞাত স্কিম (কিছুটা আগে ://) সুনির্দিষ্ট করে এবং একটি বৈধ সমাধানের জন্য সম্পূর্ণ-যোগ্যতাসম্পন্ন ডোমেন নাম (এফকিউডিএন) রাখে। উদাহরণস্বরূপ: http://superuser.com:80/একটি বৈধ ওয়েবসাইট ইউআরএল (এই শর্তাদির অধীনে)।

অন্যান্য উত্তরগুলির প্রচুর পরিমাণে ওয়েবের (যেমন একটি রেকর্ড) বনাম ইমেল (এমএক্স রেকর্ডস) এর সাথে ডিএনএস রেকর্ডগুলির মধ্যে পার্থক্যগুলি চিহ্নিত করেছে।


আমি সন্দেহ করি যে লোকেরা সম্ভবত বিভ্রান্ত হচ্ছে ইমেল ঠিকানার হোস্ট অংশের সাথে থাকতে পারে ।

একটি হোস্ট একটি ইমেল ঠিকানায় নিম্নলিখিত যে কোনও হতে পারে:

  • একটি এফকিউডিএন, এমএক্স রেকর্ডগুলির সাথে সঠিকভাবে কনফিগার করা হয়েছে।
  • অন্যথায় সমাধানযোগ্য ডোমেন নাম যা পুরোপুরি যোগ্যতা অর্জন করতে পারে না (যেমনটি অনেক কর্পোরেট পরিবেশে ব্যবহৃত হয়)। উদাহরণস্বরূপ MyMail.local- স্পষ্টতই .localকোনও বৈধ শীর্ষ-স্তর-ডোমেন (টিএলডি) নয়, তবে এই ডোমেন নামটি এখনও বৈধ এবং কোনও কর্পোরেট পরিবেশে সমাধান হতে পারে।
  • একটি হোস্টনাম, যেমন localhost(অ্যাপাচে অনেক সংস্করণে ত্রুটি পৃষ্ঠাগুলির ডিফল্ট ঠিকানা webmaster@localhost, উদাহরণস্বরূপ)। স্থানীয় মেশিনের বাইরে কেউ এই ইনবক্সে মেইল ​​পাঠাতে সক্ষম হবে না, তবে, সেই মেশিনে (এটি অনুমান করে যে এটি সেন্ডমেল বা অনুরূপ চলছে), ঠিকানাটি বৈধ
  • একটি আইপি ঠিকানা 127.0.0.1- আবার এটি কোনও নির্দিষ্ট পরিবেশে বৈধ । তবে আমি সন্দেহ করি যে অনেকগুলি (বা কোনও?) মেল সার্ভারগুলি যদি আপনি ওপেন ইন্টারনেটে এটি চেষ্টা করে থাকেন তবে সেই হোস্টটির কাছে মেল ফরোয়ার্ড করে দেবেন।

এই উপযুক্ত হোস্টগুলির মধ্যে যে কোনও একটি উপযুক্ত ওয়েবসাইট ইউআরএল হতে পারে যদি কোনও উপযুক্ত স্কিম এবং পথে আবদ্ধ থাকে : http://[উপরের যে কোনওটি]/


ভাল কথা, ওপির "বৈধ" শব্দটি ব্যবহার না করে "কাজ করা" বলার জন্য আমার উত্তরকে আপডেট করেছে, যার আলাদা প্রযুক্তিগত অর্থ রয়েছে।
পিটার কর্ডস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.