A look at filtering email messages with the Mailsac API
Mailsac has rolled out a new API endpoint feature, dubbed “inbox filter.”
It limits email messages using the to, from, and subject fields. Say goodbye to the conventional OR logic of /api/inbox-search and embrace the power of logical AND.
The Inbox Filter Endpoint: Technical Breakdown
The /api/inbox-filter API endpoint accepts the following optional query parameters:
andSubjectIncludes: Filter messages by text included in the subject line
andFrom: Filter messages by text included in the FROM envelope
andTo: Filter messages by text included in the TO envelope
This endpoint delivers results only when at least one query condition is specified, otherwise, expect a 400 error. The response is capped at 100 results, so adjust your query or prune your account accordingly.
JavaScript Unit Test with Mocha and Axios
To illustrate the usage of the /inbox-filter API endpoint, here’s a JavaScript unit test using Mocha and Axios:
Looking for a robust email testing solution that can simplify your workflow and improve efficiency? Look no further, friends. Mailsac offers powerful features like this new inbox filter API endpoint and many more, tailored to meet the needs of developers, testers, and businesses alike. Discover the benefits of Mailsac today and elevate your email management game. Try Mailsac for free or learn more about our plans and join our growing community of satisfied users at forum.mailsac.com.
Get ready for some boring news. At Mailsac, we release a steady stream of updates – week by week, all year long – with no fanfare. We avoid breaking changes wherever possible. Most of our customers have Mailsac integrated deeply into their CI/CD and QA processes. Breaking your build is not cool.
Here’s a recap of improvements we made over the past few months:
Updated UI interfaces for managing things like API keys, email addresses, and more. We’re modernizing the main website for security and ease-of-use. Stay tuned for a lot more of this.
Additional “Copy text” buttons and cross-browser compatibility improvements.
POP3 server fixes to some edge cases around Windows line endings.
Over 50 security updates to dependencies which are (hopefully) completely transparent to you.
Performance and security upgrades to our underlying servers.
Over time, SaaS services add too many features, getting clunky and slow user interfaces. At Mailsac we’re not beholden to venture capital or shareholders. Customers have our full attention. You pay us for dev and QA tools to help test email. Thus we prioritize speed and singleness of purpose to deliver you those tools. We want to be extremely helpful, yet stay out of your way.
If you’ve ever got issue with Mailsac, paying customers can contact us at [email protected] A human being will reply pretty quickly, getting you unblocked. (For non-paying users, please ask for help at https://forum.mailsac.com )
As a business manager in a software company, you understand the importance of effective communication with your customers. Email remains a critical channel for connecting with your audience, but many organizations overlook the importance of thoroughly testing their email sending capabilities. Failing to test your outbound email systems can lead to embarrassing mistakes, decreased customer satisfaction, and even regulatory consequences in certain industries. In this blog post, we’ll explore the downsides of neglecting email testing and explain why it should be a priority for your business.
Sending Duplicate or Incorrect Emails
One of the most common issues businesses face when not testing their email sending capabilities is accidentally sending duplicate or incorrect emails. This can happen due to software bugs, incorrect configuration, or simple human error. When customers receive multiple copies of the same email or emails containing inaccurate information, it can create confusion, erode trust, and damage your brand reputation. By investing in proper email testing, you can catch these errors before they reach your customers.
Personalization Mistakes
Email personalization is essential for connecting with customers on a deeper level. However, without proper testing, you may encounter issues like incorrect name insertion or the use of outdated customer data. These mistakes can make your emails appear unprofessional and impersonal, undermining your efforts to build strong relationships with your customers. Email testing can help ensure your personalization efforts are successful and your customers feel valued.
Missing Critical Notifications
When your email sending capabilities are not tested thoroughly, there’s a risk of failing to send important notifications to customers. This can include transaction confirmations, account updates, or even password reset emails. Delayed or missing notifications can lead to customer frustration, increased support requests, and potential security issues. Implementing a comprehensive email testing strategy can help ensure your customers receive timely and accurate notifications.
Deliverability Issues
Email deliverability is crucial for ensuring your messages reach your customers’ inboxes. If you don’t test your email sending capabilities, you may encounter issues like high bounce rates, being marked as spam, or being blocked by email service providers. These problems can severely impact your email marketing campaigns and customer communication efforts. Proper email testing can help you identify deliverability issues and address them before they harm your business.
Regulatory Consequences
In certain industries, companies are required to send timely and accurate notifications to customers, such as financial services or healthcare. Failing to meet these requirements due to untested email systems can result in regulatory consequences, including fines or legal actions. By prioritizing email testing, you can ensure compliance with industry-specific regulations and avoid potential penalties.
Conclusion
As a business manager, it’s essential to recognize the importance of thoroughly testing your email sending capabilities. Neglecting this critical aspect of your communication strategy can lead to various issues, including duplicate emails, personalization mistakes, missed notifications, deliverability problems, and regulatory consequences. By investing in proper email testing, you can ensure your messages are accurate, professional, and effective in reaching your customers. This will ultimately contribute to increased customer satisfaction and a stronger brand reputation.
Email has become a crucial communication channel for companies to interact with their customers. While this powerful tool offers numerous benefits, it also comes with certain responsibilities. Various laws and regulations govern how businesses must notify their customers about important information. In this blog post, we will explore some of the most common customer notification laws and discuss the role of email in ensuring compliance.
This article is informational. It cannot substitute for advice from a lawyer.
CAN-SPAM Act
The Controlling the Assault of Non-Solicited Pornography and Marketing (CAN-SPAM) Act is a US federal law that regulates commercial emails. While its primary focus is on marketing and promotional messages, the Act also has implications for transactional and relationship emails. Key requirements include: a. Providing a clear and conspicuous opt-out mechanism for recipients. b. Including the sender’s physical postal address in the email. c. Accurately representing the sender’s identity and email subject line.
By adhering to the CAN-SPAM Act, businesses can avoid potential fines and ensure their emails remain compliant with the law.
General Data Protection Regulation (GDPR)
The GDPR is a European Union regulation that governs data privacy and protection for EU citizens. It requires companies to obtain explicit consent from users before sending marketing emails. Additionally, the GDPR mandates that businesses must notify customers within 72 hours of becoming aware of a data breach. Failure to comply with GDPR requirements can result in significant fines.
California Consumer Privacy Act (CCPA)
The CCPA is a California state law that grants residents specific rights regarding their personal information. Under the CCPA, businesses must inform customers about their data collection practices and allow them to opt-out of the sale of their personal information. Email is an effective method for providing these notifications and ensuring compliance with the CCPA.
Health Insurance Portability and Accountability Act (HIPAA)
HIPAA is a US federal law that governs the privacy and security of protected health information (PHI). Healthcare providers, health plans, and other covered entities are required to notify individuals via email or written communication in the event of a breach of their PHI. The notification must be sent within 60 days of discovering the breach, and failure to comply with HIPAA regulations can result in hefty fines.
Financial Industry Regulations
Various financial regulations, such as the Gramm-Leach-Bliley Act (GLBA) and the Fair Credit Reporting Act (FCRA), require companies to notify customers about specific events or changes to their accounts. Examples include changes to account terms, privacy policies, or suspicious account activity. Email serves as a fast and efficient means of delivering these required notifications.
Conclusion
As a business, understanding and complying with customer notification laws is essential to protect your customers’ privacy and your company’s reputation. By leveraging email as a communication channel, you can efficiently and effectively meet the requirements of various regulations. However, it is crucial to remain up-to-date with these laws and ensure that your email practices align with the latest requirements. By doing so, you can foster trust with your customers and avoid potential legal consequences.
Today’s release of Mailsac’s frontend services includes many fixes.
We tend to release weekly with no downtime and no fanfare. Occasionally we’ll post updates here.
fix: infrequent crash on logout
Most notable is a fix to a UI crash when logging out. In certain situations, you may have seen an error message, even though the logout was successful.
Prettier and more usable charts
We heard your feedback. Usage charts have been aging. Sometimes the styling makes the charts hard to read.
Some additional PostgreSQL optimizations are coming soon. We’ll continue reducing the load time on charts. Thanks for the patience!
Dependency upgrades
For better or worse, modern software stacks have huge numbers of dependencies. Staying ahead of security issues is a daily effort.
At Mailsac we use security scans, Dependabot, and npm audit to stay on top of upgrades. Hundreds of automated tests run to give us confidence that minor and patch semver updates don’t introduce breaking changes.
We subscribe to security mailing lists for our software, such as:
Many email services including Gmail, iCloud and Fastmail support stripping the + plus symbol and everything after it in the local-part of the address (everything before the @ symbol).
Plus-addressing has long been a useful feature to segment user accounts across services. At Mailsac we offer a variety of disposable email and forwarding utilities that are designed for software QA engineers and developers. Things like forwarding all messages in a domain to a single address, or automatically routing email to webhooks or slack, are really easy – may not even require DNS setup.
Tech news has recently been full of CVEs related to a popular JVM logging library named Log4J.
Mailsac services do rely on JVM languages, including Java. This extends through the entire stack, custom apps, self-hosted open source software, internal and external, infrastructure, proxies, and scripts.
The Mailsac Team is small yet mighty, with decades of experience taking security seriously. We follow best practices for infrastructure-as-code, patching, testing, network isolation, backups, restoration, and principle of least access access. Large enterprises including banks and government agencies trust Mailsac for disposable email testing. We provide exceptionally fast and predictable REST and Web Socket APIs with an excellent uptime record.
Mailsac has support for multiple users under the same account, so you can keep disposable email testing private within your company.
It’s free to test email immediately – no payment details required. You can send email to any address @mailsac.com and confirm delivery in seconds without even logging in. Start now at mailsac.com.
dracula is a high performance, low latency, low resource counting server with auto-expiration.
The Mailsac engineering team recently open sourced our internal throttling service, dracula, under an open source license. Check it out on Github. In the repo we prebuild server and CLI binaries for mac and linux, and provide a client library for Go.
Dracula has performed extremely well in AWS on ARM64 in production for us. It handles thousands of requests per second without noticeable CPU spikes, while maintaining low memory.
In this blog post we’re going to give an overview of why it was necessary, explain how it works, and describe dracula’s limitations.
Why we made it
For the past few years Mailsac tracked throttling in a PostgreSQL unlogged table. By using an unlogged table we didn’t have to worry about lots of disk writes, nor the safety provided by having the write-ahead-log. Throttling records are only kept for a few minutes. We figured if Postgres was rebooting, losing throttling records from the past minutes would be the least of our worries.
In the months leading up to replacing this unlogged table with dracula we began having performance bottlenecks. Mailsac is experiencing fast growth in the past few years. Heavy sustained inbound mail was resulting in big CPU time while Postgres vacuumed the throttling tables. The throttling table started eating too many CPU credits in AWS RDS – credits the we needed for more important stuff like processing emails.
We needed a better throttling solution. One that could independently protect inbound mail processing and REST API services. Postgres was also the primary data store for parsed emails. The Postgres-based solution was a multi-tiered approach to throttling – especially against bad actors – and helped our website and REST API snappy, even when receiving a lot of mail from questionable sources. The throttling layer also caches customer data so we can filter out the paying users from unknown users. Separating this layer from the primary data store would help them scale independently.
Can Redis do it?
So it was time to add a dedicated throttle cache. We reached for Redis, the beloved data structure server.
We were surprised to find our use case – counting quickly-expiring entries – is not something Redis does very well.
Redis can count items in a hash or list. Redis can return keys matching a pattern. Redis can expire keys. But it can’t expire list or hash item entries. And Redis can’t count the number of keys matching a pattern – it can only return those keys which you count yourself.
What we needed Redis to do was count items matching a pattern while also automatically expiring old entries. Since Redis couldn’t do this combination of things, we looked elsewhere.
Other utility services seemed too heavy and full-of-features for our needs. We could have stood up a separate Postgres instance, used MongoDB, Elasticache, or Prometheus. The team has experience running all these services. But the team is also aware that the more features and knobs a service has, the more context is needed to debug it – the more expertise to understand its nuances, the more risk you’ll actually use additional features, and the more risk you’ll be slow responding to issues under heavy load.
All we wanted to do was put some values in a store, have them expired automatically, and frequently count them. We’d need application level logic to do at least some of this, so we made a service for it – dracula. Please check it out and give it a try!
How it works under the hood
Dracula is a server where you can put entries, count the entries, and have the entries automatically expire.
The dracula packet layout is as follows. See protocol.go for the implementation.
Section Description
Command characterPut, Count, Error
space
xxhashpre shared key + id + namespace + data
space
Client Message ID
space
Namespace
space
Entry data
Size
1 byte
1 byte
8 bytes
1 byte
4 bytesunsigned 32 bit integer (Little Endian)
1 byte
64 bytes
1 byte
remaining 1419 bytes
Example
byte(‘P’), ‘C’, ‘E’
byte(‘ ‘)
0x1c330fb2d66be179
byte(‘ ‘)
6 or []byte{6, 0, 0, 0}
byte(‘ ‘)
“Default” or “anything” up to 64 bytes
byte(‘ ‘)
192.169.0.1, or any string up to end of packet
500 byte dracula packet byte order
Here’s roughly how the dracula client-server model works:
The client constructs a 1500 byte packet containing a client-message ID, the namespace, and the value they want to store in the namespace (to be counted later).
A hash of the pre-shared secret + message ID + namespace + entry data is set inside the front part of the message.
A handler is registered under the client message ID.
The bytes are sent over UDP to the dracula server.
Client is listening on a response port.
If no response is received before the message times out, a timeout error is returned and the handler is destroyed. If the response comes after the timeout, it’s ignored.
Server receives packet, decodes it and checks the hash which contains a pre-shared secret.
Server performs the action. There are only two commands – either Put a namespace + entry key, or Count a namespace + entry key.
Server responds to the client using the same command (Put or Count). The entry data is replaced with a 32 bit unsigned integer in the case of a Count command. The hash is computed similarly to before.
Client receives the packed, decodes it and confirms the response hash.
Data structures
Dracula uses a few data structures for storing data.
Namespaces are stored in a hashmap provided by github.com/emirpasic/gods, and we use a simple mutex to sync multithreaded access. Entries in each namespace are stored in wrapped AVL tree from the same repo, which we added garbage collection and thread safety. Each node of the AVL tree has an array of sorted dates.
Here’s another view:
dracula server
Namespaces (hashmap)
Entries (avltree)
sorted dates (go slice / dynamic array of int64)
Server configuration
When using dracula, the client has a different receiving port than the server. By default the dracula server uses port 3509. The server will write responses back to the same UDP port it received messages from on the client.
Messages are stored in a “namespace” which is pretty much just a container for stored values. The namespace is like a top-level key in Redis. The CLI has a default namespace if you don’t provide one. The go client requires choosing a namespace.
Namespaces and entries in namespaces are exact – dracula does not offer any matching on namespaces.
At Mailsac, we use uses the namespaces to separate messages on a per-customer basis, and to separate free traffic. Namespaces are intentionally generic. You could just use one namespace if you like, but performance under load improves if entries are bucketed into namespaces.
Production Performance
Dracula is fast and uses minimal resources by today’s standards.
While we develop it on Intel, and in production we run dracula on Arm64 architecture under Amazon Linux for a significant savings.
In its first months of use, dracula did not spike above 1% CPU usage and 19 MB of RAM, even when handling single-digit-thousands of requests simultaneously.
Tradeoffs
By focusing on a small subset of needs, we designed a service with sharp edges. Some of these may be unexpected features so we want to enumerate what we know.
It only counts
It’s called dracula in an allusion to Count Dracula. There’s no way to list namespaces, keys, nor return stored values. Entries in a namespace can be counted, and the number of namespaces can be counted. That’s it! If we provided features like listing keys or namespace, we would have needed to change the name to List Dracula.
No persistence
Dracula is designed for short-lived ephemeral data. If dracula restarts, nothing is currently saved. This may considered for the future, though. Storing metrics or session data in dracula is an interesting idea. On the other hand, we see no need to reinvent Redis or Prometheus.
Small messages
An entire dracula protocol message is 1500 bytes. If that sounds familiar, it’s because 1500 bytes is the normal maximum-transmission-unit for UDP. Namespaces are capped at 64 bytes and values can be up to 1419. After that they’re cut off.
Same expiry
All namespaces and entries in the entire server have the same expire time (in seconds). It shouldn’t be too difficult to run multiple draculas on other ports f you have different expiry needs.
HA
The approach to high-availability assumes short-lived expiry of entries. A pool of dracula servers can replicate to one another, and dracula clients track health of pool members, automatically handling failover. Any client can read from any server, but in the case of network partitioning, consistency won’t be perfect.
Retries
Messages that fail or timeout are not retried by the dracula client right now. There’s nothing stopping the application level from handling this. It may be added as an option later.
Garbage
While we have not yet experienced issues with dracula’s garbage collection, it’s worth noting that it exists. A subset of entries are crawled and expired on a schedule. On “count” commands, old entries are expired. The entire store is typically not locked, but it’s likely you would see a little slowdown when counting entires in very large namespaces, or when there are a lot of old entires to cleanup, while GC is running. In our testing it’s on the order of single digit miliseconds, but this can be expected to grow linearly with size.
Unknown scale
We’re working with low-tens-of-thousands entries per namespace, maximum. Above that, we’re unsure how it will perform.
Language support
Upon release, dracula has a reference client implementation in Golang. Node.js support is on our radar, but not finished. Please open an issue in the dracula repo to request support for a specific language. We’d be thrilled to receive links to community written drivers as well.
What’s next?
Hopefully you enjoyed learning a little bit about dracula and are ready to give it a try. Head over to Github https://github.com/mailsac/dracula where added examples of using the server, client library, and CLI.
Finally, Mailsac would love your feedback. Open a Github issue or head to forum.mailsac.com. If you’d like to see additional library languages supported, let us know.
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:
Easy integration: Mailsac.com offers easy integration with popular programming languages and frameworks, making it a seamless addition to your workflow. We craft code samples in popular languages for all API endpoints.
Powerful features: With features like email address generation, message debug tools, unified testing inbox, and an super-well-documented API, Mailsac.com offers everything you need to thoroughly test your email delivery.
Affordable pricing: Mailsac.com offers flexible pricing plans to suit the needs of any business, from small startups to large enterprises. Mailsac is familiar with passing IT vendor risk assessments.
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.