मुझे SMTP सर्वर की आवश्यकता क्यों है?


92

मुझे मेल भेजने के लिए एक मध्यवर्ती SMTP सर्वर की आवश्यकता क्यों है? मेरा ग्राहक (आउटलुक, थंडरबर्ड) प्राप्तकर्ता के SMTP डोमेन पर सीधे संदेश क्यों नहीं भेज सकता है?

उदाहरण के लिए, अगर मुझे address@example.comअपने जीमेल खाते के साथ एक ईमेल भेजना है, तो मैं इसे smtp.gmail.comसर्वर पर भेज देता हूं ; और फिर यह सर्वर मेरे संदेश को एमएक्स सर्वर पर भेज देगा example.com


जवाबों:


114

आपके कंप्यूटर से प्राप्तकर्ता के SMTP सर्वर पर सीधे ईमेल भेजना तकनीकी रूप से संभव है।

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

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

लेकिन यह खराब हो जाता है- स्पैमर । अधिकांश ईमेल (80% से अधिक) स्पैम हैं। इसलिए मेल प्रदाता इस समस्या को कम करने के लिए जो कुछ भी कर सकते हैं, करते हैं - और बड़ी संख्या में तकनीकें ईमेल वितरित करने के तरीके के बारे में धारणा बनाती हैं - निम्नलिखित महत्वपूर्ण विचार हैं:

  1. Greylisting: कुछ प्रदाता स्वचालित रूप से एक मेल कनेक्शन छोड़ देंगे यदि प्रेषक और प्राप्तकर्ता ने पहले संचार नहीं किया है, और उनसे दूसरी बार कोशिश करने की उम्मीद करते हैं- क्योंकि स्पैमर्स अक्सर नहीं करते हैं, जबकि एसएमटीपी सर्वर हमेशा माना जाता है। यह स्पैम वॉल्यूम को लगभग 80% कम कर देता है। यह हालांकि यह करने के लिए बेकार है।

  2. प्रतिष्ठा: यह बहुत अधिक संभावना है कि कोई व्यक्ति किसी प्रतिष्ठित, ज्ञात एसएमटीपी सर्वर के माध्यम से ईमेल भेज रहा है, जो फ्लाई-नाइट नाइट सर्वर की तुलना में वैध है। प्रतिष्ठा पाने के लिए, प्रदाता कई काम करते हैं:

    1. डायनेमिक / क्लाइंट एड्रेस (100% नहीं, लेकिन इंटरनेट के बड़े हिस्से को मैप किया गया है) ब्लॉक करें

    2. यह देखें कि रिवर्स DNS, आगे के DNS से ​​मेल खाता है: करने के लिए बहुत कठिन नहीं है, लेकिन कुछ व्यवहार्यता और सर्वोत्तम प्रथाओं के ज्ञान का स्तर दिखाता है - और बहुत से क्लाइंट पता ब्लॉक नहीं हैं।

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

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

संभवतः अन्य छोटी चिंताएँ हैं, लेकिन ये प्रमुख होंगी।


19
इस तरह भूल मत बिल्कुल मामूली एसपीएफ़ के रूप में चीजों को और DKIM (डिजिटल डोमेन स्तर पर संदेशों पर हस्ताक्षर) (क डोमेन के लिए मेल भेजने की अनुमति सेनाओं के श्वेतसूचीकरण) - विशेष रूप से बाद केवल एक समर्पित रिले के साथ संभव है।
ग्रैविटी

@ ग्रेविटी निश्चित रूप से ध्यान देने योग्य है, लेकिन समर्पित रिले के बिना DKIM "संभव" क्यों नहीं है? DKIM चयनकर्ता आवेदन भेजने या आईपी पते के लिए बाध्य नहीं हैं। यदि आपका मेल क्लाइंट प्रकाशित कुंजी के साथ संदेश पर हस्ताक्षर कर सकता है तो यह किसी अन्य हस्ताक्षरकर्ता के रूप में मान्य है।
मैथियास आर जेसेन

2
@ मैनुह: ठीक उत्तर में मेट्रिक्स के अनुसार, सामान्य मेल मेल वॉल्यूम के 1/5 से समझौता करता है। मेरे सर्वर पर मीट्रिक के अनुसार , सामान्य मेल 1/20 मेल वॉल्यूम से समझौता करता है। यह एक शानदार व्यापार है।
dotancohen

1
@manuh: ईमेल भेजने से पहले कंसीवेशन बंद करके ग्रीलिस्टिंग कार्य करता है - यह केवल तब तक सुनता है जब तक यह प्रेषक और प्राप्तकर्ता को प्राप्त नहीं हो जाता है - जो कि हैडर में हैं। इसके अलावा, कुछ स्त्रीरोग विशेषज्ञ प्रणाली को जल्द ही छोड़ देंगे। एक smtp सर्वर से सभी ईमेल को स्वीकार करें जिसमें डिलीवरी का इतिहास है। अफसोस की बात है, यह बहुत प्रभावी है।
दाविदगो

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

32

मुझे मेल भेजने के लिए एक मध्यवर्ती SMTP सर्वर की आवश्यकता क्यों है? मेरा ग्राहक (आउटलुक, थंडरबर्ड) प्राप्तकर्ता के SMTP डोमेन पर सीधे संदेश क्यों नहीं भेज सकता है?

1991 में - और 1990 के दशक के अधिकांश समय में और इससे भी पहले-आप जो वर्णन करते हैं, वह करने में सक्षम हो सकते हैं। लेकिन 2015 में वास्तविकता यह है, जबकि कोई भी तकनीकी रूप से किसी भी मशीन से किसी को भी एक ईमेल भेज सकता है जिस पर एक मेल सेवा स्थापित है, SPAM की दुनिया ने उस पद्धति को प्रभावी रूप से बेकार बना दिया है।

जब आप "वास्तविक" SMTP सेवा का उपयोग करते हैं, तो चीजें PTR रिकॉर्ड्स, SPF रिकॉर्ड और यहां तक ​​कि DomainKeys की तरह सेट की जाती हैं, जो केवल एक उद्देश्य और एक उद्देश्य के लिए स्थापित की जाती हैं: संदेश भेजने वाला SMTP वैध है। और अगर यह नहीं है? एक स्पैम फ़ोल्डर या "महान रसातल" को हटाने के लिए संदेश को फ़िल्टर करें। यहाँ उन वस्तुओं में से प्रत्येक का एक टूटना है:

  • PTR (पॉइंटर रिकॉर्ड / रिवर्स DNS रिकॉर्ड): सर्वर स्तर सत्यापन। जैसा कि यहां बताया गया है , एक पीटीआर रिकॉर्ड का उपयोग नेटवर्क इंटरफ़ेस (आईपी) को होस्ट नाम पर मैप करने के लिए किया जाता है। मतलब अगर आपके पास 123.456.789.0अपने SMTP सर्वर पर ईमेल भेजने का पता है smtp.example.comतो उसके लिए एक उपयुक्त PTR रिकॉर्ड होगा smtp.example.com। बहुत सरल लगता है, लेकिन यह केवल उसी के साथ काम करता है जो वास्तव में एक पीटीआर रिकॉर्ड सेट कर सकता है वह आईपी पते का मालिक है और यह केवल उनके हार्डवेयर पर सेट किया जा सकता है। इसलिए यह उस आईपी पते के मालिक / चलाता / प्रबंधित करने की दिशा में एक सत्यापन बिंदु के रूप में कार्य करता है।

  • एसपीएफ (सेंडर पॉलिसी फ्रेमवर्क): होस्टनाम डीएनएस प्रवेश स्तर का सत्यापन। एक एसपीएफ रिकॉर्ड- जैसा कि यहां बताया गया है- मूल रूप से डोमेन नाम धारक द्वारा निर्धारित एक DNS रिकॉर्ड है जो उस डोमेन नाम के लिए ईमेल भेजने की अनुमति देने वाले सर्वरों के आईपी पते और होस्टनाम की एक सूची प्रदान करता है। यह फिर से एक और सत्यापन कदम है जो यह सुनिश्चित करता है कि एसएमटीपी सर्वर के लिए केवल सही डोमेन नाम मालिक ही मेल भेज सकता है। तो मान लीजिए कि IP पते वाला एक सर्वर 123.456.789.9ईमेल भेज रहा है example.com। हम पहले से ही जानते हैं कि smtp.example.comउपयोग करता है 123.456.789.0, लेकिन example.comराज्य के लिए एक एसपीएफ़ रिकॉर्ड प्रविष्टि , "अरे! 123.456.789.9एक अच्छा सर्वर है! वह वैध है! उसके ईमेल का सम्मान करें! ”

  • DKIM (DomainKeys आइडेंटिफाईड मेल): ईमेल संदेश स्तर सत्यापन। जैसा कि यहां और विकिपीडिया पर समझाया गया है , “DKIM एक ईमेल सत्यापन प्रणाली है जो ईमेल एक्सचेंजर्स को ईमेल स्पूफर्स का पता लगाने के लिए एक तंत्र प्रदान करके बनाया गया है ताकि यह जांचा जा सके कि किसी डोमेन से आने वाले मेल को उस डोमेन के व्यवस्थापक और ईमेल (अधिकृतों) द्वारा अधिकृत किया गया है। परिवहन के दौरान संशोधित नहीं किया गया है। ”क्रिप्टोग्राफिक हैश का उपयोग करके, DKIM सत्यापित करता है कि पारगमन के दौरान मेल को फ़िल्टर या छेड़छाड़ नहीं किया गया था। यह "क्या आप वैध हैं या आप स्पैम हैं?" श्रृंखला में अभी तक एक और सत्यापन बिंदु के रूप में कार्य करता है।

इसलिए अंत में, किसी भी चीज़ के लायक एक सार्वजनिक-सामना करने वाला SMTP सर्वर, इनमें से कम से कम दो आइटम (PTR और SPF) यह सत्यापित करने के लिए सेट होगा कि SMTP सर्वर और संबंधित ईमेल वैध हैं। हर कोई DKIM का उपयोग नहीं करता है, लेकिन मान्यता की एक और परत है जो आजकल तेजी से लोकप्रिय हो रही है क्योंकि SPAMERS SPAM भेजने के अपने प्रयासों में अधिक दृढ़ हो जाते हैं।


15

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


आप लिखते हैं "अधिकांश आवासीय आईएसपी टीसीपी पोर्ट 25 (एसएमटीपी) को ब्लॉक करते हैं" <- क्या आप इसका मतलब विस्तृत कर सकते हैं। क्या आपका मतलब है कि वे आपको पोर्ट 25 पर एसएमटीपी सर्वर के लिए एक आउटगोइंग कनेक्शन नहीं करने देंगे? या क्या आपका मतलब है कि वे आपको पोर्ट 25 पर कनेक्शन प्राप्त नहीं करने देंगे?
बार्लोप

2
पूर्व में @barlop - वे अपने स्वयं के मेल सर्वर (या वास्तव में कहीं भी, क्योंकि वे अपने स्वयं के सर्वर के लिए 587 या 465 का उपयोग कर सकते हैं) के अलावा अन्य आवासीय कनेक्शनों से आउटगोइंग कनेक्शनों को मशीनों पर ब्लॉक करते हैं। हालाँकि, यह कुछ हद तक अतिशयोक्ति है कि अधिकांश आईएसपी इसे करते हैं।
हॉब्स

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

3
@ होब्स, मैंने कभी नहीं लिखा कि ज्यादातर आईएसपी ऐसा करते हैं; मैंने जो लिखा है कि अधिकांश आवासीय आईएसपी ऐसा करते हैं। उदाहरण के लिए, AT & T, Comcast, TWC, Verizon, आदि अपने आवासीय ग्राहकों के लिए ऐसा करते हैं, लेकिन वे अपने व्यावसायिक ग्राहकों के लिए ऐसा नहीं करते हैं।
रॉन मौपिन

6

अन्य उत्तर सभी उत्कृष्ट हैं, और स्पैम के पास बहुत कुछ है।

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

उदाहरण के लिए, यहां तक ​​कि सबसे बुनियादी पर, एक "वास्तविक" एसएमटीपी सर्वर को कम से कम एमएक्स रिकॉर्ड को हल करने में सक्षम होना चाहिए। फिर उसे फीचर्स (ज्यादातर टीएलएस, लेकिन अन्य फीचर्स भी हैं) पर बातचीत करनी होगी। इसे पुनः प्राप्ति के लिए कतारों का प्रबंधन करना है, गैर-वितरण रिपोर्ट तैयार करना, आदि।

और यह सिर्फ बुनियादी, होना चाहिए, कार्यक्षमता जिसके बिना सर्वर भी काम नहीं करेगा। इसमें एड्रेस री राइटिंग, mailertables जैसी चीजें भी शामिल नहीं हैं। दर्जनों या इतने अन्य प्रोटोकॉल का उल्लेख नहीं है जो UUCP जैसे एटम समर्थन को भेजते हैं।

आउटलुक, थंडरबर्ड आदि में एसएमटीपी कार्यान्वयन बहुत कम से कम है - सबसे अच्छा, मोटे तौर पर सेंडमेल पर स्मार्ट होस्ट का उपयोग करने के बराबर, यदि ऐसा है।

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


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

4

मुझे मेल भेजने के लिए एक मध्यवर्ती SMTP सर्वर की आवश्यकता क्यों है? मेरा ग्राहक (आउटलुक, थंडरबर्ड) प्राप्तकर्ता के SMTP डोमेन पर सीधे संदेश क्यों नहीं भेज सकता है?

आप ऐसा करने वाला एक ईमेल प्रोग्राम बना सकते हैं, और मुझे इसमें कोई संदेह नहीं है कि दूसरों ने भी किया है (या प्रयास किया है) इससे पहले भी।

आप अनिवार्य रूप से एक उपकरण लिख रहे होंगे जो एक में एक MUA (मेल उपयोगकर्ता एजेंट) और MTA (मेल ट्रांसफर एजेंट) दोनों है।

इसका कारण यह है कि यह पारंपरिक रूप से विभिन्न उपकरणों में अलग हो गया है, एमटीए "सर्वर-साइड" के साथ, यह है कि एक एमटीए जो खुले इंटरनेट के माध्यम से मेल भेजता है लिखने और कॉन्फ़िगर करने के लिए काफी अधिक जटिल है, और यह भी कि यह एक पर रहने से लाभ होता है विश्वसनीय "हमेशा" सर्वर पर।

एक एमटीए है:

  • ऊपर देखें और उन सर्वरों से कनेक्ट करें जिन पर भरोसा नहीं है, या जो दुर्व्यवहार कर सकते हैं, और त्रुटि स्थितियों से एक समझदार तरीके से निपट सकते हैं जो मेल नहीं खोते हैं।

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

  • विभिन्न सर्वर क्षमताओं की एक श्रृंखला के साथ व्यवहार करें, प्राप्त सर्वर की क्षमताओं के अनुसार व्यवहार को समायोजित करें।

  • उपयोगकर्ता को त्रुटि स्थितियों के बारे में रिपोर्ट करें या जब मेल अपरिवर्तनीय हो, तो यह कि मेल अभी खो नहीं है।

  • उत्कृष्ट सुरक्षा प्रथाएँ हों और बहुत सुरक्षा के प्रति सचेत रहें।

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

इन आवश्यकताओं को देखते हुए, यह SMTP सर्वर को सार्वजनिक रूप से हमेशा ऑन-ऑन सर्वर पर कहीं न कहीं, और उस विशेष कार्य को करने के लिए अनुकूल टूल का उपयोग करने और उपयोग करने के लिए समझ में आता है।


1

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

जीमेल, आउटलुक 365 और याहू मेल उन ईमेल सेवाओं के उदाहरण हैं जिनका उपयोग ईमेल भेजने वाले व्यक्तियों द्वारा किया जाता है। वाणिज्यिक ईमेल भेजने के लिए, MailChimp, Marketo और Eloqua जैसी सेवाएँ हैं जो किसी कंपनी के लिए बड़े पैमाने पर ईमेल भेजने और बाउंस, थ्रॉटलिंग और डिलिवरेबिलिटी जैसी चीजों को संभालने में बहुत अच्छी हैं।

देखें: https://en.m.wikipedia.org/wiki/Bounce_address


मुझे समझ नहीं आ रहा है कि मुझे अपना उत्तर पाने के लिए एक स्थिर आईपी की आवश्यकता क्यों है ... उत्तर को मेरे कंप्यूटर पर नहीं अपने MX सर्वर (उदा। जीमेल) पर पहुंचाया जाना चाहिए। क्या मैं सही हू?
तोबिया

हाँ आप सही हैं। मुझे लगता है कि मेरी बात यह है कि आउटगोइंग ईमेल भेजने के लिए एक इनबॉक्स आमतौर पर एक सर्वर पर मौजूद होता है। तार्किक रूप से, यह उस सर्वर के लिए आउटगोइंग ईमेल को भी संभालने के लिए समझ में आता है। अन्यथा आप "भेजे गए" ईमेल फ़ोल्डर जैसी चीजों को खो देंगे।
दान

यह उचित है। लेकिन मैं अपने smtp सर्वर को एकजुट करते हुए Gmail से एक अज्ञात "से" या "उत्तर" पते के साथ एक संदेश भेजने के लिए स्वतंत्र हूं ...
Tobia

1
यदि आप GMail का उपयोग करते हैं, तो आपको smtp प्रमाणीकरण का उपयोग करना होगा। तो, FROM पता आपके @ gmail.com पते पर सेट है। अन्यथा, आप स्पूफिंग के लिए उनकी सेवा का उपयोग करने में सक्षम होंगे।
दाना

2
इन दिनों, बहुत से उपयोगकर्ता बाउंस के बारे में कम परवाह नहीं कर सकते थे, लेकिन एक सेटअप जो बाउंस स्वीकार नहीं करेगा, आमतौर पर एक संभावित स्पैम स्रोत माना जाता है।
रैकैंडबॉमन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.