Admins Accuse Microsoft of Hotmail Cap

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."

Comments

And the problem is...?

[Kelson]

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:

RFC 821 [30] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent

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?

Re:And the problem is...?

[Kelson]

No - for every recepient that they reject, they are, in effect, blocking those recipient from receiving the intended message.

The proper reaction of a sending server to a temporary error is to try again. Per that same RFC, the server should be treating '552 too many recipients' as a temporary error.

Yahoo does the same thing at 30 recipients, though they issue the more proper 452 error code. The first 30 recipients at Yahoo get the message, then the sending server retransmits to the remaining addresses.

Re:And the problem is...?

[Obfuscant]

No, according the standards, every recipient rejected for "too many" stays in the queue and delivery is attempted at the next queue run. While Hotmail's violation of the standard seems bad, the worst effect it should have is to slow the delivery, not prevent it.

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...?

[dgatwood]

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:And the problem is...?

[Obfuscant]

Refer to RFC2821, which is the RFC that MS is being blamed for violating by not allowing 100 RCPT commands per session. Normally, you are right, 5XX is fatal, but 4.5.3.1 Size limits and minimums says:

RFC 821 [30] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works. SHOULD means "unless you know what you are doing and have a good reason to do otherwise." The "logic below" is that the sending server removes the ones that were successful and tries the rest again later.

Re:And the problem is...?

[walt-sjc]

Dealing with mail servers that handle newsletters with subscribers numbering in the 100K+ each range, I have several special configurations on my servers to handle various broken behavior. In fact, I have a "butthead-TMR" list that contains hotmail for this EXACT reason. I also have a "butthead-TMC" list for a few broken servers that start doing the same 500 level errors for "too many simultaneous connections".

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.

Too many?

[shine-shine]

Oof.

"552 Too many first posts."

Hotmail is unreliable anyway

[Anonymous Brave Guy]

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

[RollingThunder]

I take it you're not on any discussion mailing lists, then?

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.

What's the bid deal?

[jtroutman]

There's been a fix for this problem for a while now.

Re:What's the bid deal?

[jtroutman]

That should, of course, have read "What's the big deal?", but I've had a head cold for the last week.

People still use hotmail?

[heptapod]

There are hundreds of free alternatives available and a simple Google search brings up numerous email forwarding services that can take the sting out of changing email accounts.

Dont worry!

[Ariastis]

No sweat guys, for 19.99$ per year, you can become a member of the Windows MSN Live Hotmail Benefactor Plus Live rewards program!

Benefits include :
1) Spam whomever you want, bypassing all spam filters!
2) Send e-mails to more than 10 recipients (Also called the "I run a mailing list you fucktard" option)
3) Free "Upgrade to Vista (Please)" coupon.

I'm in violation too...

[Ossifer]

... this is a well known anti-spam technique -- it helps thwart dictionary attacks. Hotmail allows 10 recipients, my email server allows at most 1 (one). Of course, my domain only has one email account...

RFCs are not laws

[Angst Badger]

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."

I love the way the OP makes this sound like a serious criminal violation. Microsoft (or you, or me) is free to violate RFC 2821 till the cows come home. Whether doing so is the best way to handle whatever problem they're trying to address is another matter, but they're not drowning puppies or breaking laws, they're violating voluntary standards, which is not exactly a newsworthy activity for Microsoft.

Re:RFCs are not laws

[glwtta]

I love the way the OP makes this sound like a serious criminal violation.

I love the way you just make shit up. All I got from the summary was that they are violating the RFC, I can't imagine what kind of synaptic misfire would lead anyone to think "criminal" when they read that.

Is overzealous MS reverse-bashing the in thing now?

I'm not TERRIBLY pro-MS, but...

[DigitalSorceress]

Honestly, if everyone followed all the RFCs for email and didn't adapt, spam would probably bring everything to a grinding halt. As it is, with countermeasures and counter-countermeasures in an escalating spiral in the "spam wars", I sometimes marvel that email even still works at all.

Granted, security through obscurity isn't really effective, but why should they bother telling spammers how small to make their batches in order to get things through? Make the bastards work a little bit.

Wow, I've gotten cynical.

Re:I'm not TERRIBLY pro-MS, but...

[Random832]

Granted, security through obscurity isn't really effective, but why should they bother telling spammers how small to make their batches in order to get things through? Because there are lots of legitimate reasons to send an email to more than 10 recepients on a large service like Hotmail, and batching them up (as opposed to sending the whole email, headers and body, to the server multiple times) saves bandwidth.

I would be pissed off if i were subscribed to something and I were the 11th hotmail user on their list.

RFC 2821 is not (yet) a standard

[Eric Smith]

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."

RFC 2821 isn't a standard, though. It's on the standards track, but it has not yet been accepted by the IETF as a standard. The current SMTP standard is RFC 821, also known as STD 10. RFC 821 says:

recipients buffer

The maximum total number of recipients that must be buffered is 100 recipients.

TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH OF THESE OBJECTS SHOULD BE USED.

This only requires that up to 100 recipients must be buffered, but doesn't explicitly state that there is any requirement to deliver to all 100 such recipients, nor that recipients cannot be rejected for some reason other than running out of buffer space.

Re:RFC 2821 is not (yet) a standard

[Anonymous Coward]

It may not be a recommended IETF standard, but the RFC number (on standards track) makes it an effective (read: recommended) standard. If you're a fan of RFC's you should implement them when they are in the Standards Track Especially when it's a trivial extension of an existing protocol, especially when (most) everyone else does.

You think MS is bad? Try Yahoo!

[statemachine]

Yahoo has been junking all e-mail from my domain. Yet, my domain has been around since '99, has an SPF record, and has not been on a spam blacklist ever. I don't run any lists, and usually these e-mails are only directed at one recipient.

When I contacted Yahoo, I was referred to a broken web form that supposedly would direct me to a place where I could whitelist my domain, or at least make it less spammy-looking to Yahoo. Upon further attempts to reach them, I only received automated responses, but no answers to my questions.

I am not the only one who has had this problem sending e-mail to Yahoo accounts. Ironically, just Google for all the discussions on how Yahoo doesn't care.

Sending e-mail to GMail accounts works just fine for me. None of my messages show up in the spam folder. This is an indicator that the problem lies with Yahoo, and not with my domain.

Re:Hotmail has many worse problems than this one!

[saarbruck]

OP could have provided more detail but was not trolling: I run an email server on a static IP on my 768/128 DSL line. It's for 2 users. My mother, who has been a Hotmail user for so long that she can't relocate or "no one will find her!" refuses to move to gmail despite my pleas. Hotmail silently drops mail from my server about two thirds of the time. Messages such as "Hey, where are we meeting for Grandma's birthday dinner" disappear into the ether despite me being on her whitelist. Repeated hotmail support requests go something like this:

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

... and so it goes. I understand that I'm a small fish in a big pond and that there's a war on terror, uh, I mean spam, but hotmail just sucks.