> > 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.
If it can be done, I'd say put the spamc options as a line in the domainlimits file. It would be more flexible that way. That way it's domain specific and not system specific. Charlie > -----Original Message----- > From: Ken Jones [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 03, 2005 7:19 AM > To: vchkpw@inter7.com > Subject: [vchkpw] spamassassin development was spamassassin > configuration > > > "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 > >
