I did a quick test and it looks like adding a period would solve this problem. For some reason extension detection triggers on contains rather than exact match, so that's why there were false positives in the first place.

[quote user="Brian Fluet"]You say that your MercuryD retrieves two messages from each mailbox which is different from mine which only retrieves one message from each mailbox.  It then delivers to the To: AND to the CC: of the message.  This is the problem that the MSGIDS.MER fixed. Perhaps this is just a matter of semantics.  I am looking at messages retrieved from each mailbox (one) whereas you are looking at messages delivered from each mailbox (two, possibly more if the To and/or CC contain multiple local recipients). [/quote]

I think you are right. Mercury-D retrieves only one mail but because there is no direct local user designated, Mercury checks which local user or users mostly match. Therefore it checks the synonym.mer, too. The mail contains a To: and a Cc: section where both recipients are available as local users. And that's why it delivers to both local mailboxes.

And the same game when connecting to the second ISP mailbox.

On the other hand, when designating a local user for each ISP mailbox in Mercury-D, Mercury knows the local user where the mail has to be delivered to and does not check for any other possible users. That could be the reason for that behaviour.

Thanks for the hint, Brian 

[quote user="PaulW"]Try connecting via IMAP - mixing the access types to the mailbox is going to lead to blocking issues.[/quote]

I confirm this. As already stated above, I'm not able to connect over IMAP when simultaneously Pegasus is still connected to a user mailbox.

Also two simultaneous IMAP sessions to one Peg mailbox don't work. The second IMAP attempt gets an error message back, at least with our IMAP client RoundCube.

Joerg

It is also worth noting that Pegasus Mail will not allow a PMM file to grow larger than 2GB. If you try to add messages to a folder that will take it over 2GB Pegasus Mail displays a notification saying the limit has been reached.

[quote user="Greenman"]

Messages identified as spam are often simply dumped without notification. 

[/quote]

Thanks for the input folks, but it looks like Greenman is on the money.

I took my problem to another forum where reps from the ISP contribute and got a bite.  At the end of my log is: 14:25:07.920: >> 250 ok: Message 330362388 accepted<cr><lf> , and at some point in their log is Thu Apr 30 12:24:57 2015 Info: MID 330362388 using engine: CASE spam positive

I'm now in email communication with an actual person at the ISP and he's currently looking into it, and theorised that "image in signature is a common culprit" which my emails have.  The timing of the spam identification would indicate something within the DATA section of the email too, since my message hadn't even completed sending when it was tripped.

I'll let you know the result, but in any case it's nice to know I'm not crazy.

I need to exclude autoforwards (generated by the FORWARD file) from global rule filtering as they go out.  Does anyone know whether the X-Autoforward: header is created in time to be used in an expression rule to stop processing?   

Thanks, Brian

The rules I have are simple and minimal. I have gone through every rule now and made sure that all the old rules now target the new addresses. I have also moved all the rules that forward messages from 'old address' to 'new address' to the top of the list - well, after the catchall rule that is always triggered first.

I will see how this works.

Cheers!

Its semms working but the mail not come.

Yes - copy the present folder structure to the new server (and keep a backup). 

Why not recreate the same folder structure? That way all your settings will be OK.

If you really do need to change the folder structure you will need to amend the Mail Queue Directory in the Mercury Core Module and also the paths to the Mercury System Files, also in the Mercury Core Module.

You will need to edit the location of other folders/files in MercuryS etc.

Copy the installation across to the new location, put Mercury in Offline Mode then go through each setting and check that all paths are updated.

Or, it may be simpler to carry out a fresh installation.

I think perhaps if you created an SPF record that authorized your ISP to send mail on your behalf you might be ok.  It's at least worth a try.  You could also ask your ISP to try sending them an email to see if it goes through, if not then it is your ISP's problem perhaps. 

Restarted firewall: problem gone.

Thank you very much

Filippo

We have moved Mercury from one Windows Server 2003 (32-bit) to 2008 (32-bit). Nsynonym.exe work there either. It could be related to the Netware Client with Vista/2008.

At the moment we still have a virtual machine with Windows XP where we can run a script to read the users from the NDS. That file SYNONYM.MER is generated and copied to the mail server.
Has anyone found a better solution to this problem?

If Mercury/32 would support Active Directory and Windows Users directories somewhen, this all would no longer be necessary...
Best wishes, Torsten

There is no built-in functionality for this, but it should be possible to create an event daemon that refuses a RCPT if it can connect to the primary MX server for the domain. 

I've done this already few weeks ago. Don't be afraid. It runs properly so far and I'm happy with it. As Rolf said, you could install it without deinstalling your previous version.

Just created an own public folder structure. To avoid that every user is seeing the entire expanded public folder structure every time he starts Peg I have created only one main folder under the public tree head but with a lot of subfolders under the first main folder. This subfolder structure could be collapsed and keeps collapsed also after a restart. This avoids annoying of users which are not involved in working with those public folders.

But the main problem was the automatic new mail delivery of Mercury into one defined subfolder.

When creating the public folder/subfolder structure, Peg creates single file folders at your server file system (or where you've defined the location for saving) in the form folder.mai where the folder naming is always cryptic like S14DQYXS.MAI.

Now I have used one of that cryptic *.mai folder for the definition of the PUBLIC: alias in Mercury. And it works. Also with a deep path (I'm using e.g.: PUBLIC:E:\MERCURY\MAIL\public\public.MAI\S14DQYXS.MAI). Mercury is retrieving emails from our special public internet mail address as usual. But there is no local user defined where Mercury should drop the new mails. Instead of this Mercury has an alias for that address and drops the mails into the defined *.MAI folder.

Of course, you never will get a "new mail" notification. But public mail folders based on another concept other than ordinary mail account.

Uhhhmmm, no I don't use pegasus mail client. I set up my server for family members that live in other states and well, for instance, trying to convince my mom to change to another email client wouldn't turn out pretty *heh*. Another approach I'm looking into is writing my own daemon to modify the message and redirect it. I'm still looking at that trying to figure out how to "run the spam.dat" file first (to get my identifying headers) before i send it to the spam account. I need to look into those POPfile and POPfileD daemons you suggested. I'm still researching, let me know if you have any ideas, Thanx - Gary

I have installed version 4.8beta and have had no stuck emails for 2 weeks. I will say since currently I am only using this to relay some internal emails to another mail server I did not install clamwall, spamhalter or greywall so I don't have the exact same set up as before but at this time things are working as needed so thanks for your help.

Great! This solved the problem, as far as I can see now....

I will review some 24 hours and post if I can see any other effects.

Thank you very much, should have asked long time ago!

Dieter

Ah! Sorry - I'm getting IMAP and authenticated SMTP mixed up.

Staff can connect using IMAP and read their mail, but they cannot send mail when connected unless they authenticate their session. In order for this to work for staff connecting from a remote location I have to supply a password for both the user account under 'Manage User Accounts' and in the SMTP_Auth.pw file. As you say, you can give that file any name. So, reading this again I guess that as the server will be handling incoming requests to relay mail I will, therefore, need to install MercuryS.

[Edit]

It's OK - I think I've got this sorted out now,

Thanks.

Right, that's the preferred way to define what's local to the server. Public IP can be added as well to make it complete.