When I create a message and push the send button I get the hour glass for a few seconds and then nothing happens. The message stays on my screen and when I look in Mercury nothing is happening. Any ideas of what I did wrong in setup?
When I create a message and push the send button I get the hour glassfor a few seconds and then nothing happens. The message stays on my
screen and when I look in Mercury nothing is happening. Any ideas of
what I did wrong in setup?
Generally this means that you are using a mail queue and the path to the queue is incorrect. Are you using Mercury? Did you setup a queue? Did you use the UNC format for the path to the queue so that the remote users are looking at the correct drive?
As far as I know I am. I am not using a local client, rather the shortcut to the Pmail program.
This is set in the pconfig under defined gateways right? I have it as C:\Mercury\Queue. The queue file is shared with domain user access at "read and write". In Pmail I have also tried having the "Internet Mail Options/Sending SMTP" pointing directly to the gateway and to the mail server but no success. Is there somewhere else I should be looking? This was working two days ago but I don't have a clue of what I changed. Could wrong permissions on any of these folders be messing me up? I'm ready to dump this and reinstall seeing it worked the first time I installed it. [:@]
[quote user="cynist"]
I have it as C:\Mercury\Queue.
[/quote]
This will point at the local drive on the workstation running Pegasus, not the shared queue on the server.
You need to use a UNC path like \\servername\queuesharename
[quote user="cynist"]As far as I know I am. I am not using a local client, rather the shortcut to the Pmail program.This is set in the pconfig under defined gateways right? I have it as C:\Mercury\Queue. The queue file is shared with domain user access at "read and write". In Pmail I have also tried having the "Internet Mail Options/Sending SMTP" pointing directly to the gateway and to the mail server but no success. Is there somewhere else I should be looking? This was working two days ago but I don't have a clue of what I changed.
If running from a remote system the client will be trying to find the queue on the local c: drive. This queue should be specified usign \\server\share_name\mercury\queue so that the remote systems will look at the server for the queue. If you are running in the same system as Mercury/32 then this means the user must have at least create write rights to the queue directory.
Could wrong permissions on any of these folders be messing me up? I'm ready to dump this and reinstall seeing it worked the first time I installed it. [:@]
The dump and re-install will not help all that much.
[/quote]
OK, so with your help I just figured out what I was doing wrong. I shared the queue but not the Mercury folder above it. Once I reread your instructions I realized I wasn't going from the host name directly to the share. I was using host name/unshared folder/shared queue folder/. Once I took out the unshared folder it worked. The messages were sent to the queue. I see them there but they're just sitting there and not getting sent?
Mercury is running on the server?
The queue is correctly specified in Mercury core config?
You have restarted Mercury after any changes to this?
Mercury is running on the server?
Yes
The queue is correctly specified in Mercury core config?
C:/Mercury/Queue/
You have restarted Mercury after any changes to this?
Yes
[quote user="cynist"]
The queue is correctly specified in Mercury core config?
C:/Mercury/Queue/
[/quote]
Maybe C:\Mercury\Queue\ ?
This was the original default setting when it worked a few days ago and I haven't changed the location of the Queue. I'll look at it again tomorrow morning. My head hurts now.
Thanks for your help.
[quote user="cynist"]
Mercury is running on the server?
Yes
But are you running pmail from the same system as Mercury/32 or on a different system?
The queue is correctly specified in Mercury core config?
C:/Mercury/Queue/
Definitely should not have the trailing / and I would use c:\mercury\queue anyway since this is a Windows system. If there are any remote users though (users on different systems the lan sending to the queue) this will not work. The remote systems will be looking to c:\mercury\queue on their local hard drive and will not find it. This really should be specified using UNC format.
You have restarted Mercury after any changes to this?
Yes
[/quote]
Both Mercury and Pmail are running on the same machine. The pconfig gateway is pointing to \\Server\QUEUE (shared file). If I log into any of the mailboxes they can all send mail to the queue with no problem. But, the mail just sits there in the queue and Mercury does not know there is anything in the queue. Even non-SMTP mailbox to mailbox doesn't send to each other. In the mercury core config queue location I have c:\mercury\queue. I've also tried \\Server\QUEUE (the same as in Pmail). But neither worked. It definately sounds like a Mercury config problem. Is there anywhere else I should be checking settings at other than pmail gateway and merc core config mail queue tab?
[quote user="cynist"]Both Mercury and Pmail are running on the same machine. The pconfig gateway is pointing to \\Server\QUEUE (shared file). If I log into any of the mailboxes they can all send mail to the queue with no problem. But, the mail just sits there in the queue and Mercury does not know there is anything in the queue.What specifically does \\server\queue point to if not c:\mercury\queue. This is supposed to be pointing at a directory where both Mercury and PMail can use. PMail puts a *.101 file in the queue directory and Mercury picks up the file and processes it.
Even non-SMTP mailbox to mailbox doesn't send to each other.Strange, this is where the users are sending mail directly to other users and Mercury and the queue is not involved at all when you use a simple username email address. In this case the program will be depositing an *.CNM file directly into the other users mail directory. Again though the user mail box path as specified in PMail must be \\server\volume\path if PMail is being run from any remote system. Could you show use the Help | About Pegasus Mail | Info for a user.
In the mercury core config queue location I have c:\mercury\queue. I've also tried \\Server\QUEUE (the same as in Pmail). But neither worked. It definately sounds like a Mercury config problem. Is there anywhere else I should be checking settings at other than pmail gateway and merc core config mail queue tab?Nope but they all need to be pointing at the same location. I'm not at all sure were are communicating all that well. If there are no people running the program via a shortcut from a remote system then the simple c:\mercury\queue will work. In the same way a c:\mercury\mail\~n will work for the PMail mailbox location as long as all the users only use the server to run the program. I do not mean a system connected to the server, they are setting at the server console and running the program. If they are running the program from a remote location then you must be using something that ensure that they point to the server for the queue and the mailboxes.
[/quote]
What specifically does \\server\queue point to if not
c:\mercury\queue. This is supposed to be pointing at a directory where
both Mercury and PMail can use. PMail puts a *.101 file in the queue
directory and Mercury picks up the file and processes it.
Everything is currently pointing to \\n\c:\mercury\queue. It originally was pointing to c:\mercury\queue. Neither have worked so far. Both the Mercury and PMail can access this directory. (Although Mercury is acting as if it can't) Both programs are on the same box. I do have some *.101 files in the queue but they just sit there. When I email someone within PMail the message will go through. But if I log in as that user and try to reply to my original message it doesn't go through. The message just sits in the queue as a .101 file and not a .CNM.
Could you show use the Help | About Pegasus Mail | Info for a user.
I'm not sure what you are asking. I did go to this area on the website and am currently reading through it.
If they are running the program from a remote location then you must be
using something that ensure that they point to the server for the queue
and the mailboxes.
Yes, everyone will be running Pmail remotely from their office pc and not directly logging onto the server. I am using \\n\c:\mercury\queue as the path.
I found out why the common user name reply mail was not going through. When replying to my original message PMail placed my full internet mail name in the reply and not just the common name. Do I need to make aliases that match my internet email address to my common name? Still, I can't get the .101 SMTP mail to send.
Holy Crap! I got it to work. [:D] I had to go into the PMail settings on Mercury and adjust the "Directory for PMail File" & "Mail Submission Queue". This is what it was looking for:
\\N\PMAIL\PROGRAMS
\\N\QUEUE
I didn't need the drive letter because both of these files are shared. One thing I did notice is that Mercury did not act on the old stuck mail. Only the new submittions. Is there any reason why?
[quote user="cynist"]Holy Crap! I got it to work. [:D] I had to go into the PMail settings on Mercury and adjust the "Directory for PMail File" & "Mail Submission Queue". This is what it was looking for:
\\N\PMAIL\PROGRAMS
This should be a one time setting to create the MERCURY UDG . You can manage this with pconfig.exe from the PMail program directory. Here's what it looks like by default when you use UNC mapping in Mercury/32.
Gateway name : MERCURY
*New mail path :
Is ? a program to run? : N
*New mail search mask :
*Outgoing mail path : \\thomas\maxtor\MERCURY\QUEUE
*Run for outgoing mail :
*Filename format : ~d~d.101
Run to validate address :
*Reply address format : ["~p" <~L~L~N@tstephenson.com> ]
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? : Y
THOMAS is the server name and MAXTOR is the share name.
\\N\QUEUE
Not sure what N is here but if it works for you then it's good.
I didn't need the drive letter because both of these files are shared.
Files or directories?
One thing I did notice is that Mercury did not act on the old stuck mail. Only the new submittions. Is there any reason why?
Probably does not see the old stuff until the program is restarted.[/quote]
\\N\QUEUE
N = Server Name
Queue = Shared Sub-directory Name
Sorry, I ment directories but wrote the term files. Queue is actually a sub-directory of Mercury. [:$]
Your previous draft for topic is pending
If you continue, your previous draft will be discarded.