For my org, I have all my filtering on a single server (well, a pair in parallel, but you get my meaning). But that's not going to work for Hotmail.
Hotmail undoubtedly has multiple levels of filtering. Each check they do with the SMTP connection open increases the connection time and decreases the number of connections the server can handle, making more servers a requirement. 1. MX server: accept thousands of connections a minute. They might have time to check those connections for RBL, might not. They probably also check for valid recipient addresses and recipient limits. Maybe mailbox space. 2. Antivirus filtering: Emails with HTML and attachments, get sent to the antivirus scanners. Plain text emails might bypass this step and go to the next step. 3. Text filtering: Text is analyzed for spam words. 4. Image filtering: Emails with inline images, get sent to the inline image spam detection servers. Other emails bypass this step. 5. Routing: Emails get routed to mailbox servers. I'm just guessing at all that, but you'll agree that doing all that with an option connection is going to dramatically increase the number of servers needed. -----Original Message----- From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Rich Kulawiec Sent: Wednesday, March 30, 2016 1:42 PM To: 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
