There are a number of different actions available to a rule set. "Copy" makes a copy of the original message in the selected local mailbox. "Move" writes the message to a local mailbox and ends handling of the message. So always copy to user1 and always move to user2 should cover it. 

/Rolf 

I posted a question a while back here: http://community.pmail.com/forums/thread/19136.aspx

I think I have found why this has been happening occasionally. I found that the most recent one that caused this build up of messages that said they could not be sent - which related to one message in particular) was sent from an ID in Pegasus that I rarely use. I did a bit of digging into this and discovered that at some point somehow the sender's mail address and reply to address had been deleted from the Options and Internet Options. This would explain a rejection or failure to send, I imagine.

I am posting this as it could help someone in the future.

I have no idea why an id would lose these settings but that would be another topic for the Pegasus Mail forum another day. The point is that I have discovered the reason for some of my messages never arriving at their destination and the build up of messages in the Mercury Queue folder.

Cheers!

Ellie

This is a common problem. You need to tell the socket stack not re-use the socket, f.ex. by setting the socket idle timout on your session to a very low value (like 1 second).

This is what it looks like when coding C# in .NET

MailMessage msgMail = new MailMessage(); 
msgMail.To.Add("address"); 
msgMail.Body = "test"; 
SmtpClient Client = new SmtpClient(); /* uses settings from web.config */
Client.ServicePoint.MaxIdleTime = 1; /* without this the connection is idle too long */
Client.Send(msgMail); 
msgMail.Dispose();

A download link has been sent!

In most cases the X-Envelope-To header will provide the wanted information, but move and copy rules bypass that. To make the forward action work as expected you would need to add a header with a different name, for instance X-Rcpt-To, before the rule with the forward action.

/Rolf

Thank you!

Stefan. 

You can't with an SMTP transaction filter as it is the From: address in the message body.

The SMTP MAIL FROM that you are checking with your rule is <> as reported in the Return-path: header

From transflt.mer:

[quote]# "operation" can be:
#
#    'H' for an expression applied to the client's "HELO" greeting
#    'D' for deferred HELO processing; these filters will only be
#        applied if the client does not issue a successful AUTH after
#        issuing HELO but before issuing any other command. Otherwise,
#        these filters are the same as 'H' filters. They allow a user
#        on a system that might otherwise be rejected to redeem the
#        connection by authenticating his identity.
#    'S' for an expression applied to the subject line of the message
#    'R' for an expression applied to each SMTP RCPT command
#    'M' for an expression applied to the SMTP MAIL FROM: command[/quote]

You can use a general filter rule during Core Processing to match the From: address in the body and delete it.

Thank you for the reply. I did have debug logging enabled in SpamHalter while I was troubleshooting the problem and it was enabled on the configuration page.

I was able to trick the program into operating once or twice which proved it was alive, but nothing further. I've removed it from the system and moved on to other issues.

Thanks again for the suggestions.

If that was real authentication data please change it ASAP!

/Rolf 

When Outlook and Exchange communicate they use a proprietary (and complex) MS-RPC based messaging protocol (unless you set them up to use IMAP or POP3, losing all the advanced capabilities of both). RPC does not work well across firewalls, that's why now Outlook supports RPC over HTTP. Basically, it tunnels the proprietary RPC communication inside HTTP, to allow for using Outlook outside the firewall without the need of using a VPN to contact the Exchange server. There is now way you can use it with Mercury, it is a standard SMTP/IMAP/POP server, it doesn't "speak" Exchange protocol.

I'm confused that it appears to be talking to the AVG anti-virus POP3 server but then, when it fails, the sign-off comes back as being from the Exchange server. Have you tried disabling the AVG POP3 server while testing?

Could be a hardware issue or a network connection issue, but is more likely to have something to do with the IMAP client. I regularly access big IMAP folders (>10000 messages) on Mercury using Eudora, and even though it will take a minute or two to get everything synchronized there are no huge delays. Try it with some other client software to find out if the result will be different.

It might be a good idea to make sure there is no real-time antivirus software active on the Mercury mailbox folders as well.

/Rolf

There's more than way to access mail remotely, and others may have additional suggestions.  You can use a webmail application such as Squirrel Mail, installed on the Mercury server machine and then access mail through a web GUI.  Alternatively, you could set up an encrypted VPN, such as OpenVPN.  The latter allows users to appear as part of the LAN where Mercury resides.  I routinely use both of these options.  You can, of course, also set up Mercury to provide POP3 or IMAP4 service to your users directly.  I personally prefer going the encrypted VPN route, particularly for use from hotel and other public access points.

So far as keeping a copy of all mail, the easiest way to do this, centrally, is to set up the IMAP server in Mercury and have users access their mail via IMAP rather than POP.  That way all mail can reside on the server and you can just back up the server machine (or just the Mercury directory tree) and you don't need to worry about laptop failure (or theft .... not keeping mail on the laptop is a plus in this respect .... unless you want to synchronize the laptops with the server for off-line use).

Gordon

> Since  yesterday I have actually (for whatever reason) managed to
> turn it off when I restarted the server once again. Nonetheless, I
> still have a problem. When I turn session logging on (because I need
> more information than I can find in the normal logs), the session
> log file immediately has some 40 MB and starts in May 2009. Do you
> know the reason for that?

Huh?  Are  you saying there is a 40 MByte *.MS created immediately when this is checked without anything going through MercuryS??

 Was the directory empty before you started session logging.

Nobody seemed to have an answer for me to my question, so I have done some tests and found out what happens.  It seems that wild-cards (*) will work generally using the /MATCH function in distribution lists, not just in the domain part of the address as implied by the Help file.  Thus all of the following will match /MATCH j*h*smith@*:

johanne_smith@address.com

joshsmith@joshmail.com

I was interested in this to provide a partial solution to avoiding SPAM blocking when wanted correspondents change ISPs and very often retain their username (local-part).  Not a 100% solution, but still useful.

Gordon

I created a new user in Mercury, logged into the new mailbox using

Pmail and sending a test mail. The Mail file is created in the Mercury

queue folder, but the sender adress is not complete. Only the Mercury

user name is used and the initial letter of the first name is missing.

All other users can send mail with the initial letter, only the new one can not.

The e-mail address of the user is "personal Name" <username@domain> unless you are using synonyms.  Personally though I use the "~o" <~r> in the MERCURY User Defined Gateway to create a e-mail address using "Personal Name" <Reply to: address> so the user can specify the e-mail address to be used.

[quote user="khk"]temp is empty and scratch contains only old files...[/quote]

From the Help section on configuring the queue:

[quote]Configuring Mercury's mail queues

Mercury stores mail messages it is processing in directories called Queues. All Mercury systems must have at least one queue, called the Primary Queue
, which is where jobs reside as they transit the system. The primary queue should always be located on a drive local to the machine where Mercury is running if at all possible. If you place the primary queue on a remote system, and the connection to the remote system becomes unavailable, mail may be lost or damaged.
[/quote]

MercuryD won't deliver duplicates of the same message to a mailbox because of extra headers in the message. You may have some filtering or forwarding rules on your server that causes it, though. Try having a look at the log files, it's really the best way to find out exactly what is happening.

/Rolf  

Hi Rolf,

Thanks for your input !

I've tried shortening "program files" to "progra~1" which works fine in other sections of Mercury.
I did also try putting the path between " " and eventually just placing it in the root, e.g. D:\MyTemplate.MER

//Magnus

Hi

Not sure if this will be of interest to any one  [:S]

Using Alkit VNC (http://w2.alkit.se/avnc/) it's possible to share just the Mercury32 Window via VNC.

This allows you to view and interact with the GUI via a VNC Viewer (I've tried Linux & Win) or a Web Browser.

Seems to work well, with a couple of little issues.
1: Mercury32 must be running full screen on the remote PC

2: The Mercury top tool bar is missing from the remote viewer.
(but you can still click at the top and get the drop down menus. !!)

3: Via the Web Browser the mouse seems slightly out..  You have to click a little lower that you would normally.

Not to sure if anyone will try this but though I'd post it anyway !!

Anyone have a better solution that will work on Win & Linux, please post details.

Regards