The shape of the systems are quite different. For instance, DNSBLs. If we queried SpamHaus, or any other DNSBL provider directly, they would instantly fall over. How long it takes to process each email becomes hyper critical...
But you know, these Disk Size Wars are pointless. We're hiring! And if you get the job, you can have the privilege of showing us exactly where we're wrong, driving the corrections thru to Deployment, and reap rich rewards! C# and Exchange experience are ... A Plus. https://careers.microsoft.com/jobdetails.aspx?jid=220173 Aloha, Michael. -- Sent from my Windows Phone ________________________________ From: Rich Kulawiec<mailto:r...@gsp.org> Sent: 3/30/2016 11:48 AM To: mailop@mailop.org<mailto:mailop@mailop.org> Subject: Re: [mailop] Mail accepted by outlook.com/hotmail.com disappears. On Wed, Mar 30, 2016 at 05:37:09PM +0000, Rodgers, Anthony (DTMB) wrote: > Which is exactly what framed the tenor of my question when I originally > asked it. Very Large Providers operate at a scale and under commercial > pressures that most of us (including me) cannot even imagine. Yes, but... If you can run a mail system *properly* for 50,000 people, then you can run it properly for 500 million. It's not really all that different or difficult. The trick is in the word "properly": if you make poor architectural, design, implementation, and procedural decisions, then oh my goodness yes, your life is going to be very tough indeed. I don't want to get into the (many) (many!) arguments over those decisions here, because we've kinda already had them. I'll just say that I see (here and elsewhere) mail system operators encountering problems that they never needed to have. They could have rendered them moot at the whiteboard stage, but either they didn't know, or it looked like a good idea at the time, or management forced it on them, or something else happened, and well...now they're stuck. In some cases, there are interactions between those problems that exacerbate things. Worse, sometimes those interactions cause performance, scalability, or predictability problems. (And anyone who's ever debugged software knows that things that stay broken are easier to diagnose and fix than things that are only broken some of the time.) So that's why a lot of my answers to "how do I fix X?" are of the form "Don't do X, then you don't have to fix it". Well, and because over many decades, I've had ample opportunity to do X, feel the ensuing pain, and realize that it was not a smart move. ;) ---rsk _______________________________________________ mailop mailing list mailop@mailop.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop&data=01%7c01%7cmichael.wise%40microsoft.com%7cb520e5e9388e431ff62c08d358cbde70%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9blq0UpTAjZ%2f9%2flqdWWjKhSqQ%2bdlSUy2GCzFR4Hv9vw%3d
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
