Tenga cuidado de no rebotar un mensaje de rebote. De lo contrario, puede auto-DDOS su servidor de correo.
Puede ser más seguro, al menos en los primeros meses de probar esto, que en lugar de enviar correos electrónicos, los aceptaría, pero enviaría el mensaje con una gran advertencia de que el correo electrónico no se firmó correctamente y puede haber sido un intento de suplantación de identidad (phishing) y que el destinatario no debe actuar en el correo electrónico a menos que verifique cualquier información en el mismo a través de otros medios seguros.
Si un atacante lograra obtener la clave privada de un usuario, entonces habrían sido lo suficientemente profundos en la máquina de esa persona para que cualquier cosa que esa persona haga sea sospechosa, sea cual sea el sistema que esté usando. Así que este no es un problema que deba preocuparse. Además, el requisito de firmas le brinda la posibilidad de identificar a la persona que filtró sus claves privadas y disciplinar / volver a capacitar a esa persona. También puede revocar esa clave fácilmente, mientras que el atacante tendría que buscar el sistema de otra persona para romperlo.
Una CA no debe emitir un certificado de correo electrónico a menos que pueda probar el control de la dirección de correo electrónico. Todas las CA públicas publican su Declaración de práctica de certificado, que detalla cómo validan la identidad de alguien antes de firmar un certificado para esa persona. Puede elegir una CA que tenga un CPS aceptable y limitar su superficie de ataque para que su servidor de correo solo confíe en esa CA en particular para los correos dentro de su dominio. Si desconfía de cualquier CA pública, también puede ejecutar una CA interna para no tener que depender de un tercero para la identificación de su empleado interno.
Por supuesto, solo se acepta una clave de usuario válida, no *, por lo que las claves permitidas están en la lista blanca.
En lugar de incluir directamente en la lista blanca las claves del usuario, sugeriría las claves del verificador de confianza (CA / Web of Trust) de la lista blanca. Solo los servidores cuyas claves públicas están certificadas por el verificador serán aceptados por el servidor de correo. Esto separa la responsabilidad entre los verificadores y el administrador del servidor de correo, y le permite agregar / eliminar personas sin la redistribución / reconfiguración del servidor de correo. Por ejemplo, puede capacitar a Recursos Humanos para que se convierta en su verificador de identidad, y ellos serían responsables de firmar y revocar los certificados a medida que las personas entran y salen de la empresa.