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.

Remover dominio de certificado Let’s Encrypt

Tengo un sitio que responde por varios dominios y, a su vez, con y sin www, por lo que el certificado let’s encrypt tiene un Nombre Común y varios Nombres Alternativos.

$ certbot-auto certificates
  Certificate Name: cert.com
    Serial Number: 40d6f1a43875cf95b5eeb284c2902060d8e
    Key Type: RSA
    Domains: cert.com dom.com test.us play.cert.com win.cert.com www.cert.com www.dom.com www.test.us
    Expiry Date: 2021-04-04 15:33:09+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/cert.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/cert.com/privkey.pem

resulta que de este certificado se había cancelado, borrado, eliminado el sitio win.cert.com por lo que necesitabamos bajarlo del DNS también. Si no modificamos el certificado, la próxima renovación automática de Let’s Encrypt produciría un error al no poder validar la existencia del sitio.

El procedimiento para eliminar un dominio es borrar el certificado en primer lugar:

$ certbot-auto delete --cert-name cert.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
The following certificate(s) are selected for deletion:

  * cert.com

Are you sure you want to delete the above certificate(s)?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: 

Al borrar el certificado no se afecta el servidor web que está corriendo, mientras el servidor no sea reiniciado.

Y se puede volver a tramitar un certificado, ahora con la lista de dominios excluyendo el que se quiere elimintar:

$ certbot-auto certonly -d cert.com -d cert.com -d dom.com \
  -d test.us -d play.cert.com -d www.cert.com -d www.dom.com \
  -d www.test.us

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
1: Nginx Web Server plugin (nginx) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Requesting a certificate for cert.com and 6 more domains

Espero le sea útil a alguien más.

Vagrant: Ignoring gem because its extensions are not built.

Comenzando cursos actualicé a la última version de vagrant y comencé a tener un error en las gemas de ruby instaladas:

$ vagrant version
Ignoring nokogiri-1.10.5 because its extensions are not built.  Try: gem pristine nokogiri --version 1.10.5
Ignoring ovirt-engine-sdk-4.3.0 because its extensions are not built.  Try: gem pristine ovirt-engine-sdk --version 4.3.0
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Si bien todo el funcionamiento de vagrant que probé no tenía problemas, el error aparecía previo a la ejecución de cada comando vagrant.

Las sugerencias sugeridas de correccion de ejecutar gem no funcionaron tuve unos errores de permisos.

Revisando documentación vi que el error podría estar en el código de los plugins de vagrant (que agregan funcionalidad) y ejecuté el comando para borrarlos y reinstalarlos:

$ vagrant plugin expunge --reinstall

This command permanently deletes all currently installed user plugins. It
should only be used when a repair command is unable to properly fix the
system.

Continue? [N]: y

All user installed plugins have been removed from this Vagrant environment!

Vagrant will now attempt to reinstall user plugins that were removed.
Installing the 'vagrant-aws' plugin. This can take a few minutes...
Fetching: iniparse-1.5.0.gem (100%)
Fetching: xmlrpc-0.3.0.gem (100%)
Fetching: formatador-0.2.5.gem (100%)
[...]
Fetching: faraday_middleware-0.14.0.gem (100%)
Fetching: vultr-0.4.3.gem (100%)
Fetching: vagrant-vultr-0.1.2.gem (100%)
Installed the plugin 'vagrant-aws (0.7.2)'!
Installing the 'vagrant-cachier' plugin. This can take a few minutes...
Installed the plugin 'vagrant-cachier (1.2.1)'!
Installing the 'vagrant-scp' plugin. This can take a few minutes...
Installed the plugin 'vagrant-scp (0.5.7)'!
Installing the 'vagrant-vultr' plugin. This can take a few minutes...
Installed the plugin 'vagrant-vultr (0.1.2)'!

La reinstalación como se puede ver, descargó nuevamente las gemas y las compiló junto con el plugin actualizado. Esto solucionó el problema definitivamente:

$ vagrant version
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Espero esta información sea de utilidad pues me llevó un rato interesante llegar a la solución.

exito ok

whois para nuevos TLDs

Los nuevos TLDs como guru, americanfamily, showtime y muchos otros son un desafío para el comando whois con cierta antigüedad, ya que no los pueden resolver y muestra el error:

No whois server is known for this kind of object.

La solución es configurar un archivo /etc/whois.conf con las referencias a los nuevos TLDs y los servidores whois que los resuelven.

Este gist es un archivo /etc/whois.conf pronto para pegar y tener resuelto el problema para la siguiente consulta whois que se haga con los nuevos TLDs.

Rocket Chat super rápido con Vagrant

Rocket Chat es un excelente sistema corporativo de chat completamente software libre (clientes y servidores), con todo el glamour de un sistema de chat moderno (canales, integración, componentes embebitos, chatbots, etc. etc.)

En este Vagrantfile es posible levantarlo de forma tan simple como escribir vagrant up

[pastacode lang=»ruby» path_id=»aX3qrbgr» highlight=»» lines=»» provider=»pastebin»/]

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)

fingerprint de certificados ssh

Con el tiempo uno va coleccionando muchos certificados, algunos dedicados a un determinado proyecto, otros dedicados a algun cliente y, por supuesto los propios. En ese repositorio de certificados que suele ser la carpeta ~/.ssh/ hay que agregar los certificados que por algun motivo distribuimos en algunos servidores… en fin, llegará el día que necesitemos identificar algun certificado privado.

Así que estos son los comandos para obtener el fingerprint (huella dactilar) de certificados privados.

Certificado ssh

$ openssl rsa -in id_rsa -pubout -outform DER | openssl md5 -c
Enter pass phrase for .ssh/id_rsa:
writing RSA key
a2:d7:19:27:fa:89:43:aa:59:fd:ac:eb:71:3f:fb:a8

Como ven, mi certificado privado tiene passphrase y, para leerlo se require que la escriba.

Certificado pem (AWS)

openssl pkcs8 -in .ssh/proyectoX  -inform PEM -outform DER -topk8 -nocrypt | openssl sha1 -c
d3:ff:c0:cf:6f:25:a1:88:b5:c7:9e:9b:ba:b9:57:a4:bb:45:62:68

Los certificados que creamos en AWS se suelen guardar sin passphrase y el fingerprint se muestra inmediatamente.

Cambiando vencimiento llave GPG

Las llaves GPG que me identifican les coloco un vencimiento anual.

Mi llave pública GPG en keybase

entonces cada año en esta época debo proceder a renovar la llave, que lo que hago es correrle un año para adelante el vencimiento y vovler a sincronizar con los keyservers.

Este es el proceso total que ejecuto:

Buscar mi llame en mi llavero:

$ gpg --list-keys Rodolfo
pub   rsa2048 2014-09-07 [SC] [caduca: 2017-09-14]
      FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B
uid           [  absoluta ] Rodolfo Pilas <rodolfo@>
uid           [  absoluta ] Rodolfo Pilas <rodolfo@>
uid           [  absoluta ] Rodolfo Pilas <rpilas@>
uid           [  absoluta ] [jpeg image of size 4579]
uid           [  absoluta ] [jpeg image of size 13611]
sub   rsa2048 2014-09-07 [E] [caduca: 2017-09-14]

Editar la llave:

$ gpg --edit-key FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B

Clave secreta disponible.

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2017-09-14  uso: SC
     confianza: absoluta      validez: absoluta
ssb  rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Está editando la key 0 o sea la que se identifica como A33C4E6423B5BE7B

gpg> expire
Cambiando caducidad de clave primaria.
Por favor, especifique el per'iodo de validez de la clave.
         0 = la clave nunca caduca
      <n>  = la clave caduca en n d'ias
      <n>w = la clave caduca en n semanas
      <n>m = la clave caduca en n meses
      <n>y = la clave caduca en n a~nos
?Validez de la clave (0)? 1y
La clave caduca Tue Sep 11 17:26:48 2018 -03
?Es correcto? (s/n) s

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb  rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Ya quedo cambiada la caducidad de la llave primaria, ahora la secundaria 65841C4E15CF2ADC:

gpg> key 1

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb* rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

gpg> expire
Cambiando fecha de caducidad de subclave.
Por favor, especifique el per'iodo de validez de la clave.
         0 = la clave nunca caduca
      <n>  = la clave caduca en n d'ias
      <n>w = la clave caduca en n semanas
      <n>m = la clave caduca en n meses
      <n>y = la clave caduca en n a~nos
?Validez de la clave (0)? 1y
La clave caduca Tue Sep 11 17:27:37 2018 -03
?Es correcto? (s/n) s

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb* rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2018-09-11  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Guardar la llave editada y salir de gpg

gpg> save

Subir la llave al keyserver, para que los cambios se repliquen

$ gpg --keyserver pgp.mit.edu --send-keys FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B
gpg: enviando clave A33C4E6423B5BE7B a hkp://pgp.mit.edu

Y aprovechar a actualizar todas las demas llaves de mi llavero, pero eso ya es otra tarea.

Recuperar desde BackupPC por línea de comandos

BackupPC es una herramienta formidable para respaldar y guardar un registro histórico de respaldos en el storage del servidor. Pero está orientado al uso mediante interfaz web, y cuando queremos vincularos con el servidor por la línea de comandos, es algo complicado.

Recuperar el directorio /usr/local/sbin en forma automática se puede usar este comando, ejecutado en el servidor a recuperar.


cd /usr/local; \
ssh backuppc@server.backuppc \
/usr/share/backuppc/bin/BackupPC_tarCreate \
-h "$(hostname -f)" -n -1 -s "$(pwd)" "sbin" | tar xf -

Explicándolo:

cd /usr/local: es el directorio ‘source’ respaldado, registrado en $Conf{RsyncShareName}
ssh backuppc@server.backuppc: supone que tenemos acceso ssh al servidor backuppc y las credenciales como el usuario bakcuppc. Si se accede como root se puede ejecutar con sudo -u backuppc pues el comando BackupPC_tarCreate lo debe ejecutar el usuario backuppc obligatoriamente.
-h $(hostname -f): va a ser reemplazado con el nombre del host respaldado, desde el cual se ejecuta el comando. Si BackupPC lo conoce por la IP se puede poner directamente luego del -h.
-n -1: recupera el último backup realizado. Se puede colocar el numero de backup se se desea otro.
-s $(pwd): va a ser reemplazado con el directorio actual del host respaldado, desde el cual se ejecuta el comando ssh. Es el nombre registrado en $Conf{RsyncShareName}.
sbin: es la carpeta/archivo a recuperar. Se puede utilizar un punto "." si se desea recuperar todo el contenido.
tar xf –: el comando BackupPC_tarCreate que se ejecuta mediante ssh en el servidor BackupPC genera un archivo tar en stdout. Este tar xf - se ejecuta localmente en el host respaldado y extrae del tar los archivos en el disco local.

Se puede mejorar haciendo un gzip antes de pasar los datos por la red.

Si alguien conoce un método más óptimo, agradezco lo comparta y, si encuentro algo mejor, lo documentaré por aqui.

cal 9 1752

El comando cal de Unix es un comando estándar del sistema operativo (BSD, Linux, MacOS) que mostrará el mes actual en formato calendario cuando se ejecuta:

$ cal
   September 2016
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

Si el comando cal se ejecuta seguido del año (2016) mostrará los 12 meses de dicho año; y si se ejecuta seguido de número del mes y año entonces mostrará ese mes en particular de dicho año.

De esta forma se pueden encontrar perlas o curiosidades que ha tenido nuestro calendario a lo largo de la historia:

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

En setiembre de 1752 Gran Bretaña y sus colonias adoptaron oficialmente el calendario Gregoriano y se debió ajustar los días del anterior calendario Juliano. Referencia: Wikipedia Cal (Unix).

Este ajuste se corresponde con el que en octubre de 1582 hiciera el propio Papa Gregorio XIII para que la fiesta de Pascua coincidiera con la llegada de la primavera, y de esta forma al 4 de octubre le siguió el día 15 de octubre y asi, en el año 1583, el equinoccio primaveral (hemisferio norte) tuvo lugar el 21 de marzo.

Otros países se fueron uniendo de a poco: la Alemania Católica Romana, Belgia y los Países Bajos cambiaron a este nuevo calendario en 1584; Hungría en 1587; Dinamarca y la Alemania Protestante en 1704; Suecia en 1753; Japón en 1873; Egipto en 1875; Albania, Bulgaria, Estonia, Letonia, Lituania, Rumania y Turquía cambiaron entre 1912 y 1917; la URSS en 1918; Grecia en 1928 y finalmente China cambió luego de la revolución de 1949.

La adopción paulatina del calendario Gregoriano tiene algunas curiosidades, por ejemplo:

Segun Wikipedia, Miguel de Cervantes falleció el 22 de abril de 1616 a la edad de 68 años y William Shakespeare el 23 de abril del mismo año, pero Cervantes en España estaba bajo el calendario Gregoriano y Shakespeare en Gran Bretaña bajo el Juliano, por lo que la fecha Gregoriana de la muerte de Shakespeare fue el 3 de mayo de 1916.

La Revolución Bolchevique, que puso fin al zarismo en Rusia, se conoce como “Revolución de Octubre”, ya que tuvo lugar entre el 24 y 25 de octubre de 1917. Y el calendario gregoriano se adoptó en Rusia en 1918, al año siguiente. De haber adoptado el calendario gregoriano con anterioridad a la revolución la conoceríamos como la «Revolución de Noviembre».

Leer sobre el Calendario Gregoriano