Novell's product used to be called "Novell Internet Messaging System" its now called Netmail 3.1 and Netmail XE (for windows environments) They claim that it scales to millions of accounts. It is not the same product as Groupwise, even though Groupwise makes much better sense than Exchange Server on a lot of different levels, not the least of which is better integration with Microsoft Office than Exchange Server's integration with Microsoft Office. More efficient message and attachment storage. It and the client are not vulnerable to all of the Outlook based viruses, scaleability, security and last but not least, stability.
Microsoft may have dropped the product as they have been advertising Exchange Server for ISP's these days, but the product was called SQLMail. Novell can't distribute PostgreSQL as part of the Netware distribution. That would be a violation of the BSD license. However, they've licensed MySQL in such a way as to be able to include it with Netware. That leads me to believe that MySQL would be the preferred SQL server for Netware. Curtis On Tuesday 22 April 2003 13:27, Chris Nolan wrote: > Microsoft's highend SMTP product uses MSSQL? What's the name of the > product? > > When you say "Novell's highend system" are you talking about Groupwise? > If so, you might find it uses PervasiveSQL. Novell have had a long > association with it and I doubt they've pulled it out of Groupwise just > yet. Their adoption of MySQL happened way after Groupwise 6.0 was > released, and Groupwise 6.5 is really just a client-side upgrade. > Remember, they've also ported PostgreSQL to NetWare. > > Exchange Server 2003 (aptly named "Titanium") doesn't seem to use MS SQL > on the backend. It achieves it's hot backup through Volume Shadow Copy - > an old trick that Windows 2000 and above have built in and is used by > the built-in backup utility. > > I totally agree about MySQL outclassing Oracle in the file size > argument, but the ease of configuration of MySQL cannot be understated > when you're comparing the two. Even though Oracle comes with a graphical > configuration front end and a bunch of chunky books, I'd rather set up a > mission-critical cluster using MySQL (single-master replication of > course, as it doesn't currently to it any other way) than set up an MP3 > database using Oracle. It's that damned hard to get the thing to work! > > If I had to go with a commercial DB though, I'd probably pick DB2 as > it's the only commercial one with the platform support to match the big > 2 in the open space. That and the fact that DB2 loves Linux and is > heavily standards compliant, not to mention that it's coming to the > almighty Hammer very soon. Now if only they'd port it to BSD so my > friends would shut up.... > > As for Postfix+SpamAssassin etc, e-mail me if you'd like. I've had it > happening for over a year now. I used to be a Sendmail admin, but as > soon as I got a hold of Postfix, I moved all of my installations over to > it. It wins in every area, except maybe number of features (of which > Sendmail has too many in my opinion). There are still a few gotchas with > DBMail, but I've logged all of mine in the bug tracking database and > hope to learn a bit more about DBMail's structure with a view to fixing > them. > > Regardless, off to bed. I have an SRS to hand in at uni tomorrow > morning, and it's 3:30am! > > Chris > www.itoperations.com.au/dbmail.html > > Curtis Maurand wrote: > >Let us not forget that the really highend email systems such as Openwave > > Email Kx uses Oracle (AT&T Broadband, RoadRunner, Bell Canada and a host > > of other very large systems use the Openwave product), Microsofts highend > > smtp product uses MSSQL server, Novell's highend system (which > > outperforms most but is expensive) has a database at the backend. > > They're not saying what it is. I suspect its similar to the one they are > > using for eDirectory. they used to use Btrieve for everything, but they > > just recently started shipping MySQL with netware and dropped btrieve > > support. That leads me to believe that MySQL may be at the heart of a > > lot of their services. The next version of *cough* exchange server will > > have MSSQL at the backend. IBM mainframes use DB2 for the message store. > > A database makes a lot of sense for a mail server. The database folks > > have spent a lot of time developing techniques for finding information in > > files rapidly. There is also the issue of scaling to large files. Some > > databases are better than others with that. At the top of the heap are > > MySQL, Oracle and DB2. If you talk to the folks MySQL, namely Monty, > > he'll explain it, but has found that MySQL scales to large files better > > than Oracle does. > > > >I could go on, but I like the idea of dbmail and I'm looking to implement > > it in my hosting business. It makes sense on a lot of different levels. > > The lack of documentation is a hinderance plus the fact that I've been > > working with Sendmail for years and now I'm learning postfix in addition > > to finding ways to implement spamassassin and anti-virus prior to > > dropping the message in the database. I've looked into all of the > > solutions and there is a good commercial product from the folks that > > wrote dnews and even it will use MySQL at the backend. > > > >I've gone on long enough, now back to your regularly scheduled discussion. > > > >Curtis > > > >On Tuesday 22 April 2003 10:38, Chris Nolan wrote: > >>Kiran N S wrote: > >>>Hi All, > >>>I am not an out and out techie, but would still like to know more about > >>>the stability of the PostgreSQL / MySQL database used in case of say, 10 > >>>/ 25 / 50 / 100 / 500 / 1000 users. What are the db restoration > >>> processes executed and how, in case of PostgreSQL or say, McKoi / > >>> MySQL? Somebody, pls shed light on the issue. Can a stabler db like > >>> Oracle be used? > >> > >>PostgreSQL has pg_dump. MySQL has mysqldump. In both cases, you can > >>use 'em while the DB is running. pg_dump gives you a point-in-time > >>snapshot of the entire DB. If you're using the InnoDB table type in > >>MySQL, you can use the --single-transaction switch with mysqldump for > >>the same effect (make sure that you've got your isolation level set to > >>READ_COMMITED in your my.cnf file though). > >> > >>Resotration is easily handled with the command-line clients for each. > >> > >>>Another thing with the usage of MySQL is that it is not an RDBMS, > >>> leading to code complexities when you need to incorporate more > >>> effective productivity-oriented features along with the vanilla e-mail. > >>> Even a simple thing like, say, generating a report on number of e-mails > >>> sent to a particular account with timestamps can be a problem. What is > >>> the way out? > >> > >>Umm...errr...how exactly is MySQL *not* a relational database!?!? > >> > >> > >>From a business strategy point of view, will the introduction of > >>database-centric e-mail servers with/without messaging and groupware > >>functionalities result in a non-competitive offering in the market as > >>better flexibilities are offered through a file storage mechanism? Have > >>other players in the same space already analyzed the database route, > >>discovered it to be full of complexities and opted for a stabler file > >>storage model? Does a database approach speak of unsound strategy and > >> fuzzy R&D or is there light at the end of the tunnel? > >> > >> > >>There is definitely light at the end of the tunnel. > >> > >>Are you familiar with the reasons why database systems are such big > >>business? Basically, a RDBMS solves many of the problems associated with > >>storing stuff in lots of different files through it's fundamental > >>design. Problems of change control, syncronisation and versioning that > >>can cause headaches with distributed files are all solved through > >>database usage. > >> > >>If you're looking for a commercial implementation of "mail in a > >>database" check out Oracle's Collaboration Suite. It's built on top of > >>Oracle 9i and speaks IMAP4, POP3 and MAPI (sort of, enough to be Outlook > >>compatible). > >> > >>Additionally, the massive benefits available when your mail storage > >>backend is a database include, but are not in any way limited to: > >> > >>* Adding more storage becomes trivial and instantaneous - Just add > >>another partition to your database > >>* Backups can happen online, without interrupting anything > >>* Redundancy can be added without bringing down an already existing > >> system * The data store can be accessed concurrently by any app, > >> without needing to worry about file locking or low-level storage > >> mechanisms * Performance, performance, performance > >>* Filesystem limitations (file size limits, filename length limits, max > >>number of directory entries) all become basically null and void. > >>* Data safety! Even though we have XFS, JFS, EXT3 and the almighty > >>ReiserFS in the Linux world (with JFS coming to the BSD world real soon > >>and the other Unixes already having journaling...except that poor joke > >>excuse for a Unix SCO OpenServer), I'll take a transaction-based DB in > >>addition to those thanks! > >>* Security - As the FS is never touched, that's one less part of the OS > >>we (even though indirectly) expose to the world - security flaws in apps > >>can be rectified with less downtime than OS flaws in many cases. > >> > >>The list goes on. Storing stuff in a bunch of files is a simpler > >>concept, but unlike the simple concept that is the Unix paradigm storing > >>stuff in files can cause a lot of problems as you start wanting to do > >>more complex things. Of course, there is a blur between FS and DB > >>storage thanks to those idiots at Microsoft (with Access/Jet and that > >>pile of crap called FoxPro that the other pile of crap ACT! is built on > >>top of). > >> > >>I hope this helps somewhat! > >> > >>Chris > >> > >>>Look forward to hear from all you guys out there... > >>> > >>>Best regards, > >>> > >>>NS Kiran > >>>India. > >>>Cell Phone: +91-98861-12210 > >>>Land Phone: +91-80-333-6173 x-270 > >>> > >>>&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > >>> > >>>"Sometimes you have to take the leap, and build your wings on the way > >>>down." - Kobi Yamada > >>> > >>>&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > >>>_______________________________________________ > >>>Dbmail mailing list > >>>Dbmail@dbmail.org > >>>https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > >>_______________________________________________ > >>Dbmail mailing list > >>Dbmail@dbmail.org > >>https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > >_______________________________________________ > >Dbmail mailing list > >Dbmail@dbmail.org > >https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail
