সিম্পল মেইল ট্রান্সফার প্রোটোকল

সিম্পল মেইল ট্রান্সফার প্রোটোকল (এসএমটিপি) হলো ইমেইল আদান-প্রদানের জন্য একটি ইন্টারনেট মানদণ্ড যোগাযোগ প্রোটোকল। মেইল সার্ভার এবং অন্যান্য মেসেজ ট্রান্সফার এজেন্ট ই-মেইল বার্তা পাঠাতে এবং গ্রহণ করতে এসএমটিপি ব্যবহার করে। ব্যবহারকারী-পর্যায়ের ই-মেইল ক্লায়েন্টগুলো সাধারণত মেইল সার্ভারে বার্তা রিলে করার জন্য বা পাঠাতে শুধুমাত্র এসএমটিপি ব্যবহার করে এবং অনুযায়ী সাধারণত পোর্ট ৪৬৫ বা ৫৮৭-এ মেইল সার্ভারে আউটগোয়িং ইমেইল জমা দেয়। বার্তা পুনরুদ্ধারের জন্য, আইএমএপি (যা পুরানো পিওপি৩-কে প্রতিস্থাপন করেছে) মানসম্মত, তবে প্রোপ্রাইটারি বা মালিকানাধীন সার্ভারগুলো প্রায়শই নিজস্ব প্রোটোকল প্রয়োগ করে, যেমন- এক্সচেঞ্জ অ্যাক্টিভসিঙ্ক।

১৯৭১ সাল থেকে আরপানেট-এ প্রবর্তিত ধারণাগুলোর ওপর ভিত্তি করে ১৯৮০ সালে এসএমটিপির উৎপত্তি হয়। এটি একাধিকবার হালনাগাদ, পরিবর্তন এবং পরিবর্ধন করা হয়েছে। বর্তমানে প্রচলিত প্রোটোকল সংস্করণটির একটি সম্প্রসারণযোগ্য কাঠামো রয়েছে, যাতে প্রমাণীকরণ, এনক্রিপশন, বাইনারি ডেটা স্থানান্তর এবং আন্তর্জাতিক ইমেইল ঠিকানার জন্য বিভিন্ন এক্সটেনশন যুক্ত রয়েছে। এসএমটিপি সার্ভারগুলো সাধারণত পোর্ট নম্বর ২৫ (সার্ভারগুলোর মধ্যে) এবং ৫৮৭ (প্রমাণিত ক্লায়েন্ট থেকে জমার জন্য) ব্যবহার করে ট্রান্সমিশন কন্ট্রোল প্রোটোকল ব্যবহার করে, উভয়ক্ষেত্রেই এনক্রিপশন সহ বা ছাড়া এবং জমার জন্য এনক্রিপশন সহ পোর্ট ৪৬৫ ব্যবহার করে।

 ইতিহাস 

 এসএমটিপি-এর পূর্বসূরীসমূহ 
১৯৬০-এর দশকে বিভিন্ন ধরনের ওয়ান-টু-ওয়ান ইলেকট্রনিক মেসেজিং ব্যবস্থা ব্যবহৃত হতো। ব্যবহারকারীরা নির্দিষ্ট মেইনফ্রেম কম্পিউটার-এর জন্য তৈরি সিস্টেম ব্যবহার করে যোগাযোগ করতেন। যখন আরও বেশি কম্পিউটার একে অপরের সাথে সংযুক্ত হতে শুরু করে, বিশেষ করে মার্কিন সরকারের আরপানেট-এ, তখন বিভিন্ন অপারেটিং সিস্টেমের মধ্যে বার্তা বিনিময়ের অনুমতি দেওয়ার জন্য নির্দিষ্ট মানদণ্ড বা স্ট্যান্ডার্ড তৈরি করা হয়।

আরপানেট-এ মেইলের ইতিহাস ১৯৭১ সাল পর্যন্ত বিস্তৃত: 'মেইল বক্স প্রোটোকল', যা আসলে বাস্তবায়িত হয়নি,The History of Electronic Mail , টম ভ্যান ভ্লেক: "এটি পরিষ্কার নয় যে এই প্রোটোকলটি কখনও বাস্তবায়িত হয়েছিল কি না" কিন্তু-এ আলোচিত হয়েছিল; এবং SNDMSG প্রোগ্রাম, যা বিবিএন-এর রে টমলিনসন সেই বছর আরপানেট-এ দুটি কম্পিউটারের মধ্যে বার্তা পাঠানোর জন্য অভিযোজিত করেছিলেন।The First Network Email, Ray Tomlinson, BBNPicture of "The First Email Computer" by Dan Murphy, a PDP-10Dan Murphy's TENEX and TOPS-20 Papers  ১৯৭৩ সালের জুনে RFC 524-এ একটি মেইল প্রোটোকলের আরও একটি প্রস্তাব করা হয়েছিল যা বাস্তবায়িত হয়নি।

১৯৭৩ সালের মার্চ মাসে আরএফসি ৪৬৯-এ আরপানেট-এ "নেটওয়ার্ক মেইল"-এর জন্য ফাইল ট্রান্সফার প্রোটোকল (এফটিপি) ব্যবহারের প্রস্তাব করা হয়েছিল।Internet Mail Meeting Summary RFC 561, RFC 680, RFC 724 এবং সবশেষে ১৯৭৭ সালের নভেম্বরে RFC 733-এর মাধ্যমে এফটিপি মেইল সার্ভার ব্যবহার করে "ইলেকট্রনিক মেইল"-এর জন্য একটি প্রমিত কাঠামো তৈরি করা হয়।RFC 733, 21 November 1977, Standard for the Format of ARPA Network Text Message

এসএমটিপি মূলত ১৯৭০-এর দশকে বিকশিত এই মানদণ্ডগুলো থেকেই উদ্ভূত হয়েছে। রে টমলিনসন ১৯৭৪ সালের সেপ্টেম্বরে লেখা INWG Protocol note 2-এ ইন্টারন্যাশনাল নেটওয়ার্ক ওয়ার্কিং গ্রুপ-এর মধ্যে নেটওয়ার্ক মেইল নিয়ে আলোচনা করেছিলেন। INWG ১৯৭৯ সালে ইলেকট্রনিক মেইলের প্রোটোকল নিয়ে আলোচনা করে,Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979. যা জন পোস্টেল তার ইন্টারনেট ইমেইল সংক্রান্ত প্রাথমিক কাজে উল্লেখ করেছিলেন। পোস্টেল ১৯৭৯ সালে ইন্টারনেট এক্সপেরিমেন্ট নোট ( সিরিজের অংশ হিসেবে প্রথম একটি ইন্টারনেট মেসেজ প্রোটোকলের প্রস্তাব করেন।

 মূল এসএমটিপি 
১৯৮০ সালে পোস্টেল এবং সুজান স্লুইজার প্রকাশ করেন, যেখানে মেইলের জন্য এফটিপি ব্যবহারের বিকল্প হিসেবে 'মেইল ট্রান্সফার প্রোটোকল'-এর প্রস্তাব করা হয়। ১৯৮১ সালের মে মাসের থেকে এফটিপি-এর সমস্ত রেফারেন্স সরিয়ে ফেলা হয় এবং টিসিপি ও ইউডিপি-এর জন্য পোর্ট ৫৭ বরাদ্দ করা হয়, যা পরবর্তীতে আইএএনএ দ্বারা বাতিল করা হয়েছে। ১৯৮১ সালের নভেম্বরে পোস্টেল "সিম্পল মেইল ট্রান্সফার প্রোটোকল" প্রকাশ করেন।

এসএমটিপি মানদণ্ডটি ইউজনেট-এর কাছাকাছি সময়ে তৈরি হয়েছিল, যা অনেকটা একই ধরনের ওয়ান-টু-ম্যানি যোগাযোগ নেটওয়ার্ক ছিল।

১৯৮০-এর দশকের শুরুতে এসএমটিপি ব্যাপকভাবে ব্যবহৃত হতে শুরু করে। সেই সময়ে এটি ইউনিক্স টু ইউনিক্স কপি প্রোগ্রাম-এর পরিপূরক ছিল, যা সেইসব মেশিনের মধ্যে ইমেইল স্থানান্তরের জন্য বেশি উপযোগী ছিল যেগুলো মাঝে মাঝে নেটওয়ার্কে যুক্ত হতো। অন্যদিকে, এসএমটিপি সবচেয়ে ভালো কাজ করে যখন প্রেরক এবং প্রাপক উভয় মেশিনই সার্বক্ষণিক নেটওয়ার্কে যুক্ত থাকে। উভয়ই স্টোর অ্যান্ড ফরওয়ার্ড মেকানিজম ব্যবহার করত এবং এগুলো পুশ প্রযুক্তি-এর উদাহরণ। যদিও ইউজনেটের নিউজগ্রুপগুলো তখনও সার্ভারের মধ্যে ইউইউসিপি-এর মাধ্যমে আদান-প্রদান করা হতো, মেইল ট্রান্সপোর্ট হিসেবে ইউইউসিপি এবং এর ব্যবহৃত "ব্যাং পাথ" রাউটিং এখন কার্যত বিলুপ্ত।The article about sender rewriting contains technical background info about the early SMTP history and source routing before.

১৯৮৩ সালে 4.1cBSD-এর সাথে মুক্তি পাওয়া সেন্ডমেইল ছিল প্রথম মেইল ট্রান্সফার এজেন্টগুলোর (এমটিএ) একটি যা এসএমটিপি বাস্তবায়ন করেছিল। সময়ের সাথে সাথে বিএসডি ইউনিক্স ইন্টারনেটে সবচেয়ে জনপ্রিয় অপারেটিং সিস্টেম হয়ে উঠলে, Sendmail সবচেয়ে সাধারণ মেইল ট্রান্সফার এজেন্ট হিসেবে পরিচিতি পায়।

মূল এসএমটিপি প্রোটোকল শুধুমাত্র অপ্রমাণিত এবং এনক্রিপশনবিহীন ৭-বিট ASCII টেক্সট যোগাযোগ সমর্থন করত, যা খুব সহজেই ম্যান-ইন-দ্য-মিডল অ্যাটাক, স্পুফিং এবং স্প্যামিং-এর শিকার হতে পারত এবং যেকোনো বাইনারি ডেটা পাঠানোর আগে পাঠযোগ্য টেক্সটে রূপান্তর করার প্রয়োজন হতো। সঠিক প্রমাণীকরণ ব্যবস্থার অভাবে নকশা অনুযায়ী প্রতিটি এসএমটিপি সার্ভার একটি ওপেন মেইল রিলে ছিল। ইন্টারনেট মেইল কনসোর্টিয়াম জানিয়েছে যে, ১৯৯৮ সালে ৫৫% মেইল সার্ভার ওপেন রিলে ছিল, কিন্তু ২০০২ সালে তা কমে ১%-এর নিচে নেমে আসে। স্প্যামের উদ্বেগের কারণে বেশিরভাগ ইমেইল সরবরাহকারী ওপেন রিলেগুলোকে ব্লকলিস্ট বা কালো তালিকাভুক্ত করে, যার ফলে মূল এসএমটিপি ইন্টারনেটে সাধারণ ব্যবহারের জন্য কার্যত অবাস্তব হয়ে পড়েছে।

 আধুনিক এসএমটিপি 
১৯৯৫ সালের নভেম্বরে এক্সটেন্ডেড সিম্পল মেইল ট্রান্সফার প্রোটোকল (ইএসএমটিপি) সংজ্ঞায়িত করে, যা বিদ্যমান এবং ভবিষ্যতের সমস্ত এক্সটেনশনের জন্য একটি সাধারণ কাঠামো তৈরি করে। এর লক্ষ্য ছিল মূল এসএমটিপি-তে অনুপস্থিত ফিচারগুলো যোগ করা। ইএসএমটিপি এমন একটি সামঞ্জস্যপূর্ণ পদ্ধতি নির্ধারণ করে যার মাধ্যমে ইএসএমটিপি ক্লায়েন্ট এবং সার্ভারগুলো শনাক্ত করা যায় এবং সার্ভারগুলো কোন কোন এক্সটেনশন সমর্থন করে তা জানাতে পারে।

বার্তা জমা দেওয়া এবং এসএমটিপি প্রমাণীকরণ ১৯৯৮ এবং ১৯৯৯ সালে প্রবর্তিত হয়, যা ইমেইল ডেলিভারির নতুন ধারা বর্ণনা করে। মূলত এসএমটিপি সার্ভারগুলো সাধারণত একটি প্রতিষ্ঠানের অভ্যন্তরীণ ছিল, যা প্রতিষ্ঠানের জন্য 'বাইরে থেকে' মেইল গ্রহণ করত এবং প্রতিষ্ঠান থেকে বার্তাগুলো 'বাইরের দিকে' রিলে করত। কিন্তু সময়ের সাথে সাথে এসএমটিপি সার্ভারগুলো (মেইল ট্রান্সফার এজেন্ট) বাস্তবে মেইল ব্যবহারকারীদের জন্য মেসেজ সাবমিশন এজেন্টের ভূমিকা পালন করতে শুরু করে, যার মধ্যে কিছু এখন কোনো প্রতিষ্ঠানের 'বাইরে থেকে' মেইল রিলে করছিল (যেমন একজন কোম্পানি নির্বাহী ভ্রমণের সময় করপোরেট এসএমটিপি সার্ভার ব্যবহার করে ইমেইল পাঠাতে চাইছেন)। ওয়ার্ল্ড ওয়াইড ওয়েব-এর দ্রুত প্রসার এবং জনপ্রিয়তার কারণে এসএমটিপি-তে মেইল রিলে করা এবং ব্যবহারকারীদের প্রমাণীকরণের জন্য নির্দিষ্ট নিয়ম এবং পদ্ধতি অন্তর্ভুক্ত করতে হয় যাতে অযাচিত ইমেইল (স্প্যাম) পাঠানোর মতো অপব্যবহার রোধ করা যায়। মেসেজ সাবমিশন নিয়ে কাজ শুরু হয়েছিল কারণ জনপ্রিয় মেইল সার্ভারগুলো প্রায়শই মেইলের সমস্যা ঠিক করার জন্য তা পুনর্লিখন করত, যেমন একটি অসম্পূর্ণ ঠিকানায় ডোমেইন নাম যোগ করা। এই আচরণটি তখন সহায়ক যখন মেসেজটি প্রথমবার জমা দেওয়া হচ্ছে, কিন্তু মেসেজটি অন্য কোথাও থেকে এসে রিলে হওয়ার সময় এটি বিপজ্জনক এবং ক্ষতিকর হতে পারে। মেইলকে 'সাবমিশন' এবং 'রিলে' হিসেবে আলাদা করা হয়েছিল যাতে সাবমিশন পুনর্লিখনের সুযোগ থাকে কিন্তু রিলে পুনর্লিখন নিষিদ্ধ করা যায়। স্প্যামের প্রাদুর্ভাব বাড়ার সাথে সাথে এটি একটি প্রতিষ্ঠান থেকে পাঠানো মেইলের অনুমোদন এবং ট্র্যাকিং করার একটি উপায় হিসেবেও দেখা হয়। রিলে এবং সাবমিশনের এই পৃথকীকরণ দ্রুত আধুনিক ইমেইল সুরক্ষা ব্যবস্থার মূলে পরিণত হয়েছে।

যেহেতু এই প্রোটোকলটি শুরুতে সম্পূর্ণ ASCII টেক্সট-ভিত্তিক ছিল, তাই এটি বাইনারি ফাইল বা অনেক ইংরেজি-ব্যতীত ভাষার অক্ষরের সাথে ভালোভাবে কাজ করতে পারত না। এসএমটিপি-এর মাধ্যমে স্থানান্তরের জন্য বাইনারি ফাইল এনকোড করতে মাল্টিপারপাস ইন্টারনেট মেইল এক্সটেনশনস (মাইম)-এর মতো মানদণ্ড তৈরি করা হয়েছিল। সেন্ডমেইল-এর পরে বিকশিত মেইল ট্রান্সফার এজেন্টগুলো সাধারণত ৮-বিট ক্লিন হিসেবে তৈরি করা হয়েছিল, যাতে এসএমটিপি-এর মাধ্যমে যেকোনো টেক্সট ডেটা পাঠানোর জন্য বিকল্প কৌশল ব্যবহার করা যায়। বিভিন্ন ভেন্ডরের মধ্যে ক্যারেক্টার সেট ম্যাপিংয়ের পার্থক্যের কারণে মোজিভাকে তখনও একটি সমস্যা ছিল, যদিও ইমেইল ঠিকানাগুলো তখনও কেবল ASCII সমর্থন করত। বর্তমানের ৮-বিট-ক্লিন এমটিএ-গুলো সাধারণত 8BITMIME এক্সটেনশন সমর্থন করে, যা বাইনারি ফাইলগুলোকে প্রায় প্লেইন টেক্সটের মতোই সহজে পাঠানোর অনুমতি দেয়। ২০১২ সালে 
UTF-8 টেক্সট সমর্থন করার জন্য `SMTPUTF8` এক্সটেনশন তৈরি করা হয়েছিল, যা সিরিলিক বা চীনা অক্ষরের মতো ল্যাটিন-ব্যতীত লিপিতে আন্তর্জাতিক বিষয়বস্তু এবং ঠিকানা ব্যবহারের সুযোগ করে দেয়।

মূল এসএমটিপি স্পেসিফিকেশনে অনেক ব্যক্তি অবদান রেখেছেন, যাদের মধ্যে জন পোস্টেল, এরিক অলম্যান, ডেভ ক্রকার, নেড ফ্রিড, র‍্যান্ডাল গেলেন্স, জন ক্লিনসিন এবং কিথ মুর উল্লেখযোগ্য।

 মেইল প্রক্রিয়াকরণ মডেল 

ইমেইল একটি মেইল ক্লায়েন্ট (মেইল ইউজার এজেন্ট) দ্বারা একটি মেইল সার্ভারে (মেইল সাবমিশন এজেন্ট) জমা দেওয়া হয়, যা টিসিপি পোর্ট ৪৬৫ বা ৫৮৭-এ এসএমটিপি ব্যবহার করে। বেশিরভাগ মেইলবক্স প্রোভাইডার এখনও প্রথাগত পোর্ট ২৫-এ মেইল জমার অনুমতি দেয়। এমএসএ সেই মেইলটি তার মেইল ট্রান্সফার এজেন্টের কাছে পৌঁছে দেয়। প্রায়শই, এই দুটি এজেন্ট একই মেশিনে বিভিন্ন অপশনসহ চালু করা একই সফটওয়্যারের উদাহরণ। স্থানীয় প্রক্রিয়াকরণ একটি একক মেশিনে করা যেতে পারে, বা একাধিক মেশিনে ভাগ করা যেতে পারে; একটি মেশিনে মেইল এজেন্ট প্রসেসগুলো ফাইল শেয়ার করতে পারে, কিন্তু যদি প্রক্রিয়াকরণ একাধিক মেশিনে হয়, তবে তারা একে অপরের মধ্যে এসএমটিপি ব্যবহার করে বার্তা স্থানান্তর করে, যেখানে প্রতিটি মেশিন পরবর্তী মেশিনটিকে একটি স্মার্ট হোস্ট হিসেবে ব্যবহার করার জন্য কনফিগার করা থাকে। প্রতিটি প্রসেস বা প্রক্রিয়া নিজেই একটি এমটিএ (একটি এসএমটিপি সার্ভার)।

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

বার্তা স্থানান্তর দুটি এমটিএ-র মধ্যে একটি সংযোগে ঘটতে পারে, বা মধ্যবর্তী সিস্টেমের মাধ্যমে ধারাবাহিক হপ-এর মাধ্যমেও হতে পারে। একটি গ্রহণকারী এসএমটিপি সার্ভার চূড়ান্ত গন্তব্য, একটি মধ্যবর্তী "রিলে" (অর্থাৎ, এটি বার্তাটি সংরক্ষণ করে এবং ফরওয়ার্ড করে) বা একটি "গেটওয়ে" (অর্থাৎ, এটি এসএমটিপি ছাড়া অন্য কোনো প্রোটোকল ব্যবহার করে বার্তাটি ফরওয়ার্ড করতে পারে) হতে পারে। সেকশন ২.১ অনুযায়ী, প্রতিটি হপ হলো বার্তার জন্য দায়িত্বের একটি আনুষ্ঠানিক হস্তান্তর, যার মাধ্যমে গ্রহণকারী সার্ভারকে অবশ্যই বার্তাটি পৌঁছে দিতে হবে অথবা তা করতে ব্যর্থ হলে সঠিকভাবে রিপোর্ট করতে হবে।

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

একবার স্থানীয় মেইল সার্ভারে পৌঁছে দেওয়ার পর, মেইলটি প্রমাণীকৃত (authenticated) মেইল ক্লায়েন্ট-এর মাধ্যমে ব্যাচ পুনরুদ্ধারের জন্য সংরক্ষণ করা হয়। শেষ-ব্যবহারকারী অ্যাপ্লিকেশন, যাকে ইমেইল ক্লায়েন্ট বলা হয়, ইন্টারনেট মেসেজ অ্যাক্সেস প্রোটোকল—যা মেইল অ্যাক্সেস সহজতর করে এবং সংরক্ষিত মেইল পরিচালনা করে—অথবা পোস্ট অফিস প্রোটোকল ব্যবহার করে মেইল পুনরুদ্ধার করে। পপ সাধারণত প্রথাগত এমবক্স মেইল ফাইল ফরম্যাট বা মাইক্রোসফট এক্সচেঞ্জ/আউটলুক বা লোটাস নোটস/ডোমিনো-র মতো মালিকানাধীন সিস্টেম ব্যবহার করে। ওয়েবমেইল ক্লায়েন্টরা যেকোনো পদ্ধতি ব্যবহার করতে পারে, তবে পুনরুদ্ধার প্রোটোকলটি প্রায়শই আনুষ্ঠানিক মানদণ্ড মেনে চলে না।

এসএমটিপি বার্তার পরিবহন সংজ্ঞায়িত করে, বার্তার বিষয়বস্তু নয়। সুতরাং, এটি মেইল এনভেলপ এবং এর প্যারামিটারগুলো, যেমন এনভেলপ সেন্ডার, সংজ্ঞায়িত করে, কিন্তু হেডার (ট্রেস তথ্য ছাড়া) বা বার্তার মূল অংশ (বডি) সংজ্ঞায়িত করে না। এসটিডি ১০ এবং এসএমটিপি (এনভেলপ) সংজ্ঞায়িত করে, যেখানে এসটিডি ১১ এবং বার্তা (হেডার এবং বডি) সংজ্ঞায়িত করে, যা আনুষ্ঠানিকভাবে ইন্টারনেট মেসেজ ফরম্যাট হিসেবে পরিচিত।

 প্রোটোকল পরিচিতি 

এসএমটিপি হলো একটি সংযোগ-ভিত্তিক, টেক্সট-ভিত্তিক প্রোটোকল যেখানে মেইল প্রেরক একটি নির্ভরযোগ্য সুশৃঙ্খল ডেটা স্ট্রিম চ্যানেলের মাধ্যমে—সাধারণত একটি ট্রান্সমিশন কন্ট্রোল প্রোটোকল (টিসিপি) সংযোগ—কমান্ড স্ট্রিং ইস্যু করে এবং প্রয়োজনীয় ডেটা সরবরাহ করে মেইল প্রাপকের সাথে যোগাযোগ করে। একটি এসএমটিপি সেশন গঠিত হয় এসএমটিপি ক্লায়েন্ট (উদ্যোক্তা এজেন্ট বা প্রেরক) দ্বারা প্রেরিত কমান্ড এবং এসএমটিপি সার্ভার (শ্রোতা এজেন্ট বা প্রাপক) থেকে আসা সংশ্লিষ্ট প্রতিক্রিয়ার সমন্বয়ে, যাতে সেশনটি খোলা হয় এবং সেশনের প্যারামিটারগুলো বিনিময় করা হয়। একটি সেশনে শূন্য বা তার অধিক এসএমটিপি লেনদেন (transaction) থাকতে পারে। একটি এসএমটিপি লেনদেন তিনটি কমান্ড/উত্তর ক্রম নিয়ে গঠিত:

 মেইল কমান্ড, যা রিটার্ন অ্যাড্রেস বা রিটার্ন-পাথ প্রতিষ্ঠা করতে ব্যবহৃত হয়,"The MAIL, RCPT, and DATA verbs" , [D. J. Bernstein] একে রিভার্স-পাথ,Section-7.2 বাউন্স অ্যাড্রেস, এমফ্রম, বা এনভেলপ সেন্ডারও বলা হয়।
 আরসিপিটি কমান্ড, যা বার্তার প্রাপক নির্ধারণ করতে ব্যবহৃত হয়। এই কমান্ডটি একাধিকবার দেওয়া যেতে পারে, প্রতিটি প্রাপকের জন্য একবার করে। এই ঠিকানাগুলোও এনভেলপের অংশ।
 ডাটা যা মেসেজ টেক্সট বা বার্তার মূল অংশের শুরু নির্দেশ করে; এটি এনভেলপের বিপরীত, যা বার্তার বিষয়বস্তু ধারণ করে। এটি একটি মেসেজ হেডার এবং মেসেজ বডি নিয়ে গঠিত যা একটি খালি লাইন দ্বারা পৃথক থাকে। ডাটা আসলে কমান্ডের একটি গ্রুপ, এবং সার্ভার দুবার উত্তর দেয়: একবার ডাটা কমান্ড-এর উত্তরে, এটি জানাতে যে এটি টেক্সট গ্রহণ করতে প্রস্তুত, এবং দ্বিতীয়বার ডেটা সমাপ্তির ক্রম (end-of-data sequence) পরে, পুরো বার্তাটি গ্রহণ বা প্রত্যাখ্যান করার জন্য।

ডাটা-এর মধ্যবর্তী উত্তর ছাড়াও, প্রতিটি সার্ভারের উত্তর ইতিবাচক (2xx রিপ্লাই কোড) বা নেতিবাচক হতে পারে। নেতিবাচক উত্তর স্থায়ী (5xx কোড) বা ক্ষণস্থায়ী (4xx কোড) হতে পারে। একটি প্রত্যাখ্যান হলো স্থায়ী ব্যর্থতা এবং ক্লায়েন্টের উচিত যে সার্ভার থেকে এটি গ্রহণ করেছে তাকে একটি বাউন্স মেসেজ পাঠানো। একটি ড্রপ (ফেলে দেওয়া) হলো একটি ইতিবাচক সাড়া যার পরে বার্তাটি ডেলিভারি না করে বাতিল বা ডিসকার্ড করা হয়।

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

একটি এমইউএ তার কনফিগারেশন থেকে আউটগোয়িং মেইল এসএমটিপি সার্ভার সম্পর্কে জানে। একটি রিলে সার্ভার সাধারণত প্রাপকের ডোমেইন নামের জন্য এমএক্স (মেইল এক্সচেঞ্জ) ডিএনএস রিসোর্স রেকর্ড অনুসন্ধান করে কোন সার্ভারের সাথে সংযোগ করতে হবে তা নির্ধারণ করে। যদি কোনো এমএক্স রেকর্ড পাওয়া না যায়, তবে একটি সঙ্গতিপূর্ণ রিলে সার্ভার (সবগুলো নয়) এর পরিবর্তে এ রেকর্ড অনুসন্ধান করে। রিলে সার্ভারগুলোকে একটি স্মার্ট হোস্ট ব্যবহার করার জন্যও কনফিগার করা যেতে পারে। একটি রিলে সার্ভার এসএমটিপি-র জন্য "ওয়েল-নোন পোর্ট"-এ সার্ভারের সাথে একটি টিসিপি সংযোগ শুরু করে: পোর্ট ২৫, অথবা একটি MSA-এর সাথে সংযোগের জন্য পোর্ট ৪৬৫ বা ৫৮৭। এমটিএ এবং এমএসএ-এর মধ্যে মূল পার্থক্য হলো এমএসএ-তে সংযোগ করতে এসএমটিপি প্রমাণীকরণ প্রয়োজন।

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

 রিমোট মেসেজ কিউ স্টার্টিং 
রিমোট মেসেজ কিউ স্টার্টিং একটি রিমোট হোস্টকে সার্ভারে মেইল কিউ প্রক্রিয়াকরণ শুরু করতে সক্ষম করে, যাতে এটি একটি সংশ্লিষ্ট কমান্ড পাঠিয়ে তার জন্য নির্ধারিত বার্তাগুলো গ্রহণ করতে পারে। মূল `টার্ন` কমান্ডটিকে অনিরাপদ মনে করা হতো এবং-এ `ETRN` কমান্ড দিয়ে এটিকে বর্ধিত করা হয়েছে, যা ডোমেইন নেম সিস্টেম তথ্যের ওপর ভিত্তি করে একটি প্রমাণীকরণ পদ্ধতি ব্যবহার করে আরও নিরাপদে কাজ করে।

 বহির্গামী মেইল এসএমটিপি সার্ভার 
একটি ইমেইল ক্লায়েন্টের তার প্রাথমিক এসএমটিপি সার্ভারের আইপি ঠিকানা জানা প্রয়োজন এবং এটি কনফিগারেশনের অংশ হিসেবে দিতে হয় (সাধারণত ডিএনএস নাম হিসেবে)। এই সার্ভার ব্যবহারকারীর পক্ষ থেকে বহির্গামী বার্তা পৌঁছে দেয়।

 বহির্গামী মেইল সার্ভার অ্যাক্সেস সীমাবদ্ধতা 
সার্ভার প্রশাসকদের নিয়ন্ত্রণ আরোপ করতে হয় কোন ক্লায়েন্ট সার্ভার ব্যবহার করতে পারবে। এটি তাদের অপব্যবহার, যেমন স্প্যাম, মোকাবিলা করতে সক্ষম করে। দুটি সমাধান সাধারণত ব্যবহৃত হয়ে আসছে:

 অতীতে, অনেক সিস্টেম ক্লায়েন্টের অবস্থান দ্বারা ব্যবহারের সীমাবদ্ধতা আরোপ করত, শুধুমাত্র সেই ক্লায়েন্টদের অনুমতি দিত যাদের আইপি ঠিকানা সার্ভার প্রশাসকদের নিয়ন্ত্রণে আছে। অন্য কোনো ক্লায়েন্ট আইপি ঠিকানা থেকে ব্যবহার নিষিদ্ধ ছিল।
 আধুনিক এসএমটিপি সার্ভার সাধারণত একটি বিকল্প ব্যবস্থা অফার করে যা অ্যাক্সেস দেওয়ার আগে ক্রেডেনশিয়াল বা লগইন তথ্যের মাধ্যমে ক্লায়েন্টদের প্রমাণীকরণ দাবি করে।

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

এই ব্যবস্থার বেশ কিছু প্রকরণ রয়েছে। উদাহরণস্বরূপ, একটি সংস্থার এসএমটিপি সার্ভার শুধুমাত্র একই নেটওয়ার্কের ব্যবহারকারীদের সেবা প্রদান করতে পারে, যা ফায়ারওয়ালিংয়ের মাধ্যমে বিস্তৃত ইন্টারনেটের ব্যবহারকারীদের অ্যাক্সেস ব্লক করে কার্যকর করা হয়। অথবা সার্ভারটি ক্লায়েন্টের আইপি ঠিকানার রেঞ্জ চেক করতে পারে। এই পদ্ধতিগুলো সাধারণত কর্পোরেশন এবং বিশ্ববিদ্যালয়গুলোর মতো প্রতিষ্ঠানগুলো ব্যবহার করত, যারা শুধুমাত্র সংস্থার অভ্যন্তরে ব্যবহারের জন্য বহির্গামী মেইলের জন্য একটি এসএমটিপি সার্ভার প্রদান করত। যাইহোক, এই সংস্থাগুলোর বেশিরভাগই এখন ক্লায়েন্ট প্রমাণীকরণ পদ্ধতি ব্যবহার করে, যা নিচে বর্ণনা করা হয়েছে।

যেখানে একজন ব্যবহারকারী ভ্রাম্যমাণ (mobile), এবং ইন্টারনেটে সংযোগ করতে বিভিন্ন আইএসপি ব্যবহার করতে পারেন, সেখানে এই ধরনের ব্যবহারের সীমাবদ্ধতা কষ্টকর, এবং কনফিগার করা বহির্গামী ইমেইল এসএমটিপি সার্ভারের ঠিকানা পরিবর্তন করা অবাস্তব। ইমেইল ক্লায়েন্ট কনফিগারেশন তথ্য ব্যবহার করতে পারাটা অত্যন্ত কাম্য যা পরিবর্তন করার প্রয়োজন হয় না।

 ক্লায়েন্ট প্রমাণীকরণ 
আধুনিক এসএমটিপি সার্ভারগুলো আগে বর্ণিত অবস্থান দ্বারা অ্যাক্সেস সীমাবদ্ধ করার পরিবর্তে সাধারণত অ্যাক্সেস দেওয়ার আগে ক্রেডেনশিয়াল দ্বারা ক্লায়েন্টদের প্রমাণীকরণ দাবি করে। এই নমনীয় ব্যবস্থাটি মোবাইল ব্যবহারকারীদের জন্য সুবিধাজনক এবং তাদের কনফিগার করা বহির্গামী এসএমটিপি সার্ভারের একটি নির্দিষ্ট পছন্দ রাখার অনুমতি দেয়। এসএমটিপি অথেনটিকেশন, যা প্রায়শই এসএমটিপি প্রমাণীকরণ নামে সংক্ষিপ্ত করা হয়, এটি এসএমটিপি-র একটি সম্প্রসারণ যা একটি প্রমাণীকরণ প্রক্রিয়া ব্যবহার করে লগ ইন করতে ব্যবহৃত হয়।

 পোর্ট 
মেইল সার্ভারগুলোর মধ্যে যোগাযোগ সাধারণত এসএমটিপি-র জন্য নির্ধারিত স্ট্যান্ডার্ড টিসিপি পোর্ট ২৫ ব্যবহার করে।

তবে মেইল ক্লায়েন্টরা সাধারণত এটি ব্যবহার করে না, এর পরিবর্তে নির্দিষ্ট "সাবমিশন" পোর্ট ব্যবহার করে। মেইল পরিষেবাগুলো সাধারণত ক্লায়েন্টদের কাছ থেকে নিচের যেকোনো একটি পোর্টে ইমেইল সাবমিশন গ্রহণ করে:

 ৪৬৫: ইস্যু করার আগ পর্যন্ত-এর পর এই পোর্টটি বাতিল (deprecated) করা হয়েছিল।
 ৫৮৭ (সাবমিশন): যা-এ আনুষ্ঠানিকভাবে স্বীকৃত (পূর্বে)।

পোর্ট ২৫২৫ এবং অন্যান্য পোর্ট কিছু স্বতন্ত্র প্রোভাইডার ব্যবহার করতে পারে, তবে এগুলো কখনোই আনুষ্ঠানিকভাবে সমর্থিত হয়নি।

অনেক ইন্টারনেট সেবাদাতা এখন তাদের গ্রাহকদের কাছ থেকে সমস্ত বহির্গামী পোর্ট ২৫ ট্রাফিক ব্লক বা অবরুদ্ধ করে। মূলত স্প্যাম-বিরোধী পদক্ষেপ হিসেবে, তবে এটি খোলা রাখলে তাদের যে উচ্চ খরচ হয় তা কমানোর জন্যও, সম্ভবত যে অল্প সংখ্যক গ্রাহকের এটি খোলা রাখা প্রয়োজন তাদের কাছ থেকে বেশি চার্জ করার মাধ্যমে।

 এসএমটিপি ট্রান্সপোর্ট উদাহরণ 
একই মেইল ডোমেইনে (উদাহরণ.কম) অবস্থিত দুটি মেইলবক্সে (alice এবং theboss) এসএমটিপি-র মাধ্যমে বার্তা পাঠানোর একটি সাধারণ উদাহরণ নিচের সেশন বিনিময়ে তুলে ধরা হয়েছে। (এই উদাহরণে, কথোপকথনের অংশগুলো S: এবং C: দিয়ে শুরু হয়েছে, যা যথাক্রমে সার্ভার এবং ক্লায়েন্ট বোঝায়; এই লেবেলগুলো মূল বিনিময়ের অংশ নয়।)

বার্তা প্রেরক (এসএমটিপি ক্লায়েন্ট) বার্তা প্রাপকের (এসএমটিপি সার্ভার) সাথে একটি নির্ভরযোগ্য যোগাযোগের চ্যানেল স্থাপন করার পর, সার্ভার একটি সম্ভাষণ দিয়ে সেশনটি খোলে, যাতে সাধারণত এর ফুলি কোয়ালিফাইড ডোমেইন নেম (FQDN) থাকে, এই ক্ষেত্রে যা হলো এসএমটিপি.উদাহরণ.কম। ক্লায়েন্ট তার এফকিউডিএন (FQDN) (অথবা যদি কোনোটি উপলব্ধ না থাকে তবে একটি অ্যাড্রেস লিটারেল) দিয়ে নিজেকে শনাক্ত করে HELO কমান্ডের মাধ্যমে সাড়া দিয়ে কথোপকথন শুরু করে।

 S: 220 smtp.example.com ESMTP Postfix
 C: HELO relay.example.org
 S: 250 Hello relay.example.org, I am glad to meet you
 C: MAIL FROM:<bob@example.org>
 S: 250 Ok
 C: RCPT TO:<alice@example.com>
 S: 250 Ok
 C: RCPT TO:<theboss@example.com>
 S: 250 Ok
 C: DATA
 S: 354 End data with <CR><LF>.<CR><LF>
 C: 
 C: 
 C: 
 C: 
 C: 
 C:
 C: Hello Alice.
 C: This is a test message with 5 header fields and 4 lines in the message body.
 C: Your friend,
 C: Bob
 C: .
 S: 250 Ok: queued as 12345
 C: QUIT
 S: 221 Bye
 {The server closes the connection}

ক্লায়েন্ট MAIL FROM কমান্ডের মাধ্যমে প্রাপককে বার্তার মূল ইমেইল ঠিকানা সম্পর্কে অবহিত করে। বার্তাটি পৌঁছে দেওয়া সম্ভব না হলে এটি রিটার্ন বা বাউন্স অ্যাড্রেস হিসেবেও কাজ করে। এই উদাহরণে ইমেইল বার্তাটি একই এসএমটিপি সার্ভারে থাকা দুটি মেইলবক্সে পাঠানো হয়: To: এবং Cc: হেডার ফিল্ডে তালিকাভুক্ত প্রতিটি প্রাপকের জন্য একটি করে। সংশ্লিষ্ট এসএমটিপি কমান্ডটি হলো RCPT TO। প্রতিটি কমান্ড সফলভাবে গ্রহণ এবং কার্যকর করার পর সার্ভার একটি রেজাল্ট কোড এবং রেসপন্স মেসেজ (যেমন, 250 Ok) দিয়ে প্রাপ্তিস্বীকার করে।

মেইল বার্তার মূল অংশের বা বডির ট্রান্সমিশন একটি DATA কমান্ড দিয়ে শুরু হয়, যার পরে এটি হুবহু লাইন বাই লাইন পাঠানো হয় এবং একটি ডেটা-সমাপ্তির ক্রম বা এন্ড-অফ-ডেটা সিকোয়েন্স দিয়ে শেষ হয়। এই ক্রমটি একটি নতুন লাইন (<CR><LF>), একটি একক ফুল স্টপ (.), এবং তারপরে আরেকটি নতুন লাইন (<CR><LF>) নিয়ে গঠিত। যেহেতু একটি বার্তার বডিতে টেক্সটের অংশ হিসেবে শুধুমাত্র একটি পিরিয়ড বা ডটযুক্ত লাইন থাকতে পারে, তাই প্রতিবার কোনো লাইন পিরিয়ড দিয়ে শুরু হলে ক্লায়েন্ট দুটি পিরিয়ড পাঠায়; একইভাবে, সার্ভার লাইনের শুরুতে থাকা প্রতিটি দুটি পিরিয়ডের ক্রমকে একটি দিয়ে প্রতিস্থাপন করে। এস্কেপিং-এর এই পদ্ধতিটিকে ডট-স্টাফিং বলা হয়।

উদাহরণস্বরূপ, এন্ড-অফ-ডেটার প্রতি সার্ভারের ইতিবাচক উত্তর নির্দেশ করে যে সার্ভার বার্তাটি পৌঁছে দেওয়ার দায়িত্ব নিয়েছে। এই সময়ে যোগাযোগের ব্যর্থতা ঘটলে, যেমন বিদ্যুৎ বিভ্রাটের কারণে, একটি বার্তা দ্বিগুণ বা ডাবল হতে পারে: যতক্ষণ না প্রেরক সেই 250 Ok উত্তর পায়, ততক্ষণ এটিকে ধরে নিতে হবে যে বার্তাটি পৌঁছে দেওয়া হয়নি। অন্যদিকে, প্রাপক বার্তাটি গ্রহণ করার সিদ্ধান্ত নেওয়ার পর, তাকে অবশ্যই ধরে নিতে হবে যে বার্তাটি তার কাছে পৌঁছে দেওয়া হয়েছে। সুতরাং, এই সময়ের ব্যবধানে, উভয় এজেন্টের কাছেই বার্তার সক্রিয় কপি থাকে যা তারা পৌঁছে দেওয়ার চেষ্টা করবে। ঠিক এই ধাপে যোগাযোগের ব্যর্থতা ঘটার সম্ভাবনা সার্ভার বার্তার বডিতে যে পরিমাণ ফিল্টারিং করে তার সাথে সরাসরি সমানুপাতিক, যা প্রায়শই স্প্যাম-বিরোধী উদ্দেশ্যে করা হয়। সীমাবদ্ধকারী টাইমআউট ১০ মিনিট নির্ধারণ করা হয়েছে।

QUIT কমান্ড সেশনটি শেষ করে। যদি ইমেইলটির অন্য কোথাও অবস্থিত অন্যান্য প্রাপক থাকে, তবে বর্তমান গন্তব্য(গুলো) কিউ বা সারিবদ্ধ হওয়ার পরে ক্লায়েন্ট QUIT করবে এবং পরবর্তী প্রাপকদের জন্য উপযুক্ত এসএমটিপি সার্ভারের সাথে সংযুক্ত হবে। ক্লায়েন্ট HELO এবং MAIL FROM কমান্ডে যে তথ্য পাঠায় তা গ্রহণকারী সার্ভার বার্তার অতিরিক্ত হেডার ফিল্ড হিসেবে যোগ করে (উদাহরণ কোডে দেখা যাচ্ছে না)। এটি যথাক্রমে একটি Received এবং Return-Path হেডার ফিল্ড যোগ করে।

কিছু ক্লায়েন্ট বার্তা গৃহীত হওয়ার পরে (250 Ok: queued as 12345) সংযোগ বন্ধ করার জন্য তৈরি করা হয়েছে, তাই শেষ দুটি লাইন আসলে বাদ দেওয়া হতে পারে। এটি সার্ভারে ত্রুটি সৃষ্টি করে যখন এটি 221 Bye উত্তর পাঠানোর চেষ্টা করে।

 এসএমটিপি এক্সটেনশন 
 এক্সটেনশন ডিসকভারি মেকানিজম 
ক্লায়েন্টরা মূল `HELO`-এর পরিবর্তে `EHLO` গ্রিটিং বা সম্ভাষণ ব্যবহার করে সার্ভারের সমর্থিত অপশনগুলো জানতে পারে, যার উদাহরণ নিচে দেওয়া হলো। ক্লায়েন্টরা শুধুমাত্র তখনই `HELO`-তে ফিরে যায় যদি সার্ভার `EHLO` গ্রিটিং সমর্থন না করে। 

আধুনিক ক্লায়েন্টরা সার্ভার সর্বোচ্চ কত আকারের মেসেজ গ্রহণ করবে তা জিজ্ঞাসা করার জন্য ইএসএমটিপি এক্সটেনশন কিওয়ার্ড `SIZE` ব্যবহার করতে পারে। পুরনো ক্লায়েন্ট এবং সার্ভারগুলো অত্যধিক বড় আকারের মেসেজ স্থানান্তর করার চেষ্টা করতে পারে যা নেটওয়ার্ক রিসোর্স (নেটওয়ার্ক লিংকের সংযোগ সময়সহ, যার জন্য প্রতি মিনিটে অর্থ প্রদান করতে হয়) খরচ করার পর প্রত্যাখ্যান করা হবে।

ব্যবহারকারীরা ম্যানুয়ালি বা আগে থেকেই নির্ধারণ করতে পারেন যে ইএসএমটিপি সার্ভারগুলো সর্বোচ্চ কত আকার গ্রহণ করে। ক্লায়েন্ট `HELO` কমান্ডটিকে `EHLO` কমান্ড দিয়ে প্রতিস্থাপন করে।
 S: 220 smtp2.example.com ESMTP Postfix
 C: EHLO bob.example.org
 S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
 S: 250-SIZE 14680064
 S: 250-PIPELINING
 S: 250 HELP
এভাবে smtp2.example.com ঘোষণা করে যে এটি ১৪,৬৮০,০৬৪ অক্টেট (৮-বিট বাইট)-এর চেয়ে বড় কোনো মেসেজ গ্রহণ করতে পারে না।

সবচেয়ে সহজ ক্ষেত্রে, একটি ইএসএমটিপি সার্ভার `EHLO` পাওয়ার পরপরই সর্বোচ্চ `SIZE` ঘোষণা করে। তবে, অনুযায়ী, `EHLO` উত্তরে `SIZE` এক্সটেনশনের নিউমেরিক বা সংখ্যাসূচক প্যারামিটারটি ঐচ্ছিক। এর পরিবর্তে ক্লায়েন্টরা যখন `MAIL FROM` কমান্ড ইস্যু করে, তখন তারা যে মেসেজটি স্থানান্তর করছে তার আকারের একটি সংখ্যাসূচক অনুমান অন্তর্ভুক্ত করতে পারে, যাতে সার্ভার অত্যধিক বড় মেসেজ গ্রহণ করতে অস্বীকার করতে পারে।

 বাইনারি ডেটা স্থানান্তর 
মূল এসএমটিপি শুধুমাত্র একটি টেক্সট বডি সমর্থন করে, তাই যেকোনো বাইনারি ডেটা স্থানান্তরের আগে মেসেজের বডিতে টেক্সট হিসেবে এনকোড করতে হয় এবং পরে প্রাপককে তা ডিকোড করতে হয়। সাধারণত বাইনারি-টু-টেক্সট এনকোডিং, যেমন ইউইউএনকোড এবং বিনহেক্স ব্যবহৃত হতো। 

এটি সমাধানের জন্য 8BITMIME কমান্ডটি তৈরি করা হয়েছিল। এটি ১৯৯৪ সালে হিসেবে মানক করা হয়েছিল।যা ২০১১ সালে বাতিল হয়ে দ্বারা প্রতিস্থাপিত হয়, যা তৎকালীন নতুন STD 71-এর অনুরূপ এটি সাত-বিট আসকি ক্যারেক্টার সেটের বাইরের অক্টেটযুক্ত ই-মেইল বার্তাগুলোকে মাইম কন্টেন্ট পার্ট হিসেবে এনকোড করে (সাধারণত বেস৬৪ দিয়ে এনকোড করা হয়) স্বচ্ছভাবে বিনিময়ের সুবিধা দেয়।

 অন-ডিমান্ড মেইল রিলে 

অন-ডিমান্ড মেইল রিলে (ODMR) হলো একটি এসএমটিপি এক্সটেনশন যা-এ মানক করা হয়েছে। এটি মাঝে মাঝে সংযুক্ত (intermittently-connected) থাকে এমন এসএমটিপি সার্ভারকে সংযোগ থাকা অবস্থায় তার জন্য জমা (queued) থাকা ইমেইল গ্রহণ করার অনুমতি দেয়।

 আন্তর্জাতিকীকরণ এক্সটেনশন 

মূল এসএমটিপি শুধুমাত্র আসকি অক্ষর দ্বারা গঠিত ইমেইল ঠিকানা সমর্থন করে, যা সেইসব ব্যবহারকারীদের জন্য অসুবিধাজনক যাদের মাতৃভাষা ল্যাটিন ভিত্তিক নয়, অথবা যারা এমন ডায়াক্রিটিক ব্যবহার করেন যা আসকি ক্যারেক্টার সেটে নেই। ঠিকানার নামে UTF-8 সক্ষম করার এক্সটেনশনের মাধ্যমে এই সীমাবদ্ধতা দূর করা হয়েছে। পরীক্ষামূলক `UTF8SMTP` কমান্ড চালু করেছিল এবং পরে এটি দ্বারা বাতিল ও প্রতিস্থাপিত হয়, যা `SMTPUTF8` কমান্ড চালু করে। এই এক্সটেনশনগুলো ইমেইল ঠিকানায় মাল্টি-বাইট এবং নন-আসকি অক্ষর সমর্থন করে, যেমন ডায়াক্রিটিক এবং অন্যান্য ভাষার অক্ষর যেমন গ্রিক এবং চীনা।

বর্তমান সমর্থন সীমিত, তবে চিনের মতো দেশগুলোতে এবং সম্পর্কিত আরএফসিগুলোর ব্যাপক গ্রহণের প্রতি প্রবল আগ্রহ রয়েছে, কারণ সেখানে ল্যাটিন (আসকি) একটি বিদেশি লিপি এবং ব্যবহারকারীর সংখ্যা বিশাল।

 এক্সটেনশনসমূহ 
এসএমটিপি-এর মতো, ইএসএমটিপি-ও ইন্টারনেট মেইল পরিবহনের জন্য ব্যবহৃত একটি প্রোটোকল। এটি আন্তঃ-সার্ভার ট্রান্সপোর্ট প্রোটোকল এবং (সীমাবদ্ধ আচরণ বলবৎসহ) মেইল সাবমিশন প্রোটোকল উভয় হিসেবেই ব্যবহৃত হয়।

ইএসএমটিপি ক্লায়েন্টদের প্রধান শনাক্তকারী বৈশিষ্ট্য হলো `HELO` (হ্যালো, মূল স্ট্যান্ডার্ড)-এর পরিবর্তে `EHLO` (এক্সটেনডেড হ্যালো) কমান্ড দিয়ে ট্রান্সমিশন বা সংযোগ শুরু করা। একটি সার্ভার তার কনফিগারেশনের ওপর ভিত্তি করে সাফল্য (কোড ২৫০), ব্যর্থতা (কোড ৫৫০) বা ত্রুটি (কোড ৫০০, ৫০১, ৫০২, ৫০৪, বা ৪২১) দিয়ে উত্তর দেবে। একটি ইএসএমটিপি সার্ভার কোড ২৫০ ওকে (OK)-সহ একটি মাল্টি-লাইন উত্তর দেয়, যাতে তার ডোমেইন এবং সমর্থিত এক্সটেনশনগুলো নির্দেশক কিওয়ার্ডের তালিকা থাকে। একটি RFC 821 অনুগত সার্ভার ত্রুটি কোড ৫০০ ফেরত দেয়, যা ইএসএমটিপি ক্লায়েন্টদের `HELO` বা `QUIT` চেষ্টা করার অনুমতি দেয়।

প্রতিটি সার্ভিস এক্সটেনশন পরবর্তী আরএফসিগুলোতে একটি অনুমোদিত বিন্যাসে সংজ্ঞায়িত এবং ইন্টারনেট অ্যাসাইন্ড নাম্বারস অথরিটি (IANA)-তে নিবন্ধিত। প্রথম সংজ্ঞাগুলো ছিল RFC 821-এর ঐচ্ছিক পরিষেবা: `SEND`, `SOML` (Send or Mail), `SAML` (Send and Mail), `EXPN`, `HELP`, এবং `TURN`। অতিরিক্ত এসএমটিপি ভার্ব (verbs)-এর বিন্যাস এবং `MAIL` ও `RCPT`-এ নতুন প্যারামিটারের জন্য বিন্যাস নির্ধারণ করা হয়েছিল।

আজকাল ব্যবহৃত কিছু সাধারণ কিওয়ার্ড (সবগুলোই কমান্ডের সাথে মিলে না) হলো:
 `8BITMIME` – ৮ বিট ডেটা ট্রান্সমিশন, 
 `ATRN` – অন-ডিমান্ড মেইল রিলে-র জন্য অথেনটিকেটেড `TURN`,
 `AUTH` – অথেনটিকেটেড এসএমটিপি,
 `CHUNKING` – চাঙ্কিং,
 `DSN` – ডেলিভারি স্ট্যাটাস নোটিফিকেশন, (দেখুন Variable envelope return path)
 `ETRN` – রিমোট মেসেজ কিউ স্টার্টিং কমান্ড `TURN`-এর বর্ধিত সংস্করণ, 
 `HELP` – সহায়ক তথ্য প্রদান, 
 `PIPELINING` – কমান্ড পাইপলাইনিং,
 `SIZE` – মেসেজ সাইজ ডিক্লারেশন বা ঘোষণা,
 `STARTTLS` – ট্রান্সপোর্ট লেয়ার সিকিউরিটি, (২০০২)
 `SMTPUTF8` – মেইলবক্সের নাম এবং হেডার ফিল্ডে UTF-8 এনকোডিং অনুমোদন,
 `UTF8SMTP` – মেইলবক্সের নাম এবং হেডার ফিল্ডে UTF-8 এনকোডিং অনুমোদন, (বাতিল)

ESMTP বিন্যাসটি-এ পুনঃবিবৃত হয়েছে (যা RFC 821-কে বাতিল করেছে) এবং ২০০৮ সালে -এ সর্বশেষ সংজ্ঞায় আপডেট করা হয়েছে। সার্ভারগুলোতে `EHLO` কমান্ডের সমর্থন বাধ্যতামূলক করা হয়েছে এবং `HELO`-কে একটি প্রয়োজনীয় ফলব্যাক হিসেবে রাখা হয়েছে।

অ-মানক, অনিবন্ধিত সার্ভিস এক্সটেনশনগুলো দ্বিপাক্ষিক চুক্তির মাধ্যমে ব্যবহার করা যেতে পারে; এই পরিষেবাগুলো "X" দিয়ে শুরু হওয়া `EHLO` মেসেজ কিওয়ার্ড এবং একইভাবে চিহ্নিত অতিরিক্ত প্যারামিটার বা ভার্ব দ্বারা নির্দেশিত হয়।

এসএমটিপি কমান্ডগুলো কেস-ইনসেনসিটিভ। এখানে শুধুমাত্র জোর দেওয়ার জন্য এগুলোকে ক্যাপিটাল লেটারে দেখানো হয়েছে। যে এসএমটিপি সার্ভার নির্দিষ্ট ক্যাপিটালাইজেশন পদ্ধতি দাবি করে তা স্ট্যান্ডার্ডের লঙ্ঘন।

8BITMIME
অন্তত নিচের সার্ভারগুলো 8BITMIME এক্সটেনশন ঘোষণা করে:
 Apache James (২.৩.০a১ থেকে)James Server - ChangeLog . James.apache.org. Retrieved on 2013-07-17.
 সিটাডেল (৭.৩০ থেকে)
 কুরিয়ার মেইল ​​সার্ভার
 জিমেইল২৩ নভেম্বর ২০১১-এ চেক করা হয়েছে, gmail-smtp-in.l.google.com পোর্ট ২৫-এ EHLO-র উত্তরে 8BITMIME পরিষেবা বিজ্ঞাপিত হয়েছে
 আইসওয়ার্প
 আইআইএস এসএমটিপি সার্ভিস
 কেরিও কানেক্ট
 লোটাস ডমিনো
 মাইক্রোসফট এক্সচেঞ্জ সার্ভার (এক্সচেঞ্জ সার্ভার ২০০০ থেকে)
 নোভেল গ্রুপওয়াইস
 ওপেনএসএমটিপিডি
 ওরাকল কমিউনিকেশনস মেসেজিং সার্ভার
 পোস্টফিক্স
 সেন্ডমেইল (৬.৫৭ থেকে)
 জেডমেইলার (২.৯৫ ৯৪০৯০১ থেকে)

নিম্নলিখিত সার্ভারগুলো 8BITMIME বিজ্ঞাপন করার জন্য কনফিগার করা যেতে পারে, কিন্তু নন-8BITMIME রিলেগুলোতে সংযোগ করার সময় ৮-বিট ডেটা ৭-বিটে রূপান্তর করে না:
 এক্সিম এবং কিউমেইল ৮-বিট মেসেজ ৭-বিটে অনুবাদ করে না যখন নন-8BITMIME পিয়ারদের কাছে ৮-বিট ডেটা রিলে করার চেষ্টা করে, যা আরএফসি দ্বারা প্রয়োজনীয়।Qmail bugs and wishlist. Home.pages.de. Retrieved on 2013-07-17. এটি বাস্তবে সমস্যা সৃষ্টি করে না, কারণ কার্যত সমস্ত আধুনিক মেইল রিলে 8-bit clean।The 8BITMIME extension . Cr.yp.to. Retrieved on 2013-07-17.
 মাইক্রোসফট এক্সচেঞ্জ সার্ভার ২০০৩ ডিফল্টভাবে 8BITMIME বিজ্ঞাপন করে, কিন্তু একটি নন-8BITMIME পিয়ারে রিলে করলে বাউন্স হয়। এটি দ্বারা অনুমোদিত।

এসএমটিপি-প্রমাণীকরণ

এসএমটিপি-প্রমাণীকরণ এক্সটেনশন একটি অ্যাক্সেস নিয়ন্ত্রণ ব্যবস্থা প্রদান করে। এটি একটি অথেন্টিকেশন বা প্রমাণীকরণ ধাপ নিয়ে গঠিত যার মাধ্যমে ক্লায়েন্ট মেইল পাঠানোর প্রক্রিয়া চলাকালীন কার্যকরভাবে মেইল সার্ভারে লগ ইন করে। যে সার্ভারগুলো এসএমটিপি-প্রমাণীকরণ সমর্থন করে সেগুলোকে সাধারণত কনফিগার করা যায় যাতে ক্লায়েন্টদের এই এক্সটেনশন ব্যবহার করা বাধ্যতামূলক হয়, এবং এর ফলে প্রেরকের প্রকৃত পরিচয় নিশ্চিত করা যায়। এসএমটিপি-প্রমাণীকরণ এক্সটেনশনটি-এ সংজ্ঞায়িত করা হয়েছে। 

এসএমটিপি-প্রমাণীকরণ ব্যবহার করে বৈধ ব্যবহারকারীদের মেইল রিলে করার অনুমতি দেওয়া যায় এবং একই সাথে অননুমোদিত ব্যবহারকারীদের, যেমন স্প্যামারদের, রিলে পরিষেবা অস্বীকার করা যায়। এটি এসএমটিপি এনভেলপ সেন্ডার বা "From:" হেডারের সত্যতা নিশ্চিত করে না। উদাহরণস্বরূপ, স্পুফিং, যেখানে একজন প্রেরক অন্য কেউ সেজে মেসেজ পাঠায়, তা এসএমটিপি-প্রমাণীকরণ-এর পরেও সম্ভব, যদি না সার্ভারটি এমনভাবে কনফিগার করা থাকে যা মেসেজের 'From' অ্যাড্রেসগুলোকে শুধুমাত্র সেই অ্যাড্রেসগুলোর মধ্যে সীমাবদ্ধ রাখে যা ব্যবহারের জন্য ওই AUTHed ব্যবহারকারী অনুমোদিত।

এসএমটিপি-প্রমাণীকরণ এক্সটেনশন একটি মেইল সার্ভারকে অন্য মেইল সার্ভারের কাছে নির্দেশ করতে দেয় যে রিলে করার সময় প্রেরক প্রমাণীকৃত হয়েছে। সাধারণভাবে এর জন্য প্রাপক সার্ভারকে প্রেরক সার্ভারকে বিশ্বাস করতে হয়, যার মানে হলো ইন্টারনেটে SMTP-AUTH-এর এই দিকটি খুব কমই ব্যবহৃত হয়।

SMTPUTF8
সমর্থনকারী সার্ভারগুলোর মধ্যে রয়েছে:
 পোস্টফিক্স (সংস্করণ ৩.০ এবং পরবর্তী)"Postfix SMTPUTF8 support is enabled by default" , February 8, 2015, postfix.org
 মোমেনটাম (সংস্করণ ৪.১ এবং ৩.৬.৫, ও পরবর্তী)
 সেন্ডমেইল (৮.১৭.১-এ পরীক্ষামূলক সমর্থন)
 এক্সিম (৪.৮৬ রিলিজ থেকে পরীক্ষামূলক, ৪.৯৬-এ বেশ পরিপক্ব)
 কমিউনিগেট প্রো সংস্করণ ৬.২.২ থেকে
 কুরিয়ার-এমটিএ সংস্করণ ১.০ থেকে
 Halon সংস্করণ ৪.০ থেকে নতুন সংস্করণের জন্য আপডেট করা হয়েছে
 মাইক্রোসফট এক্সচেঞ্জ সার্ভার প্রোটোকল রিভিশন ১৪.০ থেকে
 Haraka এবং অন্যান্য সার্ভার।
 ওরাকল কমিউনিকেশনস মেসেজিং সার্ভার রিলিজ ৮.০.২ থেকে।

 নিরাপত্তা এক্সটেনশন 
মেইল প্লেইন টেক্সট এবং এনক্রিপ্টেড উভয় সংযোগের মাধ্যমে বিতরণ করা যেতে পারে, তবে যোগাযোগকারী পক্ষগুলো আগে থেকে অন্য পক্ষের সুরক্ষিত চ্যানেল ব্যবহার করার ক্ষমতা সম্পর্কে নাও জানতে পারে।

 STARTTLS বা "সুবিধাবাদী টিএলএস" 

STARTTLS এক্সটেনশন সমর্থিত এসএমটিপি সার্ভারগুলোকে সংযোগকারী ক্লায়েন্টদের জানাতে সক্ষম করে যে এটি টিএলএস (টিএলএস) এনক্রিপ্টেড যোগাযোগ সমর্থন করে এবং ক্লায়েন্টদের STARTTLS কমান্ড পাঠানোর মাধ্যমে তাদের সংযোগ আপগ্রেড করার সুযোগ দেয়। সার্ভারগুলো শুধুমাত্র এই এক্সটেনশন বাস্তবায়নের মাধ্যমে কোনো নিরাপত্তা সুবিধা পায় না, কারণ টিএলএস এনক্রিপ্টেড সেশনে আপগ্রেড করা নির্ভর করে সংযোগকারী ক্লায়েন্টের এই অপশনটি ব্যবহার করার সিদ্ধান্তের ওপর, তাই একে 'সুবিধাবাদী' (opportunistic) টিএলএস বলা হয়। 

STARTTLS শুধুমাত্র প্যাসিভ পর্যবেক্ষণ আক্রমণের বিরুদ্ধে কার্যকর, কারণ STARTTLS নেগোসিয়েশন বা আলোচনা প্লেইন টেক্সটে ঘটে এবং একজন সক্রিয় আক্রমণকারী সহজেই STARTTLS কমান্ডগুলো সরিয়ে ফেলতে পারে। এই ধরনের ম্যান-ইন-দ্য-মিডল আক্রমণ-কে কখনও কখনও STRIPTLS বলা হয়, যেখানে এক প্রান্ত থেকে পাঠানো এনক্রিপশন নেগোসিয়েশন তথ্য অন্য প্রান্তে পৌঁছায় না। এই পরিস্থিতিতে উভয় পক্ষ অবৈধ বা অপ্রত্যাশিত প্রতিক্রিয়াগুলোকে ইঙ্গিত হিসেবে ধরে নেয় যে অন্য পক্ষ STARTTLS সঠিকভাবে সমর্থন করে না, এবং তারা প্রথাগত প্লেইন-টেক্সট মেইল ট্রান্সফারে ফিরে যায়। উল্লেখ্য যে STARTTLS অন্যান্য আরএফসি-তে আইএমএপি এবং পপ৩-এর জন্যও সংজ্ঞায়িত করা হয়েছে, তবে এই প্রোটোকলগুলো ভিন্ন উদ্দেশ্যে কাজ করে: এসএমটিপি মেসেজ ট্রান্সফার এজেন্টদের মধ্যে যোগাযোগের জন্য ব্যবহৃত হয়, যেখানে আইএমএপি এবং পপ৩ শেষ ক্লায়েন্ট এবং মেসেজ ট্রান্সফার এজেন্টদের জন্য।

২০১৪ সালে ইলেকট্রনিক ফ্রন্টিয়ার ফাউন্ডেশন "STARTTLS Everywhere" প্রকল্প শুরু করে যা "এইচটিটিপিএস সবখানে" তালিকার মতোই, রিলাইং পার্টিদের পূর্ব যোগাযোগ ছাড়াই অন্যদের সুরক্ষিত যোগাযোগ সমর্থন সম্পর্কে জানতে দেয়। প্রকল্পটি ২৯ এপ্রিল ২০২১-এ সাবমিশন গ্রহণ বন্ধ করে দেয় এবং ইএফএফ পিয়ারদের টিএলএস সমর্থন সম্পর্কে তথ্য জানার জন্য ডিএএনই এবং এমটিএ-এসটিএস-এ স্যুইচ করার সুপারিশ করে।

আনুষ্ঠানিকভাবে প্লেইন টেক্সটকে অপ্রচলিত ঘোষণা করে এবং মেইল সাবমিশন ও অ্যাক্সেসের জন্য সর্বদা টিএলএস ব্যবহারের সুপারিশ করে, সাথে ইমপ্লিসিট টিএলএস-সহ পোর্ট যুক্ত করে।

 এসএমটিপি-এর জন্য ডিএএনই  ডিএনএস রেকর্ডের মাধ্যমে মেইল সার্ভারের এনক্রিপশন ক্ষমতা ঘোষণা করার প্রবর্তন করে। ডিএনএসএসইসি ব্যবহার করে, মেইল সার্ভার অপারেটররা তাদের টিএলএস সার্টিফিকেটের একটি হ্যাশ প্রকাশ করতে পারে, যা আন-এনক্রিপ্টেড যোগাযোগের সম্ভাবনা হ্রাস করে।

মাইক্রোসফট ২০২৪ সালের শেষের দিকে এক্সচেঞ্জ অনলাইন গ্রাহকদের জন্য সম্পূর্ণ এসএমটিপি ডিএএনই সমর্থন চালু করার আশা করছে।

 এসএমটিপি এমটিএ স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি 
২০১৮ সালের একটি নতুন যার নাম "এসএমটিপি এমটিএ স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি (এমটিএ-এসটিএস)", সক্রিয় প্রতিপক্ষের সমস্যা সমাধানের লক্ষ্যে কাজ করে। এটি মেইল সার্ভারগুলোর জন্য সার্ভারের নির্দিষ্ট ফাইল এবং নির্দিষ্ট ডিএনএস টিএক্সটি রেকর্ডে সুরক্ষিত চ্যানেল ব্যবহার করার ক্ষমতা ঘোষণা করার একটি প্রোটোকল সংজ্ঞায়িত করে। রিলাইং পার্টি নিয়মিতভাবে এমন রেকর্ডের অস্তিত্ব পরীক্ষা করে এবং রেকর্ডে নির্দিষ্ট করা সময়ের জন্য এটি ক্যাশ করে রাখে এবং রেকর্ড মেয়াদোত্তীর্ণ না হওয়া পর্যন্ত অনিরাপদ চ্যানেলে যোগাযোগ করে না। 

উল্লেখ্য যে এমটিএ-এসটিএস রেকর্ডগুলো শুধুমাত্র মেইল সার্ভারগুলোর মধ্যে এসএমটিপি ট্রাফিকের ক্ষেত্রে প্রযোজ্য, যখন ব্যবহারকারীর ক্লায়েন্ট এবং মেইল সার্ভারের মধ্যে যোগাযোগ একটি সাংগঠনিক বা প্রযুক্তিগত নীতির সাথে মিলিয়ে এসএমটিপি/এমএসএ, আইএমএপি, পপ৩ বা এইচটিটিপিএস-এর সাথে টিএলএস দ্বারা সুরক্ষিত থাকে। মূলত, এমটিএ-এসটিএস হলো তৃতীয় পক্ষের কাছে এই জাতীয় নীতি প্রসারিত করার একটি উপায়।

২০১৯ সালের এপ্রিলে জিমেইল এমটিএ-এসটিএস-এর সমর্থন ঘোষণা করে।

 এসএমটিপি টিএলএস রিপোর্টিং 
নিরাপদে বার্তা পৌঁছে দেওয়ার জন্য ডিজাইন করা প্রোটোকলগুলো ভুল কনফিগারেশন বা ইচ্ছাকৃত সক্রিয় হস্তক্ষেপের কারণে ব্যর্থ হতে পারে, যার ফলে মেসেজ ডেলিভারি না হওয়া বা আন-এনক্রিপ্টেড বা আন-অথেনটিকেটেড চ্যানেলে ডেলিভারি হতে পারে। "এসএমটিপি টিএলএস রিপোর্টিং" প্রাপক ডোমেইনগুলোর সাথে সম্ভাব্য ব্যর্থতা সম্পর্কে পরিসংখ্যান এবং নির্দিষ্ট তথ্য শেয়ার করার জন্য একটি রিপোর্টিং মেকানিজম এবং ফরম্যাট বর্ণনা করে। প্রাপক ডোমেইনগুলো তখন এই তথ্য ব্যবহার করে সম্ভাব্য আক্রমণ শনাক্ত করতে এবং অনিচ্ছাকৃত ভুল কনফিগারেশন নির্ণয় করতে পারে।

২০১৯ সালের এপ্রিলে জিমেইল এসএমটিপি টিএলএস রিপোর্টিং-এর সমর্থন ঘোষণা করে।

 স্পুফিং এবং স্প্যামিং 

এসএমটিপি-এর আদি ডিজাইনে প্রেরককে যাচাই করার এসএমটিপি কোনো সার্ভার তাদের পক্ষে ইমেল পাঠানোর অনুমতিপ্রাপ্ত কি না তা পরীক্ষা করার কোনো ব্যবস্থা ছিল না। এর ফলে ইমেল স্পুফিং করা সম্ভব হয়, যা বর্তমানে ইমেল স্প্যাম এবং ফিশিং-এর ক্ষেত্রে ব্যাপকভাবে ব্যবহৃত হয়।

এসএমটিপি-কে ব্যাপকভাবে পরিবর্তন করার অথবা এটি সম্পূর্ণ প্রতিস্থাপন করার জন্য মাঝেমধ্যে বিভিন্ন প্রস্তাব দেওয়া হয়। এর একটি উদাহরণ হলো ইন্টারনেট মেইল ২০০০, কিন্তু প্রচলিত এসএমটিপি-এর বিশাল নেটওয়ার্ক ইফেক্ট এবং বিশাল ব্যবহারকারী ভিত্তির কারণে এটি বা অন্য কোনো প্রস্তাবই খুব একটা সুবিধা করতে পারেনি।

এর পরিবর্তে, মেইল সার্ভারগুলো এখন বিভিন্ন প্রযুক্তি ব্যবহার করে, যেমন— RFC 5322-এর মতো স্ট্যান্ডার্ডগুলোর কঠোর প্রয়োগ, ডোমেইন কি শনাক্ত করা মেইল (ডিকেআইএম), প্রেরক নীতি ফ্রেমওয়ার্ক (এসপিএফ), ডিএমএআরডি, ডিএনএসবিএল এবং গ্রেলিস্টিং। সন্দেহজনক ইমেলগুলো প্রত্যাখ্যান বা কোয়ারেন্টাইন করতে এই পদ্ধতিগুলো ব্যবহৃত হয়।

 বাস্তবায়ন 

 এখানে নির্দিষ্ট সফটওয়্যার বা সিস্টেমের বাস্তবায়নের বিবরণ যোগ করা যেতে পারে।

আরও দেখুন
 ই-মেইল
 জিমেইল
 এসএমটিপি, ইনক.
 ই-মেইলের ইতিহাস

নোট

তথ্যসূত্র








 বহিঃসংযোগ 




Category:ইন্টারনেট মেইল প্রোটোকল