Tamaño máximo de adjuntos en correos

El tamaño máximo de adjuntos en un correo varía de servicio en servicio.

Esto nos afecta, pues nuestro servicio puede tener un tamaño establecido que es mayor que el tamaño del servicio de destino y, si mis ajuntos son mayores, el correo no será ni acpetado ni entregado al destinatario. Mientras que correos que envío a cuentas en mi mismo servicio son entregados sin problema.

Por supuesto, es posible configurar un servidor de correo para soportar tamaños mayores a los indicados, pero hay que tener en cuenta que cuando se envíe un correo será el servicio de destino el que aplicará sus límites, antes de aceptar el correo, para entregar en la casilla del destinatario.

Esta es una lista de los tamaños de ajuntos soportado por distintos servicios:

Servicios internacionales:

Servicios nacionales (Uruguay):

Otros límites a un correo:

Hay que recordar también que los distintos servicios tienen límites aplicados a otras características de los correos electrónicos, que también puden afectar si mi correo llegará a destino.

  • Número máximo de direcciones de destinto (To:)
  • Tamaño máximo de mensaje (adjunto + cuerpo + cabezales)
  • Espacio máximo de casilla destino (esto puede afectar si el destinatario no vacía su casilla para alojar el correo que recibe)
  • Cantidad de correos que se aceptan recibir de un mismo dominio (por día)

Estos límites han creado un «estándar» que se observa desde hace muchos años y al que todos más o menos nos adaptamos, pero cada tanto alguien tiene requisitos por sobre estos límites y se encontrará que su correo no llega a destino.

Cuando su correo no llegue a destino por tamaño del adjunto, debe buscar la ayuda de otros servicio, como ser file.io, donde el adjunto viaja por un medio y el correo, con un enlace para recuperar el adjunto, llega al destinatario de manera normal.

Enviar correo SMTP por telnet

Nada nuevo, esto está por todo internet explicado en muchas formas, tamaños y colores. Pero sucede que lo utilizo mucho y lo que siempre hago es entrar a mi blog y hacer una búsqueda por el término «telnet» y ahi me doy cuenta que tengo todas las formas de telnet para correo, menos la común y corriente. Eso motiva este artículo.

Como enviar un correo electrónico al puerto 25 por telnet:

# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 mail.mydomain.com ESMTP

HELO yourdomain.com
250 mail.mydomain.com

MAIL FROM: you@server.com
250 2.1.0 Ok

RCPT TO: rpilas@mydomain.com
250 2.1.5 Ok

DATA
354 End data with <CR><LF>.<CR><LF>
From: "Some One" <you@server.com>
To: "Rodolfo Pilas" <rpilas@mydomain.com>
Subject: Testing
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="boundary-type-1234567892-alt"
--boundary-type-1234567890
--boundary-type-1234567892-alt
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Testing the text to see if it works!

--boundary-type-1234567892-alt
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<html>Does this actually work?</html>

--boundary-type-1234567892-alt--
--boundary-type-1234567890
Content-Transfer-Encoding: base64
Content-Type: text/plain;name="Here2.txt"
Content-Disposition: attachment;filename="Here2.txt"

KiAxMyBGRVRDSCAoQk9EWVtURVhUXSB7NjU5fQ0KLS1fZjZiM2I1ZWUtMjA3YS00ZDdiLTg0NTgtNDY5YmVlNDkxOGRhXw0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQoNCkp1c3Qgc2VlaW5nIHdoYXQgdGhpcyBhY3R1
YWxseSBjb250YWlucyEgCQkgCSAgIAkJICA9DQoNCi0tX2Y2YjNiNWVlLTIwN2EtNGQ3Yi04NDU4LTQ2OWJlZTQ5MThkYV8NCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQo8aHRtbD4NCjxoZWFkPg0KPHN0eWxlPjwhLS0N
Ci5obW1lc3NhZ2UgUA0Kew0KbWFyZ2luOjBweD0zQg0KcGFkZGluZzowcHgNCn0NCmJvZHkuaG1tZXNzYWdlDQp7DQpmb250LXNpemU6IDEwcHQ9M0INCmZvbnQtZmFtaWx5OlRhaG9tYQ0KfQ0KLS0+PC9zdHlsZT48L2hlYWQ+DQo8Ym9keSBjbGFzcz0zRCdobW1lc3NhZ2UnPjxkaXYgZGlyPTNEJ2x0cic+DQpKdXN0IHNlZWluZyB3aGF0IHRo
aXMgYWN0dWFsbHkgY29udGFpbnMhIAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0KPC9odG1sPj0NCg0KLS1fZjZiM2I1ZWUtMjA3YS00ZDdiLTg0NTgtNDY5YmVlNDkxOGRhXy0tDQopDQpmbHlubmNvbXB1dGVyIE9LIEZFVENIIGNvbXBsZXRlZA


--boundary-type-1234567890--


.
QUIT
250 2.0.0 Ok: queued as 1EDE71400DE

221 2.0.0 Bye
Connection closed by foreign host.

(esto lo he extraido de internet)

La magia de lo mágico: el correo electrónico

He manifestado muchas veces que el correo electrónico es la herramienta más abusada de Internet y a su vez una de las más viejas que se mantiene casi incambiada (casi como fue creada hace más de 40 años), y la gente acostumbrada a una especie de chat por e-mail suele perder noción de su funcionamiento básico, asignándole funcionalidades mágicas y, haciendo reclamos de magia cuando algo no funciona como espera.

Recientemente una empresa de servicios de correo electrónico empezó a clasificar el correo que envia uno de mis clientes como SPAM cuando lo entrega en la casilla de los destinatarios. Los remitentes (mis clientes) comenzaron a reclamarme por esta situación, frente a la que estoy virtualmente atado de manos, una de mis respuestas fue:

Si  mandas una carta por el Correo Uruguayo 
a un amigo en Bélgica y el cartero belga 
deja la carta en el hall del edificio en lugar 
de la buzonera del departamento (donde tu 
amigo revisa todos los dias).

¿Crees que el Correo Uruguayo puede hacer 
algo para que el cartero belga deje la carta 
donde la debería poner al entregarla?

Si llevamos el análisis del e-mail al equivalente del sistema de correo postal, solucionaríamos muy rápido muchos problemas.

¿te ha pasado que te piden hacer magia con el e-mail?

¿tienes alguna experiencia semejante para compartir?

Ceibal y Google Apps for Education: bienvenida la discusión, pero para arribar a conclusiones

IT_GAFElogo

El Plan Ceibal firmó un contrato para disponer de Google Apps For Education para la Educación Pública de Uruguay y recientemente la Universidad de la República (UdelaR) emitió un comunicado manifestando su «honda preocupación por la aplicación del acuerdo sin discusión previa«.

Su preocupación se centra en la  «cuestión la protección de los datos personales de los menores de edad alumnos de la ANEP, en clara discordancia con la normativa vigente en nuestro país«.  El comunicado concluye con la explícita disposición institucional para discutir y evaluar «alternativas eficaces» «que sean garantes de la protección de los derechos consagrados por la legislación nacional«.

Bienvenida la discusión, que siempre es buena y sana cuando su objetivo es arribar a conclusiones y lograr un mejor resultado que el originalmente previsto.

El Plan Ceibal sometió el contrato al análisis de la Unidad Reguladora de Control de Datos Personales (URCDP) que concluyó que el acuerdo «se adecúa a las disposiciones normativas vigentes en materia de protección de datos personales«.

Entonces lo primero a resolver es quién tiene razón si la Universidad de la República que ve una clara discordancia con la normativa vigente o la Unidad Reguladora de Control de Datos Personales que entiende que se adecúa a la normativa. Tiendo a pensar que la organización especializada en regular los datos personales (URCDP) a quién le piden un análisis específico, no se equivoca y creo que la Universidad de la República se apresuró en sus fundamentos, sin consultar a sus especialistas en la materia.

Pero más me llama la atención cuándo la Universidad de la República ofrece discutir y evaluar alternativas eficaces que sean garantes de la protección de los derechos, pues si tiene alternativas eficaces deberian estarlas planteando.  Es fácil darse cuenta que el Plan Ceibal YA TIENE el problema resuelto de ofrecer una plataforma mediante este acuerdo con Google, mientras que la Universidad de la República pretende detenerlo para abrir una mesa para una discusión abierta y minuciosa de alternativas (no manifiestas).

Bienvenida la discusión.  Discutamos, pero si es una discusión constructiva.

Percibo un mensaje de lo que hiciste no me gusta y como no lo discutiste conmigo, entonces «paren las rotativas»,  primero vamos discutirlo y luego vemos qué hacemos, y eso no parece constructivo.

Quién profesa «honda preocupación» por algo, no está a favor. ¿es esa la semilla para ofrecer un aporte constructivo?

¿por qué la Universidad ve problemas donde Ceibal no los ve? ¿acaso por la «clara discordancia con la normativa vigente»? …. ¿y URCDP?

o ¿por qué la Universidad conoce «alternativas eficaces» que Ceibal no conoce?  ¿por qué parecen estar  «reservadas» para la mesa de discusión una vez que el acuerdo se «congele»?   La Universidad de la República tiene gente con muchísima capacidad que seguro está al tanto de esas alternativas eficaces ¿por qué no las están planteando?

Sigo diciendo que es buena la discusión del tema y que se tiene que dar, pero que no así, que parece un palo en la rueda al Plan Ceibal.

No así, sin concretar esas alternativas eficaces a los servicios de Google Apps for Education de los que se habla, porque a mi me dan miedo otras empresas globales, competidoras de Google, que ya han ‘coqueteado’ con el Plan Ceibal y que si son alternativas.

Con comunicados de este tenor pienso que la Universidad de la República se está perdiendo la oportunidad de hacer un aporte sustancial al Plan Ceibal.  Si se tiene conciencia de los problemas relativos a la protección de la privacidad, aprovechemos a trabajar con los maestros, educadores, familias y niños para que cada uno pueda reconocer estos problemas y protejer sus datos.

Y sería bueno para toda la sociedad la discusión seria de las soluciones eficaces (que existen) para protejer la privacidad y los datos personales; pero cómo dice Raúl Echeberria en la nota de Subrayado «la discusión sobre la privacidad y protección de los datos personales ‘es otro tema’«, o  al menos es lo que hasta ahora parece y está quedando relegada.

¿Qué información envías por correo electrónico?

«Una carta enviada sin sobre por el correo tradicional tiene menos posibilidades de ser leída que un correo electrónico normal»

(esto lo he repetido muchas veces, de varias formas distintas)

Foto: Nikhil Verma
Foto: Nikhil Verma

No dejo de maravillarme con el correo electrónico moderno, en cuanto a que puede ser fácilmente trucado, modificado y espiado pero funciona bién para la inmensa mayoría de la gente. Mientras otras tecnologias de Internet son insatisfactorias si no están cifradas, resguardadas, auditadas con altos requisitos de seguridad, el correo electrónico sigue tan campante desde 1970 siendo la herramienta de comunicación más utilizada y con mínimos (casi nulos) requisitos de seguridad.

Generalmente me llama la atención como importantes profesionales manejan datos realmente críticos y los hacen fluir por correo electrónico; pero además agregan el famoso pie «Si recibe este correo por equivocación…» tratando de obligar al destinatario a una confidencialidad que ellos mismos no han tomado precauciones en asegurar.

Y aca no hay inocentes:  no importa la profesión (abogados, ingenieros, contadores), ni la importancia del negocio (empresas nacionales o multinacionales), ni el rubro; la inmensa mayoría envia sus correos para que cualquiera lo lea y, de hecho, son muchas veces leídos, indexados, analizados y registrados de forma consetudinaria, minuciosa y rigurosa.

A todo esto, el gobierno de mi país (Uruguay) pone en funcionamiento un excelente software de «monitoreo» de correo electrónico: El Guardián

El País: «El Guardián»: gobierno pone en marcha súper espía informático

Mi única referencia sobre este software es que «es bueno» en lo que dice que hace y, con el correo electrónico como lo usamos no se necesita mucho empeño para serlo.

Espero que llegue el día en que podamos identificar la calidad del remitene y del mensaje en base a los recaudos que se tomaron para asegurar la confidencialidad del correo electrónico.

Enviar correo SMTP+SSL por telnet

No es precisamente telnet ya que telnet no implementa SSL, pero me parece un buen título para explicar a que se refiere este artículo.

Siguiendo con el artículo de «Correo POP3+SSL por telnet», ahora explico cómo hacer telnet (a Gmail) para enviar correo.

Obtener usuario/clave

El usuario y clave son pasados codificados en base64, por lo que antes de empezar conviene tener el string de validación, con alguno de estos dos comandos:

$ perl -MMIME::Base64 -e 'print encode_base64("\000pilasguru\@gmail.com\000password")'
AHBpbGFzZ3VydUBnbWFpbC5jb20AcGFzc3dvcmQ=
$ printf "\0pilasguru@gmail.com\0password" | openssl enc -a
AHBpbGFzZ3VydUBnbWFpbC5jb20AcGFzc3dvcmQ=

como se aprecia, ambos devuelven el mismo string.

Conexión

El comando openssl con la opción s_client será el encargado de establecer la conexión:

s_client This implements a generic SSL/TLS client which can establish a transparent connection to a remote server speaking SSL/TLS. It’s intended for testing purposes only and provides only rudimentary interface functionality but internally uses mostly all functionality of the OpenSSL ssl library.

de la siguiente forma:

$ openssl s_client -host smtp.gmail.com -port 587 -starttls smtp -crlf

CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIOuQOXm7sFPMwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTMwOTEwMDc1NDQ3WhcNMTQwOTEwMDc1NDQ3
WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOc210
cC5nbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpMKDa
E9bW18yuVMulny5K5YLwf7ebEpINUVPZXvp7cO6vNjl+MCHjhbB2Rkg7QVJE8eNS
V0Hpq3vOuz+RQ2rPKfaeM3MFBZJ+tKscC39XmlVtmyBW5AVWy5dlO7718MQCN/L5
kpYSY6RinFrf5pIlf5XSGRCo3WYndguPP1A+X4gsDKjMaWhCP5KfczLHGTY+4T+d
31lDSah8CbFeMvKav0SFnyRYM36YAvAk2HH1/64Tolbx9tMAW6e6q8dU1U6W5u6+
Bt7WjW1iYwwfML+ZorKR9p+V070nDDN42ZE8HVZw+hOl9eMl48L/eX0eKbSGZ
....
J/3lYLI71meuut7O7G+BcFlXVphs5XSy65LkziTXikR+MRERjCKhv3AwP0oGB2+q
APMUqxtH6K6hmFE5ELtYjS4rKLbH08s8gy65y/EiaBaWKBlKG6s+r22uyxu2xmgo
LFf94N1gVJXuaZXlCgVwThCtbekh8wxjHtcVw2HCZfzQemEr7oshVOX2
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3474 bytes and written 470 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 65AAADD952AE24108001D17D0FF6C5403E5CE85040F61346A1C80C8E753E394F
    Session-ID-ctx:
    Master-Key: F8B3C5E3C2C0435ED53542A36CBB8ECA635255FBAEF73F1ADDB7BC512657E9C9A9B7E7EB567227856648A4D54C63CCA7
    Key-Arg   : None
    Start Time: 1400863594
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 CHUNKING

A partir de aquí podemos establecer el diálogo SMTP con el servidor de gmail enviando el comando ehlo:

ehlo
250-mx.google.com at your service, [64.90.52.109]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH XOAUTH2 PLAIN-CLIENTTOKEN
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 CHUNKING

Luego validando nuestro usuario con el string que otuvimos previamente:

AUTH PLAIN AHBpbGFzZ3VydUBnbWFpbC5jb20AcGFzc3dvcmQ=
235 2.7.0 Accepted

A partir de aqui, se pueden enviar los comandos SMTP estandar: MAIL FROM, MAIL TO, DATA y punto para terminar el mensaje.

El reverso de tu IP no está configurado … ¿el qué?

El spam ha llevado a quienes administramos servidores de correo a tomar precauciones para que no abusen de nuestros servidores y molesten lo menos posible a los usuarios que tienen cuenta allí. Esas precauciones van bastante más allá de instalar un sistema anti-spam, estos suelen ser la última barrera (y la más costosa).

Una de las precauciones a tener en cuenta es la configuración del servidor que desea entregarnos correo, llamado el «cliente». Las computadoras que envían SPAM suelen estar en la cuerda floja pues si son demasiado prolijos en su configuración pierden capacidad de adaptación cuando son descubiertos y bloqueados, mientras que los servidores que no envían spam tienen todo el tiempo para ajustar su configuración.

En fin, uno de los chequeos básicos es consultar un servidor de nombres (DNS) para saber si la dirección IP del cliente tiene configurado reverso, es decir resuelve un nombre y si ese nombre corresponde a su IP. En postfix esto se realiza mediante las directivas:

reject_unknown_reverse_client_hostname
Rechaza el correo cuando:

  • la dirección IP no resuelve un nombre (no tiene reverso)
  • el nombre no resuelve contra la IP (no tiene configurado el directo A)
  • el nombre (A) resuelve contra una IP que no es la IP del cliente que se conecta

reject_unknown_client_hostname
Rechaza el correo cuando:

  • la dirección del cliente no resuelve reverso con un nombre.

Lamentablemente, las buenas prácticas de configuración, que deberían ser estándar, para un servidor de correo no lo son. Generalmente porque los técnicos a cargo del servidor de correo desconocen o no invierten tiempo en estos detalles; así es que muy seguido me veo en la necesidad de explicar esto.

Detectando un servidor mal configurado

Si el cliente no resuelve un nombre aparece en el DNS:

Nov  6 06:27:55 postfix/smtpd[4944]: connect from unknown[117.6.131.49]

Nov  6 06:36:47 postfix/smtpd[9419]: NOQUEUE: reject: RCPT from unknown[201.151.212.105]: 450 4.7.1 Client host rejected: cannot find your hostname,

y es facil de verificar el reverso de una IP con los comandos host o dig:

# host 117.6.131.49
117.6.131.49 does not exist, try again

En el anterior ejemplo no hay ningún nombre configurado para el reverso de esa IP.

# dig -x 201.151.212.105
;; ANSWER SECTION:
105.212.151.201.in-addr.arpa. 2605 IN	PTR	static-201-151-212-105.alestra.net.mx.

# dig static-201-151-212-105.alestra.net.mx
;; QUESTION SECTION:
;static-201-151-212-105.alestra.net.mx. IN A

En el anterior ejemplo, hay un nombre configurado para la IP, pero luego ese nombre no está configurado para ninguna IP.

Revisando nuestro servidor

Si queremos ver si nuestro servidor está bien configurado, debemos tener en cuenta lo siguiente:

  1. Verificar la IP del servidor que realmente entrega los correos salientes. Me he topado con Admins que revisan una y otra vez la IP de su MX, y ese es el servidor que recibe los correos.
  2. Verificar la IP pública con la que el servidor sale a entregar correo. Algunas veces los Admins no saben claramente cuál es la IP pública que toman sus servidores, pues de esto se encargan «los de redes».

Y si bien los comandos host y dig son útiles, muchas veces no tenemos la posibilidad inmediata de revisar nuestra IP desde el universo público («desde afuera»), así que este servicio de Terra para Postmasters nos permite hacerlo.

Terra Postmaster Reverso

Así que si Ud. es administrador de servidores de correo (postmaster) y puede colaborar mejorando su configuración, espero este artículo sea de utilidad.

Procesar correos en Maildir: cleanup-maildir

Cuando se guardan los correos electrónicos en un servidor en formato Maildir, cada correo es guardado en un archivo; a diferencia del formato Mbox donde todos los correos están en un único archivo.

Muchas veces es necesario «limpiar» correos viejos, a veces en forma periódica (en el crontab) o a veces a pedido («borrar mensajes del año pasado») y ponerse a buscar en carpetas de Maildir y mantener la estructura es difícil. Ahi es donde la utilidad cleanup-maildir es útil.

Cleanup-maildir es un script escrito en Python que mediante parámetros permite, a partir de la antiguedad de los correos, borrar viejos mensajes, moverlos a la papelera o archivarlos en carpetas Maildir para que sigan siendo accedidos.

Ejemplos:

Guardar todos los mensajes con más de 150 días de antiguedad en la carpeta ‘Enviados’:

cleanup-maildir --age=150 archive 'Enviados'

este comando se utilizará $HOME/Maildir del usuario que ejecuta el cleanup-maildir.

Borrar mensajes en el Maildir actual con más de 60 días:

cleanup-maildir --age=60 delete ''

Archivar los correos de un usuario determinado que tengan más de 3 meses en carpetas anuales llamadas, por ejemplo, Guardado.2012:

cleanup-maildir --age=90 --archive-folder=Guardado --archive-hierarchy-depth=1 --maildir-root='/home/usuario/.Maildir' archive ''

en estos casos, se debe recordar que las carpetas nuevas creadas quedarán con dueño y permisos de quién corre cleanup-maildir, por lo que un chown suele ser necesario.

Referencia: Leer un artículo completo sobre cleanup-maildir.

Correo POP3+SSL por telnet

Siguiendo con el reciente artículo sobre Correo POP3 por telnet, debo tener en cuenta que mis servidores suelen tener el correo con SSL, para lograr la capa de validación y cifrado para la trasmisión de los datos, por este motivo, el telnet no sirve para hacer conexiones.

Entonces cuando el servidor POP3 tiene SSL (sPOP3) la solución es usar openssl, asi:

$ openssl s_client -connect servidor.correo.com:995
CONNECTED(00000005)
-> Aqui se muestra la validación y
-> el contenido del certificado digital
-> … en varios renglones
->
+OK POP3 Ready

A partir de aquí, funcionan perfectamente todos los comandos de POP3, indicados en el artículo anterior, exactamente como si estuvieramos por telnet normal.

Correo POP3 por telnet

Esto no es nada nuevo ni «rocket science«, solo es un apunte personal, ya que esto lo requiero de vez en cuando y al final termino buscando entre documentos y documentos hasta que veo lo que quiero.

Es simplemente cómo hacer telnet al servidor de correo (POP3) y ver los mensajes.

Iniciar sesión en el servidor

$ telnet servidor.correo.com 110

Cuando conecte con el servidor, aparece como lo siguiente:

+OK POP3 Ready

El protocolo POP3 es muy sencillo. Cuando hacemos algo bien el servidor nos contesta con «+OK» y cuando lo hacemos mal nos devuelve un «-ERR». En ambos casos se añadirá un texto descriptivo.

Ahora el servidor espera nuestra validación:

USER usuario@correo.com

El servidor le responderá con el mensaje de OK:

+OK USER

Significa que ha aceptado el nombre de usuario y que esta esperando por su contraseña. Escriba:

PASS contraseña

empleando la contraseña de su buzón de correo. Si todo ha ido bien el servidor nos responde con lo siguiente

+OK Logged in.

Comandos al servidor

Una vez conectados disponemos de varios comandos que podemos utilizar:

STAT (status) solicita el estado de tu buzón de correos. El servidor responderá informando de cuantos mensajes hay a la espera, en el siguiente formato: +OK mm bb, donde mm es el numero de mensajes, y bb el numero de bytes del total.

LIST te lista todos los mensajes. El primer número es el identificador del mensaje (que se requiere para otros comandos y el segundo número es el tamaño.

LIST
+OK 2 messages (320 octets)
1 120
2 200
.

LIST 2
+OK 2 200

LIST 3
-ERR no such message, only 2 messages in maildrop

TOP nn nl para ver las cabeceras y primeras lineas del mensaje (nn sería el numero del mensaje que quieras ver, nl el numero de lineas de la cabecera, p ej: TOP 1 ALL)

RETR # para ver un mensaje, debe especificarse su numero identificados del mensaje.

+OK XXXX octets follow.
Cabecera del mensaje
Cuerpo del mensaje
.

Donde XXXX es el tamaño del mensaje en bytes. Seguido de esta linea se mostrará la cabecera del mensaje y el cuerpo del mismo. Si el mensaje está codificado en HTML o tiene datos adjuntos es más que probable que entienda poco del mismo.

DELE # borra el mensaje elegido. El borrado no es al enviar el comando, sino al terminar la sesión (se debe desconectar con QUIT o los mensajes no serán borrados)

RSET recupera los mensajes marcados para borrado

NOOP (No Operation) instruye al servidor para que no ejecute ninguna acción, salvo responder con un mensaje de confirmación (+OK).

UIDL (Unique Identifier List) sirve para asignar un identificador unico a todos los mensajes o a uno especifico.

APOP (Authenticate Post Office Protocol) Este comando puede ser usado como sustituto del binomio USER – PASS para identificar y validar un usuario. Su utilidad es evitar que el password del usuario viaje por la red de forma no encriptada. La sintaxis es: APOP (nombre) (codigo).

Desconectar y cerrar sesión

Para desconectar correctamente del servidor escriba:

QUIT

El servidor nos responde con:

+OK Logging out.

Y se cierra el telnet: Connection closed by foreign host.

Fuentes: