Solved.

I set up pmail on another win 7 machine. No problems. So -- not a networking issue as such.

After some faffing, I found that, somehow, and only on the one machine, the shortcut had -roam on the command line! Doh! Remove that -- all is good!!

 Don't know how that got there, I installed with default settings on all, but anyway, good that it's all working!

Thanks Paul, I'll just avoid using the laptop with Thunderbird on anything but the home network until 4.80 is available. From other posts it looks like I could use stunnel but I have enough to do at the moment without learning new software!

Nothing 'normal' about these connections.

The first IP address is in Spamhaus and other DNSBLs so you could block that easily. The second isn't - yet.

Neither are doing anything but filling up your session log.

I suggest to update to the latest version 4.74.

[quote]

Fixes for MercuryI IMAP  MercuryI now

saves UID lists any time they change: this should prevent UID

synchronization problems from occurring, but may introduce small extra

processing delays with very large folders. There have also been some

changes in the way the IMAP SEARCH command is handled that should

improve performance and reliability in a number of search scenarios (in

some cases spectacularly), and MercuryI now caches FETCH data which

should significantly improve performance and reduce load when clients

like Apple Mail fetch messages a chunk at a time.[/quote]

Mercury/32 v4.74 available

Have you enabled session logging in MercuryS? If so, are the internet clients connecting to Mercury and being disconnected, or are they not reaching Mercury?

 If they are reaching Mercury, what is the conversation in the session log?

[quote user="questort"]

23:07:02.562: << 250 Recipient OK - send RCPT or DATA.<cr><lf>

23:07:03.156: 7: NB Socket read error 10054 (connection aborted by remote host)

23:07:03.156: --- Connection closed normally at Mon Sep 15 23:07:03 2014. ---

[/quote]

Sounds like a security mechanism to prevent spamming. The connection is closed after 100 recipients by your ISP. I would get in touch with their support desk and ask whether they could increase this limit. Sometimes you have to pay for it a monthly fee...

Try running the program from a policy and select "This task modifies the raw data of the job it examines":

In some cases, you may wish to allow the external task to modify the actual data in the mail message it examines (for instance, you may want it to add a header to the message). Checking this control tells Mercury to copy the temporary file it creates containing the message's data back into the queue job when policy processing is complete. It is your responsibility to ensure that the policy does not corrupt or damage the message data in this case, and to ensure that the message data remains in legal RFC2822 format. Checking this control will slightly increase the time it takes to process policies on your system. 

Another way to do it would be by using a daemon, but the policy approach is probably easier.

Yes. Shutdown Mercury32 and copy the files back in queue should work. The extension .$$$ is unknown to me. I know only the files listed in . I would take a look in the .$$$ files with Notepad++.

These files seem to be created by Mercury32. Either this is a program fault or the result after moving files in the queue while Mercury32 was running.

A couple of months ago there was a long thread discussing the problem of synonyms not being used by auto-replies.  A solution was found, or so we thought.  The problem was that the From: header in the auto-reply was populated with localusername@domain.com rather than domainusername@domain.com.  It was apparent that the synonym files was ignored by the auto-reply process (triggered by a FORWARD file).  Removing the local user entries from the MercuryD configuration appeared to have solved the problem but the problem is back for me.  The only change I can think of is switching from MercuryC to MercuryE.  Does anyone know if or why this change would affect this behavior?

Edit: I got it working again on auto-replies but not on auto-forwards generated by a FORWARD file.  The emphasis during the previous discussion on this topic was to get the From: header correct in the auto-replies.  I don't recall that the Resent-from: header in auto-forwards was given much attention so it may have never worked.  It is of low importance so I consider this problem fixed.

The [MercuryE] section in my Mercury.ini file was completely missing....  I inserted the section and now it appears to be working.

Thanks Rolf 

A 32 bit version of fsynonym.exe is included with the upcoming v4.80 of Mercury. You can download it separately here: http://downloads.serieguide.se/fsynonym.exe

A FORWARD file can contain as many Forward-To lines as you like. There should only be one Deliver-Also line, though.

Alternatively you could create a mailing list and use that to distribute messages to a group of recipients, or you could point an alias to a rule set that copies the message to various local accounts. 

I haven't tested the MXREDIR daemon myself, but I believe the files still can be found here: http://fenke.home.xs4all.nl/files/

I will have to see if I have any record of the original change I made, I think it may have been a line in Mercury.ini but I have not found it yet.

The odd thisng is that all the settings in the user's Pegasus appear to be correct.

I tried catching one but was unable to because they passed through so quickly.  I didn't think to stop Core.  Thanks for the suggestion. 

I think I have my original problem solved but I may play with this just out of curiosity.

im also having this problem

Thanks for all your help - I did get what I needed using MercuryC after renaming Mercury Mail local domain.

@Rolf

I believe in order to get MercuryE working using options 1 or 2 to work I need to make adjustments to the accepting exchange server so at this time I am just going to use MercuryC.

@jbanks

Thanks for all the info on making adjustments to the exchange server end. On the DNS our server at 192.168.0.2 is also our SBS 2011 running our DNS and exchange server so the DNS so it should already be setup to point to the exchange server. The on thing I wanted to avoid if possible was having to make per user changes as I did not what to go into each current and future user settings and make custom settings. I do like having the information in case I would need it in the future as you never know what kinds of setup they may ask for in the future.

As always I gained a lot knowledge from all the help here.

Thanks again, Ron

I used the cert generated by Mercury.  I didn't check the date, I sort of assumed it would be valid or report a useful error if it wasn't.  I'll check.

CA Cert, 1024-bit RSA, valid until 2034.  Re-enabling it didn't work, but creating a new cert and enabling SSL seems to have been successful.

So yeah!  If the cert gets moldy or whatever, Mercury just stops functioning.  Good to know.  =D

Thanks for the clue, Olaf.

BTW: 4.80beta16 provided by Rolf Lindby has resolved all SSL issues here. Works like a charm for 4 weeks now.

 Thanks!

[quote user="Rolf Lindby"]

Maybe some strange IPv4 / IPv6 issue? Again, would you consider trying v4.80 and see if that makes a difference? If so I can provide a download link for the current beta.

[/quote]

Yes, I'm willing to try the beta, depending on how stable it is - this is my email link to the world after all.