on 7/19/05 6:37 PM, Michael Shell <[EMAIL PROTECTED]> wrote: > On Mon, 18 Jul 2005 23:30:37 -0700 > Kurt Bigler <[EMAIL PROTECTED]> wrote: >> We each came up with similar ideas independently. I was interested in >> a set of pre-fixed alternatives for the spam filter, and you are >> interested in doing something similar with the forwarding field. > > Kurt, > > Yes, it seems clear to me now. Well, I am now thinking that, since we can > specify a single script with --enable-spam-command, should we push the > complexity into *that* rather than into qmailadmin? Now, this may not > provide full control to users, but it might be a stop gap measure > and may even provide a simpler basis for a future enhanced qmailadmin > interface. For example, users could tell the sysadmin which function > they want from the spam filter script. Now, they can selectively > enable or disable this script on a per email account basis. But, the > trick is to get this single script to respond differently (different > functions) depending on the user/domain. (In future versions of > qmailadmin, users could specify, say a single string variable, that > would cause this single script to behave differently on a per > email account basis, but for now the sysadmin would have to determine > how the script behaves for each domain.) > > That is to say, we specify one script, say "masterspamscript" via > --enable-spam-command, then masterspamscript behaves differently > for say, foo.com than for bar.org. foo.com and bar.com each have to > tell the sysadmin which way they want filtering to work. For example, > foo.com wants messages that test positive for spam just to be tagged > as such and nothing else. However, bar.org wants messages that > test positive to be forwarded to a special "spambox". Now, the > sysadmin will have to setup some type of list so that masterspamscript > will do what it is supposed to for each domain, and users certainly > cannot alter this behavior on a per-email-account basis. But, I > think this would help until a more complete solution is implemented. > > Has anyone done anything like this? If so, do tell us how.
Well see Tom's reponse about the user flags. There is still a little more to be understood about this though, so I asked a couple more questions in my reply to Tom. But you are also bringing up the per-domain issue. It might be good to have per-domain settings also. For me the per-user settings are sufficient. A hand-written filter can also check the domain and act accordingly, implementing a per-domain master script like you were saying. IIRC, the current directory is set either to the domain or to the user directory, I forget which. In either case you would be able to access a domain-specific script from a global script by using the appropriate relative pathname. > I do have a tough time believing that this is the first time this > has been discussed - especially considering that qmailadmin seems to > be so popular with hosting sites. In a site hosting multiple domains > this is, IMHO, basic functionality. Since QmailAdmin is currently a layer on top of qmail+vpopmail, I think people have been first of all pretty happy to get any web gui functionality, and have been willing to go ahead and hack .qmail files when necessary to go outside the limits of what QmailAdmin currently supports. A couple years back there was no spam filtering option. The world of spam filtering has changed a lot over that time and the expectations of typical users are a lot different now. I think you're just seeing that free software development sometimes does not always go as fast as you would like. Users tend to be pretty grateful and patient as a general rule. And usually you don't have to wait too long for anything reasonable. -Kurt
