Re: Exchange server alternative?
You know what you also can't do with Gmail create a SOX compliant export for regulators if you get audited.So if there is reason to believe that your companies emails contains data pertinent to the financial transactions of your company and your company gets audited you are in deep trouble. It is also the legal responsibility of the person or people in charge of maintaining the email system to ensure the compliant backups are taken and made available upon request.That's why most large and or financial companies in the united states won't use it.And some times the regulators are the ones who are actually asking for the tap via a compliance officer on some ones emails without managerial approval and its really bad if they can't do that.You can thank Enron for that.-- Sent from my HP Pre3On Feb 9, 2014 1:25, Nico Kadel-Garcia nka...@gmail.com wrote: On Sat, Feb 8, 2014 at 6:53 PM, Paul Robert Marino prmari...@gmail.com wrote: info sec is not the problem it's a record keeping issue. Info sec for email is *always* a problem. It's also critical to the record keeping: the ability to re-route, or delete, or backfill email needs to be handled. (Do not get me *started* on desires to backfill email that never happened, or to silently tap people's email with or without managerial permission! Switching to GMail made it possible for me to say "can't be done!!!" and avoid responsibility for such abuses.) Fortunately, modern IMAP based email systems give easy ways to transfer or replicate email wholesale ti alternative servers, wholesale. Thank you, *gods* for the migration from POP based services, which have mostly disappeared but stored all the folder information on the client. For most clients, they can pretty much cut and paste their old Exchange folders to a new IMAP environment. *Migrating* from Exchange to the new environment takes time and effort. For folks recommending Zimbra or Zarafa, I'd be very curious how they migrate data from Exchange clients. I'm sure that part's not just "drop-in replacement".
Re: Exchange server alternative?
On Sun, Feb 9, 2014 at 8:58 AM, Paul Robert Marino prmari...@gmail.com wrote: You know what you also can't do with Gmail create a SOX compliant export for regulators if you get audited. You mean like the regulations the Google Apps Vault was designed to support? I can see the risks if you've convinced that legal tapping may be committed, to your detriment. It's a risk of any SAAS businesses, and for a company with military or high value international traffic, certainly. Consider the NSA or even foreign intelligence to already have access to all the traffic. But in many environments, *they have it anyway*, without a warrant. The Carnivore email monitoring system is still in place, or a renamed version of it, to monitor email at the backbones of the Internet. In-house email repositories are vulnerable to external abuse of backdoors in firewalls and routers to grab your internal credentials and go poking around your systems, or rootkitted laptops may have already penetrated your systems. Securing against that kind of intrusion is a *lot* of work, and it doesn't usually pay the bills or get glowing project reports on your annual reviews. Using something like Scientific Linux and RHEL for internal services is a good place to start. Handing it off to someone who can afford a very sophisticated group to do precisely that kind of protecton or, as needed, access i often a wise investment. So if there is reason to believe that your companies emails contains data pertinent to the financial transactions of your company and your company gets audited you are in deep trouble. It is also the legal responsibility of the person or people in charge of maintaining the email system to ensure the compliant backups are taken and made available upon request. That's why most large and or financial companies in the united states won't use it. They're learning. Setting up in-house mail systems is fraught with adventures: ensuring high availability, supportability, archival access, and infosec have all grown and evolved. This is where build your own with even a good environment like Scientific Linux gets adventuresome. Setting up reliable backups, firewall control to the servers, good failover, spam And some times the regulators are the ones who are actually asking for the tap via a compliance officer on some ones emails without managerial approval and its really bad if they can't do that. You can thank Enron for that. That gets tricky, and it's not just Enron. Archival of mail beyond the required period is considered, by some, to be a legal liability: whether or not they've been engaged in wrongdoing, it preserves evidence that might be used against them in court. Heck, you should have seen the *outgoing* email filter I was involved in setting up once, to filter all email against a secured database of sensitive content that should not be in email. Creating filters based on data you are not allowed to see is an artform. It also ties directly to backup. Backup is often ignored, or relegated to an afterthought for critical email systems.
Re: Future of Scientific Linux
On Sun, Feb 9, 2014 at 7:44 AM, Henrique C. S. Junior henrique...@yahoo.com wrote: I'd like to know what people think about (possible) future scenarios for Scientific Linux. Let's say: - If SL becomes a CentOS SIG (builded using the CentOS Core) does it still worth the time or will you change to CentOS? Stick with SL. CentOS, historically, has mapped one-to-one with the contents of RHEL. SL has been willing to add very, very useful components to the basic build, particularly hooks kto access third-party repositories such as EPEL and RPMfusion. Those are invaluable to work I do every day, and save me work burining new virtual machines or doing base installs. - If nothing changes and SL continue to be build from SRPMs (with a huge delay compared to CentOS) See above. The delay is not huge, and I'm often forced to schedule package updates for maintenance windows, anyway. A churning set of updates is begging for environment instability in production environments. I've often locked down snapshots of yum repositories, and so that all production hosts work from the same locked down repo, and left ongoing updates active in a separate repo. The RPM contents are hardlinked among them to save disk space on the yum server or network file share: it's pretty effective. - If SL dies to be replaced by CentOS at CERN and Fermi Lab Feel free to add new scenarios. CERN manages to create a black hole and the Earth is eaten, and any astronauts in orbit fly off and colonize Europa?
