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

Rolf:

I don't think you've missed anything... this is excellent and would prevent what happened with my family earlier (two identically configured instances trying to download from the same ISP mailboxes at the same time).  Your solution sounds very simple, straightforward, and clean --- the hallmark of all good engineering.

Many thanks.

Just a tip: Include links for read-up, like the ones below

http://www.isode.com/whitepapers/imap-idle.html

Hi all.

Right now (Mercury 4.62) the only way for the VERP processor to suspend/delete a subscriber whose e-mail is bouncing is when the corresponding total error count exceeds a certain fixed threshold level either set to "N messages per week", "N messages per month" or "N messages in total".

Considering that the delivery errors are often transient, ie they usually get fixed in a relatively short period of time, I think it would be useful to have fourth error count mode (which I call "max-errors-in-a-row"), in which a subscriber would be suspended/deleted only if the delivery failed for "more than N messages consecutively". This would be quite trivial to implement, because the error count just needs to be to reset to 0 each time a message is successfully delivered.

In my opinion this additional mode could prove more effective than others in certain situations, such as the case a low-traffic distribution list in which each subscriber receives just a few message per month in the average (in this situation the other modes seem to be too much draconian).

Just my 2 Euro-cents :-)

Thanks for the attention,

  Corrado

[quote user="dilberts_left_nut"]Outlook can do POP3 as well, but for a shared mailbox, IMAP may suit your needs better.
[/quote]

Rolf,

Understand since POP is single threaded and IMAP is multi-tasking.

 
Thanks!

 
OMR
 

Ask, and ye shall ... find out you are already about to receive [:D]

Your password should only contain chars: A-Z, a-z, 0-9, - and _

We've only occasionally with Mercury 4.01 experienced cache problems related to password changes, then a restart of Mercury cured things. I haven't seen any such errors since. What could be another case, is if Mercury can't open the password.pm file, then I believe you'd see the same result - but I haven't tested that scenario since 2002.