Greetings, I expect this list is not the most appropriate place to ask this question, but I suspect I am most likely to find someone who knows a solution here...
I am implementing simscan on a qmail-ldap server. I wish to use per-user spam filtering settings and store them in the ldap database, so I have --enable-spam-user=y in my simscan config. The logs show that spamc receives the argument of the recipient's email address. In the ldap logs, I can see a search for the spamassassin attribute, and it is using a filter of ([email protected]). Everything is exactly as the documentation says it should be. This particular server is expected to only have a single domain on it, and I plan on adding other ldap-based services to it later. So when constructing the DIT, I did not set the uid to be an email address, just the local part of it (first.last instead of [email protected]). So the spamc lookup succeeds, in that it correctly identifies that there is no user by the uid of a full email address, and hence no per-user config, but that success is obviously not the desired behaviour. It seems I can tackle this problem from at least three different angles. I can try and make simscan pass only the correct portion of the email address to spamc; I can try and make spamc search ldap with a filter of mail= instead of uid=; or I can let spam be filtered with just global configs at the smtp level, and try to implement the per-user configs later - either when the lda has the mail or by scanning it after the mail has been delivered to a maildir folder. I think I have read all relevant documentation regarding the first two options. I find nothing that indicates the values involved can be changed. I also spent a few hours looking over code yesterday to see if I have what it takes to implement such changes, but my programming skills are very limited, and so far I have not made heads or tails of where/how I might accomplish that. Unfortunate, because this seems the cleaner approach. I find my brain slightly opposed to the idea of doing additional scanning later. It seems wasteful to scan and sort a message twice using the same program, and it introduces yet another spot in the chain where something might go wrong (or makes a situation where one thing can go wrong in multiple places). In addition, it seems documentation on such an idea is extremely limited, and even there is mostly related to using postfix and procmail, so it may not be any less complicated to implement than my first two ideas. So, having read a great deal of this mailing list's archives, I did not find any solutions suggested. But I have come to realize that there is more than one genius on this list. Hopefully one of you has run across this already and would share your approach to this problem... -- Bob Miller 334-7117/660-5315 http://computerisms.ca [email protected] Network, Internet, Server, and Open Source Solutions
