SMTP एक वार्तालाप है, एक भी भेजें बटन नहीं। एक क्लाइंट एक कनेक्शन खोलता है, खुद की पहचान करता है, एक लिफाफा प्रदान करता है, संदेश सामग्री स्थानांतरित करता है और सर्वर की प्रतिक्रियाओं को पढ़ता है। प्रत्येक प्रतिक्रिया एक विशिष्ट कमांड और सर्वर से संबंधित होती है। उस अनुक्रम को समझने से यह समझाना संभव हो जाता है कि एक प्राप्तकर्ता विफल क्यों हुआ जबकि दूसरे को स्वीकार कर लिया गया और क्यों प्रारंभिक सफलता अंतिम डिलीवरी साबित नहीं होती है।
संपर्क और अभिवादन से शुरुआत करें
सर्वर एक ग्रीटिंग भेजता है, आमतौर पर 220 से शुरू होता है। क्लाइंट उपयोग करता है EHLO स्वयं की पहचान करना और विस्तार संबंधी जानकारी का अनुरोध करना; HELO पुराना बुनियादी अभिवादन प्रपत्र प्रदान करता है। एक मल्टीलाइन EHLO उत्तर अपनी अंतिम पंक्ति से पहले निरंतरता लाइनों का उपयोग करता है। एक सफल के बाद STARTTLS हैंडशेक, RFC 3207 के लिए दोनों पक्षों को TLS से पहले सीखे गए SMTP ज्ञान को त्यागने की आवश्यकता है; संरक्षित सत्र की क्षमताओं की खोज के लिए क्लाइंट को पहले EHLO भेजना चाहिए। पिछली एक्सटेंशन सूची का पुन: उपयोग न करें.
प्रोटोकॉल अनुक्रम और उत्तर नियमों को परिभाषित किया गया है RFC 5321. प्रमाणीकरण, TLS और सबमिशन नीति अतिरिक्त चिंताएं हैं, न कि इस बात का सबूत कि दृश्यमान प्रेषक पता स्वचालित रूप से अधिकृत है। पासवर्ड या पुन: प्रयोज्य प्रमाणीकरण टोकन बनाए रखे बिना सहकर्मी, समय और बातचीत की गई सुविधाओं को लॉग करें।
लिफाफा अलग रखें
मेल प्रेषक परिवहन प्रबंधन और विफलताओं के लिए उपयोग किए जाने वाले रिवर्स पथ की आपूर्ति करता है। आरसीपीटी टीओ वर्तमान लेनदेन के लिए एक प्राप्तकर्ता की आपूर्ति करता है। संदेश के अंदर प्रेषक या प्रति शीर्षक में से कोई भी आदेश दृश्यमान नहीं है। एक लेनदेन में कई आरसीपीटी कमांड हो सकते हैं, और सर्वर कुछ को स्वीकार कर सकता है जबकि अन्य को अस्वीकार कर सकता है।
इस सिंथेटिक अनुक्रम पर विचार करें, कैप्चर किए गए विनिमय पर नहीं। MAIL FROM को 250 प्राप्त होते हैं। missing@receiver.test के लिए RCPT TO को 550 5.1.1 प्राप्त होते हैं, जबकि accepted@receiver.test के लिए RCPT TO को 250 प्राप्त होते हैं। स्वीकृत प्राप्तकर्ता बाद के डेटा ट्रांसफर के लिए पात्र रह सकता है; अस्वीकृत प्राप्तकर्ता को उस सर्वर द्वारा स्वीकार नहीं किया गया है। ये काल्पनिक पते और उत्तर किसी सार्वजनिक सेवा का वर्णन नहीं करते हैं।
संदेश स्थानांतरित करें और अंतिम प्रतिक्रिया पढ़ें
कम से कम एक प्राप्तकर्ता के स्वीकार किए जाने के बाद, डेटा सामग्री स्थानांतरण का अनुरोध करता है। 354 प्रतिक्रिया क्लाइंट को हेडर और बॉडी भेजने के लिए आमंत्रित करती है, जो आवश्यक डॉट लाइन के साथ समाप्त होती है। डॉट पारदर्शिता एक डॉट से शुरू होने वाली सामग्री लाइन को गलती से टर्मिनेटर समझने से रोकती है। उदाहरण के लिए, .example से शुरू होने वाली सामग्री पंक्ति को ..example के रूप में एक अतिरिक्त अग्रणी बिंदु के साथ प्रसारित किया जाता है; प्राप्त करने वाली SMTP परत उस जोड़े गए बिंदु को हटा देती है। केवल अंतिम बिंदु वाली रेखा की एक अलग भूमिका होती है।
निर्णायक संदेश-स्वीकृति प्रतिक्रिया सामग्री के बाद आती है, 354 पर नहीं। सिंथेटिक अनुक्रम में, मान लीजिए कि सर्वर समाप्ति बिंदु के बाद सर्वर-स्थानीय कतार पहचानकर्ता के साथ 250 लौटाता है। एक वास्तविक स्वीकार्य SMTP सर्वर RFC 5321 द्वारा वर्णित जिम्मेदारी लेता है, लेकिन स्वीकृति अभी भी इनबॉक्स प्लेसमेंट, रीडिंग या बाद के डाउनस्ट्रीम हॉप में सफलता की गारंटी नहीं है। यदि अंतिम उत्तर से पहले कनेक्शन गायब हो जाता है, तो ग्राहक को पता नहीं चलेगा कि स्वीकृति हुई या नहीं; पुन: प्रयास की जांच करते समय संभावित डुप्लिकेट डिलीवरी का ध्यान रखें।
संदर्भ में विफलताओं की व्याख्या करें
4xx उत्तर एक क्षणिक नकारात्मक पूर्णता है; 5xx उत्तर अनुरोध के लिए एक स्थायी नकारात्मक समापन है। पूर्ण उत्तर और किसी भी उन्नत कोड को सुरक्षित रखें, क्योंकि केवल 550 की पहचान नहीं होती है DMARC कारण के रूप में. पुनः प्रयास का व्यवहार कतार नीति और संदेश की उपयोगिता पर भी निर्भर करता है। किसी अमान्य प्राप्तकर्ता को अनिश्चित काल तक दोहराने से उसकी मरम्मत नहीं होती है।
यदि AUTH असमर्थित या अस्वीकृत है, तो उसे एक अलग कमांड परिणाम के रूप में रिकॉर्ड करें। यह स्वयं प्राप्तकर्ता की वैधता, अंतिम डेटा स्वीकृति या डाउनस्ट्रीम डोमेन-प्रमाणीकरण परिणाम का वर्णन नहीं करता है। वास्तविक जांच के लिए, प्रतिलेख को प्रेषक कतार लॉग, प्राप्तकर्ता ट्रेस और लागू नीति के साथ सहसंबंधित करें, और किसी भी चरण को लेबल करें जिसके लिए सबूत गायब है। इस गाइड के उदाहरण काल्पनिक हैं; उनके लिए कोई लॉगिन, सॉकेट एक्सचेंज या मेल डिलीवरी नहीं की गई।
एक आदेश और परिणाम बही बनाएँ
- कनेक्शन: वास्तविक सहकर्मी, समय और अभिवादन रिकॉर्ड करें।
- क्षमताएं: किसी भी TLS वार्ता से पहले और बाद में EHLO परिणामों को अलग से सहेजें।
- लिफाफा: मेल FROM और प्रत्येक RCPT परिणाम को अलग से रखें।
- सामग्री: समाप्ति बिंदु के बाद 354 आमंत्रण को अंतिम उत्तर से अलग करें।
- अनिश्चितता: यदि अंतिम उत्तर गायब है, तो स्वीकृति अज्ञात चिह्नित करें और विफलता का दावा करने से पहले रिसीवर/कतार साक्ष्य का निरीक्षण करें।
- समापन: क्रेडेंशियल लॉग किए बिना, अंतिम संदेश स्वभाव और अनसुलझे डाउनस्ट्रीम चरणों को रिकॉर्ड करें।