At 07:38 2009-10-06 -0600, LuKreme wrote:
I've never had need of any sort of vacation program before, but I am
going to be gone for a week at the end of this month and there is one
account that I need to have some sort of vacation auto-response on.
1) The account has a couple of mailing list subscriptions
2) The account is on a postfix/Courier-IMAP server with procmail
So long as procmail is getting the messages, what should it matter if the
backend is IMAP?
3) I only want a single notice sent to any non-list sender
Write each address you send a reply to into a file. My "CLEANADDR" stuff,
which is found in my sandbox works well for keeping the addresses as
addresses only (without superfluous nametext). Just be sure to check the
cache file without case sensitivity, in case they're mailing from different
PC configurations.
4) Obviously, no responses to list traffic, but if someone CCs me and
a list, I do want them to get a notice.
If you filter and store lists BEFORE personal correspondance, then this
should be easy.
5) The mail traffic on this account is pretty light (<100 messages a
day, more than half are list traffic)
If the recipe is set up correctly, volume isn't a factor.
6) Solution does not have to be procmail based (perl, php, ruby,
python, et al are available)
My question is what is the best solution? I've been the victim of far
too many poorly designed vacation scripts to just drop something in
without doing some research. On the other hand, I don't want to spend
the next three weeks writing a complex procmail file to do all this
when I know that good solutions must exist somewhere.
Complex?
Filter/identify lists (such as with listid.rc, then use the LISTNAME
variable as an exclusionary condition for the vacation recipe), check for
the presence of the reply-to address in your cache file, if present, you've
sent them a notice and you take a pass on doing it again. Otherwise, add
the reply-to address to the cache file, and send them an autoreply (which
REALLY REALLY should include a reference to the message they sent you - so
subject, or something, so they've got an idea why you're mailing them in
case you're a BCC or something).
If you're going to use vacation stuff, consider isolating the appropriate
place in your procmail recipes to situate the vacation handler - ideally,
this is after listid and standard variable extractions, after spam/malware
filtering, but before you actually start storing messages away.
Note that you can put addresses into the address cache file IN ADVANCE,
thus preventing the vacation message from being sent to certain addresses
which you know won't appreciate the notice, or which would take issue (or
are not lists but are also not people - say automated notification
systems). If you cripple the vacation recipe so that it tracks addresses
but doesn't SEND the notice, you can enable it before you go on vacation
and see that it's only looking to send notices to individuals and not
lists. Be sure to clear the cache and de-cripple it before you go though.
From my 13 year old implementation (which hasn't been used since I went on
a vacation in 1996, though I've been on vacations since then <g>), with a
couple of tweaks:
# Vacation mail handling.
VACATIONFILE=$HOME/path/to/flag/file
ALREADYSENT=$HOME/.vacation.cache
VACATIONMSG=$HOME/path/to/autoreply/text
# first, do this ONLY if the vacation file is present (allows you to
# externally toggle vacation on and off) and if this isn't a daemon message
# we also check that the LISTNAME variable is EMPTY (presumes use of listid.rc
# or similar)
:0
* ? test -e $VACATIONFILE
* !^FROM_DAEMON
* LISTNAME ?? ^^^^
{
# if vacation is in effect, get the reply to address (NOT simply
From:
# because it'd be rude to send something there)
:0 h
REPLYTO=|formail -rtzxTo:
# then, check to see if that address is in the address cache, and
# if not, then send an autoreply.
:0 ch: # the lockfile is important
* !? fgrep -s -e "$REPLYTO" $ALREADYSENT
| echo $REPLYTO >> $ALREADYSENT; \
(formail -rA "Precedence: notification" ;\
cat $VACATIONMSG) | $SENDMAIL -t
}
This can be dropped into my sandbox for testing, which will take the
"mailed" notices and store them in a file for review, rather than actually
mailing them. Trivial to take a saved mailbox and throw it at it for testing.
The notification message will have the original subject, and there will be
References and In-Reply-To: header(s) as appropriate to a reply (which
might not be wholly appreciated as it injects the reply into threads, but
it does give the sender a solid idea where your autoreply is associated to
them from - unlike generic _new_ messages with "I'm out of the office"
as a subject, and ZERO reference to what message they sent generated the
reply).
Personally, I shun vacation systems - I've seen the aftermath of far too
many poorly implemented ones, usually implemented Friday at 4:45pm, just
before the person heads out of their office for a two week absence. The
ONE DAY vacation notices ("I'll be out of the office on Wednesday") are a riot.
The canned vacation text should include areacodes (and poss country code)
for phone numbers if any are provided, and actual DATES, not
day-of-week. Time references should include the timezone.
If you update the recipe periodically, it might make sense to rename the
cache and canned text files with a vacation date name (i.e. referencing the
actual vacation you went on), so that the vacation messages can be
different, and you still have reference to the old ones (including who was
notified).
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail