sendmail+greylist-milter problem

[Alexey Tarasov]

Russell Coker wrote:

>On Tuesday 20 December 2005 18:29, Alexey Tarasov <glorg at bk.ru> wrote:
>  
>
>>Problem 1.
>>Installed:  sendmail-8.3.14, milter-greylist-2.0.2,
>>selinux-policy-targeted-1.27.2-19
>>
>>starting sendmail from init results in:
>>maillog
>>---
>>sendmail[1997]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1674:
>>Xgreylist: local socket name /var/milter-greylist/milter-greylist.sock
>>unsafe: Permission denied
>>    
>>
>
>The problem here is that there is no policy for greylist-milter (or any other 
>milter for that matter).
>
>
>I am thinking of now writing a milter policy that is not specific to mail 
>servers (which means I can't call it a "milter" policy as the term "milter" 
>is specific to Sendmail - I need to find a suitable generic term for a MTA 
>helper program).  
>
mta_filter_t is good enough.

>The idea is that the generic mta-helper policy will 
>initially support postgrey and greylist-milter (the two I'm most aware of) 
>and with small modifications to the fc file most milter-type programs.  I'm 
>sure that some milters will have different requirements, but a policy for 
>generic milters won't preclude having specific policies for milters that need 
>it.  Of course this would mean that you can have a set of milters that all 
>have access to interfere with each other, is it common to have multiple 
>milters running in a situation where there is a great need to isolate them 
>from each other?
>  
>
As far as i know, mostly chained filters are used: addittional filter - 
antispam - antivirus
Commercial software sometimes mix them in one filter. As for open source 
- It's better to get all filters working in same context, than isolated 
but not working.
Well known and thus more often used filters are using similar methods to 
plug in to mail transfer agent, so generic contexts will cover not all, 
but most of them.
There is only one problem: generic contexts are better, but for commonly 
used software. Rare soft may be incompatible with them.

>With the Postfix policy I used many domains, but I don't want to always be so 
>free with creating new domains.  With Postfix there is a limit to how many 
>domains will be needed.  But the number of milter programs can grow without 
>limit (there's even a blog at http://www.milter.org/ to inform us about all 
>the new milters that are being written).  So we want to restrict the number 
>of milters that get specific policy both to limit the size of the policy and 
>the difficulty of users getting working systems.
>
>
>Comments?
>
>  
>
It's better to introduce mechanism for programs to add contexts to 
policies during installation progress (or detect somehow at start or ask 
user for installed programms or something else), then  to add many 
domains that never will be used by specific user. There is variety of 
mail transfer programs as well other software (of course, mostly used 
only 3-4 of them, but...) and it's not good idea get in my system 
everything to work with something i'll never used or will use.