I would also suggest supporting standard pipes. Like smtp_check_tls_policy = pipe:/usr/sbin/some_script.pl
Preferable, for performance, the script will be long-running in a loop and accept questions on <STDIN> and spit out responses on <STDOUT> -----Ursprungligt meddelande----- Från: [email protected] [mailto:[email protected]] För Wietse Venema Skickat: den 22 mars 2016 15:29 Till: Postfix users <[email protected]> Ämne: Proposal: SMTP client policy protocol (for STS) In order to protect the stability of the Postfix SMTP client, I propose a new feature that builds on smtp_tls_policy_maps that allows experimentation with STS and other features. The design is similar to the way that Postfix SMTP server policies build on access maps. 1) An optional smtp_check_tls_policy client in the Postfix SMTP client that speaks TCP or local IPC just like the SMTP server's check_policy feature. /etc/postfix/main.cf: smtp_check_tls_policy = inet:127.0.0.1:12345 2) Each query is a dump of all relevant SMTP client state, one attribute and value per line: query: attribute_1 = value_1 attribute_2 = value_2 ... [empty line] Q1: What point in time is the call made? Q2: What attributes to send? E.g., nexthop, recipient, SMTP_SESSION, SMTP_ITERATOR, what else? 3) The reply is exactly the same as with smtp_tls_policy_maps. The rationale for this is to simplify implementation, user interface, and documentation (less code to write and fewer new things to learn). reply: policy = [same stuff as in smtp_tls_policy_maps lookup result] [empty line] Is this all paractical, or will we be stuck with C code? Wietse
smime.p7s
Description: S/MIME Cryptographic Signature
