Cum să măriți dimensiunea maximă a atașamentelor în Zimbra Webmail

Răspunsul scurt

Pentru Zimbra Webmail, modificarea unei singure setări poate să nu fie suficientă. Dacă utilizatorii trebuie să atașeze fișiere mai mari la mesajele trimise, coordonați limita de încărcare web, limita de conținut SOAP a cutiei poștale și limita de dimensiune totală a mesajelor a MTA. Verificați, de asemenea, dacă există o suprascriere specifică serverului sau un proxy extern care impune o limită de solicitări mai mică.

Ca exemplu practic, să presupunem că organizația dumneavoastră dorește ca utilizatorii să atașeze fișiere de până la 25 MiB. Recomandările Zimbra privind dimensiunea recomandă să se permită aproximativ 150% din dimensiunea fișierului original pentru mesajul complet codificat MIME. Un plafon de 40 MiB (41.943.040 octeți) este un exemplu de pornire rezonabil pentru această politică, sub rezerva testării și a capacității de stocare. Costul suplimentar MIME variază în funcție de mesaj, așadar niciun multiplicator nu garantează că fiecare mesaj se va potrivi.

Executați aceste comenzi în calitate de zimbrautilizator, după ce ați revizuit valorile curente și ați confirmat că politica exemplu se potrivește mediului dvs.:

su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize zimbraMtaMaxMessageSize

zmprov mcf zimbraFileUploadMaxSize 41943040
zmprov mcf zimbraMailContentMaxSize 41943040
zmprov mcf zimbraMtaMaxMessageSize 41943040
postfix reload

Aceste comenzi setează valori globale. Dacă un server de cutii poștale are propria suprascriere inferioară, verificați și ajustați și serverul respectiv. Atributele exacte și comportamentul de repornire pot varia în funcție de versiunea și implementarea Zimbra; verificați-le în raport cu versiunea instalată înainte de a aplica modificările pe scară largă.

De ce există mai mult de o limită

zimbraFileUploadMaxSizecontrolează încărcările de fișiere gestionate de Zimbra, inclusiv corpul cererii acceptat de proxy-ul web încorporat. Referința proxy a Zimbra mapează dimensiunea maximă a corpului atât pentru HTTP, cât și pentru HTTPS la acest atribut; o cerere care depășește limita proxy-ului poate primi HTTP 413. Într-o implementare cu mai multe cutii poștale, atributul poate fi setat global sau per server.

zimbraMailContentMaxSizecontrolează dimensiunea conținutului mesajului trimis prin interfața SOAP a căsuței poștale. zimbraMtaMaxMessageSizecontrolează mesajul complet maxim acceptat de MTA, care este Postfix într-o implementare Zimbra standard. Acest total include anteturile mesajelor și conținutul codificat MIME, nu doar fișierul original de pe disc.

Articolul din Centrul Tehnic Zimbra despre configurarea dimensiunii este marcat explicit ca fiind în lucru. Explicațiile și comenzile sale sunt utile, dar verificați definițiile atributelor și comportamentul pentru versiunea Zimbra instalată. Referințele sunt ghidul Zimbra pentru dimensiunea maximă a mesajului și referința variabilei proxy Zimbra .

Folosește setările care corespund erorii: un fișier respins imediat în timpul atașării punctelor mai întâi la o încărcare sau la o limită de proxy web. Un mesaj respins în timpul trimiterii sau livrării poate ajunge la MTA sau la serverul unui destinatar. O încărcare care funcționează, dar ulterior nu reușește să fie trimisă înseamnă că limita MTA sau extinderea MIME necesită încă atenție.

Alegeți o limită care se potrivește poliței dvs.

Setați o limită de business definită în loc să creșteți fiecare limită cât mai mult posibil. De exemplu, dacă utilizatorii ar trebui să atașeze fișiere de până la 25 MiB, exemplul de 40 MiB lasă loc pentru codificare și cheltuieli generale pentru mesaje. Zimbra observă că creșterea dimensiunii codificate nu este un procent fix și sugerează utilizarea a 150% ca ipoteză de planificare la estimarea limitelor de mesaje.

Mesajele mai mari utilizează mai mult spațiu de stocare în coadă, lățime de bandă și capacitate a cutiei poștale. Zimbra avertizează că o limită de dimensiune Postfix excesiv de mare poate cauza probleme de livrare a e-mailurilor atunci când partiția coadei nu are suficient spațiu liber. Atributele de dimensiune Zimbra foarte mari pot cauza, de asemenea, probleme de service în unele versiuni; Zimbra a documentat erori ale aplicației web și ale consolei de administrare după valori în afara intervalului. Măriți limitele în pași măsurați și testați rezultatul în loc să setați un plafon de mai mulți gigaocteți fără un plan de capacitate.

Verificați dacă există o suprascriere per server

Configurarea globală este convenabilă atunci când toate serverele de cutii poștale ar trebui să partajeze o singură politică. Cu toate acestea, o valoare la nivel de server poate suprascrie setarea globală. Verificați valorile globale și apoi gazda cutiei poștale care gestionează utilizatorul afectat:

su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize
zmprov gs mailbox1.example.com zimbraFileUploadMaxSize zimbraMailContentMaxSize

Înlocuiți mailbox1.example.comcu numele serverului de cutii poștale. Dacă are o valoare specifică serverului mai mică și politica dvs. permite dimensiunea mai mare, actualizați gazda respectivă:

zmprov ms mailbox1.example.com zimbraFileUploadMaxSize 41943040
zmprov ms mailbox1.example.com zimbraMailContentMaxSize 41943040

Repetați doar pentru gazdele de cutii poștale care necesită modificarea. Nu presupuneți că modificarea configurației globale elimină suprascrierile existente ale serverului. Într-un mediu cu mai multe servere, verificați fiecare nod de cutie poștală aplicabil și fiecare MTA.

Confirmați că limita MTA a intrat în vigoare

După modificarea atributului MTA global și reîncărcarea Postfix, verificați valoarea Postfix efectivă pe fiecare MTA Zimbra:

su - zimbra
zmprov gcf zimbraMtaMaxMessageSize
postconf message_size_limit

Cele două rezultate ar trebui să coincidă în octeți. Dacă atributul LDAP este corect, dar postconfîncă arată limita veche, verificați procesul de configurare și jurnalele Zimbra MTA înainte de a încerca o repornire completă. O repornire poate întrerupe serviciile de e-mail, așadar programați una doar atunci când este necesar de versiunea instalată și de topologia de implementare.

Proxy-ul Zimbra își construiește limita corpului cererii HTTP de la zimbraFileUploadMaxSize. Dacă mediul dvs. plasează și un dispozitiv separat Nginx, Apache, cloud gateway sau securitate în fața Zimbra, acea componentă poate avea propria limită de încărcare. Un răspuns 413 sau o intrare în jurnalul proxy este un indiciu pentru a verifica limita corpului cererii pe stratul care a returnat eroarea. Evitați editarea directă a fișierelor proxy generate de Zimbra; faceți modificări prin setările Zimbra acceptate și utilizați procedura de regenerare sau repornire a configurației documentată pentru versiunea dvs.

Test cu un mesaj controlat

1. Folosește o cutie poștală de testare și un fișier puțin sub limita de atașamente dorită. Nu începe cu cel mai mare fișier pe care sistemul îl poate accepta.
2. Atașați fișierul în Zimbra Webmail. Dacă browserul raportează că încărcarea este prea mare, verificați zimbraFileUploadMaxSize, suprascrierile serverului de cutie poștală și limitele proxy.
3. Trimiteți mesajul către o altă cutie poștală de testare internă. Dacă încărcarea reușește, dar trimiterea eșuează, verificați limita SOAP și limita MTA a cutiei poștale.
4. Verificați textul și jurnalele de respingere. Ghidul MTA al Zimbra arată că Postfix respinge un mesaj supradimensionat cu o eroare de dimensiune 552 și recomandă verificarea /var/log/zimbra.logevenimentelor de respingere, depășire, limită sau avertizare.
5. Dacă livrarea internă funcționează, dar un destinatar extern respinge mesajul, verificați limita de dimensiune anunțată sau documentată de destinatar. Setările Zimbra nu pot ridica o limită pe un alt sistem de e-mail.

Pentru mesajele SMTP de ieșire, Postfix poate să își anunțe dimensiunea acceptată în cadrul capabilității SMTP SIZE. Un server de mail la distanță poate anunța o valoare mai mică sau poate respinge mesajul după ce Zimbra îl trimite. Articolul de depanare Zimbra explică cum se distinge o respingere MTA locală de o respingere din partea destinatarului. Consultați referința parametrilor de dimensiune a mesajului Postfix și exemplele de depanare a dimensiunii MTA Zimbra .

Când să utilizați în schimb un link de partajare a fișierelor

Limitele atașamentelor de e-mail nu reprezintă o modalitate fiabilă de a distribui fișiere media foarte mari, imagini de disc sau arhive de proiecte. Sistemul de e-mail al fiecărui destinatar poate impune o limită totală de mesaje diferită, iar mesajele codificate sunt mai mari decât atașamentele lor originale. Dacă o limită mai mare ar suprasolicita spațiul de stocare sau capacitatea cozii, partajați fișierul printr-un serviciu de partajare a fișierelor aprobat și trimiteți prin e-mail un link controlat prin permisiuni.

Modificarea are succes atunci când un fișier de test din cadrul noii politici se încarcă, se trimite și sosește pentru un destinatar intern, în timp ce Postfix raportează valoarea dorită a dimensiunii mesajului. Dacă doar anumiți utilizatori sau noduri de server încă eșuează, comparați suprascrierile serverului de cutie poștală și ruta proxy. Dacă doar destinatarii externi resping e-mailurile, confirmați limita lor înainte de a crește din nou limitele Zimbra.