Hola chavalotes!!
Bueno, muchos protestamos siempre de lo lento que es el Fetchmail
cuando baja el correo. Es un tema que se ha mencionado varias veces
en la lista y nadie parece encontrar una soluci�n clara, pero casi
todos os habeis fijado en que el `popclient' o el `fetchpop' son
much�simo m�s r�pidos.
A mi es un tema que me mosquea bastante, y sobre todo me ha mosqueado
ahora a vuelta del verano, resulta que tengo 1.200 mensajes en mi
buz�n (jo, los de la lista no teneis vacaciones nunca) y he hechado
m�s de 2 horas y s�lo he bajado 400 mensajes. As� no voy a terminar
nunca. Necesito algo r�pido.
Antes de mandar a paseo el Fetchmail se me ocurri� hacer
experimentos, para ver de que manera se puede acelerar. Pens� que el
problema puede estar en la distribuci�n de correo.
Hice varias pruebas con distintos sistemas de distribuci�n:
mda "deliver xmanoel" -> muyyyyy lento (donde pongo deliver,
poned `procmail', y ser� a�n m�s lento)
mda "cat - >> xmanoel" -> rapid�simo (pero ni se os ocurra
usarlo, que no se crea un mailbox)
a trav�s del MTA -> rapidez muy, muy decente.
Creo que el problema viene de que el Fetchmail es un programa muy
serio. Antes de bajar el siguiente mensaje espera a que la
distribuci�n de correo sea exitosa, con lo que si la distribuci�n es
muy sencilla (como el caso segundo) va como una moto. Si hay que
pasar por filtros (procmail y deliver), bloquear el buz�n, abrirlo y
cerrarlo, la cosa se ralentiza much�simo.
Entonces alguien se preguntar�.... �y porque si usas el MTA se
acelera? Muchos usamos tambien el procmail y el deliver para repartir
el correo localmente. Yo como muchos, pens�... �si va a pasar por el
deliver, para que meterlo primero por el MTA y luego pasarselo al
programa? Pues parece que no. Los programas de distribuci�n y
filtrado estan hechos para lo que est�n y los MTA est�n hechos para
trabajar `de verdad'.
Por lo que he visto, los MTA intentan facilitar la llegada de
mensajes entrantes. Entonces, en vez de hacer esperar al emisor,
aceptan el mensaje, lo meten en una cola y intentan enviarlo. Luego
si no se puede distribuir ya se ver�.... Te mandan el t�pico
mensajito de error al emisor. (Pero el mensaje no se pierde, se
intenta enviar varias veces).
Por eso el MTA es m�s rapido con el Fetchmail. El Fetchmail se pone a
meter y meter mensajes nuevos y va como un ca��n. Luego es el MTA el
que va distribuyendo el mensaje. Para el usuario la diferencia no es
apreciable, y todo funciona m�s r�pido.
EN RESUMEN
La lentitud del Fetchmail bajando correo no es culpa del programa, si
no de los programas que se usan para meter el correo en los buzones.
Por tanto, para acelerarlo debes acelerar la distribuci�n de correo.
La mejor manera de hacer esto �ltimo es usar tu MTA (sendmail, smail,
EXIM,.....) para distribuir el correo. El Fetchmail hace esto por
defecto, o sea que no tendr�s que decir nada.
Si ten�as algo como esto en tu fichero de configuraci�n:
poll pop3.server with proto pop3:
user xmanoel password "#######"
mda "procmail -u xmanoel";
Cambialo por
poll pop3.server with proto pop3:
user xmanoel password "#######"
is "xmanoel" here;
Si a�n as� crees que esto va lento... pues entonces la culpa puede
ser de tu MTA, itntenta conseguir que se acelere la distribuci�n de
mensajes. Pero eso ya es algo que debes preguntar a otro...
--
Saudos:
><ose [EMAIL PROTECTED] (Vigo/Galicia/Espa�a)
http://pagina.de/xmanoel/
http://w3.to/mikkeli/
09/08 Anton Dvorak born in Nelahozeves, Czechoslovakia, 1841
09/08 Ron "Pigpen" McKernan (Grateful Dead) is born in San Bruno,
