Hello Chris, >>The first time I used spamdrop, it ended up with not finding the >>right queue directory. It searched in /var/lib/clapf/queue as it >>is defined in the source. The problem is, that I set the queueudir >>to another path in the config file. >>Sure one can set it during compile time, but I assumed if there >>is an option for it in the config file which is honored by clapf -- >>spamdrop will use it also.
It may be a little confusing. The queueudir is for the mail administrators only if they want to keep the queue files for later inspection or debugging an error. Normally it's not needed. Please note that only the clapf daemon honors it. I have added a similar quote to example.conf. The users' queue directory is different. A It's used to store a user's emails used by the spam quarantine applications and for training. >>Another reason would be the creation of a binary package. By using >>defines, there is no way to change paths according to special needs. After installation it does not make much sense to change the users' queue directory often... >>Maybe I do not understand exactly what the purpose of per user >>databeses is. >>In my opinion it's good for installations with many users with a >>wide spectrum of personal interest and therefore much differences >>in email contents. Then per user databases gives quite better >>results than a single big database. Is this correct? Correct. >>If yes, then I don't need it, because the number of users on the >>mail server doesn't exceed five. And the differences in content >>aren't this big (I know it ;) . Ok, this needs a little clarification, in the meantime, I have added the following to the example.conf ; If you are using spamdrop (not the clapf daemon), you have two options ; 1. You may specify this variable, then every user will share this ; token database (=shared database) OR ; 2. comment this variable out, and spamdrop will figure out where the ; users' individual token databases are. In other words: just set the sqlite3 variable, and every user will use that database file. >>But one thing remains, during maildir processing the stderr should be >>redirected to /dev/null, So the console isn't filled up with spam >>"garbage". I have added "2>/dev/null" to the proper places. The German language detection seems to be promising. It may give an even better result if I could somehow eliminate some English email stuff, such as Content-Transfer-Encoding. For now I consider it good enough. Anyway English and German are close languages - relatively speaking :-) Best regards, Janos
