Getting in late on this one, but if I didn't need to spend money, couldn't spend money, or what ever the reason may be, and the aliasing was something that needed changing on a schedule, then why not just set up multiple alias files, run cron to replace them when needed, and "newaliases", all in cron scripts? You would need to maintain as many versions as required, but sounds like it might work with minimal effort and expense.
Complex is a relative term, and this may be oversimplifying, but it would work.
Steve Campbell campbell@cnpapers.com Charleston Newspapers
From: Steve Campbell Sent: March 27, 2007 10:31
Getting in late on this one, but if I didn't need to spend money, couldn't spend money, or what ever the reason may be, and the aliasing was something that needed changing on a schedule, then why not just set up multiple alias files, run cron to replace them when needed, and "newaliases", all in cron scripts? You would need to maintain as many versions as required, but sounds like it might work with minimal effort and expense.
Complex is a relative term, and this may be oversimplifying, but it would work.
Hi Steve:
It would and does work. That is the method that we are currently using. It works fine when we are talking about only 3 variations on the alias. Currently I have files for weekday, weekend day and evening and run a crontab script at 0800 and 1600 daily. The problem I now have is that as we add staff with flexible work schedules that simple scheme starts to get very complicated very quickly.
What I was hoping for was something that could assist me with the administration of this task but it does not look like there is anything like what I a looking for.
In the long run we are looking at probably implementing a ticketing system but I just do not have the time to do the evaluation, selling and implementation at this point.
Thanks for your comments, they are appreciated.
Regards, Hugh
Hugh E Cruickshank wrote:
From: Steve Campbell Sent: March 27, 2007 10:31
Getting in late on this one, but if I didn't need to spend money, couldn't spend money, or what ever the reason may be, and the aliasing was something that needed changing on a schedule, then why not just set up multiple alias files, run cron to replace them when needed, and "newaliases", all in cron scripts? You would need to maintain as many versions as required, but sounds like it might work with minimal effort and expense.
Complex is a relative term, and this may be oversimplifying, but it would work.
Hi Steve:
It would and does work. That is the method that we are currently using. It works fine when we are talking about only 3 variations on the alias. Currently I have files for weekday, weekend day and evening and run a crontab script at 0800 and 1600 daily. The problem I now have is that as we add staff with flexible work schedules that simple scheme starts to get very complicated very quickly.
What I was hoping for was something that could assist me with the administration of this task but it does not look like there is anything like what I a looking for.
In the long run we are looking at probably implementing a ticketing system but I just do not have the time to do the evaluation, selling and implementation at this point.
Why doesn't shared imap folders work? support@example.com is read by all support staff. Sent mail is stored on the server.
From: John Summerfield Sent: March 27, 2007 17:20
Why doesn't shared imap folders work? support@example.com is read by all support staff. Sent mail is stored on the server.
Several people have already suggested this approach. Since we are using MS Outlook for our MUA I checked with the MS support site and found the IMAP folder are not supported. I have since been advised that that is not necessarily so.
To be honest I am loathed to even attempt this. Outlook and it's users (mostly the later) already cause me too many problems.
Thanks again for your suggestions.
Regards, Hugh
Hugh E Cruickshank wrote:
From: John Summerfield Sent: March 27, 2007 17:20
Why doesn't shared imap folders work? support@example.com is read by all support staff. Sent mail is stored on the server.
Several people have already suggested this approach. Since we are using
I did, but I didn't see a response.
MS Outlook for our MUA I checked with the MS support site and found the IMAP folder are not supported. I have since been advised that that is not necessarily so.
Works for us. Our email users us Entourage (MS, for OS X), Mail (Apple) assorted Linux email clients (yours truly), Seamonkey/Thunderbird (on Windows) and, sometimes, Lookout Express.
To be honest I am loathed to even attempt this. Outlook and it's users (mostly the later) already cause me too many problems.
Tell 'em Lookout is well-named and recommend Thunderbird instead:-)
Thanks again for your suggestions.
Regards, Hugh
John Summerfield wrote:
Hugh E Cruickshank wrote:
From: John Summerfield Sent: March 27, 2007 17:20
Why doesn't shared imap folders work? support@example.com is read by all support staff. Sent mail is stored on the server.
Several people have already suggested this approach. Since we are using
I did, but I didn't see a response.
MS Outlook for our MUA I checked with the MS support site and found the IMAP folder are not supported. I have since been advised that that is not necessarily so.
Works for us. Our email users us Entourage (MS, for OS X), Mail (Apple) assorted Linux email clients (yours truly), Seamonkey/Thunderbird (on Windows) and, sometimes, Lookout Express.
To be honest I am loathed to even attempt this. Outlook and it's users (mostly the later) already cause me too many problems.
Tell 'em Lookout is well-named and recommend Thunderbird instead:-)
How about imap plus Squirrelmail (web mail)?
From: John Summerfield Sent: March 28, 2007 00:17
John Summerfield wrote:
Hugh E Cruickshank wrote:
To be honest I am loathed to even attempt this. Outlook and it's users (mostly the later) already cause me too many problems.
Tell 'em Lookout is well-named and recommend Thunderbird instead:-)
How about imap plus Squirrelmail (web mail)?
The problem I have with that is amount of effort that will take to "sell", implement and support the solution. I can make recommendations but that does not mean that they will be automatically accepted. If I have to spend that much effort on what is essentially a "stop gap" measure until we implement a ticketing system I might as well spend the time on the final solution.
All I was really looking for was something that might ease the efforts I am currently expending to support the current "stop gap" measure. If that is not possible then I will have to live with things the way they are until we can proceed to the next level (i.e. a ticketing system).
Thanks again for your input, it is appreciated.
Regards, Hugh
Hugh E Cruickshank wrote:
The problem I have with that is amount of effort that will take to "sell", implement and support the solution. I can make recommendations but that does not mean that they will be automatically accepted. If I have to spend that much effort on what is essentially a "stop gap" measure until we implement a ticketing system I might as well spend the time on the final solution.
All I was really looking for was something that might ease the efforts I am currently expending to support the current "stop gap" measure. If that is not possible then I will have to live with things the way they are until we can proceed to the next level (i.e. a ticketing system).
You can't get much easier than files containing a list of the right delivery addresses for each time period and a cron job that copies the right file to the one :included: by a sendmail alias at each transition. Did you try that approach yet? But for ongoing things you lose the ability to easily see what the previous shift did unless they reply/forward a copy of anything still needing work.
From: Les Mikesell Sent: March 28, 2007 12:07
You can't get much easier than files containing a list of the right delivery addresses for each time period and a cron job that copies the right file to the one :included: by a sendmail alias at each transition. Did you try that approach yet? But for ongoing things you lose the ability to easily see what the previous shift did unless they reply/forward a copy of anything still needing work.
I agree that this approach is fairly straight forward and I have not tried it. However our current approach (concatenating files to create a new alias file) is about the same in complexity. The difficulty arises from determining the contents of those files.
For now we are going keep the current three sets of files (weekday 08-16, weekend day 08-16 and evening 16-08) and I will start the "selling" job on a Ticketing system (the long term solution).
Thanks for your comments.
Regards, Hugh
Hugh E Cruickshank wrote:
From: Les Mikesell Sent: March 28, 2007 12:07
You can't get much easier than files containing a list of the right delivery addresses for each time period and a cron job that copies the right file to the one :included: by a sendmail alias at each transition. Did you try that approach yet? But for ongoing things you lose the ability to easily see what the previous shift did unless they reply/forward a copy of anything still needing work.
I agree that this approach is fairly straight forward and I have not tried it. However our current approach (concatenating files to create a new alias file) is about the same in complexity. The difficulty arises from determining the contents of those files.
Just expose them to the person who knows what the contents should be for editing. Anyone managing a shift of people should be able to edit a text file.
-- Les Mikesell lesmikesell@gmail.com
From: Les Mikesell Sent: March 28, 2007 12:50
Hugh E Cruickshank wrote:
I agree that this approach is fairly straight forward and I have not tried it. However our current approach (concatenating files to create a new alias file) is about the same in complexity. The difficulty arises from determining the contents of those files.
Just expose them to the person who knows what the contents should be for editing. Anyone managing a shift of people should be able to edit a text file.
You would think so but I have had a hard enough time trying to convince them to use the Outlook rules and folders (without much success) which would make their life easier. I really do not think I can count on them to maintain the alias file to make my job easier. I would just end up with a lot of complaints about it not working and then end up having to maintain it myself anyway. I might as well save the time and frustration and do it myself. Sometimes it is just not worth it to try and delegate some tasks.
I will now stop my gratuitous complaining and get back to work.
Regards, Hugh
Hugh E Cruickshank wrote:
From: Les Mikesell Sent: March 28, 2007 12:50
Hugh E Cruickshank wrote:
I agree that this approach is fairly straight forward and I have not tried it. However our current approach (concatenating files to create a new alias file) is about the same in complexity. The difficulty arises from determining the contents of those files.
Just expose them to the person who knows what the contents should be for editing. Anyone managing a shift of people should be able to edit a text file.
You would think so but I have had a hard enough time trying to convince them to use the Outlook rules and folders (without much success) which would make their life easier. I really do not think I can count on them to maintain the alias file to make my job easier. I would just end up with a lot of complaints about it not working and then end up having to maintain it myself anyway. I might as well save the time and frustration and do it myself. Sometimes it is just not worth it to try and delegate some tasks.
There's a method to this madness... If you first make them do the work because they are the only ones that know the appropriate contents for these files, then you will have their support when you point out how using a real trouble ticket system will make this work unnecessary.
From: Les Mikesell Sent: March 28, 2007 13:42
There's a method to this madness... If you first make them do the work because they are the only ones that know the appropriate contents for these files, then you will have their support when you point out how using a real trouble ticket system will make this work unnecessary.
I hear you but it is more of an uphill battle then it sounds like. We already have an in-house developed system that has been refined for years for our own use. It is highly integrated with our application software for sales, support, distribution and development purposes. The only things it does not really do is staff scheduling (which is not much of a concern) and email response/tracking/routing.
I think I can prevail in proposing a new ticketing system but it will be "tough sell". I will probably just start off with the email aspects and then try and expand it after that.
Regards, Hugh
Hugh E Cruickshank spake the following on 3/28/2007 2:24 PM:
From: Les Mikesell Sent: March 28, 2007 13:42
There's a method to this madness... If you first make them do the work because they are the only ones that know the appropriate contents for these files, then you will have their support when you point out how using a real trouble ticket system will make this work unnecessary.
I hear you but it is more of an uphill battle then it sounds like. We already have an in-house developed system that has been refined for years for our own use. It is highly integrated with our application software for sales, support, distribution and development purposes. The only things it does not really do is staff scheduling (which is not much of a concern) and email response/tracking/routing.
I think I can prevail in proposing a new ticketing system but it will be "tough sell". I will probably just start off with the email aspects and then try and expand it after that.
Regards, Hugh
If you have an in-house developed system, then your programmers should be the ones to add the proper features. E-mails sent to "support" should be picked up and managed by the system.
From: Scott Silva Sent: March 28, 2007 15:07
If you have an in-house developed system, then your programmers should be the ones to add the proper features. E-mails sent to "support" should be picked up and managed by the system.
I will get myself on that right away. Who needs sleep anyway (I hear it is highly overrated). But seriously...
While what your suggesting is certainly valid, I am always hesitant to program functionality that is already available in an off-the-shelf package. In other words I would rather not re-invent the wheel as the saying sometimes goes. That and I am quite sure that I would not be able come up with something that even remotely approaches the functionality and stability that would be available in a reasonably mature open source or proprietary package. Also, as I alluded to above, I just do not have the time to devote to this.
Thanks for your comments though.
Regards, Hugh
Hugh E Cruickshank wrote:
From: Scott Silva Sent: March 28, 2007 15:07
If you have an in-house developed system, then your programmers should be the ones to add the proper features. E-mails sent to "support" should be picked up and managed by the system.
I will get myself on that right away. Who needs sleep anyway (I hear it is highly overrated). But seriously...
While what your suggesting is certainly valid, I am always hesitant to program functionality that is already available in an off-the-shelf package. In other words I would rather not re-invent the wheel as the saying sometimes goes. That and I am quite sure that I would not be able come up with something that even remotely approaches the functionality and stability that would be available in a reasonably mature open source or proprietary package. Also, as I alluded to above, I just do not have the time to devote to this.
I've used mailman lists as a really quick fix for this sort of thing to just give a place where you can control redistribution and keep an archive. And you can tell from a glance at the archive list if any of the inbound messages did not have at least one response. RT can be used this way too and is nicer because you can have additional queues and if the first person to respond can't complete whatever needs to be done, the ticket can be moved to a queue that will give it to someone that can. Either of these can be configured as the target of an email address and take effect more or less transparently, although in RT's case you probably need to periodically go though and close the tickets that have been completed by the email response. I still have a couple of these set up for general notification and problem messages. Everyone just interacts by email but the system collates the responses together so you can review later.
From: Les Mikesell Sent: March 28, 2007 15:53
I've used mailman lists as a really quick fix for this sort of thing to just give a place where you can control redistribution and keep an archive. And you can tell from a glance at the archive list if any of the inbound messages did not have at least one response.
I had not thought of mailman, although I was aware of it. I suspect that I might have the same "management" issues with it as I do with sendmail aliases but I will have a closer look since I have not actually ever used it before.
RT can be used this way too and is nicer because you can have additional queues and if the first person to respond can't complete whatever needs to be done, the ticket can be moved to a queue that will give it to someone that can. Either of these can be configured as the target of an email address and take effect more or less transparently, although in RT's case you probably need to periodically go though and close the tickets that have been completed by the email response. I still have a couple of these set up for general notification and problem messages. Everyone just interacts by email but the system collates the responses together so you can review later.
I had been considering RT (and OTRS and probably others) in the long run but will now probably look at them for email handling only in the near future.
Thanks again for your comments and suggestions.
Regards, Hugh
Hugh E Cruickshank spake the following on 3/28/2007 1:09 PM:
From: Les Mikesell Sent: March 28, 2007 12:50
Hugh E Cruickshank wrote:
I agree that this approach is fairly straight forward and I have not tried it. However our current approach (concatenating files to create a new alias file) is about the same in complexity. The difficulty arises from determining the contents of those files.
Just expose them to the person who knows what the contents should be for editing. Anyone managing a shift of people should be able to edit a text file.
You would think so but I have had a hard enough time trying to convince them to use the Outlook rules and folders (without much success) which would make their life easier. I really do not think I can count on them to maintain the alias file to make my job easier. I would just end up with a lot of complaints about it not working and then end up having to maintain it myself anyway. I might as well save the time and frustration and do it myself. Sometimes it is just not worth it to try and delegate some tasks.
I will now stop my gratuitous complaining and get back to work.
Regards, Hugh
The floggings will continue until morale improves! ;-P
Hugh E Cruickshank wrote:
From: John Summerfield Sent: March 28, 2007 00:17
John Summerfield wrote:
Hugh E Cruickshank wrote:
To be honest I am loathed to even attempt this. Outlook and it's users (mostly the later) already cause me too many problems.
Tell 'em Lookout is well-named and recommend Thunderbird instead:-)
How about imap plus Squirrelmail (web mail)?
The problem I have with that is amount of effort that will take to "sell", implement and support the solution. I can make recommendations but that does not mean that they will be automatically accepted. If I have to spend that much effort on what is essentially a "stop gap" measure until we implement a ticketing system I might as well spend the time on the final solution.
All I was really looking for was something that might ease the efforts I am currently expending to support the current "stop gap" measure. If that is not possible then I will have to live with things the way they are until we can proceed to the next level (i.e. a ticketing system).
imap plus sqirrelmail is a standard solution with official vendor support, to the exent that anything in CentOS has official vendor support:-)
It has benefits wider than just this application: I see email as official documents belonging to the organisation, and I believe the best pace to keep them is on the server. Imap does that.
Imap also allows users to read email from any computer: their office computer, their laptop, their home computer (subject to business policy, of course) using any imap-capable email client.
Squirrelmail covers for the case where a traditional email client is inappropriate, say from an Internet cafe, a friend's home, someone else's computer in another office.
When I set up user accounts, I create several standard folder son the server, one for suspected spam, one for email with possible sploitative attachments (eg office documents), and a few others. These are all on the server, and we do some preliminary sorting.
What you are proprosing is best characterised as a Crude Hack, unsupported except by yourselves, fragile and high-maintenance.
Present it to the decision-makers and see how you go.
Remember, when you want someone to make an unpalatable choice (not the case here), offer less palative alternatives.
I've seen three choices here: 1. Crude Hack. 2. Proper ticketting system 3. Imap email.
I suggest that the third is a good interim solution, your only (realistic) choice is the imap servers on your CentOS CD, and both have been tested to integrate with your other software. Same with Squirrelmail, it's on your CD.
The Crude Hack may require urgent changes whenever somone can't come in for a shift. The Imap service won't.
The Imap choice can be your standard email solution, and other groups might benefit from shared folders too - any groups that provide a service _as a group_ might. Accounts. HR. Our teachers. Policy.
-
Hugh E Cruickshank -
John Summerfield -
Les Mikesell -
Scott Silva -
Steve Campbell