Slashdot Mirror

← Back to Stories (view on slashdot.org)

Why Open Source Matters For Sensitive Email

Posted by samzenpus on from the better-mail dept.

Jason Baker writes Can you really trust your email provider? And even if you self-host your email server, can you really trust its security if you can't see the code? Over on Opensource.com, Olivier Thierry makes three cases for using open source to power your email solution: The power of numbers, the value of trust, and the importance of leverage.

73 comments

  1. Paranoia abound by Anonymous Coward · · Score: 4, Interesting

    Can you really trust your email provider?

    Yes, because I'm not a paranoid idiot. If someone wanted to do something malicious with your email, they probably could anyway, because so much of the world's email servers transmit in plaintext, the provider (other than the choice of one that does encrypt when possible) is the least of my concerns.

    1. Re:Paranoia abound by Dutch+Gun · · Score: 4, Insightful

      Even beyond that, e-mail can be encrypted client-side when necessary, meaning you don't have to trust anyone. There's no reason to trust your e-mail provider in the first place if the contents are truly sensitive. For everything else, e-mail should be considered about as secure as a postcard.

      If you need to protect the metadata as well as the content, then e-mail shouldn't even be used for that sort of correspondence. E-mail has never been secure. It probably never will be either, at least not for what we consider "e-mail" today, because there's too much legacy crap that would break if we lock it down (at least if we are trying to secure metadata).

      If we're OK with simply encrypting content as needed, then there are ways of building that sort of infrastructure into the system. We're seeing a lot of 3rd party messaging solutions that are using very good "trust no one" client-side encryption technologies and methods, such as What's App (now that they've integrated Open Whisper Systems security) or Threema.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    2. Re:Paranoia abound by Jack+Griffin · · Score: 2

      And since we KNOW we can't trust our ISPs or Govt, then you may as well give up on using security as a requirement. And since there really is only one product in the Enterprise email/calendar/collaboration space worth a damn and it isn't open source, then this argument isn't worth having.

    3. Re:Paranoia abound by jbolden · · Score: 1

      since there really is only one product in the Enterprise email/calendar/collaboration space worth a damn

      Come on. There are many products that handle email/calendar/collaboration which are better than Outlook. Outlook is a very good standard and rather feature rich for an email client. It is designed to work well with a popular enterprise email solution. But it is far from the richest solution and further still from the only solution. There is even a fairly good solution which is rather close to Outlook feature wise which is open source from VMWare: http://www.zimbra.com/

    4. Re:Paranoia abound by Jack+Griffin · · Score: 1

      Zimbra like Linux on the desktop is a me too solution that's almost there but always not quite. I've been on plenty of projects evaluating Email/Calendar/Collab solutions and Exchange/Outlook shits on everything each time, it's not pure chance that every major corporate network runs it. Lotus Notes is the next closest competitor and it sucks balls.

    5. Re:Paranoia abound by jbolden · · Score: 1

      Every major corporate network does not run Outlook. I've worked with enterprises that use in house solutions. There are corporations on Google. I've worked with many major corporations that use Lotus Notes example BTI. Texas Instruments uses Zimbra which is a major corporation. Novell Groupwise is used by corporations. Mirapoint & CriticalPath are still in use and migrating their customers not to Outlook / Exchange but to Open-Exchange. I know several hospitals that were on Scalix up till a few years ago.

      You are simply wrong on the facts.

    6. Re:Paranoia abound by Jack+Griffin · · Score: 1

      Yeah quite obviously IBM use Lotus Notes and Google use Gmail, I was making a point that Exchange/Outlook still takes the lion's share of the market, and there is a reason for that.

    7. Re:Paranoia abound by jbolden · · Score: 1

      "it's not pure chance that every major corporate network runs it." is not "Exchange/Outlook still takes the lion's share of the market,"
      Those are very different statements. You were defending the statement, " there really is only one product in the Enterprise email/calendar/collaboration space worth a damn " which is why you had to make the case it was the unique solution.

      The fact is Exchange/Outlook is a pretty good solution. But it is far from the only solution or only viable solution. The big features that Exchange offers like shared calendaring just about every piece of groupware offers. Outlook is a good mail client and certainly office integration is the best of any of them. That probably is why it is so heavily used.

      Your "sucks balls", "worth a damn"... is well beyond the actual situation.

    8. Re:Paranoia abound by Jack+Griffin · · Score: 1

      Yes you certainly got me there. You must be fun at parties...

  2. Because EVERYONE is qualified to read code by Anonymous Coward · · Score: 1

    Especially encryption code necessary to truly protect your email.

    Jeez, what color is the sky on your planet?

    1. Re:Because EVERYONE is qualified to read code by Neil+Boekend · · Score: 1

      Brownish white with some moisture stains in the corner over there.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
  3. Open Source not a silver bullet by i+work+on+computers · · Score: 5, Insightful

    We've seen over the last year many open source, power in numbers projects have critical vulnerabilities waiting to be exposed. Those defects were sitting there for years, yet being open source didn't magically fix them. I use many open source tools, but I've never inspected the code myself. Even if I did, I'm not going to be finding these hard-to-find defects that the people in the project can't find. I'm not going to implicitly trust an open source project just because it's open source. How do I know who's really contributing? At least if Apple is doing something naught with my iCloud email, at least in theory I can join a class action lawsuit and get a free download from iTunes. If the NSA is inserting nefarious code into an SSL project, there's really no recourse for action. Over the last year, I've learned that the key to internet security is that it doesn't exist. If there's something that really so sensitive, maybe you shouldn't email it.

    1. Re: Open Source not a silver bullet by Anonymous Coward · · Score: 3, Insightful

      Also of import: what's the status of turnkey open source email packages these days anyway? What is out there that exchange admins can switch to that won't make them hack on features or make their users ask WTF they just did? That is the elephant in the room and the million dollar question.

    2. Re:Open Source not a silver bullet by Anonymous Coward · · Score: 1

      How do you know you aren't just a brain in a vat? You can't trust anything, man!

    3. Re:Open Source not a silver bullet by Anonymous Coward · · Score: 1

      We've seen over the last year many open source, power in numbers projects have critical vulnerabilities waiting to be exposed. Those defects were sitting there for years, yet being open source didn't magically fix them.

      Precisely! In theory it could be more secure but in practice, as we have seen, you could have a critical bug sitting there, unbeknownst to users, being exploited for decades before somebody fixes it. Open source is not a silver bullet for security!

      I really genuinely wish people would stop tarnishing the name of open source with these garbage articles about theoretical benefits. Open source has many significant advantages, this is not one of them and crap like this is going to lead to dismissal of open source on the basis that its supposed benefits are unfounded.

    4. Re:Open Source not a silver bullet by Artifakt · · Score: 2

      How do you know there's a real vat?

      --
      Who is John Cabal?
    5. Re:Open Source not a silver bullet by Yaztromo · · Score: 1

      I use many open source tools, but I've never inspected the code myself. Even if I did, I'm not going to be finding these hard-to-find defects that the people in the project can't find.

      From a security perspective, even just having and being able to inspect the code is insufficient if you need top-notch security: you had better also be compiling that code yourself. It is nearly impossible to be able to verify that a binary blob didn't contain additional/modified code than what the sources contain without compiling it yourself. And even with being able to compile everything yourself, you're still at the mercy of the build chain and all of its dependencies (unless you audit/build them yourself too).

      Open Source is still better in this regard than closed source, of course -- at least you have the ability to compile it yourself if security is that critical. I think the problem for a lot of organizations is that security isn't critical enough for them to hire people to a) audit the code and b) build, test, and verify it for their own internal use. In which case, it would (at least form outward appearances) be cheaper/easier to go with a closed-source solution, with someone behind it whom you can blame/sue if things go sideways.

      Yaz

    6. Re:Open Source not a silver bullet by exomondo · · Score: 3, Insightful

      From a security perspective, even just having and being able to inspect the code is insufficient if you need top-notch security: you had better also be compiling that code yourself.

      With a verified compiler no less. We have seen ever more sophisticated malware these days, certainly a malicious compiler could easily slip vulnerabilities into the binary.

    7. Re:Open Source not a silver bullet by Anonymous Coward · · Score: 1

      The trouble with proprietary software is that those defects will persist forever. And, if the NSA inserts nefarious code into a proprietary TLS/SSL project, you'll still never know, and you'll still have no recourse. If it was open source, at least there's a chance it will get noticed and fixed.

      Someday, we might have formally verified open source security software. But, that's not really a valid point until we start seeing it, and making formally verified software is hard.

    8. Re:Open Source not a silver bullet by BarbaraHudson · · Score: 2

      How do you know there's a real vat?

      How do I know YOU are real?

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    9. Re:Open Source not a silver bullet by Dutch+Gun · · Score: 2

      And even with being able to compile everything yourself, you're still at the mercy of the build chain and all of its dependencies (unless you audit/build them yourself too).

      It seems a bit foolish to worry about purely theoretical security issues when we've got so many real ones to deal with. Ken Thompons' compiler infection demonstration was an interesting experiment designed to make a particular point, but I don't think it's wise to consider tool-chain hacking a legitimate threat, as we've never seen anything remotely like this in the wild, as far as I'm aware. And frankly, I question whether it's even realistically possible beyond a very simplistic demonstration.

      At some point, theory has to give way to practicality, and you have to use some good judgment and common sense. Humans have to use a "chain of trust" at some point, because if you took the time to independently verify everything yourself (even assuming you had the expertise), you'd never get anything practical done. In fact, just about everything we do in our society at a high level of technology or craftsmanship ultimately requires relying on and trusting in others to assist you, at least to some degree. Security is no different. You have to weigh the probabilities of hypothetical threats versus limited resources to deal with those threats and do the best you can with the resources available. Diverting your attention on unrealistic threats will ultimately make you less secure, not more.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    10. Re:Open Source not a silver bullet by Yaztromo · · Score: 1

      With a verified compiler no less. We have seen ever more sophisticated malware these days, certainly a malicious compiler could easily slip vulnerabilities into the binary.

      Yup -- I intended that to be considered part of the build chain. Compiler, standard libs, any 3rd party library dependencies, the build tools themselves (have to make sure they're using the libs you expect them to...), the OS kernel...right on down the chain.

      Yaz

    11. Re:Open Source not a silver bullet by Yaztromo · · Score: 2

      It seems a bit foolish to worry about purely theoretical security issues when we've got so many real ones to deal with. Ken Thompons' compiler infection demonstration was an interesting experiment designed to make a particular point, but I don't think it's wise to consider tool-chain hacking a legitimate threat, as we've never seen anything remotely like this in the wild, as far as I'm aware. And frankly, I question whether it's even realistically possible beyond a very simplistic demonstration.

      First off, naturally the level of security I'm talking about would probably only be reserved for national governmental agencies intended to protect ultra-sensitive data. For them, that level of security is necessary, and they will spend the money and resources to audit and verify everything if necessary (which is why we have SELinux).

      Additionally, the build chain comprises not only the compiler, but the standard libraries and any third-party libraries as well. If not verified, these could easily have unexpected code inserted into them, that compromises your product once linked against them. You wouldn't expect to see such compromised libraries "in the wild", as they would probably part of a targeted attack. This is hardly unprecedented; while not done at build time, Stuxnet uses DLL replacement on Windows to add extra routines to the operating system, which are used to inject code being uploaded into a PLC.

      Again, most organizations don't care to undertake the kind of expense required to protect against such attacks; they use the chain-of-trust you describe. However, national security organizations do work at this level, and if you need that level of security, pre-compiled binaries, whether they come with source or not, is insufficient.

      Yaz

    12. Re:Open Source not a silver bullet by Dutch+Gun · · Score: 1

      Yes, national security agencies probably think at that level, because they can afford to think at that level - same with top industry security experts such as Bruce Schneider. Even so, I'd still posit that it's still very much a hypothetical threat or method of attack. It's fun to theorize about what-ifs, but we should probably recognize it as such, with the understanding that it's not really relevant to nuts-and-bolts security issues in the real world. There's a pretty significant difference between "this is theoretically possible" versus "this has a reasonable chance of ever occurring".

      BTW, even early and very rudimentary viruses such as the old "happy99" virus replaced a Windows DLL to inject itself into outbound traffic. Unless I'm misunderstanding something, I don't think that's really an example of what we're talking about here. Stuxnet was hella impressive for a lot of other reasons, of course.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    13. Re:Open Source not a silver bullet by mrchaotica · · Score: 1

      ...and bootstrap the whole thing by cross-compiling on several unrelated kinds of hardware (ideally including some old enough that maybe nobody had thought to put backdoors in it yet), and then checking that the resulting binaries are identical. Maybe use a 386, an ARM or PowerPC, and something Chinese, for example.

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    14. Re:Open Source not a silver bullet by organgtool · · Score: 1

      We've seen over the last year many open source, power in numbers projects have critical vulnerabilities waiting to be exposed. Those defects were sitting there for years, yet being open source didn't magically fix them.

      I can't deny that - the "many eyes" argument hasn't quite held up over the years. However, the reason I prefer an open source solution is because they tend to acknowledge and fix the issue much faster than their closed source counterparts. Most of the serious security issues in open source software have a fix released within 24 hours. It takes many closed source organizations much longer than that to even admit that the problem exists. Worse yet, some vendors will deny the problem indefinitely or tell you to migrate to their new platform (which is obviously incredibly costly). With open source, you're free to fix the issue in-house or contract someone to do the work if the vendor is uncooperative.

      Over the last year, I've learned that the key to internet security is that it doesn't exist.

      That's the sad reality and it's completely independent of the licensing model of the software you use.

    15. Re:Open Source not a silver bullet by steveg · · Score: 1

      Ken Thompson modified the original C compiler to put a back door into the Unix login program, as well as to modify any compiler that was compiled with that compiler to include the backdoor function. So for generations of code, and backdoor was inserted, with no evidence of its existence in any code you could examine.

      http://cm.bell-labs.com/who/ke...

      --
      Ignorance killed the cat. Curiosity was framed.
  4. Not really ... by BarbaraHudson · · Score: 3, Insightful

    Unless you're using encryption, it doesn't matter, since there are many points of 'interest" between the sender and receiver.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    1. Re:Not really ... by Kjella · · Score: 2

      Unless you're using encryption, it doesn't matter, since there are many points of 'interest" between the sender and receiver.

      Yeah, for external mail no doubt. But for internal mail you probably wouldn't bother, then it's a pretty huge juicy target for sensitive information. Even when you're not passing the juiciest details by email like blueprints and source code there'll be tons of business information in attached presentations and so on.

      --
      Live today, because you never know what tomorrow brings
    2. Re:Not really ... by BarbaraHudson · · Score: 0

      For that, use storage encryption.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    3. Re: Not really ... by Anonymous Coward · · Score: 1

      Internal mail is easier to encrypt if your clients use provisioned SMIME certs. Set up an internal CA and push its root to all devices, thrn generate keys for users and push them to the right places for your OS/mail app combo, and most mail apps will use them automatically or with some minimal config that you can push to your network. Keep a backup of employees keys for data retention policies so you can recover subpoenaed mail. You can still be defeated by a determined adversary who gets the private keys from the computers or installs keyloggers, but you're a much, much harder target.

  5. Trust by Michael+Woodhams · · Score: 3, Insightful

    Sigh. Now somebody is going to bring up Ken Thompson's "Reflections on Trusting Trust" in 3... 2... oops, too late.

    --
    Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
    1. Re:Trust by Anonymous Coward · · Score: 1

      What are Bennet Hasselton's thoughts on Ken Thompson's "Reflections on Trusting Trust"?

  6. It doesn't matter what you run at your end by Anonymous Coward · · Score: 0

    Since the person at the other end is probably using gmail, which at minimum is a far juicier target.

  7. Can you really trust open source? by Anonymous Coward · · Score: 0

    If you haven't studied the program for months or years, personally, can you really trust it?

    1. Re:Can you really trust open source? by BronsCon · · Score: 1

      At the very least, no less than I can trust closed source.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  8. Fucking Clickbait by Anonymous Coward · · Score: 1

    There was no informational value at the linked page. All of those arguments have been made/refuted many times over the years. If you're actually worried about email security then a self-hosted open-source mail server isn't going to help you... you need to be using encrypted mail.

    1. Re:Fucking Clickbait by BarbaraHudson · · Score: 2
      What do you expect? The guy who wrote this is just a marketing troll.

      Olivier Thierry is the chief marketing officer of Zimbra, and has more than 30 years of experience increasing market visibility and developing go-to-market strategies for high-volume software organizations,

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  9. qmail! by Anonymous Coward · · Score: 0

    wait people use something other than qmail?

    I think I setup qmail back in the y2k hubbub, and it's been running on the same dx66 processor ever since.

  10. Stupid article is stupid by Anonymous Coward · · Score: 5, Insightful

    Open source is a source licensing model. It has no magic powers for creating secure solutions to anything.

    Stupid headline: Why open source matters for sensitive email
    Stupid headline: Why closed-source matters for sensitive email
    Smart headline: Why security matters for sensitive email

    Code audits for security defects can happen regardless of source licensing model.
    Coders authoring a service, no matter how security conscious, and no matter how many eyeballs they have, will likely miss many exploitable defects.

    1. Re:Stupid article is stupid by chromaexcursion · · Score: 2

      Sadly this was posted by an Anonymous Coward. Few will ever see it. The default is to view at +1. cowards post at 0. Took modding for me to learn that.
      It points out yet again people are mistaking open source with security.
      You'd think after heartbleed a few would have caught on.

    2. Re:Stupid article is stupid by Anonymous Coward · · Score: 0

      Code audits for security defects can happen regardless of source licensing model.

      If the software is closed-source, you can't trust the audit: if the authors of the software are deliberately inserting vulnerabilities, they can conceal them from an audit (by as simple an expedient as giving them the wrong code).

      Coders authoring a service, no matter how security conscious, and no matter how many eyeballs they have, will likely miss many exploitable defects.

      This part is true. I'm starting to think that the solution is not to keep trying to fix the codebase, but to cut it down to some minimal functionality that is reasonably likely to be completely secure. If it isn't, cut it down further.

      Take the example of the Heartbleed bug in OpenSSL. The heartbeat functionality provided a small convenience in a limited range of situations - and also produced a risk of a security vulnerability that compromised the entire package. I think the LibreSSL people are responding to this correctly, by completely cutting out this and various other pieces of extraneous functionality.

    3. Re:Stupid article is stupid by AmiMoJo · · Score: 1

      Open source does matter for any security sensitive software, which these days is pretty much all of it. It's not that open source is inherently more secure than closed source, it's that the support is better.

      When a vulnerability is found in closed source software someone has to contract the vendor. That in itself can be difficult. Then they take some time to fix the problem, maybe months or years, and until then the problem remains secret. With open source it's usually easy to contact the developers, the person who found the problem can often go to them with a patch to fix it ready for testing, and the issue becomes public quickly so people can take action.

      In addition, it's much easier to trust source code you can compile yourself than a closed source binary blob. There might still be backdoors, but the risk of them being found is much greater.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  11. FOSS email LONG before Exchange, most mail FOSS by raymorris · · Score: 4, Informative

    Email was flowing through open source systems for DECADES before Exchange came out. Today, the vast majority of mail is handled by open source systems.

    If you're accustomed to Exchange and want to get that same bloated feeling without the six figure license fees, there are many open source packages designed,for that. Examples include OpenChange, Open X-change, Zumbra, Citadel ...

    Of course the vast majority of mail is handled more in the Unix philosophy, rather than one software package that thinks it's a file server (SMB), an MTA, an MDA, a groupware calendar, an IMAP server, and six other things it does poorly, the normal Unix way is if you want IMAP, you install a good IMAP server by clicking on or typing "dovecot". It doesn't have a buggy, insecure file server sticking the out the side that you never asked for.

    1. Re:FOSS email LONG before Exchange, most mail FOSS by Anonymous Coward · · Score: 0

      Which of those offers a push email/calendar solution that I can use to get calendar and email on my iphone? AFAIK Exchange is the only option for that.

  12. X.org? by nickovs · · Score: 2

    If I was publishing an article talking about how huge numbers of eyeballs solves security problem I'm not sure that I'd choose to publish it the day after it was announced that the X window server code has had some serious security bugs for 25 years that have only just been discovered. Clearly open source code can have serious security holes that go unnoticed for a very long time.

    --
    If intelligent life is too complex to evolve on its own, who designed God?
    1. Re:X.org? by Neil+Boekend · · Score: 2

      In that the main difference with closed source is that open source shows it's dirty laundry. Why do you think a closed source solution would not have flaws of similar severity?

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    2. Re:X.org? by Anonymous Coward · · Score: 0

      Open or closed source does not make a significant difference in vulnerabilities. What makes a difference is the quality assurance and testing phase. Yes there are closed source projects with no testing, the current refuge for such behavior is in phone applications. Yes there are open source projects with thorough testing, most noticeably those with Google or Microsoft backing.

      The problem comes when you start to assume that open source means there is no need for testing, because someone else will spot any problems and either fix it themselves or use the open-source bug reporting utility you copied over for your project. That sometimes works for functionality bugs, and almost never works for security bugs.

  13. Re: FOSS email LONG before Exchange, most mail FOS by Anonymous Coward · · Score: 1

    Zimbra. There are probably others: five minutes of Googling will net you answers. Or install an IMAP mail server and a separate calendaring program on the same server, and your clients won't notice that they're two programs. Ports are just standard interfaces for standard APIs.

  14. All- OpenChange, Citadel, Zimbra .. + RSS Faceboo by raymorris · · Score: 2

    All of the packages I mentioned provide that. Not being tied to Microsoft's ecosystem, they can also integrate your Facebook, Twitter, rss, or other notifications.

  15. Re:All- OpenChange, Citadel, Zimbra .. + RSS Faceb by Anonymous Coward · · Score: 0

    No they all require me to use their mail client as well as their server to accomplish that. People use Exchange because it works with everything, having to change all your email clients just because you changed the email server makes that unfeasible.

    Push email is easy if you are willing to have a custom client but that is what people are not willing to do otherwise Exchange would have been abandoned long ago.

  16. Open source client does by iamacat · · Score: 2

    Truly sensitive e-mails should be encrypted, so open source and other characteristics of the service do not matter.An ideal client would support zero knowledge multihop forwarding so that even sender/recipient metadata can not be analyzed.

    1. Re:Open source client does by Anonymous Coward · · Score: 0

      I'm glad I'm not the only one thinking such things.

  17. Re:All- OpenChange, Citadel, Zimbra .. + RSS Faceb by jrumney · · Score: 1, Informative

    You've got that backwards. Exchange is the one that requires proprietary clients (it just happens that the major smartphone vendors include proprietary ActiveSync clients out of the box). The others listed use standard IMAP+LEMONADE extensions (which admittedly isn't widely supported by desktop clients, because they generally don't need it).

  18. Email is not suitable for sensitive material by dbIII · · Score: 2

    If you are using email for sensitive material then you are ignoring decades of warnings from everyone with a clue about email.

  19. Re:Paranoia is actually warranted these days by Anonymous Coward · · Score: 2, Insightful

    Trust? Let me tell you about trust, there is no more trust...
    You cannot trust Microsoft, or Google or anyone else with your mail for that matter. Every commercial mail provider and software maker is either already in bed with your adversary, or subject to your adversaries whim. For that matter, you cannot trust the 1.5 BILLION transistors in your CPU. But let's ignore that for now.
    You CAN generally trust open source software for your MUA and MSA/MTA, and for your crypto.
    You NEED crypto.
    Then, you cannot send your encrypted mail through stupid commercial mail providers. It STILL exposes who you are mailing, from where, when, and the subject line, when your recipient was on to get it, etc, etc.
    And you CANNOT use stupid "webmail' that says they will encrypt your mail for you, because you are either giving up your keys to them or letting them take control of your browser... exactly like the safe-mail.net debacle, you're going to get screwed.
    So you both MUST use crypto AND use an anonymous Peer-to-Peer direct messaging service.
    Think I2P-Bote, or ImperialViolet's Pond, or BitMessage... something where your message is sent directly over the anonymizing network straight to your recipient, or so that only they can see any part of it... NOT off to sit on some centralized server that will get subpoenaed and snooped and raided.
    In summary, get this straight folks....

    USE crypto AND use an anonymous Peer-to-Peer direct messaging service.
    It is the ONLY way your messages will ever be private to only you and your correspondent over the wire.

  20. Why marketers should not write articles. by bloodhawk · · Score: 1

    Perhaps rename article. "An Example, Why marketers should not write articles"

  21. Trust is of utmost value by thegarbz · · Score: 1

    What an absurd statement this is making. I like the one about "Trust is of utmost value". No, not at all and let me explain why.

    If I use open source software I use binaries. I have no more faith in those binaries than any other piece of closed source software, there's no guarantee that the binary matches the source, even if the source is somehow magically free of bugs because as we all know open source is infallible.

    Ok so there's the potential for me to do an audit. So I have the choice, I could sit down and decompile the binary and audit it against the original source code, or I could download the source code and compile from source. Which now raises the question:

    "Who in their right mind would go to this much effort securing software used to send plain text data over unsecured servers scattered around the internet?"

  22. I give money, company gives me product by Anonymous Coward · · Score: 0

    Can you really trust your email provider? And even if you self-host your email server, can you really trust its security if you can't see the code?

    Why not? They are companies with financial responsibility. If they want to keep their customers, I am sure they strive to do their job properly.

    For most products that I buy, I do not have list of the ingredients or specific knowledge about their manufacturing process. However, if they screw up, I will certainly buy from another vendor.

    It is that fucking simple. What's up with this open source verification paranoia these days?

  23. Yea right by Anonymous Coward · · Score: 0

    My wife teaches in a school district using Zimbra mail a open source project. Been hacked twice and they had to shut it down twice because everything became so
    corrupted. Open source has nothing to do with protecting information. Any email system gets hacked because of stupid users who open malware laced documents or files.

  24. Open Source == DOES get a fine tooth comb. by Dr.+Crash · · Score: 1

    I am the prime author of CRM114 (the spam filter) and IT DEFINITELY GOT CHECKED BY SMART PEOPLE. There were at least a dozen people who would dependably read the code, and they'd find the pickiest things (luckily, not anything serious; thank you Valgrind!)

    So, it's absolutely, demonstrably, provably (read the mail archive!) the case that at least SOME mail-oriented open source gets the all-orifices examination, and that examination is effective.

    Whether or not security software gets the same thing, I can't say for sure, but I'd be surprised that it didn't. The recent set of security vulnerabilities only shows that old code didn't get the same care as newer code.

  25. Open Source matters for sensitive *anything* by Qbertino · · Score: 1

    Captain Obvious submitted again.

    Open Source matters for sensitive anything. In fact, I, and any professional I've talked to, would say if it's not FOSS or at least using a free open standard in data format, it's of no use for anything sensitive or mission critical. We've arrived at the point where critical systems that are not FOSS aren't even considered to be enterprise ready by a large portion if not even the majority of IT experts. Which is a good thing, IMHO.

    For instance, anybody nowadays talking Unix and not thinking of a FOSS *nix but suggesting something other (exotic I guess you'd call it today) would be laughed out of the room. One of the reasons I find RMSes insistence on the GNU/Linux term a tad backwards - although he is right about most of the important things.

    --
    We suffer more in our imagination than in reality. - Seneca
  26. Re: All- OpenChange, Citadel, Zimbra .. + RSS Face by Anonymous Coward · · Score: 0

    I use Zimbra. I've used a variety of other mail and calendaring servers including Office365, Gmail for business, Novell Geoupwise and some proprietary stuff. Except for Groupwise (and this was 15 years ago at least) it all delivered mail and calendar services via standard protocols (imap, caldav or something else widely understood). I never figured out how to share calendars with someone in Office 365, which was a clunky and ugly beheamoth, even worse than Groupwise, but I digress: your server choice almost never impacts your client software, because email and calendaring use standards and are highly compatible. It's like web browsing: changing your server doesn't mean that your readers change their browser. Also, fuck Groupwise.

  27. Completely making that up by raymorris · · Score: 1

    Now you're just completely making stuff up. How do you think email worked for the 25 years before Microsoft said "me to"?

    1. Re:Completely making that up by Anonymous Coward · · Score: 0

      Now you're just completely making stuff up. How do you think email worked for the 25 years before Microsoft said "me to"?

      No you are just not reading. You see where I explicitly said "push" email? No? Well you need to read it again. The way email worked before Microsoft brought ActiveSync with Exchange was for the clients to periodically poll the email server.

  28. Re:All- OpenChange, Citadel, Zimbra .. + RSS Faceb by Anonymous Coward · · Score: 0

    You've got that backwards. Exchange is the one that requires proprietary clients

    Where did I say Exchange didnt require proprietary clients? Im pretty sure if you go back and read it again you will find I didnt say that at all.

    it just happens that the major smartphone vendors include proprietary ActiveSync clients out of the box

    Right and since all these other alternatives use non-standard (ActiveSync is at least a defacto standard) push email mechanisms they are not included in any major vendors' email clients. This *is* the barrier to entry, that is precisely the reason that pretty much everybody still uses Exchange.

    The open source community is a slow follower, it takes so long to produce a comparable solution that by the time it exists the proprietary one has already become the defacto standard. It is the same in almost every product category, proprietary industry comes up with something and then the open source community tries to come up with their copy of it, it takes forever to become usable and ultimately doesn't get widely adopted. There are some outliers but this is the general rule.

  29. IMAP PUSH, RFC 3501 by raymorris · · Score: 0

    RFC 3501is the standard for imap, including PUSH. You call Exchange Activesync "a de facto standard" - IMAP is an ACTUAL standard, and it includes push.

    Btw, you called it ActiveSync, but that's the name of an older,mostly unrelated protocol, used with a PDA cradle connected to the serial port. You're thinking of Exchange ActiveSync. The difference is kind of like York vs New York; similar names, totally different things.

    Fyi, with each post you only re-emphasize how completely and utterly clueless you are about these things.

    1. Re:IMAP PUSH, RFC 3501 by Anonymous Coward · · Score: 1

      RFC 3501is the standard for imap, including PUSH.

      It uses IDLE, which, given the amount of overhead, is not suitable for mobile devices which is why P-IMAP and Lemonade are in development. Do you understand that? Probably not.

      You call Exchange Activesync "a de facto standard" - IMAP is an ACTUAL standard, and it includes push.

      The IMAP standard contains IDLE which is inappropriate for mobile devices, which is why they dont support it. Oh but you didnt know that did you, that is why you just provided your stupid incorrect reply.

      Btw, you called it ActiveSync, but that's the name of an older,mostly unrelated protocol, used with a PDA cradle connected to the serial port. You're thinking of Exchange ActiveSync.

      I said "Microsoft brought ActiveSync with Exchange", clearly that is what I meant, in fact you even stated it "you call Exchange Activesync...". I wouldn't expect to need to iterate every little detail because mouthbreathers such as yourself cannot comprehend context.

      Don't pretend you don't know what I'm talking about when you explicitly stated in the previous sentence that you do, if the context provided confusion you would have asked but you know the context made it clear which is why you didn't.

  30. and wrong again by raymorris · · Score: 1

    > It uses IDLE, which, given the amount of overhead, is not suitable for mobile devices which is why P-IMAP and Lemonade are in development

    And wrong again. Per the current draft, P-IMAP devices are REQUIRED to support IDLE. SMS and WAP are optional. P-IMAP uses doesn't replace IDLE, it uses IDLE.

    Also note Exchange ActiveSync uses a heartbeat protocol very similar to IDLE - with pretty much the same problems. The content of the packets are a bit different, the overall scheme is rather similar.

    You're on Slashdot, not at the bowling alley. Here, some of us actually know a bit about this stuff. Some of us are even IETF members and help write the standards that you've apparently never heard of, much less read.

    1. Re:and wrong again by Anonymous Coward · · Score: 0

      And wrong again. Per the current draft, P-IMAP devices are REQUIRED to support IDLE. SMS and WAP are optional. P-IMAP uses doesn't replace IDLE, it uses IDLE.

      Where did I say it replaces IDLE? Oh right, I didnt but yet again you failed to read. What I said was that IMAP does Push purely through IDLE, which is very inefficient for mobile devices.

      Also note Exchange ActiveSync uses a heartbeat protocol very similar to IDLE - with pretty much the same problems. The content of the packets are a bit different, the overall scheme is rather similar.

      Yet it doesnt fail on the same inefficiencies that IDLE has which is precisely why P-IMAP (augmenting the IDLE command) and Lemonde are in development and why Exchange ActiveSync is the defacto standard for efficient push email.

      Here, some of us actually know a bit about this stuff.

      Clearly not you, you cant even read, your response to my first post was completely wrong.

      Some of us are even IETF members and help write the standards that you've apparently never heard of, much less read.

      Again, obviously not you otherwise you would understand why IMAP is not a viable solution for push email on mobile devices and why Exchange Activesync provides the best and most efficient push email for mobiles. We have had email for decades and email on mobile for the past decade yet open source and open standards are so damn slow to follow proprietary products that we *still* dont have a decent solution for something as simple as push email.