Slashdot Mirror
Yahoo's Amazing Disappearing Mail Servers
Golygydd Max writes "A Techworld story reveals that the reason Yahoo email has delivery problems is that the company's mail servers mysteriously close once in a while." From the article: "According to trimMail's Email Battles site, which recently monitored 16 of the company's advertised email hosts 240 times over a half hour period, only 133 of its probes were answered. Many of the servers were closed and unavailable. Overall availability ranged from 25 percent to 75 percent over the admittedly short test period. The average availability was 55 percent, with the worst of the servers available only 7 percent of the time."
I was under the impression that Yahoo! mail was free. Isn't the rule you get what you pay for? Seriously though, why would Yahoo put a ton of money into something which is not a revenue generator. Free email is so yesterday.
And if you don't like what I am saying you can reach me at:
server-never-works@yahoo.com
and really let me know how you feel about this. Well, you can at least reach 7 to 55% of the time.
Quality Hosting e3 Servers
Servers being down some of the time shouldn't cause large-scale delivery problems. Remember, when e-mail protocols were being designed, a lot of these servers were down for a good portion of each day. E-mail protocols were designed to deliver e-mail in whatever window existed. If the receiving server is down, the sending server will try again for a good while before giving up.
Also, as someone else has already mentioned, there are the MX priority lists...
This is hardly a news story. Tomorrow: 100% of people on my front porch stub their toe at 10:19am on Friday morning. Porch declared a national disaster zone, FEMA are organizing evacuation flights.
Email is DESIGNED to handle failures of this kind. Assuming Yahoo is running some form of clustering, it's quite reasonable to think that systems will start/stop as load fluctuates. Availability of individual servers is largely irrelevant - it's the availability of the system at large that matters.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
240 times over a half hour period is a high rate of connections per server (8 per minute per server), especially for email servers, so is it possible that Yahoo!'s servers were simply defending themselves against a perceived threat? Connection throttling was the first thing that came to mind on reading the blurb.
Yahoo is actually doing the right thing here, from a technical point of view. The worst thing you can do is have an MX that accepts connections but is not responsive enough to actually handle accepting a message at that point -- it's far better to stop accepting SMTP connections when you detect you're at your maximum capacity.
This is because SMTP clients who fail to get a connection will immediately try the next MX. If they get a connection, but can't send the message, they may back off and try again later, delaying the message further.
--
Twoflower
Yahoo is a heavy user of greylisting. I would expect any of their servers to break connections, refuse connections and even deploy firewall rules including tarpitting to anything their greylisting algorithm finds annoying. In fact I am pretty sure about the first two, dunno about the last item. I am planning on doing it on the servers I run, I would be surprised if they do not have it already. After all they have a huge department that does nothing else but mail for themselves and their resale customers.
Move along people, simply the dot.bomb times are back. Yet another metric company making big noises about the fact that someone BIG looks bad on their metric. Reason is most likely that the metric is badly designed and does not take current large scale mail handling practices into account. We have all been there a few years ago when everybody and his dog was pushing metrics around just before the bubble collapsed. Move along, nothing new here.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
You are amazingly pretty much on target.
95%+ of the SPAM reduction on Yahoo is due to the use of greylisting. Essentially the mail server simulates that it is unavailable to anyone it does not know as a well behaved relay. A well designed MTA will come back and deliver the mail later and the server will accept it. A SPAM zombie will skip to the next target.
A probe will be judged a zombie until proven opposite. A probe that does not try to deliver mail or do anything usefull will cause the SPAM ranking of the originating IP to go up until firewall shielding rules are deployed. From there on you cannot even reach the servers in question until the entry expires. In addition to that well behaved MTAs go to MXes in a predictable order. Anything hitting MXes in a different order is immediately considered a SPAMBOT and will cause the greylisting code to either set a "refuse" with a high timeout on it or (if the code is there) to raise firewall shields outright to tarpit any connections from the BOT. This also essentially disallows you to test any specific host for MX connectivity without testing the entire MX pool in correct order. If you do, you guarantee yourself a blacklist entry which will be generated automatically on the fly.
By the look of it this pretty much summarises what has happened here. Quite funny actually. It is indicative of the current crop of "security companies" and professionals. They claim understanding of security without knowing how things are done.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/