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.

After going through a few more of these I have noted that our older email accounts have extra sections which are left-over from when we were using dial-up about 15 or 16 years ago:

[Pegasus Mail for Windows - Run Info]
Program version                  = Version 4.70 (Win32), Feb 27 2014
Language resources               = Standard UK English resource set
Time and date run ended          = Wed, 18 Mar 2015 12:37:57
Running in standalone mode?      = Y
Internal username                = mark
Working home mailbox location    = \\ORION\PMAIL\greenman
New mailbox location             = \\ORION\PMAIL\greenman
LAN-based SMTP gateway status    = Disabled, not preferred, not 'use always'.
MHS status                       = Disabled, not preferred, not 'use always'.
MHS directory path               = /
MHS operating mode               = SMF-70

[Pegasus Mail for Windows - built-in TCP/IP Mail]
Host where POP3 mail account is located   =
POP3 mail account (username on host)      =
V3 Password for POP3 mail account         = SEED$23843:""
Delete downloaded mail from host          = Y
Largest message size to retrieve          = 0
Directory to place incoming POP3 mail     = \\HTL-SERVER\PMAIL\greenman
Transport control word                    = 65792
SMTP relay host for outgoing mail         =
Search mask to locate outgoing messages   = \\HTL-SERVER\PMAIL\greenman\*.PMX
Alternative From: field for message       =
TCP/IP timeout value (seconds)            = 30

Can anyone help with the following, please? 

The mailbox locations under [Pegasus Mail for Windows - Run Info] will be changed to the new server location. I will edit these with the new path and new account name.

Can I take it that the POP3 information in the [Pegasus Mail for Windows - built-in TCP/IP Mail] section is for Pegasus Mail only and that Mercury will ignore this? Does mercury completely ignore pmail.ini anyway? Mercury will be handling the POP3 retrieval of mail from \\Orion to the new server. The existing path in this section is many years out of date. Do I need to delete it or can I ignore it?

Again, if anyone can confirm or correct me I would be grateful.

Thanks.

I looked at the .ini file of four mailboxes here and only one has a [Pegasus Mail for Windows - built-in TCP/IP Mail] section.  The info in it is extremely old so I suspect it was from pre-Mercury days and was the likely the only mailbox used when I installed Mercury.  It is possible that this mailbox goes back to the v3.12 days.  Out of curiosity I enabled an SMTP host for that user just to see if the section would change and it did not.  My take is that the section is not needed but is harmless.  Mercury definitely does not use it.

I don't believe Mercury has any reliance on the pmail.ini file but can't say for certain.  One thing I feel certain about is that sending and retrieving of mail by Mercury has no reliance on any info from pmail.ini. 

Thanks very much for doing that, Brian, I appreciate it.

I thought this was the case but it is better to ask :)

I wonder if it is necessary to edit the ini file at all - I have run Pegasus Mail's pconfig to setup the mail gateway, and Mercury knows the path to folders. While I can leave the ini file as it is and test this with one account I don't know if there may be any 'hidden' issues that might become serious at a later date. I'm quite happy to edit the ini file but I'd prefer not to do it if it is not required.

Thanks

Pegasus relies on the .ini file for mailbox location so you need to edit those in the [Pegasus Mail for Windows - Run Info] section if needed but I think that is all.   The [Pegasus Mail for Windows - built-in TCP/IP Mail] section appears left over from days gone by so I think it is safe to ignore.  Definitely test one instance to see how it goes.

As for hidden issue that might arise it the future, perhaps if run freestanding although I have used mine to test smtp servers and imap profiles without problems.

Sorry - I forgot to mention that Pegasus Mail is run from a central location - no stand-alone installations at all.

Mine is as well but I can still configure and use a local mailer (smtp) and expect I could do the same with POP3 since the paths to the mailboxes should be valid.  I have never tried it so am not certain. 

Anyone out there know whether both Mercury and a Pegasus Mail configured POP3 host can feed the same mailbox?  I don't see any reason to do this but I am curious whether it is possible.

Looking again at the config I've posted above I see that Standalone is configured as Y

?? I don't understand that, unless it's a leftover from when it used to be a standalone installation. But, I guess Pegasus Mail wouldn't know whether it was running in standalone mode or via a network share - as far as it is concerned it just 'runs'. Unless, of course, I don't understand what is meant by standalone??

Mine says standalone as well so it is nothing to worry about.  As for a definition of "standalone" in this instance... I have no idea. 

This is working fine on the test account, but I was just checking the pmail.ini file and it has reverted to using the path name from the server the data was originally stored on.

Although it is working this is due to go live in a couple of weeks time and I really don't want any nasty surprises. Does anyone know what may be causing this? When I installed Pegasus Mail I ran the pconfig.exe on a 32bit machine and set the gateway etc for the new server. Is there something else that is being referenced from the files that were copied over?

[Edit]
It has also reverted to using the original internal username.

Pmail first looks to the PMAIL.CFG file for paths to the mailboxes which explains why it is working fine.  My understanding is that you have copied the entire mailbox content from the old server to the new one and run PCONFIG.  This generated the PMAIL.CFG file but would not have done anything to the .ini file.  I am pretty certain that the mailbox addresses in the .ini are ignored when a PMAIL.CFG file is in place but I would manually edit them anyway. 

As for the internal username being the old one, I don't know how this fits into the picture. The ~n or ~8 used in the mailbox path configured in PCONFIG is a substitution variable for the username which I assume is the one provided either via the shortcut switch or keyed in at Pegasus Mail startup.  So the question that remains is what the purpose is of the internal username.  If I were you I would manually edit that as well.  Backup and test (I know I don't need to say it but feel I must anyway).

Edit:  It just dawned on me that there may be other places in the .ini file where the internal username is referenced.

Thanks again, Brian

Here's what has happened:

Our present setup works fine with one 2008 server sending and receiving for two domains.

I installed a 2012 server and installed Pegasus. After installation I deleted pmail.cfg and ran winpm-32.exe and set up Pegasus for a Windows multi-user environment. I copied the program folder to a 32 bit server and ran pconfig.exe and setup the gateway, then copied the program folder back to the 2012 server.

Next I installed Mercury on the 2012 server and configured it for the new domain. I used Mercury to create new user accounts on the 2012 server for the new domain name. They are named after the original accounts but have -hl appended to them. These same *-hl accounts have also been created on the 2008 server. I then copied one of my accounts folders from the 2008 server to the 2012 server. I edited pmail.ini so that all paths to the 2008 server were replaced with the correct UNC paths to the 2012 server and to the new account name and it's folder.

Thus \\orion\pmail\greenman on the 2008 server account's pmail.ini becomes \\janus\hl-pmail\mail\greenman-hl on the 2012 server. This works fine.

When I open the new account and click Help > Info it shows the correct \\janus\... path and I can send and receive email under the new domain name.

I have global filtering rules in place on the 2008 server which forward mail sent to the old account 'greenman' to the new account named 'greenman-hl' on the same server. POP3 on the 2012 server polls the 'greenman-hl' server on the 2008 machine and copies new mail to the 'greenman-hl' account on the 2012 server.

I wonder if I have anything to worry about. I was just surprised to see the path and the internal username revert to their original settings as they exist on the 2008 server. Although this change has taken place it has not affected basic operation of Pegasus Mail. I use Group Policy Preferences to push out the PMR and PML environment settings to all client machines and these point to the 2008 server, and these are working fine when I launch the test account from the 2012 server - Pegasus picks them up and I can browse the address books and distribution lists.

I am concerned that there may be a function which relies on the path setting within the pmail.ini file and which may cause a problem. This is why I was wondering how the settings could have changed.

It would not surprise me if an entry in the .ini got updated from the pmail.cfg file.  If that were the case though, the entry should have been made current when the new pmail.cfg file was referenced.  Can you tell that I'm clueless?

I wish I understood more about any entries in the .ini that are irrelevant when running a shared install.

My thinking is that the paths in the .ini would only be an issue if that .ini was used in a standalone installation.

The cfg was generated on the new server so there is no reference to the old server name.

I am beginning to think the same thing, Brian. It does look as though the program ignores the .ini entries. Perhaps the .cfg info takes precedence over the .ini?

Once again, thanks a lot for taking the time to respond to my queries. I really appreciate your help.

Cheers!

Here's another thing I hope someone may be able to help me with, please.

On our present server 'Orion' we have enabled IMAP access. IMAP connections are controlled through the SMTP_Auth.pw file accessible via MercuryS.

I can see that the SMTP_Auth.pw is a text file located in the Mercury installation folder.

We will be switching IMAP access from the original server 'Orion' to the new server 'Janus'. Because Janus will only be sending mail for the new domain I have only installed the MercuryC SMTP module. Do I also need to install the MercuryS SMTP module in order to edit the SMTP_Auth.pw file or can I simply edit the file using notepad?

Thanks

Isn't IMAP access controlled by the credentials stored in the user list and MercS access controlled by the password file?  I do not have a password file in the instance of Mercury I run that handles IMAP.

FWIW, my password file is named authpswd.txt which I am pretty certain I have edited with Notepad.