Entonces, ¿hay alguna razón por la que no verificamos?
Porque SMTP se diseñó en un momento en el que el remitente se consideraba de confianza. Los orígenes se remontan al menos a RFC 788 desde 1981, es decir, en un momento en el que solo existían pocos nodos en Internet de manera comparable, Los correos electrónicos se pueden rastrear fácilmente al nodo de envío por dirección IP y la falsificación del remitente no fue un problema.
Parece que tiene sentido que tengamos algún tipo de firma digital para verificar.
Una firma digital requeriría tener a cada remitente algún tipo de clave o certificado en primer lugar. Además, este certificado debería ser ampliamente confiable, ya que de lo contrario uno no podría verificar si el remitente es el que afirma (es decir, los certificados autofirmados no servirían). Uno también necesitaría algo de infraestructura para revocar y renovar certificados en caso de que estuvieran comprometidos.
En su lugar, hoy en día es común que el usuario final requiera autenticación. Pero como SMTP es un modelo de salto por salto donde el usuario final solo envía el correo al primer salto y el siguiente salto reenvía el correo en nombre del usuario original, los otros saltos todavía tienen que confiar de alguna manera entre sí. Hay algún mecanismo para asegurarse al menos de que la dirección IP de los remitentes reclamados esté asociada de alguna manera con la IP de los remitentes ( SPF ), para tener una ruta confiable entre los servidores de correo ( DKIM ) y para alinear el SMTP.MAILFROM con el RFC822.From (es decir, SMTP sobre con encabezado de correo) como se hizo con DMARC . Solo que, estos "complementos" no se emplean lo suficiente como para proteger ampliamente contra la falsificación del remitente.