When you use an endpoint other than one ending in /mime mailgun sends across a bunch of really useful content in the request - e.g. "trimmed-text" which is the message text without any signatures or similar.

Unfortunately mailgun don't send this information when using a /mime endpoint and instead sends across "mime-body" which we're using to construct the message.

I'm not sure it would be possible but thought I'd float the idea of seeing if we can reconstruct the message from the extended mailgun information rather than the mime version which would give developers easy access to this additional information.

I saw that the composer.json was updated in master to support Laravel 9 but there are a couple of other changes necessary to support L9 since the Swift Mailer was replaced with the Symfony Mailer.

The Log driver and InboundEmail files needed updates. I implemented to be backward compatible by checking the app()->version() in each instance. I also added a run-tests action to test against L6-9 on php 7.3, 8 and 8.1 I confirmed that all tests failed prior to my changes and they all pass on all supported php/laravel combinations.

Move composer dependency zendframework/zend-mail to laminas/laminas-mail due to Zend Framework migration.

Upgraded the tests to use the new Laminas namespace.

This will help to speed things up when they add PHP 8 support (see https://github.com/laminas/laminas-mail/pull/117) to fix issue https://github.com/beyondcode/laravel-mailbox/issues/78 ;)

Edit, March 9 2021: now that Laminas added support for PHP 8, I updated the composer.json php versions and renamed the PR from "Migrate composer dependency from Zend to Laminas" to "Add PHP 8.0 support"

Hello @mpociot, as promised, here comes the big change PR. Take a look and feel free to comment. Independently of the outcome, I will continue to support my version since I need it anyways. I understand if this is too much of a change to accept, and that is fine as well. Thanks in advance.

Change log

Concept

The main entity is a MailboxGroup. What it enables you to do is to have multiple Mailboxes, each with its own set of patterns and actions to execute.

Refactor has been done so that Mailbox provides a fluent API to define same set of features as before with some nice additions.

Example:

$mailbox = new Mailbox();

$mailbox
    ->from('{user}@gmail.com')
    ->to('{user2}@gmail.com')
    ->subject('Subject to match')
    ->where('user', '.*')
    ->where('user2', '.*')
    ->action(function (InboundEmail $email) {
        Log::info("Mail received");
    })
    ->matchEither()
    ->priority(10);

The concept now is that each mailbox has a single or multiple rules it can match, however it can have only one action to execute. Reason being to enable matching all or either of the rules imposed.

By default, all patterns need to be matched in order for action to be executed. So if you provide from and to, they both need to match. This can be changed by including a matchEither() function which will transform this logic to matching at least one.

Due to the fact that multiple mailboxes can exist now, MailboxGroup is responsible for running them. Executing MailboxGroup::run($email) will run all the mailboxes, but will before order them by given priority(). Mailbox has a default priority of 0. The bigger the number, the sooner it is executed.

Group example:

$group = new MailboxGroup(); 

$group
    ->add($mailbox)
    ->add($mailbox2)
    ->add($mailbox3) 
    ->fallback(function (InboundEmail $email) {
        Log::info("Fell back");
    })
    ->continuousMatching()
    ->run($email);

You are responsible for adding mailboxes to the group (be it in the service provider or the controller itself). Fallback is pulled out to MailboxGroup for logical reasons. If none of the mailboxes match, fallback will be executed. A new feature here is that mailboxes will, by default, stop at first match. Meaning, if out of 5 mailboxes, second one matches the incoming mail, execution will stop. This can be overridden including the continuousMatching() function which will run through all mailboxes. So if match is found in 3/5 mailboxes, those 3 callbacks will be executed.

Dependencies

PHP version has been bumped to 7.4. Breaking changes are introduced, 7.3 is no longer supported, and in the next few days I will complete all type hints and return types, together with strict modes included.

Support for 6.x Laravel has been dropped. composer install requires a ton of memory with it, breaking most of the times if you don't give more memory to it. This is also the reason Scrutinizer checks break.

Drivers

I have removed drivers all together. Reason being that they were (at least for me) ambiguous, and their only purpose was exposing routes behind the scenes. Current setup also doesn't limit you in using a single driver.

I like my code to be explicit, so currently in order to set up the package you need to:

1. Set up endpoint manually (I like single action controllers for these purposes, but not mandatory):

Route::post('receive', ReceiveEmailController::class);

2. Add a MailboxRequest form request validation, or extend it if needed.

public function __invoke(MailboxRequest $request)
{
    ...
}

3. Define mailboxes and run them:

public function __invoke(MailboxRequest $request)
{
    $mailbox = (new Mailbox())->from(...)->action(...);

    MailboxGroup::add($mailbox);
    MailboxGroup::run($request->email());
}

4. Alternatively, you can define mailboxes in your service provider boot method, leaving the controller clean:

// App service provider
public function boot()
{
    $mailbox = (new Mailbox())->from(...)->action(...);

    MailboxGroup::add($mailbox);
}

// Controller
public function __invoke(MailboxRequest $request)
{
    MailboxGroup::run($request->email());
}

5. Alternatively, option I prefer is to pull out mailbox definition to a separate class and include it within the controller so that it doesn't overburden the rest of API calls.

public function __invoke(MailboxRequest $request)
{
    // Factory leading to defining mailboxes, and ultimately running them.
    MailboxService::receiveEmail($request->email());
}

6.. Controllers being used as driver callbacks are still there for your convenience, so you can point the routes to different variants of those:

Route::post('receive/mailgun', MailgunController::class);
Route::post('receive/mailcare', MailCareController::class);
Route::post('receive/postmark', PostmarkController::class);
Route::post('receive/sendgrid', SendGridController::class);

Dev naming

Some concepts, variables etc. have been renamed to be more intuitive.

Tests

Tests which made sense were modified to pass, other were deleted as things like Route and RouteCollection no longer exist. I am willing to support new features with tests.

Readme

I think readme is a tad outdated and unnecessarily long. I will probably rewrite it.

I was trying to implement the laravel-mailbox on our project but got this error saying:

Class 'BeyondCode\Mailbox\Facades\Mailbox' not found

I've used something like this on the web.php file:

<?php

use Illuminate\Support\Facades\Route;
use BeyondCode\Mailbox\Facades\Mailbox;


Route::post('/laravel-mailbox/sendgrid', function () use ($router) {
    \Log::info('Webhook arrives');

    Mailbox::from(config('mail.from.address'), function (InboundEmail $email) {
        // Handle the incoming email
        \Log::info(['id' => $email->id]);
        \Log::info(['subject' => $email->subject]);
        \Log::info(['message' => $email->message]);
    });
});

"beyondcode/laravel-mailbox": "^2.2",
"laravel/framework": "^8.75",

Hello,

I've modified the code to provide truly extensible code with configuration which I deem is simpler than overriding complete classes and re-binding them.

Some of the changes are also due to what I consider misleading nomenclature, but you will find those changes are not so drastic.

I've also added readme for extending.

Keep up the good work, and hit me back if something else is needed.

Regards

I need this package in a project I'm working on. Since there's no (yet) support for Laravel 5.8 I decided to make one :)

In this PR I've just bumped package versions. This (+simple fix in a test case) was enough to make the tests pass.

I have to admit that I didn't test this on a real Laravel installation.

I'd like to add some tests for handling incoming emails.

How can I do it? Should I mock Mailbox facade, or just send some dummy requests to one of the incoming endpoints?

Hi

I have defined my own model called Email, that is extending the default InboundEmail model.

I can see in the Routing/Router.php file, the save() method is like this:

protected function storeEmail(InboundEmail $email)
{
     $email->save();
}

Now in my Email model, I:

• Have extended it to use a new table.
• Is setting a custom variable, in order to "combine" it to a relationship.

In my AppServiceProvider, I am passing the custom variable (token) to my Model:

//AppServiceProvider:
Mailbox::to('{token}@myapp.com', Email::class);

Email.php:

    protected $table = 'emails';

    public function __invoke(InboundEmail $email, $token)
    {
        $email->stream_token = $token;
    }

    /**
     * An email belongs to a Stream.
     */
    public function stream()
    {
        return $this->belongsTo(Stream::class, 'stream_token');
    }

Now my question is: how can I extend the save method, so I can check if the relationship exists in the database before persiting it?

Because my code will fail (500 internal server error), if I send an email to an internal email, but where the {token) does not exist in the database.

Can I do something like this in my Email.php model:

protected function storeEmail(InboundEmail $email, $token)
{
     if($email->stream->exists()){
     $email->stream_token = $token;
     $email->save();
     }else{
      Log::debug('Invalid "to" token. It does not exist in our system');
     
    }
}

Hello,

I have a problem with the parameter in my inbox handler. The handler is defined as Mailbox::from('{application}@yourname.xyz', SupportMailbox::class);

The SupportMailbox Class simple logs the application parameter:

public function __invoke(InboundEmail $email, $application) 
    {
        Log::debug($application);
    }

Everytime I get postmaster as parameter no matter from which mail address the message was sent. Is there a problem with this package?

I can't install Mailbox on my Lumen 6 project.

Lumen doesn't automaticaly register the provider, then, I did a $app->register(BeyondCode\Mailbox\MailboxServiceProvider::class); in bootstrap/app.php.

But then I get the error

Call to undefined function BeyondCode\Mailbox\config_path()

So I've tried a solution found on the Internet https://gist.github.com/mabasic/21d13eab12462e596120 But then I get the error

Call to undefined method Laravel\Lumen\Routing\Router::aliasMiddleware()

I've also installed https://github.com/laravelista/lumen-vendor-publish to have access to vendor:publish

Now I can't do anything but uninstall all of theses...

I am using laravel-mailbox on laravel 8 with mailgun driver. I only need to simply forward the email message. The setup works fine and successfully forwards the email as expected when using mailgun sample webhook but not with realworld emails. When an email is sent from gmail or other medium to the mailgun domain configured, application redirects with a 302

to the root domain. I have tried clearing cache also adding the route laravel-mailbox/mailgun/mime to exclude csrftoken in the middleware, but no luck. Has anyone encountered this? Any help is greatly appreciated.

Hi

it looks like it failed to deploy the proper dependencies for Laravel 9: https://packagist.org/packages/beyondcode/laravel-mailbox

even though your code in repo suggests 9.0 is allowed: https://github.com/beyondcode/laravel-mailbox/blob/master/composer.json

could you try a re-deploy?

Add support for new MAILBOX_DRIVER in-memory "array" driver. It's now the default config.

Deprecate unnecessary MAILBOX_DRIVER "log" driver. If I'm not mistaking, Mailbox doesn't log any emails. Only the Laravel MAIL_MAILER does.

So I believe most people would use these testing environment variables (inside phpunit.xml):

<server name="MAIL_MAILER" value="array"/>
<server name="MAILBOX_DRIVER" value="array"/>

Or if they want to log the test emails:

<server name="MAIL_MAILER" value="log"/>
<server name="MAILBOX_DRIVER" value="array"/>

Fixes issue https://github.com/beyondcode/laravel-mailbox/issues/72

I sometimes get a memory limit error when running mailbox:cleanup since the command fetches all columns of the table which includes entire emails + raw attachments, this PR optimizes the command to run the delete statement right on the database level.