Hi
The scripting comes from the pre-installed gui on the server.
(these are like RAQ's but from an intel partnership)
The forwarding syntax works fine , the error lies in the .proc file.
If i comment out the To. test it works.
From testing using a .procmailrc file in its place and setting Verbose and
logfile i found that the To: match is the error but not cured it as yet.
Not 100% up on procmail syntax.It seems to be trying to match a FQDN against
a username!
Mark
--
Obantec Support
www.obantec.net
WebHosting and Domains
Nominet UK Tag Holder
----- Original Message -----
From: "Professional Software Engineering"
<PSE-L(_at_)mail(_dot_)professional(_dot_)org>
To: <procmail-users(_at_)procmail(_dot_)org>
Sent: Friday, March 01, 2002 5:21 PM
Subject: Re: .forward does call autoreply.proc but no message gets sent
At 13:14 2002-03-01 +0000, Support did say:
# NetStructure AutoReply
"| exec /usr/bin/procmail /usr/ins/intel/gui/bin/autoreply.proc #
obantec-dial"
Where'd you find this syntax?
Besides the forward syntax being wrong, the procmail commandline isn't
valid.
Perhaps you should try the .forward syntax shown at the foot of my
disclaimer page - that should work right off.
What are the perms on the procmail script itself?
######################################################################
# global autoreply procmail script
If it really is "global" perhaps it aught to be chucked under
/etc/procmailrcs/ (which procmail treats specially, see the main
manpage). Also, typically procmail scripts are '.rc' files.
:0 Whc: $HOME/vacation.lock
$HOME/vacation.cache$LOCKEXT
would be a trite more authentic for the lockfile name.
#Check if VACATION file is found in the user's home directory
* ? test -f $HOME/.vacation
You might move this down a few conditions - then the really trivial checks
can be done first, and if they evaluate false, we don't even need to check
this.
# Perform a quick check to see if the mail was addressed to us
* $^To:.*$LOGNAME
$ at the beginning is so totally unnecessary.
You might want to have an @$DOMAIN or something after $LOGNAME as
well. Ostensibly though, if this is being invoked by the user, the
message
must have been addressed to them (though perhaps not in the clear, which
is
an issue I harp on people about).
# Don't reply to daemons and mailinglists
* !^FROM_DAEMON
# Mail loops are evil
* !^X-Loop: $LOGNAME
Again, perhaps this should have a domain specifier tossed in there to make
it a more complete identifier.
I'd like to STRONGLY urge you to add:
# We don't bugger people if the message is "bulk" or "junk" precedence,
# which is popularly used by MAILING LISTS. People who autoreply or
# send vacation notices to MAILING LISTS are nimrods.
* ! ^Precedence:[ ]*(bulk|junk)
#The following part stores user name in cache which already received the
autoreply
#Hence they will not receive autoreply again
| formail -rD 8192 $HOME/.vacation.cache
That was the ACTION line for the preceeding conditions, so you aught to
put
a bit of space between it and the start of the next recipe.
:0 ehc # if the name was not in the cache
| (formail -rI"Precedence: vacation autoreply" \
-A"X-Loop: $LOGNAME" \
Remember, if you actually set the $LOGNAME(_at_)$DOMAIN above for the loop
check, this needs to be tweaked too.
-I"From: $USERNAME <$LOGNAME(_at_)$DOMAIN>" ;\
echo "This mail is generated using the AUTOREPLY mechanism :"; \
echo ;
echo ;\
cat $HOME/.vacation; \
) | /usr/sbin/sendmail -oi -t
Use $SENDMAIL instead of invoking sendmail by a hardcoded path. It also
allows you to very easily place your script into a sandbox for testing,
wherein you don't _actually_ invoke sendmail. See my disclaimer page for
info.
if .forward is used as a simple forward it fine.
Probably because when used as a simple forward, it has the correct syntax.
If I were doing this (particularly as a system to allow other users versus
just myself to use it for vacation), I'd use procmail as the LDA (well, I
do anyway), and set up an /etc/procmailrc which checks for $HOME/.vacation
(and secure permissions - only the owner should be able to write), then
invokes the vacation script right from /etc/procmailrc - if the user wants
to play vacation, they simply create the .vacation file, and poof, they're
on vacation. No futzing with .forward, no mucking up any local
.procmailrc
they may have going (which that .forward is going to cause issues with).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer:
<http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the
list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail