Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Spam The Internet

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."
This discussion has been archived. No new comments can be posted.

Admins Accuse Microsoft of Hotmail Cap

Comments Filter:
  • by heptapod ( 243146 ) <heptapod@gmail.com> on Wednesday October 10, 2007 @07:19PM (#20934003) Journal
    There are hundreds of free alternatives available and a simple Google search [google.com] brings up numerous email forwarding services that can take the sting out of changing email accounts.
  • by jas79 ( 196511 ) on Wednesday October 10, 2007 @07:25PM (#20934055)
    The answer Microsoft gave was about the limits for sending email, not for receiving email.
  • by fatphil ( 181876 ) on Wednesday October 10, 2007 @07:26PM (#20934069) Homepage
    Are you missing this bit:
    """
          recipients buffer
                The minimum total number of recipients that must be buffered is
                100 recipients. Rejection of messages (for excessive recipients)
                with fewer than 100 RCPT commands is a violation of this
                specification.
    """
    which is only a couple of paragraphs above what you quoted.

    You're also missing the fact that when a server rejects a message because of some issue with the recipients, it is still rejecting the message, and not "rejecting the recipient", which is a completely meaningless concept in the language of the RFC.

  • by Kelson ( 129150 ) * on Wednesday October 10, 2007 @07:32PM (#20934127) Homepage Journal

    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.

  • by Klaus_1250 ( 987230 ) on Wednesday October 10, 2007 @07:46PM (#20934249)
    The bad thing about spam filtering in Hotmail is that they do it silently. I've had complaints in the past about mails being lost, so I checked my server logs: 250's for all messages to hotmail. Wrote an email to postmaster@hotmail.com which bounced back (sigh). Then I gave up and adviced to make sure recipients had the sending email-address in their addressbooks before sending them anything, which seems to do the trick most of the times.
  • by Sorthum ( 123064 ) on Wednesday October 10, 2007 @07:57PM (#20934327) Homepage
    5xx rejections are permanent, "Give up now."
    4xx rejections are temporary, "try again later."
  • by Eric Smith ( 4379 ) * on Wednesday October 10, 2007 @08:29PM (#20934549) Homepage Journal

    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:RFCs are not laws (Score:3, Informative)

    by jamesh ( 87723 ) on Wednesday October 10, 2007 @08:31PM (#20934567)
    That's exactly right. The only problem it might cause them is they can't claim to be running an RFC2821 compliant mail server (for whatever that's worth), and as anyone who has ever implemented a spam filter would know, they aren't the only ones.

    None of the customer mail servers I look after will accept more than about 50 recipients per message from internal users, let alone external users. Otherwise, I get too many calls from customers complaining that their internet access is slow, only to find out that their marketing department have sent a 5MB attachment to 500 people again. This is made even worse by Exchange's default setting to try and send out 100 or so messages concurrently (so they all time out and retry). If you need to get any information out to that many people, especially large amounts of information, there are better ways of doing it.
  • by kju ( 327 ) on Wednesday October 10, 2007 @09:10PM (#20934859)
    Some server will deny some/more recipients even after only one prior recipient. The reason? Spam filtering during the SMTP phase and conflicting configuration of the different recipients. Doing spam filtering during SMTP is good, as you can cleanly deny spam instead of just acting like a black hole and throwing it away. In the case of a false positive the sender will at least get a clean error message without having to send one of these nowadays very annoying bounce messages. If you ever became victim to some spammer abusing your mail address as the sender of spam and you've got 25000 bounces, you know why bounce messages need to be eliminated thanks to spammers.

    Unfortunately spam filtering has became so complex that more often than not one there is no one-size-fits-them-all configuration. But this means that the same message might be acceptable to the configuration settings of user A but not to the settings of user B. When now a mail sender tries to send a message to A and B, it will be necessary to deny recipient B due to the differing config (at least for filters which are based on content and thus can not be run before the recipient was accepted and the message sent).

    Yes, this breaks a proposed standard. But so do a lot of other spam filtering techniques like RBL, SPF and Greylisting. Thanks to the spammers we have broken SMTP quite some while ago and one is to wonder why internet mail is still quite reliable. I predict it can only go downhill from here.
  • by statemachine ( 840641 ) on Wednesday October 10, 2007 @09:20PM (#20934943)
    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.
  • by Obfuscant ( 592200 ) on Wednesday October 10, 2007 @10:26PM (#20935457)
    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.

"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan

Working...