[...snip..]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.
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).
Is the information stored in a database (mysql) or a flat file/dbm format? I would like to be able to integrate it into vpopmail's database somehow, although putting it into its own file would be supportive of more implementations. Authentication for the users' web-based config sessions could use POP or IMAP, further supporting all implementations.
Looks like the transaction note works with the API idea that Ask had, although I think that we might want a rcpt_preferences thingy separate from transaction notes, as we're looking at the potential of more than one recipient (as Matt suggested). We might be blocking for one rcpt, tagging for another, and receiving (but not queueing) for the third. (Is all that even possible in a transaction?)
user filtername filtervalue action --------------- ------------ ---------------- ------ [EMAIL PROTECTED] dnsbl dnsbl.njabl.org block [EMAIL PROTECTED] dnsbl bl.spamcop.net tag
>>[EMAIL PROTECTED] spamassassin 5 tag >>[EMAIL PROTECTED] spamassassin 10 block >>@bbsc.net spamhelo myipaddress block >>@bbsc.net spamhelo dynamichost tag
[...snip...]
So this:
{
dnsbl => {
'dnsbl.njabl.org' => 'block',
'bl.spamcop.net' => 'tag'
},
spamassassin => {
threshold => { tag => 5, reject => 10 }
},
}
might turn into something like this:
%rcpt_opts = { '[EMAIL PROTECTED]' => {
dnsbl => {
'dnsbl.njabl.org' => 'block',
'bl.spamcop.net' => 'tag'
},
spamassassin => {
tag_threshold => 5,
reject_threshold => 10,
more_opts => go_here
},
},
'bbsc.net' => {
spamhelo => {
myipaddress => 'block',
dynamichost => 'tag'
}
};Which is the same as yours, but adds places for the users and wildcard domains. I would think it easy to go a step further and merge users under their parent domains. Either way, parent domain rules would be the default, with individual users' settings overriding domain defaults. (Some of that could be determined during config file generation, negating the need for loading generic defaults here.)
There's a few ways of getting at the preferences at this point:
1. One would be a subroutine that each plugin calls, simplifying plugin design and going more towards a unified API as per Ask's desires.
2. Each plugin talks to the hash directly (hash built during RCPT phase so it only has the current recipients).
3. Each @recipient contains its preferences (built during RCPT phase) in an anonymous hash, perhaps keyed off the plugin's name.
From what I can tell, all of these options would be backwards compatible with plugins that don't support preferences--but then they wouldn't behave according to users' desires (which defeats the whole purpose of providing preferences anyway, so it's a moot point).
So THEN the configuration program(s) would need a way to know what plugins support preferences and ignore ones that are system-wide (but still be able to tell customers so they know what filters are running).
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?
Yes. My mistake. I forgot that it's MAIL FROM, not MAIL BODY or some stupid thing like that. :)
-- Bryan
