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