10 posts tagged with "email"

ACME (Automatic Certificate Management Environment) represents a breakthrough in managing TLS (Transport Layer Security) certificates. This protocol automates the process of obtaining, installing, and renewing TLS/SSL certificates, which are crucial for securing network communications. TLS certificates provide authentication and encryption, ensuring that data transferred between users and servers remains private and secure.

ACME's ability to automate these tasks greatly simplifies certificate management, particularly for services like mail servers that require ongoing security maintenance. The protocol interacts with Certificate Authorities (CAs) such as Let's Encrypt to automate the verification of domain ownership and the issuance of certificates, significantly reducing manual effort and the risk of human error.

We are thrilled to announce the release of Stalwart Mail Server 0.5.2, which brings two significant advancements: the integration of the ACME protocol for automatic TLS certificate deployment and support for the HAProxy Protocol. These features mark a substantial step forward in our commitment to enhancing the security and efficiency of Stalwart Mail Server.

The Power of ACME​

The integration of ACME into Stalwart Mail Server simplifies the complexities of TLS certificate management. It ensures that the certificates are always up-to-date, thereby enhancing the overall security of your communications. With ACME, the server automatically verifies domain ownership, obtains the necessary certificates, and handles renewals, all without manual intervention. This automation is not only a boon for security but also significantly reduces the administrative burden and the risk of service interruptions due to expired certificates.

Embracing the Proxy Protocol​

The Proxy Protocol is another crucial feature in this release. When running servers behind load balancers or reverse proxies, such as Caddy, HAProxy, or Traefik, the server traditionally only sees the IP address of the proxy, not the actual client. This limitation can impact security and logging functions. By supporting the Proxy Protocol, Stalwart Mail Server 0.5.2 can now accurately identify the original client's IP address and connection details. This capability is essential for maintaining robust security measures and precise logging. It ensures that even in environments where Stalwart is behind a proxy, it retains full visibility over client connections.

Conclusion​

In conclusion, Stalwart Mail Server 0.5.2 is a significant update, offering both ACME for simplified and automated TLS certificate management and the Proxy Protocol for enhanced functionality behind proxy environments. These features underscore our dedication to providing a secure, efficient, and user-friendly mail server solution. We look forward to seeing how our users leverage these new capabilities in their Stalwart Mail Server deployments.

In the world of email security, a recent concern has arisen known as SMTP Smuggling, a vulnerability that can be exploited to spoof emails. This blog post will explain what SMTP smuggling is and how Stalwart Mail Server is designed to be immune to this vulnerability. We'll also discuss a new feature we've implemented to protect other servers that might be vulnerable.

Understanding SMTP Smuggling​

SMTP smuggling is an exploitation technique that manipulates SMTP conversations to send spoofed emails from arbitrary addresses. It leverages interpretation differences in the SMTP protocol to bypass security checks like SPF alignment. The technique was identified as effective against multiple email providers and could have significant implications for email security.

Traditionally, the end of data in an SMTP conversation is indicated by a sequence <CR><LF>.<CR><LF> (CR LF stands for Carriage Return and Line Feed, standard text delimiters). However, if an SMTP server improperly interprets this sequence, it can be tricked into starting a new email within the content of an existing email, allowing attackers to inject malicious content and spoof emails that bypass SPF alignment checks.

Research has shown that even large organizations with sophisticated IT infrastructure are not immune to SMTP smuggling attacks. Notable entities such as Ebay, PayPal, Amazon, and even Microsoft, through their use of services like Microsoft Exchange Online, have experienced challenges due to non-compliance with certain RFC specifications. This underscores the importance of adhering to established protocols and standards in email communications. Compliance with these specifications is crucial for ensuring the security and integrity of email systems.

This vulnerability has led to calls for increased vigilance and improved email server configurations to prevent such exploits. For a detailed understanding of SMTP smuggling, please refer to the full article on SEC Consult's blog.

How Stalwart is Protected​

Stalwart Mail Server is designed with robust security measures that inherently protect it from SMTP smuggling attacks. Stalwart only accepts <CR><LF>.<CR><LF> as the terminating sequence for a DATA command. This strict adherence to protocol specifications prevents the ambiguity that can lead to smuggling attacks. Furthermore, when sending outgoing messages, Stalwart Mail Server utilizes the BDAT command whenever available. The BDAT command is not susceptible to SMTP smuggling issues, as it specifies the exact amount of data being sent, leaving no room for misinterpretation.

Protecting other Servers​

While Stalwart Mail Server itself is not vulnerable to SMTP smuggling, we recognize that other servers might be. To help protect the broader email ecosystem, we have introduced in version 0.5.1 a feature to sanitize outgoing messages that might attempt to exploit this bug in other servers. This feature involves applying the transparency procedure described in RFC5321 to outgoing messages even when these messages do not use CRLF as line terminators, which prevents the exploitation of SMTP smuggling vulnerabilities in other servers.

MECSA Compliance​

In our ongoing efforts to enhance email security, we are proud to announce that Stalwart Mail Server 0.5.1 is now compliant with the My Email Communications Security Assessment (MECSA) set by the European Union. MECSA compliance signifies a robust level of security in email communication, and one of the key features in achieving this compliance is the implementation of SMTP sender validation for authenticated users.

SMTP sender validation ensures that authenticated users can only issue MAIL FROM commands that match their login name or any of the email addresses associated with their accounts. Previously, implementing this level of validation required the creation of a Sieve script. However, with our latest update, this functionality is now a straightforward boolean entry in the system settings, defaulting to true for maximum security.

Conclusion​

In summary, Stalwart Mail Server's architecture and its strict adherence to SMTP protocol specifications inherently protect it against SMTP smuggling attacks. Furthermore, our commitment to the security of the email infrastructure extends beyond our server. The new feature to sanitize outgoing messages and our MECSA compliance demonstrate our proactive approach to safeguarding against vulnerabilities and contributing to a more secure email environment

Stay up to date with the latest in email security and Stalwart Mail Server's features by following our blog and updates.

In today's digital age, the safety and authenticity of your emails are paramount. With that in mind, we're happy to announce the release of the Spam and Phishing filter in Stalwart Mail Server v0.4.0. This release is packed with features that not only enhance your email security but also ensure a seamless communication experience.

Here's a deep dive into what's new:

• Comprehensive Filtering Rules: We've crafted a set of rules that stand shoulder-to-shoulder with the best solutions out there.
• Statistical Spam Classifier: Empower your server with a classifier that constantly learns, adapts, and keeps spam at bay.
• DNS Blocklists (DNSBLs): Safeguard your users' inboxes from notorious spammers through meticulous checks on IP addresses, domains, and hashes.
• Collaborative Digest-Based Filtering: By integrating digest-based spam filtering, we ensure even greater accuracy in weeding out unwanted emails.
• Phishing Protection: Defend against cunning phishing tactics, from homographic URL attacks to deceptive sender spoofing.
• Trusted Replies Tracking: By recognizing and prioritizing genuine replies, we ensure your genuine conversations remain uninterrupted.
• Sender Reputation: An automated system that assesses sender credibility based on their IP, ASN, domain, and email address.
• Greylisting: An added shield against spam, by temporarily holding back unfamiliar senders.
• Spam Traps: Crafty decoy email addresses that help us catch and scrutinize spam, ensuring your users' inboxes remain clutter-free.
• Built-in & Ready to Roll: No dependency on third-party software. Unbox and deploy – it's that simple!

Comparative Analysis​

While we have immense respect for both RSpamd and SpamAssassin, it's essential to highlight some distinctions. RSpamd stands out for its speed and standalone capabilities but necessitates additional configuration and maintenance. Meanwhile, SpamAssassin, built on Perl, might not deliver the same speed as RSpamd due to its heavy reliance on regular expressions.

Stalwart Mail Server's spam and phishing filter offers a level of protection equivalent to both RSpamd and SpamAssassin with one notable advantage: speed. Since the message remains within the server during the entire filtering process, it's considerably quicker. Furthermore, while third-party solutions re-execute checks for DMARC, DKIM, SPF, and ARC, Stalwart has already performed these, making our built-in filter more efficient and streamlined.

In essence, with Stalwart Mail Server, you receive a blend of speed, efficiency, and top-tier protection.

Conclusion​

In essence, with Stalwart Mail Server v0.4.0, you're not just getting an email server, but a comprehensive, fast, and efficient email security solution.

We're committed to continuous innovation and ensuring that your communication remains genuine, secure, and spam-free. Upgrade to Stalwart Mail Server v0.4.0 and experience the difference today!

Today we are announcing the latest release of Stalwart Mail Server: version 0.3.6. This update includes multiple enhancements to the Sieve filtering language, including the ability to evaluate arithmetical and logical expressions, and fetch data from SQL or LDAP databases to Sieve variables.

Arithmetical and Logical Expressions​

Stalwart Mail Server now incorporates the ability to evaluate arithmetical and logical operations within Sieve scripts. For instance, the following Sieve script rejects a mail if it satisfies a particular condition:

if test eval "score + ((awl_score / awl_count) - score) * awl_factor > 2.25" {
    reject "Your message is SPAM.";
    stop;
}

Whether you're aiming to refine your filtering mechanisms or just add some mathematical magic to your scripts, this feature is sure to come in handy.

To learn more about expressions in Sieve scripts, check out the Arithmetical and Logical Expressions section in the documentation.

Fetching Data from Databases​

Using Sieve scripts, you can now query SQL or LDAP databases and store the results as Sieve variables. This is done using the query command with the optional :set argument.

Consider this example:

query :use "sql" :set ["awl_score", "awl_count"] "SELECT score, count FROM awl WHERE sender = ? AND ip = ?" ["${env.from}", "%{env.remote_ip}"];

The above Sieve script fetches the score and count columns from the awl table in an SQL database and stores them as the Sieve variables awl_score and awl_count respectively.

To learn more about fetching data from SQL or LDAP queries, check out the query extension documentation.

Conclusion​

These features allow for more advanced filtering mechanisms and more powerful Sieve scripts. We hope you enjoy them!

In the digital age where privacy and data protection are paramount, we continually strive to enhance the security features offered by Stalwart Mail Server. Today, we're thrilled to announce our latest upgrade – Encryption at Rest!

Understanding Encryption at Rest​

Encryption at Rest is designed to protect your data when it's stored, or 'at rest,' on your server. This new feature introduces the ability to automatically encrypt plain-text email messages with OpenPGP (Pretty Good Privacy) or S/MIME (Secure/Multipurpose Internet Mail Extensions) before being written to disk. It provides the option to use either AES256 or AES128 encryption for PGP and AES256-CBC or AES128-CBC for S/MIME.

Why It Matters​

With Encryption at Rest, your data remains secure even in the event of a physical storage breach. The encrypted data stored on your mail server is inaccessible without the unique decryption keys. Even system administrators don't have the capacity to decrypt these messages, reinforcing the privacy of your communications.

How it Works​

Encryption at rest in Stalwart Mail Server is easy to enable and use. All it requires is for users to upload their S/MIME certificate or PGP public key using a user-friendly web interface. These keys are utilized to automatically encrypt plain-text messages before they are written to disk.

Comparative Look​

What sets Stalwart Mail Server's implementation apart is its unique approach to key management. Unlike some other mail servers, Stalwart Mail Server does not store the private key on the server or in the database. This means that even the system administrators or anyone with access to the database won't be able to decrypt your messages.

Take for instance, Dovecot's mail-crypt plugin. While it's a powerful tool for ensuring the security of email storage, its design requires the private key to be stored in the database. This effectively means that your emails can still be decrypted by someone with the right access. In contrast, Stalwart Mail Server provides an extra layer of security by allowing the user to retain sole possession of their private keys.

Looking Ahead​

At Stalwart Labs, we're committed to your data protection and privacy. Encryption at Rest is a significant addition to our email security arsenal, and we're excited for you to start using it. For detailed information on Encryption at Rest and instructions on its use, please visit our updated documentation and FAQ.

Stay tuned for more updates, and happy mailing!

It’s official! We are proud to announce the release of Stalwart SMTP, the next-generation email server solution written in Rust for businesses, organizations, and individuals alike.

Stalwart SMTP is a robust and secure email server that offers a comprehensive set of features to meet the needs of today’s demanding email communications. Whether you’re running a large enterprise or a small business, Stalwart SMTP is designed to handle the most complex email environments with ease.

One of the key features of Stalwart SMTP is its support for advanced email security protocols, including DMARC, DKIM, SPF, ARC, DANE, MTA-STS, and SMTP TLS reporting. This means that you can be sure that your emails are protected from spoofing and phishing attempts, and that your email messages are delivered securely to their intended recipients.

We are confident that Stalwart SMTP will meet the needs of businesses and organizations of all sizes, and we look forward to hearing your feedback and suggestions. To learn more about Stalwart SMTP, visit our website and start exploring the many features and benefits of this powerful email server solution.

We are happy to announce Stalwart JMAP, an open-source JSON Meta Application Protocol server written in Rust that aims to be scalable, robust and secure.

Some of its key features are:

• JMAP Core, JMAP Mail and JMAP over WebSocket full compliance.
• IMAP4 rev2/1 support via Stalwart IMAP, an imap-to-jmap proxy.
• Scalable and fault tolerant: consensus over Raft, node autodiscovery over gossip and read-only replicas.
• RocksDB backend with full-text search support in 17 languages.
• OAuth 2.0 authorization code and device authorization flows.
• Domain Keys Identified Mail (DKIM) message signing.
• Written in Rust.
• No third-party software required to run or scale.

Currently Stalwart JMAP requires an SMTP server such as Postfix in order to receive e-mails. However, the next item on the roadmap is to release an SMTP server in Rust with the goal of making self-hosting an e-mail server much simpler without sacrificing any security.

Building and sending e-mails securely does not have to be complicated. Today the mail-send crate was released including the following features:

• Generates e-mail messages conforming to the Internet Message Format standard (RFC 5322) with full MIME support (RFC 2045–2049) and automatic selection of the most optimal encoding for each message body part.
• DomainKeys Identified Mail (DKIM) Signatures (RFC 6376).
• SMTP support with TLS and multiple authentication mechanisms (XOAUTH2, CRAM-MD5, DIGEST-MD5, LOGIN and PLAIN).
• Full async (requires Tokio).

Composing and sending an e-mail message via SMTP is as simple as:

        // Build a simple multipart message
        let message = MessageBuilder::new()
            .from(("John Doe", "[email protected]"))
            .to(vec![
                ("Jane Doe", "[email protected]"),
                ("James Smith", "[email protected]"),
            ])
            .subject("Hi!")
            .html_body("<h1>Hello, world!</h1>")
            .text_body("Hello world!");
    
        // Connect to an SMTP relay server over TLS and
        // authenticate using the provided credentials.
        Transport::new("smtp.gmail.com")
            .credentials("john", "p4ssw0rd")
            .connect_tls()
            .await
            .unwrap()
            .send(message)
            .await
            .unwrap();

And to sign a message with DKIM just do:

    // Build a simple text message with a single attachment
        let message = MessageBuilder::new()
            .from(("John Doe", "[email protected]"))
            .to("[email protected]")
            .subject("Howdy!")
            .text_body("These pretzels are making me thirsty.")
            .binary_attachment("image/png", "pretzels.png", [1, 2, 3, 4].as_ref());
    
        // Set up DKIM signer
        let dkim = DKIM::from_pkcs1_pem_file("./cert.pem")
            .unwrap()
            .domain("example.com")
            .selector("2022")
            .headers(["From", "To", "Subject"]) // Headers to sign
            .expiration(60 * 60 * 7); // Number of seconds before this signature expires (optional)
    
        // Connect to an SMTP relay server over TLS.
        // Signs each message with the configured DKIM signer.
        Transport::new("smtp.example.com")
            .dkim(dkim)
            .connect_tls()
            .await
            .unwrap()
            .send(message)
            .await
            .unwrap();

More examples can be found on Github. Enjoy DKIM signing!

Back in November we released mail-parser, a Rust library to parse MIME e-mail messages of any complexity. Today we are proud to announce the release of mail-builder, a simple yet powerful library to build RFC5322 e-mail messages with MIME support.

Using mail-builder is straightforward:

        // Build a simple text message with a single attachment
        let mut message = MessageBuilder::new();
        message.from(("John Doe", "[email protected]"));
        message.to("[email protected]");
        message.subject("Hello, world!");
        message.text_body("Message contents go here.");
        message.binary_attachment("image/png", "image.png", &[1, 2, 3, 4]);

        // Write message to memory
        let mut output = Vec::new();
        message.write_to(&mut output).unwrap();

More complex messages with grouped addresses, inline parts and multipart/alternative sections can also be easily built:

        // Build a multipart message with text and HTML bodies,
        // inline parts and attachments.
        let mut message = MessageBuilder::new();
        message.from(("John Doe", "[email protected]"));

        // To recipients
        message.to(vec![
            ("Antoine de Saint-Exupéry", "[email protected]"),
            ("안녕하세요 세계", "[email protected]"),
            ("Xin chào", "[email protected]"),
        ]);

        // BCC recipients using grouped addresses
        message.bcc(vec![
            (
                "My Group",
                vec![
                    ("ASCII name", "[email protected]"),
                    ("ハロー・ワールド", "[email protected]"),
                    ("áéíóú", "[email protected]"),
                    ("Γειά σου Κόσμε", "[email protected]"),
                ],
            ),
            (
                "Another Group",
                vec![
                    ("שלום עולם", "[email protected]"),
                    ("ñandú come ñoquis", "[email protected]"),
                    ("Recipient", "[email protected]"),
                ],
            ),
        ]);

        // Set RFC and custom headers
        message.subject("Testing multipart messages");
        message.in_reply_to(vec!["message-id-1", "message-id-2"]);
        message.header("List-Archive", URL::new("http://example.com/archive"));

        // Set HTML and plain text bodies
        message.text_body("This is the text body!\n");
        message.html_body("<p>HTML body with <img src=\"cid:my-image\"/>!</p>");

        // Include an embedded image as an inline part
        message.binary_inline("image/png", "cid:my-image", &[0, 1, 2, 3, 4, 5]);

        // Add a text and a binary attachment
        message.text_attachment("text/plain", "my fíle.txt", "Attachment contents go here.");
        message.binary_attachment(
            "text/plain",
            "ハロー・ワールド",
            b"Binary contents go here.",
        );

        // Write the message to a file
        message
            .write_to(File::create("message.eml").unwrap())
            .unwrap();

Nested MIME body structures can be created using the body method:

    // Build a nested multipart message
        let mut message = MessageBuilder::new();

        message.from(Address::new_address("John Doe".into(), "[email protected]"));
        message.to(Address::new_address("Jane Doe".into(), "[email protected]"));
        message.subject("Nested multipart message");

        // Define the nested MIME body structure
        message.body(MimePart::new_multipart(
            "multipart/mixed",
            vec![
                MimePart::new_text("Part A contents go here...").inline(),
                MimePart::new_multipart(
                    "multipart/mixed",
                    vec![
                        MimePart::new_multipart(
                            "multipart/alternative",
                            vec![
                                MimePart::new_multipart(
                                    "multipart/mixed",
                                    vec![
                                        MimePart::new_text("Part B contents go here...").inline(),
                                        MimePart::new_binary(
                                            "image/jpeg",
                                            "Part C contents go here...".as_bytes(),
                                        )
                                        .inline(),
                                        MimePart::new_text("Part D contents go here...").inline(),
                                    ],
                                ),
                                MimePart::new_multipart(
                                    "multipart/related",
                                    vec![
                                        MimePart::new_html("Part E contents go here...").inline(),
                                        MimePart::new_binary(
                                            "image/jpeg",
                                            "Part F contents go here...".as_bytes(),
                                        ),
                                    ],
                                ),
                            ],
                        ),
                        MimePart::new_binary("image/jpeg", "Part G contents go here...".as_bytes())
                            .attachment("image_G.jpg"),
                        MimePart::new_binary(
                            "application/x-excel",
                            "Part H contents go here...".as_bytes(),
                        ),
                        MimePart::new_binary(
                            "x-message/rfc822",
                            "Part J contents go here...".as_bytes(),
                        ),
                    ],
                ),
                MimePart::new_text("Part K contents go here...").inline(),
            ],
        ));

        // Write the message to a file
        message
            .write_to(File::create("nested-message.eml").unwrap())
            .unwrap();

The library is available at https://crates.io/crates/mail-builder and the documentation at https://docs.rs/mail-builder.

Today we released mail-parser, an e-mail parsing library written in Rust that fully conforms to the Internet Message Format standard (RFC 5322), the Multipurpose Internet Mail Extensions (MIME; RFC 2045–2049) as well as other internet messaging RFCs.

It also supports decoding messages in 41 different character sets including obsolete formats such as UTF-7. All Unicode (UTF-*) and single-byte character sets are handled internally by the library while support for legacy multi-byte encodings of Chinese and Japanese languages such as BIG5 or ISO-2022-JP is provided by the optional dependency encoding_rs.

In general, this library abides by the Postel’s law or Robustness Principle which states that an implementation must be conservative in its sending behavior and liberal in its receiving behavior. This means that mail-parser will make a best effort to parse non-conformant e-mail messages as long as these do not deviate too much from the standard.

Unlike other e-mail parsing libraries that return nested representations of the different MIME parts in a message, this library conforms to RFC 8621, Section 4.1.4 and provides a more human-friendly representation of the message contents consisting of just text body parts, html body parts and attachments. Additionally, conversion to/from HTML and plain text inline body parts is done automatically when the alternative version is missing.

Performance and memory safety were two important factors while designing mail-parser:

• Zero-copy: Practically all strings returned by this library are Cow<str> references to the input raw message.
• High performance Base64 decoding based on Chromium’s decoder (the fastest non-SIMD decoder).
• Fast parsing of message header fields, character set names and HTML entities using perfect hashing.
• Written in 100% safe Rust with no external dependencies.
• Every function in the library has been fuzzed and meticulously tested with MIRI.
• Thoroughly battle-tested with millions of real-world e-mail messages dating from 1995 until today.

The library conforms to all internet messaging RFCs:

• RFC 822 — Standard for ARPA Internet Text Messages
• RFC 5322 — Internet Message Format
• RFC 2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
• RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
• RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
• RFC 2048 — Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
• RFC 2049 — Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
• RFC 2231 — MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
• RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
• RFC 6532 — Internationalized Email Headers
• RFC 2152 — UTF-7 — A Mail-Safe Transformation Format of Unicode
• RFC 2369 — The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
• RFC 2919 — List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
• RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail (Section 4.1.4)

And supports 41 different character set encodings:

• UTF-8
• UTF-16, UTF-16BE, UTF-16LE
• UTF-7
• US-ASCII
• ISO-8859–1
• ISO-8859–2
• ISO-8859–3
• ISO-8859–4
• ISO-8859–5
• ISO-8859–6
• ISO-8859–7
• ISO-8859–8
• ISO-8859–9
• ISO-8859–10
• ISO-8859–13
• ISO-8859–14
• ISO-8859–15
• ISO-8859–16
• CP1250
• CP1251
• CP1252
• CP1253
• CP1254
• CP1255
• CP1256
• CP1257
• CP1258
• KOI8-R
• KOI8_U
• MACINTOSH
• IBM850
• TIS-620
• SHIFT_JIS
• BIG5
• EUC-JP
• EUC-KR
• GB18030
• GBK
• ISO-2022-JP
• WINDOWS-874
• IBM-866

Using the library is straightforward:

    let input = concat!(
            "From: Art Vandelay <[email protected]> (Vandelay Industries)\n",
            "To: \"Colleagues\": \"James Smythe\" <[email protected]>; Friends:\n",
            "    [email protected], =?UTF-8?Q?John_Sm=C3=AEth?= <[email protected]>;\n",
            "Date: Sat, 20 Nov 2021 14:22:01 -0800\n",
            "Subject: Why not both importing AND exporting? =?utf-8?b?4pi6?=\n",
            "Content-Type: multipart/mixed; boundary=\"festivus\";\n\n",
            "--festivus\n",
            "Content-Type: text/html; charset=\"us-ascii\"\n",
            "Content-Transfer-Encoding: base64\n\n",
            "PGh0bWw+PHA+SSB3YXMgdGhpbmtpbmcgYWJvdXQgcXVpdHRpbmcgdGhlICZsZHF1bztle\n",
            "HBvcnRpbmcmcmRxdW87IHRvIGZvY3VzIGp1c3Qgb24gdGhlICZsZHF1bztpbXBvcnRpbm\n",
            "cmcmRxdW87LDwvcD48cD5idXQgdGhlbiBJIHRob3VnaHQsIHdoeSBub3QgZG8gYm90aD8\n",
            "gJiN4MjYzQTs8L3A+PC9odG1sPg==\n",
            "--festivus\n",
            "Content-Type: message/rfc822\n\n",
            "From: \"Cosmo Kramer\" <[email protected]>\n",
            "Subject: Exporting my book about coffee tables\n",
            "Content-Type: multipart/mixed; boundary=\"giddyup\";\n\n",
            "--giddyup\n",
            "Content-Type: text/plain; charset=\"utf-16\"\n",
            "Content-Transfer-Encoding: quoted-printable\n\n",
            "=FF=FE=0C!5=D8\"=DD5=D8)=DD5=D8-=DD =005=D8*=DD5=D8\"=DD =005=D8\"=\n",
            "=DD5=D85=DD5=D8-=DD5=D8,=DD5=D8/=DD5=D81=DD =005=D8*=DD5=D86=DD =\n",
            "=005=D8=1F=DD5=D8,=DD5=D8,=DD5=D8(=DD =005=D8-=DD5=D8)=DD5=D8\"=\n",
            "=DD5=D8=1E=DD5=D80=DD5=D8\"=DD!=00\n",
            "--giddyup\n",
            "Content-Type: image/gif; name*1=\"about \"; name*0=\"Book \";\n",
            "              name*2*=utf-8''%e2%98%95 tables.gif\n",
            "Content-Transfer-Encoding: Base64\n",
            "Content-Disposition: attachment\n\n",
            "R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7\n",
            "--giddyup--\n",
            "--festivus--\n",
        )
        .as_bytes();
    
        let message = Message::parse(input);
    
        // Parses addresses (including comments), lists and groups
        assert_eq!(
            message.get_from(),
            &Address::Address(Addr {
                name: Some("Art Vandelay (Vandelay Industries)".into()),
                address: Some("[email protected]".into())
            })
        );
        assert_eq!(
            message.get_to(),
            &Address::GroupList(vec![
                Group {
                    name: Some("Colleagues".into()),
                    addresses: vec![Addr {
                        name: Some("James Smythe".into()),
                        address: Some("[email protected]".into())
                    }]
                },
                Group {
                    name: Some("Friends".into()),
                    addresses: vec![
                        Addr {
                            name: None,
                            address: Some("[email protected]".into())
                        },
                        Addr {
                            name: Some("John Smîth".into()),
                            address: Some("[email protected]".into())
                        }
                    ]
                }
            ])
        );
    
        assert_eq!(
            message.get_date().unwrap().to_iso8601(),
            "2021-11-20T14:22:01-08:00"
        );
    
        // RFC2047 support for encoded text in message readers
        assert_eq!(
            message.get_subject().unwrap(),
            "Why not both importing AND exporting? ☺"
        );
    
        // HTML and text body parts are returned conforming to RFC8621, Section 4.1.4 
        assert_eq!(
            message.get_html_body(0).unwrap().to_string(),
            concat!(
                "<html><p>I was thinking about quitting the &ldquo;exporting&rdquo; to ",
                "focus just on the &ldquo;importing&rdquo;,</p><p>but then I thought,",
                " why not do both? &#x263A;</p></html>"
            )
        );
    
        // HTML parts are converted to plain text (and viceversa) when missing
        assert_eq!(
            message.get_text_body(0).unwrap().to_string(),
            concat!(
                "I was thinking about quitting the “exporting” to focus just on the",
                " “importing”,\nbut then I thought, why not do both? ☺\n"
            )
        );
    
        // Supports nested messages as well as multipart/digest
        let nested_message = match message.get_attachment(0).unwrap() {
            MessagePart::Message(v) => v,
            _ => unreachable!(),
        };
    
        assert_eq!(
            nested_message.get_subject().unwrap(),
            "Exporting my book about coffee tables"
        );
    
        // Handles UTF-* as well as many legacy encodings
        assert_eq!(
            nested_message.get_text_body(0).unwrap().to_string(),
            "ℌ𝔢𝔩𝔭 𝔪𝔢 𝔢𝔵𝔭𝔬𝔯𝔱 𝔪𝔶 𝔟𝔬𝔬𝔨 𝔭𝔩𝔢𝔞𝔰𝔢!"
        );
        assert_eq!(
            nested_message.get_html_body(0).unwrap().to_string(),
            "<html><body>ℌ𝔢𝔩𝔭 𝔪𝔢 𝔢𝔵𝔭𝔬𝔯𝔱 𝔪𝔶 𝔟𝔬𝔬𝔨 𝔭𝔩𝔢𝔞𝔰𝔢!</body></html>"
        );
    
        let nested_attachment = match nested_message.get_attachment(0).unwrap() {
            MessagePart::Binary(v) => v,
            _ => unreachable!(),
        };
    
        assert_eq!(nested_attachment.len(), 42);
    
        // Full RFC2231 support for continuations and character sets
        assert_eq!(
            nested_attachment
                .get_header()
                .unwrap()
                .get_content_type()
                .unwrap()
                .get_attribute("name")
                .unwrap(),
            "Book about ☕ tables.gif"
        );
    
        // Integrates with Serde
        println!("{}", serde_json::to_string_pretty(&message).unwrap());
        println!("{}", serde_yaml::to_string(&message).unwrap());

The mail-parser library is available on Crates.io (https://crates.io/crates/mail-parser) and the documentation at https://docs.rs/mail-parser/.

Please follow us on Twitter for updates!