On 11/26/11 6:52 AM, Wietse Venema wrote: > Philip Prindeville: >> On 11/23/11 5:56 PM, Wietse Venema wrote: >>> [snip] >>> With each new attribute: >>> >>> - An XCLIENT feature is needed if the attribute will be used for >>> access decisions. Otherwise, XCLIENT can no longer be used for >>> testing. >>> >>> - A queue file attribute record is needed if the attribute will be >>> used for access decisions. Otherwise, unexpected things will happen >>> when someone does "postsuper -r" and the Milter is called by the >>> cleanup daemon. This requires changes to the cleanup daemon to > > For example, without the client name/address must be in the queue > file, mail requeued with "postsuper -r" would be processed as if > it is a local submission, and that would cause some Milters to make > the wrong security decisions such as signing other people's mail. > >>> store the attribute, to rec_attr_map() to "bless" the queue file >>> attribute name, and to rec_type.h to define the pseudo record type >>> that rec_attr_map() needs. >>> >>> - An XFORWARD feature is needed if the attribute will be used for >>> logging. Otherwise, logging will be inconsistent. This requires >>> changes in the Postfix SMTP server to receive the attribute, the >>> smtpd_proxy_filter client to forward the attribute, the queue manager >>> code to read the attribute from queue file, the queue manager to >>> delivery agent protocol to forward the attribute, and the Postfix >>> SMTP client to forward the attribute. >>> >>> That's just off the top of my head. >> >> >> Thanks... Can you point me at any particular commits I could look >> at that added such a milter attribute? > > Here is a good example of what it takes to add, document and test > a "daemon port": > > $ find proto src -type f print | xargs grep -i client_port > > This produces 151 lines of output with postfix-2.9-20111125 (of > which 6 lines are in files with test data). > > Adding the server port would largely involve duplicating those > client_port lines, and maybe borrow some client port code that the > grep command did not reveal. > > Wietse
Well, if I'm going to do all that, I might as well add: daemon_port if_addr if_name Assuming that there might be further milter values added to the milter spec in the future, or that some of the existing milter values might need to be added to Postfix in the foreseeable future, would it make sense to add infrastructure code to simplify adding such variables in the future? I can use getifaddrs() to populate both of these latter two. -Philip
