Mercury isn't free though. It is licensed software.

 http://community.pmail.com/pmail/MercuryPricing.aspx 

 As Thomas already stated, There is Squirrelmail for webmail, and with use of daemons  (even with out them) Mercury is already powerfull. Spamhalter, Greywall and Content Control and even the standard filtering Rules... and more...

I run Mercury as a service (win32) that starts up automatically when I start up the computer.
When starting, the startup screen always appears for couple of seconds.

It would be nice to have a parameter (for example mercury.exe -nosplash) that starts up Mercury without splash screen so that it feels as an "invisible" service when starting up the computer.

 
Comments:
Strangly if srvany.exe is used (part of Windows Resource Kit Tools) to create the effect of Mercury as nt service, there is no start-up screen when the parameter mercury.exe -m is used, but there is a minimized window of mercury in the taskbar that disappears when you click on it.

When the program FireDaemon () is used to let seem Mercury as a nt service, there is no minimized window but still a startup screen.

Sorry. I meant to post this in the Pegasus Wishlist!

I actually set mine to 1.  It prevents the hammering.  As for legit emails, a legit email will retry again some time after the blacklist clears.

Well, you can run the NLM version of Mercury handling mail delivery on a netware server and have a Windows server running Mercury/32 as an IMAP server in netware mode to read mail.

 You have to run Mercury/32 on windows though for this, even if it is just purely for IMAP, there is no way round that.

 David. 

For internal reasons (to do with the way Mercury manages the list files) it's not a trivial change to sort the subscriber list. It's a reasonably common request, but implementing it will take quite a bit of effort.

Cheers!

-- David --

Many thanks!

I'm trying to do this as well - I use popfile to classify mails into 5 separate categories, so I really want to use 5 folders inside a single user account.

Do you think a scheme like this work?

1) create a 'policy' that will run a program when mail arrives, like an antivirus scanner. This program must launch another process, then return control to mercury so it can finish delivering the mail

2) the process scans the mail headers to work out which user received mail. (optional, with only a few mailboxes you could just do them all)

3) the process waits a minute or two until mercury has finished delivering mail to the user's inbox

4) the process launches one of the perl scripts mentioned earlier, which then use IMAP to connect to the user's inbox and move any new mails it finds to the right folders.

Is there any way to make it more deterministic, i.e. remove the delay? For example, could a mercury daemon launch the perl script after the mail is delivered?

Thx, I'll try them

It's good to know someone is working on AD, but I'm still curious about a more generic LDAP version?

LDAP/OpenLDAP is arguably used in more places than AD.  Even in a Netware environment, LDAP is now the prefered method for connecting to an eDirectory tree from 3rd party apps...

We create the smtpauth.mer file with the same pairs as local mailbox name (= username) and the pop3 password. If your local mailboxes follow the syntax you should be able to have that combination  within smtpauth.mer.

However, we've found it to be limiting, narrowminded and confusing for the users to have local mailboxes equal the mail-address. It gets very hard to explain that a mailbox has mail addresses attached to it, and that you can have as many as you like connected with a mailbox. Also for our users when using the webmail interface our users can log in using either their email address or their mailbox name, and a conversion is made if needed into the pair of mailbox/password for proper pop and imap fetch.

At this point, you can't really write a Daemon that could have a significant impact on the way MercuryP operates - I haven't as yet opened up its innards in the way I have for MercuryS... GreyWall is a good example of the type of minute control that the new protocol-level event mechanism I have developed for Daemons allows, but I'm retrofitting the event mechanism on a module by module basis, and MercuryP hasn't been done yet (even for v4.5). It's on the list though.

That said, the sorting idea isn't a difficult option to add, so that seems like a reasonable compromise in the short term.

Cheers!

-- David --

Commentary on Point 1.
  The 30 char limit on email address in the Syslog (I and O records) will truncate this : Symantec_Mail_Security_for_SMTP@workorder.se
  Changing to variable-length records will also allow the addition of new fields more easily.

Commentary on Point 2 relating to mail stats.
   In trying to determine bandwidth usage per user, I have been examining the "I" and "O" records from the Syslog.
   2.1  Mail between Local users only generates an "I" record.
   2.2  A Local / Non-Local identifier on each address would be most useful for reporting (as indicated in the Core display)
          This to be able to split reporting between Local and Non-Local traffic.
   2.3  Inbound mail indicates the TO address as the "mailbox" name and not the "alias" (email address)
         Outbound mail shows the FROM address as the email address and not eh "mailbox" name.
         Correlating the two is not possible by looking at the data only - a matching table is required.

Have you had a look at PopfileD? It's a server-side daemon for mercury that uses popfile to classify mails.

I have 5 separate buckets set up; you could create a bucket for 'houses' that adds an X-Text-Classification header to the mails, then your boss could filter houses mail as spam, and you could filter it into your 'todo' folder for example.

This forum offers you somewhere you can suggest things you would like to see changed in, or added to, Mercury/32.

As with the other forums on this site, the only real rule in this forum

is that you should maintain basic standards of courtesy - so, no

flames, rudeness, abuse... You get the idea.

Before you post here, we strongly suggest that you search or scan

through other postings to see if your suggestion has already been made.

Forum moderators may delete posts that duplicate a suggestion already

made elsewhere, simply to reduce the number of items in the list.

Finally, although I and my test team will regularly read this forum and

will try to reply where possible, we can offer no guarantee that any

posting you make will get a reply, nor that any feature you request

will actually be added. That said, this forum is likely to exert a

quite powerful influence on the things that get chosen for development,

and the order in which they are developed. This is your forum - make

sure you have your say!

Cheers!

-- David --