@ronomon/mime
Advanced tools
Comparing version 1.1.1 to 1.1.2
{ | ||
"name": "@ronomon/mime", | ||
"version": "1.1.1", | ||
"version": "1.1.2", | ||
"description": "Fast, robust, standards-compliant MIME decoder. Ships with extensive tests and fuzz tests.", | ||
@@ -5,0 +5,0 @@ "main": "index.js", |
109
README.md
# mime | ||
Fast, robust, standards-compliant MIME decoder. Ships with extensive tests and fuzz tests. | ||
Fast, robust, standards-compliant MIME decoder. Ships with extensive tests and | ||
fuzz tests. | ||
@@ -11,11 +12,21 @@ ## Installation | ||
* Decodes on demand only as much as necessary to access a particular property. For example, if you need `mime.subject`, then `MIME` will search for the `CRLF` pair marking the end of the headers and decode only the `subject` header, without decoding any other headers and without decoding the body. This works well with the first few layers of spam defenses, which often only need to decode particular headers to reject an email. | ||
* Decodes on demand only as much as necessary to access a particular property. | ||
For example, if you need `mime.subject`, then `MIME` will search for the `CRLF` | ||
pair marking the end of the headers and decode only the `subject` header, | ||
without decoding any other headers and without decoding the body. This works | ||
well with the first few layers of spam defenses, which often only need to decode | ||
particular headers to reject an email. | ||
* Caches decoded properties for subsequent use. | ||
* Uses native fuzz-tested C++ [Base64](https://github.com/ronomon/base64) and [Quoted-Printable](https://github.com/ronomon/quoted-printable) bindings. `MIME`'s Base64 decoder in particular was developed for decoding wrapped Base64 [more efficiently](https://github.com/ronomon/base64#motivation) and detecting obvious corruption and character truncation. | ||
* Uses native fuzz-tested C++ [Base64](https://github.com/ronomon/base64) and [Quoted-Printable](https://github.com/ronomon/quoted-printable) bindings. | ||
`MIME`'s Base64 decoder in particular was developed for decoding wrapped Base64 | ||
[more efficiently](https://github.com/ronomon/base64#motivation) and detecting | ||
obvious corruption and character truncation. | ||
* Uses custom lookup tables to minimize the cost of branching through too many conditionals when decoding. | ||
* Uses custom lookup tables to minimize the cost of branching through too many | ||
conditionals when decoding. | ||
* Avoids unnecessary string and buffer allocations. Algorithms accept and work with buffers directly, and allocate and copy buffers only when necessary. | ||
* Avoids unnecessary string and buffer allocations. Algorithms accept and work | ||
with buffers directly, and allocate and copy buffers only when necessary. | ||
@@ -26,11 +37,18 @@ * Avoids regular expression decoders. | ||
* Provides detailed error messages which refer to the relevant RFCs to assist debugging, and which can be used directly as part of an SMTP `reply`. | ||
* Provides detailed error messages which refer to the relevant RFCs to assist | ||
debugging, and which can be used directly as part of an SMTP `reply`. | ||
* Accepts `CRLF` and `LF` line-endings (which are common) but not `CR` line-endings (which are rare). | ||
* Accepts `CRLF` and `LF` line-endings (which are common) but not `CR` | ||
line-endings (which are rare). | ||
* Accepts illegal transport padding frequently added by intermediaries (e.g. within the angle brackets of a `msg-id` or `angle-addr`, and between tokens in an `encoded-word`). | ||
* Accepts illegal transport padding frequently added by intermediaries (e.g. | ||
within the angle brackets of a `msg-id` or `angle-addr`, and between tokens in | ||
an `encoded-word`). | ||
* Decodes a variety of malformed but common mailbox syntaxes (e.g. no angle brackets around the `addr-spec`, with a `display-name` present on the left or right). | ||
* Decodes a variety of malformed but common mailbox syntaxes (e.g. no angle | ||
brackets around the `addr-spec`, with a `display-name` present on the left or | ||
right). | ||
* Removes balanced single quotes around the `display-name` or `addr-spec` in an email address (sometimes added by Outlook). | ||
* Removes balanced single quotes around the `display-name` or `addr-spec` in an | ||
email address (sometimes added by Outlook). | ||
@@ -41,17 +59,31 @@ * Decodes `encoded-words` not separated by `WSP`. | ||
* Decodes `encoded-words` found in `Content-Type` and `Content-Disposition` parameters (used by Outlook and Gmail contrary to [RFC 2047 5 Use of encoded-words in message headers](https://tools.ietf.org/html/rfc2047#section-5)). | ||
* Decodes `encoded-words` found in `Content-Type` and `Content-Disposition` | ||
parameters (used by Outlook and Gmail contrary to [RFC 2047 5 Use of | ||
encoded-words in message headers](https://tools.ietf.org/html/rfc2047#section-5)). | ||
* Removes any directory path components from an attachment name or filename (when accessed via `mime.filename`, see Usage below). | ||
* Removes any directory path components from an attachment name or filename | ||
(when accessed via `mime.filename`, see Usage below). | ||
* Decodes `msg-ids` not separated by whitespace or commas (i.e. separated only by angle brackets). | ||
* Decodes `msg-ids` not separated by whitespace or commas (i.e. separated only | ||
by angle brackets). | ||
* Rejects unrecognized `Content-Transfer-Encoding` mechanisms contrary to [RFC 2045 6.4 Interpretation and Use](https://tools.ietf.org/html/rfc2045#section-6.4) (e.g. anything other than `7bit`, `8bit`, `binary`, `base64`, or `quoted-printable`). This is to avoid accepting responsibility for content which will not display correctly, if at all. In contrast, the spec advocates silently altering the `Content-Type`. | ||
* Rejects unrecognized `Content-Transfer-Encoding` mechanisms contrary to | ||
[RFC 2045 6.4](https://tools.ietf.org/html/rfc2045#section-6.4) (e.g. anything | ||
other than `7bit`, `8bit`, `binary`, `base64`, or `quoted-printable`). This is | ||
to avoid accepting responsibility for content which will not display correctly, | ||
if at all. In contrast, the spec advocates silently altering the `Content-Type`. | ||
* Rejects malicious `RFC 2231` continuation indices designed to cause overallocation. | ||
* Rejects malicious `RFC 2231` continuation indices designed to cause | ||
overallocation. | ||
* Rejects Base64 data containing illegal characters (anything which is not a valid Base64 or whitespace character, e.g. null bytes which could cause security issues). | ||
* Rejects Base64 data containing illegal characters (anything which is not a | ||
valid Base64 or whitespace character, e.g. null bytes which could cause security | ||
issues). | ||
* Rejects Base64 data which is clearly truncated (as opposed to just missing padding). | ||
* Rejects Base64 data which is clearly truncated (as opposed to just missing | ||
padding). | ||
* Rejects Quoted-Printable data containing illegal characters (anything which is not a valid Quoted-Printable character, e.g. null bytes which could cause security issues). | ||
* Rejects Quoted-Printable data containing illegal characters (anything which is | ||
not a valid Quoted-Printable character, e.g. null bytes which could cause | ||
security issues). | ||
@@ -62,7 +94,12 @@ * Rejects illegal character sequences according to the specified `charset`. | ||
* Normalizes and aliases a variety of character sets to the canonical character set, (e.g. `ks_c_5601-1987` which is sometimes used by Outlook is aliased to `CP949` - Korean, otherwise the text would decode incorrectly). | ||
* Normalizes and aliases a variety of character sets to the canonical character | ||
set, (e.g. `ks_c_5601-1987` is sometimes used by Outlook and is aliased to | ||
`CP949` - Korean, otherwise the characters would decode from the wrong character | ||
set and be unintelligible). | ||
* Rejects unknown character sets not supported by [`iconv`](https://github.com/bnoordhuis/node-iconv). | ||
* Rejects unknown character sets not supported by | ||
[`iconv`](https://github.com/bnoordhuis/node-iconv). | ||
* Decodes `text/*` body parts to `UTF-8` buffers if the `Content-Type` indicates that the body is encoded in any other character set. | ||
* Decodes `text/*` body parts to `UTF-8` buffers if the `Content-Type` indicates | ||
that the body is encoded in any other character set. | ||
@@ -85,9 +122,16 @@ * Rejects unterminated `comments` and `quoted-strings`. | ||
* Rejects folded header lines which exceed the 998 line length limit, but only after applying grace for clients such as Outlook.com which exclude the `field-name` and `colon` from their character count, and which mistake the limit to be 1000 characters excluding the CRLF. The limit is in fact 998 characters excluding the CRLF. | ||
* Rejects folded header lines which exceed the 998 line length limit, but only | ||
after applying grace for clients such as Outlook.com which exclude the | ||
`field-name` and `colon` from their character count, and which mistake the limit | ||
to be 1000 characters excluding the CRLF. The limit is in fact 998 characters | ||
excluding the CRLF. | ||
* Rejects multipart boundaries containing forbidden characters. | ||
* Rejects malicious data designed to cause CPU-intensive decoding and stack overflows. | ||
* Rejects malicious data designed to cause CPU-intensive decoding and stack | ||
overflows. | ||
* Rejects malicious multiple occurrences of crucial headers and parameters, which could cause clients to render an email differently from that scanned by anti-virus software. | ||
* Rejects malicious multiple occurrences of crucial headers and parameters, | ||
which could cause clients to render an email differently from that scanned by | ||
anti-virus software. | ||
@@ -98,11 +142,16 @@ ## Standards-Compliant | ||
* [RFC 2045](https://tools.ietf.org/html/rfc2045) - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. | ||
* [RFC 2045](https://tools.ietf.org/html/rfc2045) - Multipurpose Internet Mail | ||
Extensions (MIME) Part One: Format of Internet Message Bodies. | ||
* [RFC 2046](https://tools.ietf.org/html/rfc2046) - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. | ||
* [RFC 2046](https://tools.ietf.org/html/rfc2046) - Multipurpose Internet Mail | ||
Extensions (MIME) Part Two: Media Types. | ||
* [RFC 2047](https://tools.ietf.org/html/rfc2047) - MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. | ||
* [RFC 2047](https://tools.ietf.org/html/rfc2047) - MIME (Multipurpose Internet | ||
Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. | ||
* [RFC 2183](https://tools.ietf.org/html/rfc2183) - The Content-Disposition Header Field. | ||
* [RFC 2183](https://tools.ietf.org/html/rfc2183) - The Content-Disposition | ||
Header Field. | ||
* [RFC 2231](https://tools.ietf.org/html/rfc2231) - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. | ||
* [RFC 2231](https://tools.ietf.org/html/rfc2231) - MIME Parameter Value and | ||
Encoded Word Extensions: Character Sets, Languages, and Continuations. | ||
@@ -118,3 +167,3 @@ ## Usage | ||
// Decoding will only take place when the following getter properties are accessed. | ||
// Decoding will take place when the following getter properties are accessed. | ||
// These getter properties may throw an exception for malformed MIME data. | ||
@@ -121,0 +170,0 @@ |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
195730
195