>>>>> "Hein" == Hein Roehrig <[EMAIL PROTECTED]> writes:
Hein> - From the operational point of view, the only advantage of a sieve
Hein> extension is that at this point of delivery, Cyrus knows exactly
Hein> whether the recipient exists, who it is, whether it is over quota
Hein> etc. For instance, knowing the user would make it easier to have
Hein> per-user-preferences in SpamAssassin (stored in a MySQL table.)
I thought about writing a lmtp proxy that would sit between the MTA
and Cyrus but abandoned it in part for this reason.
Hein> So perhaps it would be useful to have a generic filtering extension a
Hein> la Postfix content_filter in Sieve, to which all the context
Hein> information of Cyrus is passed.
I think this is an interesting idea. This would make it easy to build
complex filters that would otherwise be difficult to do in Sieve.
Hein> I would prefer to keep the fine-tuning of SpamAssassin out
Hein> of Sieve. Of course, on could imagine an extension that
Hein> provides a command spamassassin "some spamassassin
Hein> preference" but that precludes using, e.g., the SpamAssassin
Hein> PHP configration interface.
I did something like this in an earlier version of my spam sieve hack,
but ripped it out. It now sends the mailbox name to spamd as the
username so per-user SpamAssassin preferences work correctly.
-- Bob
