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?

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?

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?

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?

In David's Jan '26 update he mentioned problems with Memory Loss.

This is probably obvious and surely David has thought about it, but maybe as a tool, AI could help? E.g.

There may be some security / IP issues sharing code, but maybe this could help.

Currently Mercury will only accept flags for \Deleted \Draft \Seen \Answered which is ok if using Pegasus as a client, but can be frustrating for those using Outlook or Roundcube clients. Is it possible to add a 'flagged' flag for the next iteration of Mercury.
Perhaps it's an edit one could carry out already....please let me know if it is!

I was experimenting with MercuryE. I run Mercury on a dual-homed Windows PC with two ISPs and two external IPs, IP1/ISP1 and IP2/ISP2. Both IPs are nominally dynamic. The ROUTE command on the PC is set up so IP1 is the preferred interface for initiating outgoing to the Internet. As it turns out, IP1 is on the Spamhaus PBL but IP2 is not. I want to test IP2 for outgoing email but still use IP1 for general outgoing Internet. (IP1/ISP1 cannot be made static; IP2/ISP2 can be made static.) I see no way to set the interface parameter for MercuryE. I want to listen on both interfaces, so I don't want to use the SMTP server's "IP Interface to use" configuration parameter. If I make IP2/ISP2 static and exclusively send with it, I should be able to send my own email without worrying about both the PBL and using a third-party sender. Is what I want to do currently possible and I'm missing something? (In case you're curious, yes, I require auth to send.)

Hi David,

just got a error message "Message delivery status" and thought, it would be nice to have that little bug corrected with upcoming Mercury:

Message details:<br>------------------------------------------------------------------<br>Originally submitted:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 Dec 18, 9:22:57<br>Originator address:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <O.Erkens@wiwi.tu-dortmund.de> <br>Message's subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =?iso-8859-1?Q?=DCbungsblatt_4?=<br>Message's ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <72BF0.5C04F5F3.03E8@wiso.tu-dortmund.de><br>

The subject should be decoded (generally in all error messages) - doesn't look good :-)

Bye    Olaf

Some time ago I downloaded a daemon from you that fixed this very issue for me.  Hope you don't mind me sharing this.  I'm surprised really that David doesn't build this into the software..

At 17:09 2017-11-24, Jim Banks

wrote:

I had been seeing these connections

constantly and when I looked in my log noticed that the same ip has been

connecting to me for weeks trying to hack in (presumably trying different

passwords each time.  Is there any way mercury can be configured to block the ip

after so many failed attempts.  I have them locked out now, but it would be

better if mercury automatically took care of this for

me.

Mercury should block repeated

failed AUTH attempts if they happen within the same SMTP session. This is

usually not the case though. Multiple AUTH failures from the same IP address but

in separate sessions can however, if frequent enough, be caught by my SMTP Event

Daemon. If you would like to have a look at it you can download it here: / Rolf

Ooo!! Do we have a release date yet - because the developer blog is quite a bit out of date...?

 I use many filtering rules for a presorting of all incoming mails. Sometimes i want to know, which rule was activated. The message "job killed by filtering rule" does not really help.

That's great news, Rolf. Thanks for the update :)

You're welcome. Nice to hear it is working now.

 Jyrki 

It appears to me that DKIM can simply be implemented by writing a Mercury daemon, with the daemon parsing all the necessary fields, and adding the required headers to the outgoing message.

Unfortunately, all the are rather abstract, and do not show any example code, or pseudo-code at all, of a simple message, with an example public key, private key, and a verified message with all the required headers.

Hello David,

Thank you for your very detailed response. As far as I understand, it should primarily support PFS and choose that kind of ciphers with higher priority. Ciphers with a higher encryption should in general always be priorized. Older ciphers don't have to be banned, unless they are considered insecure (because of outdated/depricated) or flawed.

I did some online testing with a online smtp ssl checker: it showed PFS were not supported, but after enabling mercurys session logging I've seen that:

ECDHE-RSA-AES256-SHA, SSLv3, Kx=ECDH, Au=RSA, Enc=AES(256), Mac=SHA1

DHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=DH, Au=RSA, Enc=AESGCM(256), Mac=AEAD

ECDHE-RSA-AES256-SHA384, TLSv1.2, Kx=ECDH, Au=RSA, Enc=AES(256), Mac=SHA384

are often negotiated for encrypted communication. These are PFS ciphers. So the online testing doesn't seem to be reliable.

The person of the Data Protection Authority we are in contact with is an IT-Professional. I've heard from him that he had already contact with other mail server developers to help them out with all these issues. I've heard also that they have their own software for testing purposes. My suggestion: I will get in touch with him, show him this thread and ask him to get in direct contact with you. I think that would make more sense. 

Thanky you very much in advance.

Claudio

Just wanted to say thank you for adding SSL support to the MercuryE (Client SMTP) module.  Since Gmail started displaying the notification about non-encrypted mail I was really happy to see version 4.80 added that feature, and made it simple to start encrypting.  Keep up the good work.

P.S.  I tried to send this by your contact form at: http://community.pmail.com/pmail/Feedback.aspx but it kept saying "Wrong code" despite me being pretty sure I was typing in the correct codes.   I tried like 5 times, and the codes are pretty clear, so it seems like that form is broken.

Hi !

Is it somehow possible to verify the IP of the sender by a DNS MX Lookup ?

Either by IP of sender or domain of senders address ? 

Thanks for a short reply

bitbo 

All,

On startup after the from v4.74 to v4.80 MercuryI failed to load throwing a "No such file or directory" error.  I tracked the problem down to the path to the certificate in the MercuryI section of mercury.ini file.  The previous certificate was named "imapcert" which v4.80 obviously did not like.  I run in a second Mercury instance in which I run MercuryS so I copied its newly created certificate, then modified the path in the .ini.  My suggestion is to consider whether it would be feasible to allow access to the module GUI after encountering an error like "No such file or directory". 

One other suggestion is to provide the ability to create a certificate from outside of the modules so as not to be dependent on a module starting up in order to create a certificate.

Thanks for providing this Nenad.  I've had a few instances of dubious messages coming through recently which this should help with.  I haven't had experience with Policy Tasks but through some investigation, it looks like you need to escape the double quotes you added around the ~F argument.

So  

Task: "ZIP-EXE",17,0,"C:\\MERCURY\\ZIP-EXE\\zip-exe.bat ~X ~R "~F" ~Z","","",0,"Admin"

becomes

Task: "ZIP-EXE",17,0,"C:\\MERCURY\\ZIP-EXE\\zip-exe.bat ~X ~R \"~F\" ~Z","","",0,"Admin" 

If this isn't done, some of the fields in the 'Edit policy task' dialog are incorrect, namely:

Commandline:  C:\\MERCURY\\ZIP-EXE\\zip-exe.bat ~X ~R

Sentinel file: ~F" ~Z"

Parameter: 0

Thanks again

Hi all,

Is it possible to use the "label" function ( thunderbird) with mercury server and IMAP?

Some mailservers have the option to save the label on the server, when opening the same mail on a other computer the label is showed there too.

This wouled be a great function to use with mercury server!

Rene