[H-GEN] it's the season for... vacational auto-responders

Greg Black gjb at gbch.net
Tue Dec 2 23:59:36 EST 2003


[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On 2003-12-03, Tony Nugent wrote:

> I've used the vacation utility for my own needs in the past, but
> otherwise it is a long time since I have looked at anything like
> this, and never on a "site-wide" basis (involving multiple users who
> don't have local unix logon shells).
> 
> A quick google search found several promising solutions, but I'm
> wondering what other people here are using (or have used), and what
> is recommended.

I've always used sendmail's vacation program for this.  Apart
from one serious bug[1], it has done exactly what I wanted.

> My requirements:
>  - not respond to any spam that slips though, 

If your software can't eliminate the incoming spam (and it can't
without false positives), how can you expect vacation to do
better?  The spam that your other filters detects should never
be passed on to the vacation program.

>    to known mailing or subscription lists,

If the lists are correctly configured and include the standard
header "Precedence: list" or "Precedence: bulk", vacation will
ignore them.  Most lists do the right thing.

>    and to other things like postmaster mail
>    returns and so on.

These should be filtered at an earlier stage of processing.

>  - only one response to anyone who does send a message and has
>    already been sent an "I'm away" notice.

Configurable with the appropriate arguments to vacation as
covered in TFM.

>  - be secure enough to not allow abuse, and be safe and robust
>    enough to behave the "right way" in case of errors or having to
>    cope with unusual situations, etc.

Apart from the bug[1], it seems to manage OK.

>  - be easy to setup and en/disable on a per-user/mailbox basis
>    (procmail via a global and/or local procmailrc will be fine)

Yes.

>  - a bonus (not essential) would be the ability for users to enable
>    and configure it themselves via a web interface (eventually I'll
>    very probably build this functionality anyway, php is magic :)

You might have to write this, but it's a simple matter.

>  - and probably some other features that I haven't thought of... ;)

Let me guess ...

Cheers, Greg

[1] The serious bug in vacation is noticed if your MTA is qmail;
    it may affect other MTA's, but I'm not qualified to speak
    about them.  The standard vacation only reads some amount of
    data from its pipe -- more than enough to learn all it needs
    to know -- and then closes the pipe.  Sane MTA's interpret
    the close of an unread pipe as an error and retry -- leading
    to results that are not good.  This only happens to large
    messages and so may pass unnoticed for a considerable amount
    of time.

    My solution to this is a wrapper written in a few lines of C
    that reads all the data and passes along as much as vacation
    wants.  If vacation has a real error, it passes that back to
    the caller, but it ignores the premature pipe close.  And it
    all works just fine.  If anybody actually wants my wrapper,
    I can make it available.

_______________________________________________
General mailing list
General at lists.humbug.org.au
http://lists.humbug.org.au/cgi-bin/mailman/listinfo/general



More information about the General mailing list