Patch: Expose custom data to postfix map lookups, and call for help

[Jonathan Hall]

My organization has a requirement to expose a custom value to various map lookups[1], such as the transport map. We wrote a patch to accomplish this, and it has been working well in production for at least a couple years, with postfix 2.8.2[4]. We have recently attempted to port the patch to 2.10.2[5], but are experiencing some problems. As the author of this patch is unable to devote any time to it, we are willing to hire out[2] the debugging of this task to any willing and able party, and will gladly release the result here for public consumption and/or upstream inclusion, should anyone else find the patch to be of value[3].

-- Jonathan


1. First, an overview of how the patch works:




        if $txn->notes('postfix-queue-cookie');





hosts = localhost
dbname = dc
query = SELECT * FROM mail_route('%u','%d',('0'||'%c')::INT);
result_format = %s

I realize this sort of call-for-help might be a bit unorthodox; I hope that doesn't make it unwelcome. We are injecting mail to the postfix cleanup daemon directly (from a highly customized qpsmtpd), and during injection, we include an additional REC_TYPE_ATTR value: $strm->print_rec('REC_TYPE_ATTR', "postfix_cookie=".$txn->notes('postfix-queue-cookie')) (Our current use case has this 'postfix-queue-cookie' value simply being an integer representing a virtual UID, but it could theoretically be any string) This new 'cookie' value is then exposed to the various map lookups as the substitution variable %c. As an example, our 'transport.cf': So the mail_route() function is called with the user (%u), domain (%d), and the internal uid (%c). 2. Please contact me privately if you are interested in undertaking this project, and we can discuss details and compensation. This could lead to other work in the future, as well. We can provide debugging resources which match our production environment, if desired. 3. I can imagine that for this patch to be of optimal value for the community, it ought to be possible to read this 'cookie' value from a header, or by some other means more easily accessible to the end-user. As it is, it's only usable with a custom injection module. If Wietse felt this feature was generally useful enough to warrant inclusion in the project proper, we would entertain the possibility of hiring out the task of fleshing out this feature, and bringing it up to Wietse's standards. Having the feature included in upstream postfix would certainly be advantageous to us in the long term. 4. The working 2.8.2 patch is attached. (Patch is actually against the Debian package version 2.8.2-1, for whatever that may be worth) 5. The non-working 2.10.2 patch is attached; this causes trivial-rewrite to segfault on startup. I expect the debugging will be a very quick process for anyone proficient in C debugging, and even quicker for someone familiar with the postfix codebase. (Against Debian package, 2.10.2-1)

cookies-2.8.2.patch.gz
Description: GNU Zip compressed data

cookies-2.10.2.patch.gz
Description: GNU Zip compressed data