Esta entrada ha sido copiada de mi antiguo blog puheroska. Vale aclarar que la escribí en el 2012…
Se sabe poco sobre los orígenes de ese aborto de la naturaleza que es conocido por algunos 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. Muchos seguron lo identifican con un popular, potente y hermoso servidor de correo, para windows llamado MDeamon (pronunciado por algunos como “emodimons” y por otro como “emdaimons”). 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 y los cañones tiraban taquitos; 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 para resolver el problema del 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. Por su puesto, él 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 no van a su destino, y, 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: fetchmail lo parsea (del infintivo “parsear”) y 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)
Como por ejemplo, los correos de listas de distribuciones, etc… 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
Hasta aquí la entrada de puheroska.
En aquel momento consideraba eso “un problema sin solución”
Cuando llegué a salud, me encontré nuevamente con los DomainPOP, pero por suerte, los exim de infomed hacen bien esa pincha y dejan plasmado el destinatario en un encabezado “Envelope-To”
He aquí el fetchmailrc que tengo en el calixto:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |