5 ms·

Planned email blast accidentally cc'd other recipients, allowing users to see each other's email addresses. They caught it after <8,000 emails went out and are

Planned email blast accidentally cc'd other recipients, allowing users to see each other's email addresses. They caught it after <8,000 emails went out and are fixing the problem.

DanBC 10y ago
Some people are saying the emails were in the message body, not CC field. What's the limit for numbers of addresses in a CC field? Because this is several thousand addresses.
- aroch 10y ago
  If you're sending to/from Gmail/Exchange the limit is somewhere around 100 addresses (I believe it's technically the byte-size of the field not strictly the number of addresses). The actual spec though, AFAIK, has no limit.
  - jamiesonbecker 10y ago
    Right. SMTP header lines can't exceed 998 characters, but RFC2822 now allows multi-line headers[1], so there's no limit except one that might be imposed by an MTA (and that would generally only be imposed on sending, not receiving.) 1. https://www.ietf.org/rfc/rfc2822.txt https://www.ietf.org/rfc/rfc2822.txt §2.2.3
eterm 10y ago
It wasn't a CC, if it was then there wouldn't have been a way to stop after only some had gone out, because that's not how CC works.
- theoh 10y ago
  Isn't the CC header essentially an instruction for the local MTA? So their local MTA might could have been relatively slowly working through the CC list (contacting each recipient mail server in turn). I'm not saying this is what actually happened.
  - stormbrew 10y ago
    No, MTAs don't look at the To or Cc headers at all. The addresses to deliver to are listed in the SMTP rcpt to command. The MUA can provide a completely different list to what's in the headers.
    - theoh 10y ago
      Ok, good if pedantic response. I think the substance of my point stands: MTAs can take some time to work through the CC list (which, as you say, is passed to them with the "rcpt to" command by a well-behaved MUA) In other words, delivering a message to copious CC: recipients is not an uninterruptable operation even after the MUA has finished its job. They might have had to/been able to stop the local MTA to interrupt the rogue emails.
      - Dylan16807 10y ago
        In a scenario where the entire list is in CC, this could matter. But when your scenario is leaking a small fraction of the list members, you would have to be batching CC. Once you're batching CC, then it doesn't matter if all the emails in a batch are sent out at the same time.
      - stormbrew 10y ago
        Sorry, to clarify why this is not just pedantic, the MUA is likely to split up a long list of recipients rather than try to send an arbitrarily long list in one rcpt to command and potentially fail after a very long time processing and sending data. The fact that they don't have to be the same means that the list in the message can be arbitrarily long regardless of how the MUA batches it for the MTA. In that event, it is interruptible. Also, the MTA will batch its own outgoing sends to individual servers (giving them either just one rcpt to or all the recipients whose MX map to that server) and it could be interruptible there as well. The point is that when sending to many many delivery addresses, things get batched at various stages and become more interruptible than if your CC was the master list of how a message were routed.
        10y ago

Planned email blast accidentally cc'd other recipients, allowing users to see each other's email addresses. They caught it after <8,000 emails went out and are fixing the problem.

DanBC 10y ago

Some people are saying the emails were in the message body, not CC field. What's the limit for numbers of addresses in a CC field? Because this is several thousand addresses.

aroch 10y ago
If you're sending to/from Gmail/Exchange the limit is somewhere around 100 addresses (I believe it's technically the byte-size of the field not strictly the number of addresses). The actual spec though, AFAIK, has no limit.
- jamiesonbecker 10y ago
  Right. SMTP header lines can't exceed 998 characters, but RFC2822 now allows multi-line headers[1], so there's no limit except one that might be imposed by an MTA (and that would generally only be imposed on sending, not receiving.) 1. https://www.ietf.org/rfc/rfc2822.txt https://www.ietf.org/rfc/rfc2822.txt §2.2.3

eterm 10y ago

It wasn't a CC, if it was then there wouldn't have been a way to stop after only some had gone out, because that's not how CC works.

theoh 10y ago
Isn't the CC header essentially an instruction for the local MTA? So their local MTA might could have been relatively slowly working through the CC list (contacting each recipient mail server in turn). I'm not saying this is what actually happened.
- stormbrew 10y ago
  No, MTAs don't look at the To or Cc headers at all. The addresses to deliver to are listed in the SMTP rcpt to command. The MUA can provide a completely different list to what's in the headers.
  - theoh 10y ago
    Ok, good if pedantic response. I think the substance of my point stands: MTAs can take some time to work through the CC list (which, as you say, is passed to them with the "rcpt to" command by a well-behaved MUA) In other words, delivering a message to copious CC: recipients is not an uninterruptable operation even after the MUA has finished its job. They might have had to/been able to stop the local MTA to interrupt the rogue emails.
    - Dylan16807 10y ago
      In a scenario where the entire list is in CC, this could matter. But when your scenario is leaking a small fraction of the list members, you would have to be batching CC. Once you're batching CC, then it doesn't matter if all the emails in a batch are sent out at the same time.
    - stormbrew 10y ago
      Sorry, to clarify why this is not just pedantic, the MUA is likely to split up a long list of recipients rather than try to send an arbitrarily long list in one rcpt to command and potentially fail after a very long time processing and sending data. The fact that they don't have to be the same means that the list in the message can be arbitrarily long regardless of how the MUA batches it for the MTA. In that event, it is interruptible. Also, the MTA will batch its own outgoing sends to individual servers (giving them either just one rcpt to or all the recipients whose MX map to that server) and it could be interruptible there as well. The point is that when sending to many many delivery addresses, things get batched at various stages and become more interruptible than if your CC was the master list of how a message were routed.
      - 10y ago