Hi, Postfix by default enables the pix workarround for an server after a message has been queued for more than 500s.
http://www.postfix.org/postconf.5.html#smtp_pix_workaround_threshold_time The 500second threshold is (probably) only triggered when the server greeting in the SMTP Dialog is replaced by stars, which is still done (by default) by newer Cisco ASAs, that at least support ESMTP and in the case we ran into this also let the STARTTLS pass poperly. Best practice would be propably to disable this helper on the ASA and for IPv6 it's already disabled by default, but you don't want to discuss this with the firewall team of you E-Mail recipient. ;-) If the server with the default configured ASA between itself an you and a downtime of more than 500s has DANE (or any other way to enforce TLS encryption) enabled, and we're respecting DANE this leads tho the messages, when the server gets reachable again: Apr 26 09:39:46 <MyServer> postfix/smtp[22908]: E7CD35F79E: enabling PIX workarounds: disable_esmtp delay_dotcrlf for <ServerFQHN>[<ServerIP>]:25 Apr 26 09:39:46 <MyServer> postfix/smtp[22908]: E7CD35F79E: TLS is required, but was not offered by host <ServerFQHN>[<ServerIP>] And the mail won't be delivered any more, and it seems like also any further mail to this server is affected. My workarround is to set smtp_pix_workarounds = delay_dotcrlf in the main.cf and leave ESMTP enabled this way. And hoping nobody is using Cisco PIXes without ESMTP today anymore. Disabling ESMTP breaks the STARTTLS support, which is strictly necessary for DANE and any other way of TLS enforcement. So Disabling ESMTP is not an option any more if TLS is enforced. If it's really neccessary there are also ways to configure exceptions, but this is OT. Since this called a PIX workarround, PIXes are'nt manufactured by Cisco since aprox 2005 and even the last of them have no Software maintenance for aprox 10 years. The first ESMTP RFC1425 was even from 1993 (so probably/hopefully only PIXes from the 20th-Century had this Problem), I strongly hope not to find anything like this any more. ;-) My suggestion for a real fix is to leaven ESMTP always enabled (and ignore the disable_esmtp option) if TLS is enforced by DANE, MTA-STS or policy. I consider this old default behavior to be a Bug. And it breaks mail delivery if different default configs met each other. This is Postfix not Ubuntu specific, and in my case occured with a postfix 3.1.0-3ubuntu0.3, but I would expect this to happen with all versions, from the documented behavior. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: [email protected] man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert
