On 2003-12-17 14:11:26 -0700, Bryan Scott wrote: > I've been thinking for the past little bit (a dangerous habit, I know), and > came up with an idea that should fit seamlessly into qpsmtpd, vpopmail, > spamassassin, etc. I'm curious if other developers have already done > something like the idea I'm about to describe, or if it's something that > needs starting. > > Many of my customers complain about too much email being blocked from the > various block lists and email filters, or that not enough email is being > caught.
Same here. I think it is very important to give the users control over
their spam filters. That way it is their responsibility.
> 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)
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).
> user filtername filtervalue action
> --------------- ------------ ---------------- ------
> [EMAIL PROTECTED] dnsbl dnsbl.njabl.org block
> [EMAIL PROTECTED] dnsbl bl.spamcop.net tag
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.
An idea for an simple improvement would be to allow hierarchical keys,
so you could write
dnsbl/dnsbl.njabl.org=block, dnsbl/bl.spamcop.net=tag,
spamassassin/threshold/tag=5, spamassassin/threshold/reject=10
and it would be parsed into
{
dnsbl => {
'dnsbl.njabl.org' => 'block',
'bl.spamcop.net' => 'tag'
},
spamassassin => {
threshold => { tag => 5, reject => 10 }
},
}
> [EMAIL PROTECTED] spamassassin 5 tag
> [EMAIL PROTECTED] spamassassin 10 block
See example above.
> @bbsc.net spamhelo myipaddress block
> @bbsc.net spamhelo dynamichost tag
My plugin doesn't accept wildcards (yet - it is on the wishlist)
> The idea would mean a not-so-strict set of rules for the early plugins; all
> of their blocking would have to wait until RCPT or MAIL was called.
Rcpt actually (at least in my implementation), because these are
per-recipient options, and the recipients are not known at the time of
the MAIL command.
> Blocked servers would be given a 550, "Sorry, the user/domain you are
> trying to communicate with has chosen to block this message for one or more
> reasons:..." (wording subject to change).
Yup.
> If the filter chooses to wait until MAIL is processed, then the mail can be
> saved in an IMAP Junk folder (maildir) that can be downloaded via IMAP or
> from the web with IMP, SqWebmail, etc.
Do you mean the DATA command?
hp
PS: I have posted the aliases plugin and my patches for
denysoft_greylist to this list some time ago. The current version can be
found on http://www.hjp.at/projekte/qpsmtpd/.
--
_ | Peter J. Holzer | In this vale
|_|_) | Sysadmin WSR | Of toil and sin
| | | [EMAIL PROTECTED] | Your head grows bald
__/ | http://www.hjp.at/ | But not your chin. -- Burma Shave
pgp00000.pgp
Description: PGP signature
