> "Charles J. Boening" <[EMAIL PROTECTED]> said > So let me see if I can summarize where this might be going. A lot has > been talked about on this topic. > > Use the pw_uid/pw_gid to check and see if a user wants their mail > filtered. I'd also suggest setting another bit for delivery. So we'd > have a bit that says scan for spam That code is already in the development branch and well tested.
> and a bit that says deliver to domain > default spam folder (.SPAM or whatever) or not. Sounds good. > This would handle both > the problem of if the user wants their mail scanned and the disposition > of the scanned mail. Yep. > The user's only options for tagged spam are to > deliver to inbox so they can filter or deliver to a predetermined spam > container that the domain administrator specifies. I agree. > vdelivermail would pull the delivery location for spam from it's command > line or from the domain limits file. I'd rather put it in the domain limits file. Either option would effect an entire domain and we already have the domain limits method. It's a good place to add new options. > I also think spamc options should > be stored in the same place. Currently the spamc options can be set on the configure line. We thought that would be a good place since the spamc options are site wide. I think all the user preference options are stored in each user_prefs directory. > vdelivermail would call spamc. > Personally, I don't think we should offer the ability to call > Spamassassin directly. It's just not as efficient. I think when people talked about calling spamassassin they meant calling spamc to talk to spamassassin. At least, that's how the development code works now. > Maybe the spamc > functionality could be compiled right into vdelivermail so no forking is > necessary. That would be slick! Depends on how much of a moving target spamc code is. If it just is a socket write/read type of thing then it might be a good idea. Anyone feel like reviewing spamc.c? > Sound about right? Have I missed anything? Nice summary! New configure options? --enable-spamassassin enables both spamc and spamfolder processing this is already in the development branch --enable-spamdir = "relative directory for spam folder" to override the default spam directory location Ken Jones
