Può verificarsi un rifiuto della dimensione del messaggio prima che il server ricevente valuti l'autenticazione di tutti i messaggi. Può anche apparire dopo che un server upstream ha accettato un messaggio e un hop successivo applica un limite inferiore. Diagnosticare la condizione dimensionale del salto di rifiuto piuttosto che trattare ogni rifiuto permanente come un problema SPF, DKIM O DMARC difetto.
Distinguere le dimensioni dalla policy e dall'archiviazione
RFC 3463 definisce X.3.4 come un messaggio troppo grande per il sistema ricevente e X.2.3 come una lunghezza del messaggio che supera un limite amministrativo per la casella di posta. Questi differiscono dalla casella di posta X.2.2 piena. Leggi la diagnostica completa perché i prodotti possono aggiungere limiti, unità e termini esplicativi propri. Un'etichetta generica "552" da sola non stabilisce l'esatta restrizione configurata. RFC 3463 sezioni 3.3 e 3.4.
Gli errori di autenticazione riguardano identità, firme o policy piuttosto che il numero di ottetti del messaggio. La riduzione delle dimensioni non è una riparazione DKIM ; la modifica del contenuto firmato può essa stessa invalidare una firma, quindi una sostituzione autorizzata deve passare attraverso il normale flusso di lavoro di firma. Al contrario, autorizzare un altro IP in SPF non aumenta la dimensione del messaggio consentita al destinatario. Mantenere le due indagini separate a meno che prove indipendenti non dimostrino che entrambe stanno fallendo.
Leggi correttamente la capacità DIMENSIONE pubblicizzata
L'estensione SMTP SIZE consente a un server di pubblicizzare il supporto e, facoltativamente, una dimensione massima del messaggio al suo interno EHLO risposta. Un cliente di supporto può fornire una dimensione stimata MAIL DA, consentendo il rifiuto prima di trasmettere l'intero messaggio. DIMENSIONE senza numero non trasmette informazioni sul massimo fisso; DIMENSIONE 0 indica esplicitamente che non è in vigore alcun limite massimo fisso. Nessuno dei due garantisce l'accettazione. L'elaborazione successiva e altri passaggi possono ancora imporre vincoli. RFC 1870 sezioni 3 e 4.
Per RFC 1870 DIMENSIONE, contare gli ottetti del messaggio inclusi i finali di riga CRLF, le intestazioni, la struttura MIME e il contenuto codificato, ma escludere il punto terminale DATA e i byte extra di riempimento punto. Non contare solo il file allegato. La codifica Base64 espande i dati binari e le interruzioni di riga e le parti del messaggio circostanti aggiungono più byte. Vedere RFC 2045 sezione 6.8. Le interfacce del provider possono visualizzare le unità arrotondate in modo diverso. Registra gli ottetti misurati e l'esatto limite pubblicizzato o documentato anziché confrontare due etichette "MB" inspiegabili.
Confronta varianti controllate
Crea due varianti autorizzate che differiscono solo per il contenuto rilevante per le dimensioni. Conserva le dimensioni serializzate più piccole e più grandi e la fase SMTP di ciascun risultato. Una coppia illustrativa potrebbe contenere lo stesso breve testo esplicativo, con un grande allegato sostituito da un collegamento a un file approvato con accesso controllato. Non dare per scontato che il collegamento a un file sia adatto a materiale riservato o che il destinatario abbia accesso.
La sezione 4.5.3.1 .7 RFC 5321 richiede il supporto per una dimensione del messaggio di almeno 64 KB ottetti, comprese le intestazioni. Il seguente limite di 100.000 ottetti è superiore al minimo del protocollo e non è un'impostazione del provider consigliata.
Per un ipotetico controllo aritmetico, supponiamo che lo stesso endpoint annunci DIMENSIONE 100000. Un messaggio presunto di 115.900 ottetti supera tale limite di 15.900 ottetti; una presunta sostituzione di 20.100 ottetti è 79.900 ottetti al di sotto di esso. Il primo può essere rifiutato presso MAIL FROM; il secondo è idoneo per un'ulteriore elaborazione ma non è garantita l'accettazione. Questi numeri sono inventati, non misurazioni o risultati SMTP eseguiti. Non descrivono il limite massimo di attaccamento di alcun fornitore.
Riparare il vincolo rilevante più stretto
Chiedi al proprietario del sistema di rifiuto se la dimensione è un limite di servizio intenzionale o un'impostazione controllata dall'organizzazione. Se l'esigenza aziendale può essere soddisfatta con un file più piccolo, utilizza questo percorso anziché aumentare i limiti nell'intero sistema di posta. Se viene autorizzata una modifica del limite, considerare il consumo di risorse, la scansione del malware e la compatibilità downstream prima di applicarla.
Non continuare a riprovare senza modifiche lo stesso contenuto rifiutato in modo permanente. Confermare che l'originale non è stato accettato presso un altro hop o per un altro destinatario, quindi inviare la sostituzione approvata con una chiara relazione con il tentativo precedente. Conserva i propri identificatori di messaggi e code. Un nuovo messaggio è un nuovo evento di recapito, anche se l'utente lo considera lo stesso allegato.
Chiudere con la dimensione misurata del messaggio, il limite di rifiuto identificato e l'esito del tentativo corretto. Lascia il posizionamento della casella di posta e l'accesso del destinatario ai contenuti collegati come controlli separati.
Separare il limite dalla soluzione alternativa
- Misura: conta il messaggio serializzato completo utilizzando la definizione DIMENSIONE, non solo l'allegato.
- Individuazione: acquisizione dell'hop di rifiuto, fase di comando, limite diagnostico e applicabile.
- Riparazione: scegli un messaggio più piccolo approvato o un metodo di consegna con accesso controllato.
- Ricontrolla: registra la dimensione di sostituzione e il risultato per destinatario; non dare per scontato che ogni limite a valle corrisponda.
- Chiudi: conferma l'accesso del destinatario separatamente dall'accettazione SMTP .