We strongly recommend always using UNC paths for multi-user setups rather than using drive mappings (and of course local drive mappings won't work remotely either ;-).  You never know when a network drive letter will fail to map at login or somehow become messed up.

<P>Hi</P> <P>We are suddenly experiencing a strange problem. Last night I used VPN/Remote Desktop to access the server on which Mercury is installed. I had experienced a problem with IMAP accessing my mail account and looking through the Mercury settings Configuration>Pegasus Mail... I noticed that the field 'Directory to Pegasus Mail .exe file' was empty and typed in the local path to the winpm-32.exe. I did not realise that this was always empty.</P> <P>This morning at work, the three trial machines which access Pegasus Mail via a shortcut to the pmail installation on the server (<A href="file://server/share/winpm-32.exe" mce_href="file://server/share/winpm-32.exe">\\server\share\winpm-32.exe</A>) are unable to send mail. All the other PC's which use a local installation of Pegasus Mail (C:\PMAIL\winpm-32.exe) can send mail without a problem.</P> <P>I have tried changing the 'Directory to Pegasus Mail...' to <A href="file://server/share/" mce_href="file://server/share/">\\server\share\</A> but mail is still not being sent.</P> <P>pconfig.exe on the server shows the following:</P> <P>Standalone configuration:</P> <P>  Home mailbox :    [\\ORION\PMAIL\~8                     ]  New mailbox  :     <A href="file://orion/PMAIL/~8" mce_href="file://orion/PMAIL/~8">\\ORION\PMAIL\~8</A>  Asynch gateway? :  Y</P> <P>and the UDG:</P> <P>               Gateway name : [MERCURY         ]             *New mail path :     Is ↑ a program to run? :  N      *New mail search mask :        *Outgoing mail path :  E:\MERCURY\QUEUE     *Run for outgoing mail :           *Filename format :  ~d~d.101    Run to validate address :      *Reply address format :  "~p" <<A href="mailto:~L~L~8@apsarchaeology.co.uk" mce_href="mailto:~L~L~8@apsarchaeology.co.uk">~L~L~8@apsarchaeology.co.uk</A>>    Accepts SMTP addresses? :  Y    Simple message headers? :  'Glue' headers      UUEncode attachments? :  Y            Burst messages? :  N    Gateway processes BCC? : N        Strip gateway name? :  Y    Force all mail through? :  N </P> <P>I configured Pegasus Mail to keep a record of messages sent in the syslog.pm file:</P> <P>08-03-05 11:40 M <A href="mailto:greenman@gmail.com" mce_href="mailto:greenman@gmail.com">greenman@gmail.com</A> test - 0 <Default> NNYNNY</P> <P>And according to the System Messages window the mail was sent:</P> <P>Wed, 11:40:05 Message sent to <A href="mailto:'greenman@gmail.com'" mce_href="mailto:'greenman@gmail.com'">'greenman@gmail.com'</A>, 'test'</P> <P>However, there is no evidence that this reaches Mercury. Nothing is logged in the Mercury SMTP Client (end to end version), and no log file is produced that shows any mail to that address was sent. Session logging for the MercuryE module is permanently enabled.</P> <P>Does anyone have any suggestions as to what may be happening here please and how I can fix this? I am not convinced that verifying the path to the executable has caused this behaviour, so I wonder if there is anything else that may upset things.</P> <P>Thanks</P> <P mce_keep="true"> </P> <P>p.s.</P> <P>The IMAP problem was caused by a copy of my Pegasus Mail account still being open on a work machine. I used the same remote desktop connection to close it, and then could access my mail on my home PC.</P> <P mce_keep="true">Edit:</P> <P mce_keep="true">I fixed it.</P> <P mce_keep="true">Looking at my post I realised that the Outgoing Mail Path in the UDG was local (E:\...). So, verifying the path to the Winpm-32.exe file (which had not been done since Pegasus Mail was installed on this sever a few weeks ago), seems to have forced the clients to re-read the UDG. Why they were able to send mail before this is a mystery.</P> <P mce_keep="true">Using the DFS root convention to point to the gateway (<A href="file://htlincs.local/IT/Mercury">\\htlincs.local\IT\Mercury</A>), enabled the clients using the shortcut to Pegsasus installed on the server to send mail again. So - after updating the path to the exe file, the clients were looking for E:\...\mercury which is why they failed.</P> <P mce_keep="true">Amazing.</P>