The underscore seems to be a safe bet and the deliminator could be something as simple as a double underscore "__" or even "ZZZ" - anything that wouldn't be "commonly" part of an email address.  Ideally, having a setting where you could set your own deliminator would be best.

Windows itself sometimes writes file data into the registry for indexing for example the mui entries or shell folder specific stuff in the portion of the user registry. But this isnt required for normal program operations an the program will run with or without its existence.

A developer news page was just published by David Harris on the pmail.com site:

http://pmail.com/devnews.htm

The new mail store will as I understand it be able to fully handle folders within folders. In the current version of Mercury an IMAP folder can either contain messages or other folders, but not both.

/Rolf 

I just moved mercury/32 from a Windows Server 2003 machine to a Windows Server 2008 R2, which is a 64-bit OS.

Two issues surfaced, both of which could be worked around, but, for the record, might be resolved in a future release of mercury/32:

When installing on Windows Server 2008 R2, I wanted to install Mercury/32 in "C:\Program Files (x86)\Mercury\".  This was accepted by the installer, but after the wizard completed, it proceeded to install in  "C:\Program Files (x86)\" instead.  This behavior was reproducible, although I was able to spot the missing directory on the second attempt, since the wizard gives the opportunity to cancel the install after showing the full install path on the screen. I also tried using "%The immediate workaround is to install using the 8.3 version of the directory name (in my case C:\PROGRA~2\Mercury). The PROGRA~2 was discoverable from a command prompt via "DIR  /D /X" (run from C:\).  I'm not sure if a different system would give the same 8.3 result, so I recommend this procedure to ensure the correct directory is chosen. using the 8.3 directory name in the installer.

Running malias.exe from a command-line prompt produces a pop-up with the heading "Unsupported 16-Bit Application" with the body text "The program for feature "\??\C:\PROGRA~2\Mercury\malias.exe cannot start or run due to incompatibility with 64-bit versions of Windows. Please contect the software vendor to ask if a 64-bit Windows compatible version is available". I was able to copy my ALIAS.MER file from the old server, so this was a non-issue.  Running malias on a 32-bit Windows OS would work too, but eventually that might not be a practical solution for new installations.

[warning: soapbox] A general comment on new Microsoft Windows OS's:

While it used to be common practice (my 44+ years as a programmer are showing) to have editable, and volatile files in the "Program Files" directory (or other file system space reserved for executables), it is now frowned upon because it requires programs to have write-access to files, necessitating Administrator access on a continuing basis (as opposed to install-time admin access). In an ideal "Windows" world, Mercury.ini and other volatile files should reside elsewhere (perhaps %ALLUSERSPROFILE%\Application Data\Mercury\Mercury.ini). Thus the files installed in a "Program Files" directory would be read-only, and the application would not require elevated privileges on an every-day basis. It's easy for me to say this, but as a developer, the task of making such changes to a mature, but highly successful application such as Mercury32, is time consuming. I only make these comments in the interest of Mercury/32 continuing as a viable solution in its segment of the marketplace.

Rob

[quote user="Greenman"]
Hi

How about an annotation for each connection control entry in the SMTP settings?

I was reviewing these and had to spend some time tracking down a couple of entries that I had made several years ago.

It would be useful if there was an extra column after Allow/Refuse called Notes or something similar. It would allow the entries to be quickly identified. It would also be useful in case a new administrator needed to quickly understand what each of the entries related to.
[/quote]
I realize I'm following-up to a rather old post, but I thought I'd throw in my 1.87 cents-worth (inflation, you know...).

What I do is, I keep a text file on a local system, in which I log each and every new ACL entry, including not only the "why", but also the "when" and all the supporting evidence I used to reach the conclusion that I don't want traffic from that IP range or network.  That way, if I'm ever asked why so-and-so can't send mail to my domain, all I need is the source IP (or often just the e-mail address) in order to not only answer the question, but (usually) mete out a bit of education regarding incompetent/malicious mail service providers & ISPs.

Alas, over the years that text file has by now grown rather huge -- just under 2MB as we speak.  So while it is still usable (specifically, full-text searches still run acceptably fast), a "better way" would be welcome.  I probably ought to put it into some form of DBMS (perhaps an SQL database); but converting it at this point would be a fair amount of work.  Still, if I had the database, then that "extra column" you speak of potentially could -- and IMHO *should* -- be a key into that database, which would make lookups even more painless.

That said, using the ACL list itself as the index would NOT be all that useful unless it could be sorted (presumably by IP Address) on-the-fly -- i.e., *without* shutting down and restarting Mercury.  If anything, that sorting feature in and of itself would be MORE useful, at least to me.  As it stands, I have to periodically shut down Merc, then MANUALLY sort the ACL file, resave it, then restart Merc, just to keep it from becoming an utter mess.  Pretty crude.

So my "vote" wold be to first make the ACL sortable from within Mercury.  *Then* maybe add the additional field.

It works well, kills most of the spam and just works... But I need to filter my IMAP Mail.

The phrase 'future versions' does not mean and was not intended to mean 'the next update'. It means that at some indeterminate future time, the plan is to include those features. The plural form suggests that those features will appear asynchronously, too.

There have been very few releases since 4.62, with none of them major, hence the numbering. As another reply has mentioned, there are also alternative methods of achieving the mentioned functionality, so of course these will be of lower priority to David. Cut him some slack, huh?

:) Nice, that looks like it.

Thanks,

Troy

Hello,

we suggest adding a message several head entries of the type X-CC-Diagnostic with several content control sets the option "Add a diagnostic header" is selected.

With X-UC-Weight and X-AC-Weight further the head entries from the proceeding rule should be overwritten.

Best Regards, Torsten

Hello,

we want to generate a automatic whitelist from all external recipients, to whom local users send emails. With further filter rules it would be possible to exclude local users from whitelist, whose email addresses are often used from spammers.

Therefore a filter action would be useful:  Recipients AddToList  ""

Also a new filter condition could be helpful:  If recipient(s) ListScan "" action

The difference to the scan for a sender is, that many recipients exist. This task is done in Content Control with the "recipient matches" but cannot be used with lists now.

Best Regards Torsten

A simple webmail interface integrated with Mercury would be fine. Any integrated interface would work better than an external interface. No need for a full webserver (with all it's functions, virtual hosts, cgi, ...), just an interface.

The web interface should use templates files that can be modified by the users (like the normal mail templates).

Added: I've checked IMP. That's not what most users are looking for:to run IMP you need a webserver with PHP. What most people would like is a simple DLL that you could start and stop like the other modules (SMTP, POP, IMAP,...)

It would be very nice if the new Mercury Mail Store had the ability of Zero-Knowledge Encryption.

 This refers to encryption where all mail & attachments of the user account are stored with strong 256 bit AES or even better 512 bit AES and only  the user knows the password and can decrypt his mail. The user can set the password via web or remote log-in.

 The administrator can delete the account or delete the mails, but can never spy on the CONTENTS of the mail, since they are at all time encrypted.

This would be a very nice feature and a good selling point since many enterprises like this security precaution and if they don't - well then the feature does not need to be activated by the administrator.

 Strong AES encryption would also be great in Pegasus mailboxes.

 Thank you.

Sincerely,

P.

Hello,

are there any news about the umlaut search "problem"?

Thank you,
Martin

Hi!

I know this question has been asked in the past but I could not find a real answer for it. Are there any plans for the next releases? I really need this function for my users since they want to connect via mobil devices and use "real push" instead of polling against the server...

Thanks,

Konrad

I agree this would be a great feature to have.
David did post that it would be quite easy to do !!

Any chance this could be included, even if it's only for 'registered / donated' users..

PS: I'm emigrating to NZ soon.. [H]

While waiting for that free time you could try testing the RCPT daemon I wrote some time ago. It's available in the download section:

http://community.pmail.com/files/folders/community_add-ons_for_mercury/entry10133.aspx

/Rolf

Noted - the list engine is good, but can be improved - any other suggestions?

wikipedia defines SPF as Sender Policy Framework (SPF), as defined in , is an e-mail validation system designed to prevent e-mail spam by tackling source address spoofing, a common vulnerability. SPF allows administrators to specify which hosts are allowed to send e-mail from a given domain by creating a specific SPF record in the public Domain Name System (DNS). Mail exchangers then use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators

 and DKIM
DomainKeys Identified Mail (DKIM) is a method for associating a domain name

to an email, thereby allowing an organization to take responsibility

for a message in a way that can be validated by a recipient.

I understand the difference but they are both trying to accomplish the same thing which to me translates into if I get an email from the bank I KNOW it really came from the bank.  I don't really care which route Mercury goes but wish it would choose one.

I also knew the date of the article was from 2008 and was using it to simply show how long Google and others have been doing this for their users and I wish I could provide to to mine.

Cheers,

 Jim

Added to the Beta internal wish list.

I really do think it's time for Mercury to support the proper DSN ESMTP mechanism and format (it's nearly there!) in both server and client code, and in Pegasus Mail as "Confirm Delivery" instead of using the now obsolete Return-Receipt-To that many mailers don't even listen to anymore.  Also, see Disposition-Notification-To for "Confirm reading" for the same reasons.  It'd bring Mercury in line with the big players and make parsing errors it generates easier for mailing list software.  Added points for getting the list server to do same.  See these standards documents:

* Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
* Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
* Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
* Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
* Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
* Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

You may want, but I think it essentially optional, to also implement this while you're about it:

* Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.

And now, ESMTP command pipelining.  Again, for speedy handling of mailing lists especially.  This depends on how you do things, of course, and there are some issues to be aware of, but from experimentation your server is already there and need only advertise the extension to permit clients to blast - even if you won't return the favour, you at least handle it and, thanks to TCP_NODELAY not having been set, may even be already doing it yourself!  The client, well, that's over to you.  If you can connect to a host and blast a load of recipients that the host is supposed to handle, you should!  For instance, a non-VERP list, for which the return address is software you've written to handle DSNs and pass the rest onto the Postmaster (or handle MTA-specific bounce formats like QSBMF as well if you fancy) gains both the throughput advantages of SMTP and yet in many instances the automatic ability to identify offending bouncers!

Here's the reference:

* Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.

In your own time.  And thanks for Mercury!

 Cheers,

Sabahattin