[quote user="Peter Strömblad"]

Out of curiosity: Why do you detest RDP?

[/quote]

I have found it very slow, and lacking in configuration options.

By contrast ultraVNC is very easy to adjust the encoding & compression among many other options like screen scaling, colour depth etc so it can be tuned to be very fast over most connections (I have used over dial up quite successfully). It also includes a remote file transfer facility & is dead easy to put through an SSH tunnel.

The "single-click" executable version (~160k one .exe no installation, I have it on my webserver for people to click on [:D]) is runnable by 'support clients' to call back to me, bypassing firewall configuration issues if I had to try and connect to a server running on their machine.

I used it to fix an email issue on a client's laptop on a public wireless link in North Carolina from my lounge room in New Zealand :)

Over an enterprise, or Local LAN, RDP may be perfectly adequate, but it doesn't fit my needs.

Thanks...  Missed that !

But what happens if that message is finally delivered. Here's the

situation: We are currently set up to retry a message once an hour for

10 times (10 hours). Our VERP, as previously mentioned, is set to three

times in a week. If I understand the above correctly, after three times

of trying to deliver, it will VERP. What happens if the message is

delivered on the fourth, fifth, etc. time? Does it 'un-VERP'?

Nope, the third bounce blocked it.  It never gets anything from a successful delivery.  It's only tracking failures.

It seems to me that the retries and the VERP settings need to be in

sync with each other. For my case, if I want to capture all the

addresses that are not delivered in three days out of a week, I would

set it to 30 (three days times 10 attempts a day). While this would not

be perfect, it would be a lot closer. Right?

That's probably a lot closer.  However with a really good mailing list I would not expect so many temporary failures.  I really would set MercuryE to timeout in not less than 600 seconds (you might get by with somewhat less but 600 is a good place to start) to ensure that you are not simply trying to deliver to busy servers that timeout on you.  I use 300 seconds currently and almost never get one of these multiple delivery failures and then one that succeeds.  If I get a VERP bounce it's either because the the account is blocking, there is a problem on the server or the account is bad.  The account blocking and mailbox too fill are my most common errors.

Is it possible to delete the email with our external daemon, when we append the mail to another inbox?

 Yes, no and maybe.  MercuryI does not support deletion of a message via IMAP4 when there are multiple connections.  It will be marked for deletion but will not actually be purged until the last connection is closed.  You of course can use a daemon to delete the actual CNM file but I'm not all that sure how the IMAP4 clients will handle deletion of the message file without cache corruption of some sort.

[quote user="kfreeborn"]What does Delivered-to do? [/quote]

Generally this is the way an ISP passes the original SMTP RCPT TO: address to the body of the message when delivering to the users mailbox.  Every ISP that provides a "domain" type POP3 mailbox should do something like this so that the receiving POP3 mail client can separate and deliver the messages based on the original SMTP addresses.

Well, that's a lot easier than the way I finally figured out. Mercury writes the VERP address and the actual TO: address in the logs, so I was searching for the VERP address and then searching for the message number to find the e-mail address.

I like your way better!

Thanks.

[quote user="Barius"]Hmm, who's definition of 'soon' are we going by here...?[/quote]

Where did you get 'soon' from?  Did you read the original thread?  Nobody made any promises of when it would be done.

Not that I know off Thomas. But I fully agree something must have happened, since my current situation is Merc/Peg's default behaviour !

On another location, users have RF rights on their PXMF.INI as well, but are able to change (and save) the extended features in Peg.

But I'll stop bugging you, this is clearly not a Merc/Peg problem, but a filesystem thing.

Thanks for your help!

Ron

PLEASE add IMAP filtering

Please knock it off.  He's answered you a long time ago and knows you want this.  If you want to do this put it into the wish list forum that's ok since I do not follow that one.

Interesting Morten,

Among my utilities (downloadable here: ) you can invoke delay.exe for x-number of seconds prior to running loader.exe

Have a look at http://community.pmail.com/forums/post/4965.aspx

Someone wants to know what your favourite choice of MTA is.  I'm well aware that Mercury is in the definite minority, but I'm pleased to see that it's explicitly represented in the survey.  Perhaps you can add your voices and give a genuine figure on Mercury usage; it seemed a post here (someone please advise the mailing list, too) would provide an opportunity for those not already aware of this.  The URL is:

I can't be surprised that Postfix is taking the beauty spot nowadays.  Two years back it was definitely Sendmail; nowadays Postfix is pretty much all there, copycat as it is; fast, flexible and secure.  But, for sure, Sendmail is still my top choice of power MTA when a Unix-like OS is available.  Mercury is the best I can find for Windows-only or Windows-majority situations.  I would sooner use Mercury on Windows than try to convert an existing Exchange into a usable MTA, either by proxy, modification or fronting using a Unix mailer if clients are all ready to go on Windows direct to an all-in-one piece-of-cake mailer like Mercury.  (If there's any doubt, that's no insult, David, in case you read this.  Mercury rocks and is NEEDED.)

Cheers,

Sabahattin

"Subject:" is not one of the SMTP envelope headers, which is what gets logged.

You could probably use a policy to call a batch file or other program to parse the message body and extract any info you want to a file.

no problems with srvr2008 in play - I've tested MercuryS/E/P/I under load with messages up to 30MB without problems. When I test I always test on a clean system, within virtual server or the later HyperV, meaning nothing else installed than Mercury on the test machine.

Most likely as Rolf has pointed out is that you have hooks within the WinSock stack that intercepts the traffic, examines and passes it along to the next process in the chain. These process hooks cannot be turned off unless you clean the registry hooks and re-boot the machine. We had similar problems with one particular build of NOD32 v3, and it resulted in frequent but random blue screens. We uninstalled NOD32, re-booted twice for all the hooks to clear, and the problem went away. Then later we applied a newer build of NOD32 v3 and there hasn't been problems since.

When you turn off an Antiviral or antispy software, the dataflow still has to be passed on to the hooks (= dll's the hooks point to) but, should be just going in and back out again. But if the Dll in play has some other form of fault, memory leak etc, then you get all sorts of trouble within the windows kernel.

Once again the online community came through.  Thank you for all your help. I found that the INI file was indeed considerably smaller than the bak & bk2 files. Copied over the backup file and all is back working as normal.

Thanks again

Is it possible to have multiple instances of Mercury running on different machines, all accessing the same outbound queue?

No it is not, you will send multiple messages if you try this.  You can split and use two versions of Mercury/32 and have one doing the sending and the other doing the receiving.  This second version would be looking at the same queue directory but would only be running MercuryC or MercuryE.

 We have several really large e-mail lists and want to set up another

machine to handle outbound mail for these lists. Our concern is that

the core of the 'secondary' machine will pick up a message that was

meant for the list and not be able to process it since it doesn't have

access to the list.

You can setup the second server to only process the mail for the list by having the first server forward any list mail to the mailing list on the second server.  You would create an alias pointing to the second sever via a user@[<IP address>] address form where the server name would be [<IP address>] so it would go to maiser.  For example, you create a list called "large_list" on the second server running on IP address 192.168.1.2.  You alias mail to large_list@mydomain.com to large_list@[192.168.1.2].  Now mercury core sees the mail come in for the list, creates and outbound task and ends it to the second server.  The second server sees the match for the server name and so passes it off to maiser.  The second server now sends out the mail.

This can also be done via a domain accont and MercuryD on the second server to pull the mail from the MercuryP server.

ok, it works, thanks a lot...

[quote user="PaulW"]

Go to Configuration / Mercury core - Files tab, and ensure 'Delivery confirmation template' points to a non-existant file.

or simply leave the entry blank.

[/quote]

You can disable delivery notifications by selecting Configuration / Mercury core / Files and removing the Delivery confirmation template (just leave the field blank).

/Rolf 

Ok, Thomas, that was it! Thank you very much! [:D]

I don't know why I left this field empty. I think because the docs say somthing about PMail and I thought this would only have to be set if I would plan on using PMail which I am not. The issue is solved than. Thanks again.