Discussion:
Patch: Expose custom data to postfix map lookups, and call for help
(too old to reply)
Jonathan Hall
2013-11-23 14:25:13 UTC
Permalink
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].

I realize this sort of call-for-help might be a bit unorthodox; I hope
that doesn't make it unwelcome.

-- Jonathan


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

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'))
if $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':

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

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)
Wietse Venema
2013-11-23 14:41:52 UTC
Permalink
FWIW, Sender-requested custom transports are already supported
as of Postfix 2.7.

header_checks:
/^X-Postfix-Cookie: xxx/ FILTER:smtp-xxx:

where smtp-xxx is a custom transport in master.cf with its own
smtp_bind_address, myhostname, etc. settings.

Wietse

Loading...