Eine Ablehnung der Nachrichtengröße kann erfolgen, bevor der empfangende Server die gesamte Nachrichtenauthentifizierung auswertet. Es kann auch erscheinen, nachdem ein Upstream-Server eine Nachricht angenommen hat und ein späterer Hop ein geringeres Limit anwendet. Diagnostizieren Sie die Größenbedingung am abweisenden Hop, anstatt jede permanente Ablehnung als eine zu behandeln SPF, DKIM oder DMARC Defekt.
Unterscheiden Sie Größe von Richtlinie und Speicher
RFC 3463 definiert X.3.4 als eine Nachricht, die zu groß für das empfangende System ist, und X.2.3 als eine Nachrichtenlänge, die eine administrative Grenze für das Postfach überschreitet. Diese unterscheiden sich von X.2.2, Postfach voll. Lesen Sie die vollständige Diagnose, da Produkte möglicherweise eigene Grenzwerte, Einheiten und erläuternde Formulierungen hinzufügen. Ein generisches „552“-Label allein legt nicht die genaue konfigurierte Einschränkung fest. RFC 3463 Abschnitte 3.3 und 3.4.
Authentifizierungsfehler betreffen Identitäten, Signaturen oder Richtlinien und nicht die Anzahl der Nachrichtenoktette. Eine Größenreduzierung ist keine DKIM Reparatur; Das Ändern signierter Inhalte kann eine Signatur ungültig machen, sodass ein autorisierter Ersatz den normalen Signatur-Workflow durchlaufen muss. Umgekehrt erhöht die Autorisierung einer anderen IP in SPF nicht die zulässige Nachrichtengröße eines Empfängers. Halten Sie die beiden Untersuchungen getrennt, es sei denn, unabhängige Beweise zeigen, dass beide fehlschlagen.
Lesen Sie die beworbene SIZE-Funktion richtig
Mit der SMTP -SIZE-Erweiterung kann ein Server Unterstützung und optional eine maximale Nachrichtengröße in seinem Server ankündigen EHLO Antwort. Ein unterstützender Kunde kann eine geschätzte Größe mit angeben POST VON, was eine Ablehnung vor der Übertragung der gesamten Nachricht ermöglicht. SIZE ohne Zahl vermittelt keine Information über ein festes Maximum; GRÖSSE 0 gibt explizit an, dass kein festes Maximum gilt. Beides garantiert keine Akzeptanz. Spätere Verarbeitung und andere Hopfen können immer noch Einschränkungen mit sich bringen. RFC 1870 Abschnitte 3 und 4.
Zählen Sie für RFC 1870 SIZE Nachrichtenoktette einschließlich CRLF-Zeilenenden, Header, MIME Struktur und codiertem Inhalt, schließen Sie jedoch den DATA-Abschlusspunkt und zusätzliche Punkt-füllende Bytes aus. Zählen Sie nicht nur die Anhangdatei. Die Base64-Codierung erweitert Binärdaten und Zeilenumbrüche und umgebende Nachrichtenteile fügen mehr Bytes hinzu. Sehen RFC 2045 Abschnitt 6.8. Anbieterschnittstellen zeigen gerundete Einheiten möglicherweise unterschiedlich an. Notieren Sie die gemessenen Oktette und den genauen angekündigten oder dokumentierten Grenzwert, anstatt zwei ungeklärte „MB“-Beschriftungen zu vergleichen.
Vergleichen Sie kontrollierte Varianten
Erstellen Sie zwei autorisierte Varianten, die sich lediglich im größenrelevanten Inhalt unterscheiden. Behalten Sie die kleineren und größeren serialisierten Größen und die SMTP Stufe jedes Ergebnisses bei. Ein illustratives Paar könnte denselben kurzen erläuternden Text enthalten, wobei ein großer Anhang durch einen genehmigten zugriffskontrollierten Dateilink ersetzt wird. Gehen Sie nicht davon aus, dass ein Dateilink für vertrauliches Material geeignet ist oder dass der Empfänger Zugriff darauf hat.
RFC 5321 Abschnitt 4.5.3.1 .7 erfordert die Unterstützung einer Nachrichtengröße von mindestens 64.000 Oktetten, einschließlich Headern. Das folgende Limit von 100.000 Oktetten liegt über diesem Protokollminimum und ist keine empfohlene Anbietereinstellung.
Nehmen wir für eine hypothetische arithmetische Prüfung an, dass derselbe Endpunkt die GRÖSSE 100.000 ankündigt. Eine angenommene Nachricht mit 115.900 Oktetten überschreitet diesen Grenzwert um 15.900 Oktette. ein angenommener Ersatz von 20.100 Oktetten liegt 79.900 Oktette darunter. Die erste kann bei MAIL FROM abgelehnt werden; der zweite ist zur weiteren Bearbeitung berechtigt, es ist jedoch keine Annahmegarantie gegeben. Bei diesen Zahlen handelt es sich um erfundene Zahlen, nicht um Messungen oder ausgeführte SMTP Ergebnisse. Sie beschreiben nicht die Anhangobergrenze eines Anbieters.
Reparieren Sie die engste relevante Einschränkung
Fragen Sie den Eigentümer des ablehnenden Systems, ob es sich bei der Größe um eine absichtliche Servicebeschränkung oder um eine von der Organisation kontrollierte Einstellung handelt. Wenn die geschäftlichen Anforderungen mit einer kleineren Datei erfüllt werden können, verwenden Sie diese Route, anstatt die Grenzwerte für das gesamte E-Mail-System zu erhöhen. Wenn eine Limitänderung autorisiert ist, berücksichtigen Sie den Ressourcenverbrauch, das Malware-Scannen und die Downstream-Kompatibilität, bevor Sie sie anwenden.
Versuchen Sie nicht, denselben dauerhaft abgelehnten Inhalt unverändert zu wiederholen. Bestätigen Sie, dass das Original bei einem anderen Hop oder für einen anderen Empfänger nicht akzeptiert wurde, und reichen Sie dann den genehmigten Ersatz mit einem klaren Bezug zum früheren Versuch ein. Behalten Sie die eigenen Nachrichten- und Warteschlangen-IDs bei. Eine neue Nachricht ist ein neues Zustellungsereignis, auch wenn der Benutzer sie als denselben Anhang betrachtet.
Schließen Sie mit der gemessenen Nachrichtengröße, der identifizierten Ablehnungsgrenze und dem Ergebnis des korrigierten Versuchs ab. Belassen Sie die Posteingangsplatzierung und den Empfängerzugriff auf verlinkte Inhalte als separate Prüfungen.
Trennen Sie das Limit von der Problemumgehung
- Messen: Zählen Sie die gesamte serialisierte Nachricht anhand der SIZE-Definition, nicht nur den Anhang.
- Lokalisieren: Erfassen Sie den ablehnenden Hop, die Befehlsstufe, die Diagnose und den anwendbaren Grenzwert.
- Reparatur: Wählen Sie eine genehmigte kleinere Nachricht oder eine zugriffskontrollierte Zustellungsmethode.
- Erneute Prüfung: Notieren Sie die Ersatzgröße und das Ergebnis pro Empfänger. Gehen Sie nicht davon aus, dass alle Downstream-Grenzwerte übereinstimmen.
- Schließen: Bestätigen Sie den Empfängerzugriff getrennt von SMTP Akzeptanz.