Articolo originale pubblicato venerdì 29 marzo 2013

Sono un addetto all'assistenza nell'ambito del Servizio Supporto Tecnico Clienti. Stavo lavorando con un cliente che aveva segnalato come errore un ciclo di posta per un dominio specifico come contoso.com. Era possibile osservare questo errore solo con messaggi di posta elettronica di grandi dimensioni. Questa situazione è veramente misteriosa finché non si comprende che il ciclo di posta dipende dalla restrizione relativa alla dimensione configurata nel connettore di invio. Ho pensato che tale episodio fosse sufficientemente curioso da condividerlo con voi.

Comprensione della configurazione e della causa principale del problema

Ho pensato inizialmente che l'errore dipendesse dal fatto che il server perimetrale (Edge) fosse configurato per l'utilizzo di un server DNS esterno, ovvero di un server DNS che risolve gli host esterni. Quando il server Trasporto Edge è configurato per l'utilizzo di un server DNS esterno, in genere risolve il nome del dominio come indirizzi IP pubblici (che di solito puntano al server stesso, al firewall esterno o al provider del servizio) anziché come server Trasporto Hub del sito di Active Directory, dando luogo a un ciclo di posta.

Riproducendo il problema, ho scoperto che il server Trasporto Edge non era configurato per l'utilizzo di un server DNS esterno. L'ambiente che ho allestito per riprodurre il problema era simile a quello illustrato nel diagramma riportato di seguito.

clip_image002

 

Ecco cosa accade in questo scenario: quando il server Trasporto Edge riceve un messaggio di posta elettronica di 20 MB da un mittente Internet, lo accetta. Tale server dispone di due connettori per cui viene trovata una corrispondenza con lo spazio degli indirizzi, uno per lo spazio degli indirizzi da contoso.com al sito di Active Directory e uno per lo spazio degli indirizzi *. Quando viene presa la decisione relativa al routing in base a tutti i connettori disponibili, quello che va da Edge a Hub non viene considerato a causa della restrizione relativa alla dimensione, ovvero del limite di 10 MB. La corrispondenza migliore è rappresentata dal connettore * che va da Edge a Internet e che prevede 30 MB come limite di dimensione per i messaggi. Rivedere l'algoritmo di selezione dei connettori illustrato in Informazioni sul routing dei messaggi.

Risultato finale: il messaggio viene reinstradato a Internet, generando un ciclo tra Internet e il server perimetrale (Edge).

A seconda del fatto che il connettore di invio verso Internet sia configurato per l'utilizzo di DNS o di uno smart host per recapitare la posta in uscita, si riceverà uno dei rapporti di mancato recapito riportati di seguito.

In caso di utilizzo di DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; i record DNS per questo dominio sono configurati in un ciclo ## (#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##)

In caso di utilizzo di uno smart host:

5.4.6 smtp;554 5.4.6 Superato conteggio hop - possibile ciclo di posta> #SMTP# (5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#)

Soluzione

Questo comportamento è da progettazione e può essere facilmente corretto modificando il limite di dimensione dei messaggi nel connettore. In base alle proprie necessità, è possibile scegliere una delle opzioni seguenti:

  • Impostare il parametro MaxMessageSize nel Connettore di ricezione (che riceve la posta in ingresso da Internet) su 10MB, in modo che i messaggi provenienti da Internet abbiano come limite 10 MB.
  • Impostare il parametro MaxMessageSize nel Connettore di invio dal server perimetrale (Edge) all'hub su 30MB, in modo che sia possibile ricevere messaggi da 30 MB da mittenti esterni.

Mistero risolto! Grazie ad Arindam Thokder e Scott Landry, che mi hanno aiutato a preparare questo post per il blog.

Suresh Kumar (XCON)

Questo è un post di blog localizzato. L'articolo originale è disponibile in Mysterious mail loop on Edge Transport server: Check your size limits!.