Pix workaround should be (partially?) disabled when DANE is in use
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| postfix (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Hi,
Postfix by default enables the pix workarround for an server after a message has been queued for more than 500s.
http://
If the server with an downtime of more than 500s has DANE enabled. And we're respecting DANE this leads tho the messages, when the server gets reachable again:
Apr 26 09:39:46 <MyServer> postfix/
workarounds: disable_esmtp delay_dotcrlf for <ServerFQHN>
Apr 26 09:39:46 <MyServer> postfix/
was not offered by host <ServerFQHN>
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_
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 necessary for DANE.
If it's really neccessary there are also ways to configure exceptions, but this is OT.
My suggestion for a real fix is to disable the pix workaround detection if DANE or TLS enforcement is enabled, or not to disable ESMTP in that case.
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
| description: | updated |
| Lars Kollstedt (lk-x) wrote | #1 |
| Scott Kitterman (kitterman) wrote Re: [Bug 1826534] [NEW] Pix workaround should be (partially?) disabled when DANE is in use | #2 |
| Lars Kollstedt (lk-x) wrote | #3 |
| Andreas Hasenack (ahasenack) wrote | #4 |
Hi again,
the 500second threshold is probably only trigggered when the server greeting 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 properly.
Combining PIXes which are not ESMTP ready, and DANE or other ways to enforce STARTTLS would be deadly for SMTP anyway. So leaving ESMTP activiated if STARTTLS is enforced would fix this in any case.
Kind regards,
Lars