Brackets are for numerical addresses only. 

It might be possible to break a loop by adding a header and having a global rule look for it, but it's of course better to avoid creating the loop in the first place. Check console or logs to see if the looping message actually is sent out by MercuryE or if it loops locally on the Mercury server. Unless the MX record for mydomain.de points to IP 11.22.33.44 there shouldn't be a loop.

I've tested forwarding messages from Mercury to another Mercury server and to a common webmail provider, and in both cases the TO: header is unchanged and the original recipient address is shown in the client. It could be that the server program used for your German MTA behaves differently though.

The rule you describe should work assuming that the message actually had a TO: header containing user123@mydomain.de. It would miss on header CC: unless that was selected too (an would definitely miss on BCC as that isn't a header). Try using action Log a console message when testing if a rule triggers or not.

I dont run real time antivirus

You're missing a few special issues with Win here:
The limited user as itself is not the problem but the way the software is started as a limited user.
Runas != normal program start as user. If you login as that user and then start the program should work OK (can't test as I have no console access and don't want to add mercury user to various groups).

Also the switch /env changes the environment to be used to "to use current environment instead of user's." Thus the Admins Temp dir for writing temporary files (*this* behavior will have changed from 4.7.4 to 4.8: in 4.7.4 mercury.ini was written directly to, now it behaves as if a temp file is created and moved.)

 Also your conclusion is wrong as  the command that reproduces the error actually *is* issued from C:\Mercury ("cd C:\Mercury").

Sorry but that's how it is over here.

Right, existing licenses are good for all v4 releases of Mercury!

There are actually a few important fixes in v4.80 final, so I would recommend to update. 

In case you didn't already see this: 

http://community.pmail.com/forums/thread/44354.aspx

As far as I can see membership files are not automatically deleted when a mailing list is removed.

Install the latest version of Mercury with default settings and modify only those settings that must be changed. It's important to define host name for the server and local domains correctly, so please read the information in the installer carefully, and check Mercury help or the PDF manual for additional information. It's actually a good idea to spend some time reading relevant parts of the manual. 

After installation you can create accounts for your users. Your firewall will need to allow access to at least port 25 (SMTP) and port 143 (IMAP). If you want the server to be reachable from the Internet you will need to forward those ports from the device that connects to the Internet (modem/router/firewall) to the server that is running Mercury.

[quote user="Rolf Lindby"]

There are a number of different ways to time sort email messages, so there isn't a single correct way to do it. The basic IMAP protocol doesn't include sorting, but there is an extension that allows it. At this time IMAP SORT isn't available in Mercury though, so it's up to the client to perform all sorting. 

[/quote]

Unfortunately our webmai client does not support sorting: it simply list on user's webpage all mail messages as they are received.

I thought that message's filenames was appended in the "_INBOX_.PNM" file neatly one after the other, and i was surprised to find all mixed.

ALex. 

Right, as Brian confirmed too, Windows 7 will handle all TCP/IP connections the same way as a server OS would, including email protocols. The difference is the number of connections to Windows resources (like file shares), and various server functionality like AD, IIS and DNS.

Found the problem!  I had a trailing comma in the Clamwall banned extension list which apparently tells Clamwall to ban any file without an extension.  Removing the comma allows files without extensions to pass.

As empty HELO greetings aren't RFC compliant we will probably have Mercury reject them by default in v5. Thanks for pointing this out!

I that you are having such problems and that you missed the setting in the POP3 host configuration that controls deletion of messages on the server.  Recovery may be possible if you can create an IMAP connection to your hosted mailbox then copy the messages to the IMAP connected new mail folder.  This will put them back on the server.

For additional help start a new thread on the Pegasus Mail forum with a description of what has happened and the specifics you need help with.

Hi,

I'm not shure about what you are doing.

You have some groups created on Netware?

You want to send mails to those groups so that they will be distributed to the members?

Then you have to create a "groupsalias" (public name) in Mercury Core Module pointing to each group in Netware you want to use for maildistribution. With bindery module loaded in Mercury you simply enter the groupname, with NDS Module the full distinguished name (.groupname.ou.o).

If a Netware group has no public name in Mercury poiting to it, Mercury should not recognize it and send no mails to the members. That's how it works for me for many years.

bye    Olaf

With all your help I am getting there. I went through all again and really it turned out to be a mistake in the UNC path. there was a little "l" missing for the drive on the server where mercury and pmail reside, which obviously goes away if you map drives.

Sending is working all well now, after I updated the gateway via pconfig with the right information.

Now I learned as well that I have to create a fsynonym database, as this was handled by netware in my case... 

 :-), Thanks again to everybody who looked into it,

Dieter

Rather than confuse the OP the answer is that you can either configure a new mailbox(User) account or use an existing one.

The protocol IMAP has no feature translating mailaddresses! It's something like a filesystem for your mailbox.

To solve that problem, you have to avoid users from using Netware usernames for addressing. There is no other way to solve it.

The way I've gone years ago is to install a SMTP-Configuration for my Pegasus users. If in place, two things happen. The module SMTPS in Mercury shows up on such a mail:

Connection from 129.217.xxx.xxx, Tue Jul 21 07:39:10 2015
EHLO xxx.xxx.tu-dortmund.de
STARTTLS
EHLO xxx.xxx.tu-dortmund.de
MAIL FROM:<xxx.xxx@xxx.tu-dortmund.de> SIZE=1840
RCPT TO:<netwareuser>
QUIT

Seems normal, but SMTPS denies receipt (the protocol entry DATA is missing, which indicates SMTPS to accept the mail) and Pegasus produces an internal errormessage including the line:

553 Invalid RFC821 mailbox specification.

 So your local users can't send with netware usernames any more.

bye   Olaf

[quote user="PaulW"][quote user="Greenman"][quote user="Rolf Lindby"]

The way I understood it the message arrived from an external distribution list to local user A, was forwarded using Pegasus Mail to local user B, resulting in the forwarded message being killed by Mercury, but that was maybe not actually the case?

[/quote]

You are almost right. The external message was addressed to local user A who forwarded it via a distribution list to several local users B, C, D, E etc.

However, the original message was delivered by Mercury without being 'killed'.[/quote]

Is this just happening to one user or several?  And how is it being forwarded - bounce or fwd with edit?

[/quote]

They tried it with forward as edit, and forward as attachment. Did not use the bounce option as they needed to introduce the message.

RE:  TRANSFLT,MER:  No transaction filtering.  I checked the file with a text editor confirming that all lines are commented out.

I originally installed Mercury with the sole purpose of running it with POPFile to keep the crap out of the users mailboxes.  I created a large number of global filters to auto-delete known unwanted messages (vulgar terms, male enhancement, viagra,...) as well as rules that manipulated messages (copied, forwarded, deleted attachments, added text fragments).  The second instance was the result of me never being able to exclude outgoing messages from global rule filtering.  It worked well so I never revisited the issue.

The occasional outgoing messages that are being copied to the postmaster mailbox appear to be just flukes.  I searched 6 months worth of logs and only find the two messages that prompted this post, and they occurred months apart.  Whatever is causing it appears harmless and is so rare that it is not worth any more effort.

Thanks for your thoughts.

I confirmed it last night and have since suggested that the user enable the delivery confirmation on a per message/as needed basis.

Hi PaulW,

Thanks for the reply.  No, they got sent after a few minutes.  I was just being impatient, and wanted to know if I could force them somehow.  It sounds like that isn't an option, and you just have to wait.  I even tried exiting and restarting the server, but that didn't force them either.