This is what the help text says:

Local user  If you enter the name of a local user on your system (one to which Mercury can deliver directly) then all the mail downloaded from the remote account will be sent to that local user, irrespective of the address fields in the message. If you leave this field blank, MercuryD will examine the To, CC and BCC fields of each message looking for addresses it recognizes as local. When it finds a local address, it will send a copy of the message to that local user.

As far as I can tell no address headers in the message should be checked if a local user has been defined. 

 /Rolf
 

I emailed the author of the clamav version I'm running.
He suggested trying the SVN version.

I've tried that and now it launches in a couple of seconds with NO event log errors.

Thanks :)

Thanks David.  I am going to do the upgrade right now.

 Eric

Unless there is support in M/32 or the new daemon interface for recalculating the queue counters a webadmin interface won't help much in this case, though. If there is support for it I'd be happy to add the function to my web interface.

/Rolf 

Interesting, I'll play with this in a test environment later on and let you know what I find - I say interesting because it is something I can elaborate on in the webadmin for a domain since many have asked about how to divide and distribute info between departments.

Thanks.

Installed and seems to be working very well.

Okay, well thanks a lot for the help, I'm pretty sure I got it working properly now!  What happened was, I logged into my DNS center and after searching around for a while, I finally found out that, by default, the mail was being redirected to my hotmail account.  I just wish that it wasn't set as default like that without me even knowing, and it would have saved a lot of stress.

Oh and I can send and receieve e-mails properly now, so thanks a lot guys, I really really appreciate it!!   

Most any unused port is valid for receiving mail from your e-mail clients, port 587 is normally used for mail user agents.  Mail sent from other servers to MercuryS though must be received on port 25.  You can configure MercuryS to use port 587 as well as port 25 and you can also use TLS secure links and authorization.  Mail servers sending through MercuryS may or may not be able to use the secure connection so you must not disable the unsecured connections.

It's possible that your IP is on a blackhole list. 

For a variety of reasons, Mercury is quite strict about enforcing the syntax of the MAIL FROM: and RCTP TO: SMTP commands. The main reason is that syntax errors in these commands are a common indicator of spam (no properly-written SMTP client should ever be getting the protocol this badly wrong). The secondary reason is that a number of open relay testers use deviant or invalid forms like this as part of their test, and evaluate the server based on how it handles them.

As Thomas has pointed out, the syntax for these commands in RFC2821 is quite specific - you can't just throw any address format in there. If your mail clients are getting this so badly wrong, you need to get back to their authors and suggest that they re-read RFC2821, then correct their code.

Cheers!

-- David --

Thx!

Installed the beta version, duplicates not resolved, haven't had a chance to see whether the slowness has been fixed. Meantime I did find out that my duplicates issue seems to be Android related; see  , though the thread suggests that its a bad sever implementation. But the number of different servers mentioned with the problem imho indicate a client issue nontheless. Still not entirely sure as I had the issue with AgendusMail on the Palm device as well...

It turns out that this was nothing to do with Mercury or Pegasus.   We use file permissions to control who has access toeach mail box and the user accoutnin question had not had permission for the administrator account which runs Mercury to access it properly.   This was a mistake as it happens.   I corrected the directory permissions and the file hieracy appeared correctly.

Thanks to all those who helped me on this one. 

Thanx it worked.

Cheers
amir

... and I can make the modifications necessary to make it work with any browser. Which is what the vast majority of webmailers aim to do. Fancy stuff, like drag and drop from inbox to another folder is possible too (see GMX), but that doesn't mean that it has to work that way.

Actually, I don't see why David has to spend the little time he has developing yet another webmailer. That wheel has already been invented. Horde ( http://www.horde.org/webmail/ ) works fine with any IMAP server. 

[quote user="tomt"]

I think to help me with this, I need to know exactly what Graywall is meant to do !!

Is it working on the IP address or the FROM address or both ?

Thanks

[/quote]

It's a triad of IP address of the sending system, MAIL FROM and RCPT TO address.. 

using server 2003 and 4.51: i only have the problem, when i use mercury with the help of a service-wrapper and connect to the console. then i can´t use the help. otherwise no problem.

Thank you, Han.  I am going to move this topic to the Pegasus Mail support forum (which is where it should have been in the first place - sorry!).

I'm looking for a solution that doesn't require user interaction.  There's two reasons for this; one: I've trained the users to be suspicious of email that wants to be activated in such a fashion (that training has paid off significantly in the past - we got hundreds of email zip viruses on day zero)  and two: my users, my management, and I myself want this sort of thing to be handled in a completely user-transparent fashion.  These people do not want to mess about tuning their email system, they want to do their real jobs.

Most of Pegasus's configuration is extremely well suited to this sort of thing; flipping switches from N to Y or editing strings is pretty easy to do on a massive scale, and using INI files means that configurations can be stored and backed up using very OS-agnostic methods.  There's no putzing about with registry imports and exports that may or may not be written to disk or held in memory at any given time, there's no relative identifiers encoded into anything. The only exception is the bit-mapped and byte-mapped variables, and even those can generally be decoded by simply  turning stuff on and off and diffing the resultant INI files.

For example:  If I wanted to set the "organization string" for 10,000 users without having to co-ordinate the efforts of 10,000 human beings, I could do it all by myself with four or five lines of code.  Pegasus's simple, clean ASCII configuration is what allows me to do so.  Registry-driven software is inherently more difficult and cost-ineffective to manage.
 

Sorry for the late reply, thought I had already posted a message, thank you both for your quick response!

[quote user="tokul"]

mercury32 4.51 crashes if submitted IMAP folder name does not match character set selected in IMAP module configuration.

[/quote]

This problem is fixed in the v4.52 patch, which will be out either today or tomorrow. Note that the "fix" only prevents the crash - if you try to create a folder with a name that cannot be represented using the default character set configured in Mercury, the foldername almost certainly won't be the way you expect it to be, but the program won't crash. In the examples in this thread, where attempts were made to create a folder with a single illegal character as a name, you'll just get a "NO" failure response from Mercury.

The aim is to add full unicode support for folder names in an upcoming release, but for now, this workaround will have to do.

Cheers!

-- David --

Duly noted, I'll let you know when this work starts, and hopefully can add you as tester.

First I have to translate an upcoming release of the webmail product we use.