Bug#331716: exim4: handling of various system users

[Marc Haber]

On Wed, Nov 30, 2005 at 11:00:04AM -0800, Ross Boylan wrote:
> On Wed, Nov 30, 2005 at 04:03:01PM +0100, Marc Haber wrote:
> > Technically, this is possible, and I am even using this approach on
> > some of my boxes:
> > set_address_data_uid:
> >   debug_print = "R: set_address_data for $local_part@$domain"
> >   check_local_user
> >   domains = +local_domains
> >   local_part_suffix = +*
> >   local_part_suffix_optional = yes
> >   address_data = "${extract{2} \
> >                            {:} \
> >                            {${lookup passwd{$local_part}}} \
> >                            {$value} \
> >                            {} \
> >                     }"
> >   driver = redirect
> >   data =
> > 
> > local_user_low_uid:
> >   debug_print = "R: local_user_low_uid for $local_part$local_part_suffix@$domain (uid $address_data)"
> >   driver = redirect
> >   check_local_user
> >   domains = +local_domains
> >   condition = "${if <{$address_data}{1000}{1}}"
> >   local_part_suffix = +*
> >   local_part_suffix_optional = yes
> >   data = zgadmin+$primary_hostname-$local_part$local_part_suffix at zugschlus.de
> 
> I'm a little surprised the local_user_low_uid ever gets hit; however,
> I'm not sure what ${extract} does above since the docs say
> --------------------------
> ${extract{<key>}{<string1>}{<string2>}{<string3>}}
> 
> The key and <string1> are first expanded separately. Leading and
> trailing whitespace is removed from the key (but not from any of the
> strings). *The key must not consist entirely of digits. *
> ----------------------------------------------------

The key must not consist of digits to give a hint which form of
extract{ is wanted. If the first argument is entirely made of digits,
the second extract{ form is used which you'll find just a few lines
below in spec.txt.

> > We decided against doing this to keep compatibility with other MTAs,
> > and we'd cement Debian policy into exim configuration which a local
> > admin would probably not like.
> > 
> I'm not sure why a Debian box having Debian policy would be a
> problem.  I guess you're thinking some admins might not want to stick
> to policy?

Yes, especially in heterogenous environments where different OSes
might run from the same LDAP database.

> > > Though I've filed a lot of trivial bugs today, and this one is only
> > > wishlist, I'd say it's a bit important.
> > 
> > Yes, it's so important that I feel that this needs to be solved in a
> > consistent way for all MTA packages in Debian. Would you want to
> > discuss this on debian-devel at l.d.o?
> I'm short of time right now, and am not a developer, but I could kick
> off the discussion sometime in the future.  But is it appropriate for
> a non-DD to do so?

Absolutely. Debian-devel is for discussion regarding Debian
development, but is not restricted to DDs. We have many non-DDs
regularly contributing, and this is appreciated.

> I kind of like having the MTA do it, at least as a fallback, since
> there will probably always be some cases that don't update the aliases
> file appropriately.  If policy prohibits packages from messing with an
> existing alias file (I'm not sure if it does), then it's a certainty
> this will continue to come up.

Since /etc/aliases is not a dpkg-conffile, we could theoretically
modify it.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835