Newsgroup: it.comp.os.linux.sys
Titolo: Fetchmail e il punto assassino

 BODY=8BITMIME SIZE=5179
fetchmail: SMTP< 250 2.1.0 Ok
fetchmail: SMTP> RCPT TO:<zzz@localhost>
fetchmail: SMTP< 250 2.1.5 Ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
fetchmail: message zzz@xxxxx@
yyyy.it:1
 was not the expected length (2817
actual != 5179 expected)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 Ok: queued as 135F77A59
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3<
fetchmail: POP3> QUIT
fetchmail: POP3< I hope we can help you and have a good day.
fetchmail: client/server protocol error while fetching from
zzz@xxxxx@
yyyy.it
fetchmail: 6.3.6 querying 
yyyy.it
 (protocol POP3) at lun 15 set 2008
10:32:28 CEST: poll completed
fetchmail: Query status=4 (PROTOCOL)
Il fetchmail mi dice che il messaggio e' piu' corto di quanto si aspetta,
allora mi scarico il messaggio col telnet e lo vado a guardare e scopro che
proprio a circa 2800 caratteri dall'inizio ci sono queste righe (notare i
due punti sulla terza riga):
Compound: I belive NBR If for XXXXX should be all right, the price for 1000=
 pcs is Euro 0.160 each Mould Euro 350. Delyvery samples 10 days from order=
..
I hope we can help you and have a good day.
Eccetera, eccetera, eccetera....
Se, invece, scarico il messaggio direttamente con Thunderbird, vedo che
quelle due prime righe non vanno a capo e che dopo la parola 'order' c'e'
un punto soltanto mentre col telnet ne vedo due !
Qui pero' giungo al limite delle mie conoscenze sui protocolli di posta,
credo di capire che le linee piu' lunche di tot caratteri vengono spezzate
e viene posto il carattere '=' a fine linea per poi determinarne il
ricomponimento da parte del client di posta.
Chi ha spezzato la linea, ha probabilmente messo un punto di troppo, che il
fetchmail si ritrova come primo e unico carattere di una riga e quindi
interpreta come fine del messaggio, fine che pero' non e' reale.
Lo strano e' che Thunderbird non si lascia ingannare, non va' in errore e
visualizza un punto soltanto !
Come mai ? Conosce il problema e non si lascia ingannare, mentre fetchmail
invece inciampa ?
Ho Googolato parecchio, ho trovato parecchi problemi riguardo l'errore: "was
not the expected length" ma nulla riguardo il fenomeno che ho esposto.
Che ne pensate ???
-- 
Stefano L.

 riceve il '.' per cavoli suoi.
Puo' darsi, ma nei log di postfix non c'e' traccia di errore, nulla di
diverso rispetto a quanto logga quando processa un messaggio che viene
accettato.
Dopo l'errore del fetchmail c'e' semplicemente la disconnessione da
parte di postfix e poi manca la consegna al procmail che invece compare per
gli altri messaggi.
L'unico che si lamenta nei log e' il fetchmail.
-- 
Stefano L.

 L'unico che si lamenta nei log e' il fetchmail.
Ok, 
Ho riguardato i log: ho detto una ca##ata.
Il problema pero' rimane, di chi e' la colpa ?
Del fetchmail che non capisce che succede e non ricompone la linea come
dovrebbe ?
Del mittente che mette un punto di troppo ?
E sopratutto, come risolvo ?
-- 
Stefano L.

 (dove XX è il numero del messaggio che crea l'errore).
Questo l'ho gia fatto.... 2 volte !  :(
La prima volta ho penstato alla sfiga e ai raggi cosmici assassini che 
corrompono le e-mail che con sistemi sofiticatissssimi viaggiano da una
parte all'altra del mondo attravarso internet. :)
La seconda volta mi sono deciso a indagare.
La mail e' parte di un dialogo 'botta e risposta' con cc e ccn vari, mi
aspetto che il guaio si ripeta :(
-- 
Stefano L.

 Zappare quella mail a mano?
Gia' fatto,  vedi l'altro mio messaggio.
Rimane il fatto che esiste una qualche circostanza per la quale fetchmail
si impalla.
Il guaio, che non ho detto prima, e' che a quel punto, nonostante nel log di
fetchmail si legga il DELE, il messaggio non viene cancellato, la sessione
si interrrompe e i messaggi seguenti non vengono scaricati, e dopo 5
minuti, al giro successivo di fetchmail il tutto si riopete da capo
-- 
Stefano L.

 un punto soltanto mentre col telnet ne vedo due !
Questo č perfettamente normale: il "." da solo, su una riga, indica la 
fine del messaggio. Se si presenta nel body, viene quindi "escapato" 
raddoppiandolo...
Per caso c'č un firewall tra il fetchmail e il server POP3? E che 
firewall č? (Riformulo: sicuro non ci sia uno di quei begli aggeggi che 
fanno proxying della sessione POP a metterci le mani e combinare casini?)
-- 
http://www.linkedin.com/in/skull

 fanno proxying della sessione POP a metterci le mani e combinare casini?)
Il firewall c'e', ma controlla solo porte e indirizzi, niente analisi dei 
contenuti o proxing.
-- 
Stefano L.

 contenuti o proxing.
Dal tuo lato[1], ok.
Ma dal lato del server POP3?
[1] ...e non dare per scontato che non lo facciano solo perchè non lo 
hai mai sentito citare: nel dubbio verifica. Mi capita almeno una volta 
al mese di dire "disabilitate l'SMTP inspection da quel PIX" a qualcuno 
che lamenta problemi simili con qualche sporadica mail, e mi sento 
sempre rispondere "non abbiamo mai avuto questa funzione", salvo dirmi 
"ah, avevi ragione..." dopo 3-4 mesi che ripeto sempre la stessa risposta...
-- 
http://www.linkedin.com/in/skull

 Ma dal lato del server POP3?
Dal mio lato, il firewall l'ho messo su io e sono sicuro che non faccia
casino.
Del lato server non conosco nulla, provero' a indagare anche se mi viene mal
di stomaco solo a pensarci....
-- 
Stefano L.

 
[cut]
Alla fine ho risolto !  :)
Premessa 1:
Quando un messaggio contiene una riga che ha un solo un punto in prima
colonna questo punto viene raddoppiato per evitare che un MTA lo consideri
come indicazione di fine messaggio.
Tale "raddoppiamento" avviene solo durante la trasmissione del messaggio e
non viene mai scritto nei vari file.
Questo avviene sia durante un colloquio SMTP che durante un colloquio POP
Premessa 2:
Il fetchmail, per motivi suoi e a meno che non venga forzato diversamente,
usa il comando TOP invece del comando RETR per scaricare i messaggi (man
fetcthmail per spiegazioni in proposito)
Causa del casino:
Il server POP dal quale scarico il messaggio, se si usa il comando RETR,
giustamente raddoppia il punto solitario prima di trasmetterlo, se invece
si usa il TOP si dimentica allegramente di farlo.
Soluzione:
Aggiungendo, ad esempio, l'opzione fetchall al fetchmailrc si forza il
fetchmail a usare RETR invece di TOP.
Un grazie a tutti per i commenti che mi hanno aiutato a trovare la
soluzione.
 
-- 
Stefano L.