Download the PHP package kodus/mail without Composer

On this page you can find all versions of the php package kodus/mail. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package mail

kodus/mail

PHP Version Build Status Code Coverage Scrutinizer Code Quality

Simple services for sending UTF-8 e-mail.

See UPGRADING.md for upgrade instructions.

Features

Non-Features

Some features are delibarely outside the scope of this project:

Overview

Mail service implementations are abstracted behind the MailService interface, which depends on the Message model to define the actual content.

To send mail, simply create an instance of Message, populate it with new instances of Address and Attachment models by calling various public set/add-methods, then call MailService::send().

The model permits any combination of UTF-8 text and HTML message bodies with any number of attachments.

Usage

The following example assumes a MailService instance named $service is in scope - subsequent sections will explain how to configure an e-mail service.

Here's an example of sending a plain-text e-mail with an attachment:

Refer to the Message model to learn about additional message properties.

SMTP Mail Service

The SMTPMailService implementation connects directly to an SMTP server via sockets.

To bootstrap an SMTP mail service, you need to select your Connector and Authenticator implementations - for example:

Note the third argument, which is the local host-name - this is used in the handshake (EHLO) message send to the SMTP server when the client connects.

SMTP protocol-level logging is supported for diagnostic purposes, and can be enabled by injecting a PSR-3 Logger into SMTPClient via SMTPClient::setLogger() - this may be useful if you have connection issues, as it will write a debug-level entry for every SMTP command sent, and every response received.

Message Logging

Unlike SMTP protocol-level logging described above, a more general logging facility is also available - this will write a single log-entry on success or failure to send a message, and is more generally applicable to any MailService implementation, including of course the SMTP service.

To write a log-entry to a PSR-3 Logger, use the MailSeviceLogger implementation, which acts as a decorator for any other MailService implementation - for example:

See inline documentation for MailServiceLogger for details on customizing the message template and log-level.

Passive Mail Service

A passive implementation of MailService is available, which does nothing.

You can use this during testing/development to disable any outgoing Messages.

This is typically most useful in conjunction with the MailServiceLogger described above, to bootstrap a fake mail-service for testing and development, enabling you to see Messages that would have been sent.

Development

To run the integration tests, you will need to set up a local SMTP server for testing.

To make sure SecureSocketCest passes your SMTP server also needs to have TLS support with a SSL certificate.

It is recommended to use smtp4dev since it has cross-platform support and can generate its own self-signed SSL certificate.

When configuring smtp4dev make sure to set TlsMode to StartTls, this ensures that TLS is only used when the client asks for it, setting it to ImplicitTls will likely make all non-TLS tests fail.

When starting the smtp4dev server it should tell you where the generated certificate is stored, you'll need to add this to your systems trusted CA store.

You may need to copy integration.suite.dist.yml to integration.suite.yml to customize the SMTP host-name, port-number, etc.

Objectives

This library has a number of stated design objectives:


All versions of mail with dependencies

PHP Build Version
Package Version
Requires php Version >= 8.0
psr/log Version ^1 || ^2 || ^3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package kodus/mail contains the following files

Loading the files please wait ....