Hello, when using the Laravel Framework, the integration you provided overrides the default configuration values which resolves .env file. That is why, we end up entering this information manually.

Instead, can you please provide the .env file values as well/instead of the config file?

Like:

MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME={mail_username}
MAIL_PASSWORD={mail_password}
MAIL_ENCRYPTION=null

It would be great if team members within a paid team could sign in using our organisation's existing single sign on infrastructure.

This would mean when folks leave the organisation, they'd automatically lose access to Mailtrap. Better yet, if we could configure Mailtrap to allow anyone with a specific role access as a team member, this would greatly simplify our ability to manage team members.

All our systems are configured to send to an inbox.
We require the ability to forward all mail regardless of address, subject or content.

Mark as Unread opened email

View forwarded smtp logs

At the moment, it seems like you can only invite company users by the share link. When inviting a team of folks, this means I have to send the link to them all, then check back that they've accepted it before changing that share link to prevent further sign-ups if it's accidentally shared later.

It would be good if you could invite specific email addresses only, rather than anyone who has access to a global share link.

Symfony 4 configuration example would also be nice.

.env example:

###> symfony/swiftmailer-bundle ###
# For Gmail as a transport, use: "gmail://username:password@localhost"
# For a generic SMTP server, use: "smtp://localhost:25?encryption=&auth_mode="
# Delivery is disabled by default via "null://localhost"
MAILER_URL=smtp://81d3957be84923:9e35845b8b3b2f@smtp.mailtrap.io:2525?encryption=tls&auth_mode=login
###< symfony/swiftmailer-bundle ###

Some software doesn't let you specify port...

I need to check case when email ( recipient ) does not exist.
I know you don't check if email address exists in real world, but you could allow to set one or some email address(es) in configuration
and send 'recipient not exist' response with appropriate status code when client/user sends email to that address(es)

The person who starts the account and handles the billing isn't always the one that wants to manage all the users as employees come and go. You need to allow multiple owners (incase owner A get hit by a truck) or at least another layer of security so someone else can manage users on the companies account.

improving search the emails? Starts with is not really good...

A while ago you removed [MAILTRAP FORWARD] from the subject and added a customer email header (x-mailtrap-forwarding) instead. This is causing problems for our Gmail users which had a custom filter for all emails from mailtrap.

While most of the standalone email clients allows to filter on the
new email header (x-mailtrap-forwarding), gmail doesn't allow this.

We would really appreciate the possibility to toggle the [MAILTRAP FORWARD] in the subject or maybe even better; allow users to add their custom prefix to the subject.

Allow users to sign up and access a shared inbox in one step.

Right now, users have to sign up, and then the inbox owner has to share the inbox with them in a separate step.

It will be good to be able to receive bigger emails using mailtrap. Is it possible to increase message limit to, for example, 10MB for paid account?
Or as workaround - allow forwarding of that emails.

SMTP servers forward mail on to BCC recipients while at the same time stripping that field. Because Mailtrap is serving as the SMTP server, it can record the original data in the BCC header.

The default Mailtrap view should continue to hide the BCC header to provide a Client-like view, but the BCC header should be made available in either the RAW view or another view "As Received".

Why aren't different roles defined in your solutions. Currently I see owner and user.
What about administrators etc..

According to https://twitter.com/Mailtrap/status/1034816874188554240 you removed the ability to remove email messages using POP3 protocol.

We rely on this function since we don't only use mailtrap to send emails but also to read emails and test our POP3 client.

Generate a .muttrc file from the "Integrations" menu.