On Tue, 4 Jul 2006, Chris Lightfoot wrote:
>
> ... that said, doing all of the necessary processing in an ACL could
> become a little bit unwieldy. It would be useful to be able to call some
> arbitrary external code from an ACL without the fork-and-exec cost and
> with something slightly more convenient than the UNIX socket read/write
> interface. How about a general `pass message and envelope to some
> external process over [authenticated] HTTP, get response status and
> content' string expansion function? That's a bit nasty, I admit, but (I
> argue) no more so than the package-specific protocols for ClamAV,
> SpamAssassin, etc....
It's really hard to do this in a way which isn't totally nasty.
One idea is to have something like a whole-message SMTP call-forward,
which is effectively how Postfix's before-queue filtering works.
http://www.postfix.org/SMTPD_PROXY_README.html
The disadvantages are that it limits the SMTP extensions you can use to
those supported by the filter, and it makes it harder to trace a message
through your logs.
Your HTTP call-aside idea is somewhat reminiscent of the OPES architecture
(see
http://www.ietf.org/html.charters/opes-charter.html) but the WG seems
to be moribund.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
