ऐसा कोई कारण नहीं है कि आप इसे PHP में नहीं लिख सके, हालांकि मैं नहीं इसे वेबरेक्वेस्ट/एचटीटीपी प्रक्रिया का हिस्सा बनाएं। मैंने प्रति मेलिंग 500,000 ग्राहकों को देने या लेने के लिए सफलतापूर्वक कार्यान्वित किया है (उपलब्ध स्थानीय डेटा के आधार पर, क्योंकि यह एक स्थान-विशिष्ट परियोजना थी)। यह एक इन-हाउस प्रोजेक्ट था, इसलिए दुर्भाग्य से आपके लिए कोई कोड/पैकेज नहीं था, लेकिन कुछ संकेत मुझे मिले:
डिलीवरी सेट करना
- प्रारूपण, सामग्री और शीर्षलेखों की एन्कोडिंग, अनुलग्नकों को जोड़ने आदि का ध्यान रखने के लिए, phpmailer के साथ ही शुरू किया गया। इसका वह भाग अच्छी तरह से काम करता है, और मैं इसे खरोंच से नहीं लिखना चाहता।
- ईमेल का 'भेजना' केवल डेटाबेस में कुछ ध्वज सेट कर रहा है कि क्या ग्राहकों को (एक हिस्से) को/कैसे/क्या भेजा जाना चाहिए।
- इस ध्वज के सेट होने के बाद, यह स्वचालित रूप से एक cronjob द्वारा उठाया जाएगा, इसमें कोई और वेबसर्वर शामिल नहीं होगा।
- मैंने लाखों ईमेल पतों के साथ भारी प्रदूषित डेटाबेस के साथ शुरुआत की, जिनमें से एक बहुत स्पष्ट रूप से मान्य नहीं थे, इसलिए सबसे पहले सभी ईमेल पतों को प्रारूप के लिए मान्य करना था, फिर होस्ट के लिए:
filter_var($email, FILTER_VALIDATE_EMAIL);ग्राहकों से अधिक (और स्पष्ट रूप से परिणाम संग्रहीत करना) ने पहले कुछ लाख अमान्य ईमेल से छुटकारा पा लिया।- होस्ट को विभाजित करना (और संग्रहीत करना होस्ट नाम) ईमेल से, और इसे सत्यापित करना (क्या इसका DNS में MX या कम से कम A रिकॉर्ड है, लेकिन ध्यान रखें:आप किसी IP-पते पर ईमेल भेज सकते हैं
[email protected][255.255.255.255], इसलिए उन्हें मान्य रखें)) एक अच्छे हिस्से से अधिक छुटकारा पाया। यहां ईमेल पते नहीं हैं स्थायी रूप से अक्षम, लेकिन एक स्थिति ध्वज के साथ जो इंगित करता है कि वे डोमेन नाम / आईपी के कारण अक्षम हैं। - लिपियों को आवश्यकता . में बदल दिया गया सदस्यता पर / प्रविष्टि से पहले मान्य ईमेल पते, 'आपको example@ मिलने वाला है, की यह बकवास sqldat.com ' डेटाबेस में सदस्यता-प्रदूषण केवल हास्यास्पद था।
- अब मैं ईमेल पतों की एक सूची के साथ समाप्त हुआ जिसमें वैध होने की क्षमता थी। अमान्य पतों का पता लगाने के तीन तरीके हैं (ध्यान रखें, सभी अस्थायी हो सकता है):
- उन्हें सर्वर द्वारा तुरंत अस्वीकार कर दिया जाता है।
- पहले से निर्धारित सर्वर ट्रैफिक को नहीं सुनता।
- जब तक आपको लगा कि आपने उन्हें डिलीवर कर दिया है, तब तक वे बाउंस हो जाते हैं।
- अजीब बात, बाउंस, जिसके लिए प्रत्येक ईमेल सर्वर के पास एक और प्रारूप होता है और पहली बार में पार्स करने के लिए एक नरक था, वास्तव में VERP
. इसके बजाय पूरे ईमेल को पार्स करना, एक समर्पित ईमेल पता (चलिए इसे [email protected] कहते हैं। ए> ) को मेलबॉक्स में डिलीवर करने के लिए कॉन्फ़िगर किया गया था, इसे एक कमांड के माध्यम से पाइप करने के लिए, और यदि हमने [email protected]
,
Return-Path[email protected]. रसीद पर आसानी से पार्स किया गया, और कितने बाउंस के बाद (मेलबॉक्स मौजूद नहीं हो सका, मेलबॉक्स भरा हो सकता है (हाँ, अभी भी!), आदि) आप एक ईमेल पते को अनुपयोगी घोषित करते हैं। - अब, सर्वर द्वारा सीधे इनकार। संभवत:हम उन लोगों के लिए कुछ एमटीए और/या लिखने वाले प्लगइन्स को ठीक से कॉन्फ़िगर करने के साथ जा सकते थे, लेकिन चूंकि ईमेल समय-संवेदी थे, और हमें पिछले उपयोग योग्य डिलीवरी समय पर प्रति मेलिंग पूर्ण विन्यास योग्य नियंत्रण रखना था (जिसके बाद ईमेल लंबा नहीं था उपयोगकर्ता के लिए ब्याज की), प्रति प्राप्त सर्वर थ्रॉटलिंग, और आम तौर पर सब कुछ, PHP में एक मेलर लिखने में लगभग एक ही समय लगेगा, जिसे हम बेहतर जानते थे, जो सर्वर प्राप्त करने पर सीधे सॉकेट 25 में एसएमटीपी प्रोटोकॉल का उपयोग करता था। न्यूनतम प्रयास के साथ किसी अन्य परिवहन की संभावना के साथ PHPMailer में डिफ़ॉल्ट विकल्प अंतर्निहित थे। एसएमटीपी प्रोटोकॉल वास्तव में काफी सरल है, लेकिन कुछ चेतावनी हैं:
- बहुत से प्राप्त करने वाले सर्वर ग्रे लिस्टिंग लागू करते हैं:अधिकांश स्पैमबॉट वास्तव में परवाह नहीं करेंगे यदि कोई विशिष्ट मेल आता है, तो वे उन्हें निकाल देते हैं। इसलिए, यदि कोई अज्ञात / अभी तक विश्वसनीय प्रेषक मेल नहीं भेजता है, तो इसे अस्थायी रूप से अस्वीकार कर दिया जाएगा। उसे पकड़ें (आमतौर पर कोड 451), और बाद में पुन:प्रयास के लिए ईमेल को कतार में रखें।
- एक मेलसर्वर, विशेष रूप से बड़े आईएसपी और मुफ्त सेवाओं (जीमेल, हॉटमेल/एमएसएन/लाइव, आदि) के लिए बिना लड़े मेल की एक धार के लिए खड़ा नहीं होगा:सौ / हजार के पहले जोड़े के बाद, वे अस्वीकार करना शुरू कर देते हैं तुम। इसके बारे में बाद में।
गति प्राप्त करना
- अब, हमारे पास एक वितरण प्रणाली थी जो काम करती थी, लेकिन इसे तेज़ होना आवश्यक था . यदि आपके पास भेजने के लिए केवल 10,000 पते हैं, तो एक घंटे में 10,000 ईमेल भेजना ठीक है, लेकिन हमें कम से कम 200,000 प्रति घंटे की आवश्यकता थी। इसकी शुरुआत एक समर्पित सर्वर थी (जो वास्तव में बहुत कम शक्ति वाला हो सकता है, चाहे आप कुछ भी करें, ईमेल की डिलीवरी में लगने वाला अधिकांश समय नेटवर्क में होता है, आपके सर्वर पर नहीं)।
- आईपी का कैशिंग:उन सभी आईपी को याद रखें जिन्हें हमने ईमेल पतों में होस्टनाम से अनुरोध किया था? हमने उन्हें स्पष्ट रूप से संग्रहीत किया है, और उनके आईपी को बार-बार देखने से काफी अंतराल होता है। हालांकि, आईपी बदल सकते हैं:वहां एक डीएनएस रिकॉर्ड, दूसरी जगह पर एक और एमएक्स ... डेटा तेजी से पुराना हो जाता है। अधिकांश समय सर्वर वास्तव में कुछ भी नहीं भेज रहा है (सदस्यता न्यूज़लेटर्स स्पष्ट रूप से फट जाते हैं), एक कम प्राथमिकता वाला क्रोनजॉब एक आईपी पते के लिए सभी होस्टनामों की जांच कर रहा है (हमने पुराने के रूप में 1 दिन पुराना चुना है) , उनमें शामिल हैं जिनके पास पहले कोई नहीं था (नए डोमेन हर समय पंजीकृत होते हैं, तो किसी के द्वारा पहले ही उत्साहपूर्वक अपने ब्रांड के नए ईमेल पते के साथ सदस्यता लेने के अगले दिन डोमेन उपलब्ध क्यों नहीं होना चाहिए? या कुछ डोमेन के साथ सर्वर की समस्याएं हल हो जाती हैं, आदि)। वास्तव में ईमेल भेजने के लिए अब डोमेन लुकअप की आवश्यकता नहीं है।
- एसएमटीपी कनेक्शन का पुन:उपयोग:सर्वर से कनेक्शन सेट करने में अपेक्षाकृत अधिक समय लगता है जब आप सीधे पोर्ट 25 पर बात कर रहे हों तो ईमेल डिलीवर करने में समय लगता है। आपको प्रत्येक के लिए एक नया कनेक्शन सेटअप करने की आवश्यकता नहीं है ईमेल, आप बस उसी कनेक्शन पर अगला भेज सकते हैं। थोड़ी सी त्रुटि-और-त्रुटि के परिणामस्वरूप यहां डिफ़ॉल्ट को लगभग 50 ईमेल प्रति कनेक्शन पर सेट किया गया है (यह मानते हुए कि आपके पास डोमेन के लिए कई या अधिक हैं)। हालाँकि, एक ईमेल पते की विफलता पर पुनः प्रयास के लिए कनेक्शन को बंद करने और फिर से खोलने से कभी-कभी मदद मिलती है। कुल मिलाकर, यह वास्तव में चीजों को गति देने में मदद की।
- कुछ स्पष्ट, इतना स्पष्ट कि मैं इसका उल्लेख करना लगभग भूल गया:मौके पर ईमेल का मुख्य भाग बनाना बेकार होगा:यदि यह एक सामान्य मेल है, तो शरीर तैयार है (मैंने PHPMailer को कुछ हद तक बदल दिया है कैश्ड ईमेल का उपयोग करने में सक्षम हो), संभवतः कुछ दिन पहले (यदि आप जानते हैं आप शुक्रवार को एक मेल भेजने जा रहे हैं, और आपका सर्वर निष्क्रिय है, क्यों न उन्हें बुधवार को ही तैयार कर लिया जाए? यदि यह वैयक्तिकृत है, तो आप इसे पर्याप्त समय दिए जाने से पहले ही तैयार कर सकते हैं, यदि नहीं, तो कम से कम गैर-वैयक्तिकृत भागों के जाने का इंतज़ार करें।
- कई प्रक्रियाएं। क्या मैंने उल्लेख किया है कि ईमेल वितरित करने में लगने वाले समय का अधिकांश समय नेटवर्क पर खर्च होता है? एक मेलिंग प्रक्रिया आपके ईमेलसर्वर से लगभग सबसे अधिक प्राप्त नहीं कर रही है, मुश्किल से ध्यान देने योग्य भार और मेल छल कर रहे हैं। आपके सर्वर/कनेक्शन के लिए क्या सही है, यह देखने के लिए कतार के विभिन्न हिस्सों को मेल करने वाली कई प्रक्रियाओं के साथ खेलें, लेकिन 2 बहुत महत्वपूर्ण बातें याद रखें:
- विभिन्न प्रक्रियाएं आपको दौड़ की स्थितियों के प्रति बहुत संवेदनशील बनाती हैं:बिल्कुल निश्चित रहें आपके पास एक फुलप्रूफ सिस्टम है जो कभी नहीं एक ही मेल दो बार भेजें (तीन बार, और भी अधिक)। यह न केवल उपयोगकर्ताओं को गंभीर रूप से परेशान करता है, आपकी स्पैमिंग एक पायदान ऊपर जाती है।
- जहां संभव हो डोमेन को एक साथ रखें:कतार से बेतरतीब ढंग से चुनने पर आप डोमेन के लिए ईमेल प्राप्त करने वाले सर्वर से एक खुला कनेक्शन रखने का लाभ खो देंगे।
अस्वीकार करने से बचना
- आप बहुत सारी मेल भेजने जा रहे हैं। स्पैमर ठीक यही करते हैं। हालांकि, आप स्पैमर के रूप में नहीं दिखना चाहते हैं (आखिरकार, आप नहीं हैं, है ना)? कई तंत्र मौजूद हैं जो सर्वर प्राप्त करने के लिए आपकी विश्वसनीयता को पूरी तरह से बढ़ाएंगे:
- एक उचित रिवर्स डीएनएस है:आईपी से संबंधित डीएनएस की जांच करने वाली प्रक्रियाएं जो ईमेल भेज रही हैं बहुत यदि दूसरे स्तर के डोमेन मेल खाते हैं तो बहुत कुछ:क्या आप example.com . की ओर से मेल भेज रहे हैं? ? सुनिश्चित करें कि आपके सर्वर का रिवर्स डीएनएस कुछ इस तरह है somename.example.com ।
- अपने डोमेन के लिए एसपीएफ़ रिकॉर्ड प्रकाशित करें:स्पष्ट रूप से इंगित करें कि आपके बल्क ईमेल को भेजने के लिए उपयोग की जाने वाली मशीन को अनुमति दी गई है और उस से / रिटर्न-पाथ हेडर के साथ मेल भेजने की उम्मीद है।
- अस्वीकार करना याद रखें :सर्वर आपको बार-बार यह बताना पसंद नहीं करते कि अलग-अलग ईमेल पते मौजूद नहीं हैं। या तो स्वचालित तंत्र, और यहां तक कि मानव व्यवस्थापकों ने भी हमारे सर्वर को अवरुद्ध कर दिया, जबकि हमने उन सभी गैर-मान्य ईमेल पतों के माध्यम से काम किया जो (अब नहीं) मौजूद थे। हमने बाद में डबल ऑप्ट-इन का उपयोग नहीं किया था, इसलिए डेटाबेस टाइपो, आईपी स्विच करने वाले लोगों और इस तरह ईमेल पता, शरारत ईमेल पते आदि से प्रदूषित हो गया था। उन अमान्य को कैप्चर करना सुनिश्चित करें, और पर्याप्त या पर्याप्त विफलताओं को देखते हुए, उनकी सदस्यता समाप्त करें . वे आपका भला नहीं कर रहे हैं, वे संसाधनों का दोहन कर रहे हैं, और यदि वे वास्तव में आपको मेल चाहते हैं और मेलबॉक्स बाद में उपलब्ध हो जाता है, तो उन्हें बस फिर से सदस्यता लेनी होगी।
- DKIM एक अन्य तंत्र है जो आपकी विश्वसनीयता को बढ़ा सकता है, लेकिन जैसा कि हमने इसे (अभी तक) लागू नहीं किया है, मैं आपको इसके बारे में अधिक नहीं बता सकता।
- MX रिकॉर्ड:कुछ सर्वर अभी भी इसे पसंद करते हैं यदि आपका भेजने वाला सर्वर भी डोमेन के लिए प्राप्तकर्ता सर्वर है। जैसा कि उस समय था, हमारे पास केवल 1 एमएक्स था, और चूंकि मेलिंग सर्वर अभी भी बहुत व्यस्त नहीं था, इसलिए हमने इसे डोमेन के लिए फॉलबैक एमएक्स सर्वर करार दिया। सामान्य MX सर्वर नहीं था सर्वर सदस्यता भेज रहा है, क्योंकि यह उस सर्वर द्वारा अस्थायी रूप से अवरुद्ध होने के लिए बहुत परेशान है जिसे आप (क्लाइंट इत्यादि) को एक महत्वपूर्ण ईमेल भेजने का प्रयास कर रहे हैं क्योंकि आपने पहले ही कम महत्वपूर्ण मेल का भार भेजा है। एमएक्स प्राप्त करने के रूप में इसकी सर्वोच्च प्राथमिकता है, लेकिन अगर यह विफल हो जाता है तो हमारे पास अच्छा बोनस था कि हमारा सब्सक्रिप्शन भेजने वाला सर्वर अभी भी डिलीवरी के लिए वापस आ जाएगा, इसलिए संकट में हम अभी भी इसे प्राप्त कर सकते हैं, कोशिश कर रहे ग्राहकों को अजीब बाउंस को रोकना हम तक पहुँचने के लिए।
- उन्हें अपने बारे में बताएं। गंभीरता से। live.com जैसे मुफ्त ईमेल पतों में बहुत से प्रमुख खिलाड़ी आपको किसी तरह से साइन अप करने का अवसर प्रदान करते हैं, या यदि आपके ईमेल अस्वीकृत हो जाते हैं, तो सहायता और समर्थन के लिए संपर्क करने का अवसर प्रदान करते हैं। मेरे पास इतने सारे ईमेल भेजने का एक वैध कारण है, और यह विश्वसनीय है कि आपके पास कई ग्राहक हैं, संभावना है कि वे गंभीरता से उन ईमेल की संख्या को बढ़ा सकते हैं जिन्हें आप प्रति घंटे उनके सर्वर पर भेज सकते हैं। यदि आप पर्याप्त रूप से प्रेरक और ईमानदार हैं, तो दस-हजारों या उससे भी अधिक में एक मात्र 1,000 हो सकता है। अनुबंध, आवश्यकताएं हो सकती हैं जिन्हें आपको पूरा करना है, और वादे आपको इसकी अनुमति देने के लिए (और रखना) चाहिए। ISP एक अलग ब्रांड है, और हर दूसरा खिलाड़ी अलग है। उन्हें आमतौर पर कॉल करने की जहमत न उठाएं, क्योंकि 99% बार केवल वही नंबर मिल सकते हैं जो आपके इंटरनेट कनेक्शन की समस्या का निवारण करने के इच्छुक लोग होंगे, जो कुछ और समझते हैं (या अनुमति है)। एक
[email protected]ईमेल पता शुरू करने के लिए एक अच्छी जगह है, लेकिन देखें कि क्या आप कहीं से अधिक टू-द-पॉइंट ईमेल पते तक पहुंचा सकते हैं। सटीक, ईमानदार और पूर्ण रहें:मोटे तौर पर आपके कितने ग्राहकों के पास उस आईएसपी के साथ एक ईमेल पता है, आप उन्हें कितनी बार मेल करने का प्रयास कर रहे हैं, आपको कौन सी त्रुटियां या इनकार प्राप्त होते हैं, सदस्यता लेने और सदस्यता समाप्त करने की प्रक्रिया कैसी है, और क्या है वह सेवा जो आप वास्तव में उनके ग्राहकों को प्रदान करते हैं। इसके अलावा, अच्छा बनें:उन मेलों को भेजना आपके व्यवसाय के लिए कितना महत्वपूर्ण हो सकता है, इसके बारे में घबराना और भयानक नुकसान का दावा करना उनके लिए चिंता का विषय नहीं है। तथ्यों और इच्छाओं का विनम्र बयान, और पूछना क्या वे मदद कर सकते हैं बल्कि समाधान की मांग करना बहुत लंबा रास्ता तय करता है। - थ्रॉटलिंग:जितना आपने प्रयास किया, कुछ सर्वर आपसे प्रति घंटे और/या दिन में केवल एक निश्चित मात्रा में मेल स्वीकार करेंगे। उन नंबरों को जानें (हम वैसे भी सफलताओं और असफलताओं को लॉग कर रहे हैं), उन्हें सामान्य डोमेन के लिए एक उचित डिफ़ॉल्ट पर सेट करें, उन्हें बड़े खिलाड़ियों के लिए सीमा पर सहमत होने पर सेट करें।
स्पैम के रूप में टैग किए जाने से बचना
- पहला नियम:स्पैम न करें!
- दूसरा नियम:हमेशा! 'एक बार बंद' नहीं, 'उन्होंने सदस्यता नहीं ली है लेकिन यह उनके लिए जीवन भर का सौदा हो सकता है', सर्वोत्तम इरादे से नहीं, लोगों को आपके ईमेल मांगना पड़ा है।
- स्पष्ट रूप से एक सही डबल ऑप्ट-इन सदस्यता तंत्र सेट करें।
- PHPMailer अपने आप उचित शीर्षलेख सेट करता है,
- वेब द्वारा एक आसान अनसब्सक्राइब मैकेनिज्म सेट करें (इसमें हर में एक लिंक शामिल करें) मेल), संभवतः ईमेल और ग्राहक सेवा भी यदि आपके पास है। सुनिश्चित करें कि ग्राहक सेवा कर सकते हैं लोगों को सीधे सदस्यता समाप्त करें।
- जैसा कि पहले कहा गया था:सदस्यता समाप्त करें (अत्यधिक) विफल और बाउंस।
- अनचाहा 'डील ऑफ ए लाइफटाइम' शब्दों से बचें।
- अपने ईमेल में यूआरएल का कम से कम इस्तेमाल करें।
- अपने नियंत्रण से बाहर के डोमेन में लिंक जोड़ने से बचें, जब तक कि आप पूरी तरह सुनिश्चित न हों कि आप उन पर भरोसा कर सकते हैं उन पर स्पैम न करें, यदि तब भी...
- उपयोगकर्ता को मूल्य प्रदान करें:Google/याहू/लाइव वेबमेल क्लाइंट में उपयोगकर्ता-इंटरैक्शन द्वारा स्पैम के रूप में टैग किया जाना भविष्य की सफलताओं को गंभीर रूप से नुकसान पहुंचाता है (साइट नोट पर:यदि आप इसके लिए साइन अप करते हैं, तो लाइव/एमएसएन/हॉटमेल सभी को अग्रेषित करेगा आपको मेल आपके डोमेन द्वारा भेजा जाता है जिसे उपयोगकर्ताओं द्वारा स्पैम के रूप में टैग किया गया है। इसे प्यार करना सीखें, और हमेशा की तरह:उन्हें सदस्यता समाप्त करें, वे स्पष्ट रूप से आपका मॉल नहीं चाहते हैं और आपकी स्पैम रेटिंग को नुकसान पहुंचा रहे हैं)।
- अपने आईपी के लिए काली सूची की निगरानी करें। यदि आप उनमें से किसी एक पर दिखाई देते हैं, तो यह अलविदा है, इसलिए अपना नाम और साफ़ करते हुए तत्काल कार्रवाई करें मामले का निर्धारण आवश्यक है।
सफलता दर मापना
- आपके नियंत्रण में पूरी प्रक्रिया के साथ, आप निश्चित रूप से सुनिश्चित हैं कि ईमेल कहीं समाप्त हो गया है (हालाँकि यह MX का बिटबकेट या स्पैम फ़ोल्डर हो सकता है), या आपने विफलता दर्ज की है और इसका कारण क्या है। यह 'वास्तव में वितरित' संख्याओं का ध्यान रखता है।
- कुछ लोग आपके ईमेल में ऑनलाइन छवियों के लिंक जोड़ने के लिए आपको मनाने की कोशिश करेंगे (या तो वास्तविक या प्रसिद्ध 1x1 पारदर्शी gif) यह मापने के लिए कि कितने लोग वास्तव में आपका ईमेल पढ़ते हैं। चूंकि एक उच्च प्रतिशत उन छवियों को अवरुद्ध करता है, ये संख्याएं सबसे अच्छी तरह से अस्थिर होती हैं, और हमारा मानना है कि हमें उनसे परेशान नहीं होना चाहिए, उनकी संख्या पूरी तरह से अविश्वसनीय है।
- यदि आप चाहते हैं कि उपयोगकर्ता कुछ करें तो वास्तविक सफलता दर मापने के लिए आपका सर्वश्रेष्ठ दांव बहुत आसान है। मेल में लिंक में पैरामीटर जोड़ें, ताकि आप माप सकें कि आपके द्वारा लिंक की गई साइट पर कितने उपयोगकर्ता पहुंचे, क्या उन्होंने वांछित कार्य किए (वीडियो देखा, एक टिप्पणी छोड़ी, सामान खरीदा)।
कुल मिलाकर, सभी लॉगिंग के साथ, उपयोगकर्ता-इंटरफ़ेस, प्रति डोमेन/ईमेल/उपयोगकर्ता आदि कॉन्फ़िगर करने योग्य सेटिंग्स। विचित्रताओं को बनाने और आयरन करने में हमें लगभग 1,5 मानव-माह का समय लगा। ईमेल आउटसोर्सिंग की तुलना में यह काफी निवेश हो सकता है, ऐसा नहीं हो सकता है, यह सब वॉल्यूम और व्यवसाय पर ही निर्भर करता है।
अब, ज्वलन शुरू करें कि मैं PHP में एक एमटीए लिखने के लिए एक मूर्ख था, मैंने एक के लिए इसका पूरी तरह से आनंद लिया (यही कारण है कि मैंने इतनी बड़ी मात्रा में पाठ लिखा है), और अत्यंत बहुमुखी लॉगिंग और सेटिंग्स क्षमताएं, प्रति-होस्ट विफलता प्रतिशत आदि पर आधारित अलर्ट लाइव को इतना आसान बना रहे हैं;)
