All of our plans now included additional features. These features will help quality assurance teams and individual developers test sending and receiving of email, and easily share non-production email accounts.
To see a complete listing of feature visit see our pricing page.
We are in the process of rolling out these features to our existing customers. Please contact support@team.mailsac.com if you need access to the features ahead of our scheduled roll out.
Devs and Quality Assurance Testers Can Easily Validate Mail Headers
The SMTP header endpoint provides quality assurance testers with the option to view an email message’s SMTP headers in parsed formats that easily integrate with automated testing frameworks.
Problem
Developers and QAs are often asked to validate contents of emails. This can include from address, links, and subject. For many organizations this can be a manual process of checking the email and validating if the test criteria has been met.
Solution
Mailsac’s new message header endpoint provides SMTP headers in 3 formats:
1. JSON object format, grouped by lowercased header key. This format is easily consumed by industry standard tools such as Selenium.
{
"received": [
"from 107.174.234.77 by frontend1-172-31-29-224 via 172.31.42.57 with HTTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon Dec 24 2018 15:29:06 GMT+0000 (Coordinated Universal Time)",
"from 107.174.234.77 by smtp-in2-172-31-42-57 via 172.31.23.10 (proxy) with SMTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon, 24 Dec 2018 15:29:06 UTC",
],
"from": [
"grem@hello.msdc.co"
],
"to": [
"cd@mailsac.com"
],
"subject": [
"invitation to collaborate"
],
"date": [
"Mon, 24 Dec 2018 15:29:06 +0000"
]
}
2. Ordered JSON array format. This formats pre-parses the headers, but maintains the original order, while still handling duplicate headers such as Received.
?format=ordered-json
[
{
"name": "received",
"value": "from 107.174.234.77 by frontend1-172-31-29-224 via 172.31.42.57 with HTTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon Dec 24 2018 15:29:06 GMT+0000 (Coordinated Universal Time)"
},
{
"name": "received",
"value": "from 107.174.234.77 by smtp-in2-172-31-42-57 via 172.31.23.10 (proxy) with SMTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon, 24 Dec 2018 15:29:06 UTC"
},
...
{
"name": "to",
"value": "cd@mailsac.com"
},
]
3. Plaintext original format. This format is useful when you are interested in parsing or inspecting the email headers yourself, and do not wish to download the entire message.
?format=plain
Received: from 107.174.234.77 by frontend1-172-31-29-224 via 172.31.42.57 with HTTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon Dec 24 2018 15:29:06 GMT+0000 (Coordinated Universal Time)
Received: from 107.174.234.77 by smtp-in2-172-31-42-57 via 172.31.23.10 (proxy) with SMTP id 8m7iqeiZKJ3MzwTwUQlU for <cd@mailsac.com>; Mon, 24 Dec 2018 15:29:06 UTC
...
To: cd@mailsac.com
“We are currently using the REST API headers endpoint in support between our own microservices. Our POP3 server fetches headers of message to implement the POP3 TOP command.” — Michael Mayer, Partner Forking Software LLC
Getting Started
The message header endpoint/api/messages/:messageId/headers is available on all Mailsac plans (including our free tier). See our API Specification for more information.
This code example could can be modified to view the headers for the first email message on an inbox calendartrinity@mailsac.com. Make sure to insert your API Key and change the email address to an email address you which is public or reserved by your account.
const superagent = require('superagent') // npm install superagent
const mailsac_api_key = 'YOUR_API_KEY_HERE' // change this!
superagent
.get('https://mailsac.com/api/addresses/calendartrinity@mailsac.com/messages')
.set('Mailsac-Key', mailsac_api_key)
.then((messages) => {
const messageId = messages.body[0]._id
superagent
.get('https://mailsac.com/api/addresses/calendartrinity@mailsac.com/messages/' + messageId + '/headers')
.set('Mailsac-Key', mailsac_api_key)
.then((response) => {
console.log(response.body)
})
})
.catch(err => console.error(err))
/**
{
received: [
'from [ by fireroof via ::1 with HTTP id bo4xdVji_oqEixBO0gGLbvIoe for <calendartrinity@mailsac.com>; Wed, 28 Oct 2020 23:05:29 GMT',
'from [ fireroof with SMTP id bo4xdVji_oqEixBO0gGLbvIoe for <calendartrinity@mailsac.com>; Wed, 28 Oct 2020 16:05:29 PDT'
],
'x-mailsac-inbound-version': [ '' ],
date: [ 'Wed, 28 Oct 2020 16:05:29 -0700' ],
to: [ 'calendartrinity@mailsac.com' ],
from: [ 'bclinton@mailsac.com' ],
subject: [ 'test Wed, 28 Oct 2020 16:05:29 -0700' ],
'message-id': [ '<20201028160528.2893005@fireroof>' ],
'x-mailer': [ 'swaks v20190914.0 jetmore.org/john/code/swaks/' ]
}
**/
Custom domains and Private Addresses have been great for quality assurance teams to conduct end to end automated testing of email. But sometimes interacting with an REST API can be a lot of overhead for non-repeating tasks. API Credentials can now be used to login to the website.
All private addresses and custom domains associated with the primary account will be visible from the website for API users. The permissions for API users are the same as API keys.
Quality assurance teams often share credentials of test accounts for the web application they are testing. These test accounts might to be associated with an email provisioned by their IT department or the QA tester’s personal email. Mailsac private domains allow the test accounts to be created in an an environment all members of the QA team have access to.
This feature allows teams to work together in the Mailsac platform. There is no longer a need to for each person to have their own Mailsac account. A named API Key can be created for each person. That API key can be used to interact with the REST API and the website. As a result, password resets and transaction emails sent to a Mailsac private domain can be accessed by any member of the QA team.
“Internally we have used Mailsac for collaboration. Being able to share a private address or domain allows my team members to see exactly what I am seeing. This feature allows our customers to do the same with their own private domains and addresses” Michael Mayer – Member – Forking Software LLC
We will be rolling this feature out to our Business and Enterprise Plans in the next couple weeks. If you have an immediate need for this feature we can enable it on your account. Contact support@team.mailsac.com to get early access to this feature on you Business or Enterprise Plan.
Our REST APIs and website will require the use of TLSv1.2 on October 24, 2020. TLS 1.2 was published as RFC 5246 in 2008.
All major web browsers (Chrome, Edge, Internet Explorer, Firefox, and Safari) have already disabled TLS 1.0 and TLS 1.1. Most modern programming languages have support for TLS 1.2.
Integrations written in Java 6 and Python 2.6 do not have TLS 1.2 support.
References
Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): https://tools.ietf.org/html/rfc7525
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.
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 for viewing 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 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. The software environments environments don’t map 1:1 with 3rd party services, making even more confusion.
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.
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