On Fri, Dec 19, 2003 at 04:53:58PM +0100, Peter J. Holzer wrote:
> On 2003-12-17 14:11:26 -0700, Bryan Scott wrote:
> > To solve this problem one would need per-user and/or per domain
> > controls.
> >
> > My thought is to create a suite of scripts that uses a user database (such
> > as vpopmail's) for customer and/or domain preferences. The FiltersToUse
> > table would look something like this:
>
> I have done something similar for my "aliases" plugin. It allows to
> specify per recipient options like this:
>
> [EMAIL PROTECTED]: [EMAIL PROTECTED] (denysoft_greylist,
> spamassassin_reject_threshold=10)
Is this a single config file? (it looks like Bryan's was) One problem
I see with this kind of approach is it makes it harder to automate user
management of their options - you're loading and then resaving the whole
file with the consequent security and corruption issues to handle.
Per-domain or per-user files are more friendly in this respect, but
slightly less convenient for the admin. This is just a variant on the
old /etc/aliases vs. .qmail discussions, of course.
> This would set a transaction note with key "recipient_options" and the
> value { denysoft_greylist => 1, spamassassin_reject_threshold => 10 },
> which other plugins can then access.
>
> Currently I have only modified the greylisting module to check for the
> existence a non-null denysoft_greylist value in the recipient_options. I
> was planning to add support to other plugins as well.
>
> I would appreciate it if others would use the same scheme, and I am
> open to suggestions for improvement (I see a bit of danger in qpsmtpd
> that everybody does it his own way).
It's the downside of giving us all so much power. :-) But I know what you
mean.
You probably handle this already, but your consumer plugin check needs to
still work for people that *aren't* using recipient options, of course.
<snip>
> Right now the syntax of my aliases file only allows simple key-value
> pairs. I'd probably write that as:
>
> [EMAIL PROTECTED]: [EMAIL PROTECTED] (dnsbl_block=dnsbl.njabl.org,
> dnsbl_tag=bl.spamcop.net)
>
> and allow colonseparated lists of domainnames as arguments for the
> dnsbl_block and dnsbl_tag parameters. So the dnsbl plugin would do
> something like:
>
> my $ro = $transaction->notes('recipient_options');
> @block_lists = split(/:/, $ro->{dnsbl_block});
> @tag_lists = split(/:/, $ro->{dnsbl_tag});
>
> to get at the blacklists which it should use for blocking, tagging, etc.
A concern I have with going down this direction is that we're going to
then have *three* possible places plugins can source their config data -
config/plugins arguments passed into register(), config files accessible
via $self->qp->config, and your new recipient options. This is going to
confuse people (if it doesn't already).
Another thing is that this doesn't look terribly maintainable for larger
size lists - whitelists, for example, can get pretty long pretty fast,
but they're just the kind of thing I want to be able to customer per-user
or domain.
This is good discussion though, and I agree with you that setting up a
decent interface between config plugins and downstream consumer plugins
is going to make for a much cleaner solution.
Cheers,
Gavin
--
Open Fusion P/L - Open Source Business Solutions [ Linux - Perl - Apache ]
ph: 02 9875 5032 fax: 02 9875 4317
web: http://www.openfusion.com.au mob: 0403 171712
- Fashion is a variable, but style is a constant - Programming Perl
