ई-मेल कैसे करें और गड़बड़ न करें: व्यावहारिक सुझाव

डेवलपर, जिसने पहली बार ईमेल की पीढ़ी का सामना किया था, के पास वस्तुतः ऐसा कोई आवेदन लिखने का कोई मौका नहीं है जो इसे सही ढंग से करेगा। कॉर्पोरेट अनुप्रयोगों द्वारा उत्पन्न लगभग 40% ईमेल में मानकों का उल्लंघन है, और, परिणामस्वरूप, वितरण और प्रदर्शन समस्याएं। इसके कारण हैं: ईमेल तकनीकी रूप से वेब की तुलना में बहुत अधिक जटिल है, मेल कई सौ मानकों द्वारा विनियमित किया जाता है और आम तौर पर स्वीकृत (और ऐसा नहीं) प्रथाओं का एक बेशुमार संख्या है, और ईमेल क्लाइंट विविध और अप्रत्याशित हैं। परीक्षण से स्थिति में काफी सुधार हो सकता है, लेकिन व्यावहारिक रूप से कोई भी सामग्री परीक्षण मेल के लिए समर्पित नहीं है।

Mail.Ru मेल नियमित रूप से अपने उपयोगकर्ताओं के साथ ईमेल के माध्यम से बातचीत करता है। हमारी परियोजना में, सभी घटक जो ईमेल उत्पन्न करने के लिए जिम्मेदार हैं, और यहां तक ​​कि एकल मेलिंग भी अनिवार्य परीक्षण से गुजरते हैं। इस लेख में हम अपने अनुभव (और धक्कों से भरे) को साझा करेंगे।

• ईमेल क्या हैं
• परीक्षण और नियंत्रण प्रक्रिया में कौन शामिल है
• डाक और डाक परिवहन
• मेल इंफ्रास्ट्रक्चर का इंटरफ़ेस और परीक्षण के तहत आवेदन की सीमाएं
• परीक्षण किए गए मापदंडों की परिभाषा
• एक जनरेटिंग एप्लिकेशन की विशिष्ट संरचना
• क्या और कब टेस्ट करना है
  
  1. वितरण बुनियादी ढाँचा
  2. अनुप्रयोग उत्पन्न करना
  3. संरचनात्मक और लेआउट पत्र टेम्पलेट
• बुनियादी ढांचे की जाँच के लिए बुनियादी आवश्यकताएं
• प्राधिकरण की आवश्यकताएं
• जनरेटिंग एप्लिकेशन का सत्यापन
  
  • डाक पता की आवश्यकताएँ
  • ईमेल हैडर आवश्यकताएँ
  • पत्र की संरचना के लिए आवश्यकताएँ
  • URI आवश्यकताएँ
  • लेआउट आवश्यकताएँ
• विभाजित परीक्षणों का आयोजन

ईमेल क्या हैं

आवेदन विभिन्न प्रकार के पत्र उत्पन्न कर सकता है। उन्हें कई श्रेणियों में वर्गीकृत किया जा सकता है। प्राप्तकर्ता चुनने की विधि से: ट्रिगर - चयनात्मक - समूह। नियुक्ति से: लेन-देन - विपणन - सेवा। विभिन्न प्रकार के पत्रों में अलग-अलग आवश्यकताएं हो सकती हैं और विभिन्न परीक्षण स्क्रिप्ट को लागू कर सकते हैं।

ट्रिगर ईमेल किसी भी घटना के जवाब में उत्पन्न होते हैं, उदाहरण के लिए, उपयोगकर्ता की कार्रवाई या किसी भी सिस्टम ऑब्जेक्ट की स्थिति में परिवर्तन। वे आवेदन द्वारा उत्पन्न होते हैं, और इसलिए परीक्षण के संदर्भ में सबसे दिलचस्प हैं। ट्रिगर ईमेल ट्रांसेक्शनल और मार्केटिंग दोनों हो सकते हैं।

कस्टम पत्र किसी भी मापदंड से मेल खाने वाले उपयोगकर्ताओं के गतिशील चयन के लिए भेजे जाते हैं।

समूह संदेश प्राप्तकर्ता के एक ज्ञात समूह को भेजे जाते हैं, उदाहरण के लिए, सभी उपयोगकर्ताओं या भागीदारों के लिए। चयनात्मक और समूह पत्र सबसे अधिक बार विपणन होते हैं, ऐसे पत्रों को भेजना मैन्युअल रूप से या एक कार्यक्रम के अनुसार शुरू किया जाता है।

जब उपयोगकर्ता कोई क्रिया करता है, तो ट्रांसेक्शनल अक्षर उत्पन्न होते हैं। इस तरह के पत्रों में शामिल हैं, उदाहरण के लिए, चालान, टिकट या डिलीवरी की स्थिति की सूचनाएं, एक एक्सेस रिकवरी कोड के साथ पत्र आदि। लेनदेन संबंधी ईमेल हमेशा ट्रिगर होते हैं। अधिकतम संगतता उनके लिए महत्वपूर्ण है, जिसका अर्थ है कि उन्हें यथासंभव सरल होना चाहिए, और उन्हें बड़ी संख्या में ग्राहकों पर परीक्षण करने की आवश्यकता है।

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

समूह विपणन पत्र, उदाहरण के लिए, मौसमी ऑफ़र, प्रचार और बिक्री के बारे में संदेश, अक्सर "मैन्युअल रूप से" भेजे जाते हैं और आपके आवेदन का हिस्सा नहीं होते हैं, लेकिन आप (और उन्हें) सामान्य परीक्षण सिद्धांतों को लागू कर सकते हैं।

इसके अलावा, स्वचालित या स्वचालित सीआरएम, जर्नलिंग, ऑडिटिंग या डीडब्ल्यूएच सिस्टम के लिए कर्मचारी उत्पन्न सेवा पत्र हो सकते हैं। इस तरह के पत्र ट्रिगर होते हैं, जिसका अर्थ है कि वे भी आवेदन का हिस्सा हैं और उनका परीक्षण किया जाना चाहिए।

परीक्षण और नियंत्रण प्रक्रिया में कौन शामिल है

1. QA- इंजीनियर - प्रक्रिया के सभी चरणों में भाग लेता है।
2. नेटवर्क इंजीनियर - नेटवर्क और संदेश संरचना के विन्यास के लिए जिम्मेदार। एक नेटवर्क इंजीनियर को बुनियादी ढांचे के परीक्षण की योजना में शामिल होना चाहिए।
3. एक वितरण विशेषज्ञ एक ऐसा व्यक्ति है जो पत्रों के वितरण की निगरानी करता है, जो भेजे गए सभी संदेशों के तकनीकी और प्रशासनिक मापदंडों के नियंत्रण में भी भाग लेता है और मेलिंग प्रक्रिया की प्रगति की निगरानी करता है। वह यह सुनिश्चित करने के लिए जिम्मेदार है कि भेजे गए पत्र उपयोगकर्ताओं के अधिकतम संभव प्रतिशत तक पहुंचते हैं और स्पैम में नहीं आते हैं, और इसके लिए विशेषज्ञ के पास निश्चित ज्ञान और संपर्क होना चाहिए। यदि पत्रों के वितरण में समस्याएं आती हैं, तो यह वह है जो संभावित कारण को समझना चाहिए और इसे समाप्त करना चाहिए: या तो तकनीकी बाधाओं को दूर करके; या अक्षरों की सामग्री में कुछ बदल रहा है; या मेल प्रदाता के समर्थन सेवा के साथ समस्या को हल करना, जिसमें पत्र नहीं पहुंचते हैं। इस तरह के एक विशेषज्ञ (यदि कोई हो) को भी अनुप्रयोगों और पत्रों को उत्पन्न करने वाले बुनियादी ढांचे की एक चेकलिस्ट और परीक्षण की तैयारी में शामिल होना चाहिए। हालाँकि, परीक्षण प्रक्रिया स्वयं QA सेवा के नियंत्रण में होनी चाहिए।
4. ईमेल मार्केटर - मार्केटिंग अभियानों की प्रभावशीलता को निर्धारित करता है। उनके नियंत्रण में, विपणन मेलिंग के लिए आवश्यक दर्शकों के लिए विभाजन परीक्षण आयोजित किया जाता है। ईमेल मार्केटर यूजर बेस के सेगमेंटेशन, भेजे गए ईमेल की रचना और आवृत्ति, और यूजर को ईमेल की विजुअल "प्रेजेंटेशन" को भी नियंत्रित करता है।

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

डाक और डाक परिवहन

मेल संरचना एक विशाल हिमखंड के समान है, और इसके दो स्तर हैं। मेल को नियंत्रित करने के लिए सौ से अधिक विभिन्न मानक हैं, लेकिन उनमें से लगभग सभी दो स्तरों में से एक हैं:

आइसबर्ग का पानी के नीचे का हिस्सा एक नेटवर्क सेवा है जिसका मूल प्रोटोकॉल SMTP अनुप्रयोग प्रोटोकॉल है, जिसे RFC 5321 द्वारा परिभाषित किया गया है। यह पत्रों के वितरण के लिए जिम्मेदार है। पत्र को वितरित करने के लिए, एक तथाकथित एसएमटीपी लिफाफा बनता है, जिसमें एसएमटीपी स्तर के प्रेषक और रिसीवर के पते शामिल होते हैं। पत्र वितरित करने के लिए DNS जैसी अन्य नेटवर्क सेवाएं भी जिम्मेदार हैं। नेटवर्क इन्फ्रास्ट्रक्चर का मुख्य घटक मेल ट्रांसफर एजेंट है, या संक्षिप्त नाम MTA का अधिक बार उपयोग किया जाता है। MTA संदेश वितरण कतार और प्राप्तकर्ता सर्वर को वितरण प्रक्रिया को संभालने के लिए जिम्मेदार है। एमटीए के उदाहरण पोस्टफिक्स, सेंडमेल, एक्जिम, माइक्रोसॉफ्ट एसएमटीपी सेवा हैं।

हिमखंड का यह पानी के नीचे का हिस्सा, जिसमें एमटीए, डीएनएस पैरामीटर और अन्य नेटवर्क पैरामीटर शामिल हैं, हम मेल इंफ्रास्ट्रक्चर, या संदेश डिलीवरी इन्फ्रास्ट्रक्चर कहेंगे।

हिमखंड की सतह ही अक्षर है। पत्र की मूल संरचना RFC 5322 में परिभाषित की गई है। इस पत्र में सर्विस हेडर और डेटा के साथ एक या अधिक भाग शामिल हैं। डेटा में सादा पाठ और / या HTML, इनलाइन छवियां या लगभग किसी भी प्रकार के अनुलग्नक में पाठ हो सकता है।

मेल इंफ्रास्ट्रक्चर का इंटरफ़ेस और परीक्षण के तहत आवेदन की सीमाएं

मेल इंफ्रास्ट्रक्चर, एक नियम के रूप में, एक या अधिक इंटरफेस है जिसके साथ एक पत्र भेजा जाता है (यह एमटीए डिलीवरी कतार में प्रवेश करता है)। उदाहरण के लिए, SMTP सबमिशन सेवा, PHP में mail() फ़ंक्शन, बाहरी मेल या सेंडमेल एप्लिकेशन को डेटा ट्रांसफर, आंतरिक या बाहरी सेवाओं की एपीआई (उदाहरण के लिए, GetResponse, SendPulse या Amazon SES)। हम इन इंटरफेस को बुनियादी ढांचे का हिस्सा मानेंगे। अक्सर एक ऐसी स्थिति होती है जहां एप्लिकेशन ए पत्र और प्राप्तकर्ताओं की सूची के लिए डेटा तैयार करता है, और फिर इसे अपने एपीआई के माध्यम से आवेदन बी में स्थानांतरित करता है (बड़े पैमाने पर मेलिंग विपणन के लिए, यह उपयोगकर्ता इंटरफ़ेस - यूआई के माध्यम से मैन्युअल रूप से किया जा सकता है), और पहले से ही बी में एक मेल संदेश उत्पन्न करता है। RFC 5322 प्रारूप और किसी तरह MTA वितरण के लिए इसे कतार में खड़ा करता है। एप्लिकेशन ए (और इसका परीक्षण करते समय) के दृष्टिकोण से, एप्लिकेशन बी मेल बुनियादी ढांचे का हिस्सा होगा। एप्लिकेशन B API या UI एप्लिकेशन A के लिए मेल इंफ्रास्ट्रक्चर इंटरफेस होगा। यद्यपि आवेदन बी के दृष्टिकोण से, स्थिति अलग होगी, और इसके लिए मेल बुनियादी ढाँचा निचले स्तर के नेटवर्क अनुप्रयोग या प्रोटोकॉल होंगे।

परीक्षण किए गए मापदंडों की परिभाषा

प्रत्येक एप्लिकेशन का परीक्षण करते समय, इसके द्वारा उपयोग किए जाने वाले सभी मेल इन्फ्रास्ट्रक्चर को उजागर करना महत्वपूर्ण है (कई हो सकते हैं), और प्रत्येक बुनियादी ढांचे के लिए, उपयोग किए गए इंटरफेस का चयन करें (प्रत्येक बुनियादी ढांचे के लिए भी कई हो सकते हैं)। प्रत्येक इंटरफ़ेस के लिए, इसके लिए हस्तांतरित डेटा की संरचना और प्रारूप को यथासंभव सटीक रूप से निर्धारित किया जाता है, उदाहरण के लिए: TEXT / HTML में संदेश पाठ, TEXT / PLAIN में संदेश पाठ, संदेश विषय, प्राप्तकर्ता का नाम, प्राप्तकर्ता का नाम, प्रेषक का नाम, पत्र भेजने वाले का पता (RFC5321.From) ), SMTP कंडक्टर (RFC5322.mailfrom) के प्रेषक का पता। अगला, आवश्यकताओं का एक सेट प्रत्येक पैरामीटर (प्रतिनिधित्व, एनकोडिंग, सीमा मान आदि) के लिए विकसित किया जाता है, प्रत्येक पैरामीटर के लिए नियंत्रण विधियां निर्धारित की जाती हैं (किस तरह से वास्तविक परिणाम की अपेक्षा की जा सकती है)।

एक जनरेटिंग एप्लिकेशन की विशिष्ट संरचना

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

एप्लिकेशन के मुख्य तत्व जिन्हें नियंत्रित करने की आवश्यकता है:

• हेडर और / या अक्षर संरचना उत्पन्न करने के लिए जिम्मेदार कोड यदि पत्र संरचना गतिशील रूप से उत्पन्न होती है और / या इसकी संरचना का वर्णन करने वाला एक स्थिर पत्र टेम्पलेट;
• पत्र के HTML भाग का लेआउट (आदर्श रूप से, यह एक अलग इकाई या पत्र के टेम्पलेट / लेआउट का हिस्सा है, लेकिन इसे एप्लिकेशन कोड में सीवन किया जा सकता है);
• एक पत्र में आवेदन डेटा का प्रतिस्थापन (या एक पत्र टेम्पलेट में);
• पत्र वितरण बुनियादी ढांचे के साथ आवेदन एकीकरण, बुनियादी ढांचे के इंटरफेस में स्थानांतरित मापदंडों की शुद्धता।

क्या और कब टेस्ट करना है

हमें यह पसंद है या नहीं, पूरे हिमखंड का परीक्षण करने की आवश्यकता है। कई मुख्य घटक हैं जिन्हें परीक्षण की आवश्यकता होती है:

1. वितरण बुनियादी ढाँचा

परीक्षण में जोर दिया जाना चाहिए: पत्र वितरण; पीटीआर / एफसीआरडीएनएस, एमएक्स और ए रिकॉर्ड सहित डीएनएस रिकॉर्ड की शुद्धता; एसएमटीपी प्रोटोकॉल सेटिंग्स (टीएलएस का उपयोग करके हेलो); पत्र प्राधिकरण (SPF / DKIM / DMARC); एसएमटीपी लिफाफा पते (यदि वे एप्लिकेशन द्वारा प्रबंधित नहीं किए जाते हैं); इंफ्रास्ट्रक्चर इंटरफेस के इनपुट मापदंडों का सही प्रसंस्करण; वितरित पत्रों का ट्रैकिंग, लेखा और प्रसंस्करण।

प्रारंभिक कार्यान्वयन के दौरान बुनियादी ढांचे का परीक्षण करना आवश्यक है और हर बार जब बुनियादी ढांचे में परिवर्तन किए जाते हैं (एमटीए, डीएनएस या नेटवर्क परिवर्तन का विन्यास) या पत्र भेजने के लिए इंटरफ़ेस; एक नए डोमेन, नेटवर्क, या एपीआई का उपयोग करना महत्वपूर्ण रूप से भेजे गए ईमेल की विशेषताओं को बदल दें, जैसे कि उनकी भाषा, आकार या मात्रा। अनुभव के अनुसार, बुनियादी ढांचा युद्ध की घोषणा किए बिना बदल जाता है, इसलिए बुनियादी परीक्षणों को समय-समय पर किया जाना चाहिए, भले ही किसी भी बदलाव के बारे में कोई जानकारी न हो।

एक नेटवर्क इंजीनियर और सुपुर्दगी विशेषज्ञ योजना और बुनियादी ढांचे के परीक्षण की सूचियों की तैयारी में शामिल हो सकते हैं।

2. उत्पन्न करने वाला आवेदन

आपको एसएमटीपी लिफाफे के पते को नियंत्रित करना चाहिए (यदि वे एप्लिकेशन द्वारा नियंत्रित होते हैं, अर्थात् इंटरफ़ेस - लिफाफा-लिफाफा, लिफाफे में स्थानांतरित किया जाता है), सेवा संदेश हेडर के मान (दिनांक, संदेश-आईडी, सूची-सदस्यता समाप्त, ऑटो-सब्मिट, आदि) पी।), पत्र प्राधिकरण (DKIM / DMARC), MIME एनकोडिंग (बेस 64, उद्धृत-मुद्रण योग्य), पत्र प्रारूप की सामान्य शुद्धता, उदाहरण के लिए, हेडर में गैर-ASCII वर्णों की अनुपस्थिति, प्रतिस्थापित डेटा की संरचना, ट्रिगर, सही तंत्र की प्रतिलिपि बनाना, सदस्यता समाप्त करना, ट्रैकिंग प्रणाली। पत्र और सांख्यिकी संग्रह (पोस्टमास्टर हेडर, उदाहरण के लिए, फीडबैक-आईडी या एक्स-मेल्रू-एमएसगाइप, साथ ही ट्रैकिंग पिक्सल) ।

आपको अपने विकास के दौरान एप्लिकेशन का परीक्षण करने की आवश्यकता होती है, जब डेटा को उत्पन्न करने और संग्रहीत करने के लिए जिम्मेदार सभी संबंधित घटकों को बदलते हैं, पत्र टेम्पलेट में महत्वपूर्ण परिवर्तन के साथ, जब उपयोग किए गए बुनियादी ढांचे या इसके इंटरफ़ेस को बदलते हैं, साथ ही साथ सामान्य रजिस्टरों के ढांचे में भी।

3. स्ट्रक्चरल और लेआउट लेटर टेम्प्लेट (जेनरेटिंग एप्लिकेशन का हिस्सा हो सकते हैं या अलग से विकसित किए जाते हैं)

संदेश की संरचना की जाँच की जाती है (सामग्री-प्रकार, सामग्री-विवाद, पत्र के बहु-भागों के हिस्से, पाठ एन्कोडिंग, स्ट्रिंग पैरामीटर), लक्ष्य का मूल्य और प्रदर्शित हेडर (से, प्रति, उत्तर-से-विषय), संदेश पत्र की सूची में और पढ़ते समय प्रदर्शित होता है। विभिन्न इंटरफेस में, माइक्रोफ़ॉर्मेट्स (उदाहरण के लिए, एक कैलेंडर ईवेंट को कैलेंडर ईवेंट के रूप में, या एयर टिकट के रूप में एयर टिकट) के रूप में पहचाना जाता है।

हर बार जब आप कम से कम मामूली बदलाव करते हैं, और अलग-अलग, उदाहरण के लिए, ईमेल टेम्प्लेट का परीक्षण किया जाना चाहिए, उदाहरण के लिए, ऐसी स्थिति में जहां सर्वर के तैयार होने से पहले पत्र आवेदन में आते हैं।

यह अनुशंसा की जाती है कि आप पत्र टेम्पलेट के परीक्षण के लिए एक चेकलिस्ट लिखने के लिए एक ईमेल मार्केटर और डिलीवरी विशेषज्ञ का उपयोग करें।

बुनियादी ढांचे की जाँच के लिए बुनियादी आवश्यकताएं

मेल सर्वर के लिए चयनित आईपी पता, मेल सर्वर के आईपी पते के समान ही होना चाहिए। यह whois उपयोगिता का उपयोग करके इसे जांचने की सिफारिश की गई है। विशेष रूप से, प्रेषक का पता उस नेटवर्क से संबंधित नहीं होना चाहिए जिसे गतिशील माना जा सकता है; चयनित नेटवर्क के पास वैध संपर्क होना चाहिए जिससे आप शिकायतें भेज सकें; नेटवर्क का उपयोग किया जाना चाहिए (RIPE में ASSIGNED स्थिति)। IP पते में सही ढंग से कॉन्फ़िगर किया गया PTR रिकॉर्ड होना चाहिए। इसे होस्टिंग कंट्रोल पैनल के माध्यम से या प्रदाता की सहायता सेवा का उपयोग करके स्वतंत्र रूप से कॉन्फ़िगर किया जा सकता है। PTR रिकॉर्ड को वास्तविक होस्ट नाम की ओर इंगित करना चाहिए और उसी समय सार्थक होना चाहिए, उसी IP पते (तथाकथित FCrDNS चेक) पर वापस जाएं, न कि डायनामिक होस्ट का नाम याद दिलाएं और न ही संख्याओं या वर्णों के एक बड़े समूह को शामिल करें। एक अच्छा उदाहरण mailserver.example.com है।

लिफाफे के पते या संदेश हेडर में उपयोग किए गए प्रत्येक डोमेन के पास होस्ट के ए-रिकॉर्ड की ओर इशारा करते हुए एक वैध एमएक्स रिकॉर्ड होना चाहिए, जो कम से कम डिलीवरी विफलता के बारे में संदेश संसाधित कर सकता है। एमएक्स के लिए, सीधे आईपी पते पर संदर्भित करने की अनुमति नहीं है।

एसपीएफ़, डीकेआईएम, डीएमएआरसी के पारित होने को नियंत्रित करें। एसपीएफ़ डोमेन स्वामी को TXT में निर्दिष्ट करने की अनुमति देता है, उन सर्वरों की एक सूची दर्ज करता है, जिन्हें इस डोमेन में वापसी पते के साथ ईमेल संदेश भेजने का अधिकार है। यह डोमेन DNS ज़ोन प्रबंधन अनुभाग में लिफाफे से (SMTP लिफाफे) में उपयोग किए गए पते के लिए कॉन्फ़िगर किया गया है। डीकेआईएम डिजिटल हस्ताक्षर तकनीकों का उपयोग करके किसी संदेश या उसके प्रेषक के किसी विशिष्ट डोमेन से संबंधित लेखक के सत्यापन का सत्यापन प्रदान करता है, जो स्वयं संदेश में (इसके डीकेआईएम-हस्ताक्षर हेडर में) जोड़े जाते हैं। आमतौर पर, एक डीकेआईएम हस्ताक्षर एमटीए (बुनियादी ढांचे) स्तर पर कॉन्फ़िगर किया गया है। DMARC एक विशिष्ट डोमेन में आने वाले मेल की जाँच करने और एसपीएफ या डीकेआईएम प्रमाणीकरण पारित नहीं करने वाले पत्रों पर कार्रवाई करने की नीति निर्धारित करता है। जब आप इस नीति का उल्लंघन करने का प्रयास करते हैं, तो इस तरह के प्रयास के बारे में जानकारी के साथ एक संरचित रिपोर्ट आती है। DMARC, साथ ही SPF को डोमेन ज़ोन में TXT रिकॉर्ड के रूप में प्रकाशित किया जाता है।

रूस, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru के लिए मुख्य डाक सेवाओं के लिए पत्रों की डिलीवरी की जाँच करें। पत्रों में आपको हेलो की शुद्धता को सत्यापित करने की आवश्यकता है; उपलब्धता और चेकों का पारित होना PTR / FCrDNS, SPF, DKIM और DMARC; हेडर की वैधता और उनमें डेटा, विशेष रूप से, तारीखों में घंटों का सिंक्रनाइज़ेशन और टाइम ज़ोन की शुद्धता।



कुछ मापदंडों का गठन, उदाहरण के लिए, प्राधिकरण, वितरण और स्पैमिंग, सभी घटकों द्वारा अभिन्न रूप से प्रभावित होता है, हालांकि आमतौर पर उन्हें नियंत्रित करने के लिए अलग परिचालन उपकरण होते हैं - DMARC और FBL रिपोर्ट, पोस्टमास्टर सेवा API, ईमेल ट्रैकिंग टूल, और डिलीवरी आँकड़े। परीक्षण को कंपनी में परिचालन निगरानी उपकरणों के कार्यान्वयन के स्तर को ध्यान में रखना चाहिए - उदाहरण के लिए, DMARC रिपोर्टों के संचालन की निगरानी के अभाव में, आपको नियमित रूप से मेल वितरण का परीक्षण करना चाहिए, परिचालन वितरण नियंत्रण की अनुपस्थिति में - नियमित रूप से जांच करें कि पत्र कैसे और कहां मिलते हैं, भले ही पत्र भेजने से संबंधित कोई विकास न हो। आयोजित नहीं किया गया।

बुनियादी ढांचे की जांच के लिए, आप विशेष सेवाओं का उपयोग कर सकते हैं, उदाहरण के लिए, mail-tester.com , mxtoolbox.com । इस लेख में विस्तृत अवसंरचना आवश्यकताओं को पाया जा सकता है।

प्राधिकरण की आवश्यकताएं

एसपीएफ, डीकेआईएम के पारित होने की जाँच करना, डीएमएआरसी आमतौर पर प्राप्तकर्ता के सर्वर पर प्रमाणीकरण-परिणाम हेडर का उपयोग करना संभव है।

वाक्यविन्यास के लिए SPF रिकॉर्ड की वैधता की जाँच करें, DNS प्रश्नों की सीमा (उदाहरण के लिए, mxtoolbox.com का उपयोग करके)। एक एसपीएफ़ का गठन करते समय, सभी मेलिंग स्रोतों को ध्यान में रखा जाना चाहिए (सीआरएम सिस्टम को मत भूलना, सभी उपयोग किए गए डिलीवरी इन्फ्रास्ट्रक्चर, जिसमें वे भी शामिल हैं, जिनके माध्यम से एक-बार मार्केटिंग अभियान संचालित होते हैं)। नेटवर्क की सूची ('ip4' / 'ip6') के माध्यम से डोमेन के लिए अनुमत सर्वर सेट करने की सिफारिश की गई है। एसपीएफ को एसएमटीपी लिफाफे से प्रेषक पते के लिए जाँच की जाती है। सत्यापित करें कि SMTP लिफाफा डोमेन (लिफाफा-से) डोमेन से हेडर से मेल खाता है। इस आलेख में सामान्य SPF त्रुटियाँ सूचीबद्ध हैं।

DKIM DNS रिकॉर्ड की जाँच करें, DKIM हस्ताक्षर की वैधता और संरचना। सत्यापित करें कि आप कम से कम 1024 बिट्स की DKIM कुंजी का उपयोग कर रहे हैं। डीकेआईएम हस्ताक्षर की अनुशंसित हैश मोड: आराम / आराम। सुनिश्चित करें कि सभी महत्वपूर्ण हेडर पर हस्ताक्षर किए गए हैं (से, टू, सब्जेक्ट, दिनांक, संदेश-आईडी, माइम-संस्करण, सामग्री-प्रकार), जो ट्रैकिंग हेडर (प्राप्त, वितरित-टू, रिटर्न-पाथ) पर हस्ताक्षर नहीं किए गए हैं, और DKIM के लिए मान्य है मूल डाक सेवाएं मेल सेवाओं में से किसी एक को अग्रेषित करने के लिए सेट करें; अग्रेषित पत्रों पर DKIM को "हरा" नहीं करना चाहिए। सत्यापित करें कि DKIM हस्ताक्षर डोमेन प्रेषक डोमेन से हेडर से मेल खाता है।

बेसिक मेल सेवाओं के लिए DMARC की जाँच करें। DMARC रिपोर्ट की जाँच करें, पहचानें और अपने बुनियादी ढांचे के सभी IP पतों के लिए SPF और DKIM का निवारण करें।

सत्यापित करें कि संदेशों को एन्क्रिप्शन (TLS) का उपयोग करके बाहरी सर्वरों तक पहुंचाया गया है। कभी-कभी आप प्राप्तकर्ता के सर्वर पर प्राप्त हेडर द्वारा टीएलएस के लिए जांच कर सकते हैं: उदाहरण के लिए, ESMTPS प्रोटोकॉल या फॉर्म के मापदंडों की उपस्थिति (संस्करण = TLS1_2 सिफर = ECDHE-RSA-A8128-GCM-SHA256 बिट्स = 128/128) निर्दिष्ट करना; टीएलएस की उपस्थिति को इंगित करता है।

जनरेटिंग एप्लिकेशन का सत्यापन

डाक पता की आवश्यकताएँ

लिफाफा पते
हम एसएमटीपी लिफाफे में पतों के साथ जेनरेटिंग एप्लिकेशन का सत्यापन शुरू करते हैं।

लिफाफा पते मेल इंफ्रास्ट्रक्चर स्तर के पते हैं। वे उपयोगकर्ता के लिए दृश्यमान नहीं हैं, लेकिन वितरण के लिए महत्वपूर्ण हैं, क्योंकि जिस पत्र में मेलबॉक्स मिलता है, वह लिफाफे के पते से सटीक रूप से निर्धारित होता है।

एक लिफाफे में प्राप्तकर्ता का पता (लिफाफा-टू, उर्फ ​​आरसीपीटी टू :) वह पता है जिसके लिए पत्र वास्तव में वितरित किया जाएगा।

• पंजीकरण को छोड़कर सभी पत्रों के लिए, पते को कानूनी रूप से हस्ताक्षरित होना चाहिए और प्रशासनिक आवश्यकताओं के अनुसार मेलिंग के लिए मान्य होना चाहिए।
• समाचार पत्र के लिए, पता "लाइव" होना चाहिए, जिन पते पर पत्र नियमित रूप से वितरित नहीं किए जा सकते, उन्हें निष्क्रिय के रूप में चिह्नित किया जाना चाहिए, उन्हें मेल नहीं बनाया जाना चाहिए। लेकिन कुछ श्रेणियों के पत्र (उदाहरण के लिए, एक्सेस रिकवरी) को पहले से निष्क्रिय के रूप में चिह्नित पते पर भेजने की आवश्यकता हो सकती है।

एक SMTP लिफाफे में प्रेषक का पता (आमतौर पर लिफाफा-से, smtp.mailfrom या रिटर्न-पथ कहा जाता है) - संदेश इस पते पर एक पत्र और स्वचालित उत्तर देने में असमर्थता के बारे में दिया जाएगा। यह पता उपयोगकर्ता को दिखाई नहीं देता है। इस पते का उपयोग SPF प्राधिकरण के लिए भी किया जाता है। हम यह सत्यापित करते हैं:

• पता उपलब्ध है;
• यह कर्मचारी का पता नहीं है और ऑटो उत्तर, अपात्रता के बारे में संदेश आदि को बाहर करने के लिए उसे पुनर्निर्देशित नहीं किया गया है;
• यह एक स्क्रिप्ट द्वारा संसाधित किया जाता है जो दुर्गम उपयोगकर्ताओं के पते को निष्क्रिय के रूप में चिह्नित करेगा;
• पता स्वतः उत्पन्न हो सकता है, अर्थात प्रत्येक अक्षर के लिए अद्वितीय;
• इस पते पर एक पत्र किसी भी प्रतिक्रिया पत्र की पीढ़ी के लिए नहीं जाना चाहिए, उदाहरण के लिए, एक बॉक्स अतिप्रवाह के बारे में एक संदेश।

ईमेल हैडर पते

ये पते या तो सीधे उपयोगकर्ता को दिखाई देते हैं या किसी पत्र का उत्तर देते समय उपयोग किए जाते हैं।

प्रेषक का पता (:) :) शीर्षक अक्षरों की सूची में प्रदर्शित और प्रेषक का नाम है और एक पत्र पढ़ते समय। हम यह सत्यापित करते हैं:

• यह एक "मानव पठनीय" दोस्ताना पता है जो कंपनी की पहचान करता है।
• इसमें न केवल ई-मेल, बल्कि प्रेषक का नाम भी शामिल है।
• noreply @ संभव है, लेकिन केवल अगर हम इस बात पर जोर देना चाहते हैं कि हम पत्र की प्रतिक्रिया प्राप्त करने की उम्मीद नहीं करते हैं और इसे पढ़ा नहीं जाएगा। पत्र के पाठ में इस विचार की नकल करना बेहतर है।
• गैर-एएससीआईआई पात्रों (उदाहरण के लिए, सिरिलिक) की उपस्थिति में, प्रेषक का नाम माइम के अनुसार एन्कोड किया जाना चाहिए, गैर-एएससीआईआई पात्रों की उपस्थिति में डोमेन को पुनर्नवीनीकरण में एन्कोड किया जाना चाहिए।
• एक ही श्रेणी के अक्षरों का एक ही पता होना चाहिए, ऑटो-जनरेट किए गए पते के उपयोग की अनुमति नहीं है। यह इस तथ्य के कारण है कि सबसे अधिक बार लोगों द्वारा फिल्टर का उपयोग करके फ़ोल्डर में अक्षरों को सॉर्ट करने के लिए उपयोग किया जाता है।
• लेन-देन, विपणन और तत्काल पत्रों (जैसे समर्थन से पत्र) के लिए पता अलग-अलग होना चाहिए (अधिमानतः विभिन्न उप-क्षेत्रों में)। यह इस तथ्य के कारण भी है कि उपयोगकर्ता विपणन ईमेल को स्पैम के रूप में चिह्नित कर सकता है या किसी अपठनीय फ़ोल्डर में फ़िल्टर कर सकता है।
• DMARC के भीतर SPF पास करने के लिए पता और SMTP लिफाफे का पता एक ही डोमेन में या एक ही संगठनात्मक डोमेन के उप-डोमेन में होना चाहिए।
• पता संगठन के डोमेन से होना चाहिए। से फ्री मेल सेवाओं और अन्य सार्वजनिक मेल डोमेन का उपयोग करने के लिए अस्वीकार्य है, क्योंकि ऐसे मेलिंग DMFC के ढांचे के भीतर SPF और DKIM प्रमाणीकरण पारित नहीं करेंगे।

उत्तर-पता करने के लिए - "मैनुअल" उत्तर इस पते पर भेजे जाएंगे जब उपयोगकर्ता पत्र का जवाब देगा। यह वैकल्पिक है: यदि यह अनुपस्थित है, तो From का पता प्रतिक्रिया के लिए उपयोग किया जाता है। उत्तर दें कि:

• यह ऑटो-जनरेट किया जा सकता है, अर्थात पत्र के लिए अद्वितीय (आपको यह पता लगाने की अनुमति देता है कि कौन सा पत्र उत्तर आया)।
• यह उत्तर देने वाले कॉल से बचने के लिए कर्मचारी के बॉक्स में नहीं गिरना चाहिए, लेकिन आदर्श रूप से सीआरएम में "लिपटे" होना चाहिए।
• यह एक मानक सीआरएम ऑटो उत्तर उत्पन्न कर सकता है, लेकिन यह कुछ भी अतिरंजित नहीं होना चाहिए, उदाहरण के लिए, एक बॉक्स अतिप्रवाह के बारे में संदेश। ऑटो-प्रतिक्रियाएं पैदा करते समय, लूपिंग से बचने के लिए उपाय किए जाने चाहिए, वे आरएफसी 3834 में सूचीबद्ध हैं।
• यह किसी भी डोमेन से हो सकता है जो जरूरी नहीं कि से मेल खाता हो, लेकिन कभी-कभी यह उपयोगकर्ताओं को जवाब देते समय डराता है।
• अनुपस्थित हो सकता है, तब से पता अपने कार्य करता है।
• पते के अलावा, प्रेषक का नाम इंगित किया गया है।

पता करने के लिए:

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

ईमेल हैडर आवश्यकताएँ

पाठ के वास्तविक एन्कोडिंग को हेडर में इंगित एक से मेल खाना चाहिए। पत्र के सभी हेडर और भागों में एक एन्कोडिंग का उपयोग करना उचित है। यह अनुशंसा की जाती है कि आप एक व्यापक रूप से समर्थित के रूप में UTF-8 का उपयोग करें। एन्कोडिंग सामग्री-प्रकार के हेडर और HTML भाग के <META> टैग में इंगित की गई है।

से:, संदेश-आईडी: और दिनांक: पत्र भेजने के लिए हेडर का निर्माण सीधे स्क्रिप्ट में होना चाहिए (और मानकों द्वारा - पत्र के पाठ के साथ) और हमेशा सही प्रारूप में। यदि वे अनुपस्थित या गलत तरीके से बनते हैं, तो पारगमन सर्वरों में से एक इन हेडर को जोड़ सकता है, जिससे DKIM हस्ताक्षर की अखंडता का उल्लंघन होता है।

हेडर में 8-बिट वर्ण, विषय पंक्ति (विषय) और संलग्न फ़ाइलों (सामग्री-प्रकार और सामग्री-विवाद) के नामों सहित, अनुपस्थित होना चाहिए; Cyrillic सहित सभी गैर-ASCII वर्ण, उद्धृत-मुद्रण योग्य या आधार 64 में एन्कोड किए जाने चाहिए।

पत्र की संरचना के लिए आवश्यकताएँ

पत्र के HTML भाग के लिए, वैकल्पिक - पाठ (सादा) भाग बनाना वांछनीय है। पत्र के सादा पाठ भाग (यदि हो तो) और पत्र की सामान्य संरचना की अनुरूपता और पठनीयता की जांच करना भी आवश्यक है।

आरएफसी 5322 के अनुसार, एक पत्र में लाइन की लंबाई 998 8-बिट वर्णों से अधिक नहीं होनी चाहिए। कृपया ध्यान दें कि UTF-8 में, एक चरित्र कई ओकटेट्स पर कब्जा कर सकता है। ईमेल में लाइनों का टर्मिनेटर CRLF (<cr> ascii 13, lf> ascii 10) की एक जोड़ी है, जो 2 ऑक्टेट पर है। आपको स्ट्रिंग टर्मिनेटर की शुद्धता की जांच करने की आवश्यकता है, क्योंकि अक्षरों को अक्सर एक यूनिक्स स्क्रिप्ट का उपयोग करके भेजा जाता है, और यूनिक्स में, लाइन टर्मिनेटर एक एकल एलएफ चरित्र है - यह ईमेल के लिए एक त्रुटि है। आपको यह देखने के लिए भी जांचना चाहिए कि क्या स्ट्रिंग टर्मिनेटर UTF-8 एन्कोडेड वर्णों को तोड़ते हैं: आप एक ही वर्ण के दो ऑक्टेट के बीच एक स्ट्रिंग टर्मिनेटर की उपस्थिति की अनुमति नहीं दे सकते हैं, उदाहरण के लिए, सिरिलिक। , base64.

— «Content-Disposition: inline», , , «Content-Disposition: attachment», .
, , : , multipart- (mixed, alternative, related), multipart/mixed , multipart/related — , multipart/alternative — plain text- HTML-. , -, :

multipart/alternative
— text/plain
— text/html

, text/plain text/html multipart/related. , HTML-, - — plain-.

- :

multipart/alternative
— text/plain
— multipart/related
—— text/html
—— image/… (-)
—— image/… (-)

- Content-Disposition: inline multipart/related-.

, , , :

multipart/mixed
— multipart/alternative
—— text/plain
—— multipart/related
——— text/html
——— image/png
——— image/png
...
— application/octet-string (content-disposition: attachment)
— application/octet-string (content-disposition: attachment)
...

(multipart/related- multipart/alternative- , multipart/mixed-)

URI

URI ( src, href, ..) ( https://example.com/somepath ). (/somepath) (//example.com/somepath), , .. file://.

• ASCII- ( , ) URI percent encoding.
• , (.. URL, ), <>, . - , . href A , - . «», .
• htt://, htts:// milto:.
• http:// htts://.
• (, example.com :8080/somepath), .. .
• HTML- - (, , ..) , .. - , ; , , , ( - GET-, POST PUT).
• List-Unsubscribe, , - , .. .
• , , , (, ). . , , , , , .
• क्योंकि URI , URI data:. URI.
• , . , , .
• - .

?

. — (XSS, Crossite scripting), (interface spoofing), DOM clobbering, / (, IP- ) .., . , . :

• ,
• / ,
• ,
• ( ),
• (.. ) ,
• HTML- ( Microsoft Exchange / Outlook RTF, - Outlook ),
• .

, - URI cid://, . , Mozilla Thunderbird cid:// .

- - .

. , URI, - , - , . : , ( , ).

:

• , , , , .
• .
• , , , . ( ). . , .
• , .
• , , .. -, - , c, , ( , , , , - ). , , .
• .
• , , , . (, - ), , , , .
• .
• :
  
  • : « » Mail.Ru, Yandex, Gmail, Rambler Outlook.com;
  • ;
  • , IMAP, , iPhone, Pixel ( Android), Samsung ( Android), MIUI ( Android-);
  • : Chrome, Firefox, Edge, Internet Explorer, Opera .;
  • ( ), Thunderbird, Outlook Apple Mail, The Bat! Opera Mail;
  • - (Exchange, Roundcube, Communigate, Zimbra, SquirrelMail) — B2B-;
  • Retina-, .
• :
  
  • , SPF/DKIM/DMARC.
  • : , .
  • : , , , (, «»).
  • : , .., .
  • .
  • .
  • .
  • , . , , - , , .
    
    
    
    
• ( ) , . , .
• , , , .. , , , «» .
• . , DKIM- - ( DNS DKIM-, ), - ( , , From, Date Message-ID) - ( , , ). «» , .

-

, , .

, , ( ). . , , .

CTR — . postmaster.mail.ru . (), . CTR < 10% — , . CTR > 30%. CTR («») . ( ). , — . , , : https://help.mail.ru/developers/mailing_rules/technical .

- . CTR . ( ). «» — 10 000 , .

: , , . « » . , .

z3apa3a s4ever . EdT 4Alexander .