On Tue, Mar 31, 2026 at 04:27:12PM -0400, Curtis Villamizar wrote: > > The policy cache is supposed to facilitate policy continuity, the > > client system needs to get many things "right" for this to remain a > > robust mechanism across multiple policy "age" limits (often set to > > just 1 day by the major players). > > So age could be set long but how long before cache space is low and > entries with long age are tossed prematurely. > > It seems like caching the policy of every other mail domain in > existance has a scalability issue.
Depends on how much disk space you have. Perhaps surprisingly storage is often the most abundant resource, capacity is growing faster than CPU speed. A single O(10-TB) drive can store a bunch of data on each of the ~400M domains delegated from a public suffix, many times over, with lots of room to spare. Of course keeping the cache warm for domains you might reach infrequently could be a problem. At the scale of Gmail, and given Google's data storage and retrieval capacity, MTA-STS policy storage is negligible noise not even worth a moment's thought. > > They don't *require* STARTTLS, they also accept mail in the clear. > > MTA-STS just asks clients to deliver over authenticated TLS, sort > > of like DANE, but without downgrade resistance, and much more > > complex deployment model for an MX hosting many domains. > > No downgrade resistance is very convenient for the MITM. They don't > need to bother with TLS if they don't want to. No downgrade resistance during policy refresh, but if policy refresh happens before expiration, and is retried multiple times on error, perhaps some resilience could be possible, but this takes effort to get "right" and to prioritise downgrade resistance in the first place. Speaking of getting things right, I feel obligated to once again mention that anyone who implements DANE inbound (publishes TLSA records for their own server) and MUST actively monitor the correctness of those TLSA records to ensure that they'd be notified in a timely manner (at most hours, not days or weeks, ...) should the TLSA records cease matching reality. Unmonitored security is an oxymoron, do not go there, implement monitoring **before** you publish TLSA records, and check that it works, including that alerts would reach you even if the TLSA records of all the MX hosts were wrong. - https://github.com/sys4/smtp-dane-verify - https://list.sys4.de/hyperkitty/list/[email protected]/message/6723WDBLPYWSXAORTAJR7EPAIOFAP5N4/ Also, for occasional external sanity checks: - Real time check (connects to your servers): https://github.com/sys4/smtp-dane-verify - Results of last 24hour DNSSEC/DANE survey run (quick database lookup, also info about the zone's DNSSEC), covers only TLDs and immediate children of public suffix domains. Ask about the recipient domain, not the MX host: https://stats.dnssec-tools.org/explore/ -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
