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 [EMAIL PROTECTED]"
> > > 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 [EMAIL PROTECTED] (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 = [EMAIL PROTECTED]
> >
> > 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 [EMAIL PROTECTED]
> > 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
