> Maybe not only virtal host keys but also one for each user mailbox. AutoWhite doesn't consult user Registry keys, though it does look up alias Registry keys in order to consolidate aliases and their target usernames under the same .AWL whitelist file. AFAICS:
- If a user only uses a single e-mail address, you wouldn't need to add anything to the Registry to "fake it out." - If a user only uses (both sends from and receives at) a single local e-mail address -- either user or alias -- for any given remote correspondent, it would also not require any extra tweaking. - Registry additions would only be necessary in the case that a user sends from and receives mail at _different local addresses for the same remote correspondent_, and you thus want to check one AutoWhite list for all combos. > Autowhite does a great job at my side here, but I would suggest the > following: The current way to keep all data in numerous files es the > same file-based way as declude 1.x and 2.x has done. Now with the > new declude v3 service it would be great to have this functionality > inside the service (or added as a module) > This module could keep a RAM-based database of MAILFROM <=> MAILTO > communication of the last - let's say - 7 days. I'll say this: just because you're now building from a service model doesn't mean that using shared memory will be smarter than using non-volatile storage for data that needs to persist across service restarts. You can use shared memory without running from a service, but very I'm glad AW does not. As an avid user of AW, I take great comfort in knowing that data is stored on disk, rather than trusting a "flush on shutdown" of what can easily grow to many MB of data, and also in knowing that I can manually add, edit, and delete entries in .AWL files, none of which would be possible if everything were moved to an opaque data store. The rest of your feature requests are similarly cool, but "databases" that are opaque to the user are usually not! --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
