On Wed, 2009-09-16 at 17:32 +0200, Stefan Schulze Frielinghaus wrote: > On Tue, 2009-09-15 at 09:39 -0400, Christopher J. PeBenito wrote: > > On Mon, 2009-09-14 at 14:41 +0100, Paul Howarth wrote: > > > On 14/09/09 14:01, Christopher J. PeBenito wrote: > > > > On Fri, 2009-09-11 at 16:18 +0100, Paul Howarth wrote: > > > >> On 11/09/09 15:22, Stefan Schulze Frielinghaus wrote: > > > >>> On Fri, 2009-09-11 at 08:30 -0400, Chris PeBenito wrote: > > > >>>> On Fri, 2009-09-11 at 10:20 +0200, Stefan Schulze Frielinghaus wrote: > > > >>>>>>>>>> On Thu, 10 Sep 2009 21:40:56 +0200 > > > >>>>>>>>>> Stefan Schulze Frielinghaus<stefan@xxxxxxxxxxxx> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>>> Attached is a new policy for the dkim-filter application. > > > >>>>>>>>>>> > > > >>>>>>>>>>> Chris, is the policy OK/ready for merge? > > > >>>> > > > >>>>> Tested attached policy again on CentOS 5.3 with strict policy. > > > >>>> > > > >>>> It looks ok. However I'm starting to get concerned about the milter > > > >>>> module getting big. If you want, say the spamassassin milter, you add > > > >>>> the milter module... but then you get rules for a several other milters > > > >>>> too. > > > >> > > > >> True, but how much of a problem is that, given that any milter user is > > > >> at least going to have also the sendmail/postfix policy and the mta > > > >> policy too? > > > > > > > > Perhaps not. But how many milters are there? I don't want to get to > > > > the point where there are 10-20 milters in the same module. > > > > > > Having that many milters is quite conceivable: > > > > > > https://www.milter.org/milters > > > > > > >>> Attached is a milter version which behaves like the apache_template(). I > > > >>> only took care of the dkim-milter but in general this would only mean > > > >>> some reorganization of all modules ... nothing more. Any cons about > > > >>> that? > > > >> > > > >> Splitting each milter out into its own module is certainly do-able; > > > >> doesn't that add overhead (from having more modules) as well though? > > > > > > > > Only a little disk space and some memory during policy linking. No > > > > overhead for the final policy, which is what I'm concerned about. > > > > > > > >>> If this would be the right way then we could also talk about the > > > >>> milter_template() naming convention: > > > >>> > > > >>> type $1_milter_t > > > >>> > > > >>> The apache_template generates slightly different type names: > > > >>> > > > >>> type httpd_$1_script_t > > > >>> > > > >>> What about changing $1_milter_t to milter_$1_t? > > > >> > > > >> That would make sense given that most types in refpolicy are prefixed > > > >> with the module name. There would need to be typealiases added though > > > >> for the old names for the benefit of existing users, wouldn't there? > > > > > > > > Yes. But I'd prefer to keep the current naming convention. I consider > > > > the apache convention nonstandard. > > > > > > Let's split each milter off into its own module then, leaving the type > > > names unchanged. > > > > We'll do this for new milters. The ones that are currently in the > > milter module will stay for now, since its problematic moving types > > between modules. > > Attached is a policy for DKIM-Milter based on the latest changes. Works > fine with the default milter policy. Merged as dkim. In the future please include a .if file, even if its just the <summary> line. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
