Bug#331716: exim4: handling of various system users

Ross Boylan RossBoylan at stanfordalumni.org
Wed Nov 30 19:00:04 UTC 2005


On Wed, Nov 30, 2005 at 04:03:01PM +0100, Marc Haber wrote:
> Hi,
> 
> On Tue, Oct 04, 2005 at 02:29:01PM -0700, Ross Boylan wrote:
> > Thanks to recent local chaos, the system attempted to deliver some
> > undeliverable messages to the original sender, logcheck.
> > 
> > /etc/aliases on my system needed
> > logcheck: root
> > 
> > as an entry.  When I checked, I discovered a signficant, though old,
> > bunch of mail delivered to /var/spool/mail/logcheck.
> > 
> > There's similar story for cyrus.
> > 
> > I don't know if either matter is properly an exim issue, but this
> > seemed the best place to report it.
> 
> The issue here is that /etc/aliases does not belong to any package,
> and we only create it on package installation if it doesn't exist.
> This is consistent with the other MTA packages in Debian, and since
> we share /etc/aliases with them, we decided to go that way.
> 
> > This suggests a more general idea: maybe there should be a router that
> > sends all messages for users < 1000 to root?  I recall there's some
> > Debian policy that would allow identification of account type from
> > uid.
> 
> 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. *
----------------------------------------------------

Also, I recall some earlier discussion that 1000 was not the right
cutoff.

> 
> This will probably break with NIS or LDAP, though.
> 
> 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?

> > 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?

There are certainly a number of issues here, the first being whether
this is a matter that should be managed through the aliases file, by
the MTA, or both.

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.

> That being said, I am inclined to tag this bug wontfix for the time
> being.
That's fine.

Ross




More information about the Pkg-exim4-maintainers mailing list