At 13:12 2003-05-31 -0400, William L. Thomson Jr. wrote:
The responder does not respond to itself, but it does respond to emails
where the sender and the recipient are the same.
Uh, perhaps the only emails it should respond to are the ones where *YOUR*
address is in the To: (not even Cc:, just To:) field.
:0 c
* !^FROM_DAEMON
* !^X-Loop: sales(_at_)obsidian-studios(_dot_)com
* ! ^X-Loop:[ ]*sales(_at_)obsidian-studios\(_dot_)com
Allows for the possibility that some schmuckheaded person who autoreplies
this back to you might have translated the leading space in some
fashion. Also, note that the DOT is properly escaped.
* ^TOsales
This is bad form - if you want to match to a specific address, match to
that specific address, not to a simple keyword. Also, match in the To:
field only, not Cc: and Bcc: (via assumptions made through other headers):
* ^To:.*\<sales(_at_)obsidian-studios\(_dot_)com
Also add:
* ! ^Precedence:[ ](junk|bulk)
To lessen the chance that you'll fire off an autoreply to a listserve you
may be subscribed to (though MOST of those will be Bcc'ing you, not
addressing you in the To:). Legit person-to-person mail will not be marked
junk or bulk.
| (formail -rI"From: sales(_at_)obsidian-studios(_dot_)com" -A"X-Loop: \
sales(_at_)obsidian-studios(_dot_)com" ; cat .vacation.msg) | $SENDMAIL -oi -t
Also bad form - you have absolutely NOTHING checking to see if you've
already blessed this particular sender with a vacation message. You should
cache the sender's address in a file and only send a vacation notice if you
haven't previously sent one to that address - that makes it much less
likely that you'll annoy someone to the point that they construct a message
intended to cause your mailserver to implode (say, by forging a message to
be from yourself).
Continuing that X-Loop across a line could be inserting more than one
whitespace (which in turn, is yet another good reason to use the X-Loop
condition I revised above). As a rule, I avoid splitting header
definitions across lines, so that formail invocation would be transformed to:
| (formail -r -I"From: sales(_at_)obsidian-studios(_dot_)com" \
-A"X-Loop: sales(_at_)obsidian-studios(_dot_)com" ; \
cat .vacation.msg) | $SENDMAIL -oi -t
which seems so much more readable anyhow.
Drop the following into a file "vacation.rc", and in your .procmailrc, add:
INCLUDERC=vacation.rc
This way, you can turn the vacation handling on and off by un/commenting
that one line. There are other ways to do this as well - having the
vacation message file act as an external control for example.
# BEGIN vaction.rc
# Originally written 1996-09-23, revised for procmail list on 2003-05-31
# Author: Sean B. Straw
#
# define the address you're monitoring
# You can do this external to including this rcfile, in which case you can
# INCLUDERC this file multiple times for different addresses. This simply
# sets a default if nothing was previously defined.
:0
* MYADDRESS ?? ^^^^
{
MYADDRESS=sales(_at_)obsidian-studios(_dot_)com
}
# Your offsite email address (say, you're travelling, and have a webmail
# account, a text pager, or SMS phone, etc). Undefine if you don't want
# offsite messages (an undefined OFFSITE will disable the urgent forwards)
# Again, you can externally define this (and, if you're planning to do
# that, you might want to NOT set a default here, because otherwise, you
# cannot define it to be unset). Note that the address doesn't have to be
# a remote address - it could be a local mailbox (though for logical reasons,
# it should be a SEPARATE mailbox from the rest of your email). A webmail
# account which is easily accessed from any public terminal makes a useful
# offsite mailbox.
:0
* OFFSITE ?? ^^^^
{
OFFSITE=your_offsite_mailbox(_at_)somedomain(_dot_)tld
}
# define the message file to be sent with information about your absense,
# and who to contact, etc. Please make is SENSIBLE - only idiots refer
# potential strangers to contact "bob" at an unknown number, or provide
# numbers without country and area codes prefixes.
# presumes that $AUTOREPLY is defined to the directory path where you store
# your autoreply texts.
:0
* VACATIONMSG ?? ^^^^
{
VACATIONMSG=$AUTOREPLY/.vacation.msg
}
# define the (flat text) database of sender addresses which we have already
# sent replies to. Between any two vacations, you should want to purge this
# file. You may want to put this in a different directory, or give it a
# vacation-event-specific name. When you return, the contents of this file
# are a convenient reminder of just who was told you were away.
:0
* VACATIONDB ?? ^^^^
{
VACATIONDB=vacation.db
}
# your urgency tag - text checked for in the subject line
# this could be any keyword you define with friends/family/customers to
cause the
# message to be selectively forwarded to another account.
:0
* URGENCY ?? ^^^^
{
URGENCY=\[URGENT\]
}
# If the message is marked with what we've defined as an urgent tag, then
forward
# the message to an offsite address, and continue processing it as normal.
:0c
* ! OFFSITE ?? ^^^^
* ! URGENCY ?? ^^^^
* $ ^Subject:.*$\URGENCY
* $ ^X-Loop:[ ]*$\OFFSITE
| formail -A"X-Loop: ${OFFSITE}" | $SENDMAIL $OFFSITE
# If you were so inclined, you could set a variable in the above recipe
# that identifies that the message was forwarded, and the following
# recipe could make use of that to tack an additional text file into the
# autoreply, letting the sender know that you've actually been notified.
# Don't autorespond to a host of things - daemon messages, messages with
# our own X-Loop, messages with list-type precedences, messages where we
# are not a recipient in tht To: line (Cc: and Bcc: need not apply - people
# address you in that fashion when they're simply "keeping you in the loop").
# And lastly, don't send a notification if the $CLEANFROM address is already in
# our DB (you could check for $SENDER as well - see my sandbox for examples
# of how the fields are centrally extracted already).
# Add the 'E'(lse) flag if you want this only to be sent to people who
# didn't get forwarded as URGENT.
:0c:
* !^FROM_DAEMON
* ! $ ^X-Loop:[ ]*$\MYADDRESS
* ! ^Precedence:[ ](junk|bulk)
* $ ^To:.*\<$\MYADDRESS
* !? grep -s -e "$CLEANFROM" $VACATIONDB
| echo "$CLEANFROM" >> $VACATIONDB; \
( formail -r -I"From: ${MYADDRESS}" \
-A"X-Loop: ${MYADDRESS}" ; \
cat $VACATIONMSG ) | $SENDMAIL -oi -t -f ${MYADDRESS}
# END vacation.rc
That '-f ${MYADDRESS}' bit at the end is intended to set the envelope
address to be that of your account - I'm working on the assumption that you
probably have multiple addresses aliased through the one shell account, and
the shell account itself may not send through the same address - this
better ensures that the notice will effectively be sent from that address,
and not through the hosting account id.
This is a hasty rehash of something I haven't used in ages, since I'm
rarely out of contact (as it is, I carry a 2-way pager 24/7 for CoLo
monitoring), and vacation messages are usually a lot more annoying than
useful - anyone who *REALLY* has business with you would know to contact
you by telephone, and from that would probably receive a message advising
them of your vacation status.
This whole thing is trivial to test in a sandbox - you can throw saved mail
messages at it and see how it will respond without flooding anyone with
crap. See my .sigline for info on sandboxes (which is also where you want
to check for how I generate $CLEANFROM)
---
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