Ultimamente ho avuto un paio di casi di malfunzionamento del connettore POP3 di Small Business Server 2008. I clienti hanno lamentato il fatto di non riuscire a scaricare le mail (solo alcuni account) nonostante la presenza di messaggi nella webmail del provider. In entrambi i casi (domini di posta gestiti da ISP differenti, uno dei quali Aruba) nella webmail ho riscontrato la presenza di parecchi messaggi contenenti conferme di lettura relative a email da loro inviate o di messaggi di mancato recapito (NDR) dovuti, ad esempio, all’indirizzo del destinatario errato. Oggi ho deciso di accanirmi per capire l’origine di tali malfunzionamenti e, dopo una serie di controlli e un consulto con l’ottimo Simone (grazie! :)), il mistero è stato svelato!
Da un controllo nel registro eventi dei server affetti dal problema ho riscontrato la presenza ripetuta dell’errore in figura:
Uno o più messaggi di posta elettronica nell’account di cassetta postale POP3 ‘nomeaccount’ sul server POP3 ‘serverpop3’ presentano campi di intestazione non validi. Per questo motivo, i messaggi non possono essere recapitati alla cassetta postale di Exchange Server ‘indirizzodipostaelettronica’ in Windows Small Business Server. I messaggi sono ancora presenti sul server POP3. Per risolvere il problema, connettersi all’account di cassetta postale POP3 e recuperare o eliminare manualmente i messaggi.
Nome: Microsoft-Windows-Small Business Server/Operational
Origine: Windows Small Business Server
Accesso: data e ora ultimo accesso
ID Evento: 217
Categoria attività: Connettore POP3 di Windows Small Business Server
Livello: Errore
Parola chiave:
Utente: SERVIZIO LOCALE
Computer: nomedelserver
Opcode: Informazioni
Il problema è generato dall’SMTP del provider (Aruba nel caso in oggetto) utilizzato come connettore Smart Host per l’invio da Exchange Server. Questo SMTP infatti genera erroneamente dei messaggi di notifica di mancato recapito (ad esempio per mail inviate a indirizzi inesistenti) con un return path come il seguente:
Return Path <MAILER-DAEMON>
che, ovviamente, il server Exchange non è in grado di interpretare. Modificando lo smart host per puntare ad un altro server SMTP, lo stesso messaggio allo stesso indirizzo genera un NDR con return path corretto, come il seguente:
Return Path <>
La soluzione al problema è stata quindi quella di cambiare l’SMTP utilizzato da Exchange nella configurazione dello Smart Host eliminando il server di Aruba e utilizzando quello di Fastweb, provider di connettività del cliente, con il quale il problema non si presenta.
Il problema di blocco dello scaricamento dei messaggi in caso di header malformati come questi è dovuto al fatto che il connettore POP3 quando scarica un messaggio dal server del provider non effettua una validazione dell’header, ma delega questo compito al server Exchange. L’header del messaggio viene quindi inviato dal connettore POP3 a Exchange come parte del comando MAIL FROM ed Exchange respinge il messaggio con un errore 501 conteggiandolo come errore di protocollo SMTP. Per dafault Exchange chiude una connessione SMTP dopo un certo numero errori di protocollo, 5 per impostazione predefinita. Nel caso in cui sul server POP3 siano presenti quindi 5 o più messaggi con header malformato, la connessione verrà interrotta in loop, poichè i messaggi non verranno mai scaricati e saranno nuovamente presenti alla schedulazione successiva.
Un workaround per questo problema consiste nell’incrementare la proprietà “MaxProtocolErrors” nel connettore Windows SBS Fax Sharepoint Receive e, successivamente, riavviare in servizio Transport di Exchange così che le modifiche abbiano effetto. La modifica va effettuata tramite Exchange Managent Shell, con il comando
Set-ReceiveConnector -Identity ($Env:computername + “\Windows SBS Fax Sharepoint Receive ” + $Env:computername) -MaxProtocolErrors 500
che aumenta il numero massimo di errori di protocollo per corrispondere al numero massimo di messaggi scaricabili in una sessione POP3. Una volta eseguito il comando dovremo riavviare il servizio Transport.
Una volta ricevuti 500 messaggi con un header malformato sarà comunque necessario accedere alla casella POP3 per una eliminazione manuale.
Questa soluzione l’ho applicata. Non risolve il problema, ma permette lo scarico dei messaggi. Il problema pero’ nel tempo si ripresenta rallentando lo scarico di essi. Pechè le e-mail rimango di delivery rimangono sul provider e con il tempo, quando il server cerca di scaricare, li ricontrolla tutti mettendoci piu’ tempo.
Non è stata trovata un altra soluzione migliore???
grazie mille per la collaborazione
Saluti
Guarda, io considero l’utilizzo del connettore POP una soluzione temporanea per una breve fase di migrazione di un sistema. La soluzione sarebbe poi, a mio avviso, quella di gestire la posta trasferendo il record MX e lavorando a livello dns. Se invece si intende utilizzate a tutti i costi il connettore POP varrebbe forse la pena cercarne uno di terza parti che consenta delle configurazioni più granulari…
Salve, io ho non uso smart host per l’invio dei messaggi bensì lo lascio fare tramite DNS, ma ho lo stesso problema con le conferme di lettura e di recapito. Aumentando il limite degli errori non risolvo comunque il problema perche sono costretto ogni tanto a connettermi ad ogni casella di posta e cancellare i messaggi. Davvero incredibile che non si sia trovata ancora una soluzione definitiva al problema. Mi fa piacere però aver trovato una spiegazione in questo forum. Secondo lei se imposto uno smart host per l’invio (quello della connessione) risolvo il problema?
Grazie
Purtroppo ad oggi non esiste una soluzione definitiva al problema. L’unica cosa fattibile potrebbe essere quella di acquistare un connettore POP alternativo a quello offerto da SBS 2008, ma reputo sempre più conveniente gestire l’MX internamente e configurare il provider dei servizi di posta come MX secondario per evitare la perdita di messaggi di posta elettronica in caso di problemi con la connettività aziendale (ipotesi ormai, peraltro, molto remota).
Se servissero informazioni sulla configurazione a livello di MX fammi sapere.
Ciao
ho anche io il problema che ormai sembra che pure microsoft abbia rinunciato a risolvere visto che la scorsa settimana ho partecipato alla presentazione del sbs2011. se non avete anche voi trovato nuove notizie a riguardo della correzione di questo bug non è che potreste darmi altre indicazione su una configurazione a livello mx magari con un controllo spam visto che il problema più grosso rimane quello a questo punto.
grazie ciao
http://www.igetmail.com/
la minima spesa, la massima resa. Funziona da dio.
Tra l’altro ha la funzione catch all che ti consente ad esempio di realizzare una situzione come questa.
Exchange riceve la posta tramite record MX.
E’ impostato un MX secondario con priorità piu’ bassa su mail server aruba.
Quando/se la adsl del server exchange e’ down la posta viene spedita al mx di aruba.
Nel mx di aruba ho configurato una sola casella che si chiama backupmail@sqr.it impostata per ricevere tutte le mail da indirizzi inesistenti.
Igetmail e’ configurato per scaricare la posta da questo indirizzo in modalità catchall per il dominio sqr e inoltrarle a exchange.
In questo modo se il mio server exchange e’ down tutte le mail vanno ad aruba e appena torna online le scarica con igetmail. Tutto questo pero’ senza il bisogno di configurare le stesse caselle di exchange su aruba e senza dover configurare un pop3 per ogni account.
Spero sia utile a qualcuno.
Ciao.