ईमेल और मेस मेक अप कैसे करें: प्रैक्टिकल टिप्स

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

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

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

किस तरह के ईमेल हैं?

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

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

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

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

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

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

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

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

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

मेलिंग और मेल ट्रांसपोर्ट

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

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

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

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

ईमेल अवसंरचना का इंटरफ़ेस और परीक्षण किए गए अनुप्रयोग की सीमाएँ

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

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

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

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

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

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

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

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

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

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

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

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

अनुप्रयोग उत्पन्न करना

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

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

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

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

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

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

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

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

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

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

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


(पंजीकरण मेल का उपयोग किए गए फ़्रीमेल पते के कारण प्रमाणीकरण टूट गया है)

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

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


(टूटे एसपीएफ़ रिकॉर्ड का एक उदाहरण)

प्रमाणीकरण आवश्यकताओं

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

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

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

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

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

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

ईमेल पते की आवश्यकताएं

लिफाफे के पते

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

लिफाफे में प्राप्तकर्ता का पता ( envelope-to , उर्फ RCPT TO: वह पता है, जिस पर ईमेल वास्तव में दिया जाएगा।

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

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

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

ईमेल हेडर पते

ये पते या तो सीधे उपयोगकर्ता को दिखाई देते हैं या ईमेल का जवाब देते समय उपयोग किया जाता है।
प्रेषक का पता (हेडर From: ईमेल की सूची में और ईमेल पढ़ते समय प्रदर्शित पते और प्रेषक का नाम है। हम यह सत्यापित करते हैं:

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

जब कोई उपयोगकर्ता किसी ईमेल का उत्तर देता है, तो इसका उत्तर Reply-to - 'मैन्युअल' उत्तरों को इस पते पर भेजा जाएगा। यह वैकल्पिक है। यदि यह अनुपस्थित है, तो 'फ्रॉम:' के पते का उपयोग प्रतिक्रिया के लिए किया जाता है। जाँच करें कि 'उत्तर दें':

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

इस पते पर To:

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

ईमेल हेडर आवश्यकताओं

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

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

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


(अजीब एन्कोडिंग में पंजीकरण की पुष्टि)

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

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

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

अनुलग्नकों और इनलाइनों की सही मार्किंग की जांच करना आवश्यक है - अर्थात, हेडर्स के गठन की शुद्धता "सामग्री-विवाद: इनलाइन", यदि यह ईमेल के अंदर प्रदर्शित चित्र है, या "सामग्री-विवाद", संलग्नक " अगर फ़ाइल संलग्न है डाउनलोड के लिए करना है।

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

मल्टीपार्ट / विकल्प
- पाठ / सादा
- पाठ / html

भागों का क्रम महत्वपूर्ण है, पाठ / मैदान को पाठ / html या मल्टीपार्ट / संबंधित होना चाहिए। यह आवश्यक है ताकि HTML भाग डिफ़ॉल्ट रूप से प्रदर्शित हो, और केवल अगर इसका प्रदर्शन किसी कारण से अनुपलब्ध है, तो सादे भाग प्रदर्शित होता है।

यदि ईमेल में इनलाइन चित्र हैं, तो इसकी संरचना इस तरह दिखनी चाहिए:

मल्टीपार्ट / विकल्प
- पाठ / सादा
- मल्टीपार्ट / संबंधित
—— पाठ / एचटीएमएल
—— छवि / ... (इनलाइन-चित्र)
—— छवि / ... (इनलाइन-चित्र)

इनलाइन छवियों में सामग्री-विवाद होना चाहिए: इनलाइन और मल्टीपार्ट / संबंधित भाग के अंदर सख्ती से होना चाहिए।
सबसे कठिन स्थिति में, जब इनलाइन छवियां और संलग्न फाइलें होती हैं, तो ईमेल में निम्न संरचना होती है:

मल्टीआर्ट / मिश्रित
- मल्टीपार्ट / विकल्प
—— पाठ / सादा
- मल्टीपार्ट / संबंधित
—— पाठ / html
—— छवि / png
—— छवि / png
...
- आवेदन / ओकटेट-स्ट्रिंग (सामग्री-स्वभाव: लगाव)
- आवेदन / ओकटेट-स्ट्रिंग (सामग्री-स्वभाव: लगाव)
...
मल्टीपार्ट संबंधित- और मल्टीपार्ट / वैकल्पिक-भागों को संलग्नक से पहले बंद किया जाना चाहिए, संलग्नक बाहरी मल्टीपार्ट / मिश्रित भाग से संबंधित हैं)


(गलत भागों संरचना के साथ पंजीकरण संदेश)

URI की आवश्यकताएं

किसी भी URI (src, href विशेषताएँ, स्टाइल आदि) में प्रोटोकॉल और होस्टनाम (https://example.com/somepath) होना चाहिए। विशिष्ट त्रुटियां सापेक्ष लिंक (/ somepath) और एक प्रोटोकॉल (//example.com/somepath) की कमी का उपयोग हैं, जो ईमेल के लिए अस्वीकार्य है, क्योंकि उनमें, डिफ़ॉल्ट प्रोटोकॉल file:// हो सकता file:// ।

• URI में किसी भी सेवा और गैर-ASCII वर्ण (विशेष रूप से, सिरिलिक) को प्रतिशत एन्कोडिंग का उपयोग करके एन्कोड किया जाना चाहिए।
  
• पाठ के रूप में डाला गया लिंक (जो कि URL के रूप में उपयोगकर्ता को दिखाई देता है, और पाठ के टुकड़े के रूप में नहीं) फिर भी <> टैग के साथ चिह्नित किया जाना चाहिए, अन्यथा, उपयोगकर्ता उस पर क्लिक नहीं कर पाएगा। कुछ वेबमेल अपने दम पर ऐसे लिंक को चिह्नित करते हैं, लेकिन यह मानक व्यवहार नहीं है। इस स्थिति में, A के अंदर का href पता लिंक टेक्स्ट से मेल खाना चाहिए, अन्यथा, सामग्री फ़िल्टर उपयोगकर्ता को धोखा देने के प्रयास के रूप में इस तरह के लिंक पर प्रतिक्रिया कर सकता है। यह विशेष रूप से ध्यान देने योग्य है जब "क्लिकर्स" होते हैं जो ईमेल से उपयोगकर्ता के संक्रमण को ट्रैक करते हैं।
  
• प्रोटोकॉल http:// , https:// और mailto: के उपयोग से खुद को सीमित करना बेहतर है mailto:
  
• उच्च-सुरक्षा आवश्यकताओं के साथ, आपको https:// पक्ष में http:// का उपयोग पूरी तरह से छोड़ देना चाहिए।
  
• गैर-मानक पोर्ट का उपयोग नहीं किया जाना चाहिए (उदाहरण के लिए, example.com : 8080 / somepath), क्योंकि वे उपयोगकर्ता के लिए सुलभ नहीं हो सकते हैं।
  
• HTML भाग के अंदर लिंक पर क्लिक करने से पृष्ठ पर उपयोगकर्ता द्वारा अतिरिक्त पुष्टि के बिना आवेदन की स्थिति (सदस्यता, सदस्यता समाप्त करना, आदेश को रद्द करना, आदि) में कोई बदलाव नहीं होना चाहिए, क्योंकि कुछ सामग्री फ़िल्टरिंग सिस्टम स्वतंत्र रूप से कर सकते हैं। संदर्भ द्वारा पृष्ठ का अनुरोध करके इस तरह के संक्रमण की सुरक्षा को सत्यापित करें; मेल एप्लिकेशन होवर पर लिंक द्वारा पृष्ठ का पूर्वावलोकन दिखा सकता है, और लोड होने के समय को कम करने के लिए उपयोगकर्ता द्वारा लिंक क्लिक करने से पहले आधुनिक ब्राउज़र पृष्ठ को लोड कर सकते हैं (वेब ​​अनुप्रयोग में आमतौर पर किसी भी संशोधित कार्रवाई करने की अनुशंसा नहीं की जाती है अनुरोध प्राप्त करें, सभी संशोधित अनुरोध POST या PUT के माध्यम से जाने चाहिए)।
  
• लिस्ट-अनसब्सक्राइब हैडर में लिंक पर क्लिक करना, इसके विपरीत, उपयोगकर्ता से किसी भी अतिरिक्त कार्रवाई की आवश्यकता नहीं होनी चाहिए, क्योंकि इस लिंक द्वारा सदस्यता समाप्त करना आमतौर पर उपयोगकर्ता की ओर से ईमेल प्रोग्राम या वेबमेल द्वारा किया जाता है। इसके अलावा, RFC 8058 द्वारा शुरू किया गया एक नया हेडर लिस्ट-अनसब्सक्राइब-पोस्ट है।
  
• आपको उपयोगकर्ता से ईमेल पढ़ने और उसी ब्राउज़र में लिंक का अनुसरण करने की अपेक्षा नहीं करनी चाहिए जिसमें वह ईमेल भेजने के लिए अग्रणी कार्रवाई शुरू करता है (उदाहरण के लिए, खाता पंजीकृत करता है)। लिंक किसी अन्य ब्राउज़र या मोबाइल डिवाइस में काम करना चाहिए। विशेष रूप से, उपयोगकर्ता अधिकृत किए बिना लिंक को खोल सकता है, या जिस खाते में ईमेल भेजा गया था, उसके अलावा किसी अन्य खाते में अधिकृत है।
  
• क्योंकि यूआरआई की लंबाई सीमित हो सकती है; आपको बड़ी वस्तुओं के लिए 'डेटा:' प्रकार के यूआरआई का उपयोग नहीं करना चाहिए। उसी कारण से, URI का उपयोग न करें जो हाइपरलिंक में बहुत लंबा है।
  
• आपको बाहरी लिंक शॉर्टनर का उपयोग नहीं करना चाहिए, यह ईमेल की डिलीवरी को नकारात्मक रूप से प्रभावित करता है। यह बेहतर है यदि सभी लिंक आपके डोमेन की ओर इशारा करते हैं, तो यह ईमेल के वितरण पर किसी और की प्रतिष्ठा के संभावित नकारात्मक प्रभाव को कम करेगा।
  
• कुछ सार्वजनिक सेवाओं या मुफ्त होस्टिंग पर बाहरी छवियां न रखें, एक विश्वसनीय होस्टिंग सेवा या सीडीएन का उपयोग अच्छे प्रदर्शन और प्रतिष्ठा के साथ करें।
  

(अमान्य छवि और अनुपस्थित प्रोटोकॉल विनिर्देश के कारण URI

ईमेल लेआउट आवश्यकताओं

ईमेल बनाना इतना मुश्किल क्यों है?

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

• अलग सीमित फ्रेम,
  
• फ़िल्टरिंग टैग और / या विशेषताएँ,
  
• पूर्ण स्थिति पर प्रतिबंध,
  
• ब्लॉक शैलियों के उपयोग पर प्रतिबंध या प्रतिबंध (जो अनुकूली लेआउट के लिए महत्वपूर्ण है),
  
• बाह्य तत्वों को डिफ़ॉल्ट रूप से प्रतिबंधित करना (अर्थात बाहरी छवियों को डाउनलोड करने के लिए उपयोगकर्ता की अनुमति की आवश्यकता होती है) या उन्हें एक्सेस करने के लिए प्रॉक्सी का उपयोग करना,
  
• HTML ईमेल को किसी अन्य मध्यवर्ती प्रारूप में परिवर्तित करना (उदाहरण के लिए, Microsoft Exchange / Outlook RTF का उपयोग करता है, जो पारंपरिक तरीकों का उपयोग करके Outlook में तत्वों को ठीक से प्रदर्शित करना बहुत कठिन बना सकता है),
  
• रूपों या उनके व्यक्तिगत तत्वों के उपयोग पर प्रतिबंध या प्रतिबंध।
  

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

यहां तक ​​कि एक सही ढंग से बनाई गई ईमेल को अलग-अलग इंटरफेस में उनके कार्यान्वयन की ख़ासियत और ईमेल की सामग्री को फ़िल्टर करने के कारण अलग-अलग तरीके से प्रदर्शित किया जा सकता है।

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



निम्नलिखित बातों पर ध्यान देना आवश्यक है:

• शब्दार्थ सामग्री, प्रदर्शन, टाइपो की अनुपस्थिति, वाक्य रचना, वर्तनी और शाब्दिक त्रुटियों के लिए ईमेल के पाठ की जांच करें।
  
• ईमेल के टेम्प्लेट या लेआउट में एप्लिकेशन डेटा के प्रतिस्थापन की शुद्धता की जांच करें।
  
• अनुमत सीमा सीमाओं को ध्यान में रखते हुए, राशियों, तिथियों, संख्याओं, वस्तुओं की वस्तुओं और अन्य जानकारी की शुद्धता की जांच करें। तिथियां एक वर्ष होनी चाहिए (कुछ उपयोगकर्ता बॉक्स में बहुत कम ही दर्ज करते हैं)। एक समय क्षेत्र समय में मौजूद होना चाहिए। पते में एक शहर होना चाहिए, और कुछ मामलों में, देश को इंगित करना आवश्यक है।
  
• ईमेल में सभी लिंक की परिचालन स्थिति की जाँच करें, यदि कोई हो।
  
• पते की पुष्टि से पहले भेजे गए ईमेल में, incl। एक पुष्टिकरण लिंक के साथ ईमेल, बाहर से नियंत्रित कोई भी पाठ नहीं होना चाहिए, यहां तक ​​कि उपयोगकर्ता नाम भी, अन्यथा, उन्हें स्पैम के लिए उपयोग किया जा सकता है (ईमेल में प्रदर्शित फ़ील्ड में, उदाहरण के लिए, नाम में, स्पैम पाठ डाला जाता है और पता पीड़िता का संकेतित पता है)। उदाहरण के लिए, यदि आप अपनी सेवा की ओर से डेवलपर के पते पर एक अश्लील पाठ भेज सकते हैं, तो एक समस्या है।
  
• तृतीय-पक्ष सेवाओं पर बाहरी छवियों की अनुपस्थिति के लिए जाँच करें। यह वितरण और आपके ग्राहकों के बारे में जानकारी को प्रभावित कर सकता है।
  
• भेजने, वितरण, ईमेल पढ़ने, संक्रमण के लिए काउंटरों की उपलब्धता की जाँच करें। उनमें से कुछ ईमेल में ही स्थित हैं (उदाहरण के लिए, ईमेल पढ़ने के काउंटर-पिक्सेल), कुछ मेलर द्वारा ट्रैक किए जाते हैं, लेकिन, एक नियम के रूप में, सभी मेलर के व्यवस्थापक पैनल में उपलब्ध हैं।
  
• ईमेल में लिंक के माध्यम से सदस्यता श्रेणी की शुद्धता और इस श्रेणी के लिए उपयोगकर्ता की सदस्यता रद्द करें।
  
• यह देखें कि ईमेल कैसा दिखता है:
  
  • किसी लक्षित देश के लिए मेल के लोकप्रिय वेब संस्करण: रूस के लिए "बड़े तीन" मेल हैं। रु, यैंडेक्स, जीमेल। आप Rambler और Outlook.com भी जोड़ सकते हैं;
    
  • उपरोक्त ईमेल प्रदाताओं के मोबाइल एप्लिकेशन;
    
  • कम से कम iPhone, Pixel (Android संदर्भ प्लेटफ़ॉर्म), Samsung (Android के लिए सबसे आम), MIUI (Android प्लेटफ़ॉर्म के लिए रूस में दूसरा स्थान लेता है) के लिए, IMAP का उपयोग करते हुए मानक मोबाइल एप्लिकेशन लोकप्रिय मोबाइल प्लेटफार्मों को ध्यान में रखते हैं;
    
  • विभिन्न डेस्कटॉप ब्राउज़र: क्रोम, फ़ायरफ़ॉक्स, एज, इंटरनेट एक्सप्लोरर, ओपेरा, आदि;
    
  • डेस्कटॉप एप्लिकेशन (ईमेल प्रोग्राम), विशेष रूप से थंडरबर्ड, आउटलुक और एप्पल मेल, वैकल्पिक रूप से बैट! और ओपेरा मेल;
    
  • एक वेब इंटरफेस के साथ लोकप्रिय कॉर्पोरेट समाधान (एक्सचेंज, शायद राउंडक्यूब, कम्युनिटेज, जिम्ब्रा, स्क्विरमेल) - बी 2 बी समाधानों के लिए;
    
  • रेटिना मॉनिटर और मॉनिटर पर कम रिज़ॉल्यूशन के साथ लेआउट की जांच करना न भूलें।
    
• प्रत्येक मामले में जाँच के दौरान, आपको निम्न पर ध्यान देने की आवश्यकता है:
  
  • प्राधिकरण हेडर, SPF / DKIM / DMARC पास करना।
    
  • ईमेल डाउनलोड गति: इसे जल्दी से लोड करना चाहिए, और इसका समय नहीं लेना चाहिए।
    
  • ईमेल की सूची में एक ईमेल प्रदर्शित करना: अवतार, प्रेषक का नाम और वह विषय जो संदेश के स्निपेट में आता है, क्या इसकी श्रेणी को सही ढंग से परिभाषित किया गया था (उदाहरण के लिए, यदि ऑर्डर "सोशल नेटवर्क" श्रेणी में नहीं आता है)।
    
  • ईमेल का लेआउट एक पूरे के रूप में: यदि लेआउट लगातार बना रहा, तो क्या विंडो को स्केल करने और आकार बदलने सहित कोई गलत शब्द विराम आदि थे।
    
  • फ़ॉन्ट्स छोटा या पढ़ने में कठिन नहीं होना चाहिए।
    
  • पृष्ठभूमि छवियों और पृष्ठभूमि रंग।
    
  • ब्रांड बुक से मिलान।
    
  • ईमेल द्वारा निहित कार्यों को करने में आसानी। उदाहरण के लिए, यदि ईमेल में एक पुष्टिकरण कोड या अन्य जानकारी होती है, जिसे कहीं संग्रहीत करने की आवश्यकता हो सकती है, तो इसे न केवल अच्छी तरह से पढ़ा जाना चाहिए, बल्कि मोबाइल इंटरफ़ेस में भी इसे चुनना और कॉपी करना सुविधाजनक होना चाहिए।
    
  
  
• ईमेल के समग्र आकार (बाहरी छवियों सहित) पर नज़र रखें और यह उचित मूल्यों से अधिक नहीं है। भार समय जितना भारी होगा, उतनी ही अधिक संभावना होगी कि किसी व्यक्ति की उस पर नकारात्मक प्रतिक्रिया होगी।
  
• यहां तक ​​कि जिन ईमेलों में संशोधन नहीं किया गया है, उन्हें समय-समय पर जांचना चाहिए, क्योंकि परिवर्तन डाक सेवा की तरफ से हो सकते हैं, और, उदाहरण के लिए, एक पिछली अदृश्य समस्या को "प्रकट" करते हैं।
  
• कुछ मापदंडों को सभी परीक्षणों में नियंत्रित किया जाना चाहिए। उदाहरण के लिए, डीकेआईएम प्रमाणीकरण पारित करने में समस्याएं बुनियादी ढांचे में समस्या (डीएनएस के साथ समस्याएं या डीकेआईएम हस्ताक्षर के गठन, समय सिंक्रनाइज़ेशन त्रुटियों) के कारण हो सकती हैं, उत्पन्न होने वाले कार्यक्रम में त्रुटियों के कारण (प्रेषक पता गलत तरीके से बनाया गया है, गलत वर्ण में) हेडर गायब या अनिवार्य हैं, दिनांक, या संदेश-आईडी हेडर को डुप्लिकेट किया गया है) और सामग्री त्रुटियों के कारण (गलत लाइन टर्मिनेटर, लाइनें बहुत लंबी, गलत पते हैं)। उसी समय, ईमेल "बीट" नहीं कर सकता है, और समस्या किसी भी सेवा पर प्रकट नहीं हो सकती है।
  

स्प्लिट-टेस्ट का आयोजन

विपणन अनुसंधान इस लेख के दायरे से परे है, लेकिन कुछ प्रमुख बिंदु जो ईमेल की गुणवत्ता को महत्वपूर्ण रूप से प्रभावित करते हैं, उनका उल्लेख किया जाना चाहिए।

The newsletter has a purpose, so it should entail through its quality, not quantity (which is the opposite for spammers). The newsletter must be segmented. When conducting an advertising campaign, you need to know exactly who gets into the segment sample, why they need the offered product and what they want to convey.

For each mailing list, it is necessary to calculate the CTR of the list of emails — this is the ratio of the number of emails read to the total number that has been sent out. In postmaster.mail.ru, you can see indicators for unique users. If the measurement goes through the counter in the email (pixel), then the absolute number of openings is estimated. CTR <10% is a very low indicator, it is undesirable to carry out such mailing. It should strive for a CTR> 30%. For marketing emails, the clickthrough rate of clickthroughs and the percentage of completed actions («sales») on these links are also of great importance. Be sure to monitor complaints (marking the email as spam). Typically, for one-time mailings, a tenth of a percent is a good indicator, for regular ones, a hundredth of a percent. The critical values, after which the mailing is always interpreted as spam, are indicated here: https://help.mail.ru/developers/mailing_rules/technical .

It is necessary to conduct split testing of various distribution options to obtain optimal performance. Just changing the name of the sender and the subject of the email can increase the CTR by several times and significantly reduce the number of complaints. The number of emails should be statistically significant for evaluating the results (for large projects, usually a few thousand). The final version of the email is sent in several stages for additional measurement of indicators and «warming up» — starting with about 10,000 recipients, with an increase of about an order of the day.

The main idea: emails are part of your application, perhaps one of the most complex and problematic. At the same time, this is often a «blind spot» in terms of testing. I hope that I was able to draw your attention to this issue.

I would like to thank Vladimir Dubrovin ( z3apa3a ) and Alena Likhacheva ( s4ever ) for helping me with this article. As well as that, the article utilised sources of Eduard Tyantov ( edT ) and Alexander Purtov ( 4Alexander ).