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

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

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

उदाहरण के लिए हमारे पास एक पता [email protected] है। info हमारे मुख्य मेल सर्वर पर एक समूह के रूप में कॉन्फ़िगर किया गया है; इस समूह में एक संग्रह है जो प्रत्येक आने वाली मेल की एक प्रति संग्रहीत करता है, और इसके सदस्य हैं (उदाहरण martin.von.wittich ), और समूह के प्रत्येक सदस्य को अपने इनबॉक्स में भी एक प्रति प्राप्त होती है। वर्तमान में हम अभी भी कायाको को अपनी टिकट प्रणाली के रूप में उपयोग कर रहे हैं, और कायाको को /etc/aliases माध्यम से एक प्रति प्राप्त होती है:

info:        \info,          [email protected]

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

TLDR: मुझे यह पसंद है जिस तरह से यह वर्तमान में काम करता है :)

मैं मार्टिंस के तर्क को समझ सकता हूं।
हमें कम से कम निगरानी में एक जानकारी जोड़नी चाहिए, अन्यथा आप इसकी सफाई से निगरानी नहीं कर सकते हैं!

स्वतः उत्तर को सक्षम/अक्षम करने का विकल्प एक अच्छा विचार है - मैं इसे सेटिंग्स के अंदर देखूंगा और विज़ार्ड के भीतर व्यवस्थापक से पूछूंगा कि वह इसे कैसे पसंद करेगा। कारण यह है कि, मैं व्यक्तिगत रूप से ज़माद को डिफ़ॉल्ट रूप से ऑटो उत्तर देना पसंद करूंगा।

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

आप देखिए, यह थोड़ा जटिल है ^^"

इसे अब Zammad 3.2 के लिए लागू किया गया है।

1) अपग्रेड इंस्टॉलेशन पर अन्य व्यवहार नहीं होगा जैसा कि अभी है। Zammad मॉनिटरिंग एंडपॉइंट में केवल बहुत बड़े ईमेल दिखाए जाते हैं।

यदि आप अभी व्यवहार करना चाहते हैं, तो व्यवस्थापक करें -> चैनल -> ई-मेल -> सेटिंग्स और "पोस्टमास्टर मेल भेजें यदि मेल बहुत बड़ा है" बदलें

2) नए सेटअप में या यदि "पोस्टमास्टर मेल भेजें यदि मेल बहुत बड़ा है" सत्य पर सेट है, तो प्रेषक को एक ईमेल संदेश भेजा जाता है कि मेल बड़ा है (यह कितना बड़ा था और अधिकतम क्या है) और यह था पहुंचाने में सक्षम नहीं है।