While analyzing what mail library to use when refactoring a code base, we discovered that the available ones are mostly legacy libraries. Some do not use namespaces and every library we encountered was merely a collection of scalar property bags than objects using encapsulation. Although we used these libs with joy in the past, they do not meet current quality standards. So, we built a new and better library according to modern programming principles.
Use this if you want to send e-mails over different transports and protocols using immutable messages and streams.
use Genkgo\Mail;
$message = (new Mail\MessageBodyCollection('<html><body><p>Hello World</p></body></html>'))
->withAttachment(new Mail\Mime\FileAttachment('/order1.pdf', new Mail\Header\ContentType('application/pdf')))
->createMessage()
->withHeader(new Mail\Header\Subject('Hello World'))
->withHeader(Mail\Header\From::fromEmailAddress('[email protected]'))
->withHeader(Mail\Header\To::fromSingleRecipient('[email protected]', 'name'))
->withHeader(Mail\Header\Cc::fromSingleRecipient('[email protected]', 'name'));
$transport = new Mail\Transport\SmtpTransport(
Mail\Protocol\Smtp\ClientFactory::fromString('smtp://user:pass@host/')->newClient(),
Mail\Transport\EnvelopeFactory::useExtractedHeader()
);
$transport->send($message);$ composer require genkgo/mail- Use SMTP or mail() to send messages
- Use IMAPv4 to read messages from your mailbox (no extension required)
- Create replies and forward messages, including quoting of original message
- Queue messages when transport fails
- Automatically connects and reconnects after interval to SMTP server
- Automatically generate alternative text for formatted messages
- Optimal encoded headers, so no excessive (Q/B) encoded headers
- Optimal encoded multipart messages
- Only streams and connections are mutable
- Messages and actors are immutable
- Value objects protect against invalid states
- Streams make sure the library has a low memory burden
- Many objects but still easy API
- 90%+ test coverage
- Uses highest PHPStan detection level
- Only uses TLS < 1.2 if not otherwise possible
- Discourages SSL
- DKIM signed message
- Security is highly prioritized
- SMTP server for testing purposes
- Great RFC compliance
- Cast messages to valid string source
- Library has no external dependencies (but uses intl extension)
- Only supports PHP versions that are not EOL
- Encrypted and signed messages
The following features are not planned for development by the owners, but could become part of the library when initiative is taken by the community.
- POP Support
- Mailbox abstraction layer
This library tends to be as compliant with e-mail RFCs as possible. It should be compliant with the following RFCs.
- RFC 821, Simple Mail Transfer Protocol
- RFC 1896, The text/enriched MIME Content-type
- RFC 2822, Internet Message Format
- RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One
- RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two
- RFC 2047, Multipurpose Internet Mail Extensions (MIME) Part Three
- RFC 2048, Multipurpose Internet Mail Extensions (MIME) Part Four
- RFC 2049, Multipurpose Internet Mail Extensions (MIME) Part Five
- RFC 2392, Content-ID and Message-ID Uniform Resource Locators
- RFC 2821, Simple Mail Transfer Protocol
- RFC 3501, Internet Message Access Protocol - version 4rev1
- RFC 4954, SMTP Service Extension for Authentication
- RFC 5321, Simple Mail Transfer Protocol
- RFC 6530, Overview and Framework for Internationalized Email
This library was not able to exist without Zend/Mail and PHPMailer.