[quote user="Joerg"]1. Is it possible to avoid the permanently expanded view of additional public folder trees when starting Peg? Of course I'm able to collaps (or close - what is the right expression for it?) the public folder tree after the Peg start. But many of our users which are not involved in working with that public folders are annoyed of the permanent expanded additional tree every time they are starting their Peg session.[/quote]

Not that I am aware of.

[quote user="Joerg"]2.  From time to time the names of the single public folders (not the name of the public tree structure but subfolders) are being changed automatically. I tried to turn out why and when Peg do this but without success. E.g. if I named a folder "01 Ship", Peg changed it to e.g. "01 ShipSeed: 29822399". Any ideas?[/quote]

Sorry that I can't help with this either.  I have not experienced it.  I looked in my hierarch.pm for an entry that might provide a clue but there is only an entry for "Public folders", not for the actual folders themselves.

The thought of using directories as added mailboxes popped into my head this morning.  You should be able to feed them from Mercury but I don't know what the sharing ramifications are. 

Hi Guys,

We are using a combined Mercury - Pmail configuration here (both in latest release versions), where only one Pmail installation is available at a network. All users are starting their Pmail session from this network link, of course with their own user mailboxes. So far so good.

In case one user tries to open another user's mailbox, which is currently in use, he gets a warning message that this mailbox is presently blocked.

Now we've got a task where different users have to simultaneously work on one mailbox. Is there a simple solution for?  I thought about starting Pmail in "IMAP mode", because the Mercury IMAP server is also activated and available. But is there a possibility to start Pmail such mode instead of the standard mode?

Or is it better to install an additional email client (e.g. Thunderbird) which is able to access the Mercury Server by IMAP?

Best regards

Joerg

Joerg,

Would public folders work?  I use three here that serve the purpose of being a repository for messages from vendors & sale reps that need to be available to all users.  I manually copy messages to those folders but it looks like filters would work as well.  Below is a quote from the Mercury manual.

Public folder aliases
Mercury's companion mail client, Pegasus Mail, supports the idea of Public Folders - folders
that can be accessed by more than one user at a time. Mercury can deliver mail directly into
Pegasus Mail's public folders in the proper format, ready to read. To allow Mercury to do this,
you need to create an alias for each public folder to which delivery is to be enabled. The alias
type for public folders is PUBLIC:, followed by the full path to the directory. So, if you have
a public folder in P:\PUBLIC\MAIL1, and want any message sent to public1@exam-
ple.com to be delivered automatically into that folder, you would create this alias:
public1@example.com = PUBLIC:p:\public\mail1

Hi Brian,

How does this public folder appear in your mailbox tree? As an additional yellow folder where I'm able to create subfolders or drawers? Or as an additional mailbox? And could different users work at the same time to that folder(s)? What happens e.g. if one user is deleting something therein - is Pmail immediately updating the folder content of the other user who has opened the same public folder?

Greetings

Public folders appear in the folder list as folder in an added mailbox named "Public Folders".  As for the inner workings questions, I use them for message sharing and am the only adding and deleting messages so I don't really know the answers to your questions.  What I do know is that you can reply from them and copy self to them but you can not create subfolders within them.  Their limited functionality may not meet your needs but I wanted to make sure you had given them consideration.

As for IMAP, I have tested and played but have not used it enough to feel like I know much about it.

Brian,

Just testing the public folder idea. Thanks for the hint. Will see wheather it works for us.

Brian,

One problem with public folders.

Firstly I have to create a file system folder e.g. "public1" at the server. In Mercury I have to  create an alias where an ordinary e-mail is linked to that folder e.g. PUBLIC:c:\public1. Then Mercury forwards all mails, retrieved from the e-mail address to that public folder. Clear so far.

Now I'm in Pmail. Here I have to create a new Public Folder Structure. Therefore I select  from menu Extras > Public Folder. Therein I create a new Public Tree Structure which generates a new additional mailbox symbol in my own Pmail folder structure. When creating the new public tree structure I have to define a name and the path to the public folder at the server file system. Now I have a new public mailbox which is connected with the server folder \\server\public1. But this mailbox has no subfolders like an inbox. I could not open anything. That's why I create own subfolders in Pmail within the new public mailbox structure.

And here is the problem:  In Pmail I'm not able to assign the path to the server folder "public1" (which is the inbox for Mercury) to the new Pmail subfolder "inbox" (subfolder of the new public mailbox tree structure). I'm only able to assign a path to the entire new "public tree structure". But I would like to create a Pmail subfolder under the public mailbox "Public1" called "inbox". Any subfolders which are being created by Pmail have cryptical names like MGEZAF7K.MAI at the server. Should I use the cryptical name MGEZAF7K.MAI for the Mercury alias, so that Mercury forwards the retrieved messages to my new inbox?

I hope you understand, what I mean. [:S]

I think I understand what you are trying to accomplish but I don't think you can.  Here is how it work.

On the server you create a directory that will be the container for the public folders.  Mine is \\server\mail\public folders.

Inside of that directory is where the .MAI files reside. 

In Pegasus Mail you can only point to the directory that holds the public folders.  This creates the appearance of an added mailbox in the folder list with all public folders (the .mai files) as subfolders.  The concept of "inbox" does not exist.  It is just a flat list of messages.

As for the .MAI files, if you create a public folder from within Peg you can assign a friendly name so you might way to try that.  I don't feed mine from Mercury and I see where your question comes from because the manual doesn't mention the .MAI files.  It reads like you point to the root public mailbox directory but that does not make any sense since only .MAI files reside in that directory from what I can see.  You are probably going to have to test to see what happens.

Before getting too deep into the Mercury side consider creating a test public folder from withing Peg then copying a bunch of messages into it.  You can then determine whether functionality is acceptable before mucking around on the Mercury side.

Thanks for excellent explanation, Brian. But the automatically delivering of mails by Mercury into a public folder (which is e.g. named inbox) is the main task of what we are looking for. If this is not possible, one user has to check manually this special email account regulary and has to forward new mails to public folders for access by the other users.

I will play arround a little bit tomorrow.

Understood.  I suggested the test public folder only so you could determine whether the limited functions of a public folder would meet your needs.

Good Morning Brian,

I have experienced some new side effects with public folders. Maybe you could bring some light into my darkness.

1. Is it possible to avoid the permanently expanded view of additional public folder trees when starting Peg? Of course I'm able to collaps (or close - what is the right expression for it?) the public folder tree after the Peg start. But many of our users which are not involved in working with that public folders are annoyed of the permanent expanded additional tree every time they are starting their Peg session.

2.  From time to time the names of the single public folders (not the name of the public tree structure but subfolders) are being changed automatically. I tried to turn out why and when Peg do this but without success. E.g. if I named a folder "01 Ship", Peg changed it to e.g. "01 ShipSeed: 29822399". Any ideas?