Swallow, Harold wrote: > It is/was our intention to create > a plugin that will operate on the body of the message not > as an anti-virus or anti-spam device but > provide a different beneficial service.
The problem I'm having is that you aren't sharing those details with us. All you've told us is that you have decided, for reasons we do not know, that you want to run qpsmtpd post-queue. I'm trying to get across the idea that qpsmtpd isn't intended/designed/suited to run except pre-queue (since many of the things it currently does well depend on being the first MTA in the conversation). > I want to use qpsmtpd as an SMTP wrapper around our > intended application in order to insert it into > Postfix. If you cannot tell us, even in vague terms, what that application is, there is little that we can do to help you change qpsmtpd's nature to fit that application. I'm not saying that you couldn't use qpsmtpd post-queue, but rather that, as it currently stands, there is hardly any point in doing so. There aren't really many existing plugins which would have any effect post-queue (even with the XFORWARD stuff added). If you are only looking for a fully compliant SMTP engine, then qpsmtpd is capable of doing that without any plugins loaded (except a queue of some sort). I've looked up XFORWARD (which is a non-standard ESMTP extension). It should be relatively easy to write a plugin that implements it (see plugins/tls for details on extending the command set by hooking ehlo and unrecognized_command. The only slightly tricky part is that you also need to hook FROM, since XFORWARD assumes that. What you would do is to parse the XFORWARD fields and fill in the associated transaction fields. HTH John
