Mail-Make

 view release on metacpan or  search on metacpan

CHANGES  view on Meta::CPAN

    - Improved documentation
    - Correction in Mail::Make::Body::InCore open method
    - Added the method return_path in Mail::Make

v0.21.0 2026-03-07T03:04:20+0900
    - Initial public release on CPAN

    [Core features]
    - Fluent API for constructing MIME email messages (plain text, HTML,
      multipart/alternative, multipart/mixed, inline attachments)
    - Mail::Make::Entity: full MIME entity model with streaming serialisation
      via Mail::Make::Stream, Mail::Make::Stream::Base64, and
      Mail::Make::Stream::QuotedPrint
    - Mail::Make::Headers and subclasses: typed header objects for
      Content-Type (with parameter handling and RFC 2231 encoding),
      Content-Transfer-Encoding, Content-Disposition, Subject (RFC 2047
      encoded-word), and Message-ID (UUID-based generation)
    - Mail::Make::Body::InCore and Mail::Make::Body::File: transparent
      in-memory and on-disk body storage; large attachments never loaded
      into RAM unless explicitly requested
    - Configurable memory threshold (max_body_in_memory_size) and explicit
      use_temp_file option for streaming large messages
    - Entity::length() mirrors print() without buffering the entire message
    - Headers::as_string() with RFC 2822 field ordering and line folding

    [SMTP delivery (smtpsend)]
    - Net::SMTP integration with plain TCP, SSL/TLS, and STARTTLS support
    - SASL authentication (PLAIN/LOGIN preferred, DIGEST-MD5/CRAM-MD5
      intentionally excluded as deprecated); Authen::SASL used directly to
      avoid mechanism negotiation pitfalls
    - Passphrase supplied as string or CODE reference
    - Bcc stripping from the transmitted copy

README  view on Meta::CPAN

S/MIME METHODS
    These methods delegate to Mail::Make::SMIME, which requires Crypt::SMIME
    (an XS module wrapping OpenSSL "libcrypto"). All certificates and keys
    must be supplied in PEM format, either as file paths or as PEM strings.

  Memory usage
    All three methods load the complete serialised message into memory
    before performing any cryptographic operation. This is a fundamental
    constraint imposed by two factors: the Crypt::SMIME API accepts only
    Perl strings (no filehandle or streaming interface), and the underlying
    protocols themselves require the entire content to be available before
    the result can be emitted, thus signing requires a complete hash before
    the signature can be appended, and PKCS#7 encryption requires the total
    payload length to be declared in the ASN.1 DER header before any
    ciphertext is written.

    For typical email messages this is not a concern. If you anticipate very
    large attachments, consider Mail::Make::GPG instead, which delegates to
    the "gpg" command-line tool via IPC::Run and can handle arbitrary
    message sizes through temporary files. A future "v0.2.0" of

README.md  view on Meta::CPAN

        Passphrase => sub { MyKeyring::get_passphrase() },
        Recipients => [ 'alice@example.com', 'bob@example.com' ],
    ) || die( $mail->error );

# S/MIME METHODS

These methods delegate to [Mail::Make::SMIME](https://metacpan.org/pod/Mail%3A%3AMake%3A%3ASMIME), which requires [Crypt::SMIME](https://metacpan.org/pod/Crypt%3A%3ASMIME) (an XS module wrapping OpenSSL `libcrypto`). All certificates and keys must be...

## Memory usage

All three methods load the complete serialised message into memory before performing any cryptographic operation. This is a fundamental constraint imposed by two factors: the [Crypt::SMIME](https://metacpan.org/pod/Crypt%3A%3ASMIME) API accepts only ...

For typical email messages this is not a concern. If you anticipate very large attachments, consider [Mail::Make::GPG](https://metacpan.org/pod/Mail%3A%3AMake%3A%3AGPG) instead, which delegates to the `gpg` command-line tool via [IPC::Run](https://me...

See ["MEMORY USAGE AND LIMITATIONS" in Mail::Make::SMIME](https://metacpan.org/pod/Mail%3A%3AMake%3A%3ASMIME#MEMORY-USAGE-AND-LIMITATIONS) for a full discussion.

## smime\_encrypt( %opts )

    $encrypted = $mail->smime_encrypt(
        RecipientCert => $smime_rec_cert,
    );

lib/Mail/Make.pm  view on Meta::CPAN

        Passphrase => sub { MyKeyring::get_passphrase() },
        Recipients => [ 'alice@example.com', 'bob@example.com' ],
    ) || die( $mail->error );

=head1 S/MIME METHODS

These methods delegate to L<Mail::Make::SMIME>, which requires L<Crypt::SMIME> (an XS module wrapping OpenSSL C<libcrypto>). All certificates and keys must be supplied in PEM format, either as file paths or as PEM strings.

=head2 Memory usage

All three methods load the complete serialised message into memory before performing any cryptographic operation. This is a fundamental constraint imposed by two factors: the L<Crypt::SMIME> API accepts only Perl strings (no filehandle or streaming i...

For typical email messages this is not a concern. If you anticipate very large attachments, consider L<Mail::Make::GPG> instead, which delegates to the C<gpg> command-line tool via L<IPC::Run> and can handle arbitrary message sizes through temporary ...

See L<Mail::Make::SMIME/"MEMORY USAGE AND LIMITATIONS"> for a full discussion.

=head2 smime_encrypt( %opts )

    $encrypted = $mail->smime_encrypt(
        RecipientCert => $smime_rec_cert,
    );

lib/Mail/Make/SMIME.pm  view on Meta::CPAN

=head1 MEMORY USAGE AND LIMITATIONS

=head2 In-memory processing

All cryptographic operations performed by this module load the complete serialised message into memory before signing or encrypting it. This is a consequence of two factors:

=over 4

=item 1. C<Crypt::SMIME> API

L<Crypt::SMIME> accepts and returns plain Perl strings. It does not expose a streaming or filehandle-based interface.

=item 2. Protocol constraints

B<Signing> requires computing a cryptographic hash (e.g. SHA-256) over the entire content to be signed. Although the hash algorithm itself is sequential and could theoretically operate on a stream, the resulting C<multipart/signed> structure must car...

B<Encryption> uses a symmetric cipher (AES by default) operating on PKCS#7 C<EnvelopedData>. The ASN.1 DER encoding of C<EnvelopedData> declares the total length of the encrypted payload in the structure header, which must be known before the first b...

=back

=head2 Practical impact

For typical email messages, such as plain text, HTML, and modest attachments, memory consumption is not a concern. Problems may arise with very large attachments (tens of megabytes or more).

=head2 Future work

A future C<v0.2.0> of C<Mail::Make::SMIME> may optionally delegate to the C<openssl smime> command-line tool via L<IPC::Run>, using temporary files, to support large messages without holding them in memory. This mirrors the approach already used by L...

If in-memory processing is a concern for your use case, consider using L<Mail::Make::GPG> instead: OpenPGP uses I<partial body packets> (RFC 4880 §4.2.2) which allow true streaming without knowing the total message size in advance.

=head1 CONSTRUCTOR

=head2 new( %opts )

    my $smime = Mail::Make::SMIME->new(
        cert         => '/path/to/cert.pem',
        key          => '/path/to/key.pem',
        key_password => 'secret',    # or CODE ref
        ca_cert      => '/path/to/ca.pem',