[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.

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]