Admins Accuse Microsoft of Hotmail Cap 166
kurmudgeon writes "The Register is fielding reader tips that Hotmail has placed Draconian limits on the number of Hotmail recipients who can receive an email. The first 10 Hotmail addresses included in a mass email go through just fine, according to these reports. But any additional addresses are returned to sender with a message that reads: "552 Too many recipients." (Microsoft denies it has placed any such restriction on the number of senders.) This would appear to be a violation of RFC 2821, which states: "Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification."
And the problem is...? (Score:5, Interesting)
Let's look at that phrasing: "Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification." (emphasis added).
Are they rejecting messages, or are they rejecting recipients?
According to this, they're rejecting recipients with an obvious "try this again" code. Really that should be 452, not 552, but that same RFC 2821 says that senders should treat a 552 as temporary:
So whatever sending server runs into these limits should retransmit the message to the remaining recipients on the next queue run. Okay, it'll only reach 10 recipients at a time, which is annoying. It shouldn't be kicking back the error to the client.
Really, assuming Microsoft has actually put this limit in place, the only thing I can see that's wrong, from a practical standpoint, is using the outdated 552 code instead of the more specific 452 -- but that same RFC people are waving around says that their servers should treat it as temporary anyway.
Am I missing something?
Hotmail is unreliable anyway (Score:5, Interesting)
Our (100% legitimate, double opt-in) mailing list gets a few Hotmail addresses added to it every now and then. We frequently get people complaining about missing mails and so on. Invariably, it's because of something silly, usually spam filtering that has been set to be so ludicrously aggressive that practically anything not white-listed (i.e., nothing on a new account) gets through.
We have now reached the point where we consider Hotmail an irrelevance. We don't even advise complainants to use another mail client any more, we just ignore them. The list is not run for profit, and the effort of supporting Microsoft's not-playing-ball freebie mail system just isn't worth it for what is basically a hobby set-up run for the benefit of our community.
Re:E-mail is dead for mass communication (Score:5, Interesting)
All MS is doing is cranking up bandwidth costs now. Instead of one copy being sent to all 68 subscribers on the server, my listserv now has to send them 68 copies of the same damned thing. Incredibly inefficient, but the subscribers want the email, so that's what'll happen.
You gotta pay up! (Score:2, Interesting)
Of course, it's not the exact, same thing, but the similarity between the two situations is spooky, to say the least.
Re:And the problem is...? (Score:5, Interesting)
If a client actually stops trying to deliver based on a 552 error, then it, too, is violating the standard, in a way that actually prevents delivery. I consider that a more serious violation.
Re:And the problem is...? (Score:4, Interesting)
Only if the sending SMTP server is broken. SMTP has two types of return codes: permanent failures and temporary failures. A permanent failure causes the message to bounce to the sender. A temporary failure causes the message to be queued and resent. Upon resending, only recipients for whom an error was generated are retried. Thus, if this error occurs after ten recipients, the remainder won't get the message in the first pass, but the next ten will get it when the sending server retries (usually after an hour, IIRC). This should continue until the recipient list is exhausted. Even this assumes that the sending SMTP server is extremely dumb and doesn't really understand anything about this error code at all beyond that it is a temporary error.... If it actually understands the code, it should try resending to additional recipients immediately, and divide the message into smaller batches, in which case it would delay delivery by a few minutes at most.
In theory, in some extreme cases, the recipient might never get the message. If it retries once an hour for a week (fairly typical), that would effectively cap the number of HoTMaiL recipients of a single message at 10 * 24 * 7 = 1680 recipients. Of course, a proper sending SMTP server should already be able to split messages into batches of a hundred or less because a limit of 100+ is considered acceptable behavior by the receiving server. Thus, in effect, because 1680 is larger than 100, short of a very long term net outage after the initial connection attempt, all the recipients should receive the message in every case. If this does not occur, the sending SMTP server is broken.
This is, of course, just my opinion.
Re:E-mail is dead for mass communication (Score:3, Interesting)
At UMBC [umbc.edu], almost all student organizations, many classes, club teams, etc. etc. all use a mailing list system powered by Sympa [sympa.org] to communicate. It's way more convenient than logging into our blackboard site, browsing to the class, finding the discussions forums, and finding the right thread in the mangled excuse for organization.
With the mailing list, all I have to do is check my email. Email is easier to centralize to the individual than forums, and leaves organization up to the end user. I have to check my email for personal communiques, contact from professors, and automatic notifications ANYWAY, why the hell should I not use the system to stay in the loop in a group, too?
That said, reply-all is the worst thing in the world.
Re:I'm not TERRIBLY pro-MS, but... (Score:4, Interesting)
I would be pissed off if i were subscribed to something and I were the 11th hotmail user on their list.
Yahoo is worse (Score:1, Interesting)
Yahoo has, with much fanfare, implemented this crock called "DomainKeys". And it's recently been advanced as DKIM, and even more recently had a full-blown RFC issued for it.
One would think that, with either Domainkeys or DKIM signed email that Yahoo, of all people, would treat that as non-spam. Nope. Domainkeys signed email still goes straight into people's bulk folder, along with all the other spam. And the bulk folder is usually automatically purged in 30 days (IIRC), by default.
Hello? Why promote something if you're not going to use it correctly?
Maybe it's because DK/DKIM won't stop spam at all, since it misses the target? Maybe Yahoo understands this all too well, from first hand experience? Maybe the problem is that it is easy for a spammer to set up a DK/DKIM domain, spam a lot of people, and then drop it from sight? And maybe the problem is with certain Domain Registrars would profit quite well from selling domains to spaammers? Something that the RFC won't/can't address?
In any case, Yahoo has totally screwed up with this one. Note very well that, while they try to get you to use domainkeys, nowhere on their site do they say that they'll actually treat it as non-spam.
In short, Yahoo has hoodwinked a lot of people with this complete nonsense. And they are extremely hypocritical in promoting it, but not using it as per what they tout. Or what the new RFC says.
And this is with their own software on sourceforge!
In short, don't waste your time with either Yahoo or DomainKeys or DKIM. It's all a scam.
Oh. And for the crackers out there, you might try doing a security audit on the code. Maybe, just maybe, all the big email sites using domainkeys are vulnerable.
Sorry for the rant, but I REALLY don't appreciate my time being wasted. Just stick with Google. They seem to have some technical competence over there.
Re:RFC 2821 is not (yet) a standard (Score:3, Interesting)
Re:Hotmail has many worse problems than this one! (Score:5, Interesting)
me: why are you accepting my email with code 250 OK, but never delivering it?
them: we can't talk to you until you submit all the forms at postmaster.hotmail.com
me: submits the forms, which are clearly geared toward businesses (my "site" doesn't have a "privacy policy" or an "opt out form" because I don't SELL ANYTHING).
them: we can't talk to you until you sign up for our email tracking service to analyze your traffic
me: signs up. My server doesn't generate enough traffic for them to even log.
them: you need an SPF record
me: installs an SPF record
them: your SPF record is wrong. RFC blah blah states...
me: IT WAS GENERATED BY YOUR ONLINE TOOL!! And if you want to quote RFCs at me how about the one where if your server accepts email, you're guaranteeing not to drop it for frivolous reasons (RFC 2821, sec. 6.1)?
them: our reasons are not frivolous, but we won't tell you anything.
me: like how your servers drop email sent from thunderbird but let the same messages through when sent from outlook express?
them: we don't filter based on header information
Re:And the problem is...? (Score:4, Interesting)
It's one thing to have anti-spam and anti-abuse mechanisms in place, it's another to deliberately break basic functionality in direct violation of the standards that make email work. There are MUCH better ways of handling situations where you want to rate limit inbound mail that are fully compliant with the RFCs, that allow all valid mail to get through.
It simply amazes me how many IDIOTS are running servers at large ISP's / sites. It is well known by most competent email admins that hotmail is totally broken and unreliable. Anyone still using hotmail for everyday use should have their head examined.