Re: [Exim] WishList: never_users uid ranges

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Pat Lashley
Date:  
À: exim-users
Sujet: Re: [Exim] WishList: never_users uid ranges
--On Monday, July 14, 2003 10:45:08 +0100 Philip Hazel <ph10@???>
wrote:

> On Fri, 11 Jul 2003, Pat Lashley wrote:
>
>> It would be convienient if the never_users option handling were extended
>> to allow the use of uid ranges. Or better yet, uid ranges and negation;
>> so that an entry like:
>>
>>    never_users = ! mailnull : ! cyrus : !mailman : 0-100

>
> I can certainly Wish List this, but I have to say that I feel there are
> plenty of things already on the list that seem to me to have much wider
> applicability.


My reasoning is that very few of the special uids (bin, daemon, etc.)
should ever recieve any mail; and it doesn't take much security paranoia
to want to prevent deliveries under those uids. Since tradition says
that those accounts (except for 'nobody') occupy a range of low numbered
uids; with 'real' users starting at some arbitrary round number (100,
500, 1000, etc.) it would be convienient to restrict the entire range
rather than have to remember to update your exim config when adding or
removing one of those accounts.


> (I tried to remove never_users from Exim 4, but people complained... :-)


Hmmm. I missed that thread. I just did a search on the mailinglist
archive - lots of hits on 'never_users'; but nothing that looked
relevant. I'm willing to be convinced though. Could you point me
at (or briefly summarize) the rationale and arguments on both sides?


>> (If it already does support something like this, then convert my
>> request to a desire to have the never_users documentation updated
>> to reflect that...)
>
> I try hard to keep the documentation up-to-date with the code.
> Occasionally I fail, but not in this case. :-)


And you do a damn fine job of it too; if I may say so. But I had
to leave open the possibility that I had just missed something
that was in one of the sections discussing more generic aspects
of option syntax.



-Pat