Bug#331716: exim4: handling of various system users

[Ross Boylan]

On Wed, Nov 30, 2005 at 08:11:30PM +0100, Marc Haber wrote:
> 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.
How embarrassing!  Sorry  about that.

Anway, won't the first router pick up all cases that the 2nd would
cover?
....
> > > 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.

I think the relevant we in this case would be whatever package created
the new user.  Maybe MTA's could do a check and rewrite if necessary,
but that's pretty ugly.