Jeff Hyman typed (on Mon, Mar 26, 2007 at 01:30:52PM -0400):
|
| SCO 5.0.6
| mutt ver ??
|
| I have an employee 'dlawson' out on maturnity leave.
| I added /usr/dlawson/.deliver (atached below)
| '/usr/person/vacation-list' gets appended with any incoming email
| so that sender receives a message from 'dlawson' that they are
| out for vaca|maturnity|sick|etc. ONLY ONE TIME.
|
| Problem is that 'vacation-list' is creating incorrect outgoing
| email address, so nobody outside 'cactus.com' receives email
| notification that user 'dlawson' is out. Email address below
| are examples only to protect the senders ID.
|
| Xmail2!myactv.net!wayscomm@cactus.comX
| Xjeff@cactus.comX <=== This was OK
| XMAILER-DAEMON@cactus.comX
| Xmail2!mirenvelope.com!pach@cactus.comX
| Xmail2!club.co.uk!eister@cactus.comX
| Xroot@cactus.comX <=== This was OK
| Xmail2!ds.localdomain!root@cactus.comX
| Xmail2!wanadoo.fr!johnnyl@cactus.comX
| Xmail2!domain.com!do-not-reply@cactus.comX
| Xmail2!saka.com!Jimmy.Bath@cactus.comX
| Xmail2!ecux.net!eman@cactus.comX
| Xmail2!northrupp.com!debrap@cactus.comX
| ----------------- clipped -------------
|
| Where would I start looking to track down this problem to fix it?
| Solution is that the sender receives ONE email that dlawson is out on vaca.

Nothing whatsoever to do with mutt. The script I wrote is tripping over uucp
bang!addresses.

Try replacing your /usr/local/lib/deliver.vacation with the following,
after editing the LOCALDOM and the PLACE:


##### cut here --- file below stored as /usr/local/lib/deliver.vacation #####
#!/bin/ksh
# .vacation
# 1.6 JPRadley 27mar07
#
# A user delivery file for when you're away.
PATH=/usr/local/bin:/bin:/usr/bin
LOCALDOM=jpr.com
PLACE="JP Radley, Inc"
SP=`header -f X-Spam-Flag $HEADER`

echo "$1" # First of all, keep the mail!

case "$SP" in
YES) exit ;; # replying to what is probably SPAM is a waste of time.
esac

# Do nothing more unless the message was directly addressed to you.
header -n -f To -f Cc -f Apparently-To $HEADER |
fgrep -iq $1@$LOCALDOM || exit 0

# Don't waste any energy on daemons
case $SENDER in
uucp@$LOCALDOM|cron@$LOCALDOM|*daemon@$LOCALDOM|MA ILER-D*) exit 0 ;;
esac

typeset -l FROM=`header -f From $HEADER`

# The ALREADY file remembers to whom you've already mailed vacation messages.
ALREADY=vacation-list

if fgrep X${FROM}X $ALREADY >/dev/null 2>/dev/null
then
exit 0 # We already notified this person; do nothing more
fi

# Remember this person
echo X${FROM}X >>$ALREADY

# Send the vacation message
SUBJECT=`header -f subject $HEADER`
mutt -s "I'm away from $PLACE" $FROM < Your message to me on the subject

"$SUBJECT"

has been delivered. I have not yet read your message,
since I am away from $PLACE.

I expect to return BEBACK.

This is the only such notice you will receive.

Thank you.

!EOF!

exit 0
######### cut here #######

--
JP
==> http://www.frappr.com/cusm <==

Jean-Pierre Radley typed (on Mon, Mar 26, 2007 at 07:33:48PM -0400):
| Jeff Hyman typed (on Mon, Mar 26, 2007 at 01:30:52PM -0400):
| |
| | SCO 5.0.6
| | mutt ver ??
| |
| | I have an employee 'dlawson' out on maturnity leave.
| | I added /usr/dlawson/.deliver (atached below)
| | '/usr/person/vacation-list' gets appended with any incoming email
| | so that sender receives a message from 'dlawson' that they are
| | out for vaca|maturnity|sick|etc. ONLY ONE TIME.
| |
| | Problem is that 'vacation-list' is creating incorrect outgoing
| | email address, so nobody outside 'cactus.com' receives email
| | notification that user 'dlawson' is out. Email address below
| | are examples only to protect the senders ID.
| |
| | Xmail2!myactv.net!wayscomm@cactus.comX
| | Xjeff@cactus.comX <=== This was OK
| | XMAILER-DAEMON@cactus.comX
| | Xmail2!mirenvelope.com!pach@cactus.comX
| | Xmail2!club.co.uk!eister@cactus.comX
| | Xroot@cactus.comX <=== This was OK
| | Xmail2!ds.localdomain!root@cactus.comX
| | Xmail2!wanadoo.fr!johnnyl@cactus.comX
| | Xmail2!domain.com!do-not-reply@cactus.comX
| | Xmail2!saka.com!Jimmy.Bath@cactus.comX
| | Xmail2!ecux.net!eman@cactus.comX
| | Xmail2!northrupp.com!debrap@cactus.comX
| | ----------------- clipped -------------
| |
| | Where would I start looking to track down this problem to fix it?
| | Solution is that the sender receives ONE email that dlawson is out on vaca.
|
| Nothing whatsoever to do with mutt. The script I wrote is tripping over uucp
| bang!addresses.
|
| Try replacing your /usr/local/lib/deliver.vacation with the following,
| after editing the LOCALDOM and the PLACE:
|
|
| ##### cut here --- file below stored as /usr/local/lib/deliver.vacation #####
| #!/bin/ksh
| # .vacation
| # 1.6 JPRadley 27mar07
| #
| # A user delivery file for when you're away.
| PATH=/usr/local/bin:/bin:/usr/bin
| LOCALDOM=jpr.com
| PLACE="JP Radley, Inc"
| SP=`header -f X-Spam-Flag $HEADER`
|
| echo "$1" # First of all, keep the mail!
|
| case "$SP" in
| YES) exit ;; # replying to what is probably SPAM is a waste of time.
| esac
|
| # Do nothing more unless the message was directly addressed to you.
| header -n -f To -f Cc -f Apparently-To $HEADER |
| fgrep -iq $1@$LOCALDOM || exit 0
|
| # Don't waste any energy on daemons
| case $SENDER in
| uucp@$LOCALDOM|cron@$LOCALDOM|*daemon@$LOCALDOM|MA ILER-D*) exit 0 ;;
| esac
|
| typeset -l FROM=`header -f From $HEADER`
|
| # The ALREADY file remembers to whom you've already mailed vacation messages.
| ALREADY=vacation-list
|
| if fgrep X${FROM}X $ALREADY >/dev/null 2>/dev/null
| then
| exit 0 # We already notified this person; do nothing more
| fi
|
| # Remember this person
| echo X${FROM}X >>$ALREADY
|
| # Send the vacation message
| SUBJECT=`header -f subject $HEADER`
| mutt -s "I'm away from $PLACE" $FROM < | Your message to me on the subject
|
| "$SUBJECT"
|
| has been delivered. I have not yet read your message,
| since I am away from $PLACE.
|
| I expect to return BEBACK.
|
| This is the only such notice you will receive.
|
| Thank you.
|
| !EOF!
|
| exit 0
| ######### cut here #######
|
| --
| JP
| ==> http://www.frappr.com/cusm <==

Seems to work much better.
One noticable error is that a message sent FROM (ie) jeff@cactus.com
will reply to the SENDER as follows:
jeffrey@cactus.com
hyman@cactus.com
jeff@cactus.com

# grep jeff /etc/passwd
jeff:zzzzzzzz:Jeffrey Hyman:/usr/jeff:/xxx/xxx

It has also been tested outside domain 'cactus.com' with same results.
I will BOUNCE you a copy of this email.

- Jeff H

Jeff Hyman typed (on Tue, Mar 27, 2007 at 01:34:00PM -0400):
| Jean-Pierre Radley typed (on Mon, Mar 26, 2007 at 07:33:48PM -0400):
| | Jeff Hyman typed (on Mon, Mar 26, 2007 at 01:30:52PM -0400):
| | |
| | | SCO 5.0.6
| | | mutt ver ??
| | |
| | | I have an employee 'dlawson' out on maturnity leave.
| | | I added /usr/dlawson/.deliver (atached below)
| | | '/usr/person/vacation-list' gets appended with any incoming email
| | | so that sender receives a message from 'dlawson' that they are
| | | out for vaca|maturnity|sick|etc. ONLY ONE TIME.
| | |
| | | Problem is that 'vacation-list' is creating incorrect outgoing
| | | email address, so nobody outside 'cactus.com' receives email
| | | notification that user 'dlawson' is out. Email address below
| | | are examples only to protect the senders ID.
| | |
| | | Xmail2!myactv.net!wayscomm@cactus.comX
| | | Xjeff@cactus.comX <=== This was OK
| | | XMAILER-DAEMON@cactus.comX
| | | Xmail2!mirenvelope.com!pach@cactus.comX
| | | Xmail2!club.co.uk!eister@cactus.comX
| | | Xroot@cactus.comX <=== This was OK
| | | Xmail2!ds.localdomain!root@cactus.comX
| | | Xmail2!wanadoo.fr!johnnyl@cactus.comX
| | | Xmail2!domain.com!do-not-reply@cactus.comX
| | | Xmail2!saka.com!Jimmy.Bath@cactus.comX
| | | Xmail2!ecux.net!eman@cactus.comX
| | | Xmail2!northrupp.com!debrap@cactus.comX
| | | ----------------- clipped -------------
| | |
| | | Where would I start looking to track down this problem to fix it?
| | | Solution is that the sender receives ONE email that dlawson is out on vaca.
| |
| | Nothing whatsoever to do with mutt. The script I wrote is tripping over uucp
| | bang!addresses.
| |
| | Try replacing your /usr/local/lib/deliver.vacation with the following,
| | after editing the LOCALDOM and the PLACE:
| |
| |
| | ##### cut here --- file below stored as /usr/local/lib/deliver.vacation #####
| | #!/bin/ksh
| | # .vacation
| | # 1.6 JPRadley 27mar07
| | #
| | # A user delivery file for when you're away.
| | PATH=/usr/local/bin:/bin:/usr/bin
| | LOCALDOM=jpr.com
| | PLACE="JP Radley, Inc"
| | SP=`header -f X-Spam-Flag $HEADER`
| |
| | echo "$1" # First of all, keep the mail!
| |
| | case "$SP" in
| | YES) exit ;; # replying to what is probably SPAM is a waste of time.
| | esac
| |
| | # Do nothing more unless the message was directly addressed to you.
| | header -n -f To -f Cc -f Apparently-To $HEADER |
| | fgrep -iq $1@$LOCALDOM || exit 0
| |
| | # Don't waste any energy on daemons
| | case $SENDER in
| | uucp@$LOCALDOM|cron@$LOCALDOM|*daemon@$LOCALDOM|MA ILER-D*) exit 0 ;;
| | esac
| |
| | typeset -l FROM=`header -f From $HEADER`
| |
| | # The ALREADY file remembers to whom you've already mailed vacation messages.
| | ALREADY=vacation-list
| |
| | if fgrep X${FROM}X $ALREADY >/dev/null 2>/dev/null
| | then
| | exit 0 # We already notified this person; do nothing more
| | fi
| |
| | # Remember this person
| | echo X${FROM}X >>$ALREADY
| |
| | # Send the vacation message
| | SUBJECT=`header -f subject $HEADER`
| | mutt -s "I'm away from $PLACE" $FROM < | | Your message to me on the subject
| |
| | "$SUBJECT"
| |
| | has been delivered. I have not yet read your message,
| | since I am away from $PLACE.
| |
| | I expect to return BEBACK.
| |
| | This is the only such notice you will receive.
| |
| | Thank you.
| |
| | !EOF!
| |
| | exit 0
| | ######### cut here #######
| |
| | --
| | JP
| | ==> http://www.frappr.com/cusm <==
|
| Seems to work much better.
| One noticable error is that a message sent FROM (ie) jeff@cactus.com
| will reply to the SENDER as follows:
| jeffrey@cactus.com
| hyman@cactus.com
| jeff@cactus.com
|
| # grep jeff /etc/passwd
| jeff:zzzzzzzz:Jeffrey Hyman:/usr/jeff:/xxx/xxx
|
| It has also been tested outside domain 'cactus.com' with same results.
| I will BOUNCE you a copy of this email.

Ditch the version of deliver.vacation I sent in my last message.

A revised one is attached.


--
JP
==> http://www.frappr.com/cusm <==

On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:

>
> Ditch the version of deliver.vacation I sent in my last message.

Why not ditch the whole thing and use procmail. There are vacation
receipes available on the web. Why re-invent the wheel?

jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
|
|
| On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
|
| >
| >Ditch the version of deliver.vacation I sent in my last message.
|
| Why not ditch the whole thing and use procmail. There are vacation
| receipes available on the web. Why re-invent the wheel?

Why should I use 'procmail' when 'deliver' (with its own vacation
template script) works perfectly well, and existed years before the
wheel known as 'procmail' was (re-)invented?

--
JP
==> http://www.frappr.com/cusm <==

On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:

> jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
> |
> |
> | On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
> |
> | >
> | >Ditch the version of deliver.vacation I sent in my last message.
> |
> | Why not ditch the whole thing and use procmail. There are vacation
> | receipes available on the web. Why re-invent the wheel?
>
> Why should I use 'procmail' when 'deliver' (with its own vacation
> template script) works perfectly well, and existed years before the
> wheel known as 'procmail' was (re-)invented?

Because there are procmail recipes that do EXACTLY what you are trying to
do and are available to anyone who can use Google? For example:
http://www.clarkconnect.com/wiki/ind...o-Reply_Recipe

This one allows a system-wide procmail recipe, which sends auto-replies
only if the user creates a certain file in his/her home directory. The
text of the message is taken from that file. It also has extra capability
to avoid mail loop problems.

Quoting jd :

>
>
> On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:
>
> > jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
> > |
> > |
> > | On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
> > |
> > | >
> > | >Ditch the version of deliver.vacation I sent in my last message.
> > |
> > | Why not ditch the whole thing and use procmail. There are vacation
> > | receipes available on the web. Why re-invent the wheel?
> >
> > Why should I use 'procmail' when 'deliver' (with its own vacation
> > template script) works perfectly well, and existed years before the
> > wheel known as 'procmail' was (re-)invented?
>
> Because there are procmail recipes that do EXACTLY what you are trying to
> do and are available to anyone who can use Google? For example:
>
http://www.clarkconnect.com/wiki/ind...o-Reply_Recipe
>
> This one allows a system-wide procmail recipe, which sends auto-replies
> only if the user creates a certain file in his/her home directory. The
> text of the message is taken from that file. It also has extra capability
> to avoid mail loop problems.

Did you buy a new car when you ashtrays filled up?

bkw

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

On Wed, 28 Mar 2007, brian@aljex.com wrote:

> Quoting jd :
>
>>
>>
>> On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:
>>
>>> jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
>>> |
>>> |
>>> | On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
>>> |
>>> | >
>>> | >Ditch the version of deliver.vacation I sent in my last message.
>>> |
>>> | Why not ditch the whole thing and use procmail. There are vacation
>>> | receipes available on the web. Why re-invent the wheel?
>>>
>>> Why should I use 'procmail' when 'deliver' (with its own vacation
>>> template script) works perfectly well, and existed years before the
>>> wheel known as 'procmail' was (re-)invented?
>>
>> Because there are procmail recipes that do EXACTLY what you are trying to
>> do and are available to anyone who can use Google? For example:
>>
> http://www.clarkconnect.com/wiki/ind...o-Reply_Recipe
>>
>> This one allows a system-wide procmail recipe, which sends auto-replies
>> only if the user creates a certain file in his/her home directory. The
>> text of the message is taken from that file. It also has extra capability
>> to avoid mail loop problems.
>
> Did you buy a new car when you ashtrays filled up?

OK, I'm totally puzzled. Why spend time trying to hack a script that does
not work properly (that's what the original post stated) when there are
working solutions already available?

Apparently, to some people, there is some value in using crufty old tools,
when there are better solutions available, but I just don't see it. I do
subscribe to the "if it ain't broke don't fix it" philosophy, but in this
case, the starting point was broken and in need of fixing. The quickest
solution would likely have been the installation of procmail.

So, let me ask you: if it costs more to fix your car than to buy an
equivalent new car, do you fix your old one? This is not like caring for
a classic car, this is about providing a service to your clients in the
most efficient manner, or don't you care about this?

Another thought for you: Usenet provides a resource for many people, don't
you think that if someone had no existing vacation solution and wanted to
install something that discussing alternatives has value?

But finally: I really don't see why the suggestion of a WORKING technical
alternative should be met with an ad-hominem attack.

----- Original Message -----
From: "jd"
Newsgroups: comp.unix.sco.misc
To:
Sent: Wednesday, March 28, 2007 7:43 PM
Subject: Re: mutt vacation-list issue


>
>
> On Wed, 28 Mar 2007, brian@aljex.com wrote:
>
>> Quoting jd :
>>
>>>
>>>
>>> On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:
>>>
>>>> jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
>>>> |
>>>> |
>>>> | On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
>>>> |
>>>> | >
>>>> | >Ditch the version of deliver.vacation I sent in my last message.
>>>> |
>>>> | Why not ditch the whole thing and use procmail. There are vacation
>>>> | receipes available on the web. Why re-invent the wheel?
>>>>
>>>> Why should I use 'procmail' when 'deliver' (with its own vacation
>>>> template script) works perfectly well, and existed years before the
>>>> wheel known as 'procmail' was (re-)invented?
>>>
>>> Because there are procmail recipes that do EXACTLY what you are trying
>>> to
>>> do and are available to anyone who can use Google? For example:
>>>
>> http://www.clarkconnect.com/wiki/ind...o-Reply_Recipe
>>>
>>> This one allows a system-wide procmail recipe, which sends auto-replies
>>> only if the user creates a certain file in his/her home directory. The
>>> text of the message is taken from that file. It also has extra
>>> capability
>>> to avoid mail loop problems.
>>
>> Did you buy a new car when you ashtrays filled up?
>
> OK, I'm totally puzzled. Why spend time trying to hack a script that does
> not work properly (that's what the original post stated) when there are
> working solutions already available?
>
> Apparently, to some people, there is some value in using crufty old tools,
> when there are better solutions available, but I just don't see it. I do
> subscribe to the "if it ain't broke don't fix it" philosophy, but in this
> case, the starting point was broken and in need of fixing. The quickest
> solution would likely have been the installation of procmail.
>
> So, let me ask you: if it costs more to fix your car than to buy an
> equivalent new car, do you fix your old one? This is not like caring for
> a classic car, this is about providing a service to your clients in the
> most efficient manner, or don't you care about this?
>
> Another thought for you: Usenet provides a resource for many people, don't
> you think that if someone had no existing vacation solution and wanted to
> install something that discussing alternatives has value?
>
> But finally: I really don't see why the suggestion of a WORKING technical
> alternative should be met with an ad-hominem attack.

The point is, the deliver script just uses things that are already on every
sco box out of the box. No installation. It's always valuable to be able to
get jobs done completely within the least common denominator if you can.
It's more efficient, if less fun, than telling the customer you need to
install something new and cooler. When you need a new or more sophisticated
feature that simply isn't available, fine, then the overhead becomes worth
it. But if as appeared to be the case here, the deliver script simply needed
a little bugfix or tweak, I say it was smarter to do that.

But... then again, I still write cgi scripts in, and do pretty much
everything other than actual application coding, in ksh and awk instead of
perl. By now I finally admit the main original arguments against doing
everything in perl no longer applies, which was: I worked on lots of old sco
boxes (as in, several xenix boxes even), and they had neither perl, nor any
painless way to get it, but the very oldest still had ksh88 and awk. (and so
did the few solaris, freebsd, linux, one hpux, one aix,...) Today all boxes
have perl.
The cpu/ram expence of loading a large interpreter like perl just to do
trivial things that could be done with shell builtins and awk, etc...(heck
I see people using perl just to do what cut does!) also mattered on those
old boxes, but while the discrepency is still true today, really doesn't
hurt much today.
So I have to admit theres no special reason to avoid perl anymore except
maybe for embedded or appliance developers, and even there theres an
argument for perl if one perl binary can take the place of all the rest.
Busybox pretty well proves that point I think.

Even though I understand above enough to have just written it, I still just
can't make myself not care about efficiency, and no matter how you dice it,
throwing out an established working thing, which your consultant, who you
pay a lot per hour, is many years fully familiar with, in favor of a brand
new question mark (where is a procmail binary for sco? how do you use it?
will it work with mmdf? does it have any dependancies like expecting a
certain shell (bash), will sco's suid/euid/shell/child-process behaviour
which differs from linux be a problem? will it need a big pain in the ass
library package download? will I need to do unhygenic things to make room on
my small root fs for said library update pack?etc etc etc), is just not
practical unless you need something only available that way, or you
consciously wish to explore the new possibilities and choose to take on the
overhead of the change. BTW, before you dismiss the fud-sounding list of
possible gotchas, every one of those are things I've actually run up against
for real and had to spend considerable time dealing with. And surely I
haven't managed to hit the last software integration problem yet either.

My response was intended to be neither attack nor ad-hominim.
It was merely devoid of all but the point. In my delusions of smartitude I
might even wish to say, efficient.

Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

jd typed (on Wed, Mar 28, 2007 at 04:43:33PM -0700):
|
|
| On Wed, 28 Mar 2007, brian@aljex.com wrote:
|
| >Quoting jd :
| >
| >>
| >>
| >>On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:
| >>
| >>>jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
| >>>|
| >>>|
| >>>| On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
| >>>|
| >>>| >
| >>>| >Ditch the version of deliver.vacation I sent in my last message.
| >>>|
| >>>| Why not ditch the whole thing and use procmail. There are vacation
| >>>| receipes available on the web. Why re-invent the wheel?
| >>>
| >>>Why should I use 'procmail' when 'deliver' (with its own vacation
| >>>template script) works perfectly well, and existed years before the
| >>>wheel known as 'procmail' was (re-)invented?
| >>
| >>Because there are procmail recipes that do EXACTLY what you are trying to
| >>do and are available to anyone who can use Google? For example:
| >>
| >http://www.clarkconnect.com/wiki/ind...o-Reply_Recipe
| >>
| >>This one allows a system-wide procmail recipe, which sends auto-replies
| >>only if the user creates a certain file in his/her home directory. The
| >>text of the message is taken from that file. It also has extra capability
| >>to avoid mail loop problems.
| >
| >Did you buy a new car when you ashtrays filled up?
|
| OK, I'm totally puzzled. Why spend time trying to hack a script that does
| not work properly (that's what the original post stated) when there are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
JD,

I believe the original script I posted was authored by
Jean-Pierre Radley [JP]. Even if not, the script had a
problem and JP fixed it, and he did so rather quickly.
I still have issues with UUCP, but the vacation-reply
portion works like a charm. Its aways nice to know of
alternative ways to fix any problem, but its also hard
to beat some of the fixes given in this forum. There's
a lot of brain power lurking here. I guess I lean toward
the way Brian is thinking in his reply.

In any case, please continue to add your feedback. All input
is appreciated.

- Jeff Hyman

| working solutions already available?
|
| Apparently, to some people, there is some value in using crufty old tools,
| when there are better solutions available, but I just don't see it. I do
| subscribe to the "if it ain't broke don't fix it" philosophy, but in this
| case, the starting point was broken and in need of fixing. The quickest
| solution would likely have been the installation of procmail.
|
| So, let me ask you: if it costs more to fix your car than to buy an
| equivalent new car, do you fix your old one? This is not like caring for
| a classic car, this is about providing a service to your clients in the
| most efficient manner, or don't you care about this?
|
| Another thought for you: Usenet provides a resource for many people, don't
| you think that if someone had no existing vacation solution and wanted to
| install something that discussing alternatives has value?
|
| But finally: I really don't see why the suggestion of a WORKING technical
| alternative should be met with an ad-hominem attack.