mime

I wrote @ronomon/mime (https://github.com/ronomon/mime) as a strict fuzz-tested MIME parser in a memory-safe language to prevent similar attacks such as: 1. Malicious character encodings that can crash email clients such as Apple Mail. 2. Malicious RFC 2231 continuation indices designed to cause overallocation. 3. Base64 data containing illegal characters such as null bytes. 4. Unterminated comments and quoted-strings. 5. Missing multipart parts (e.g. no terminating boundary delimiter). 6. Malicious data designed to cause CPU-intensive decoding or stack overflows (aka MIME bombs, the email equivalent of zip bombs). 7. Malicious multiple occurrences of crucial headers and parameters, which could cause clients to render an email differently from that scanned by antivirus software. 8. Encoded words containing malicious control characters (cf

> some email providers also filter incoming messages and remove malformed MIME components that are needed to reach a vulnerability. I wrote @ronomon/mime [1] for this purpose, to protect downstream user email clients from MIME bombs [2], invalid charsets which can crash Apple Mail, multiple From headers which can exploit Gmail [3], attachment directory traversals, malicious continuation indices, truncated MIME messages, stack overflows etc. [1] https://github.com/ronomon/mime [2] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin... [3] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...

That is an interesting approach. Care to let us know how you go from https://github.com/ronomon/mime to some kind of SMTP server plugin (like for postfix for example)?

Thanks, one thing we also found is that spammers tend to be poor at RFC standards, in a way that Gmail etc. will have no problem with, but which are obviously broken. For example, we use our own https://github.com/ronomon/mime to detect and reject email which has missing multi-parts (no terminating boundary delimiter). All of this has been spam so far, and we are yet to see a false positive. I don't think SpamAssassin has a rule for this (yet)? Another example is illegal header characters, which are almost always spam, with a handful of false positives (usually machine-generated).

I wrote @ronomon/mime, an email parser which enforces RFC 2822 3.6.2 and which also detects a variety of attack vectors before they can reach the email client. A summary of these vectors are listed in the README (amongst various sanity checks): https://github.com/ronomon/mime#robust Just through checking everything about an email carefully, @ronomon/mime has detected and brought to light some interesting attack vectors, for example a malformed email which crashes Apple Mail. This was disclosed to Apple's security team although they did not see any actual security implications. Another interesting attack vector was an email containing millions of empty multiparts, which was able to crash several popular email servers. This was disclosed through Snyk, here are the details: https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...

Since I came across Jeff Dean's tip a few years ago about back-of-the-envelope calculations and latency numbers (http://highscalability.com/blog/2011/1/26/google-pro-tip-use...), I can't count the number of times that sketching out a design's complexity has saved me from implementing designs that can't possibly work, and eventually resulted in designs that are orders of magnitude faster. In fact, it's not just about designs that work, or designs that are fast, but getting into the practice of estimating complexity in terms of hardware numbers also makes for safer code, especially where validating user data is concerned. Just recently even, it kept me back from what might have been a potential denial of service in https://github.com/ronomon/mime, and lead to discovering a vulnerability in several popular email parsers (https://snyk.io/blog

If anyone is interested in general MIME validation, not specifically email addresses, I wrote @ronomon/mime: https://github.com/ronomon/mime The source code has comments from the various RFCs inline. It's not just a question of reading and knowing the RFCs but also of interpreting them and balancing them. The decoder will throw detailed exceptions which are designed to pinpoint where the message went wrong, and which RFCs were broken by the message. It also does just-in-time decoding, and decodes only the properties you access. This is much more efficient if you only need a header or two to reject spam quickly as part of a front line defense. Above all, most of the methods are extensively fuzz-tested against independent reference implementations.