With email capture, Quality Assurance teams testing email delivery can easily see the exact emails customers will receive.
The new Email Capture Service is an SMTP server that accepts all mail regardless of the To and From address. It is similar to Mailsac’s existing disposable mail, with some key differences. The capture service acts like a fake outbound relay, rather than a fake inbound relay.
Messages sent via capture.mailsac.com are available from the Mailsac Website or REST API. This allows Quality Assurance teams to validate that the message was sent and the contents of the message.
Web applications frequently send transactional emails to users. During development and User Acceptance Testing, sending email is disabled in the application – so emails are not accidentally sent to customers or fake test addresses. Sending lots of bounces from a development application is a great way to get your domain blacklisted, greylisted, or onto a spam list.
Send via capture.mailsac.com instead
Web applications can be configured to use the Email Capture Service as their SMTP server. Emails sent by the application can then be viewed by developers and testers.
Customers have been sending test emails to hosted custom domains at Mailsac for years. The email capture services simplifies the process of sending emails to Mailsac by allowing developers to relay through Mailsac without any additional email infrastructure.
Michael Mayer – LLC Member at Forking Software LLC.
Most customers can get started sending through the Email Capture service instantly. Wherever you input SMTP credentials in your application, change to the following:
Customers have sent inquiries to support@mailsac.com requesting to have their accounts deleted. This functionality is now available from Manage Account Details, which is accessible from the Dashboard.
Requesting account deletion expresses your intention to fully remove both your user account and any existing information relevant to your account.
This action cannot be undone, and we will be unable to recover any data.
We’ve listened to your feedback. This week we released new functionality to delete all the messages in an inbox.
Purging an inbox can be accomplished in two ways:
programmatically, via the REST API DELETE /api/addresses/:email/messages route
by clicking the new “Purge Inbox” button
Here’s an example of clicking the Purge Inbox button, instantly recycling over 80 messages:
Why were all the messages not deleted?
Starred messages (savedBy in the REST API) will not be purged.
We recommend un-starring those messages first, then purging the inbox, if you want to completely clear the inbox. Or, use the existing single-message deletion feature will allow you to delete a starred message. There is a button for deleting messages on the inbox page. The REST API route to delete a single message is DELETE /api/addresses/:email/messages/:messageId.
The GET Method on the REST API endpoint /api/validations/addresses/:addressToValidate has been updated to return a JSON object. Previously, this endpoint was returning an array. The POST Method response remains unchanged.
Email validation via the Mailsac Website is still available to all registered customers. An email address can be checked for valid format and if it is associated with any known disposable email services.
When building software-as-a-service, many different pre-production environments are often in play. Developers, product managers, and QA engineers work together to test software in various environments, but there’s often confusion around which user accounts can be used in which environments. Often, software environments do not map 1:1 to 3rd party services, making even more confusion.
Mailsac provides disposable email accounts that can be created within a private custom with little or no overhead to keep testing environments separate and prevent user collisions with third party providers.
Common Environment Setup Example
A QA team may have a test environment called “UAT” and developers have a different test environment called “Staging.”
The infrastructure might map to URLs with different subdomains like:
uat.example.com – QA team
staging.example.com – Developers
app.example.com – Production (customers)
where each subdomain has a completely separate database with a users table.
However, our sample app uses a 3rd identity provider (such as Amazon Cognito, Forgerock, Auth0, etc). The identity provider only has two environments:
test-identity.example.com – All non-production usage (UAT, Staging)
identity.example.com – Production (customers)
Furthermore, our app uses Stripe, which also has only two environments:
Stripe Test Mode – All non-production usage (UAT, Staging)
Production Mode – Production (customers)
One can imagine a users database table with the following properties:
users.id int, primary
users.email text, unique
users.identity_provider_id text, unique, corresponds to the Identity Provider
users.stripe_customer_id text, unique, corresponds to the Stripe Customer ID
Such a setup is common. Problems begin brewing when using the same email address in multiple environments.
Password issues with shared email addresses
A QA person wants to test their app. They sign up with alice@example.com in UAT. alice@example.com was created by a friendly sysadmin at their company. It is a real email inbox. The company has to pay a few bucks per month for the inbox, and it isn’t easily accessible by anybody else. Where’s that password again? Oh you asked Dave from IT to reset the email password? Oh you mean the UAT app password was changed only? The new password should be in a spreadsheet..oops somebody reset it and didn’t update the password? It doesn’t look like I have access to the alice@example.com inbox. Wait a second..the Dev team is also using it?
Identity Provider Clash, Stripe duplicate
UAT person uses alice@example.com and creates the user account with the Identity Provider, linking the identity_provider_id to their user in UAT. They also link the Stripe customer.
id
email
identity_provider_id
stripe_id
22
alice@example.com
idp_q7e4
cus_t6n
UAT users table
But then a developer in Staging attempts to perform the action but gets blocked by the identity provider, and duplicates the customer in Stripe with the same email address, making the tracking of financial transactions overly complicated. UAT and Stating also end up with a different user id.
id
email
identity_provider_id
stripe_id
19
alice@example.com
NULL (failed)
cus_yb1
Staging users table
It is possible the same password is used for alice@example.com with the identity provider, and both UAT and Development are able to login. But the identity_provider_id will need to be manually set to match both environments, and it will never match the users.id column.
Let’s add one more common layer: role based permissions.
Developer 1 sets up alice@example.com to
These are just a few of the problems with using a limited number of shared credentials for testing software.
Using Mailsac for Test User Accounts
A software team and QA team can share the Mailsac Business account to add nearly unlimited email addresses, and apply special features to up to 50 private address across 5 custom domains (and more via addons). Mailsac allows any custom subdomain of *.msdc.co, it may not even be necessary to involve an IT department to configure DNS.
QA team sets up example-uat.msdc.co.
The QA team will create 10 private addresses with specific purposes such as a user they will configure in uat.example.com with elevated admin permissions:
Next the Dev team, can do something similar but with a different custom domain, and different private email addresses.
Setting up a bunch of private addresses is simple and included with any paid plan. It can help prevent test credential collisions.
Random Inboxes and API Keys
It is not even necessary to setup private addresses, as done above, to receive email.
With a custom domain, any Developer or QA person can send email to any address in the domain without needing to create it first. Then they can check the mail with a personal API key.
To make a random address, generate a random string:
openssl rand -hex 4 yields de692e19 (for example)
and prefix it to your custom domain:
de692e19@dev-env-sample.msdc.co
Assume Greg’s API key is: wv6OCCXE4svjxuv7sOsCBA (note: never share these!)
He can easily check the inbox using the following URL scheme: https://mailsac.com/inbox/de692e19@dev-env-sample.msdc.co?_mailsacKey=wv6OCCXE4svjxuv7sOsCBA
Beginning 2:36 AM US Pacific time, Mailsac internal monitoring indicated slowness due to an abnormally large amount of spam coming from China. By approximately 6:30 AM we identified all root causes and believe the issue is resolved.
Our service employs several methods of blocking, shaping, and throttling egregious traffic from unpaid users. This particular attack worked around these automatic mitigation efforts, in part because the attackers opened thousands of sockets and left them open a long time, exploiting a loophole in our SMTP inbound receiver code.
Here is a graph of our inbound message rate showing the attack compared to baseline.
Last year, we soft-launched a new forwarding feature on private addresses. You may have noticed – underneath the “Forwarding” section, there is now a Forward to Slack option. (Manage Addresses > Settings > Forwarding)
With only a little clicking, you can have inbound emails dumped into a Slack channel. It’s easy – no coding, and no servers, are necessary.
We built this feature because we use Slack internally, and had a custom webhook translator to send certain emails to a channel. After a little copy and paste, code massaging, and unit testing, we were able to get the feature into the platform.
Email → Slack Options
After inserting a valid Slack Webhook URL, we give you the option to enable the To and From address to display in the Slack message (Include To and From in the slack message checkbox). Here’s the difference:
Disabled TO and FROM in Slack Message
Enabled FROM and TO in Slack Message from Email
Enabling TO and FROM is useful for support requests, shared email inboxes, or when you might have multiple inboxes pointed at the same channel.
Disabling TO and FROM is useful for receiving alerts or notifications from the same service. For example, if you send a notification about a new purchase on your website to a Slack channel, and it always comes from the same service email address, you don’t need it to take up space in the Slack message.
Email Images and Attachments to Slack
The email-to-Slack forwarding feature supports file attachments, including images. Images will be displayed inline.
We recommend archiving attachments outside Slack at this time. Attachments are subject to recycling. Also, attachments must be made public in order for Slack to accept the messages. So do not send any PII or sensitive information. This is another reason why we chose to recycle attachments.
The same Mailsac message size limits apply for Slack. If you are interested in bumping up the attachment sizes, make a feature request or contact support and include your account ID.
Debugging Forwarding
The mail activity log will show forwards, and reports failures posting to Slack with error messages. (Dashboard / Usage / Recent Mail Activity Log)
Debug logging on email webhooks to Slack. Response data is redacted. On errors, you will see Slack’s response.
Feedback
As always, please post feedback and questions to the Mailsac Discussion Forum. We think the feature is useful as-is, but we are open to making changes to better meet our customers needs.
A new feature allows viewing recent activity across the account – inbound email messages, web socket publishing, webhooks, and Slack webhook posts.
From the dashboard, go to Usage & Analytics, then Recent Mail Activity Log.
The debug log shows all inbound, outbound, and publishing actions by 15 minute intervals. Business Plans and higher get access to at least 6 months of history. Free and Indie Plans can see the most recent 15 minutes.
We intend to continue improving this feature by including extended debugging information, response codes, bounces, and other useful information. Please share your experiences with us, and report any problems.
This is a good time to mention you can view have inbound and outbound message counts and bandwidth, up to 30 days currently visible.
This tool helps make it easier to understand how many messages your app is sending – whether it is a custom email app built atop Mailsac, or QA integration testing team.
When releasing a private address, there is now an option to “empty the inbox” – deleting all messages associated with the private address. You can find the option by clicking the settings button when managing your private addresses.
The API endpoint DELETE /api/addresses/:email now supports the query string deleteAddressMessages. When deleteAddressMessages=true is passed, all messages associated with the inbox will be deleted.
Please note that all messages are deleted, including starred/saved messages. It is immediate and irreversible.
The Mailsac dashboard has a brand new look. Our commonly used services are easier discover. You may find out about features you never new existed.
Setting up disposable or test email for a domain has never been easier. With the Mailsac Zero-Setup-Subdomain, choose you subdomain name and start receiving emails within minutes.
We do our best to build simple, indispensable APIs and tools for Quality Assurance teams. End to end testing of emails sent by web applications is easy with Mailsac. API Keys are included with all Mailsac accounts, including our free tier with generous API call limits.
Increase your privacy by using the Mailsac’s free disposable email service. Send to virtually any @mailsac.com address and view the email without ever signing in. To see all messages in an inbox and to view images you will need to sign up for a free account. With the free account you can star messages you need to keep and make them hidden to other users. If you find yourself needing extra email addresses that nobody else can see. They are available as an addon.
