En afvisning af meddelelsesstørrelse kan ske, før den modtagende server evaluerer al meddelelsesgodkendelse. Det kan også vises efter en upstream-server har accepteret en besked, og et senere hop anvender en mindre grænse. Diagnostiser størrelsestilstanden ved det afvisende humle i stedet for at behandle enhver permanent afvisning som en SPF, DKIM eller DMARC defekt.
Skelne størrelse fra politik og opbevaring
RFC 3463 definerer X.3.4 som en besked for stor til det modtagende system og X.2.3 som en beskedlængde, der overstiger en administrativ grænse for postkassen. Disse adskiller sig fra X.2.2 postkasse fuld. Læs hele diagnosticeringen, fordi produkter kan tilføje deres egne grænser, enheder og forklarende ordlyd. En generisk "552" etiket alene etablerer ikke den nøjagtige konfigurerede begrænsning. RFC 3463 afsnit 3.3 og 3.4.
Godkendelsesfejl vedrører identiteter, signaturer eller politik snarere end antallet af meddelelsesoktetter. Reduktion af størrelse er ikke en DKIM reparation; ændring af signeret indhold kan i sig selv ugyldiggøre en signatur, så en autoriseret erstatning skal passere gennem den normale signeringsworkflow. Omvendt øger godkendelse af en anden IP i SPF ikke en modtagers tilladte beskedstørrelse. Hold de to undersøgelser adskilt, medmindre uafhængige beviser viser, at begge fejler.
Læs den annoncerede SIZE-funktion korrekt
SMTP SIZE-udvidelsen lader en server annoncere support og eventuelt en maksimal meddelelsesstørrelse i dens EHLO svar. En støttende kunde kan levere en estimeret størrelse med MAIL FRA, hvilket tillader afvisning, før hele beskeden sendes. STØRRELSE uden et nummer giver ingen fast-maksimal information; STØRRELSE 0 angiver eksplicit, at der ikke er et fast maksimum i kraft. Ingen af dem garanterer accept. Senere forarbejdning og anden humle kan stadig pålægge begrænsninger. RFC 1870 sektion 3 og 4.
For RFC 1870 SIZE, tæl meddelelsesoktetter inklusive CRLF-linjeafslutninger, overskrifter, MIME struktur og kodet indhold, men ekskluder DATA-terminerende prik og ekstra dot-stuffing-bytes. Tæl ikke kun den vedhæftede fil. Base64-kodning udvider binære data, og linjeskift og omgivende meddelelsesdele tilføjer flere bytes. Se RFC 2045 afsnit 6.8. Udbydergrænseflader kan vise afrundede enheder anderledes. Registrer de målte oktetter og den nøjagtige annoncerede eller dokumenterede grænse i stedet for at sammenligne to uforklarlige "MB"-etiketter.
Sammenlign kontrollerede varianter
Opret to autoriserede varianter, der kun adskiller sig i det størrelsesrelevante indhold. Bevar de mindre og større serialiserede størrelser og SMTP stadiet for hvert resultat. Et illustrativt par kunne indeholde den samme korte forklarende tekst, med en stor vedhæftet fil erstattet af et godkendt adgangskontrolleret fillink. Antag ikke, at et fillink er egnet til fortroligt materiale, eller at modtageren har adgang.
RFC 5321 afsnit 4.5.3.1 .7 kræver understøttelse af en meddelelsesstørrelse på mindst 64K oktetter, inklusive overskrifter. Den følgende grænse på 100.000 oktet er over dette protokolminimum, ikke en anbefalet udbyderindstilling.
For en hypotetisk aritmetisk kontrol, antag, at det samme slutpunkt annoncerer STØRRELSE 100.000. En antaget 115.900 oktet besked overskrider denne grænse med 15.900 oktetter; en antaget 20.100 oktet erstatning er 79.900 oktetter under den. Den første kan afvises på MAIL FRA; den anden er berettiget til yderligere behandling, men er ikke garanteret accept. Disse tal er opfundet, ikke målinger eller udførte SMTP resultater. De beskriver ikke nogen udbyders tilknytningsloft.
Reparer den snævreste relevante begrænsning
Spørg ejeren af det afvisende system, om størrelsen er en bevidst servicegrænse eller en organisationsstyret indstilling. Hvis virksomhedens behov kan opfyldes med en mindre fil, så brug den rute i stedet for at hæve grænserne på tværs af hele mailsystemet. Hvis en grænseændring er godkendt, skal du overveje ressourceforbrug, malware-scanning og downstream-kompatibilitet, før du anvender den.
Bliv ikke ved med at prøve det samme permanent afviste indhold uændret. Bekræft, at originalen ikke blev accepteret ved et andet hop eller for en anden modtager, og indsend derefter den godkendte erstatning med et klart forhold til det tidligere forsøg. Bevar sine egne besked- og kø-id'er. En ny besked er en ny leveringsbegivenhed, selvom brugeren betragter den som den samme vedhæftede fil.
Luk med den målte beskedstørrelse, identificeret afvisningsgrænse og resultatet af det korrigerede forsøg. Efterlad indbakkeplacering og modtageradgang til linket indhold som separate kontroller.
Adskil grænsen fra løsningen
- Mål: tæl hele den serialiserede meddelelse ved hjælp af SIZE-definitionen, ikke kun den vedhæftede fil.
- Find: Fang det afvisende hop, kommandostadiet, diagnosticering og gældende grænse.
- Reparation: vælg en godkendt mindre besked eller adgangskontrolleret leveringsmetode.
- Tjek igen: optag erstatningsstørrelsen og resultatet pr. modtager; antag ikke, at alle downstream-grænse matcher.
- Luk: Bekræft modtageradgang separat fra SMTP accept.