![Thunderbird logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2024-02-12-07-36-53-599028_1.png)
Advice sought re: configuring Thunderbird as a simple multi-user helpdesk system
I am going to try using Thunderbird with a group of shared IMAP mailboxes as a very simple "helpdesk" system, and am seeking advice on how to make it as robust as possible. The IMAP server is on a Cpanel-based provider (some flavour of Unix, I believe), but I do not yet know the details of the IMAP server.
The overall goal is to allow multiple customer support staff to reply to external customers, in a way that ensures that only one person replies to any given incoming message, and for that person to then be able to continue replying in that conversation, to provide continuity to the customer. Ticket numbers are not desired. All support staff must be able to view all discussions, and be able to take ownership of a discussion, without the current owner having to grant ownership.
There will be approximately 6 users providing support, with typically 2 or 3 active at a time.
The approach that looks like it will work is the following: - to have a shared email address that the customer uses for the initial contact (e.g support@ourcompany.com), using IMAP for this mailbox. - Each user would have their own email address, with IMAP being used for these mailboxes as well. - All mailboxes - the shared one, and the individual user's mailboxes, would be fully accessible to all users. - The "recipient" field would be enabled in all mailbox views. - The support staff would send FROM their own personal email address at all times. I.e, the customer will always be replying directly to the staff, for ongoing discussions. The only time the customer would use the shared support address would be for the initial request. - Each user would monitor the main shared mailbox, looking for new support requests that were addressed to the main support email address. Before replying to these new requests, the user would MOVE the message into their personal mailbox. If the move succeeds, they own the discussion from that point. If the move does NOT succeed, that means someone else attempted the move at the same time, and they got in first. No problem - that other person owns it instead. - Each user would also monitor their own mailbox for new messages for existing discussions, and reply normally from their mailbox. - Each user would also monitor the OTHER personal mailboxes, and be able to either reply on behalf of that user, or take ownership of the discussion, by moving the discussion thread into their own mailbox.
For our small team, I think this approach could work very well, but I want advice on how to set it up for a production environment. For example, is there anything special I need to do related to making it reliable for concurrent access, to ensure messages aren't lost with all this moving of messages etc?
Thanks, Greg.
所有回复 (14)
Sorry - I was a bit self-contradictory - the support staff obviously don't ALWAYS reply using their own email address. When they want to reply in a discussion that is currently owned by another user, without taking ownership, then yes, they will be replying using the existing owner's address - not their own. They would only do this if they were absolutely sure the existing owner was not currently active.
Just by the way, I've looked at a number of commercial products, but so far none of them seem like a good fit - either overkill, or simply not good enough. I had really high hopes for the Collaborative Inbox mode of Google Groups for Business - one day, maybe, when it matures)
Also, it would be good if i could do the following: - disable the ability to REPLY from within the shared mailbox - disable the ability to COPY messages between all the mailboxes - provide a shortcut method for the users to take ownership of a discussion (e.g right-click, select "take ownership" and it would automatically move the discussion thread into the user's private mailbox)
The message tagging feature might be useful too.
Arrrghh!!! If more than one user attempts to MOVE messages from the shared IMAP mailbox, into their private mailbox, the result can be that more than one user will receive a copy - yes - the messages can go to more than one place!!!
Is there a way to solve this problem?
Is it possible there is a bug somewhere? Both Thunderbird and my IMAP server support the IMAP "MOVE" extension - isn't the whole reason for MOVE to enable this to work properly? I'm not necessarily expecting the move of the whole thread to be atomic, but I did NOT expect messages to end up in more than one destination folder. I.e - if some messages went to one folder, and other messages went to another, I would have accepted that. (but I'm hoping I can get an atomic thread move as well, though)
Even doing a POP download simultaneously from two clients results in the messages being downloaded to both clients. I'm pretty sure Outlook Express doesn't have this problem - I've tested it in the past. (will re-test though, just to make sure).
I've tried setting mail.pop3.deleteFromServerOnMove to True on both clients, but that didn't make any difference.
I think that much of what you seek is a function of the server and has little to do with the client.
I can only suggest that you set up your support address, and a set of subfolders, one for each operative. Then all users login to the support account and can see all messages, moving a message into their own subfolder as they take ownership.
You'll need to create a unique email account for each operative, because if you expect your clients to be able to reply to whoever is handling their query, those clients need a valid address to send to. The IMAP server can be set to forward all messages arriving at these separate addresses to your communal support account Inbox, and filters could be used either on the server or in Thunderbird to move or copy these messages into the appropriate users' subfolders. Hopefully that would ensure that each operative would have their specific messages brought to their attention.
Your operatives could run their own accounts, copying messages into their own account folders, but I can't see a simple way to ensure those messages remain visible to their colleagues (presumably you want this so one operative can take over another's correspondence in the event of absence or overload) and also ensuring that others can see when a message in another's account is overdue for attention. If you follow the subfolders method, you could set up the operatives' individual email addresses as additional identities under your main support account, allowing them to be used as "from:" addresses.
Without running your own server to manage multiple access, you will be at the mercy of the available IMAP server. Some don't allow concurrent access by multiple logins.
You have mentioned "shared mailboxes". I don't think I understand what you mean by a "mailbox". To my mind, it has a very specific meaning, referring to the folder system on a server in which an account stores its messages. As such, I don't know of any way to share these between users. However, if your IMAP server permits multiple concurrent logins, we can, as outlined above, try to share one mailbox between multiple users.
I can't comment on what you have described as I have no experience in running multiple concurrent instances of Thunderbird accessing one shared account, let alone your "shared mailboxes".
Zenos, Thanks for your detailed reply - much appreciated.
My IMAP server appears to at least "allow" concurrent access, but whether it's designed to be robust for concurrent access, I'm not sure. (btw, it's Dovecot, if that helps at all) I did contact our hosting provider about the IMAP MOVE problem, and they said that it could be because the email client caches the email messages. They did NOT say "we don't allow concurrent access", so that's a bit of evidence that our IMAP server does support concurrent access. I'll ask them the question just to make sure though.
Regarding the operatives using their own accounts (which is my preference), I envisioned that each operative would have all the accounts defined in their Thunderbird profile, and so far, on the surface, that idea seems to work fine - each operative can see at a glance the list of accounts, along with the number of unread messages, and can easily click on an account to view the messages.
Greg.
If you add each operative's account to all the installed Thunderbirds, then they'll all need to login to each others' accounts to see others' messages.
I think a single common shared account that everybody logs into would be easier to manage, if the server permits this to be done. Again, how it manages clashes between concurrent accesses by different users is I suspect a function of the server and not the client.
I understand that. We're a very small team, and I don't mind setting up the accounts in each profile. They never have to "log in" explicitly - Thunderbird stores the login information. That isn't a problem. They just click on the account.
The reasons I prefer separate accounts at the moment are: - Each operative can have a different signature for each account, for those occasions where they reply on behalf of another operative - Each operative can have a different email address when they switch accounts.
However, if I were to find that the IMAP MOVE worked reliably between folders of the same account, and could not be made to work between accounts, I would then give up on the idea of separate accounts.
The very first thing I would like to do next is test concurrent POP access from Outlook Express.
Greg.
Moving in IMAP has never given me any problems, and specifically not those you describe.
The additional identities can also have their own signatures.
Tools|Account Settings|Account Settings→Manage Identities
And a signature choice add-on can make selection of signature a trivial matter.
POP shows only the Inbox on the server. It cannot offer you visibility of shared folders, and cannot show what's in an Inbox on a different computer. You'll have no indication that a message has been processed already.
"Moving in IMAP has never given me any problems, and specifically not those you describe."
Even for concurrent moves between accounts, like I have been doing?
The reason I want to look into POP is just because it might be a clue as to what's going wrong. As I said, POP has been working reliably for us using O.E, although I want to repeat exactly the same test I did with Thunderbird. POP seems to have been reliably distributing incoming messages to multiple clients, without ever resulting in the same message landing on more than one client.
Another reason I am interested in POP is that if I can get that to work, I can then use a filter rule to simply move the messages into the operative's personal IMAP account, which of course then makes it visible to everyone else. (I have a slight preference for the manual move method though, using IMAP for the incoming messages, as originally outlined)
Thanks for the tip re the signature add-on!
I was wrong! Simultaneous POP downloads using Outlook Express can also download the messages to more than one client! It it ever worked before, it's not working at the moment. We've got a problem. :)
With POP, you either download and delete immediately, or download and leave a copy on the server for other clients to download. Each client has to decide if it leaves a copy behind. Each client also keeps its own tally of which messages it has already had, so I can't see any mechanism to control how many connected clients get a copy, other than arrange that the first one to take a new message deletes it from the server immediately. So this might work for the initial contact, and I guess thereafter the client would see just the signature and address of the operative who is handling their case.
But that would defeat your requirement to share stuff, or to let one operative take over another's correspondence, UNLESS you have some independent, probably IMAP-based, method for sharing correspondence after downloading it.
Yes, exactly - the scenario you describe is exactly what I am trying to achieve, and is in fact what I had in mind when I wrote my previous reply. The message filter rule I mentioned is the mechanism by which the incoming messages are placed in the "private" IMAP accessible account for each operative. (that bit works - I've tried it)
In any case I have discovered that POP does not support simultaneous access to the same account, so my idea won't work. It is designed for one client to be connected at a time. Maybe, if the connections could be queued somehow, it might then work well enough.