Recently, based on my own practical needs, I created a Chrome extension project. The core goal of this project is to transform a process that originally relied on manual operations, frequent page switching, and waiting for verification codes into a visual, manageable, and reusable automation tool.
Unlike solutions that only focus on advancing a single process, I was more concerned with these issues: whether email sources are centrally managed, whether waiting for verification codes is smooth enough, whether the status is traceable after a process run, and whether the next round of tasks can automatically avoid already processed email addresses.
It is precisely because of this that the project ultimately focused on "visual email pool management and closed-loop label management for process results."
🔗Project Address:
After this project was released, GitHub gained 260+ Stars within 1 day. For me, this result is important because it shows that this tool solves a real problem, and it also indicates that this approach has been validated and received feedback from many users.
Why I Created This Project
Initially, when using existing solutions, I encountered two main problems.
The first problem was unstable email receiving experience.
Some email sources (like duck email) were slow to receive messages, had long single wait times, and had limited daily availability, often causing the process to get stuck at the verification code stage. After verification, it was found that emails like hotmail receive verification codes much faster, so I modified the acceptable verification code email sources.
The second problem was lack of status management after a process run.
When a process fails midway, or after many rounds have been run, it's easy to lose track of which email addresses have been completed, which haven't been processed, and which need retrying. This directly leads to duplicate consumption, manual backtracking, and management chaos.
So I finally decided to create my own version, focusing on "modifying it to support multiple email sources, visual email pool management, and closed-loop labeling of process results."
What Problems Does This Project Solve
Simply put, what this extension does is:
1️⃣ Pull available email addresses from the email pool
2️⃣ Automatically poll for verification code emails and extract the results
3️⃣ Advance the authentication process on the page
4️⃣ Automatically apply labels after the process is completed to avoid reuse
To achieve this, I integrated the mature multi-email management tool Outlook Email, unifying originally scattered email sources into a visual interface. Currently supported email sources include: Outlook, Gmail, QQ, 163, 126, Yahoo, Alibaba Mail, custom IMAP, and it is also compatible with various temporary email provider capabilities, making it easy to switch between different sources based on actual scenarios.
After the entire process is completed, the plugin automatically applies labels to the corresponding email addresses. The next time it runs, it will prioritize processing email addresses without labels.
This way, on one hand, email acquisition, verification code waiting, and account switching are integrated into the same interface, making the usage process smoother. On the other hand, through label management like "Registered," unprocessed email addresses can be quickly filtered, achieving status closure and reducing omissions and duplicate operations.
Usage Tutorial
Install this extension
Open the github repository, clone or download the zip file locally
Open
chrome://extensions/Enable "Developer mode"
Click "Load unpacked extension"
Select the current directory
hotmail-register-extension
Deploy and start the Outlook Email service
Use the repository: assast/outlookEmail, and deploy successfully according to the readme instructions
Ensure you can access its backend page and API through a browser (** You must open the frontend in a browser at least once first! Otherwise, you cannot apply labels to email addresses**)
Obtain the Outlook Email API key and API URL
The API URL is the Outlook Email frontend address
The API key is generated by opening the Outlook Email frontend, clicking the settings icon in the top right corner, finding "External API," and clicking generate
Configure the plugin
- Fill in the API URL, API key, CPA URL, management key, and default login password in the plugin sidebar
Start running
Q&A
Where do hotmail email addresses come from?
You can purchase them directly; generally, they cost 2-6 cents each, and buying 100 won't exceed 10 yuan, which is sufficient for personal use.
If you have hotmail email addresses, you can refer to the method shared by a friend: hotmail plugin registration tool (90% success rate, one every two minutes) Click the GitHub repository in this project. The repository has an "alias email generator" that can generate alias email addresses with one click. After generation, import them into Outlook Email.
Registration tool repository files- Stuck at step 8 with the add-phone popup and can't proceed?
This is an IP / email issue, and hotmail also has a small probability of this. You can consider abandoning this email address, marking it as registered, and starting the next one.
- Stuck at step 2, staying on the OAuth page, unable to get to the registration page, cannot proceed
This is usually related to the node environment. You can prioritize checking the current network environment and page status.
- Can pull email addresses, but labels are not syncing properly
Usually, this is because the frontend page of the email management side was not opened in the browser first, causing the related state not to be established.
Follow the documentation prompt and visit the frontend page once.
Test Results:
Plugin running successfully
Outlook Email labels
Pitfalls Encountered During Development
Many people, upon hearing about an automation extension, first think it's just about "automatically clicking buttons." But after actually doing it, I found the most troublesome part is actually process stability.
This project involves multiple stages: "CPA panel, OAuth page, registration page, verification code acquisition, authorization callback, label synchronization." Each stage can fail due to factors like "page language, node environment, email type, email format, page structure changes, timing differences in redirects, old state contaminating a new round of the process."
So the real workload of this project was mainly spent on "process state recognition, exception branch compatibility, verification code polling and extraction strategies, multi-round task reset and recovery, label synchronization and log observability."
It is precisely because of this that I prefer to see it as an automation system with state advancement and exception recovery capabilities, rather than a one-time script.
During testing and maintenance, I encountered many very real problems, which I also recorded here:
Page language differences causing recognition failure Initially, many recognition logics were written based on English pages, but real user environments included Chinese pages, resulting in certain steps getting stuck directly. Later, I added multi-language compatibility logic, reducing the occurrence of such problems.
Page state not correctly reset during multi-round execution After the first round succeeded, the next round might still be stuck in the old page state, preventing normal acquisition of new entry points or continuation. This issue was later fixed with refresh and reset logic.
Verification code email formats are not uniform Email formats vary greatly between different email sources and different stages. Some verification codes are in the subject, some in the body, and some can be misread due to interference from historical emails. Later, I adjusted the polling and extraction strategies and added labels for whether emails have been read, reducing the problem of repeatedly reading old emails.
Label synchronization depends on frontend access state A very easily overlooked detail is that if the frontend page of the email management side has never been opened in a browser, a situation may arise where "email addresses can be pulled but labels cannot be applied." This issue was also later added to the documentation and prompt information.
Why I Chose to Integrate an Existing Email Management Tool
Initially, I also considered directly interfacing with the underlying email APIs, but after evaluation, I found this would quickly increase complexity, mainly considering authentication systems, token lifecycle, backend management, and unified abstraction of multiple email sources. This would require significant additional effort in development, essentially reinventing the wheel.
So I made a more practical engineering choice: integrate a mature email management tool and focus my main efforts on extension interaction, process orchestration, and stability optimization. If we want to reduce user costs in the future, we could consider integrating the management tool into a server.
From the results, this trade-off was worth it. It allowed me to get a usable version out faster and made the focus of subsequent iterations clearer.
Real Feedback Drove the Continuous Evolution of This Project
This project didn't end after it was made. After release, I received a lot of real feedback from community users, including step timeouts, page recognition failures, verification code extraction anomalies, multi-round execution deadlocks, labels not syncing, and process branches in certain environments not matching expectations. This feedback was very helpful to me.
Because many issues might not be reproducible on my own machine, but once they enter real user environments, compatibility issues become concentrated.
It was also during this process that I gradually advanced the project from "usable by me" to a state where "more people can also use it stably."
For me, this is actually the most valuable part of the entire project.
Finally
🔗GitHub:
If you are interested in this project, feel free to check out the code, and also welcome to raise Issues or suggestions.
I will continue to iterate on this project based on real usage feedback.
For me, the significance of this project is not just about making the process work. More importantly, I organized a process that was originally scattered, fragile, and required frequent manual intervention into a visual, manageable, reusable, and sustainably iterable tool.
From email pool management, to verification code polling, to label writing back after process completion, the entire chain finally has clear status and closure.
This is also the open-source project I have been most invested in and most proud of recently.