La documentación de Postfix es muy específica en cuanto a que el problema ocurre si un cliente ofrece cifrados que el cliente no implementa correctamente. Para citar desde la documentación :
... algunos clientes SSL han enumerado cifrados de prioridad más baja que no implementaron correctamente. Si el servidor elige un cifrado que el cliente prefiere menos, puede seleccionar un cifrado cuya implementación de cliente sea defectuosa.
En otras palabras: los problemas ocurren con esta configuración si el cliente a) ha roto los cifrados en primer lugar yb) ofrece estos cifrados a pesar de que están dañados yc) confía en que el servidor no elija los cifrados dañados que el cliente ofertas.
Los "clientes de Microsoft Exchange de Windows 2003" solo se brindaron como un ejemplo conocido de dicha implementación rota, lo que no significa que no haya otras implementaciones rotos. Contrariamente a HTTPS (donde no es raro que los servidores prefieran su propio orden de cifrado), hay una gran variedad de clientes de correo (incluido el MTA que intenta reenviar el correo al siguiente salto) y la posibilidad de comunicarse con alguna implementación defectuosa suele ser mayor . Esto no significa que la configuración tls_preempt_cipher_list=no
evitará estos problemas en todos los casos. Pero podría aumentar la posibilidad un poco de que el cliente y el servidor acuerden un cifrado que se implementa correctamente en el cliente.
Aparte de eso, en realidad no debería importar si el servidor elige el cifrado según los clientes o la preferencia de los servidores. Sin embargo, lo que importa es que el servidor solo tiene cifrados configurados que se consideran seguros. En este caso, no importa si el cliente ofrece cifrados no seguros, ya que el servidor no los seleccionará como cifrados comunes, sin importar si la preferencia de cifrado se toma del cliente o del servidor.