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.

Hello,

I use autoreplies in MERCURY using an AREPLY.CFG file. With the actual release of MERCURY,we can exclude some autoreplies by managing a file named AREPLY.KFS. I think it could be very interesting to have another file which list all approved e-mail for autoreplies.

With this new file: 

Imagine a simple situation, you are in holliday you want to set an autoreply on your account only for known contacts, so you have just to export you adress book in text format select the Email column and past it in the file.

Another idea could be to support wildcards in AREPLY.KFS (and the new rule file) for example rule like : "*@pipio.com"

Greeting

Francoy 

Well, it's in the help.

Send an unformatted email to maiser@..... 

with the text body like 

Add <listname> <user> <personal name>
Add <listname> <user> <personal name>
Add <listname> <user> <personal name>

Hi Richard

I use both Mercury and Pegasus Mail in a high school, I've about 1300 users. Each year about 1/3rd leave the school, 1/3rd are new ones and the last 1/3rd change their group (as they change their grad).

I created some scripts to manage those change in Mercury/Pmail and also in W2k3 AD, all scripts are in vbs. It's quite simple. You're right some scripts should be given to help to manage Mercury/PM.

Last think : a domain mailbox is not only *ONE* user it's multiple users so you've to pay for the right license.

Regards

Worth giving this another kick [;)]

@fojtik 

Yes, I already use dos command format, sometimes it is still not short enough.  In these cases I resort to .bat files.  However, this is the 'Suggestion & Wishlist' forum, which is why I am posting a request for a feature, which in my opinion, should have been implemented years ago.

I'm afraid there seems to be some problems with the online license purchase system for Mercury.

The first (technical) one is that the PayPal page didn't at all load in Firefox, I had to start again using MSIE. The second (legal) one is that the receipts received from PayPal aren't acceptable business documents for the transaction. The full name and address of the seller isn't included, nor the name of the buyer, nor a specification of what kind of license has been purchased.

/Rolf
 

Update:

There is an email sent out at a later time (in this case 2 days after the payment) with a download link, that gives the opportunity to print an invoice. This does presumably take care of the legal problem.

Hi all

Many thanks for your support, sorry my silence during last days... I see you understand my wish, i want a private relay server and I can 't use IP filter adress because some connections will come from internet and the IP adress could be xxx.xxx.xxx.xxx.

Yesterday i found another way:

    -Close all port on my internet firewall except the incoming port 80

    -Install IMAP support in MERCURY

    -Install Appache-PHP server with squirreimail on the mercury server

So when an internet (autorised) user need to use my SMTP server to relaying an mail, he can do it using the webmail interface.

Francoy 

[quote user="rshouts"] I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.[/quote]

Interesting solution, & I agree to the wish of either a separate config file, to allow direct host forwarding - would prefer not to mess up the hosts file.

[quote user="Thomas R. Stephenson"]Not really sure how much good they will do for most people.[/quote]You could say the same thing about any proposed feature; that doesn't mean the feature lacks value.  In any event, I think it would be VERY useful to at least be able to apply transaction-level filtering to ANY header, even if we must (for now) forego examination of the actual message body.

[quote]The transaction filters generally work on the SMTP mail headers[/quote]But, as it stands now, only a small predefined subset of them.  That's the problem.

[quote]Working on the body of the RFC 2822 message looking for headers means are are in the process of downloading the mail already and normally you would not issue the 500 series error message in this stage of the message delivery.[/quote]I think that in place of "normally", the term "traditionally" is the better fit -- but the traditional approach does not really serve us very well in the here and now.

[quote]I know it's legal to do it this way but it's messy.[/quote]So what's your alternative?  The point here is, issuing a "250 Data received OK" and then realizing you've got a spam/virus/whatever on your hands is even messier.  As explained in my original post, that leaves you on the horns of a no-win dilemma.  No matter what you do at that point, it's going to be wrong in some way -- perhaps seriously wrong in the case of "backscattered" spam (or worse, viruses).  The only truly clean solution is to not "accept" that mail in the first place -- which brings us right back to doing ALL the tests before issuing the "250 ...".

[quote]FWIW, I've got Mercury/32 running on Linux (Ubuntu v7.10 with Wine v0.9.50) without any problems at all.  I am running Clamwall, Spamwall and Graywall as well.[/quote]Cool!  That definitely give me some encouragement; but it doesn't really address the primary issue I posted about.

[quote user="tBB"]Spamhalter doesn't strip images, it just does a Bayesian analysis of the image characteristics. Stripping inline images altogether or converting them to attachments also breaks many commercial (legal) newsletters etc. If you use Mercury's content control you can use something like this

IF BODY MATCHES "/b*src[=3D ]+[\"c]+id:*" WEIGHT 50 Tag "BODY: Contains Inline Image"

to give mails containing inline images additional spam points.

Best regards

Nico
[/quote]

I found that this does a great job in helping me detect the

"enhancement & meds type" image spam. I use it in a CC rule set that gives

SpamHalter 50% trigger value and this the other 50% and

it seems to work very well. Thanks much!

In fact using -1 as the age of a message DOES detect future dated emails in Pegasus so a similar feature in Mercury would be very useful.  

 Having said that the popularity of future dating by spammers seems to be on the wane a bit.
 

Hi

This is something I've already asked for.

Hopefully David will consider it ! [:D]

Hi Peter,

it's Regular Expressions. Sorry for using it.

A KB article with as much as possible examples was very much appreciated. Especially as regular expressions in different portions of the program seem to behave different and the help file does not cover it (enough).
Mostly I think about information what part of information is evaluated at all (like the "SMTP TO:me@domain.comCRLF" in transaction filtering), where to derive it from and which regular expressions (or metacharacters) are supported at which point.
Example: H, "[HE][HE]LO lappy/w/w", S, "my machine" works in transaction filtering, H, "/x[HE][HE]LO lappy", S, "Lappy" does not (from help, section content control: "/x Toggle "ignore-non-alpha" mode - ignore non alphanumeric characters".

Thank you, Rainer

[quote user="David Harris"]
You are welcome to suggest extensions to the existing regex engine, though - I will consider any reasonable request if it is feasible and can be done without creating significant backwards-compatibility problems.
[/quote]

I suggest this:

 Cheers!