Hi all:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
In the past I just created a "alias.bas" file to hold the bulk of our aliases and then 3 "support" alias files, alias.wkd, alias.evn and alias.wed (for weekday, evening and weekend day distribution lists) and then used crontab entries to cat the base file and one of the "support" files into the alias file and run newaliases.
This worked fine while everyone was working on an 0800-1600 schedule but now we have one person that will be working on an 0600-1800 schedule a few days per week. This is going really muck up my simple little procedures.
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
Failing that can anyone recommend an automatic email receiving and routing package that is not to difficult to setup?
TIA
Regards, Hugh
OK, why not just add a couple more scripts to the cron job you have now. One for 0600 to 0800 aliases, then run the 0800 to 1600 version, then next 1600 to 1800 version, but you should still be able to do it in the same manor you are handling it in already... Adding 2 more support files should get it done, just use cron to make live as needed...
john
Hugh E Cruickshank wrote:
Hi all:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
In the past I just created a "alias.bas" file to hold the bulk of our aliases and then 3 "support" alias files, alias.wkd, alias.evn and alias.wed (for weekday, evening and weekend day distribution lists) and then used crontab entries to cat the base file and one of the "support" files into the alias file and run newaliases.
This worked fine while everyone was working on an 0800-1600 schedule but now we have one person that will be working on an 0600-1800 schedule a few days per week. This is going really muck up my simple little procedures.
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
Failing that can anyone recommend an automatic email receiving and routing package that is not to difficult to setup?
TIA
Regards, Hugh
From: John Plemons Sent: March 23, 2007 12:28
OK, why not just add a couple more scripts to the cron job you have now. One for 0600 to 0800 aliases, then run the 0800 to 1600 version, then next 1600 to 1800 version, but you should still be able to do it in the same manor you are handling it in already... Adding 2 more support files should get it done, just use cron to make live as needed...
Hi John:
Yes I know I can do that (and probably will for now) but it not quite as simple as adding 2 new files. All the work schedules do not coincide with each other which means I will probably be adding 4 or more files to the mix and more crontab entries as well. When you consider adding more people or having them change shifts for some reason it gets even worse. The more complex the setup the less flexible and the more likely there will be errors.
I really thought there might be soemthing out there like what I need.
Thanks for your input.
Regards, Hugh
Hugh E Cruickshank wrote:
From: John Plemons Sent: March 23, 2007 12:28
OK, why not just add a couple more scripts to the cron job you have now. One for 0600 to 0800 aliases, then run the 0800 to 1600 version, then next 1600 to 1800 version, but you should still be able to do it in the same manor you are handling it in already... Adding 2 more support files should get it done, just use cron to make live as needed...
Hi John:
Yes I know I can do that (and probably will for now) but it not quite as simple as adding 2 new files. All the work schedules do not coincide with each other which means I will probably be adding 4 or more files to the mix and more crontab entries as well. When you consider adding more people or having them change shifts for some reason it gets even worse. The more complex the setup the less flexible and the more likely there will be errors.
I really thought there might be soemthing out there like what I need.
alias them to a dedicated account, in said dedicated account use a procmail recipe that checks some kind of active duty roster and forward copies of the message to whomever is signed in on active duty. combine this with a punch-in/punch-out type application, perhaps using a webpage, where each support person punchs in when on active duty. if noone is listed as 'active', default to forwarding to the 'normal' folks or whatever.
seems like what you REALLY should be doing is having these emails going into a ticket tracking system, such as Remedy, which in turn sends out notifications to the assigned support person etc etc.
From: John R Pierce Sent: March 23, 2007 13:51
alias them to a dedicated account, in said dedicated account use a procmail recipe that checks some kind of active duty roster and forward copies of the message to whomever is signed in on active duty. combine this with a punch-in/punch-out type application, perhaps using a webpage, where each support person punchs in when on active duty. if noone is listed as 'active', default to forwarding to the 'normal' folks or whatever.
That sound interesting as well. I forgot all about procmail.
seems like what you REALLY should be doing is having these emails going into a ticket tracking system, such as Remedy, which in turn sends out notifications to the assigned support person etc etc.
That is definitely the direction we are headed in but I was trying to find something to tide us over until I could carve out the time to evaluate and implement a ticketing/tracking system.
Thanks again for your comments.
Regards, Hugh
Hugh E Cruickshank wrote:
From: John Plemons Sent: March 23, 2007 12:28
OK, why not just add a couple more scripts to the cron job you have now. One for 0600 to 0800 aliases, then run the 0800 to 1600 version, then next 1600 to 1800 version, but you should still be able to do it in the same manor you are handling it in already... Adding 2 more support files should get it done, just use cron to make live as needed...
Yes I know I can do that (and probably will for now) but it not quite as simple as adding 2 new files. All the work schedules do not coincide with each other which means I will probably be adding 4 or more files to the mix and more crontab entries as well. When you consider adding more people or having them change shifts for some reason it gets even worse. The more complex the setup the less flexible and the more likely there will be errors.
I really thought there might be soemthing out there like what I need.
I usually handle group addresses as :include: files in sendmail aliases just to make them easier to edit and avoid the need to rebuild the aliases db after changes. All you need is a program to generate the right list at the right times into a tmp name on the same file system, then mv's to the included name for an atomic cutover. You are better off keeping that logic separate from anything else. In fact it doesn't even have to be logical if you put copies of the files where the appropriate shift supervisor or equivalent can edit them.
From: Les Mikesell Sent: March 23, 2007 14:22
I usually handle group addresses as :include: files in sendmail aliases just to make them easier to edit and avoid the need to rebuild the aliases db after changes. All you need is a program to generate the right list at the right times into a tmp name on the same file system, then mv's to the included name for an atomic cutover. You are better off keeping that logic separate from anything else. In fact it doesn't even have to be logical if you put copies of the files where the appropriate shift supervisor or equivalent can edit them.
Hi Les:
I was not aware of the :include: files. That does sound interesting and I will definitely check it out.
Thanks, Hugh
Hugh E Cruickshank wrote:
From: Les Mikesell Sent: March 23, 2007 14:22
I usually handle group addresses as :include: files in sendmail aliases just to make them easier to edit and avoid the need to rebuild the aliases db after changes. All you need is a program to generate the right list at the right times into a tmp name on the same file system, then mv's to the included name for an atomic cutover. You are better off keeping that logic separate from anything else. In fact it doesn't even have to be logical if you put copies of the files where the appropriate shift supervisor or equivalent can edit them.
I was not aware of the :include: files. That does sound interesting and I will definitely check it out.
Just make an alias entry with: aliasname: :include:/path/to/file
and run newaliases. Then you can edit the file any time to change that list. I sometimes give the files .txt extensions and put them somewhere with samba access so others can edit with windows/notepad. Sendmail doesn't seem to care about the line endings - just make sure it has read access permission. Also, if you didn't already know, aliases can include other aliases and sendmail will recurse until things stop expanding, weeding out any duplicates so if you have a common group with a few others you can put the common group in one list, then mention its alias in the others along with their unique entries.
Hugh E Cruickshank spake the following on 3/23/2007 1:42 PM:
From: John Plemons Sent: March 23, 2007 12:28
OK, why not just add a couple more scripts to the cron job you have now. One for 0600 to 0800 aliases, then run the 0800 to 1600 version, then next 1600 to 1800 version, but you should still be able to do it in the same manor you are handling it in already... Adding 2 more support files should get it done, just use cron to make live as needed...
Hi John:
Yes I know I can do that (and probably will for now) but it not quite as simple as adding 2 new files. All the work schedules do not coincide with each other which means I will probably be adding 4 or more files to the mix and more crontab entries as well. When you consider adding more people or having them change shifts for some reason it gets even worse. The more complex the setup the less flexible and the more likely there will be errors.
I really thought there might be soemthing out there like what I need.
Thanks for your input.
Regards, Hugh
Maybe a login page for the techs that triggers the changing of the aliases with sed-like scripts.. add them when they log in, remove them when they log out, and also remove them after a certain amount of time if they don't log out. That way you aren't depentent on certain times, and changing schedules, like vacations or sick days.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Mar 23, 2007 at 10:49:47AM -0700, Hugh E Cruickshank wrote:
Hi all:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
In the past I just created a "alias.bas" file to hold the bulk of our aliases and then 3 "support" alias files, alias.wkd, alias.evn and alias.wed (for weekday, evening and weekend day distribution lists) and then used crontab entries to cat the base file and one of the "support" files into the alias file and run newaliases.
This worked fine while everyone was working on an 0800-1600 schedule but now we have one person that will be working on an 0600-1800 schedule a few days per week. This is going really muck up my simple little procedures.
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
Failing that can anyone recommend an automatic email receiving and routing package that is not to difficult to setup?
Humm, the "not too difficult to setup" is the hard part.
I would do this using Exim, maybe with MySQL and the backend, and using "condition" based on the time to determine how to route the message.
However, doing stuff like this on exim takes some learning. The documentation is very complete but anything but intuitive (or even light reading).
Maybe you can even do something "simpler", having multiple aliases routers, using something like:
data = ${lookup{$local_part}lsearch{/etc/alias.0800-1600}} condition = ${if and{{if >={${run{date "+%H"}{$value}}}{8}{1}{0}}{if <{${run{date "+%H"}{$value}}}{16}{1}{0}}}}
In this case, the router would only work between 08:00 and 15:59. (NOTICE: This condition is untested, and probably contains syntax errors)
It would be easier using a database backend (mysql is my favorite), since would could use the sql query for testing, instead of the "condition".
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
From: Rodrigo Barbosa Sent: March 23, 2007 13:25
Humm, the "not too difficult to setup" is the hard part.
I would do this using Exim, maybe with MySQL and the backend, and using "condition" based on the time to determine how to route the message.
Hi Rodrigo:
Thanks, I will have a look at your sugggestion, however, we are a sendmail shop I a would rather stick with that if I can.
Regards, Hugh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Mar 23, 2007 at 01:47:51PM -0700, Hugh E Cruickshank wrote:
From: Rodrigo Barbosa Sent: March 23, 2007 13:25
Humm, the "not too difficult to setup" is the hard part.
I would do this using Exim, maybe with MySQL and the backend, and using "condition" based on the time to determine how to route the message.
Hi Rodrigo:
Thanks, I will have a look at your sugggestion, however, we are a sendmail shop I a would rather stick with that if I can.
Good luck then. You will need it.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Hugh E Cruickshank wrote:
Hi all:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
In the past I just created a "alias.bas" file to hold the bulk of our aliases and then 3 "support" alias files, alias.wkd, alias.evn and alias.wed (for weekday, evening and weekend day distribution lists) and then used crontab entries to cat the base file and one of the "support" files into the alias file and run newaliases.
This worked fine while everyone was working on an 0800-1600 schedule but now we have one person that will be working on an 0600-1800 schedule a few days per week. This is going really muck up my simple little procedures.
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
A shared imap account/folder?
Why aren't you doing this anyway? It's a good way for Freda to see what Fred said on the previous shift.
Failing that can anyone recommend an automatic email receiving and routing package that is not to difficult to setup?
TIA
Regards, Hugh
From: John Summerfield Sent: March 24, 2007 15:52
Hugh E Cruickshank wrote:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
[SNIP]
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
A shared imap account/folder?
Why aren't you doing this anyway? It's a good way for Freda to see what Fred said on the previous shift.
Hi John:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
Also the sharing of email accounts is not going to work either. We are a small shop with some overlap of responsibilities but it is not a 100% overlap and we still need some distinction between users.
Thanks again for your suggestion.
Regards, Hugh
Why don’t you do the industry standard thing and use a trouble ticket package like Cerberus?
-Drew
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Hugh E Cruickshank Sent: Monday, March 26, 2007 1:55 PM To: CentOS mailing list Subject: RE: [CentOS] Complex sendmail alias handling.
From: John Summerfield Sent: March 24, 2007 15:52
Hugh E Cruickshank wrote:
I have a situation where I need to change the distribution of emails for selected accounts on a regular basis. This is for the controlling of the distribution of our "support" email address.
[SNIP]
I was wondering if anyone out there new of something short of an automatic email receiving and routing package (which I have not done any research on) that might fit my simple requirements.
A shared imap account/folder?
Why aren't you doing this anyway? It's a good way for Freda to see what Fred said on the previous shift.
Hi John:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
Also the sharing of email accounts is not going to work either. We are a small shop with some overlap of responsibilities but it is not a 100% overlap and we still need some distinction between users.
Thanks again for your suggestion.
Regards, Hugh
From: Drew Weaver Sent: March 26, 2007 11:00
Why dont you do the industry standard thing and use a trouble ticket package like Cerberus?
That is what we will probably do in the long run. I was just hoping that there might be something out there that would assist us with our email distribution issue without to much effort.
Regards, Hugh
Well, check out Cerberus.
What we do is have a mailbox setup for support, Cerberus downloads the mail and then forwards it to our exchange server (public folder) than we share the work load in the public folder, and we track tickets using Cerberus.
It works really well, and unless you update it constantly its fairly hands-off.
-Drew
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Hugh E Cruickshank Sent: Monday, March 26, 2007 2:10 PM To: CentOS mailing list Subject: RE: [CentOS] Complex sendmail alias handling.
From: Drew Weaver Sent: March 26, 2007 11:00
Why dont you do the industry standard thing and use a trouble ticket package like Cerberus?
That is what we will probably do in the long run. I was just hoping that there might be something out there that would assist us with our email distribution issue without to much effort.
Regards, Hugh
From: Drew Weaver Sent: March 26, 2007 11:15
Well, check out Cerberus.
I will definitely do that.
What we do is have a mailbox setup for support, Cerberus downloads the mail and then forwards it to our exchange server (public folder) than we share the work load in the public folder, and we track tickets using Cerberus.
The mail handling is my primary concern at this time. The other aspects of ticketing systems is already being handle be in-house developed applications that are highly integrated into our own application software management, packaging and operation. It will be both a major selling job and implantation effort to replace that.
It works really well, and unless you update it constantly its fairly hands-off.
Thank you for your recommendation.
Regards, Hugh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Mar 26, 2007 at 01:59:55PM -0400, Drew Weaver wrote:
Why don’t you do the industry standard thing and use a trouble ticket package like Cerberus?
Ok, granted I've only been to the client side of Cerberus, but it is one of the worst TTS solutions I ever saw.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Mar 26, 2007, at 13:54, Hugh E Cruickshank wrote:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
I've used Outlook with IMAP folders extensively in the past. Not using it currently so I can't verify that it still works, but it definitely used to.
Alfred
From: Alfred von Campe Sent: March 26, 2007 11:09
On Mar 26, 2007, at 13:54, Hugh E Cruickshank wrote:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
I've used Outlook with IMAP folders extensively in the past. Not using it currently so I can't verify that it still works, but it definitely used to.
That is interesting because when I checked it out on the MS support site before replying to John they specifically stated that Outlook did not support IMAP folders. It is a moot point as I can not take advantage of share folders for logistical reasons, but thanks anyway.
Regards, Hugh
Hugh E Cruickshank wrote:
That is interesting because when I checked it out on the MS support site before replying to John they specifically stated that Outlook did not support IMAP folders. It is a moot point as I can not take advantage of share folders for logistical reasons, but thanks anyway.
What version is that? Outlook 2000 did OK, 2003 is pretty good at it.
From: Les Mikesell Sent: March 26, 2007 11:40
Hugh E Cruickshank wrote:
That is interesting because when I checked it out on the MS support site before replying to John they specifically stated that Outlook did not support IMAP folders. It is a moot point as I can not take advantage of share folders for logistical reasons, but thanks anyway.
What version is that? Outlook 2000 did OK, 2003 is pretty good at it.
OL2000 but even if it does work we have logistical reasons that would preclude taking this approach.
Regards, Hugh
Alfred von Campe spake the following on 3/26/2007 11:09 AM:
On Mar 26, 2007, at 13:54, Hugh E Cruickshank wrote:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
I've used Outlook with IMAP folders extensively in the past. Not using it currently so I can't verify that it still works, but it definitely used to.
Alfred
Outlook does have some problems with IMAP but no more so than the problems it can have with POP3.
Hugh E Cruickshank wrote:
A shared imap account/folder?
Why aren't you doing this anyway? It's a good way for Freda to see what Fred said on the previous shift.
Hi John:
Thanks for your reply. That is a good suggestion but it probably will not "fly" in our instance. We are using Outlook for the MUA and, as far as I am aware, does not work with IMAP folders.
Yes it will - just add a new account. If it is set up to only use exchange you might have to install a component for internet email access (and some very old versions can't do both).
Also the sharing of email accounts is not going to work either. We are a small shop with some overlap of responsibilities but it is not a 100% overlap and we still need some distinction between users.
Basically you would add a new mailbox for each set of messages and have the appropriate people subscribe to it. If you are using exchange, you'd have the equivalent functionality in public folders. With IMAP, I think only Cyrus handles shared folders well.
-
Alfred von Campe -
Drew Weaver -
Hugh E Cruickshank -
John Plemons -
John R Pierce -
John Summerfield -
Les Mikesell -
Rodrigo Barbosa -
Scott Silva