OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: ??: vacation solution
From: John Hensley (johnsunislelodge.com)
Date: Thu Jun 29 2000 - 07:35:20 CDT

At 19:15 +0800 29 June 2000, Peng Gao <peng.gaorenren-inc.com> wrote:

> in ~/.forward of the particular user:
>
> |/usr/bin/vacation username
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> but my site is very large, so user account are
> in ldap server. there is no ~/.forward

Yeah, that's a problem. The biggest difficulty is privileges: who does
the local delivery program run vacation as? With recipients pulled from
an LDAP map, it's got to be the user ID specified in the default_privs
parameter in main.cf. I'm pretty sure I remember getting it to work at
some point, but it was on a system where all the local LDAP users also
had UNIX accounts and home directories.

I suppose an LDAP-aware vacation could be written that looks up a
"vacation" attribute for the specified user ID, then does the usual with
that in lieu of ~/.vacation.msg. Since it would run with $default_privs,
you'd want to restrict the modification of user maildrop attributes to
prevent them from adding other programs. You could make your LDAP
query_filter parameter something like (formatted to avoid a huge long
line):

(&
  (mail=%s)
  (|
    (!
      (|
        (maildrop="*/*")
        (maildrop="*|*")
        (maildrop="*:*")
      )
    )
    (maildrop="/usr/local/bin/ldapvacation %s")
  )
)

Translation: mail is the recipient, and maildrop either doesn't contain
[/|:] or is the vacation program.

I suppose if one were to get really ambitious, this vacation program
could be generalized to use Postfix' dictionary lookup mechanism instead
of just an LDAP query to retrieve the vacation message, and then you
could use it with other maps, like MySQL. I think that map's
additional_conditions parameter would let you restrict the contents of
the select_field, as in the query_filter example above. You'd probably
need yet another main.cf parameter: vacation_maps.

It should go without saying (but it won't :) that this vacation program
would have to be paranoid about the vacation attribute's contents, etc.
Or you could just always use a canned vacation message.

I think I'm talking myself into something here. Is this needed? Would
anyone be interested in it?

John