3 ms·
The reason for this screw up was guessed by a Twitter user, and his theory was confirmed by Josh from Let's Encrypt [1]. The whole mess was caused by the Pytho
by Cyph0n 10y ago
The reason for this screw up was guessed by a Twitter user, and his theory was confirmed by Josh from Let's Encrypt [1].
The whole mess was caused by the Python `email` package, and specifically the behavior of the `MIMEMultipart` object [2]. When you reuse the same `MIMEMultipart` object for multiple emails, each destination address is appended. The same problem takes place when you use Python 3 [3].
[1]: https://twitter.com/0xjosh/status/741487697059946497 https://twitter.com/0xjosh/status/741487697059946497
[2]: https://docs.python.org/3/library/email.mime.html#email.mime.multipart.MIMEMultipart https://docs.python.org/3/library/email.mime.html#email.mime...
[3]: http://i.imgur.com/XwWlUXv.png http://i.imgur.com/XwWlUXv.png
- drdaeman 10y agoI see that it's confrimed, but find it a bit odd that they had originally said "prepended between 0 and 7,618 other email addresses to the body of the email.", as this way it would be just a lot of "To" headers.
- andrewstuart2 10y agoThe design of MIMEMultipart causes duplicate key: values to be printed, rather than comma-separated addresses as specified in RFC 2822. [1] https://tools.ietf.org/html/rfc2822#section-3.6.3 https://tools.ietf.org/html/rfc2822#section-3.6.3
- anderskaseorg 10y agoMultiple occurrences of the To, Cc, and Bcc fields are permitted (though obsolete). https://tools.ietf.org/html/rfc2822#section-4.5.3 https://tools.ietf.org/html/rfc2822#section-4.5.3
- aodin 10y agoI was part of the disclosed list and can confirm that this is exactly what happened (plus an extra newline!)
- chaz6 10y agoIt was not just due to this but also lack of QA/testing.