Se sabe poco sobre los orígenes de ese aborto de la naturaleza que es conocido por alguno como "recolección aPOP" o por otros como "DomainPOP" . Haciendo referencia al hecho de bajar todo el correo para un dominio de un pop remoto. La historia se remonta a un popular, potente y hermoso servidor de correo, para windows llamado MDeamon (pronunciado como "emodimons") creado por la compañía Alt-New Technolgy, muy conocido por su simple pero elegante cliente web, el World Client. Entre sus features, podemos ver el almacenamiento de TODO el correo de un dominio en un mismo buzón. Esto, sumado a que en cuba todo el software es gratis :D lo convirtió en la herramienta definitiva para las redes conmutadas.
Por otra parte, no todo se le impugna windows. Cuando aún el morro era de palo, ya citmatel usaba un CuciPOP (vean que clase de nombre "Cubic Circles = CuCiPOP") para depositar el correo de sus clientes por lineas conmutadas; una clara implementación de aPOP. Esto resolvió ser la manera mas burda pero eficiente de resolver el problema de correo en lineas conmutadas.
Lo único que perturba este barato panorama, es el hecho de que si el correo no tiene un To: bien claro, se jode todo y te ves obligado a usar MDeamon, que en ese aspecto se saca todos los premios, porque su puesto, el es una de la principales implementaciones de este modelo. A menudo nos encontramos con que al
bajar el correo con fetchmail, uno o varios correos como los de las listas, no van a su destino, por el contrario, van al postmaster sin tener coincidencias de usuarios locales.
Hay quien esta acostumbrado a que el postmaster este LLENO de correos y eso le parece normal, cuando el buen funcionamiento de un servidor, se mide por el postmaster vacío.
Si un correo tiene un To: o un Cc: cuando fetchmail lo parsea (del infintivo "parsear"), entonces localiza una dirección de nuestro dominio basándose en que tiene el dominio en la configuración. Como le dijimos 'is * here' buscará cual nombre que este delante de lo que se parezca a nuestro dominio y lo entregara.
Pero: Qué pasa si el To: o el Cc: NO tienen una dirección de nuestro dominio?
Supongamos que el correo viene Bcc: (blink carbon copy) o que proviene de una lista. Donde el destino es la dirección de la lista. En ese caso los destinos se especifican en la orden RCPTO durante la sesión SMTP. Algunos servidores incluyen encabezados como: "Delivery-To","Envelope-To" o "X-Orignial-To" En mi opinión todos están de más, porque el Received: tiene esta información; pero bueno, podríamos decirle a fetchmail que ademas de esos, parsee encabezados Received:
Eso parecería una solución, el único problema es que no pincha :-P
Lo ideal sería un "algo" que parcee los Received uno a uno en busca de coincidencias locales. Por ejemplo, veamos el aspecto de un conveniente Received.
Received: from mx.jovenclub.cu (unknown [200.55.152.25]) by
mailserver.tudominio.cu (Postfix) with ESMTP id 6ADEC35055E
for <fulano@tudominio.cu>; Wed, 28 Nov 2012 15:44:53 -0500 (CST)
Es tan simple como detectar un Received: con nuestro dominio involucrado y ver que hay con el nombre de usuario. NO ENTIENDO por que carajo no funciona en fetchmail. El parametro include sería definitivamente un batazo si pinchara.
PERO!
Con este script
He parseado los Received: e incluso, sin parsear los To: no falla. La versión actual también incluye el parseo de todos los pertinentes encabezados, aunque hasta el momento, lo resuelve solamente con lo Received: sin problemas. Solo tienes que dárselo a fetchmail como "mda" y configurar tu dominio. En las primeras lineas del fichero están las configuraciones e instrucciones para la instalación.
