I am getting a bit lost in the documentation, have no experience with DSPAM and am looking for recommendations on which form of user grouping to use, and which training-mode and backend storage fit best with that.
Scenario: Postfix mailserver which does only two things: mailing lists with Mailman, and expanding virtual aliases* that eventually resolve to remote mailaddresses (sometimes multiple as a poor man's mailing list); no mail is stored locally so no mailboxes exist on this mailserver, and there is no authentication scheme for the "users" of the virtual aliases. Most of the spam is already caught pre-DATA by Postfix restrictions, postfwd and postgrey; DSPAM would serve as a second layer for spam from RFC-compliant not-blacklisted sources (e.g. major freemail servers, that send a mix of spam and notspam). About 10k mails per day are rejected pre-DATA; several hundred, mostly legitimate, mails make it through and are inspected in the second layer. Interfacing as content_filter that reinjects to a dedicated port is the preferred setup, this role is currently filled by AMaViS (dual-MTA mode). The system runs Debian and using the package system is highly preferred over building from source, so DSPAM 3.6.8 is the most recent version at my disposal. The users are mostly not tech-savvy and many of them are on GMail-accounts. Probably not many will help in training DSPAM, so some form of user grouping will be useful (not sure which though, mostly doubting between shared and merged). I don't understand yet how the group data in a merged group gets filled, the readme states that no data is written to the group. Using a global retrain address is preferred over per-user, but I'm not sure how to set this up correctly. The way I have it now registers even token-less test mails to the retrain-address as misses, but maybe the webUI just lied and really it is just ignoring those mails. Logging in to webUI is not an option for users, because there is no authentication scheme, nor is it desirable to create one just for this purpose; privacy of users is a concern so a centrally managed quarantine is not an option. Tag subject or deliver with header instead, and let the user (which can also be a mailing list) decide what to do with it. * Munged example of virtual aliases: council.a...@example.org: president.a...@example.org, treasurer.a...@example.org, secretary.a...@example.org president.a...@example.org: john.sm...@example.org john.sm...@example.org: jsm...@gmail.com etc. president.a...@example.org aliases to john.sm...@example.org for a year or so, then the position is taken by e.g. jane....@example.org ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
