I don't think of myself, of course—not while I can run other server software on macOS or Linux (typically in a VM on a hypervisor). I think only of my potential future self, and all the other poor sods who insist on running Windows in order to do actual work, many of whom I will support, and for whom Mercury has long served them as the excellent and efficient mail-server-on-a-trolley with nice integration for Pegasus Mail. I hope you will therefore understand the lack of diplomacy, but I think this is what you should do to get Mercury into a decent shape, at least for a mail server supporting the commodity protocols (with your HTTP server, you could also consider the *DAV, JMAP and even ActiveSync protocols, but I'll leave that out for now since it would be significant effort). IMO the fact that Mercury is the only really decent community-supported option on Windows with minimal strings attached for non-commercial use and a very reasonable price for commercial use, except perhaps for the young and cross-platform upstart Stalwart, is a credit to you, but it does have gaps which are a bit painful to see in 2026, and I think you want to fix them for a competitive commercial product that will compete with more fully-featured kitchen-sink alternatives. And, to be clear, I would be more than happy to pay for an upgraded Mercury with the most crucial of these features included. So here you go. This is what I think you should really consider adding in the near term. In your own time, obviously. And, as a long-time user of Mercury and Pegasus (but now largely on macOS), it goes without saying that I appreciate the work you do, whatever you decide to do. Cheers! * Get rid of MercuryX and leave scheduling tasks to the OS. A command-line interface should provide pause/resume/drain/ETRN. * Combine MercuryE and MercuryC: * Because the distinction is unnecessary and confusing. * Because it duplicates functionality. * Because it's less flexible. * Mail routes, including a default route, supply the relay/null client case. * Authentication credentials and TLS requirement levels are matched by hostname. * Parallelism by destination host/address, not just overall. * Selective disabling of ESMTP extensions or authentication mechanisms, to work around bugs and misconfigurations in servers. * Optionally derive HELO/EHLO argument from interface address. * MTA-STS and/or DANE for automatic TLS policy discovery. * Alias overload: * Wildcard aliasing, on the username and domain portions. * Queue-only, to support backup relay, whether for fixed recipients or whole domain(s). * Filtering rule action to deliver to a mailing list supports overloading list addresses as with mailboxes. * Supported and documented hot-reloading of the aliases file and/or the user/list databases. * Disable receiving mail to other than aliases and postmaster (support real virtual domains). * Mailing lists: * Better DMARC mangling of From ("Poster's Name (via listname)", or similar/customisable). * Optional poster address stuffing into Reply-To. Obscene, yes, but works well enough. * Per-user moderation flag and default state on subscribe (moderator approves first posting, unsets mod bit). * Mobile-friendlier approval by maintaining a moderation queue (via email or MercuryB, but not resending). * Foolproof email-based and HTTP-based (including one-click) unsubscribes for VERPed subscribers. * VERP action holdoff period: don't count bounces for a delay after the first, to deal with irregular floods of bounces. * MercuryI: upgrade to IMAP4rev2 and recommended extensions. * But especially QRESYNC and CONDSTORE, because those significantly improve bandwidth-efficiency on mobile devices. * MercuryS: * PIPELINING, CHUNKING, DSN extensions. * DSN format reports, as required. * Advertise hostname by address of interface(s). * Selective disabling of extensions and authentication mechanisms (to work around bugs in clients). * Differentiate submission from public SMTP services properly according to port used: * Submissions have Date and Message-Id added when absent, optional From validation/enforcement (header and envelope, as required), require authentication at all times, maybe always uses TLS-on-connect (port 465), and never rejects mail (optionally including to local users, for a nicer bounce experience). * And SMTP never advertises AUTH. * DKIM and SPF validation, optionally, so: * Header additions (Authentication-Results). * Rejections of SPF hardfail and user-specified quarantine behaviour. * DMARC policy enforcement (do nothing, quarantine in a configurable way, reject). * People like me think DKIM, SPF and DMARC are obscene, so please make all rejection optional / quarantine as a ceiling. * Two-pass mailing list submission check: if possible, reject unwanted posts at SMTP time to reduce backscatter from lists or Maiser. * Documentation: * Roll the stuff in the manual, like the flowchart, into the help. * And all the little secrets buried on this community board. * And the job submission format (.101 files). * Make the help browsable on the web (or maybe via MercuryB)? * Pegasus mail integration: * Should always preferably use IMAP for mailbox access. * Can continue to use files for other integrations, or (better) design a network protocol for them that can be used by anyone. * Is asking for SIEVE filtering and ManageSIEVE asking too much? Yes, probably … * But, quite definitely, still defer user rules to the server. * Or maybe a simple web interface for rules, forwarding and autoreplies?