Een afwijzing van de berichtgrootte kan plaatsvinden voordat de ontvangende server alle berichtauthenticatie heeft geëvalueerd. Het kan ook verschijnen nadat een upstream-server een bericht heeft geaccepteerd en een latere hop een kleinere limiet hanteert. Stel de omvang van de afwijzende hop vast in plaats van elke permanente afwijzing als een probleem te behandelen SPF, DKIM of DMARC defect.
Onderscheid grootte van beleid en opslag
RFC 3463 definieert X.3.4 als een bericht dat te groot is voor het ontvangende systeem en X.2.3 als een berichtlengte die de administratieve limiet voor de mailbox overschrijdt. Deze verschillen van X.2.2 mailbox vol. Lees de volledige diagnose omdat producten hun eigen limieten, eenheden en verklarende bewoordingen kunnen toevoegen. Een generiek “552”-label alleen legt niet de exact geconfigureerde beperking vast. RFC 3463 paragrafen 3.3 en 3.4.
Authenticatiefouten hebben betrekking op identiteiten, handtekeningen of beleid en niet op het aantal berichtoctetten. Het verkleinen is geen DKIM reparatie; Het wijzigen van ondertekende inhoud kan op zichzelf een handtekening ongeldig maken, dus een geautoriseerde vervanging moet de normale ondertekeningsworkflow doorlopen. Omgekeerd vergroot het autoriseren van een ander IP-adres in SPF de toegestane berichtgrootte van een ontvanger niet. Houd de twee onderzoeken gescheiden, tenzij uit onafhankelijk bewijsmateriaal blijkt dat beide niet slagen.
Lees de geadverteerde SIZE-mogelijkheid correct
Met de SMTP SIZE-extensie kan een server ondersteuning en optioneel een maximale berichtgrootte in zijn bericht adverteren EHLO antwoord. Een ondersteunende klant kan een geschatte omvang doorgeven MAIL VAN, waardoor weigering mogelijk is voordat het hele bericht wordt verzonden. SIZE zonder getal geeft geen vaste maximale informatie; GROOTTE 0 geeft expliciet aan dat er geen vast maximum van kracht is. Geen van beide garandeert acceptatie. Latere verwerking en andere hopsoorten kunnen nog steeds beperkingen opleggen. RFC 1870 secties 3 en 4.
Voor RFC 1870 SIZE telt u berichtoctetten inclusief CRLF-regeleinden, headers, MIME structuur en gecodeerde inhoud, maar sluit u de DATA-afsluitpunt en extra puntopvulbytes uit. Tel niet alleen het bijlagebestand mee. Base64-codering breidt binaire gegevens uit, en regeleinden en omringende berichtdelen voegen meer bytes toe. Zien RFC 2045 sectie 6.8. Providerinterfaces kunnen afgeronde eenheden anders weergeven. Noteer de gemeten octetten en de exacte geadverteerde of gedocumenteerde limiet in plaats van twee onverklaarde “MB”-labels te vergelijken.
Vergelijk gecontroleerde varianten
Maak twee geautoriseerde varianten die alleen verschillen qua inhoud die relevant is voor de grootte. Behoud de kleinere en grotere geserialiseerde formaten en de SMTP fase van elk resultaat. Een illustratief paar kan dezelfde korte verklarende tekst bevatten, waarbij een grote bijlage wordt vervangen door een goedgekeurde, op toegang gecontroleerde bestandslink. Ga er niet van uit dat een bestandslink geschikt is voor vertrouwelijk materiaal of dat de ontvanger toegang heeft.
RFC 5321 sectie 4.5.3.1 .7 vereist ondersteuning voor een berichtgrootte van minimaal 64K octetten, inclusief headers. De volgende limiet van 100.000 octetten ligt boven dat protocolminimum en is geen aanbevolen providerinstelling.
Stel voor een hypothetische rekenkundige controle dat hetzelfde eindpunt SIZE 100000 adverteert. Een verondersteld bericht van 115.900 bytes overschrijdt die limiet met 15.900 bytes; een veronderstelde vervanging van 20.100 octetten ligt 79.900 octetten daaronder. De eerste kunt u afwijzen bij MAIL FROM; de tweede komt in aanmerking voor verdere verwerking maar is geen gegarandeerde acceptatie. Deze cijfers zijn bedacht, geen metingen of uitgevoerde SMTP resultaten. Ze beschrijven niet het bevestigingsplafond van welke aanbieder dan ook.
Herstel de smalste relevante beperking
Vraag de eigenaar van het afwijzende systeem of de omvang een opzettelijke servicelimiet is of een door de organisatie gecontroleerde instelling. Als aan de zakelijke behoefte kan worden voldaan met een kleiner bestand, gebruik dan die route in plaats van de limieten voor het hele e-mailsysteem te verhogen. Als een limietwijziging is toegestaan, moet u rekening houden met het verbruik van bronnen, het scannen op malware en de downstream-compatibiliteit voordat u deze toepast.
Probeer dezelfde permanent afgewezen inhoud niet ongewijzigd opnieuw. Bevestig dat het origineel niet is geaccepteerd bij een andere hop of voor een andere ontvanger en dien vervolgens de goedgekeurde vervanging in met een duidelijke relatie tot de eerdere poging. Behoud zijn eigen bericht- en wachtrij-ID's. Een nieuw bericht is een nieuwe bezorgingsgebeurtenis, zelfs als de gebruiker het als dezelfde bijlage beschouwt.
Sluit af met de gemeten berichtgrootte, geïdentificeerde afkeurlimiet en resultaat van de gecorrigeerde poging. Laat de plaatsing van de inbox en de toegang van de ontvanger tot gekoppelde inhoud als afzonderlijke controles achter.
Scheid de limiet van de oplossing
- Meten: tel het volledige geserialiseerde bericht met behulp van de SIZE-definitie, niet alleen de bijlage.
- Lokaliseren: leg de afwijzende hop, commandofase, diagnostische en toepasselijke limiet vast.
- Reparatie: kies voor een goedgekeurd kleiner bericht of een toegangsgecontroleerde bezorgmethode.
- Opnieuw controleren: noteer de vervangende maat en het resultaat per ontvanger; ga er niet van uit dat elke stroomafwaartse limiet overeenkomt.
- Sluiten: bevestig de toegang van de ontvanger afzonderlijk van SMTP acceptatie.