Why Professional QAs and Software Devs May Choose Mailsac Over Disposable Email

Email deliverability testing, and QA testing web apps with multiple account permissions, are critical aspects of software development and Quality Assurance (QA). Although disposable email websites and gmail addresses are a common choice for this task, they present several significant drawbacks for enterprises. This article will detail the advantages of using dedicated email deliverability platforms like Mailsac instead.

Limitations of Disposable Email

1. Security and Privacy

Disposable email platforms typically make all emails public. These websites are frequently crawled by scammers to acquire sensitive information.

Disposable email services often lack robust security measures, exposing sensitive test data. This lack of security can compromise the integrity of testing and risk breaches of confidential information. They rely on security through obscurity – random email addresses that are hopefully unguessable.

Disposable email providers typically do not have Information Security and Assurance programs, and cannot pass a Vendor Risk Assessment.

2. Business Agreements

The terms of service for disposable email services are often unsuitable for professional development and testing contexts. They can include problematic clauses and offer limited protections for users, which isn’t ideal for businesses. The terms and privacy policies tend to be non-negotiable.

3. B2B Interfaces

Disposable email services often lack capabilities for Business-to-Business (B2B) interfacing. This limitation can hinder the integration of these services into larger, automated testing suites, significantly limiting their usefulness in professional testing scenarios.

4. Uptime and Performance

Disposable email services are often slow and lack reliable uptime. These performance issues can introduce unnecessary delays into the testing process and create uncertainties around the reliability of test results. If an email was delayed, it can be hard to know if it was on your end, or theirs.

Advantages of Using Mailsac

Mailsac, as a dedicated email deliverability platform, provides a solution to these limitations and offers considerable advantages for professional QAs and software devs.

1. Enhanced Security

Mailsac prioritizes security, providing secure paid private inboxes and whole subdomains for testing.

You can test your application’s email functionality without risking sensitive data being leaked or public, or sold to a data broker.

2. Professional Business Agreements

Mailsac offers business-friendly terms of service, custom terms, P.O.s, multiple users, SSO and other features designed with the needs of professional QAs and software developers in larger companies with legal and security requirements. This provides a more suitable environment for business operations and testing.

3. Integration and functional testing

Mailsac provides powerful REST APIs, webhooks, and web sockets for integrating into CI/CD and workflows. Companies frequently integrate mailsac seamlessly into their automated testing suite. Using a consumer disposable provider often results in unexpectedly failed builds. Using a professional provider gives you comprehensive and efficient testing and enables continuous deployment.

4. Reliable Performance

Mailsac has high uptime and quick API and UI performance, ensuring a smooth and reliable email testing process. We believe performance is a feature.

5. Share test environment account email addresses

When you are testing a web application, you can use email addresses that are private to your Mailsac account to sign up for your app. Then share those inboxes with your teammates. For example, you may be testing a web app with two RBAC roles – administrator and readonly user. Each can have a unique mailsac email address. Your web app sends a sign-in link via email. All team members can access it (using mailsac’s multi-user or SSO feature). And since it’s not disposable email, the sign-in link to your app’s dev environment won’t be public.

While disposable email services may appear convenient, they come with considerable drawbacks for professional QAs and software devs. They can be against company policies because they may leak proprietary business information. Mailsac, with its robust features and focus on business needs, provides a far more effective solution for email deliverability testing.

QA Testing Email Deliverability using Mailsac: An Overview for QA Managers

The importance of Quality Assurance (QA) testing in software development and operations cannot be overstated. It ensures the product or system performs as expected, minimizing the risk of unexpected failures in production environments. A crucial aspect of QA testing involves testing email deliverability. This article will focus on how to use Mailsac, a leading tool in email testing, to execute this task effectively.

What is Mailsac?

Mailsac is a service providing temporary, “for-test-only” email addresses that can be used for testing and development purposes. Mailsac’s uniqueness lies in its capability to accept emails sent to any unique, auto-generated email addresses under its domain, thus eliminating the need for pre-generating email addresses or setting up a dedicated testing email server.

Why Use Mailsac for Email Deliverability Testing?

Email deliverability testing is vital to ensure emails are correctly dispatched from your application and are appropriately received by your users. Mailsac offers the flexibility to test various email formats and content, inspect the received emails, and verify they are correctly formatted and contain the correct data. This helps mitigate common issues such as emails being marked as spam, lost emails, or broken email formats.

How to Perform QA Testing with Mailsac

Let’s delve into the steps to conduct QA testing for email deliverability using Mailsac.

Step 1: Set Up a Mailsac Account

First and foremost, you need to create a Mailsac account. Visit the Mailsac website and follow the sign-up instructions.

Step 2: Send Emails to Mailsac

Next, send emails from your application to any addresses on the mailsac.com domain. Mailsac is designed in such a way that you don’t need to pre-generate the email addresses. Just decide on the address you want to use and send the email. The inbox will be created automatically when an email is received.

You can send the emails from anywhere, too – personal or work addresses, fake senders, CLI tools, software applications – without a separate sending gateway.

Step 3: Check Email Deliverability

After sending the emails, you can verify their delivery in the Mailsac interface. Here, you can view the received emails, check their contents, and confirm they are correctly formatted. Mailsac also enables you to check if attachments are included correctly using the Unified Inbox or API, and whether the links and images in the email are functioning properly.

Advanced Testing with Mailsac API

For more sophisticated or comprehensive testing, Mailsac offers a robust JSON REST API and Web Socket API. This empowers you to automate the process of sending emails, checking their delivery, and verifying their contents. These API calls can be integrated into your automated testing suite, enabling you to conduct in-depth email deliverability tests as a part of your regular testing process.

Wrapping Up

Mailsac presents a powerful and versatile method to test email deliverability as a part of your QA process. It allows you to send emails to any address on its domain, and the inboxes are created automatically when an email is received. By integrating Mailsac into your QA testing, you can significantly enhance the quality and reliability of your email notifications, thus offering a better user experience. Sign up and start receiving email in seconds.

Unveiling Mailsac’s New API Endpoint Feature: Inbox Filter

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:

  1. andSubjectIncludes: Filter messages by text included in the subject line
  2. andFrom: Filter messages by text included in the FROM envelope
  3. 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:

const axios = require('axios');
const assert = require('assert');

describe('Inbox Filter API Endpoint Test', () => {
  it('should return filtered messages', async () => {
    const mailsacApiKey = 'your-api-key-here';
    const endpoint = 'https://mailsac.com/api/inbox-filter';
    const andSubjectIncludes = 'Important';
    const andFrom = '[email protected]';
    const andTo = '[email protected]';

    const response = await axios.get(endpoint, {
      headers: { 'Mailsac-Key': mailsacApiKey },
      params: { andSubjectIncludes, andFrom, andTo },
    });

    assert.strictEqual(response.status, 200);
    assert.strictEqual(Array.isArray(response.data.messages), true);
    response.data.messages.forEach((message) => {
      assert.strictEqual(message.subject.includes(andSubjectIncludes), true);
      assert.strictEqual(message.from[0].address.includes(andFrom), true);
      assert.strictEqual(message.to[0].address.includes(andTo), true);
    });
  });
});

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.

Streamlined Mailsac Updates: Enhancing Email Testing with UI, Performance, and Security Improvements

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 )

The Hidden Costs of Neglecting Email Testing for Your Business

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.

A Guide to Customer Notification Laws: The Importance of Email Compliance

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.

Logout fixes, new charts, running on the software treadmill

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:

and more!

Plus-addressing is supported by all Mailsac inboxes

When you send to any inbox @mailsac.com, if a + plus symbol is included, we remove that symbol and everything after it.

jeff+12345asdf@mailsac.com

will be delivered to

[email protected]

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.

Mailsac is not affected by Log4J CVEs

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.

There is one exception – an instance of the CI server Jenkins which is isolated behind a VPN, and is was never vulnerable according to troubleshooting steps from the Jenkins developers.

Mailsac and Security

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.

A new open source counting and throttling server: say hello to dracula

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 DescriptionCommand characterPut, Count, Errorspacexxhashpre shared key + id + namespace + dataspaceClient Message IDspaceNamespacespaceEntry data
Size1 byte1 byte8 bytes1 byte4 bytesunsigned 32 bit integer (Little Endian)1 byte64 bytes1 byteremaining 1419 bytes
Examplebyte(‘P’), ‘C’, ‘E’byte(‘ ‘)0x1c330fb2d66be179byte(‘ ‘)6 or []byte{6, 0, 0, 0}byte(‘ ‘)“Default” or “anything” up to 64 bytesbyte(‘ ‘)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:

  1. 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).
  2. A hash of the pre-shared secret + message ID + namespace + entry data is set inside the front part of the message.
  3. A handler is registered under the client message ID.
  4. The bytes are sent over UDP to the dracula server.
  5. Client is listening on a response port.
  6. 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.
  7. Server receives packet, decodes it and checks the hash which contains a pre-shared secret.
  8. Server performs the action. There are only two commands – either Put a namespace + entry key, or Count a namespace + entry key.
  9. 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.
  10. 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.

Check out the roadmap of features, currently tracked in the Readme.

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.

Happy counting!