* This is the modus mailing list * Greetings,
I sent this to support, but thought I would ask on the list as well. I have some questions regarding the use of Generic vs. Standard Database vs. Extended Database authentication, particularly as it relates to the integration of ModusMail with the Platypus billing system. We are getting ready to migrate all of our mailboxes to ModusMail 3 and need to make a decision on which authentication method to use. Our conversion to Platypus will not occur until after the first of the year, but we want to decide on the best ModusMail authentication mode now so that we don't have to convert all of our mailboxes to a different authentication mode later. 1) Platypus and Generic Authentication. Our understanding is that Platypus would store the basic mailbox ID information (e.g. mailbox name, domain, password, full name) in the standard Platypus email services table, and would manage ModusMail via scripting with the Mailbox utility. If this solution is used, how many/which mailbox properties can be managed via this utility (assuming the additional fields were added to the table in Platypus)? The ModusMail documentation lists about 20 properties in the section about this utility. Are those the ONLY properties that can be managed by this utility or can ALL properties be managed by this utility? 2) Platypus and Standard Database. Our understanding is that the "Platypus Authentication" method would be chosen in ModusMail and ModusMail would essentially be operating in Standard Database mode, except with knowledge of some stored procedures in the Platypus database for listing mailboxes, verifying users, setting passwords, and setting user information, and four additional scanning-related property fields. What is the purpose of the list and verify stored procedures? Is it to isolate the actual table structure in Platypus from ModusMail and present ModusMail with only those fields that it needs? Is the same true for the password procedure (i.e. to allow ModusMail to update the password in the Platypus database without knowing the actual table structure)? What about the user_info procedure? Is this to allow these four properties to be stored in the Platypus table instead of the registry so that Platypus could control these settings? With other mailbox properties being s tored in the registry, could Platypus still manage some of these additional properties (assuming the additional fields were added to the table in Platypus) via the Mailbox utility? 3) Platypus and Extended Database. Our belief is that the ModusMail Extended Database structure would need to be modified to include the billing-related fields needed by Platypus, then ModusMail would be set up using ODBC w/Extended Database enabled. Will this work with ModusMail? Will this work with Platypus? Are the stored procedures used with "Platypus Authentication" mode needed? Is ModusMail free to modify all fields of the table? The ModusMail documentation indicates that "Extended Database mode is similar to the standard mode, except that all mailbox properties are mapped to the database", but according to the list in the documentation, as well as the SQL script used to create the Extended Database, there are several mailbox properties that are NOT included in the Extended Database (e.g., whitelist, blacklist, aliases, etc.). Are these properties stored in the registry regardless of which authentication mode is used? Are they accessible via scripting? Regarding aliases (the general functionality of aliases, not the ModusMail feature), we need to be able to support either mailboxes with forwarding or mailboxes with aliases from the billing system so that the billing system has knowledge of which addresses are in use and thus not available for assignment to another customer. From an administration viewpoint, it seems that using mailbox aliases would be a much easier way to manage multiple addresses associated with a particular mailbox because all of the addresses are stored with the mailbox vs. forwarding which would have the same end result, except that multiple mailboxes would need to be created with all of the "alias" addresses set to forward to the master mailbox. In the billing system, both would need to be created as mailboxes, but with additional forwarding or alias attributes defined in the table so that the billing system could provision them in ModusMail. In the first scenario (ModusMail aliases), is the aliases property accessible via scripting? If so, how? If not, that leaves the forwarding mailboxes as the only solution for providing this functionality. That being the case, would you add the forwarding properties to the Platypus/Standard Database option, provision them via scripting, and have users make any changes to the forward-to addresses via the billing system; or use the Platypus/Extended Database (assuming that is a viable option) in which case the data is already in the table? What are the performance affects of Standard vs. Extended? Are there any issues with having "all" of the mailbox properties in the billing system? Thanks in advance for your replies. Jim Craig TDE Internet ** To unsubscribe, send an Email to: [EMAIL PROTECTED] with the word "UNSUBSCRIBE" in the body or subject line.
