Topic: Conflitto Thunderbird - win 7: lento in invio

[vroby67]

Pur avendo cercato altri col problema che fronteggio, non ho trovato analogie, quindi temo una congiunzione negativa della nostra rete quando convive con thunderbird.

Gestiamo in proprio il server smtp (sendmail) connesso a 100 mbit nella rete interna e nattato al mondo. Con XP l'invio della posta è immediato, mentre con 7 la finestra di invio col progressbar che scorre permane sino a 50 secondi prima di spedire la mail.

Consultando /var/log/maillog, vedo che l'invio e rapidissimo, ma parte dopo 49 dei 50 secondi citati.

La prova l'ho fatta su diversi client, con le medesime risultanze. Il fenomeno si è verificato anche aggiornando un client da XP a 7: prima era una scheggia, dopo è comparsa la latenza.

SMTP è configurato per accettare relaying solo dai client del proprio segmento di rete, senza autenticazione e non criptato. L'istradamento è tramite DNS privato; il ping a smtp.tizio.caio risolve immediatamente l'ip e risponde immediatamente. Non esistono firewall all'interno della intranet. Su sendmail collabora spamassassin sotto le spoglie di canit, ma da quel che so (e che vedo da maillog) il passaggio dal milter è successivo alla connessione con sendmail, attività che ritarda a partire.

A corollario, aggiungo che abbiamo avuto problemi di comunicazione anche con dispositivi industriali su TCP, che con XP rispondono in 4-7 secondi, con 7 rispondono in 35", pur disabilitando QoS, IPV6 eccetera.

Spero di aver fornito elementi sufficienti per incuriosire qualcuno; è il primo post da niubbo, siate clementi e grazie.

Roberto

[Underpass]

Guarda la prima cosa che mi viene in mente è il fatto che Windows 7 utilizza l'IPv6 e Windows XP no. Hai provato a impostare

network.dns.disableIPv6

in about:config in Thunderbird?

[vroby67]

Grazie della risposta. Ho provato e non è cambiato nulla. Per andare oltre, ho sostituito nella definizione dei servers l'indirizzo IP secco, onde evitare chiamate al DNS. Nenti!!. In paga ho scoperto di avere un certificato non valido sul server, che dovrebbe però interferire solo con l'IMAP e che comunque una volta accettatane l'eccezione non scoccia più. La ricezione IMAP comunque non sembra dar problemi: lo spostamento di una mail tra cartelle è immediato.

Allego (per quanto ne veda poca utilità) l'estratto del log di consegna di una mail. Dopo l'invio è passato più di un minuto e mezzo prima di vedere il log relativo.

Codice: [Seleziona]

Mar  2 11:49:09 remsnc06 sendmail[17937]: p22An9CD017937: from=<r.visca@remnet.it>, size=516, class=0, nrcpts=2, msgid=<4D6E2083.9030501@remnet.it>, proto=ESMTP, daemon=MTA, relay=pc-roberto.remautomazioni.it [10.0.0.14] (may be forged)
Mar  2 11:49:09 remsnc06 CanIt[17955]: p22An9CD017937: what=accepted, stream=default, nrcpts=2, prob=0.0001, relay=10.0.0.14, score=0, sender=r.visca@remnet.it, threshold=5, subject=Eridaiie
Mar  2 11:49:10 remsnc06 CanIt[17955]: p22An9CD017937: Auto-trained as not-spam (score = 0)
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter change (add): header: X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, default)
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter change (add): header: X-Spam-Score: 0.00 () [Hold at 5.00]
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter change (add): header: X-CanIt-Geo: No geolocation information available for 10.0.0.14
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter change (add): header: X-CanItPRO-Stream: default
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter change (add): header: X-Canit-Stats-ID: 02EeaN99b - c9fd51fe95d9 (trained as not-spam)
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: Milter add: header: X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.0.0.3
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: to=<m.Visca@remnet.it>, delay=00:00:01, mailer=local, pri=60516, dsn=4.4.3, stat=queued
Mar  2 11:49:10 remsnc06 sendmail[17937]: p22An9CD017937: to=<v.magnifico@remnet.it>, delay=00:00:01, mailer=local, pri=60516, dsn=4.4.3, stat=queued


[Underpass]

Purtroppo non ho modo di fare verifiche. Mi spiace.

Hai provato a vedere se su BugZilla il problema è riportato? Soprattutto se è sistematico e riproducibile, magari altri utenti l'hanno riscontrato.

Ciao

[lucasali]

hai provato a disabilitare dal menu strumenti - opzioni - avanzate - generali
le voci:
"permetti a ricerca di windows ..."
"attiva la ricerca globale e l'indicizzazione"

prova anche ad abilitare il log di tb seguendo l'apposita faq

[vroby67]

hai provato a disabilitare dal menu strumenti - opzioni - avanzate - generali
le voci:
"permetti a ricerca di windows ..."
"attiva la ricerca globale e l'indicizzazione"

prova anche ad abilitare il log di tb seguendo l'apposita faq

Grazie.
Ho disattivato globale e indicizzazione, mentre non ho trovato la ricerca windows.
Ho attivato il log, mettendoci un attimo (sigh!) a capire che era per sessione: mi creava il file ma lo lasciava vuoto, visto che riavviavo tb.
Chiarito il problema, questo l'esito:

Codice: [Seleziona]

0[3328140]: SMTP: bad pref authMethod = 0
0[3328140]: SMTP Connecting to: 10.0.0.3

circa 50"

0[3328140]: SMTP entering state: 0
0[3328140]: SMTP Response: 220 remsnc06.remautomazioni.it ESMTP Sendmail 8.13.8/8.13.8; Thu, 3 Mar 2011 11:52:02 +0100
0[3328140]: SMTP entering state: 14
0[3328140]: SMTP Send: EHLO [10.0.0.14]

dopo l'ehlo segue ovviamente l'handshake completo e l'invio, pressochè istantaneo.
Saluti

[lucasali]

quindi è il server che ti fa attendere

[vroby67]

A livello di "messages" non ho riscontro sino all'ehlo. Per maggiori informazioni probabilmente dovrei sniffare il tcpip alla 25, per vedere se arriva la richiesta e chi è l'ultimo a parlare... non son certo di saperlo fare.
Se hai qualche idea o indicazione è gradita, se no gugglo un po' in giro.