Investigating reports of slowness this morning beginning around 4:45am US Pacific time.
The issue has been mitigated resolved around 5:15am US pacific time.
A slow, locking query was identified to be in a critical path. It has been adjusted.
Investigating reports of slowness this morning beginning around 4:45am US Pacific time.
The issue has been mitigated resolved around 5:15am US pacific time.
A slow, locking query was identified to be in a critical path. It has been adjusted.
Are you tired of spending countless hours manually testing email delivery in your company? Do you want a reliable SaaS developer tool that can simplify and automate the process? Look no further than Mailsac.com!
Mailsac.com offers an easy-to-use platform for testing email delivery. With Mailsac, you can test your email sending capabilities, simulate incoming email messages, and check the delivery status of your outgoing messages. Whether you’re a developer, tester, or IT professional, Mailsac.com is the perfect tool to streamline your email testing process.
But why should you choose Mailsac.com over other email testing tools? Here are just a few reasons:
But don’t just take our word for it – here’s what some of our satisfied customers have to say:
“I’ve been using Mailsac.com for my email testing needs and I couldn’t be happier. It’s saved me so much time and effort, and the features are incredibly powerful.” – John P., Developer
“Mailsac.com has been an essential tool for our QA team. It’s helped us catch bugs and issues before they can cause any real problems, and the integration was a breeze. Support is responsive, often within an hour.” – Sarah M., QA Manager
So why wait? Sign up for a free Mailsac.com API & testing account today and start testing your email delivery with ease. With our reliable platform and powerful features, you can rest assured that your emails will always be delivered as intended.
At 7:40PM US West Coast Pacific time, we started a large planned database migration. Infrequent downtime is expected.
Stop using mailing lists, shared inboxes, and GMail aliases for email testing. Things get messy fast, and often they aren’t easily shared with a team.
Use Mailsac for test email accounts. Make private or shared email addresses for each environment and test scenario. It’s disposable mail designed for QA.
Mailsac helps software teams organize their test accounts in 2 steps.
1. Setup a custom domain.
Pick any available subdomain of *.msdc.co
.
Or, add a few DNS entries and use your existing domain, like test.example.com
.
2. Start getting email immediately. You are ready to start testing! No need to create any inboxes.
Send an email to any address at your Mailsac domain.
Then check the mail.
If you want, an email inbox can be saved for reuse.
Add a comment so you and your team can see what that address is used for (“test account with admin role for dev and uat environments”).
Enable a catch-all under the custom domain’s settings. It’s useful for one-off signup tests. A Catch-All inbox receives all email sent to a specific domain (for non-reserved addresses).
Now, any email address under your mailsac domain will be routed to the catch-all.
Public inboxes for any @mailsac.com email address are free.
Custom domain plans start at $12 per month, or $10 per month when paid yearly.
We serve small dev shops, financial institutions, and government project teams with the same friendly support.
Some users experienced issues logging into the service, and signing up, yesterday and this morning (US Pacific). There was a configuration issue with cookies which has been resolved. Please continue to report any new issues with login or signup.
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:
DELETE /api/addresses/:email/messages
routeHere’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
.
When building software-as-a-service, several pre-production environments are often in play.
Developers, product managers, and QA engineers work together to test software in the various environments.
But there’s confusion around which user accounts can be used in which environments. Which accounts have the right permissions for testing. And your test environments environments don’t map 1:1 with 3rd party services. It’s confusing to know if you tested the right thing.
Mailsac lets you create disposable email accounts within a private custom. Temp email addresses to share with the team. This results in less effort keeping testing environment accounts separate. It prevents user collisions with third party providers.
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:
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:
Furthermore, our app uses Stripe, which also has only two environments:
One can imagine a users
database table with the following properties:
users.id
int, primaryusers.email
text, uniqueusers.identity_provider_id
text, unique, corresponds to the Identity Providerusers.stripe_customer_id
text, unique, corresponds to the Stripe Customer IDSuch a setup is common. Problems begin brewing when using the same email address in multiple environments.
A QA person wants to test their app. They sign up with [email protected]
in UAT. [email protected]
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 [email protected]
inbox. Wait a second..the Dev team is also using it?
UAT person uses [email protected]
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 | identity_provider_id | stripe_id | ||
22 | [email protected] | idp_q7e4 | cus_t6n |
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 | identity_provider_id | stripe_id | ||
19 | [email protected] | NULL (failed) | cus_yb1 |
It is possible the same password is used for [email protected] 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 [email protected] to
These are just a few of the problems with using a limited number of shared credentials for testing software.
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.
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.
The Business Plan allows creating multiple custom API keys:
To make a random address, generate a random string:openssl rand -hex 4
yields de692e19
(for example)
and prefix it to your custom domain:[email protected]
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/[email protected]?_mailsacKey=wv6OCCXE4svjxuv7sOsCBA
Or get messages as JSON:
curl --header 'Mailsac-Key: wv6OCCXE4svjxuv7sOsCBA' https://mailsac.com/api/[email protected]/messages
which returns an array of messages including any links to be clicked.
[{ "_id": "m77238f-0", "inbox": "[email protected]", "subject": "Confirm your account or something", //......... "links": ["https://app.example.com/confirm-account/iOZifOYkLX5qFfEo"] }]
We hope this guide provides an overview of how software teams are using Mailsac to simplify testing.
Thousands of enterprises and software project teams use Mailsac to test their environments and manage “known good” test accounts for their SaaS.
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.
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:
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.
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.
The mail activity log will show forwards, and reports failures posting to Slack with error messages. (Dashboard / Usage / Recent Mail Activity Log)
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.
Read more about the email-to-Slack webhook on our docs site.
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.